no reloading context after power on

[davidBaselga]

I used LoraWan Basic on stm32Cube with STM32L082KZT6 and semtech SX1276IMLTRT.
Join, Uplink and downlink work correctly.

I would like the system not to make a "join" at each startup (power on).

I see backups in EEPROM, at startup during init I also see loading from the EEPROM but I cannot send any frame.
I don't understand why and I haven't found an example.

thanks a lot
David

[opeyrard]

Hi,

Only Devnonce and joinnonce are stored in non-volatile memory as requested by LoRaWAN standard.
The full LoRaWAN stack context is not stored in NVM.

[davidBaselga]

if I understand correctly, To not do a join after a restart I only need joinnonce and Devnonce, or do I need other data?

Thank you very much for your response

[opeyrard]

Hi,
In the current LBM implementation, you have to perform a new Join after a Reset.
The whole context of LoRaWAN is not saved.
We are studying the possibility to improve it (especially to support ABP) in the next release.
Many thanks,

[davidBaselga]

Thank you very much for these clarifications.

I succeeded in saving the context by making these modifications in the lower layers:

• I added the devAdr in the context (CONTEXT_LORAWAN_STACK)
• I added a function to write to fcnt_up: I have a special algorithm who save de fcnt_up only every 100 to limit writing in eprom
• on the SMTC_MODEM_EVENT_JOINED event, I added the key backup: smtc_secure_element_store_context(STACK_ID);

So on the reset event:

• I force the status to join: lorawan_api_set_join_status(STACK_ID, JOINED);
• I load the modem context: modem_load_modem_context();
• I load the keys: smtc_secure_element_restore_context(STACK_ID);
• and I load the new fcnt_up

[opeyrard]

Hi,
To be more LoRaWAN compliant, you could improve your code by saving the LoRaWAN/regional parameters (channel, Data rate, RX1 delay ...) sent by the network server.
Many thanks,

[jonaskerremans-rombit]

Hi, it would indeed be very useful to be able to reuse the OTAA context across boot cycles. Any rough estimates on when this feature would be available?

[gonzabrusco]

Shouldn't this be implemented specially for devices not powered by battery (like an energy meter)? Resets can be a frequent thing, and It makes no sense to perform a join every time there's a power outage.

[opeyrard]

Hi,
At this stage, this feature is not part of the roadmap. This is linked to ABP support.
This could be implemented in the future, depending on ABP support on LoRaWAN 1.2.
Many thanks,

[gonzabrusco]

@opeyrard, do you expect a device powered by an unreliable power source, like the electrical grid, to perform the join procedure every time it loses power?

Quoting SEMTECH's own documentation (https://learn.semtech.com/mod/book/view.php?id=171&chapterid=101):

To ensure that a power cycle does not require the device to rejoin, store the AppSKey, NwkSKey, last used DevNonce, and any JoinNonce values in non-volatile memory (NVM). If you use ABP, also store FCntUp in NVM.

[davidBaselga]

For my project, I have a lot equipment (>50 or 100) that are powered by 220V and start at the same time. If I do the join procedure it takes several hours for all the equipment to connect on network. I implemented random but it is not efficient. The context reload is mandatory for me.
Futhermore, in basic source, the context and key are save in EEPROM or Flash, but some data is missing, I don't understand why to save it ?