OTAA still confuses me

I have managed to register a device and join using OTAA, but I would like some clarification on how to go forward in using it.

All the examples Arduino sketches I have seen include a join request in the setup but TTN best practices say to avoid unnecessary joins. So what do I do to avoid re-joining when I load a new sketch? I vaguely remember seeing something about storing keys in non-volatile memory on the device but am unclear which keys to store and how to do that if that is the path forward. Or should I just not worry about it and rejoin when changing my code or after a reset?

Is it better to develop using ABP and then only use OTAA for production? I expect to deploy about 10 devices.

Thanks for any enlightenment you can shed on this.

There is no need to worry if you do not reset your device after every uplink. A device can join 65535 times if every attempt uses a unique random number. That won’t happen because you will start hitting previously used random numbers after some time.
However, if your random function does not produce the same pseudo random values after each reset you won’t run into any issues soon. And if you start running into excessive duplicate numbers you can delete the device from the TTN console and re-add it to start with new keys and a clean slate…

1 Like

It is best practice to use a join nonce counter. That is the first value to store in NVM.

Next is the session settings created during the join process. DevAddr, NwkSKey, AppSKey.

Then store the Uplink and Downlink counters. These will change with each packet tx’d or rx’d. You may need another strategy for saving these without wearing a flash or eeprom.

Other session info could be pending mac command answers, ack status and ADR power/datarate/channelmask.

That best practice is not what most stacks implement by default and it only works if your stack allows you to set the nonce, if you are using a module with a LoRaWAN certified stack (rn2483/2903 comes to mind) that might not be possible.

Given that even the big module makers struggle to get storing all applicable parameters right I wouldn’t bother. For a run of thousands of devices that might be worthwhile, for small numbers… And for development when you are uploading new firmware all the time it doesn’t add value at all imho,

I did some demo code for ESP32 which saves all that stuff in FLASH and survives Reflashing of Microcontroller.
You may have a look:

2 Likes