ESP32 Deep Sleep Telemetry: Estimate Battery Life from the Whole Cycle
“The chip draws only a few microamps in deep sleep” is not a battery-life estimate. A field sensor also wakes, starts its regulator and peripherals, measures, connects a radio, retries when coverage is poor, transmits and returns to sleep. Board leakage, battery behavior, temperature and delivery expectations all matter. Optimize the energy of a complete report cycle, then verify it on the assembled device.
Published September 28, 202614 min readLow-power telemetry design
Think in a wake-measure-report-sleep cycle
Battery cost accumulates across the entire product path
1 / WakeRTC source, boot, state restore and sensor power-up.
2 / MeasureWarm-up, sample count, filtering and sensor conversion.
3 / ConnectAssociation, DNS/TLS, payload, acknowledgement and retries.
4 / PersistSequence, time, health and pending-delivery state.
5 / SleepDisable unused domains; schedule a valid next wake.
Deep sleep powers down CPUs, most RAM and digital peripherals; only selected RTC-related resources remain available. This differs from light sleep, which preserves more execution state. Wi-Fi and Bluetooth connections are not maintained in deep sleep. After wake, handle the cause explicitly and restore only the small state needed for the next cycle.
Estimate energy, not just current
For each phase, measure average current and duration. Approximate charge per cycle as the sum of current multiplied by time across wake, sensor, radio, retries and sleep; then add board-level idle draw and the expected number of reports. Translate charge into a conservative service interval using usable battery capacity, not the label’s nominal milliamp-hours. Conversion loss, cutoff voltage, temperature, aging, pulse capability and self-discharge reduce what the application can use.
A dev board can mislead: USB-UART bridges, LEDs, regulators and voltage dividers may dominate sleep current. Measure at the battery input with the final board, sensors, enclosure and antenna. Capture radio current peaks with adequate bandwidth and burden voltage; a slow multimeter average can hide brownout-causing bursts.
Radio policy dominates many reporting workloads
Association, address resolution, DNS, TLS handshakes and weak-signal retries can cost more than the sample itself. Choose an upload cadence that matches the freshness requirement, batch only when latency allows, compress small payloads carefully and use bounded retry with jitter. Persist a sequence number and unsent measurement before transmitting; mark it delivered only after an application-level acknowledgement. Otherwise, a reboot can either lose telemetry or create duplicates.
Do not retry indefinitely while the battery drains. Set a retry budget, preserve pending data locally and defer to the next scheduled window when appropriate. If time synchronization requires network access, define how the device represents uncertain time and how backend ingestion handles delayed records.
Choose wake sources and retained state deliberately
Timer, GPIO and other wake mechanisms vary by ESP32 family and pin. Check the specific chip’s ESP-IDF sleep guide and board wiring; do not copy a wake pin from another model. Some state can live in RTC memory, while ordinary RAM is lost after deep sleep. Store critical counters durably with wear-aware writes, and make a reset or brownout distinguishable from a normal scheduled wake.
Design choice
Measure
Failure to guard against
Sensor duty cycle
Startup stabilization and conversion energy.
Sampling before the sensor has settled.
Network interval
Join time, transmit energy and acknowledgement rate.
Repeated association loops in poor coverage.
Power supply
Quiescent current, efficiency and peak response.
Regulator leakage or radio-induced brownout.
Battery model
Usable capacity across temperature and age.
Planning from nominal capacity alone.
State persistence
Flash write energy and endurance budget.
Excessive NVS writes or lost delivery cursor.
Build observability into the energy budget
Report firmware version, wake reason, cycle duration, battery voltage under load, retry count, reset cause and last successful delivery. These signals help separate a low battery from a coverage problem or a firmware regression. Calibrate voltage-to-state-of-charge for the selected chemistry and divider; one unloaded voltage sample is not a precise fuel gauge. Use sparse, privacy-conscious telemetry and avoid waking the radio solely to send every diagnostic event.
Validate autonomy with a current profiler over representative days, then run an accelerated test that exercises poor signal, cold starts, missed acknowledgements, sensor faults and brownouts. Compare measured energy per successful report to the model and include margin for seasonal conditions and component variation.
In summary
Battery life is a property of the whole sensing and delivery cycle. Measure the assembled board, include radio peaks and retries, model usable capacity conservatively, and make wake, persistence and delivery states explicit. Deep sleep is a useful tool, but energy per trustworthy report is the metric that tells you whether the product will survive in the field.