Measuring ESP32 Deep-Sleep Current: Wake-Source Comparison and Battery-Life Modelling for a Field Sensor Node

Every battery-powered IoT design lives or dies by one number: the current the microcontroller draws while it sleeps. The ESP32's datasheet quotes a deep-sleep current of about 10 µA, but development boards routinely measure twenty to a hundred times that figure because of on-board regulators, LEDs and USB chips that never sleep. This project builds a measurement rig that resolves microamps — an INA226 current monitor with a low-side shunt, cross-checked against a bench multimeter — and uses it to answer three questions with declared error bounds. First, what does a stock ESP32 DevKit actually draw in deep sleep, and how much of it is the module versus the board around it? Second, how do the five documented wake sources compare — timer, EXT0, EXT1, GPIO touch and the ULP coprocessor — in both sleep current and wake latency? Third, which combination lets a soil-moisture field node running on a 2000 mAh lithium cell reach a realistic one-year deployment? The study measures each configuration across ten sleep cycles, reports mean and standard deviation with the rig's stated accuracy, models battery life with a duty-cycle spreadsheet, and closes with a parts-and-power budget for the field node. The deliverable is the measurement dataset, the analysis notebook and the model — an honest characterisation exercise in the tradition of instrumentation coursework, scaled to a question the industry asks daily.

A battery-powered sensor node's life is governed mostly by what its controller draws while asleep, because a duty-cycled node sleeps far more than it works. For the ESP32, the figure everyone plans with — roughly 10 µA — is a bare-chip laboratory number that ignores the development board around the chip: the regulator's quiescent current, the always-on power LED, the USB bridge. Forum measurements swing over two orders of magnitude and quote no methodology, no repeats, no error bounds, so a student designing a one-year soil-moisture deployment cannot tell whether to plan for two months or twenty. The problem this project addresses is the absence of a protocol-first, reproducible measurement of deep-sleep and wake current for a commonly used ESP32 DevKit across all five documented wake sources, together with the conversion of those measurements — with honest uncertainty — into a battery-life model a project team can actually trust and defend in a review.

Abstract. Deep-sleep current is the dominant term in a duty-cycled sensor node's energy budget, yet datasheet figures and board realities diverge widely. This project measures ESP32 deep-sleep and wake currents for five wake sources on a calibrated microamp rig, quantifies measurement uncertainty, and converts the results into a defensible battery-life model for a one-year field deployment.

Introduction. The ESP32 has become the default student and startup microcontroller for Indian IoT projects — soil-moisture stations, gas sensors, cattle trackers — and nearly all of them are battery-powered. The marketing number everyone quotes (deep sleep ≈ 10 µA) applies to the bare chip under laboratory conditions; a ₹300 DevKit board adds an LDO, a USB-UART bridge and a power LED that draw continuously. Between these extremes sits the practical question nobody answers without measurement: on the board a student actually buys, what will the battery do?

Literature and gap. Vendor documentation characterises the chip, not boards; hobbyist forum posts quote single readings without error bars or methodology; the small research literature on node lifetime profiling assumes instrumentation beyond a postgraduate teaching lab. What is missing at this level is a protocol-first comparison: same board, same rig, all five wake sources, repeated measurements with reported dispersion, and a wake-latency measurement that catches the often-ignored boot current spike.

Proposed study. Build and calibrate the rig (INA226, 1 Ω precision shunt, burden verified against a bench DMM at three currents). Measure, for each wake source and for a bare-module control: sleep current over ten 60-second cycles, wake-to-first-instruction latency by GPIO toggle and oscilloscope where available, and the boot energy spike by integrating the wake current transient. Model duty-cycle battery life for a 15-minute-interval moisture node; test the model's sensitivity to sensor-on time and report duration. Deliver the dataset, notebook and a parts/power budget for a one-year deployment on a 2000 mAh cell.

Feasibility. Total component cost is under ₹3,000, all available in Indian retail; the electronics is within M.Sc laboratory skill; the statistics is descriptive plus one sensitivity analysis. The study's honest limitation — a single board sample, so conclusions are about this board family, not all ESP32s — is stated and defended.

In scope. One ESP32 DevKit board family and one bare ESP32-WROOM-32 module; the five documented wake sources; deep-sleep and wake current measurement at laboratory temperature; wake latency by GPIO-toggle timing; boot-energy integration; a spreadsheet duty-cycle battery model for a soil-moisture node with a 2000 mAh lithium cell; measurement-uncertainty reporting for the rig. Analysis in Python with NumPy and Matplotlib.

Out of scope. Hibernation and deep-sleep-with-RTC-memory-off variants beyond one confirmation run; light-sleep operation; temperature and supply-voltage characterisation sweeps; radio transmission energy beyond a single measured transmit window for the model; long-term battery self-discharge and ageing chemistry; certification or product design. The study characterises a board sample; it does not certify all ESP32 boards.

A five-phase measurement protocol, declared before data collection.

Phase 1 — rig build and calibration (weeks 1–4). Assemble the INA226 with a 1 Ω ±0.1% shunt in low-side configuration; write the I²C logger that samples current at up to 100 samples per second to a CSV file. Calibrate at three reference currents (a 10 kΩ, 100 kΩ and 1 MΩ resistor across the 3.3 V rail, giving roughly 330, 33 and 3.3 µA) with the bench DMM as reference; compute the rig's offset and gain correction and its stated accuracy band.

Phase 2 — firmware matrix (weeks 5–7). Write one parameterised firmware sketch covering the five wake configurations, each sleeping 60 seconds, toggling a GPIO on wake, reading a capacitive moisture sensor for two seconds and transmitting a 20-byte payload once; a build flag selects the wake source so the code under test is otherwise identical.

Phase 3 — measurement campaign (weeks 8–12). For each configuration: ten full sleep-wake cycles, logging current continuously; one extended 10-minute pure-sleep run for the sleep-current statistic; oscilloscope or logic-analyser capture of the GPIO toggle for wake latency where equipment is available, else timer-stamp inference with its error stated. One confirmation run with RTC memory off. Bare-module control measured on a minimal carrier with its own LDO.

Phase 4 — analysis and modelling (weeks 13–17). Compute per-configuration sleep current (mean ± SD), wake latency statistics, and boot energy by trapezoidal integration of the wake transient. Build the duty-cycle model: battery life = capacity / (duty-weighted average current), with self-discharge noted. Sensitivity analysis on sensor-on time (1–10 s) and transmit duration (0.5–3 s).

Phase 5 — write-up (weeks 18–20). Report chapters, figures regenerated from the notebook, and the parts/power budget; rehearse the viva with the rig as the live demonstration.

The measurement system separates the device under test from the instrument and the analysis chain, so every number in the report traces to a logged raw file.

flowchart TD
  A["DUT: ESP32 DevKit<br/>parameterised firmware"] --> B["INA226 + 1 ohm shunt<br/>low-side, calibrated"]
  B --> C["I2C logger<br/>100 Sa/s to CSV"]
  C --> D["Raw current logs<br/>one file per cycle"]
  D --> E["Python analysis<br/>sleep mean, wake transient, latency"]
  E --> F["Duty-cycle model<br/>battery-life + sensitivity"]
  G["Bench DMM + reference resistors"] --> B

The device under test runs one firmware with a build-time wake-source selector, which removes code differences as a confound. The logger timestamps every sample so wake latency and boot-energy integration come from the same raw file as sleep current — no second instrument chain. The bare-module control sits on the same rig, which lets the analysis attribute the difference between DevKit and module measurements to board overhead rather than to instrumentation drift.

Three continuations follow naturally. A multi-board sample across sellers would turn the single-board characterisation into a board-family survey, the study's main limitation into its main result. A temperature sweep (10–50 °C in a controlled enclosure) would expose how sleep current and battery self-discharge interact in Indian field conditions, where enclosures routinely exceed 45 °C. Finally, adding a small solar panel and a supercapacitor moves the model from battery-life prediction to energy-neutral design, connecting directly to the ULP-coprocessor configuration this study already measures.