I am encountering a weird issue with the device address of my ‘custom’ device. I a using a Nucleo-WL55JC using the default LoRaWAN_End_Node_DualCore project provided as a example by ST. The LoraWAN stack is compliant with v1.0.3 Revision A specification.
The problem is that regularly, when the device tries to join the Network via OTAA, it retrieves the wrong device address. I’m in eu, so following https://www.thethingsnetwork.org/docs/lorawan/addressing/, my device address should be 0x2601xxxx if I understood correctly. However, I noticed that when the device retrieves a wrong address, the TTN backend shows an address in 0x260Bxxxx, while the device uses an address in 0x2601xxxx.
When printing the device address out the device after the join, it corresponds to the address received by the gateway when trying to send a packet.
A device joining (under OTAA) doesnt join using a Dev Addr - the Dev Addr is assigned by the NS as part of the join process. (Note ABP devices dont ‘join’ they just throw data over the wall hoping NS will receive and accept using pre programmed keys (DEV EUI, APP/JOINEUI, and yes DevAddr set by you/your node)
Unless you are developing changing device and need to force rejoins general principle dont do multiple/repeat rejoins - perhaps only after e.g. battery swap - though even then best practice is persist session data in the device to avoid a full rejoin. You will run out of Dev Nonces eventually!
I am currently working on a Non-Volatile version of the session data, but it is unfortunately unfinished yet, hence the rejoin at each device boot. Currently I have no other choice and have to rejoin, but this devEUI is allocated to a development board, so the Dev Nonces issue is not a concern. This is obviously not the desired behavior for our production devices. Thanks for the reminder anyway, always a good thing !
As for the problem, I may have failed to express myself here, what I meant is that the device uses the Dev Addr that it has received from the NS (I can explore the LoraWAN stack in debug, and printed the received Dev Addr). The default Dev Addr in the device is overwritten by the one recevied. The device uses the address received in the JoinAccept packet, but this address does not match the one set in TTS Application. This means the data packets are not forwarded to the application.
As Jac mentions has the device ever been used in V2? If so does it show as still connected in V2? If there is a V2 GW still in range there can be a race condition where both systems recognise the device, both accept a join req and send a new Dev Addr but the V2 version gets there 1st, esp if crossin Packet Broker with additiona latency, Device accepts that and so… have had that a few times as bench/lab/site has lots of GW’s both V2 & V3 in close proximity, deployed or on soak… needed to make small mod (low order bytes swapped in App EUI) to stop V2 accepting so V3 took hold
You got it, this device was also registered on an old V2 version. We cleared all these old v2 application just in case as well. Thanks a lot for the help both of you !
I can’t seem to find how to mark this thread as solved… Either I’m missing something obvious, or I still do not have the rights to do so (new user account limitations ?)
