ESP32 on batteries: deep sleep, wake sources, the ULP and the brownout detector

An ESP32 runs on batteries by spending almost all of its time in deep sleep, where the classic chip draws 10 µA with only its RTC timer and RTC memory powered, according to the ESP32 datasheet, and waking briefly to measure and transmit. The radio is the expensive part: Wi-Fi reception alone takes 95 to 100 mA. Battery life is therefore decided less by the sleep current than by how often the device wakes, how long it stays awake and what else on the board keeps drawing current while the chip sleeps.

This guide walks through the power modes, the ways to wake the chip, the ultra-low-power coprocessor, the gap between chip and board, the brownout message that puzzles many first designs, and a method to estimate battery life without guessing.

What power modes does the ESP32 have?

The classic ESP32 datasheet defines five modes. Each one switches off more of the chip and needs more work to get back to running code.

Mode	What keeps running	Typical current (ESP32 datasheet)
Active	CPU and radio	95 to 100 mA receiving, up to 240 mA transmitting 802.11b at full power
Modem-sleep	CPU, radio off	20 to 68 mA depending on clock and cores
Light-sleep	CPU paused, RTC and ULP running	0.8 mA
Deep-sleep	RTC timer, RTC memory, optionally the ULP	10 µA, or 150 µA with the ULP powered
Hibernation	One RTC timer and some RTC GPIOs	5 µA

With the chip powered off through its enable pin, the datasheet gives 1 µA. When Wi-Fi is enabled, the chip moves between active and modem-sleep on its own, which is why a connected ESP32 never drops to the light-sleep figure unless the application configures automatic light sleep.

ESP32 power modes from the classic ESP32 datasheet: each step down switches off more of the chip, cuts the current and makes waking up more expensive.

Newer chips have lower floors. The datasheets give deep-sleep currents of 5 µA for the ESP32-C3, 7 µA for the ESP32-C6 and ESP32-H2, 7 to 8 µA for the ESP32-S3 and 12 µA for the ESP32-C5, all with the RTC timer and low-power memory kept on.

What can wake an ESP32 from deep sleep?

The ESP-IDF sleep modes documentation lists the wake sources for the classic ESP32: the RTC timer, a single RTC GPIO at a chosen level (ext0), several RTC GPIOs combined (ext1), the touch sensor, the ULP coprocessor and, through a separate GPIO wake-up call, pins in the RTC power domain. UART wake-up works only from light sleep.

Waking from deep sleep is a restart. The CPU and most RAM were powered off, so the bootloader runs and the application starts from the top. Variables marked RTC_DATA_ATTR live in RTC memory and survive, which is how firmware keeps a counter, a buffer of readings or the last Wi-Fi channel between wakes. Wi-Fi and Bluetooth connections do not survive either light or deep sleep; the documentation says to stop the radio before sleeping and reconnect afterwards. A device that must stay associated with an access point uses modem-sleep with automatic light sleep instead, at a much higher average current.

One easy mistake: a GPIO with an internal pull-up connected to external circuitry can leak current through the sleep. The documentation recommends calling rtc_gpio_isolate() on such pins before entering deep sleep.

What does the ULP coprocessor do?

The ultra-low-power (ULP) coprocessor is a small processor that keeps running while the main cores sleep. It can read sensors and peripherals and wake the main CPU only when something interesting happens, such as a value crossing a threshold. The ULP documentation describes three generations: the ULP-FSM on the ESP32, S2 and S3, programmed in assembly; the ULP-RISC-V on the S2 and S3, programmed in C; and the LP core on the C5, C6 and P4, a RISC-V core with wider access to memory and peripherals.

The ULP is not free. On the classic ESP32, deep sleep with the ULP powered on rises from 10 µA to 150 µA, and the datasheet quotes 100 µA for a “sensor-monitored pattern” with the ADC at a 1% duty cycle. The ULP pays off when it saves wake-ups: checking a door contact or a water level a few times a second costs far less than booting the main CPU and the radio each time.

Why does a development board draw more than the chip?

The datasheet figures describe the chip alone. A development board adds parts that keep drawing current while the chip sleeps: a linear voltage regulator with its own quiescent current, a USB-to-UART bridge, a power LED, pull-up resistors and whatever sensors are attached. Memory counts too. The ESP32-S3 datasheet tells you to add the PSRAM’s own consumption to its light-sleep figure, for example 140 µA for 8 MB of octal PSRAM at 3.3 V.

The result is that a board that should sleep at 10 µA can draw many times that figure, and the battery estimate built on the datasheet number is off by an order of magnitude. For a battery product, choose or design a board with a low-quiescent regulator, no always-on LED and a USB bridge powered only from USB, and switch sensors off through a GPIO or a load switch. Then measure the whole board, with an instrument that resolves microamps and captures the short peaks of the wake phase.

What does “Brownout detector was triggered” mean?

The brownout detector watches the supply voltage and resets the chip when it falls below a safe level. The ESP-IDF fatal errors page says the chip prints “Brownout detector was triggered” and resets, and that the detector is enabled by default and configured through CONFIG_ESP_BROWNOUT_DET and CONFIG_ESP_BROWNOUT_DET_LVL_SEL.

The usual trigger is a supply that cannot follow the current peaks of Wi-Fi transmission. Espressif’s hardware design guidelines warn that the sudden current increase when the chip transmits can collapse the power rail, and ask for a 3.3 V supply of at least 500 mA with at least 10 µF of capacitance at the power entrance. Common culprits are long thin USB cables, weak USB ports, undersized regulators, batteries near the end of their charge and coin cells, which cannot deliver Wi-Fi peak currents. Fix the supply rather than disabling the detector, which only hides the symptom. For supplies that rise or fall slowly, such as solar or battery charging circuits, the same guidelines recommend a supervisor chip on the enable pin with a threshold around 3.0 V.

How do you estimate battery life?

Split the device’s cycle into a wake phase and a sleep phase, measure each on the real board, and average:

I_avg = (I_wake × t_wake + I_sleep × t_sleep) / (t_wake + t_sleep)
life (hours) = usable capacity (mAh) / I_avg (mA)

I_wake and t_wake cover everything from wake-up to sleep: boot, sensor reading, Wi-Fi association, DHCP, the TLS handshake and the MQTT publish. I_sleep is the whole-board sleep current, not the datasheet figure. “Usable capacity” is lower than the label: derate it for self-discharge, cold temperatures and the voltage at which your regulator stops working.

The formula shows where the effort should go. A full day of deep sleep at the datasheet’s 10 µA is 0.24 mAh, the same charge as about nine seconds of Wi-Fi reception at 100 mA. Once the board’s sleep current is under control, cutting the time awake matters most: send less often, batch several readings in RTC memory and transmit them together, avoid a full Wi-Fi scan on every wake, and keep the TLS session short. If the wake phase cannot shrink enough, the radio is the wrong one, and Bluetooth LE, Thread or LoRaWAN will do better than Wi-Fi.

Where to go next

Choosing an ESP32 compares the variants, including the low-power C6 and H2.
ESP32 with MQTT covers the connect, publish and disconnect cycle a sleeping device runs.
Bluetooth Low Energy for IoT explains the radio that suits the smallest batteries.
Types of IoT devices and the constraints that shape them puts power budgets in context.

Topics: ESP32, deep sleep, battery life, low power, hardware