search

Lora-net / LoRaMac-node

Reference implementation and documentation of a LoRa network node.
Other
1.88k stars 1.09k forks source link

minimization of persisted data possible? -> battery lifetime optimization #1037

Closed lanmarc77 closed 3 years ago

lanmarc77 commented 3 years ago

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.

altishchenko commented 3 years ago

@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. The reason I am asking such things, is that I am considering an upgrade from 4.4.4 to 4.5.1and didn't have time to analyze the changes between the two yet. At least, in 4.4.4 it was possible to modify the NVM_CTX_STORAGE_MASK, which is not the case in 4.5.1... An upgrade from an extremely older version to 4.4.4 went rather smoothly for me in the past, but EEPROM write time on my chip (STM32L051) is rather unnoticeable for the purposes of the protocol from my measurements.

lanmarc77 commented 3 years ago

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. The save to the eeprom happens on every transmit. In the beginning the save process is even longer (~5s). The size I can see in the output logs is 1200bytes after join and 224bytes after each paket transmission. From what I have seen is that the change detection is happening by comparing the nvm structs crc32. I added a patch to only update the eeprom if the devnonce changes. This works for me and also works when rejoining in an 1.0.4 network. I am using an IM880b module which uses the STM32L151.

altishchenko commented 3 years ago

@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. As for the sleep modes, some devices (non-STM ones) can't retain RAM in a proper battery saving sleep mode, they use more like standby mode in STM speak...

djaeckle commented 3 years ago

Hi all, thanks for the reports and the discussion. In general, the procedure to store and restore data is designed in the way that it supports devices which use a low power mode which loose the RAM context. Also, the end node should not run into the OTAA procedure every time it wakes up.

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.

lanmarc77 commented 3 years ago

Sure, fine with me.

bwesen commented 3 years ago

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.