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

Stack operation without ram retention during sleep #59

Closed
thomatec opened this issue Mar 25, 2016 · 9 comments
Closed

Stack operation without ram retention during sleep #59

thomatec opened this issue Mar 25, 2016 · 9 comments

Comments

@thomatec
Copy link

Hi,

To minimize consumption during sleep, I don't have ram retention during sleep. To achieve that, i plan to save DevAddr, NwkID, NwkSKey, AppSKey in flash before sleep, and restore them after .
( LoRaMacMibGetRequestConfirm and LoRaMacMibSetRequestConfirm ).

But there are many others global variables in stack and I'm afraid to loose some important configuration data during sleep.
Is it a problem to loose state of stack ?
May it increase consumption at start ? ( receive each time mac commands with configuration data from network)

Is there a way to properly save stack state during sleep ?

Regards,

@kjendal
Copy link

kjendal commented Mar 25, 2016

You must also save the Fcnt (up and down) as these must always increase in value after a join (with the exception of during repeated message transmissions).

@daniwebCH
Copy link

I'm afraid that there would be much more to save, I assume:

  • Uplink counter
  • all the parameters got from the network like, Added and removed channels, ...
  • the Datarate and power (in case of ADR enabled)
  • the information about dutyCycle on different bands
  • the info of last time that a confirmation has been asked (in case that ADR is enabled and by default sending without Confirmation)
  • be aware about running timers, especially in case of duty cycle enabled and your telegram is delayed (it may be quite long from power saving point of view, I mean level of minutes)

Maybe you can try to ask Semtech to facilitate this work to identify those params ;-)
I'm not experienced on this area but if you use an OS and you are running this on a task context, you could save it on NVRAM....

@thomatec
Copy link
Author

No, I only have 32K of flash, i can't use an OS....I'm using structure saved in flash before sleep. I will tell semtech about that.

@abouillot
Copy link
Contributor

One comment, about Flash usage. It will age and depending how often you power cycle your board, it can reach the limit quite fast. depending the component, it will have between 10.000 and 100.000 write cycles. https://en.wikipedia.org/wiki/Flash_memory#Write_endurance. If you power cycle once a day, no problem, but if this is more often, it might be problematic. You probably can write at various location in the flash to prevent aging.
The Flash write and erase will consume some power. Does this is lower than the deep sleep mode of the micro controller you plan to use?
Can you chose a MCU with a very low deep sleep consumption?

@thomatec
Copy link
Author

Yes, one transmission per day during 5 years. 1825 transmission it's largely below 10000....
My consumption is below 1uA without ram retention and about 5uA with. For just a write per day, it's better to save in flash.

@daniwebCH
Copy link

This was a suggestion to ask, but I'm not sure that it is on their priority list.
If you really can't change CPU with one that can make RAM retention at the required power consumption (as example you could have a STM32L0 or L4 that has RAM retention with less than 1uA), then you have some work to do :-(

I would take in consideration those possibilities:
A) Just save the info related to the activation (devAddr, nwkSKey, appSKey), this in case of OTAA (in case of ABP you already have saved) and restart the stack every time using ABP.
But before to do so, verify with Semtech/LoRa Alliance and the network provider if it is accepted that you proceed on this way, from my interpretation it is not forbidden, but you never know what the server side is doing (e.g. when receiving always Frame counter Up = 1) .

B) similar to A) but include more parameters (after discussion with the other parties

C) more safe (from approach, but not from potential introduction of bugs) but may require quite big effort on definition, stack modification and stack merge at every release.
On this case I would proceed on :

  1. Collect all those parameters
  2. Ask Semtech if they have time to review it
  3. add new functions on the stack to save and recover those variables (in case that they have static variables directly on functions, adapt them to take it out)
  4. Test, Test, Test

@thomatec
Copy link
Author

It's possible to get MIB_UPLINK_COUNTER and MIB_DOWNLINK_COUNTER but it's impossible to set them with LoRaMacMibSetRequestConfirm....

@anthonyblx
Copy link

Hi,

Just read quickly. What mcu are you using? Does it have eeprom?
I think (if I am not wrong) that all the STM32L have internal eeprom. Much easier to use as you can write byte in any location (no need to erase half a page etc).

@mluis1 mluis1 added this to the Release Version 4.4.2 milestone Jan 16, 2018
@mluis1
Copy link
Contributor

mluis1 commented Jan 16, 2018

This issue is covered by the #364 issue.

@mluis1 mluis1 closed this as completed Jan 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants