search

arduino / mkrwan1300-fw

22 stars 23 forks source link

AU915 frequency #18

Open shinukamo opened 5 years ago

shinukamo commented 5 years ago

When using joinOTAA() with band set to AU915, my nodes send join requests on frequencies between 902 and 928. My gateway is (correctly, I think) ignoring messages sent on frequencies outside of 915 to 928.

This is seriously tanking the reliability of my project. Is there a way to fix this in the firmware? Or is it a hardware problem?

facchinm commented 5 years ago

Hi @shinukamo , it looks like the node is picking US915 configuration (https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html#us902-928). For sure it's not an hardware problem but fw or library related.

shinukamo commented 5 years ago

Thanks @facchinm

I'm using firmware 1.1.9 with the MKRWAN library

leogaggl commented 4 years ago

I do believe the AU915 is definitely not behaving properly when used fro the MKRWAN library. There seems to be no way to set the frequency sub-band anywhere? Unless I am missing something.

In Australia, TTN gateways are generally set to use FSB2.

Using the MKRWAN library on MKR WAN 1310 will eventually do an OTAA join, but only after quite a number of retries. Also, any data send is extremely unreliable.

aalbinati commented 3 years ago

I have the same problem. Joining over OTAA fails 80% of the times I try to join. How could this problem be fixed?

facchinm commented 3 years ago

Hi @aalbinati , could you please test this https://github.com/arduino-libraries/MKRWAN/pull/90 PR (after flashing fw 1.2.3 using MKRWAN_firmwareupdate_standlone sketch) ? It should allow a greater granularity when setting up the channels in use, fixing the gateway "avaliable bands" problem

aalbinati commented 3 years ago

@facchinm @leogaggl I can confirm this works perfectly for me! For AU915 sub-band 2 users you must run this function in your script so the device can send only packets in the frequencies they will be listened to:

modem.sendMask("ff000001f000ffff00020000");

Thanks!

ElectronicallyE commented 3 years ago

@aalbinati, thanks for letting us know it's working. Unfortunately, I can't get it to connect. Seems to be it's timing out (getting Something went wrong; are you indoor? Move near a window and retry and it's stalling on if (waitResponse(timeout, "+EVENT=1,1") != 1) {). Had a couple of questions:

  1. Could you share your code? Saves me asking a heap of questions!
  2. Could you explain what f000001f000ffff00020000 refers to?

I'm using the example file LoraSendandReceive with the frequency plan changed to AU915.

The MKRWAN1310 firmware is 1.2.3.

Regards,

Lachlan

aalbinati commented 3 years ago

Hi @ElectronicallyE ,

  1. Of course, Just blocked all channels that weren't from sub-band 2 and then I did a common OTAA join.

    AU915 OTAA Join gist

  2. f000001f000ffff00020000 is the string you get as the channel mask if you block all channels except those from sub band 2. This way your 8-channel gateway will be always listening to your join request if you set it to use sub--band 2.

If you are still having issues just let me know!

aalbinati commented 3 years ago

btw @facchinm, I think we could already mark this issue as solved!

ElectronicallyE commented 3 years ago

Thanks @aalbinati. The code works in V2 of The Things Network Console. Switching over to V3, I can't get it to work, which is what I was using for testing before.

I've put a post on TTN Forum regarding this issue (https://www.thethingsnetwork.org/forum/t/mkr-wan-1310-wont-connect-to-the-things-stack-v3-drop-join-request-au915/46884). Mind taking a look?

Lachlan

aalbinati commented 3 years ago

Alright but that's not because of a failed join request but because of a misconfiguration in the TTN settings. I use a custom Chirpstack server and not TTN so I might not be able to help you here. Only note is that the MKR 1310 uses 1.0.2 rev B not A. Also, I would try setting the data rate yourself and ADR to false. Maybe that fixes your data rate not found problem

ElectronicallyE commented 3 years ago

@aalbinati, just tested and working successfully after changing to 1.0.2 rev B. Thanks! Seems that ADR also works, (Link ADR accept received). Will do some more testing.

For future reference, where did you find the info which states the supported LoRaWAN and regional parameter versions?

facchinm commented 3 years ago

@aalbinati I'd wait until the new channel mask functions are properly documented to close the issue but yes, it's solved :slightly_smiling_face: Thank you for the invaluable feedback and help!

aalbinati commented 3 years ago

@ElectronicallyE glad to hear it now works. The regional parameter version is hidden somewhere in the code I cannot seem to find it right now. Maybe it would be nice to clarify it in the readme.md file.

ElectronicallyE commented 3 years ago

Hey @aalbinati, I'm trying to make sense of f000001f000ffff00020000. I understand what its purpose is, as per your earlier reply, but how did you determine that it was the correct mask for AU915 FSB 2 (channels 9-16, plus a downlink channel)?

As far as I understand, the 24 hexadecimal characters (90 bits) are separated into blocks of 4 characters (16 bits), so ff00 0001 f000 ffff 0002 0000. The mask size for AU915 is 6 (6 x 16 bits).

aalbinati commented 3 years ago

Hey @aalbinati, I'm trying to make sense of f000001f000ffff00020000. I understand what its purpose is, as per your earlier reply, but how did you determine that it was the correct mask for AU915 FSB 2 (channels 9-16, plus a downlink channel)?

As far as I understand, the 24 hexadecimal characters (90 bits) are separated into blocks of 4 characters (16 bits), so ff00 0001 f000 ffff 0002 0000. The mask size for AU915 is 6 (6 x 16 bits).

Hi @ElectronicallyE,

First of all, AU915 FSB 2 are channels 8-15 plus 500kHz channel 65, all of them are uplink channels and your device will use one of those to send the join request if you correctly configured the channel mask.

Those numbers you see are the hexadecimal representations of binary numbers that indicate which channel to turn on (1) and which one to turn off (0). The best way to make sure you don't make a mistake when defining the mask is to tell your device to turn off al channels and then turn on each individual channel you want be turned on. After that you only have to tell your device to output the channel mask string, this string is the most efficient way to tell your device to turn off all channels except for FSB 2 when it powers on.

I'll post my code here for you to look at it: Gist It seems you need to know a little bit more about the regional specification, you can find it here: LoRaWAN Regional Parameters 1.0.2

Btw, explaining my code made me find an error in the channel mask, I was also enabling channel 16 by mistake. So thanks for making me double check it. One out of 10 tries was going to fail.

I hope I was clear enough ;)

ElectronicallyE commented 3 years ago

Thanks for the explanation. Makes sense. Apologies for the confusion regarding channels. I was referring to channel 0 as channel 1 (source).

For others, note: UPDATED CHANNEL MASK (Channels 8 to 15 plus 65) = ff000000f000ffff00020000

aalbinati commented 3 years ago

For others, note: UPDATED CHANNEL MASK (Channels 8 to 15 plus 65) = ff000000f000ffff00020000

You are right!

PaulSchulz commented 3 years ago

(Quick question): If I read this correctly, why are channels 47,46,45,44 (f0 00) and channels 48-63 (ff ff) enabled? (Other bitmask settings agree with Channels 8 to 15 plus 65.)

Ref: https://lora-alliance.org/wp-content/uploads/2020/11/RP_2-1.0.2.pdf (Sec 282, Line 934)

ElectronicallyE commented 3 years ago

Using aalbinati's channel mask code, try disabling all channels and printing the channel mask. You'll see the output is not all 0s.

Let me know if that’s what you’re experiencing or if you have another issue.

aalbinati commented 3 years ago

Hi @PaulSchulz @ElectronicallyE, that's the mask that get's printed when using the commands for enabling and disabling channels individually. If you think the mask is not correct by reading it then there should be an error in the mask setting function. Do you think you can review that? Thanks

ericjohns commented 2 years ago

Has anyone had any issues with receiving downlink messages with their mkr1300? I have tried setting the mask to both ff000000f000ffff00020000 and ff000001f000ffff00020000. I can send an uplink fine but I'm not receiving anything on the device. Ive tried using a pycom lopy4 with the same configurations on the gateway, ttn and node and the downlink works. I also have the device configured as a CLASS C device. Any help would be much appreciated. Cheers.

Bobblybook commented 2 years ago

Has anyone had any issues with receiving downlink messages with their mkr1300? I have tried setting the mask to both ff000000f000ffff00020000 and ff000001f000ffff00020000. I can send an uplink fine but I'm not receiving anything on the device. Ive tried using a pycom lopy4 with the same configurations on the gateway, ttn and node and the downlink works. I also have the device configured as a CLASS C device. Any help would be much appreciated. Cheers.

Have you checked the RX1 and Rx2 delay windows? I had issues with the MKR1300 on downlinks too, and I realised it was not correctly obtaining Rx1 and Rx2 on subsequent joins. Manually setting these delays to the correct values from TTN tended to fix it I think..