There is no such thing at the gateway. Gateways are stupid and just forward LoRaWAN packets received from the air to the backend and transmit packets received from the backend at the specified time.
Does the device attempt to join when the feature is enabled?
Nope, that feature is part of the code base and its implementation depends on that particular code base. Anything I write would be a guess. Look at the code if the documentation isn’t sufficient, that is what I would need to do as well.
Sorry but it seems you are contradicting yourself. In debug mode with JOIN_BACKOFF_SUPPORT set to true, does it join or does it not join?
BTW, given that these questions seem very specifically related to the Microchip code it might be a good idea to try their forum as @descartes suggests. If you find a solution, don’t forget to report back. We’re curious what it might be…
Hey Marco, let me help you with this! I spent a few weeks breaking my head on this, and finally understood the issue.
The problem is with the Microchip LoRaWAN stack- MLS versions!
The latest MLS 1.0.5 requires LoRaWAN Core 1.0.4 specs, which TTN is not. So you’ll keep having join issues like crazy here.
You need to chose MLS 1.0.4 or lower, which is compatible with LoRaWAN Core 1.0.2 and lower.
So how do you solve this?
For the application examples given by Microchip, choose Atmel Software Framework ASF 3.48 version and lower, and not the latest ASF 3.49+ versions… You can choose between the versions in the application examples… ASF 3.48 incorporates MLS 1.0.4
I’m surprised it took this long for someone to come along who’d read the release notes, what will we do now that you’ve told @MarcoAndrade what to do to fix it.
If any of you want to check out the MLS migration guide, here’s the link
It’s pretty easy to oversee this document, which is hidden in the application code example from Microchip…
There’s a statement in this document, which goes like this: ‘Note: Gateways/Network servers Supporting LoRAWAN 1.0.4 will only be compatible with this firmware version(MLS_SDK_1_0_P_5). Those who are using Network servers with older version (1.0.2) should not migrate to this as this firmware will not be compatible with that version.’
As i had mentioned in my earlier post, this is perhaps the solution to @MarcoAndrade 's issue…
The PDF parked at the top level of all the sample projects when opened in Atmel/Microchip Studio in the file explorer panel??
Just so anyone finding this thread is clear, TTN v2 needs a previous version of MLS and whilst you can tell the v3 stack which version of LoRaWAN you are using so that other devices based on the SAMR34 can be used if they are already running with a previous version, with the WLR089 you should set the device to 1.0.4 when configuring.
