Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AU915 frequency #18

Open
shinukamo opened this issue Jun 10, 2019 · 23 comments
Open

AU915 frequency #18

shinukamo opened this issue Jun 10, 2019 · 23 comments
Labels

Comments

@shinukamo
Copy link

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 facchinm added the bug label Jun 10, 2019
@facchinm
Copy link
Member

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
Copy link
Author

Thanks @facchinm

I'm using firmware 1.1.9 with the MKRWAN library

@leogaggl
Copy link

leogaggl commented May 4, 2020

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
Copy link

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

@facchinm
Copy link
Member

Hi @aalbinati , could you please test this arduino-libraries/MKRWAN#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
Copy link

@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
Copy link

ElectronicallyE commented Apr 19, 2021

@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
Copy link

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
Copy link

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

@ElectronicallyE
Copy link

ElectronicallyE commented Apr 20, 2021

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
Copy link

aalbinati commented Apr 20, 2021

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
Copy link

@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
Copy link
Member

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

@aalbinati
Copy link

aalbinati commented Apr 20, 2021

@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
Copy link

ElectronicallyE commented Apr 21, 2021

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
Copy link

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
Copy link

ElectronicallyE commented Apr 22, 2021

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
Copy link

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

You are right!

@PaulSchulz
Copy link

(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
Copy link

ElectronicallyE commented Jun 29, 2021

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
Copy link

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
Copy link

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
Copy link

Bobblybook commented Nov 5, 2021

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..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants