@bluejedi I agree that the save should be made in lmic library, and should adapt to different kind of storage. Maybe it can be made by a function which call a callback in user program to save on or more block of byte.
To be generic I think that all the value modified by OTAA join response and by mac command should be save.
It includes, session keys but also RX2 configuration, channels configuration, current datarate, … (like describe in the link put by @arjanvanb)
But for the state to be correct the time must also be correct (for globalDutyavail and Band.avail for global and band duty rate) or maybe you can ignore theses values if you sleep long enough (maybe more than 3 hours, I did not do the exact calculation).
While a callback is a nice option I think it is not required here and possibly makes things more complex / dependent / slower.
Time is a good point. Many/most nodes will not have a realtime clock nor can they access a (NTP) time server, so I’m curious how the time issue might be solved or (reliably) worked around in this case.
Is this solution still state-of-the-art, using it with MCCI LMIC? Or is there a better piece of code for the task of storing/restoring LMIC state while sleeping on ESP32?
In V3 OTAA is the preferred method to join LoRaWAN network.
It is now a good opportunity to switch my devices from ABP to OTAA.
That’s why I would like to know what is required to restore a session after power down the device.
In the end, was there a solution for MCCI LMIC and, for example, an ATmega328P?
MCCI LMIC (and the older classic) show the keys returned when a join request is completed, those need preserving along with the frame count.
It is quite rare for anyone to power down their nodes - particularly on the lightweight AVRs which don’t consume much current at all in sleep mode - so I’m not aware of any implementations but it’s easy enough to code using the built-in flash.
You only need to store the keys each time you get a join accept event - but the frame counter will need storing before power down.
You need to store a bit more, channel definitions provided in the join accept come to mind, RX1 offset, ADR results (power and data rate), DevNonces used for join. There is probably more…
It would be easier to just use a incrementing DevNonce and only save that value and rejoin on reset. Be aware that limits the number of resets to just 65535 times before you need to re-add the device in TTN to generate a fresh set of ‘credentials’.
Thanks for the answers but it is hard to follow the best practices guidelines which says, for example:
“A device should keep the result of an activation in permanent storage
if the device is expected to be power-cycled during its lifetime.”
when the required information is not available or difficult to obtain to implement them.
For a “normal” user, this makes creating a device a trial and error process.
There should be a simple guide where it is described what to save, as always it doesn’t seem easy.
The consensus is that a small device is going to be on all the time, even if it’s in deep sleep, so the code to save the settings is of academic interest. The ESP32 does have code for that because it’s version of deep sleep doesn’t include power to memory.
The only time someone wants to turn off the element that has the settings in is when they have something else that is controlling time - which again is a bit redundant given the very low current levels of many of the appropriate MCU’s in deep sleep mode. In fact it’s got to a point where you can tell if you have succeeded because either your multimeter shows some current draw or it appears to be off - as 0.7µA is usually a bit too low for the average meter to accurately measure.
Even if the device is always switched on, the battery has to be replaced.
After inserting new batteries, the device have lost its settings and start a new session.
This is probably how most otaa devices work.
The idea was a sketch that works with adjustments for all of my devices.
For example there could be a button that force the device to save its
settings and after the batteries have been replaced the old session will continue.
It is complete expected that there will be rejoins if you do a battery change.
It’s not acceptable and has technical issues if you rejoin too frequently.
What is the expected battery life of your devices - if it’s daily, then you have other problems, if it’s a few months or more, concentrate on other aspects of your project.
As I said above, there is a reason you can’t find clear information on saving session info with LMIC, that’s because most people using it have devices that run for months or years, so don’t consider saving session data worth the effort.
