How Do You Manage Power and Use Deep Sleep on the ESP32?

Detailed Explanation

Battery life in an ESP32 product is almost entirely determined by how much time the chip spends at each power level. Getting from a device that runs for a week to one that runs for a year requires moving the ESP32 into lower-power modes for as much time as possible.

Understanding the four power modes, their trade-offs, and the constraints each imposes on the firmware design is the foundation of ESP32 power optimisation.

Power Mode Overview

All current figures are typical values from Espressif datasheets — actual measurements will vary with supply voltage, operating temperature, software configuration, and radio activity. Always measure your actual application's current waveform to validate the design.

Active Mode

Active mode covers both "radio idle" (CPU running, no transmission) and "radio active" (CPU running plus Wi-Fi or BLE transmission). The current is dominated by the radio:

• Wi-Fi TX peak: up to ~240 mA at 802.11n peak throughput (device-dependent, see datasheet table).
• Wi-Fi RX: ~80 mA continuous.
• BLE advertising: ~15 mA peak per advertising event, short duration.
• CPU only (no radio): ~20–30 mA at 240 MHz; ~5 mA at 80 MHz.

For battery-powered designs, minimise time in radio-active mode. Connect to Wi-Fi, publish data, disconnect — do not maintain a continuous Wi-Fi connection if the device sends data only periodically.

Modem Sleep

Modem sleep keeps the CPU running but turns off the radio between DTIM beacon intervals. The CPU can still process sensor data, update a display, or run control loops while the radio is off between beacon windows.

/* Enable modem sleep after connecting to Wi-Fi */
esp_wifi_set_ps(WIFI_PS_MIN_MODEM);    /* wake at every DTIM beacon */
/* or */
esp_wifi_set_ps(WIFI_PS_MAX_MODEM);   /* wake at AP's DTIM interval * listen_interval */

Average current in modem sleep with a DTIM interval of 3 (≈ 307 ms): approximately 15–20 mA average, versus 80 mA for continuous receive. Modem sleep is the right mode for applications that need to receive incoming data (MQTT subscribe, HTTP server) but can tolerate DTIM-interval latency.

Light Sleep

Light sleep pauses the CPU and halts peripheral clocks, but preserves CPU state in SRAM. The Wi-Fi and BLE stacks can maintain connections during light sleep with modem sleep enabled (the radio wakes at beacon intervals automatically).

/* Configure wake sources before entering light sleep */
esp_sleep_enable_timer_wakeup(5000000ULL);    /* wake after 5 seconds */
esp_sleep_enable_gpio_wakeup();               /* wake on GPIO level change */
gpio_wakeup_enable(GPIO_NUM_4, GPIO_INTR_LOW_LEVEL);

/* Enter light sleep (function returns when woken) */
esp_light_sleep_start();

/* Execution continues here after wake */
esp_sleep_wakeup_cause_t cause = esp_sleep_get_wakeup_cause();

Light sleep wake latency is under 1 ms — the firmware continues execution immediately after esp_light_sleep_start() returns. This makes light sleep suitable for applications where a short response time to external events is needed but full deep sleep/boot time is unacceptable.

Deep Sleep

Deep sleep powers off the main CPUs and most peripherals. Only the RTC domain (RTC timer, RTC memory, RTC GPIOs, and the ULP co-processor) remains active. On wake, the chip restarts from app_main() — deep sleep is a partial power cycle.

#include "esp_sleep.h"

/* Wake after 30 seconds */
esp_sleep_enable_timer_wakeup(30ULL * 1000000ULL);    /* microseconds */

/* Or wake on GPIO level (must be RTC GPIO) */
esp_sleep_enable_ext0_wakeup(GPIO_NUM_4, 0);    /* wake when GPIO4 goes LOW */

/* Save state to RTC memory before sleep */
RTC_DATA_ATTR static int boot_count = 0;    /* survives deep sleep */
RTC_DATA_ATTR static float last_temperature = 0.0f;

boot_count++;
last_temperature = read_sensor();

/* Enter deep sleep — does not return */
esp_deep_sleep_start();

RTC_DATA_ATTR marks a variable to be placed in RTC slow memory, which retains its value across deep sleep cycles. Up to 8 KB of RTC slow memory is available for this purpose on the ESP32 (check the specific variant's datasheet — sizes differ).

Wake sources from deep sleep:

• esp_sleep_enable_timer_wakeup(useconds) — RTC timer, most common for periodic sensor logging.
• esp_sleep_enable_ext0_wakeup(gpio, level) — single RTC GPIO level.
• esp_sleep_enable_ext1_wakeup(gpio_mask, mode) — multiple RTC GPIOs, any-high or all-low.
• esp_sleep_enable_touchpad_wakeup() — capacitive touch (ESP32 classic only).
• esp_sleep_enable_ulp_wakeup() — ULP co-processor triggered wake.

ULP (Ultra-Low Power) Co-Processor

The ESP32 includes a ULP (Ultra-Low Power) co-processor — a simple finite-state machine that runs during deep sleep while the main cores are off. The ULP can:

• Read ADC channels periodically and compare to thresholds.
• Read and write RTC GPIOs.
• Access RTC memory.
• Wake the main core when a condition is met (e.g. ADC reading exceeds a threshold).

This allows the device to remain in deep sleep (10 µA) while the ULP (typically 100–300 µA additional when active, much less when idle) monitors a sensor without waking the main CPU for every sample.

The ULP is programmed in ULP assembly or using the ULP FSM API in ESP-IDF. For the ESP32-S3, the ULP is a RISC-V core that can run C code (CONFIG_ULP_COPROC_TYPE_RISCV).

/* Configure ULP to read ADC and wake main CPU if value > threshold */
#include "ulp.h"
#include "driver/rtc_io.h"
#include "driver/adc.h"

/* ULP programs are written in ULP assembly (or C for S3 RISC-V ULP) */
/* This example shows the ESP-IDF ULP FSM setup — see ESP-IDF examples for full code */

Battery Life Estimation

For a periodic sensor node that wakes every 30 seconds, connects to Wi-Fi for 2 seconds to send data, then returns to deep sleep:

Active time per cycle:   2 s at ~80 mA (Wi-Fi active) = 160 mAs
Deep sleep per cycle:   28 s at ~10 µA = 0.28 mAs
Total per cycle:        ~160.3 mAs

Average current = 160.3 mAs / 30 s = ~5.3 mA average

With a 2000 mAh LiPo battery:
Runtime ≈ 2000 mAh / 5.3 mA = ~378 hours ≈ 15 days

To extend to months or years:

• Reduce Wi-Fi connection time per cycle (pre-connect to a faster DHCP, use static IP).
• Increase the sleep period (30 s → 5 min).
• Use a low-power variant (ESP32-C3 has lower active current than ESP32 classic).
• Cut power to external peripherals (sensors, LEDs) during sleep with a GPIO-controlled MOSFET switch — see GPIO configuration and output drive on the ESP32 for the gpio_config() API.

For the full battery life estimation methodology — including multi-state current budgets, temperature derating, and design margins — see battery life calculation for embedded devices.

For battery-powered IoT product firmware optimisation, Zeus Design's firmware team designs ESP32 power management strategies from hardware architecture through firmware implementation.

Design Considerations

• Measure actual current with a high-bandwidth analyser. A multimeter averages current and misses short peaks. An ESP32 connecting to Wi-Fi draws a 200 mA peak for 10–20 ms during the DHCP transaction. These peaks matter for battery selection (voltage sag under pulse load) and for actual runtime estimates. Use a Nordic PPK2 or Otii Arc for accurate waveform capture.
• Set all GPIOs to a defined state before entering deep sleep. Floating input GPIOs can draw several hundred µA through internal substrate diodes depending on the driven voltage level. Call gpio_deep_sleep_hold_en() for any output GPIOs that must maintain their level during deep sleep, and ensure all inputs have pull-ups or pull-downs.
• Use static IP for faster Wi-Fi reconnect. DHCP adds 50–200 ms to each Wi-Fi connection cycle. For periodic-wake designs where every millisecond of radio-active time costs battery, configuring a static IP eliminates the DHCP transaction. Call esp_netif_dhcpc_stop() and esp_netif_set_ip_info() before connecting.

Common Mistakes

• Forgetting to disable the watchdog before entering deep sleep. The task watchdog timer fires if deep sleep entry takes longer than expected (e.g. waiting for Flash cache to flush). Call esp_task_wdt_delete(NULL) before esp_deep_sleep_start() if the task watchdog is enabled.
• Assuming deep sleep current matches the datasheet without external loads. The datasheet specifies ESP32 SoC current only. External components — voltage regulators in quiescent mode, sensors with always-on oscillators, RGB LEDs with pull resistors — all add to the measured system current during deep sleep. Model and measure the full system, not just the SoC.
• Using non-RTC GPIOs as wake sources. Only specific GPIO pins support wake from deep sleep (the RTC GPIOs, typically GPIO0–GPIO5 and GPIO12–GPIO39 on the ESP32 — check the datasheet for the specific variant). Configuring a non-RTC GPIO as a wake source via ext0 produces an error or silent failure. Use rtc_gpio_is_valid_gpio() to validate the chosen pin.
• Not testing the full boot sequence on wakeup. After deep sleep, app_main() runs from scratch including all global variable initialisers, NVS reads, and peripheral initialisations. Time this sequence — it can take 300–800 ms before the application begins useful work, which is significant for applications that wake frequently.