35  Connected Devices - Power Management

35.1 Learning Objectives

After completing this chapter, you will be able to:

  • Apply power budget analysis to IoT device design
  • Implement effective power mode strategies for battery-operated devices
  • Calculate expected battery life based on duty cycle and component consumption
  • Select appropriate power sources for different deployment scenarios
  • Optimize firmware for minimal power consumption

Power management determines how long your IoT device runs before the battery dies or needs recharging. Think of it like budgeting your phone battery through the day – if you keep the screen on maximum brightness, stream video, and leave GPS running, it dies by lunch. But if you turn off what you do not need and let the phone sleep between uses, it lasts until bedtime.

IoT devices face the same challenge, but much more extreme. A soil sensor in a farm field cannot be recharged every night. It needs to run for months or years on a single battery. The secret is duty cycling – spending 99.9% of the time in deep sleep (using almost no power) and waking up briefly to measure and transmit. The difference between good and bad power design can be 3 months versus 5 years of battery life from the same hardware.

“Okay team, we have a problem,” announced Bella the Battery. “I only have 1,000 milliamp-hours of energy. That is like having 1,000 coins to spend. How do we make me last a whole year?” The team huddled up to make a power budget.

Sammy the Sensor said, “I need 5 coins every time I take a temperature reading. If I measure every second, that is 5 coins times 86,400 seconds in a day – I would use up all 1,000 coins in no time!” Max the Microcontroller had an idea. “What if you only measure once every 10 minutes? That is 144 readings per day instead of 86,400. Way fewer coins!”

“And I will only blink for one second when there is new data, instead of staying lit all the time,” added Lila the LED. “That saves hundreds of coins!” Bella smiled, “See? Power management is like budgeting your allowance. You figure out what costs the most, then find clever ways to spend less. Sleep when you can, wake up only when needed, and never waste energy on things nobody notices!”

35.2 Prerequisites

Before diving into this chapter, you should be familiar with:

Key Concepts

  • IoT Device Architecture: Hardware stack comprising microcontroller, sensors, connectivity module, power supply, and optional display or actuator.
  • Design Triangle: Trade-off between size, battery life, and capability that constrains every IoT device design decision.
  • Power Budget: Maximum average current consumption a device can draw while meeting its battery life target.
  • Form Factor: Physical size, shape, and mounting method of a device determined by its deployment environment and user interaction model.
  • Ingress Protection (IP) Rating: IEC 60529 code specifying a device’s resistance to dust and water ingress, required for outdoor and industrial deployments.
  • Bill of Materials (BOM): Itemised list of every component in a device with part numbers, quantities, and costs used for procurement and cost estimation.
  • Certification: Regulatory approval (FCC, CE, UL) required before a wireless IoT device can be sold in a given market.

35.3 Introduction

Power is often the most critical constraint for IoT devices. A sensor that needs monthly battery changes will fail in the market, while one that lasts 5 years on a coin cell battery enables new deployment scenarios. This chapter covers power budget analysis, power mode implementation, and the techniques that determine whether your IoT device achieves its battery life goals.

35.4 Power Budget Analysis

Understanding where power goes is the first step to optimizing it.

35.4.1 Power Budget Components

Pie chart showing power budget breakdown: Radio TX/RX 45%, MCU Active 25%, Sensors 15%, Sleep Current 10%, Peripherals 5%
Figure 35.1: Power budget breakdown for a typical battery-powered IoT sensor

Power modes and typical consumption:

Mode Description Typical Current
Active Mode MCU running, radio transmitting, sensors sampling 50-200mA
Sleep Mode MCU in low-power state, peripherals off 1-10mA
Deep Sleep Only RTC running, wake on timer or interrupt 10-100µA

Radio power comparison:

Protocol Typical TX Current Typical RX Current Notes
Wi-Fi 200-350mA 100-150mA Highest power, fastest data
Cellular (LTE-M) 100-500mA 50-100mA Wide area, high power
BLE 10-20mA 10-15mA Short range, low power
LoRa 20-120mA 10-15mA Long range, variable TX power
Zigbee 15-30mA 15-25mA Mesh capable

35.4.2 Battery Life Calculation

Basic formula:

Battery Life (hours) = Battery Capacity (mAh) / Average Current Draw (mA)

For duty-cycled devices (most IoT sensors):

Average Current = (Active_mA × Active_Time%) + (Sleep_mA × Sleep_Time%)

35.4.3 Interactive Battery Life Calculator

Adjust the parameters below to see how duty cycle affects battery life:

Example calculation:

A temperature sensor with: - 3000mAh battery - Active 1 second/hour drawing 50mA - Deep sleep drawing 50µA

Calculation: - Active time: 1s / 3600s = 0.028% - Sleep time: 99.972% - Average current: (50 × 0.00028) + (0.05 × 0.99972) = 0.014 + 0.050 = 0.064mA - Battery life: 3000 / 0.064 = 46,875 hours = 5.35 years

Battery lifetime for duty-cycled IoT devices follows a power-weighted average model. For a device with \(n\) operational modes, each mode \(i\) with current draw \(I_i\) (mA) and duty cycle \(D_i\) (fraction of time, \(\sum D_i = 1\)), average current is:

\[I_{\text{avg}} = \sum_{i=1}^{n} I_i \cdot D_i\]

Battery life in hours: \[t_{\text{life}} = \frac{C_{\text{battery}}}{I_{\text{avg}}} \cdot \alpha\]

where \(C_{\text{battery}}\) is nominal capacity (mAh) and \(\alpha \approx 0.85\) accounts for self-discharge and temperature derating.

For the temperature sensor example with three modes (TX, sense, sleep): - \(I_{\text{TX}} = 200\text{mA}\), \(D_{\text{TX}} = 0.1\text{s} / 3600\text{s} = 2.78 \times 10^{-5}\) - \(I_{\text{sense}} = 5\text{mA}\), \(D_{\text{sense}} = 0.9\text{s} / 3600\text{s} = 2.5 \times 10^{-4}\) - \(I_{\text{sleep}} = 0.05\text{mA}\), \(D_{\text{sleep}} = 3599\text{s} / 3600\text{s} = 0.99972\)

\[I_{\text{avg}} = 200(2.78 \times 10^{-5}) + 5(2.5 \times 10^{-4}) + 0.05(0.99972) = 0.0056 + 0.00125 + 0.05 = 0.0569\text{mA}\]

\[t_{\text{life}} = \frac{3000}{0.0569} \times 0.85 = 44,\!800\text{ hours} = 5.1\text{ years}\]

The sleep current dominates: 88% of power consumption is from sleep mode despite it being “low power”. Reducing \(I_{\text{sleep}}\) from 50µA to 2µA (STM32L series) extends life to 18.7 years.

Sleep Current Dominates Battery Life

For duty-cycled devices that sleep 99%+ of the time, sleep current is the primary battery drain, not active current. A device with 50µA sleep current drains 2.6x faster than one with 20µA sleep, even if active power is identical.

Modern MCU deep sleep targets:

  • STM32L series: 0.3-2µA
  • nRF52 series: 0.4-3µA
  • ESP32: 5-150µA (varies by wake source)

35.5 Device Taxonomy by Power

IoT device taxonomy showing two main classification axes: Environment (on-body, indoor, outdoor, industrial, mobile) with their respective constraints, and Constraint Level (tiny sensors, battery devices, mains powered, gateways) with their power and capability profiles
Figure 35.2: IoT Device Taxonomy: Environment Types and Power Constraint Levels
Three-column flow diagram mapping environments to design decisions: On-Body leads to BLE and coin cell power; Indoor leads to Wi-Fi/Zigbee and AC/USB power; Outdoor leads to LoRaWAN/NB-IoT and solar/battery; Industrial leads to Industrial Ethernet and 24V DC; Mobile leads to LTE-M/Cellular and vehicle power
Figure 35.3: Environment-to-Design Matrix: Mapping deployment environments through recommended connectivity options to appropriate power strategies

35.6 Power Mode Implementation

ESP32 power mode implementation example:

#include <esp_sleep.h>
#include <esp_wifi.h>
#include <driver/adc.h>

// Power mode configuration
const int MEASUREMENT_INTERVAL_SEC = 300;  // 5 minutes
const int WIFI_TIMEOUT_SEC = 30;

// RTC memory persists across deep sleep
RTC_DATA_ATTR int bootCount = 0;
RTC_DATA_ATTR float lastTemperature = 0;

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

  // Increment boot counter
  bootCount++;

  // Determine wake-up reason
  esp_sleep_wakeup_cause_t wakeup_reason = esp_sleep_get_wakeup_cause();

  Serial.printf("Boot #%d, Wakeup reason: %d\n", bootCount, wakeup_reason);

  // Perform measurements
  float temperature = readTemperature();
  float humidity = readHumidity();
  float batteryVoltage = readBatteryVoltage();

  Serial.printf("T: %.1f°C, H: %.1f%%, Batt: %.2fV\n",
                temperature, humidity, batteryVoltage);

  // Only connect to Wi-Fi and send data if significant change
  // or every Nth measurement (to confirm device is alive)
  bool significantChange = abs(temperature - lastTemperature) > 2.0;
  bool periodicReport = (bootCount % 12) == 0;  // Every hour if 5-min intervals

  if (significantChange || periodicReport || batteryVoltage < 3.3) {
    // Connect to Wi-Fi
    if (connectWiFiWithTimeout(WIFI_TIMEOUT_SEC)) {
      // Send data
      sendDataToCloud(temperature, humidity, batteryVoltage);

      // Disconnect Wi-Fi
      WiFi.disconnect(true);
      WiFi.mode(WIFI_OFF);
    }
  }

  lastTemperature = temperature;

  // Configure wake-up
  esp_sleep_enable_timer_wakeup(MEASUREMENT_INTERVAL_SEC * 1000000ULL);

  // Optional: wake on external trigger (e.g., button press)
  // esp_sleep_enable_ext0_wakeup(GPIO_NUM_33, 0);  // Wake on LOW

  Serial.println("Entering deep sleep...");
  Serial.flush();

  // Enter deep sleep
  esp_deep_sleep_start();
}

void loop() {
  // Never reached - device resets on wake from deep sleep
}

float readTemperature() {
  // Read from sensor (e.g., BME280)
  // In deep sleep mode, minimize sensor warm-up time
  return 23.5;  // Placeholder
}

float readHumidity() {
  return 55.0;  // Placeholder
}

float readBatteryVoltage() {
  // Read battery voltage through voltage divider
  // Configure ADC for low-power operation
  adc1_config_width(ADC_WIDTH_BIT_12);
  adc1_config_channel_atten(ADC1_CHANNEL_0, ADC_ATTEN_DB_11);

  int raw = adc1_get_raw(ADC1_CHANNEL_0);

  // Convert to voltage (assuming 2:1 voltage divider)
  // 12-bit ADC, 11dB attenuation allows up to ~3.3V input
  // With 2:1 divider, can measure up to ~6.6V
  float voltage = (raw / 4095.0) * 3.3 * 2.0;

  return voltage;
}

bool connectWiFiWithTimeout(int timeout_sec) {
  WiFi.mode(WIFI_STA);
  WiFi.begin("SSID", "PASSWORD");

  unsigned long start = millis();

  while (WiFi.status() != WL_CONNECTED) {
    if (millis() - start > timeout_sec * 1000) {
      Serial.println("Wi-Fi connection timeout");
      return false;
    }
    delay(100);
  }

  Serial.println("Wi-Fi connected");
  return true;
}

void sendDataToCloud(float temp, float humidity, float battery) {
  // Send via MQTT or HTTP
  // Use efficient payload format (binary or compressed JSON)
  Serial.println("Data sent to cloud");
}

35.6.1 Power Optimization Techniques

Three-column diagram showing power optimization strategies: Hardware (MCU selection, efficient regulators, power gating, low-power radio), Firmware (deep sleep, adaptive sampling, data aggregation, efficient protocols), and System Design (event-driven wake, local processing, predictive maintenance, energy harvesting), all leading to extended battery life
Figure 35.4: Power Optimization Strategies: Hardware, firmware, and system design approaches to extend battery life

35.7 UX Impact of Battery Life

Power management is not just an engineering concern – it directly shapes user experience. Poor battery life causes more product returns and negative reviews than almost any other factor.

35.7.1 Case Study: Ring Video Doorbell Battery Life

Ring’s first battery-powered doorbell (2014) promised “6-12 months of battery life.” Real-world experience told a different story:

Condition Advertised Actual Root Cause
Low motion 12 months 6-8 months Wi-Fi keep-alive drains in standby
High traffic 6 months 3-6 weeks Each motion event = 30s video @ 400mA
Cold weather Same 50% reduction LiPo capacity drops below 0C
Live view N/A Days Users checking camera drains battery fast

Ring’s UX solutions:

  1. Motion zones: Users define detection areas, reducing false triggers by 60-80%. Fewer motion events = less camera/radio time = longer battery.
  2. Motion sensitivity slider: “People only” mode uses PIR + software classification to ignore animals and cars. Reduced events from 50/day to 5-10/day.
  3. Battery health dashboard: Shows remaining charge, estimated days remaining, and “charge by” date. Reduces anxiety from “is it dead?” to predictable maintenance.
  4. Low battery UX sequence: At 20%, push notification. At 10%, simplified recording (no live view). At 5%, audio-only doorbell (preserves core function). At 0%, physical ding-dong chime still works.

Design principle: When battery life is limited, give users control over the power-vs-features tradeoff. Degrading gracefully (fewer features as battery drops) is better than failing suddenly.

35.7.2 The 10% Battery Warning Pattern

When battery drops below critical thresholds, the device UX must communicate urgency without causing panic:

Battery Level → UX Response:
100-30%:  Normal operation, battery icon in app
20-30%:   Yellow icon + "Charge within 2 weeks"
10-20%:   Push notification + reduced functionality
 5-10%:   Persistent banner + core functions only
  0-5%:   "Last message" before shutdown + schedule recharge

Why this matters: A study of 2,000 smart home users found that 34% abandoned devices that died unexpectedly, compared to only 8% who abandoned devices with clear battery management UX. Predictability builds trust.

35.8 Battery Technology Selection

35.8.1 Battery Chemistry Comparison

Chemistry Voltage Energy Density Self-Discharge Temp Range Best For
Lithium Coin (CR) 3.0V High Very low (1%/year) -20 to +70°C Long-life sensors
Lithium-ion 3.7V Very high Low (2-3%/month) 0 to +45°C Rechargeable wearables
LiFePO4 3.2V Medium Very low -20 to +60°C Cold weather, safety
Alkaline (AA/AAA) 1.5V Medium Medium (5%/year) -18 to +55°C Replaceable, low cost
NiMH 1.2V Medium High (20%/month) -20 to +50°C Rechargeable, eco-friendly

35.8.2 Cold Weather Considerations

Lithium Batteries Fail in Cold Weather

Lithium-ion/LiPo batteries suffer significant degradation below 0°C: - Capacity drops 20-40% at 0°C - Capacity drops 50%+ at -20°C - Internal resistance increases, causing voltage sag under load - May not charge below 0°C (permanent damage risk)

Cold weather solutions:

  1. Use LiFePO4 chemistry (better cold performance)
  2. Use primary lithium cells (non-rechargeable but cold-tolerant)
  3. Oversize battery capacity by 50% for cold deployment
  4. Thermally insulate battery compartment
  5. Pre-warm battery before high-current operations

35.9 Knowledge Check

Device: Outdoor temperature/humidity sensor (weather station) Target: 2-year battery life on 2× AA batteries (3,000 mAh total at 3.0V nominal)

Component Power Consumption (from datasheets): - MCU active (STM32L0): 8 mA @ 3.0V - MCU sleep (STM32L0): 1.8 µA @ 3.0V - Sensor (BME280): 340 µA during measurement, 0.1 µA sleep - LoRa TX @ +14 dBm: 28 mA for 100ms transmission - LoRa sleep: 1 µA

Operational Profile (measure every 10 minutes, transmit every hour): - Wake from sleep - MCU active: 500ms (sensor stabilization + reading) - Sensor measurement: 100ms - MCU processes data: 200ms - LoRa TX (every 6th wake): 100ms - Return to deep sleep

Calculation:

Per-hour cycle (6 wake events: 5 measure-only, 1 measure+transmit):

Measure-only wake (5× per hour): - MCU active: 0.7s × 8 mA / 3600s/h = 0.00156 mAh - Sensor: 0.1s × 0.34 mA / 3600s/h = 0.0000094 mAh - LoRa sleep: 3600s × 0.001 mA / 3600s/h = 0.001 mAh - Subtotal per wake: 0.00257 mAh × 5 = 0.01285 mAh

Measure+transmit wake (1× per hour): - MCU active: 0.7s × 8 mA / 3600s/h = 0.00156 mAh - Sensor: 0.1s × 0.34 mA / 3600s/h = 0.0000094 mAh - LoRa TX: 0.1s × 28 mA / 3600s/h = 0.000778 mAh - Subtotal: 0.00235 mAh

Sleep (majority of time): - MCU sleep: 3594s × 0.0018 mA / 3600s/h = 0.00179 mAh - Sensor sleep: 3594s × 0.0001 mA / 3600s/h = 0.0001 mAh - LoRa sleep (already counted above)

Total per hour:

  • Active wakes: 0.01285 + 0.00235 = 0.01520 mAh
  • Sleep: 0.00179 + 0.0001 = 0.00189 mAh
  • Total: 0.01709 mAh/hour

Battery Life:

  • Battery capacity: 3,000 mAh
  • Average consumption: 0.01709 mAh/hour
  • Life: 3,000 / 0.01709 = 175,541 hours = 20 years

Wait - that cannot be right. What did we miss?

Self-discharge:

  • Alkaline AA: 2-5% per year @ 25°C
  • At 3% per year: 3,000 mAh × 0.03 = 90 mAh lost per year

Temperature correction:

  • Cold weather capacity reduction: 30% at 0°C
  • Effective capacity in winter: 3,000 × 0.7 = 2,100 mAh

Revised Calculation:

  • Usable capacity: 2,100 mAh (winter derated)
  • Self-discharge: 90 mAh/year = 0.0103 mAh/hour
  • Active consumption: 0.01709 mAh/hour
  • Total: 0.0274 mAh/hour

Realistic Battery Life:

  • 2,100 mAh / 0.0274 mAh/hour = 76,642 hours = 8.75 years

But wait - we want 2 years (17,520 hours). We have 4× margin!

Optimization - Transmit more frequently (better user experience): - New plan: Transmit every 15 minutes (4× data rate) - LoRa TX: 4× per hour instead of 1× = +0.00233 mAh/hour - Total: 0.0274 + 0.00233 = 0.02973 mAh/hour - Life: 2,100 / 0.02973 = 70,635 hours = 8.1 years (still >2-year target)

Lesson: Power calculation revealed 20-year theoretical life → after self-discharge and temperature derating → 8.75-year realistic life → enabled 4× transmission frequency while exceeding 2-year target.

Power Comparison (for 50-byte payload transmission):

Protocol TX Power TX Current TX Duration Energy/TX Sleep Current Range
Wi-Fi +20 dBm 200-350 mA 500ms (connect + send) 175 mAh 15-20 mA (idle) 50-100m
LoRa +14 dBm 28 mA 100ms 2.8 mAh 1 µA 2-15 km
BLE +4 dBm 10-15 mA 50ms 0.75 mAh 1-3 µA 10-50m
Cellular (LTE-M) +23 dBm 200-500 mA 1-3s (connect + send) 500 mAh 5-10 mA (idle) 10+ km

Battery Life Comparison (3,000 mAh battery, 1 transmission/hour):

Protocol Energy/Hour Battery Life Best For
Wi-Fi 175 mAh TX + 15 mAh idle = 190 mAh/h 16 hours Mains-powered only
LoRa 2.8 mAh TX + 0.001 mAh sleep = 2.8 mAh/h 1,071 hours (45 days) Long-range sensors
BLE 0.75 mAh TX + 0.002 mAh sleep = 0.75 mAh/h 4,000 hours (167 days) Short-range beacons
Cellular 500 mAh TX + 10 mAh idle = 510 mAh/h 6 hours Vehicle-powered only

Selection Matrix:

Requirement Recommended Protocol Rationale
Long battery life (>1 year) LoRa or BLE Sleep current <3 µA
Wide area (>1 km range) LoRa or Cellular Wi-Fi/BLE too short
High data rate (>1 KB/min) Wi-Fi or Cellular LoRa limited to 50-250 bytes
Existing infrastructure Wi-Fi or BLE Reuse routers/phones
Budget (<$5 BOM for radio) BLE or LoRa Wi-Fi/Cellular more expensive
Real-time (<1s latency) Wi-Fi or BLE LoRa has air-time limits

Real-World Example - Smart Agriculture:

  • Use case: Soil moisture sensor in field, 2 km from farmhouse
  • Data: 20 bytes every 15 minutes
  • Wi-Fi: Would need repeaters every 100m = $500+ infrastructure cost
  • LoRa: Single gateway at farmhouse, 2km range, $40 gateway + $5/sensor radio = $45 total
  • Battery life: LoRa @ 4×/hour TX = 2.8 × 4 = 11.2 mAh/h → 3,000 / 11.2 = 268 hours (11 days) → Use solar panel ($8) for infinite life
  • Winner: LoRa + solar

Decision Rule:

  1. Mains power available → Wi-Fi (cheapest, fastest)
  2. Battery + short range (<50m) → BLE (lowest power)
  3. Battery + long range (>500m) → LoRa (long range + low power)
  4. Wide area + high data rate → Cellular (expensive but necessary)
Common Mistake: Ignoring Sleep Current in Power Budget

What practitioners do wrong: Calculating battery life based on active power consumption only:

Wrong calculation:
TX power: 100 mA for 0.5 seconds every hour
Battery: 2,000 mAh
Life: 2,000 mAh / (100 mA × 0.5s / 3600s) = 144,000 hours (16 years!)

Why it fails: This ignores the 99.99% of time the device is sleeping. Even tiny sleep currents dominate over long periods.

Real-world example - ESP32 sleep current disaster:

  • Developer used ESP32 for battery sensor (coin cell CR2032, 225 mAh)
  • Measured TX power: 200 mA for 2 seconds every 10 minutes
  • Calculated life (active only): 225 / (200 × 2 / 600) = 338 hours (14 days)
  • Target was 1 year, so developer thought “plenty of margin”
  • Actual field life: 6 days (10% of calculated)

Root cause discovered:

  • ESP32 “deep sleep” current: 150 µA (not the 10 µA in datasheet - that requires disabling Wi-Fi/BT modules properly)
  • Developer assumed deep sleep was “basically zero”

Correct calculation:

Active (2s every 10 minutes = 0.033% duty cycle): - 200 mA × 2s / 600s = 0.667 mAh/hour

Sleep (598s every 10 minutes = 99.967% duty cycle): - 0.15 mA × 598s / 600s = 0.1495 mAh/hour

Total: 0.667 + 0.1495 = 0.817 mAh/hour

Battery life: 225 mAh / 0.817 mAh/h = 275 hours = 11.5 days (close to observed 6 days when you add self-discharge)

Lesson: Sleep current dominated the power budget (0.1495 vs 0.667 mAh/h = 18% of total), yet developer ignored it entirely. For duty-cycled IoT devices that sleep >95% of the time, sleep current IS the primary battery drain.

Fix applied:

  1. Switched to STM32L0 (sleep current 1.8 µA vs. ESP32’s 150 µA = 83× improvement)
  2. New sleep power: 0.0018 mA × 598s / 600s = 0.0018 mAh/hour
  3. New total: 0.667 + 0.0018 = 0.669 mAh/hour
  4. New life: 225 / 0.669 = 336 hours (14 days) → Add solar panel for indefinite operation

Power budget checklist:

  • Measure sleep current (do not trust datasheet typical values)
  • Calculate sleep power: sleep_current × (sleep_time / total_time)
  • Calculate active power: active_current × (active_time / total_time)
  • Add them together
  • De-rate for temperature and self-discharge (20-30%)

Common Pitfalls

Smart meters without cryptographic tamper detection can be compromised to under-report consumption, resulting in revenue loss estimated at 1-3% of billed energy. Implement device attestation, encrypted meter-to-head-end communication, and anomaly detection flagging statistically improbable consumption patterns.

Assuming all enrolled distributed energy resources will respond on demand ignores equipment failures and communication outages. Committing overstated flexibility creates reliability violations. Apply statistical availability models (typically 85-90% realisation rates) and maintain reserves to cover non-delivery.

Utilities that enrol customers without providing easy opt-out and transparent price signals face regulatory penalties and customer churn. Implement opt-in with clear benefit communication, real-time price visibility, and one-tap opt-out in the customer app.

35.10 Summary

This chapter covered power management for IoT devices:

Key Takeaways:

  1. Power Budget Analysis: Radio transmission is typically the largest power consumer (40-50%), followed by MCU active time

  2. Sleep Current Dominates: For duty-cycled devices, sleep current determines battery life more than active power. Target <5µA deep sleep

  3. Battery Life Calculation: Use Battery_mAh / Average_Current_mA = Hours. Account for duty cycle when calculating average current

  4. Protocol Selection: BLE and LoRaWAN are far more power-efficient than Wi-Fi and cellular for battery-powered devices

  5. Optimization Techniques: Combine hardware (low-power MCU, power gating), firmware (deep sleep, adaptive sampling), and system design (event-driven, local processing) approaches

  6. Cold Weather: Lithium batteries lose 20-50% capacity below 0°C—oversize batteries or use LiFePO4 for cold deployment

35.11 Concept Relationships

Power management connects to multiple layers of IoT system design:

  • Duty cycling (sleep/wake patterns) directly determines average current draw and battery life
  • Protocol selection (Wi-Fi, BLE, LoRa) is constrained by power budget – battery devices cannot sustain Wi-Fi’s 200-350mA TX current
  • Battery chemistry choice (Li-ion, LiFePO4, alkaline) affects voltage stability, temperature tolerance, and self-discharge rate
  • Form factor constraints (wearable < 50g) limit battery volume, which in turn limits capacity and required power efficiency
  • Cold weather performance exemplifies how environmental conditions interact with component specifications

Understanding power management reveals that battery life is not determined by any single design choice but emerges from the interaction of MCU sleep current, radio duty cycle, sensor sampling frequency, battery capacity, and self-discharge rate – optimizing one dimension while ignoring others fails.

35.12 See Also

In 60 Seconds

Power management prototyping measures actual current draw in each device state, identifies wake/sleep optimisations, and validates battery life estimates before manufacturing a product whose power consumption cannot be easily changed.

35.13 What’s Next

Next Chapter
Next Chapter Device Lifecycle Management
Previous Chapter Form Factors
Related Energy Aware Considerations

35.14 Resources

Power Measurement Tools:

  • Nordic Power Profiler Kit 2 (PPK2)
  • Joulescope DC Energy Analyzer
  • Monsoon Power Monitor

Low-Power MCU Datasheets:

  • STM32L4 series (ultra-low-power Cortex-M4)
  • nRF52840 (BLE SoC, 0.4µA sleep)
  • ESP32-S3 (Wi-Fi/BLE, ~10µA sleep)