LoRaWAN Persistence #1346
-
|
The LoRaWAN examples point out that persistent storage is required for LoRaWAN v1.0.4/v1.1 compliance. To this end I have implemented the persistence example at https://github.com/radiolib-org/radiolib-persistence/tree/main/examples/LoRaWAN_ESP32. My custom board has an EEPROM and I store the devnonces as well as the entire session to EEPROM. I restore these when my device powers up. I have two questions about this procedure. First, is storing/restoring the RadioLib nonces and the session to EEPROM sufficient for v1.0.4/v1.1 compliance? Second, in the radiolib-persistence example header there is a caution that "complications with which parts of the session may have changed after an uplink." What parts of the session could change after an uplink is complete? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
|
Hi @rroeber! We wouldn't put out warnings and then provide a solution that doesn't solve the actual problem ;) so rest assured that the persistence example is fully compliant. I don't know what type of EEPROM your custom board uses, but some EEPROM chips
Some or all of the frame counters will change on every uplink, and so may the MAC state because the network might have instructed the device to alter some settings. While the latter is less likely to occur, it may happen at any time. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, Steve. My device sends an uplink, stores the nonces and session to EEPROM and immediately powers off - no low-power modes used. From your answer I probably will not have any session changes to deal with. Good to know. |
Beta Was this translation helpful? Give feedback.
-
|
Well, I was not completely clear, but the frame counters and MAC state are the session. So the session changes on every uplink, by definition. Thus, I hope your EEPROM chip supports many many write cycles, otherwise it will wear out in a few months. |
Beta Was this translation helpful? Give feedback.
Hi @rroeber! We wouldn't put out warnings and then provide a solution that doesn't solve the actual problem ;) so rest assured that the persistence example is fully compliant.
I don't know what type of EEPROM your custom board uses, but some EEPROM chips
are more equaloffer more write-cycles than others. So saving the full session to EEPROM may not be a good idea (which is why the example uses theRTC_DATA_ATTRtag for RTC memory). The nonces must be stored, the session may be lost causing the device to rejoin (but this definitely shouldn't happen often, with once a week being the lower limit in production, preferably at most once a month).