Enable WiFi/BLE automatic light sleep mode on ESP32

[EternityForest]

The ESP32 can do sub-milliamp current while remaining connected, but I don't see anything about enabling automatic light sleep for WiFi.

Since there's already alarms, would it be possible to add some way to idle in the ESP's automatic light sleep mode rather than sleeping the whole time and messing up WiFi?

[tannewt]

I don't think we need another API. Seems like the existing light sleep API should work. Is this ESP32 only or does it apply to more of the ESP line?

[EternityForest]

As far as I know, every popular Espressif chip has an equivalent, I don't think I've ever seen or used one without it.

Adding it to the existing API seems reasonable, but I'm not sure what it would look like, since there are several similar modes, and the WiFi and CPU have separate sleep settings, and the power consumption is more than full light sleep without automatic wakeups for the WiFi hardware.

[dhalbert]

When I was working on ESP32-nn sleep, I gave up on using light sleep because of the first paragraph below:

WiFi/BT and sleep modes

In Deep-sleep and Light-sleep modes, the wireless peripherals are powered down. Before entering Deep-sleep or Light-sleep modes, the application must disable Wi-Fi and Bluetooth using the appropriate calls (i.e., nimble_port_stop(), nimble_port_deinit(), esp_bluedroid_disable(), esp_bluedroid_deinit(), esp_bt_controller_disable(), esp_bt_controller_deinit(), esp_wifi_stop()). Wi-Fi and Bluetooth connections are not maintained in Deep-sleep or Light-sleep mode, even if these functions are not called.

If Wi-Fi/Bluetooth connections need to be maintained, enable Wi-Fi/Bluetooth Modem-sleep mode and automatic Light-sleep feature (see Power Management APIs). This will allow the system to wake up from sleep automatically when required by the Wi-Fi/Bluetooth driver, thereby maintaining the connection.

But the second paragraph says you can... I don't remember exactly why I gave up. Perhaps it was because I could not maintain the state of certain other peripherals, and our intention was that a light sleep did not break anything else.

[EternityForest]

I had it mostly working at one point in Micropython, but never made a PR because nobody replied to the thread and eventually someone else made one.

But now with the C6 and 802.11ax, there's also target wake time, which I believe they say can last for years on a battery, so the APIs should probably support that.

And it seems there's also the ability to sleep for more than one DTIM interval for a similar effect on older WiFi, but it can break broadcast traffic.

Seems like everyone else is using an enum to let you set whether to care about broadcast traffic or not, and we could add an extra wake_interval param for TWT capable boards?

So the API would be:

# For WiFi 5 and earlier, sleep 3 beacons
radio.beacon_sleep=3

# For WiFi 6, sleep 0.3 seconds
radio.wake_interval=0.3

# Idle using automatic light sleep,
# waking as needed for WiFi, until an alarm
# wakes us.  Can't just use time.sleep as we want
# to be able to handle pin interrupts
idle_until_alarm()

[tannewt]

Could you translate a wake_interval to beacon count? That way you only need one more setting.

There is an existing light_sleep API: alarm.light_sleep_until_alarms()

We'd be happy to merge this in if you get it working.

[EternityForest]

I was thinking of that, but I'm not sure how you would get the beacon interval, I'm not seeing any APIs for that in the ESP-IDF, maybe I haven't looked hard enough but I suspect it's not even sent by the AP. You could assume it's 100ms, or measure it? But the value of 1 beacon is special regardless of the interval because of broadcasting, some users will likely want to do DTIM1 regardless of time, so we'd want the ability to explicitly set DTIM1, right?

…

On Mon, Jul 29, 2024, 12:45 PM Scott Shawcroft ***@***.***> wrote: Could you translate a wake_interval to beacon count? That way you only need one more setting. There is an existing light_sleep API: alarm.light_sleep_until_alarms() <https://docs.circuitpython.org/en/latest/shared-bindings/alarm/index.html#alarm.light_sleep_until_alarms> We'd be happy to merge this in if you get it working. — Reply to this email directly, view it on GitHub <#9463 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFZCHZJCOUMKUVVX7BITFLZO2EUHAVCNFSM6AAAAABLPXY7TCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJWGY2TOMJRHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[tannewt]

Start with the bare minimum. We can always add things that folks want.

So, I'd suggest getting the light sleep working under the existing API first.

[EternityForest]

I think I might have some free time so I was planning to work on this in a bit.

If I understand correctly, the idea for now is:

Have the existing alarm.light_sleep_until_alarms use automatic light sleep, letting the chip handle actually entering sleep and waking as needed so peripherals keep doing their thing, preferring correctness over minimum power consumption.

Add a radio.listen_interval property that enables WiFi power saving, matching the API that the IDF exposes, letting you set it in terms of number of DTIM intervals, since the most common bare minimum is just going to be setting it to 1

Target Wake Time gets ignored for now, and can be figured out later.

[tannewt]

Sounds good @EternityForest! Let us know if you need any guidance about where code lives. #circuitpython-dev on Discord is a good place for realtime help.

[EternityForest]

Right now the only thing that seems to be confusing is this file: https://github.com/adafruit/circuitpython/blob/2f626121867efa429b7484fa3ca5a315021cc506/ports/espressif/common-hal/alarm/__init__.c

It uses port_idle_until_interrupt(), which seems to call xTaskNotifyWait, but I don't see how that enters actual light sleep, unless CONFIG_FREERTOS_USE_TICKLESS_IDLE is set somewhere outside the repo.

Does light sleep until alarms actually sleep? The comment // We cannot esp_light_sleep_start() here because it shuts down all non-RTC peripherals. seems to suggest it doesn't and can't sleep without being a breaking API change?

Then, in the documentation, they seem to say things like audio playback are supposed to keep going in light sleep, but the ESP's implementation of light sleep seems to pause things like the UART(You can receive but the send buffer just waits).

Is it sleeping somewhere I'm not seeing, or did they at some point decide to not bother with that to keep the strong guarantees of their sleep API?

Maybe I need to dig out my USB power meter for this and see what it's actually doing!

Edit: I am not actually seeing any power savings in sleep mode. It just hovers around 80mA with 160mA spikes, that's with the screen on powered from a USB wall charger, 5 seconds of time.sleep(), 5 seconds of light sleep until alarms.

Unless I'm missing something, it seems like significant power savings would be a somewhat breaking change or require a new parameter.

ESP does have a wake locks feature and the set of peripherals that stays on is pretty vaguely specified though, so could we change the API of light sleep to just accept that some peripherals might not work unless they use the locks?

Or, could we add a new full_sleep_until_alarms() that turns off peripherals if needed?

This seems like a bigger project that it looked like even though the actual implementation is simple, just because of the API guarantees!