Replies: 6 comments 2 replies
-
@lanmarc77 You are correct about nonce, but as far as I remember, saving crypto info is meant to minimize on the number of OTAA Join requests, because some publicly available networks penalize or otherwise charge for their overuse as joins typically take up more time and resources to process from them. Is this delay you mentioned happens after every transmit? I had an impression that the code makes its best to save only things that were really changed. |
Beta Was this translation helpful? Give feedback.
-
I can see how usefull this beahviour can be, if the device does not go into a sleep mode but completely looses RAM contents. I mainly go into a sleep mode that will be broken by the watchdog. The RAM stays intact. |
Beta Was this translation helpful? Give feedback.
-
@lanmarc77 Oh, I see. I'll have to look at the changes closer then, every transmit should only update FCnts as far as I am concerned. DevNonce only changes before Join, so that should not be a problem. |
Beta Was this translation helpful? Give feedback.
-
Hi all, If you don't mind we move this issue to the Discussions tab as this discussion looks to be a general discussion on NVM usage and not an issue. |
Beta Was this translation helpful? Give feedback.
-
Sure, fine with me. |
Beta Was this translation helpful? Give feedback.
-
I have the same experience, used the old stack for years and now upgraded to the latest and found it impossible to use due to the EEPROM saving hundreds of bytes at every packet (that EEPROM save takes 1-2 seconds on the STM32L0 in the Murata LORA module, so who knows how many issues it causes). I ended up having to completely disable NVM support in the stack. |
Beta Was this translation helpful? Give feedback.
-
Hi there,
first thank you for providing this stack. I am using a much older version since over a year.
I now wanted to upgrade to 4.5.1 and noticed a long time delay after the rx window. I figured out that it takes around 2seconds to save the current nvm information to the internal eeprom of my IM880b.
I scrolled through the LoRaWAN spec 1.0.4 to check where this might come from. I figured out, that the DevNonce needs to be persistet now. But nothing else for OTAA devices. The current implementation seems to persist much more. In my case every cycle 224 bytes, for the flags LORAMAC_NVM_NOTIFY_FLAG_CRYPTO, LORAMAC_NVM_NOTIFY_FLAG_MAC_GROUP1, LORAMAC_NVM_NOTIFY_FLAG_REGION_GROUP1.
Maybe I did not catch all of the data from the spec that needs persisting. Otherwise I would suggest to somehow change the structs to only persist data, that must be persisted. Alternatively maybe not choose to detect changes based on crc32 changes of the struct, but by the originating event, e.g. when a join changes the devnonce, or a new band setup is received; only then the change flags would need to be set.
Beta Was this translation helpful? Give feedback.
All reactions