I am using the RAK3172 module to connect to TTN Stack V3 using OTAA. The problem is that the TTN says for best practice we should save activation parameters that are Device address, NwkSKey, and AppSKey. What I see is that every time I power off the module and power it again I need to rejoin. This rejoin requests new activation parameters, i.e., new Device address, NwkSKey, and AppSKey.
How can I reuse the previously obtained activation parameters?
Welcome to RAK forum @mayyan .
It is true that it is best practice but there is no provision at the moment on saving those sessions keys. Do you encounter issues with RAK3172 at the moment? Also, may I know why do you need to power off the device? It consumes very minimal current while it is sleeping.
We use a system that shuts down between samples with the help of TPL5110 timer and a power MOSFET. It consumes 35nA while shutdown. Our team is working on a project to build and deploy thousands of LoRaWAN nodes in forests and rivers. These nodes are supposed to start up fresh everytime for more robustness and reliability. Therefore, shutting down between samples is a must have feature for us. We want to minimize power consumption and to reduce cost of labor that might be, otherwise, needed to revisit nodes to reset or replace batteries. I really hope this feature is soon added to the module which seems really promising and neat.
Thank you, @carlrowan for the reply.
Why doesn’t the module just save the provisioning keys (Device address, NwkSKey, and AppSKey) into its EEPROM when using OTAA like what it does for AppEUI and AppKey?
That’s in direct conflict with how LoRaWAN is designed to work - the entire concept of LoRaWAN from the LoRa Alliance and so applied across the entire industry is that it is a network which carries state forward. Cold restarts aren’t supposed to happen.
That wouldn’t be enough, anyway - you also have to save the uplink and downlink frame counters, channel map, RX2 settings, ADR state, giveup counters, and probably more I’m not thinking of at the moment - really all state… Do so constantly and you potentially wear out the EEPROM in the long run.
Really, LoRaWAN is designed to be implemented on nodes that either retain state in RAM by using a low power sleep mode (as it was already mentioned this module does), or use some novel non-volatile storage like a magnetic RAM.
Given your intended quantity, you really, really need to do this right. Doing an improper rejoin every time you power up will cause no end of trouble, it’s also extremely wasteful of battery as you exhange several unnecessary radio messages. Plus since you can only join with a unique not previously used join nonce, you’ll start seeing the join requests themselves increasingly ignored.
We have been using Catena 4612 by MCCI. This platform uses an FRAM to save what you explained. We have an external FRAM on our custom board. We can use it to save all those numbers. That is exactly what is being done on Catena. Saving these numbers on an FRAM and shutting down between samples saves lots of energy especially when we sample at every one or more hours. Our system uses small batteries and are usually deployed in forests where solar panels do not see sunlight during summer because of leaves. I can see that the other lora module made by seeed can save these states even after repower. Please see section 2.5 EEPROM in the LoRa-E5 AT Command Specification
Hi @mayyan ,
This feature is not yet implemented on RAK3172. I see your valid point shutting down the power using TPL5110 with nanoAmpere operating current at sleep. I will ask some info from the R&D team regarding this.
The savings between a proper low power sleep and an actual shutdown are really not very meaningful - still years from a coin cell, which is itself pretty marginal for the instantaneous power need for a LoRaWAN transmission.
If you’re absolutely determined to use FRAM you probably want to create your own firmware from scratch anyway.