LoRa.nvram_save() doesn't save parameters necessary for ADR

[mgranberry]

I have observed this with a LoPy running 1.8.0b1.

For ADR to perform correctly with deep sleep, the AdrAckCounter value must be saved in order for the device to decrease its data rates.

Similarly some information about the channel mask (among other things) and other setup parameters, transferred in the LinkAdrReq etc MAC commands must be persisted for the lifetime of the device session or the device will behave incorrectly. Channel frequency setups for non-US bands are a separate problem. RX1/RX2 timing windows and frequencies should also be persisted.

It looks like persisting LoRaMacParams and AdrAckCounter within LoRaMacNvsSave and adding some MIB_... enums to handle them should be sufficient. LoRaMacParams doesn't appear to contain any pointers so it should be straightforward.

[jcaron23]

+1

Any update on this?

[jmarcelino]

It's not simply saving/restoring the values because those values shouldn't persist across a true device reset, they must only be restored if the reset cause was the deepsleep shield returning from deep sleep.

[jcaron23]

It seems to me it should be the same behaviour as the join status, frame counters, addresses and keys, so it's really up to the user to decide to call nvram_restore() or not.

There could be a further discussion to make sure the restore happens automatically in some cases and not in others, but I think that's a different topic.

[jmarcelino]

IMHO essential settings for basic communications (frame counters, assigned addresses and keys and in the US case channel map) should be a restored separately from current (but non-essential, in the sense that communication can still happen) transmission parameters such as data rates.