Lowest power consumption while maintaining an association

[tvoneicken]

I'm trying to determine the lowest power consumption that I can get while maintaining an AP association. So far I'm arriving at ~20-25mA, is this the best I can expect?

Overall, I do not understand why Espressif does not provide functions to power down the chip without disconnecting from the AP. As far as I can tell, the majority of APs keep an association alive even if they don't hear from a device for a minute. Why can't I initiate light-sleep with a value up to a minute without disassociating from the AP?

I'm looking at use-cases where the esp32 is battery powered and needs to last for at least a week, if not more, or is solar powered by a small panel. For example as a serial bridge type of debugging tool attached to some other battery operated device in the field, or as an RF-Wifi gateway away from power. In some of these use-cases deep-sleep is not a real option because the esp32 should respond to the network in under a minute (whether that's <5 secs or <60 secs depends on the specific use-case). Using deep-sleep has the overhead of re-associating every time it wakes up.

I have started to work with the latest power-save example IDF application (IDF git head version). I changed the app to have my local Wifi creds and to set the listen interval to 5, i.e. 500ms given the std 100ms beacon interval on my AP. I'm enabling power management with light_sleep and frequency scaling from 10 to 80Mhz. Here is what I observe:

NewFile15.png (47.37 KiB) Viewed 12217 times

The scope shot has 500ms per horizontal division and 100mA per vertical. The current is captured using a uCurrent Gold. The board is an Adfruit Huzzah32, i.e. esp-wroom-32. What I'm seeing:

• There are ~125mA current spikes every 100ms, what is that? Is that due to the wifi beacon even though I set listen_interval to 5? Or some other timer-based housekeeping?
• The current spikes are a bit fatter every 5ms, so the listen interval does do something.
• There are ~550mA current spikes almost every second. I assume that's Wifi TX? Are those ACKs for some random packets destined to the esp32? I'm pinging it (ICMP) every 5 seconds, so one of those spikes could be the Wifi ACK and then ping-reply TX.
• The base power consumption is around 11mA (can't tell that from this particular scope shot), is that the lowest it can go? The datasheet says "light sleep ... 0.8mA". I'm not seeing that.

Here is a magnified view of a portion of the previous scope shot:

NewFile16.png (40.82 KiB) Viewed 12217 times

The most relevant log lines pertaining to power management are the following ones:

Code: Select all

I (346) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (517) pm_esp32: Frequency switching config: CPU_MAX: 80, APB_MAX: 80, APB_MIN: 10, Light sleep: EN
ABLED
I (527) wifi: wifi driver task: 3ffc09ec, prio:23, stack:3584, core=0
I (527) wifi: wifi firmware version: a85ca5e
I (527) wifi: config NVS flash: enabled
I (537) wifi: config nano formating: disabled
I (537) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (547) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (597) wifi: Init dynamic tx buffer num: 32
I (597) wifi: Init data frame dynamic rx buffer num: 32
I (597) wifi: Init management frame dynamic rx buffer num: 32
I (597) wifi: Init static rx buffer size: 1600
I (597) wifi: Init static rx buffer num: 10
I (607) wifi: Init dynamic rx buffer num: 32
I (717) phy: phy_version: 4000, b6198fa, Sep  3 2018, 15:11:06, 0, 0
I (717) wifi: mode : sta (30:ae:a4:23:86:64)
I (717) power_save: SYSTEM_EVENT_STA_START
I (717) power_save: esp_wifi_set_ps(2).
I (717) wifi: Set ps type: 2
I (727) power_save: listen inverval: 5
I (837) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1
I (2797) wifi: state: init -> auth (b0)
I (2797) wifi: state: auth -> assoc (0)
I (2807) wifi: state: assoc -> run (10)
I (3027) wifi: connected with tve-home, channel 1
I (3037) wifi: pm start, type: 2
I (4567) event: sta ip: 192.168.0.130, mask: 255.255.255.0, gw: 192.168.0.1
I (4567) power_save: SYSTEM_EVENT_STA_GOT_IP
I (4567) power_save: got ip:192.168.0.130

The questions I'm left with:

• Why doesn't the IDF seupport light-sleep while keeping wifi on?
• Why does the esp32 wake up every 100ms even though listen-interval is 5?
• How do I bring the baseline/minimum power consumption level down to 0.8mA?
• Can you publish whatever app you use to test list-sleep and achieve the lowest power consumption while maintaining an association?
• Is there anything that jumps out that I'm missing or doing wrong?

[ESP_igrr]

I don't see anything obviously wrong with your test procedure, however we are getting slightly different peak values — 180mA during TX (which may be because of different data rate, antenna, etc, not sure) and 37mA for the periodic 100ms wakeup. We measure these values using a current probe and an oscilloscope, while running the same power_save example. TCP/IP stack timer is responsible for the 100ms period wakeup. Base current consumption (in light sleep state) should be around 1mA. If you are seeing 16mA current consumption in idle state, I see two possible explanations: 1) system is not actually entering light sleep mode, or 2) the measurement setup is not calibrated correctly. To check 1), enable profiling under menuconfig, power management, and after some time (10 seconds) in the app, call esp_pm_dump function. Among other things, it will print how much time was spent in each of the power modes. To check 2, run system/light_sleep example. It has smaller spikes (no wifi) and should be easier to calibrate. Reference graphs are in https://github.com/espressif/esp-idf/bl ... /README.md. Regarding the question why does IDF not provide a function to enter light sleep while maintaining association, I think the answer is that the automatic light sleep feature was intended to provide that. We assume that the wifi driver should know better when a wake-up is required. I see that you want to enter sleep mode for very long periods of time, so we probably need to allow either setting long listen interval, or indeed add a new API to pause listening without disconnecting from the AP.

[tvoneicken]

Thanks for the thoughtful reply, igrr! I will continue to work on this and report back or ask more questions.

[tvoneicken]

Regarding the question why does IDF not provide a function to enter light sleep while maintaining association, I think the answer is that the automatic light sleep feature was intended to provide that. We assume that the wifi driver should know better when a wake-up is required. I see that you want to enter sleep mode for very long periods of time, so we probably need to allow either setting long listen interval, or indeed add a new API to pause listening without disconnecting from the AP.

The reason for this is that I would like to control power usage. If I followed correctly, the reason Espressif introduced the "light-sleep-interval" setting is because otherwise the DTIM setting in the AP controls what the power usage of the esp32/esp8266 is. Often that setting is unknown or cannot be set by the person deploying the esp32/esp8266. The light-sleep-interval setting takes control so the power usage is not left to the unknown AP.

With the current automatic light sleep it is similar. When I deploy an esp32 I cannot control how many broadcasts and other things are happening on the network (for example pings and tcp keep-alives) and they determine how often the esp32 wakes up and thus how much battery power it is consuming. I am currently in the process of trying to determine where the cross-over is between maintaining an association and periodic disconnect/reconnect using light-sleep or deep-sleep. It may be that disconnect/reconnect is better at much shorter wake-up intervals that I think, I will not know until I get to try it out. (Is there already a good write up on this somewhere?)

[ESP_igrr]

To back up the numbers I gave in the previous post, I ran a test using wifi/power_save example of ESP-IDF v3.1.1, and got the below graph. This was captured using TCP0030A current probe on 5A range.

tek00001.png (16.33 KiB) Viewed 12151 times

[tvoneicken]

Thanks for the update. Did you see the issue I'm having with getting the power_save example to run? (https://github.com/espressif/esp-idf/issues/2711)
Would it be possible for you to provide the elf or bin of your power_save example (assuming it works on an esp-wroom-32) and the AP info? I would love to run it locally so I can see whether my issues are due to my Wifi environment or due to some toolchain set-up differences.

[ESP_igrr]

I have seen the issue on GitHub, but someone else is going to look into WiFi disconnections are reply to that issue.
I can say that this might be dependent on Wi-Fi AP, because the same example works in my local testing for hours with only a few disconnects followed by successful reconnect.