24 Low-Power Sensors: Energy Budgets

24.1 Start With the Decision

A battery sensor can meet its average current target and still die during radio bursts. Its energy budget must include every state and transition.

24.2 Route Overview

This is part 1 of 3. Continue with Low-Power Sensors: Duty Cycles and Fusion.

24.3 Part Objectives

• Compute sensor lifetime from active, sleep, and radio energy.
• Identify peak-current and battery limits hidden by an average budget.

24.5 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

24.6 Introduction

A battery sensor budget combines the energy needed for measurements, communication, and the time between useful tasks. Buffered transmission reduces repeated radio work while preserving readings for the next upload. Sleep still contributes to the total even when its current is much lower than the active current. A useful lifetime claim therefore follows the complete operating schedule rather than quoting a low-current mode by itself.

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.

The mathematical gist. Charge used in one state is current times time, $\Delta Q_{mAh}=I_{mA}\Delta t_s/3600$. This chapter’s 96 daily sensor reads cost 2.40 mAh, 12 buffered Wi-Fi bursts cost 1.13 mAh, and sleep costs about 0.239 mAh, giving 3.77 mAh/day and about 530 days from 2,000 mAh—roughly 3.1 times the unbuffered lifetime before real-cell derating.

Math Bridge · guided foundationsWhere do 530 days of battery life come from?Let Phoebe turn current and seconds into the weather node's daily charge ledger. Learn the maths

24.7 Multi-Sensor Data Aggregation

A node with several sensors needs a payload that preserves the meaning of their combined readings. JSON provides a readable structure for those values, but each transmitted byte still costs work on the radio path. The design question includes how many values are sent and how often the node communicates. One combined transmission can replace separate transfers while keeping the sensor readings organized for the receiver.

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.

Focus first on the payload design question: how many sensor values must be transmitted, how often, and how expensive is each byte over the chosen radio link? Use the estimator below before writing firmware.

#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;
}

#include <ArduinoJson.h>

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

24.8 Low-Power Sensor Reading

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
}

The code gives the control sequence; Figure 24.1 shows its timing consequence. Read one complete cycle from wake-up through sensor work and transmission to the long sleep interval, comparing widths as elapsed time rather than assuming the blocks consume equal energy.

In Figure 24.1, the active window contains the useful measurement and communication work, while sleep occupies most of the schedule. Average current depends on both current level and duration, so shortening an expensive radio burst can matter more than shaving a small amount from sleep current. This timing view is the bridge from firmware states to the duty-cycle calculator’s weighted average.

The duty-cycle diagram is qualitative. Use Figure 24.2 to inspect the current shape of a concrete five-minute sensor cycle: follow the baseline sleep current, the sensing and processing steps, the radio peak, and the return to sleep in time order.

In Figure 24.2, deep sleep is long and low, the sensor and processor occupy shorter intermediate regions, and Wi-Fi transmission produces the highest peak. The area under each region—not peak height by itself—contributes charge per cycle. That observation reconnects the physical current trace to the chapter’s batching result: fewer transmissions reduce how often the costliest state appears.

24.9 Continue to the Next Part

Carry this evidence into Low-Power Sensors: Duty Cycles and Fusion, which begins with Checkpoint: Duty Cycle Is Average Current.