What is the difference between doing api.system.lpm.set(1) with an empty loop and using api.system.sleep.all() in a loop?
Also, based on my experience using api.system.sleep.all() the device wakes up from sleep via any interrupt, is api.system.sleep.setup(mode, pin) designed to allow only a single source to wakeup the device?
Difference between api.system.lpm.set(1) and api.system.sleep.all() is not easy to explain.
When you write an application that is event driven (timer events, LoRaWAN events, external interrupts, …), which means your loop() is not used and you put it to sleep or even destroy it, api.system.lpm.set(1) makes sure the MCU goes into power save mode between the events.
I am personally preferring this method, most my application examples are based on this.
But if you prefer to use the loop(), you can use api.system.sleep.all() to sleep between the actions you need to take. However, api.system.sleep.all() does not guarantee that your loop is waking up by other events like LoRaWAN events.
I found it rather difficult to write applications this way.
api.system.sleep.setup(mode, pin) is not preventing the loop() to wake up on the “usual” events. It only adds an GPIO as additional wakeup source.
Historically, api.system.lpm.set(1) was added to RUI3 later in the development, to make it easier to write low power applications.
alright, i was reading the apollo3 datasheet and noticed the apollo3 blue has 4 modes: active, sleep, deep sleep and shutdown
I was wondering if the rui3 api provides access to deep sleep mode
The API provides only enabling/disabling of the LPM mode. No further setttings.
Not sure if you have access to the power modes directly. But as this only affects the MCU itself and not the LoRa transceiver, its effect might be limited.
That’s a good point, thanks, I’ll take a deeper look to figure out if this is worth exploring.
It’s just that my use case will have long periods of no action so i wanted to make sure I’m not wasting battery power.
Hello Bernd,
Not completely sure I understand what you’re saying.
So you’re saying that when you’re just event based and don’t use the loop(), then you’re better off with api.system.lpm.set(1)
And also that api.system.sleep.all() might not wake up on all events.
Yet, when I’m looking at your example here, you’re starting by setting up low power here and then also using sleep.all() here
That raises quite a few questions that are still unclear at this stage:
Your explanation would have been much clearer, if, in your example, the loop would have been empty.
I hope you’ll be able to further elaborate for us to better understand how to optimize for low power without side effect because I think this is one of the major expectations of pretty much everyone here it seems.
Thanks
Let me rephrase my sentence:
However,
api.system.sleep.all()does not guarantee that your loop is waking up by other events like LoRaWAN events.
to
If using
api.system.sleep.all()the system will wake up on events like LoRaWAN RX.
Using api.system.sleep.all() sends the loop() immediately back into sleep.
Alternative to api.system.sleep.all() you can use api.system.scheduler.task.destroy(); which makes sure the loop() is never called again. But the scheduler API is not documented well.
How do I find out what events do and dont cause a wakeup when using api.system.sleep.all()
Never thought about it because I am not using sleep() to put device in low power mode.
A little test shows, it wakes up on basically everything
I don’t care in my apps, because if loop wakes up, I just put it back to sleep. I am not doing anything there.
Result from a test app. Sometimes loop() is called before the event, sometimes it is called after the event.
Same code, but using api.system.scheduler.task.destroy();. Loop is called only once.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.
