Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no reloading context after power on #64

Open
davidBaselga opened this issue Jun 5, 2024 · 6 comments
Open

no reloading context after power on #64

davidBaselga opened this issue Jun 5, 2024 · 6 comments

Comments

@davidBaselga
Copy link

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
Copy link

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
Copy link
Author

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
Copy link

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
Copy link
Author

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
Copy link

opeyrard commented Jul 8, 2024

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
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants