You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I posted some explanation of this in one of the linked PRs that's since closed, but here's what is happening (mostly copied from #16431):
lightsleep() behaviour has always been to "sleep for the allotted time unless woken by an interrupt first". This issue was introduced in 74fb42a (#13329) when we switched away from the pico-sdk alarm pool for soft timers and unintentionally made soft timer expiry a wakeup source.
Before 74fb42a (including V1.23), both the pico-sdk alarm pool and the lightsleep wakeup timer use alarm 3. The lightsleep timer would quietly clobber alarm 3's timeout, meaning softtimer events wouldn't wake the chip from lightsleep.
After 74fb42a (including V1.24), soft timer wakeup happens on timer alarm 2 so this interrupt can wake the chip from light sleep. On PICO-W builds this happens every lwIP tick (64ms), which is unexpected and prevents lightsleep from sleeping more than 64ms.
We could change the code back so that soft timer isn't a wakeup source, or make this configurable. However, I think the happy path for most users will be to stop the the lwIP tick (or timers) when there aren't any active network interfaces. That would mean lightsleep+wifi would work (lightsleep stills exit earlier, but wifi stays up with minimal power consumption), however if you instead disconnect wifi then lightsleep would run until something else woke it up or it hits the timeout.
This work has gotten intertwined with some related pico-sdk sleep problems, but now those are approaching resolution (see #16454) then it's probably a good time to revisit it.
I consider the proposal from @projectgus to be a really good solution:
However, I think the happy path for most users will be to stop the the lwIP tick (or timers) when there aren't any active network interfaces. That would mean lightsleep+wifi would work (lightsleep stills exit earlier, but wifi stays up with minimal power consumption), however if you instead disconnect wifi then lightsleep would run until something else woke it up or it hits the timeout.
This would bring back the possibility to lightsleep for >64ms (with WiFi turned off) as it was with <=1.23.0. The Pico_W guys can go back to 1.23 ... but for the Pico2_W there is currently no solution, so this proposal is even more important for those wanting to use a Pico2_W in low power-consumption scenario.
Is there any work going on to stop the the lwIP tick/timers when there aren't any active network interfaces?
I don't seem much point in calling lightsleep() while the wifi radio is active.
The wifi radio consumes much more power than lightsleep saves.
When I run the following fragment on a RPI Pico W power consumption (measured on USB)
jumps from 19.2 milli-amps eventually stabilizing at 52.2 milli-amps.
from network import WLAN, STA_IF
from rp2 import country
from time import sleep_ms
country('ca')
wlan=WLAN(STA_IF)
wlan.active(True)
wlan.connect('my_ssid', 'my_password')
sleep_ms(10000)
Running on a RPI Pico (where lightsleep works) I measure a power consumption drop
of from 19.9 milli-amps to 4.96 milli-amps.
For an application running from battery it makes sense to shutdown WIFI and the CYW43 chip first.
Only after that call lightsleep.
Having said that, I agree with @projectgus about the 'happy path'.
Activity
bclermont commentedon Nov 8, 2024
related to #16180 16180
CrabbyPete commentedon Dec 8, 2024
I got the same result using a regular PICO. Works on 1.23, not on 1.24.1
scruss commentedon Dec 9, 2024
scruss commentedon Dec 9, 2024
Does your Pico say RP2-B1 on the chip, or RP2-B2?
projectgus commentedon Mar 25, 2025
I posted some explanation of this in one of the linked PRs that's since closed, but here's what is happening (mostly copied from #16431):
lightsleep()behaviour has always been to "sleep for the allotted time unless woken by an interrupt first". This issue was introduced in 74fb42a (#13329) when we switched away from the pico-sdk alarm pool for soft timers and unintentionally made soft timer expiry a wakeup source.Before 74fb42a (including V1.23), both the pico-sdk alarm pool and the lightsleep wakeup timer use alarm 3. The lightsleep timer would quietly clobber alarm 3's timeout, meaning softtimer events wouldn't wake the chip from lightsleep.
After 74fb42a (including V1.24), soft timer wakeup happens on timer alarm 2 so this interrupt can wake the chip from light sleep. On PICO-W builds this happens every lwIP tick (64ms), which is unexpected and prevents lightsleep from sleeping more than 64ms.
We could change the code back so that soft timer isn't a wakeup source, or make this configurable. However, I think the happy path for most users will be to stop the the lwIP tick (or timers) when there aren't any active network interfaces. That would mean lightsleep+wifi would work (lightsleep stills exit earlier, but wifi stays up with minimal power consumption), however if you instead disconnect wifi then lightsleep would run until something else woke it up or it hits the timeout.
This work has gotten intertwined with some related pico-sdk sleep problems, but now those are approaching resolution (see #16454) then it's probably a good time to revisit it.
madozu commentedon Apr 30, 2025
I consider the proposal from @projectgus to be a really good solution:
This would bring back the possibility to lightsleep for >64ms (with WiFi turned off) as it was with <=1.23.0. The Pico_W guys can go back to 1.23 ... but for the Pico2_W there is currently no solution, so this proposal is even more important for those wanting to use a Pico2_W in low power-consumption scenario.
Is there any work going on to stop the the lwIP tick/timers when there aren't any active network interfaces?
cpottle9 commentedon Apr 30, 2025
I will weigh-in on @projectgus and @madozu recent comments.
I don't seem much point in calling lightsleep() while the wifi radio is active.
The wifi radio consumes much more power than lightsleep saves.
When I run the following fragment on a RPI Pico W power consumption (measured on USB)
jumps from 19.2 milli-amps eventually stabilizing at 52.2 milli-amps.
Running on a RPI Pico (where lightsleep works) I measure a power consumption drop
of from 19.9 milli-amps to 4.96 milli-amps.
For an application running from battery it makes sense to shutdown WIFI and the CYW43 chip first.
Only after that call lightsleep.
Having said that, I agree with @projectgus about the 'happy path'.