Hi. Yesterday I have encountered a problem that haven’t occurred to me before. I have a device with RN2483, and I use OTAA to join the network. When I initialize the LoRaWAN parameters (DevEUI, AppEUI and AppKey), I store them in RN module’s EEPROM with mac save command, and I join the network with mac join otaa.
The problem is that join command works only the first time I try to join the network. If the device is powered off and on again, on each subsequent attempt the otaa join is denied, even though the parameters are still preserved in EEPROM. The only way to make it work again is to execute mac reset 868, but unfortunately the parameters are erased in the process, so I need to restore them manually.
The firmware running inside the device has been working perfectly before, no matter how many times I did the power cycle or reset. Also, I tried it on another network (Loriot), and everything works fine: on their network i can do sequential otaa join attempts without any issues. Example:
TTN:
mac set … //init parameters
ok
mac save
ok
mac join otaa
ok accepted
mac join otaa
ok denied
LORIOT:
mac set … //init parameters
ok
mac save
ok
mac join otaa
ok accepted
mac join otaa
ok accepted
Anyone has any idea why this happens? Could it be that they updated something in the back-end recently, causing this problem?
The backend maintains your OTAA credentials once joined, both OTAA/ABP communications are the same one the authentication is completed, so I would see an OTAA on the first connect followed by ABP connections with the stored connection values - there seems to be issues about exactly what is stored too see below link.
Also, for EU868 the OTAA Join Accept includes network settings, which change the RX2 parameters. However, an OTAA Join Accept will always use the defaults for RX2. Any chance the Join Accept is indeed using RX2, and that the module is using the TTN-specific settings if it has joined earlier?
Given the logs you’re showing: am I right to assume you were really issuing those commands directly? Hence: for those tests, you did not power off the device between the two mac join otaa commands? (I’m asking as I’d assume that upon a power down the device would forget about any RX2 settings it might have received in the EU868 Join Accept, unless you somehow issued a mac save after the join.)
Also, it might help to know what the failing OTAA Join Request is actually sending? Maybe some screenshots from TTN Console can help. Or, as a Join Request is not encrypted, an online decoder can also decipher it.
Indeed. And for this to work when powering down the RN2xx3 between transmissions, one needs mac save after the OTAA join (and after each transmission, for the counters and all). Probably unrelated, but with an RN2483 version 1.0.1 (Dec 15 2015 09:38:09), I’ve run into an issue with that: after a factory reset, I needed to set (dummy) values for the (ABP) DevAddr, AppSKey and NwkSKey, for otherwise calling mac save after mac join otaa did not save the Join Accept settings, or the subsequent mac join abp somehow did not recognize those.
I’m aware of that, but when the device has been powered down (battery out), there is no way for the device to know that it had already been joined the network. So, it tries to do the OTAA join again and it fails.
@arjanvanb yes, I was issuing the mac commands directly, but actually it don’t matter if the device has been powered down in the meantime or not, the outcome is the same.
As for the screenshot, here it is but it’s not very useful as I don’t see any payload data:
This only tells you that it did not receive an OTAA Join Accept:
If TTN did not receive it, then of course nothing happened.
If TTN rejected it, it will not send any response at all. You will only see the orange Join Request in the gateway’s Traffic page (without a DevAddr).
If TTN accepted it and made one gateway transmit the Join Accept, then somehow the device has not received it. In TTN Console you will see both an orange Join Request Activation in the device’s Data page (now including a DevAddr), and a green Join Accept in the gateway’s Traffic page. Sometimes you’ll also see the orange Join Request in the gateway’s Traffic page. So, in TTN Console all will look fine then.
No, a Join Request does not hold any application data, hence shows no payload in the application’s or device’s Data page. However, this does tell you that TTN accepted it. Also, it uses SF12, so it’s very likely that TTN uses RX2 for the Join Accept (which you should also see in the gateway’s Traffic page, if you have access to the gateway that is transmitting it).
So, I think the RN2483 remembered the non-default setting from the earlier join: I am quite sure it does that when not powering down between the tests, but I don’t understand why it would also do that when powering down, assuming you did not run mac save after the join. And I assume that Loriot is always using the default RX2.
So, what if you execute the following before the second mac join otaa?
…but then the question is still: what changed, making TTN use RX2 now, assuming it previously used RX1 which was then hiding the problem of the wrong RX2 settings?
Maybe the above “init parameters” includes some mac set dr 0 to use SF12, which was not there earlier?
(As an aside: using SF12 indeed increases the chance that the OTAA Join Request is received by at least one gateway, but also implies that your node might keep using SF12 after its join and hence needs a lot of air time. If the node is not moving then make sure to enable ADR when joining at such high SF. When the node is moving, then you should not enable ADR, but then note that using a fixed SF11 or SF12 is not allowed.)
If you’re using the community network, then you’re still on V2.
I’m quite sure any relevant changes are not in the network software, as the RX2 behavior is really old and was implemented in June 2016, and I think that using SF12 has always caused TTN to use RX2. If things worked differently for that same device before, then I’d assume it’s due to using a high SF, or some changes in saving the settings, like in the node’s software or some upgrade of the RN2483’s firmware?
