6  Sensor Networks and Power Management

Multi-Sensor Aggregation and Battery Optimization

sensing
power-management
low-power
networks
Author

IoT Textbook

Published

March 22, 2026

Keywords

power management, deep sleep, battery life, sensor networks, duty cycling, ESP32 sleep

In 60 Seconds

Battery-powered IoT sensor nodes must balance data collection with power conservation. Deep sleep reduces current from milliamps to microamps (10uA on ESP32). The biggest power drain is wireless transmission – buffering 8 readings and sending them together instead of individually can extend battery life by 3x or more. Always configure a wake source before entering deep sleep, or the device sleeps forever.

Key Concepts
  • Sleep Mode: a low-power MCU state where most clocks and peripherals are disabled; the device wakes on interrupt or timer to take a measurement then returns to sleep
  • Duty Cycle: the fraction of time a sensor or device is active versus sleeping; lower duty cycle means lower average power consumption
  • Energy Harvesting: the process of capturing ambient energy (solar, thermal, kinetic, RF) to supplement or replace battery power in IoT nodes
  • LDO Regulator: Low-Dropout Regulator — a linear voltage regulator that operates with very small difference between input and output voltage, improving efficiency at low current loads
  • Sleep Current: the quiescent current drawn by a device in its lowest-power sleep state, critical for estimating battery life between sampling events
  • Power Gating: switching off power to entire circuit blocks (sensors, radios, peripherals) when not needed using a transistor switch, eliminating leakage current
  • Battery Capacity (mAh): the total charge a battery can deliver at a given discharge rate; used with average current to calculate expected battery lifetime in IoT devices

6.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Design multi-sensor data aggregation systems with structured JSON payloads
  • Calculate power budgets for battery-powered sensor nodes using energy-per-cycle analysis
  • Implement deep sleep modes that reduce current consumption to microamp levels
  • Justify transmission buffering as the dominant power optimization by quantifying its 3x+ battery life improvement over alternative strategies
  • Select the appropriate sensor fusion algorithm for a given constraint profile by applying complementary vs Kalman filter tradeoff criteria

Battery-powered IoT sensors face the same challenge as your phone – they need to do useful work while making the battery last as long as possible. The trick is “deep sleep,” where the device wakes up briefly to take a reading, then goes back to sleep, using almost no power. It is like setting an alarm to check the temperature every 10 minutes instead of staring at the thermometer all day.

6.2 Introduction

Battery-powered IoT sensor nodes face a fundamental challenge: they must collect and transmit data reliably while consuming minimal power. A well-designed power management strategy can extend battery life from weeks to years. This chapter covers the techniques that make long-term remote sensing practical – from structuring multi-sensor data payloads, through deep sleep and duty cycling, to transmission buffering strategies that yield the largest real-world battery life gains.

6.3 Multi-Sensor Data Aggregation

15 min | Intermediate | P06.C09.U03a

Combining multiple sensors into a single IoT node requires structured data handling. JSON payloads provide a flexible, human-readable format for transmitting aggregated sensor data.

#include <DHT.h>
#include <Wire.h>
#include <BH1750.h>
#include <Adafruit_BMP280.h>

DHT dht(4, DHT22);
BH1750 lightMeter;
Adafruit_BMP280 bmp;

struct SensorData {
  float temperature;
  float humidity;
  float pressure;
  float altitude;
  float light;
  unsigned long timestamp;
};

void setup() {
  Serial.begin(115200);
  Wire.begin();

  dht.begin();
  lightMeter.begin();
  bmp.begin(0x76);
}

SensorData readAllSensors() {
  SensorData data;

  data.temperature = dht.readTemperature();
  data.humidity = dht.readHumidity();
  data.pressure = bmp.readPressure() / 100.0;
  data.altitude = bmp.readAltitude(1013.25);
  data.light = lightMeter.readLightLevel();
  data.timestamp = millis();

  return data;
}

void loop() {
  SensorData data = readAllSensors();

  // Create JSON payload
  String json = createJSON(data);
  Serial.println(json);

  // Publish to MQTT or send via HTTP
  // publishData(json);  // Implement based on your platform (MQTT, HTTP, etc.)

  delay(10000);
}

String createJSON(SensorData data) {
  // Note: Check isnan() before production use -- DHT22 can return NaN on read failure
  String json = "{";
  json += "\"temperature\":" + String(data.temperature) + ",";
  json += "\"humidity\":" + String(data.humidity) + ",";
  json += "\"pressure\":" + String(data.pressure) + ",";
  json += "\"altitude\":" + String(data.altitude) + ",";
  json += "\"light\":" + String(data.light) + ",";
  json += "\"timestamp\":" + String(data.timestamp);
  json += "}";

  return json;
}
Try It: JSON Payload Size Estimator

The manual String concatenation above works for learning, but production code should use the ArduinoJson library. It handles memory allocation, escaping, NaN values, and nested objects safely:

#include <ArduinoJson.h>

JsonDocument doc;
doc["temperature"] = data.temperature;
doc["humidity"] = data.humidity;
doc["pressure"] = data.pressure;
String json;
serializeJson(doc, json);

6.4 Low-Power Sensor Reading

20 min | Advanced | P06.C09.U03b

Deep sleep modes reduce current consumption from milliamps to microamps, dramatically extending battery life.

#include <esp_sleep.h>

#define SLEEP_DURATION 60  // seconds

void setup() {
  Serial.begin(115200);

  // Read sensors
  float temperature = readTemperature();

  // Send data
  sendDataToCloud(temperature);

  // Enter deep sleep
  Serial.println("Entering deep sleep...");
  esp_sleep_enable_timer_wakeup(SLEEP_DURATION * 1000000ULL);  // microseconds
  esp_deep_sleep_start();
}

void loop() {
  // Not used - device resets after deep sleep
}
Timing diagram showing duty cycling pattern for low-power sensor operation with active periods (150mA, 5 seconds) alternating with sleep periods (10uA, 15 minutes), demonstrating 99.4% sleep time ratio reducing average power consumption from 150mA to 0.84mA
Figure 6.1: Duty cycling for low-power sensor operation
Interactive Duty Cycle Calculator
Power consumption profile during wireless transmission showing distinct phases: sleep mode (10uA), wake and sensor read (30-50mA), radio initialization and connection (80-170mA), data transmission (150-170mA), and return to sleep (10uA), illustrating why wireless TX dominates the power budget of battery-powered sensor nodes
Figure 6.2: Wireless transmission power management

6.5 Power Budget Calculation

20 min | Advanced | P06.C09.U03c

Understanding power budgets is essential for designing battery-powered sensor nodes. Let us calculate the battery life for a typical environmental monitoring node.

6.5.1 Example: Weather Station Power Analysis

System Configuration:

  • ESP32 with BME280 sensor
  • Wi-Fi transmission every 15 minutes
  • 2000 mAh battery

Current Consumption:

State Current Duration per Cycle
Sensor Read 30 mA 3 seconds
Wi-Fi Connect + TX 170 mA 2 seconds
Deep Sleep 10 uA 895 seconds

Calculation:

Sensor Read Energy:
  30mA × (3/3600)h = 0.025 mAh per cycle

Wi-Fi TX Energy:
  170mA × (2/3600)h = 0.094 mAh per cycle

Sleep Period Energy:
  0.01mA × (895/3600)h = 0.0025 mAh per cycle

Total per 15-minute cycle: 0.12 mAh

Cycles per day: 96

Daily consumption: 96 × 0.12 = 11.5 mAh/day
  (plus ~0.24 mAh/day sleep = 11.7 mAh/day total)

Battery life: 2000mAh / 11.7 mAh/day ≈ 171 days
Interactive Power Budget Calculator

6.5.2 Optimization Strategy: Transmission Buffering

The biggest power consumer is Wi-Fi/LoRa transmission. Buffering multiple readings before transmitting dramatically reduces power consumption.

Using the detailed breakdown from our example: - Sensor reading: 30 mA for 3 seconds = 0.025 mAh - Wi-Fi transmission: 170 mA for 2 seconds = 0.094 mAh

Original approach: 96 transmissions/day (one per 15-minute reading)

Buffered approach (transmit every 2 hours): 12 transmissions/day (8 readings per transmission)

#include <esp_sleep.h>

#define READINGS_PER_TX 8

// RTC memory survives deep sleep (normal RAM is lost on wake)
RTC_DATA_ATTR float tempBuffer[READINGS_PER_TX];
RTC_DATA_ATTR int bufferIndex = 0;

void setup() {
    // Read sensor (fast, low power)
    tempBuffer[bufferIndex++] = bmp.readTemperature();

    if (bufferIndex >= READINGS_PER_TX) {
        // Transmit all buffered readings
        connectWiFi();
        sendAllReadings(tempBuffer, READINGS_PER_TX);
        disconnectWiFi();
        bufferIndex = 0;
    }

    // Configure wake source and enter deep sleep
    esp_sleep_enable_timer_wakeup(15 * 60 * 1000000ULL);  // 15 minutes
    esp_deep_sleep_start();
}

void loop() {
    // Not used - device resets after deep sleep
}
Interactive Transmission Buffering Calculator

Using the detailed breakdown: sensor reading (30 mA, 3s) and Wi-Fi transmission (170 mA, 2s) are separate operations.

Original approach (96 transmissions/day):

  • Sensor reads: \(96 \times 30\text{mA} \times \frac{3}{3600}\text{h} = 2.4\) mAh/day
  • Wi-Fi TX: \(96 \times 170\text{mA} \times \frac{2}{3600}\text{h} = 9.0\) mAh/day
  • Sleep: \(\approx 0.24\) mAh/day
  • Total: 11.6 mAh/day → Battery life: \(\frac{2000}{11.6} = 172\) days

Buffered approach (12 transmissions/day, 8 readings per transmission):

  • Sensor reads: \(96 \times 30\text{mA} \times \frac{3}{3600}\text{h} = 2.4\) mAh/day (unchanged)
  • Wi-Fi TX: \(12 \times 170\text{mA} \times \frac{2}{3600}\text{h} = 1.1\) mAh/day
  • Sleep: \(\approx 0.24\) mAh/day
  • Total: 3.7 mAh/day → Battery life: \(\frac{2000}{3.7} = 541\) days

Result: Wi-Fi energy drops from 9.0 to 1.1 mAh/day (87.5% reduction), extending battery life by 3.1× (172 → 541 days). Transmission buffering is the single most effective optimization.

6.5.3 Power Optimization Hierarchy

Bar chart showing power consumption hierarchy for ESP32 at 3.3V: Wi-Fi TX at 561mW (170mA) dominates, followed by CPU active at 396mW (120mA), sensor read at 99mW (30mA), light sleep at 2.6mW (0.8mA), and deep sleep at 0.033mW (0.01mA)
Figure 6.3: Power Optimization Hierarchy: Wi-Fi Transmission Dominates Power Budget
Try It: ESP32 Power Mode Explorer

6.6 Sensor Fusion Tradeoffs

15 min | Advanced | P06.C09.U03d

Minimum Viable Understanding: Sensor Fusion

Core Concept: Sensor fusion combines data from multiple sensors (e.g., accelerometer + gyroscope + magnetometer) using algorithms like complementary filters or Kalman filters to produce more accurate and reliable measurements than any single sensor alone.

Why It Matters: Individual sensors have inherent limitations – accelerometers drift over time, gyroscopes accumulate integration errors, and magnetometers are affected by nearby metals – but fusing their outputs compensates for each sensor’s weaknesses while amplifying their strengths.

Key Takeaway: Start with a simple complementary filter (weighted average of fast and slow sensors) for orientation sensing – it requires only 5 lines of code and achieves 80% of Kalman filter accuracy without the computational complexity or tuning challenges.

Tradeoff: Complementary Filter vs Kalman Filter for Sensor Fusion

Option A: Complementary Filter - Simple weighted combination using high-pass filter on one sensor and low-pass filter on another (e.g., gyroscope + accelerometer for orientation)

Option B: Kalman Filter - Statistically optimal recursive estimator that models system dynamics, measurement noise, and process noise for state estimation

Decision Factors:

Factor Complementary Filter Kalman Filter
Computational load Very low (few multiplies) High (matrix operations)
Memory footprint ~20 bytes 200-2000 bytes
Tuning complexity 1-2 parameters 5-20+ parameters
Accuracy Good (80-90% of optimal) Optimal (by definition)
Sensor modeling Assumes fixed noise Adapts to varying conditions
Latency Minimal Slight (prediction step)
Implementation time Hours Days to weeks

Choose Complementary Filter when: Constrained MCU (8-bit AVR, small ARM Cortex-M0); battery life critical; quick prototyping; simple sensor fusion (2-3 sensors); accuracy requirements modest.

Choose Kalman Filter when: Accuracy is paramount; sensors have varying reliability over time; need state prediction between measurements; tracking moving targets; fusion of many sensors (5+); adequate computational resources available.

Practical guideline: Start with complementary filter for proof-of-concept. If accuracy is insufficient, upgrade to Kalman.

Tradeoff: Smart Sensors vs Raw Sensors with External Processing

Option A: Smart Sensors - Sensors with on-chip intelligence including calibration, digital output, threshold detection, and sometimes embedded ML (e.g., BNO055 with on-chip sensor fusion, MAX30102 with SpO2 algorithm)

Option B: Raw Sensors + External MCU - Basic analog/digital sensors where all processing, calibration, and fusion happens in your microcontroller (e.g., MPU6050 raw mode + custom fusion code)

Decision Factors:

Factor Smart Sensors Raw Sensors + MCU
Host MCU load Minimal (data ready) High (continuous processing)
Algorithm control Vendor black-box Full transparency
Calibration Factory-set Custom per-unit possible
Latency Fixed (sensor-determined) Configurable
Cost per unit Higher ($5-$30) Lower ($1-$10)
Power (total system) Often lower Often higher
Debugging visibility Limited Full access
Algorithm updates Firmware upgrade (rare) OTA software update

Choose Smart Sensors when: Rapid development required; limited MCU resources; vendor algorithm is proven for your use case; consistent behavior across units needed.

Choose Raw Sensors when: Custom algorithms required (proprietary IP, research); maximum flexibility for parameter tuning; need visibility into intermediate values; cost-optimized high-volume production.

Try It: Complementary Filter Tuning

6.7 Common Power Pitfalls

Pitfall: Entering Deep Sleep Without Configuring Wake Sources First

The Mistake: Calling deep sleep functions (ESP32’s esp_deep_sleep_start(), STM32’s HAL_PWR_EnterSTOPMode(), nRF52’s sd_power_system_off()) without configuring a valid wake source, causing the device to sleep forever and require manual reset or power cycle to recover.

Why It Happens: Deep sleep disables most peripherals and CPU activity to achieve microamp-level current consumption. Unlike light sleep, there is no automatic wake on timer expiration unless explicitly configured. Developers test with short delays during development, then remove the delay for “production” without adding proper wake sources, bricking the device.

The Fix: Always configure at least one wake source BEFORE entering deep sleep:

// WRONG: Entering deep sleep with no wake source (ESP32)
esp_deep_sleep_start();  // Device sleeps forever! Requires power cycle.

// CORRECT: Configure timer wake source (10 seconds)
esp_sleep_enable_timer_wakeup(10 * 1000000);  // 10 seconds in microseconds
esp_deep_sleep_start();

// CORRECT: Configure external interrupt wake (GPIO 33, active LOW)
esp_sleep_enable_ext0_wakeup(GPIO_NUM_33, 0);  // Wake when GPIO33 goes LOW
esp_deep_sleep_start();

// CORRECT: Multiple wake sources (timer OR button)
esp_sleep_enable_timer_wakeup(60 * 1000000);  // 60-second timeout
esp_sleep_enable_ext0_wakeup(GPIO_NUM_0, 0);  // Boot button wake
esp_deep_sleep_start();

Recovery Strategy: During development, always include a “fail-safe” wake source like a 5-minute timer even if primary wake is external interrupt.

Pitfall: Reading I2C/SPI Sensor Registers Before Conversion Complete

The Mistake: Reading sensor data registers immediately after triggering a measurement, before the sensor’s internal ADC has completed conversion, resulting in stale data from the previous measurement or invalid values.

Why It Happens: Sensors like the BMP280 (temperature/pressure), ADS1115 (precision ADC), and HX711 (load cell) have multi-millisecond conversion times. The datasheet specifies conversion time, but example code often uses fixed delays or omits waiting entirely. At 400kHz I2C, you can read registers in ~50us, but BMP280 needs 44ms in ultra-high-resolution mode.

The Fix: Check the sensor’s data-ready signal or wait for the specified conversion time:

// WRONG: Reading BMP280 immediately after trigger (44ms conversion!)
bmp.takeForcedMeasurement();
float temp = bmp.readTemperature();  // Returns PREVIOUS measurement!

// CORRECT: Wait for conversion time (check datasheet)
bmp.takeForcedMeasurement();
delay(44);  // Ultra-high resolution mode: 44ms
float temp = bmp.readTemperature();

// BETTER: Poll status register for data-ready flag
bmp.takeForcedMeasurement();
while ((bmp.getStatus() & 0x08) == 0) {  // Bit 3 = "measuring"; 0 = conversion done
    delayMicroseconds(100);  // Poll every 100us
}
float temp = bmp.readTemperature();

Conversion Times to Know: BMP280 standard: 8ms, ultra-high: 44ms. ADS1115 at 8 SPS: 125ms, at 860 SPS: 1.2ms. HX711 at 10 Hz: 100ms.

6.8 Knowledge Check

Knowledge Check: Power Management Test Your Understanding

Question 1: A battery-powered environmental monitoring node uses an ESP32 with BME280 sensor, transmitting readings every 15 minutes via Wi-Fi. Current consumption is: sensor read 30mA (3 seconds), Wi-Fi TX 170mA (2 seconds), deep sleep 10uA. Using a 2000mAh battery, approximately how long will the node operate?

Click to see answer

Answer: Approximately 170 days (5.7 months)

Calculation:

  • Sensor Read Energy: 30mA x (3/3600)h = 0.025 mAh per cycle
  • Wi-Fi TX Energy: 170mA x (2/3600)h = 0.094 mAh per cycle
  • Sleep Period Energy: 0.01mA x (895/3600)h = 0.0025 mAh per cycle
  • Total per 15-minute cycle: 0.12 mAh
  • Cycles per day: 96
  • Daily consumption: 96 x 0.12 + 0.24 (sleep) = 11.7 mAh/day
  • Battery life: 2000mAh / 11.7 mAh/day = 171 days

Question 2: What is the most effective way to extend battery life by 3x or more for the node described above?

Click to see answer

Answer: Reduce Wi-Fi transmissions by buffering multiple readings

Wi-Fi transmission dominates the power budget (80%+ of energy). By buffering 8 readings and transmitting every 2 hours instead of every 15 minutes: - Wi-Fi transmissions drop from 96 to 12 per day (87.5% reduction) - Daily energy drops from 11.7 to 3.7 mAh (sensor: 2.4, TX: 1.1, sleep: 0.24) - Battery life extends from 171 days to 541 days (3.1x improvement)

Other options (ESP8266, larger battery, reduced sampling) provide smaller improvements.

Question 3: Why must you configure a wake source BEFORE calling esp_deep_sleep_start()?

Click to see answer

Answer: Without a configured wake source, the device sleeps forever and cannot recover without a manual power cycle.

Deep sleep disables the CPU and most peripherals. There is no automatic timeout - the device will remain in sleep mode indefinitely (consuming ~10uA) until a wake event occurs. If no wake source is configured, no wake event can ever occur, and the device is effectively bricked until physically reset.

Always configure at least one wake source (timer, GPIO interrupt, touchpad, or ULP coprocessor) before entering deep sleep.
Key Takeaway

The power management hierarchy for battery-powered sensor nodes is: (1) minimize transmissions first (buffering yields 3x+ improvement), (2) use deep sleep between readings (reduces idle current 10,000x from mA to uA), (3) then optimize active-period current (sensor selection, clock speed). Tackling these in wrong order – such as choosing a lower-power MCU before reducing transmission count – delivers marginal gains while ignoring the dominant power consumer.

Bella the Battery had a big problem. “I only have so much energy,” she said. “If everyone keeps talking all the time, I will run out in just a few months!”

Sammy the Sensor felt bad. “But I need to measure the temperature!” Max the Microcontroller had an idea: “What if Sammy takes his readings, but instead of shouting them to the cloud every single time, we save them up and send a big batch all at once?”

“Like saving up your drawings and mailing them all in one envelope instead of 8 separate letters!” Sammy the Sensor suggested.

“Exactly!” said Max. “The Wi-Fi radio uses the MOST energy – way more than Sammy reading the temperature. By sending one big message instead of eight small ones, Bella lasts THREE TIMES longer!”

Bella was relieved. “And between readings, everyone goes to DEEP SLEEP. That means I only use 10 microamps – that is like a tiny trickle instead of a fire hose!”

“But ALWAYS set an alarm before sleeping,” Max warned. “If you sleep without an alarm, you sleep FOREVER and someone has to unplug you and plug you back in!”

Scenario: You are deploying 50 environmental sensors across a 5 km² agricultural area. Each sensor reads temperature and soil moisture every 15 minutes. Should you use Wi-Fi or LoRaWAN?

System Specifications:

  • ESP32 microcontroller
  • BME280 temperature/humidity sensor
  • Capacitive soil moisture sensor
  • 3.7V 2000 mAh Li-ion battery
  • Sensor reading interval: 15 minutes (96 readings/day)

Option A: Wi-Fi Connectivity (same analysis as the Power Budget Calculation section)

State Current (mA) Duration per Cycle Energy (mAh)
Deep Sleep 0.01 14 min 55 sec (895 sec) 0.0025
Sensor Read 30 3 sec 0.025
Wi-Fi Connect + TX 170 2 sec 0.094
Total per cycle 15 min 0.12 mAh

Daily consumption: 96 cycles × 0.12 mAh + 0.24 (sleep) = 11.7 mAh/day

Battery life: 2000 mAh / 11.7 mAh/day = 171 days (5.7 months)

Option B: LoRaWAN Connectivity

Note: At +14 to +20 dBm TX power (required for the 5-15 km range in this scenario), LoRaWAN modules such as the SX1276 draw 100-130 mA. We use 120 mA as a realistic value for long-range agricultural deployments.

State Current (mA) Duration per Cycle Energy (mAh)
Deep Sleep 0.01 14 min 55 sec (895 sec) 0.0025
Sensor Read 30 3 sec 0.025
LoRaWAN TX (+17 dBm) 120 2 sec 0.067
Total per cycle 15 min 0.094 mAh

Daily consumption: 96 cycles × 0.094 mAh + 0.24 (sleep) = 9.3 mAh/day

Battery life: 2000 mAh / 9.3 mAh/day = 215 days (7.1 months)

Comparison Table:

Metric Wi-Fi LoRaWAN Winner
Battery Life 171 days 215 days LoRaWAN (1.3× longer)
TX Current 170 mA 120 mA LoRaWAN (1.4× lower)
Range 50-100m 5-15 km LoRaWAN (100× longer)
Infrastructure Wi-Fi AP every 50m 1 gateway for entire 5 km² LoRaWAN (simpler)
Cost per Node $5 (ESP32 only) $13 (ESP32 + LoRa module) Wi-Fi (cheaper)
Total Infrastructure Cost 50× Wi-Fi APs @ $30 = $1,500 1× LoRaWAN gateway @ $200 = $200 LoRaWAN (much cheaper)

Decision: LoRaWAN wins for agricultural deployment due to: - 1.3× longer battery life (215 vs 171 days) with realistic TX power for 5+ km range - 100× longer range (15 km vs 100m) – covers entire 5 km2 farm with ONE gateway - $1,300 lower infrastructure cost ($200 vs $1,500) - Lower maintenance (fewer battery changes per year)

Note: At low TX power (+7 dBm, ~40 mA), LoRaWAN battery life extends to 400+ days, but range drops to 1-2 km. The advantage grows further with transmission buffering, since LoRaWAN’s lower per-TX energy cost compounds the savings.

When Wi-Fi Makes Sense:

  • Indoor deployment with existing Wi-Fi infrastructure (no gateway cost)
  • High data rate needs (>10 KB/transmission) – LoRaWAN limited to 242 bytes
  • Real-time applications (<1 second latency) – LoRaWAN has 1-5 second latency
  • Short range (<100m) with frequent communication (every minute)

Key Insight: For battery-powered outdoor IoT with infrequent small-payload transmissions, LoRaWAN’s lower TX current and vastly longer range make it the clear winner. Wi-Fi’s higher power consumption (170 mA) dominates the energy budget, and the infrastructure savings alone often justify LoRaWAN even before considering battery life.

6.8.1 Interactive: Wi-Fi vs LoRaWAN Battery Life

6.9 Summary

This chapter covered power management strategies for sensor networks:

  • Multi-Sensor Aggregation: Structured data collection with JSON payloads
  • Deep Sleep Modes: Reduce consumption from milliamps to microamps
  • Power Budget Calculations: Estimate battery life for design decisions
  • Transmission Buffering: Reduce Wi-Fi/LoRa usage by 80%+ for 3x battery life
  • Sensor Fusion Tradeoffs: Complementary vs Kalman filters, smart vs raw sensors
  • Wake Source Configuration: Critical for deep sleep recovery

The ESP32 offers multiple wake sources for deep sleep mode (see also Common Power Pitfalls for what happens when you forget to configure one):

  1. Timer wake – esp_sleep_enable_timer_wakeup(microseconds) – Most common for periodic sensing
  2. GPIO wake (EXT0) – Wake on single RTC GPIO pin state change (e.g., button press, PIR sensor)
  3. GPIO wake (EXT1) – Wake when multiple RTC GPIOs match condition (AND/OR logic)
  4. Touchpad wake – Wake on capacitive touch sensor activity (ESP32 has 10 touch-capable pins)
  5. ULP coprocessor – Ultra-low-power coprocessor can monitor sensors and wake main CPU only when thresholds are exceeded

ESP32 power mode comparison:

Mode Current What Stays On
Active (CPU + Wi-Fi) 160-240 mA Everything
Modem sleep 20-40 mA CPU active, Wi-Fi wakes at DTIM intervals
Light sleep 0.8 mA typical CPU paused, Wi-Fi suspended, RAM retained
Deep sleep 10-150 uA RTC controller + RTC memory only
Hibernation 2.5-5 uA RTC timer only (no RTC memory)

Goal: Make ESP32 read a sensor, send data, then sleep for 10 minutes.

Code structure:

#include <esp_sleep.h>

void setup() {
    // Read sensor
    float temp = readTemperature();

    // Send data (Wi-Fi or LoRa)
    sendDataToCloud(temp);

    // Configure wake timer
    esp_sleep_enable_timer_wakeup(10 * 60 * 1000000ULL); // 10 minutes in µs

    // Enter deep sleep
    esp_deep_sleep_start();
}
void loop() { /* Never runs */ }

Expected result: Current drops from 80mA active to 10µA sleep

Goal: Combine GPS + accelerometer + barometer, but only wake GPS when movement detected.

Strategy:

  • Accelerometer runs continuously (low power)
  • GPS off unless accelerometer detects motion
  • Barometer updates every minute
  • Transmit fused data every 5 minutes

Power savings: GPS uses 40-60mA. Only running when moving saves 80%+ energy.

Goal: Sample faster when sensor values change rapidly, slower when stable.

Algorithm:

  1. Calculate rolling standard deviation of last 10 readings
  2. If stddev > threshold: sample every 10s
  3. If stddev < threshold: sample every 60s
  4. Transmit only when value changes by >5%

Challenge: Implement this for temperature sensor with automatic adaptation

Try It: Adaptive Sampling Power Savings

6.10 Concept Relationships

Core Concept Related Concepts Why It Matters
Deep Sleep Wake Sources, RTC, ULP Coprocessor Reduces current from mA to µA range
Transmission Buffering Data Aggregation, Batch Updates Wi-Fi/LoRa dominates power budget
Duty Cycling Active %, Sleep Time, Average Power Extends battery life proportionally
Sensor Fusion Complementary Filter, Kalman Filter Combines multiple sensors for accuracy
Match: Power Management Concepts

Order: Steps to Implement a Low-Power Sensing Cycle

Common Pitfalls

Wireless transmission (Wi-Fi, LoRa, BLE advertising) is often 10–1000x more power-hungry than the microcontroller. Profile transmit current separately and minimize transmission frequency and payload size.

Voltage regulators, pull-up resistors, and always-on LEDs all draw continuous current. Switch off peripherals using power gating transistors and remove unnecessary pull-ups on unused pins.

Some sensors require a warm-up or stabilisation period after power-on before they produce accurate readings. Factor this into duty-cycle calculations or keep critical sensors powered continuously.

Battery voltage drops nonlinearly with state-of-charge and temperature. Lithium cells lose capacity at low temperatures; alkaline cells have a steeper voltage drop curve. Test your system at expected operating temperature extremes.

6.11 What’s Next

If you want to… Read this
Understand sensor calibration to maintain accuracy over time Sensor Calibration
Learn signal processing to reduce unnecessary wakeups Signal Processing for IoT Sensors
Explore edge computing to offload processing from constrained nodes Edge and Fog Computing
Survey wireless protocols and their power profiles Wireless Sensor Networks

The next chapter covers Sensor Applications, including smart home environmental monitoring, automated blinds control, and temperature-controlled relay systems with practical implementation examples.