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.
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.
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:
do you need sleep.all() for the low power setting to actually trigger ?
if you put sleep.all() in the loop, does it prevent catching some of the events ?
what happens after an event is finished if low power is set but the loop is empty ?
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.
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.