LoRa NVRAM clear on restore issues
I had a couple of LoPys on which I had to change batteries today (batteries fully exhausted).
The initial idea was to replace the battery and have the LoPys start again as if they had woken up from sleep. However that did not work, and I ended up having to re-join.
My guess (don't have detailed logs for that though) is that there could be an issue with the recent logic on
lora.nvram_restorewhich clears the NVRAM after the restore. This probably leads to situations that go like this:
- battery is close to exhausted
- LoPy still able to wake up
- starts, nvram_restores, attempts to send
- fully exhausts battery and stops before (or during) nvram_restore
The result is that when a new battery is inserted, it won't be able to nvram_restore.
I'm not sure what the consequences would be if we just kept the previous state and sent a new frame with the same counter (would just the "duplicate" packet be ignored, or would that trigger other issues?).
The alternative (which I'm going to implement for now) will be to re-join automatically if needed (join was done manually when setting up the device only until now), but that seems a bit overkill.
For reference, this is running 1.16.0.b1.
Just to note this method works also for both a software reset AND powercycle.
@han I usually do the initial join process manually moving to the load/work/send/save/sleep cycle.
But if you do a
nvram_restoreand there's nothing to restore,
falseand you can do your join as usual.
You logic should be something along the lines of:
- create lora object
has_joinedis false, join, and wait for
has_joinedto become true
- do the work, send the data
- deep sleep
@jcaron how did you program the nvram_restore()? and where did you placed the rule in your code?
I have some trouble with the first time when the Lopy is starting up and connecting.
If the module is starting up with nvram_restore active, is not joining. But when I make the nvram_restore function inactive it joins directly when the module is starting up.