4  Power Consumption Analysis

4.1 Learning Objectives

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

  • Analyze power consumption across different device operating states
  • Calculate average current for duty-cycled IoT devices
  • Identify and quantify power consumption components
  • Explain radio power states and their impact on energy consumption
  • Create accurate power budgets for IoT system design

Key Concepts

  • Operating States: The discrete power modes a device transitions through: active sensing, radio transmit, radio receive, CPU active, and deep sleep — each with distinct current draw
  • Average Current: I_avg = Σ(I_state × t_state) / T_total — the time-weighted mean current that determines actual battery life
  • Radio Idle Current: Current drawn when the radio is initialized but not actively transmitting; often 10–100× higher than MCU sleep current and a common battery drain surprise
  • Pull-Up Resistor Leakage: Pull-up resistors on I2C, SPI, and GPIO pins create continuous current paths; a 10 kΩ pull-up to 3.3 V draws 330 µA constantly
  • Power Budget Spreadsheet: A tool listing all operating states with their current draw and duty cycle fraction, enabling calculation of average current and battery life estimate
  • Voltage Regulator Quiescent Current: LDO regulators draw 30–200 µA regardless of load; for low-current sleep modes, regulator quiescent current can dominate total sleep power
  • Debug Interface Leakage: JTAG/SWD debug interfaces can add 1–5 mA when active; always disable debug interfaces in production builds
In 60 Seconds

Power consumption analysis builds a complete picture of device energy use across all operating states — active sensing, radio transmission, idle, and sleep — then calculates the time-weighted average current that determines actual battery life in deployment.

Energy and power management determines how long your IoT device can operate between battery changes or charges. Think of packing for a camping trip with limited battery packs – every bit of power must be used wisely. Since many IoT sensors need to run for months or years unattended, power management is often the single most important engineering decision.

“Power analysis is like tracking where your allowance goes each week,” said Bella the Battery. “You list every state the device can be in – sleeping, sensing, processing, transmitting – and how much current each state draws. Then you calculate the average based on how long the device spends in each state.”

Max the Microcontroller showed the math: “A typical IoT device might draw 10 microamps sleeping, 5 milliamps sensing, 15 milliamps processing, and 120 milliamps transmitting. If it sleeps 99 percent of the time and only transmits for 0.01 percent, the average current is dominated by the sleep current. But if it transmits 1 percent of the time, radio becomes the biggest drain!”

Sammy the Sensor emphasized the radio: “The radio is almost always the biggest energy consumer. Transmitting data uses 10 to 100 times more power than anything else. That is why communication protocol choice matters so much – BLE uses far less than Wi-Fi, and LoRa uses less than cellular.” Lila the LED summarized, “Break down the power budget, find the biggest consumer, and optimize that first. You get the most savings by fixing the biggest problem!”

4.2 Power Consumption Analysis

Understanding power consumption requires analyzing all device states and their duration. Most IoT devices cycle through multiple power modes:

State machine diagram showing IoT device power states: deep sleep (1-100 µA), light sleep (0.1-1 mA), idle (1-10 mA), active (10-50 mA), sensing (5-50 mA), processing (20-80 mA), and TX/RX (100-300 mA) with transition arrows between states
Figure 4.1: IoT device power state machine showing typical current consumption for each state

4.2.1 Power State Definitions

State Current Range Wake Time What’s Active
Deep Sleep 1-100 µA 100-500 µs RTC only, RAM retained
Light Sleep 0.1-1 mA 10-100 µs RTC + limited peripherals
Idle 1-10 mA Immediate CPU idle, peripherals on
Active 10-50 mA N/A CPU running, no radio
Sensing 5-50 mA N/A Sensors powered and sampling
Processing 20-80 mA N/A CPU compute-intensive
TX/RX 100-300 mA N/A Radio transmitting/receiving

4.2.2 The Idle Power Myth: Radio Idle ≈ Radio Receive

Critical Insight: “Idle” Radio Still Consumes Significant Power

Many developers assume a radio in “idle” mode consumes minimal power. This is FALSE for most wireless protocols:

Protocol TX Power RX Power Idle Power Deep Sleep
Wi-Fi 160-300 mA 80-120 mA 50-80 mA 10-20 µA
BLE 10-20 mA 10-15 mA 1-5 mA <1 µA
LoRa 40-120 mA 10-15 mA 1-5 mA 0.2-1 µA
Zigbee 15-30 mA 15-25 mA 1-5 mA <1 µA

Key insight: For Wi-Fi, idle mode (50-80 mA) is nearly as expensive as receiving (80-120 mA). The only way to save power is complete radio shutdown with deep sleep (10-20 µA).

For BLE and LoRa, idle is better than active but still consumes 1,000× more than deep sleep. Always completely disable radios when not in use.

4.2.3 Average Current Calculation

For duty-cycled devices, average current determines battery life:

\[I_{avg} = \sum_{i=1}^{n} \frac{I_i \times T_i}{T_{total}}\]

Where:

  • \(I_i\) = Current in state i
  • \(T_i\) = Time in state i
  • \(T_{total}\) = Total cycle time

Example: Environmental Sensor (1-hour cycle)

State Current Duration Energy (mAs)
Deep Sleep 10 µA 3595 s 35.95
Wake + Init 20 mA 0.5 s 10
Sensor Read 5 mA 2 s 10
Process Data 30 mA 0.5 s 15
Wi-Fi Connect 160 mA 1.5 s 240
Wi-Fi TX 200 mA 0.3 s 60
Wi-Fi Shutdown 80 mA 0.2 s 16
Total 3600 s 386.95

\[I_{avg} = \frac{386.95 \text{ mAs}}{3600 \text{ s}} = 0.107 \text{ mA} = 107 \text{ µA}\]

Battery life with 2000 mAh capacity:

\[Life = \frac{2000 \text{ mAh}}{0.107 \text{ mA}} = 18,692 \text{ hours} = 2.13 \text{ years}\]

Which state dominates the energy budget? Break down the percentages:

Energy percentage by state:

\[\text{Deep Sleep: } \frac{35.95}{386.95} = 9.3\% \quad \text{(despite 99.9% of time!)}\]

\[\text{Wi-Fi Connect: } \frac{240}{386.95} = 62.0\% \quad \text{(just 0.04% of time)}\]

\[\text{Wi-Fi TX: } \frac{60}{386.95} = 15.5\%\]

Lesson: Wi-Fi connection consumes 62% of total energy despite being active for only 1.5 seconds per hour. Never keep Wi-Fi “connected” between transmissions—the idle power (50-80mA) would dominate. Always connect → transmit → disconnect for battery-powered devices.

4.2.4 Radio Power States as Energy Multipliers

Bar chart comparing radio power consumption across protocols: Wi-Fi idle (50-80 mA), BLE idle (1-5 mA), LoRa idle (1-5 mA), all protocols' deep sleep (<1-20 µA), showing 1000-8000× difference between idle and sleep modes
Figure 4.2: Radio power states showing the dramatic difference between active and sleep modes

4.2.5 Protocol Energy Comparison

Different protocols have vastly different energy costs per transmission:

Protocol Typical TX Time TX Current Energy per TX (at 3.3V)
BLE (1 packet) 1-3 ms 15 mA 50-150 µJ
Zigbee 5-10 ms 20 mA 330-660 µJ
LoRa SF7 50 ms 40 mA 6,600 µJ
LoRa SF12 1,500 ms 40 mA 198,000 µJ
Wi-Fi (short) 100 ms 180 mA 59,400 µJ
Wi-Fi (incl. connect) 3,000 ms 160 mA 1,584,000 µJ
LTE-M 500 ms 220 mA 363,000 µJ
NB-IoT 1,000 ms 200 mA 660,000 µJ

Key observation: BLE is 300-10,000× more efficient than Wi-Fi per transmission. Choose protocols carefully based on range and data requirements.

4.3 Power Budget Worked Examples

4.3.1 Worked Example: Optimizing Power Budget for a Wildlife Tracking Collar

Scenario: You are designing a GPS tracking collar for deer monitoring in a wildlife research project. The collar must last 2 years on a single battery, transmit location every 4 hours, and weigh under 100g (including battery).

Given:

  • GPS module: L96 (acquisition 26mA × 30s cold start, 22mA × 1s hot start)
  • Radio: LoRa SX1276 (40mA TX @ +14dBm)
  • MCU: STM32L4 (8mA active, 1µA deep sleep)
  • Battery constraint: <50g → 2× CR2450 = 1,200 mAh total
  • Transmission: 50-byte location packet every 4 hours

Steps:

  1. Calculate GPS energy per acquisition:

    Cold start (first fix after power cycle):
E_cold = 26mA × 30s = 780 mAs = 0.217 mAh

Hot start (subsequent fixes with ephemeris):
E_hot = 22mA × 1s = 22 mAs = 0.006 mAh

Average (assuming 1 cold start per day, 5 hot starts):
E_gps_day = 780 + (5 × 22) = 890 mAs/day = 0.247 mAh/day

  2. Calculate LoRa transmission energy:

    TX time for 50 bytes @ SF7: 70ms
E_tx = 40mA × 0.07s = 2.8 mAs per transmission
6 transmissions/day = 16.8 mAs/day = 0.0047 mAh/day

  3. Calculate MCU energy:

    Active time per cycle: 2s (wake, process, initiate GPS/radio)
Active energy: 8mA × 2s × 6 = 96 mAs/day = 0.027 mAh/day

Sleep time: 24h - (6 × 32s) = 86,208s
Sleep energy: 1µA × 86,208s = 86.2 mAs/day = 0.024 mAh/day

  4. Total daily consumption:

    GPS:     0.247 mAh/day
LoRa:    0.005 mAh/day
MCU Act: 0.027 mAh/day
MCU Slp: 0.024 mAh/day
Total:   0.303 mAh/day

  5. Calculate battery life:

    Theoretical: 1,200 mAh / 0.303 mAh/day = 3,960 days = 10.8 years
With 70% efficiency factor: 3,960 × 0.7 = 2,772 days = 7.6 years

Result: The design significantly exceeds the 2-year requirement. This margin can be used to:

  • Increase transmission frequency (every 2 hours → still 3.8 years)
  • Add activity detection with accelerometer
  • Use smaller/lighter battery (600 mAh still gives 3.8 years)

Key Insight: GPS acquisition dominates the power budget (82%). Optimizations should focus on keeping GPS in hot-start mode (preserve ephemeris data) or using A-GPS for faster acquisition.

4.3.2 Worked Example: Comparing Protocol Energy Costs for a Smart Agriculture Sensor

Scenario: A soil moisture sensor transmits 100-byte readings every 30 minutes. Compare Wi-Fi, BLE, and LoRa for a 2-year battery life target.

Given:

  • Sensor reading: 5mA × 0.5s = 2.5 mAs per reading
  • MCU (nRF52840): 5.5mA active, 1.5µA deep sleep
  • Processing: 10ms per reading
  • Readings per day: 48

Protocol Comparison:

Protocol Connection Time TX Time Total Energy/TX
Wi-Fi 3s @ 160mA = 480 mAs 100ms @ 200mA = 20 mAs 500 mAs
BLE 0ms (advertising) 5ms @ 15mA = 0.075 mAs 0.075 mAs
LoRa SF7 0ms 100ms @ 40mA = 4 mAs 4 mAs

Daily Energy Consumption:

Component Wi-Fi BLE LoRa
Radio (48 TX) 24,000 mAs 3.6 mAs 192 mAs
Sensor 120 mAs 120 mAs 120 mAs
MCU Active 26.4 mAs 26.4 mAs 26.4 mAs
MCU Sleep 130 mAs 130 mAs 130 mAs
Daily Total 24,276 mAs 280 mAs 468 mAs

Battery Life (2000 mAh @ 70% efficiency):

Protocol Daily (mAh) Life (days) Life (years)
Wi-Fi 6.74 208 0.57
BLE 0.078 17,949 49.2
LoRa 0.130 10,769 29.5

Conclusion: Wi-Fi gives only 7 months of battery life, making it unsuitable without energy harvesting. BLE achieves 49 years (theoretical), allowing for smaller batteries or higher transmission rates. LoRa provides excellent range with 29 years life. For this application, BLE is optimal for short-range or LoRa for long-range.

4.4 Real-World Example: Smart Agriculture Deployment

A practical deployment of 100 soil moisture sensors across a vineyard:

Initial Design Choices:

  • ESP8266 with Wi-Fi (familiar technology)
  • 4× AA batteries (6V, 2000mAh effective)
  • Transmit every 15 minutes

Measured Power Profile:

State Current Duration Energy
Wi-Fi Connect 160 mA 5 s 800 mAs
Wi-Fi TX 200 mA 0.5 s 100 mAs
Idle (no sleep) 15 mA 894.5 s 13,418 mAs
Per cycle 900 s 14,318 mAs

Average current: 14,318 / 900 = 15.9 mA

Battery life: 2000 mAh / 15.9 mA = 126 hours = 5 days

Problem: Sensors died after one week. Replacement labor cost: 100 sensors × 30 min × $20/hr = $1,000 per cycle = $52,000/year

4.4.1 Optimized Redesign

Changes Made:

  1. ESP32 with deep sleep (10 µA vs 15 mA idle)
  2. LoRa radio (40 mA TX, no connection overhead)
  3. Transmit every 30 minutes (reduced from 15)
  4. Static network configuration

Optimized Power Profile:

State Current Duration Energy
Wake 20 mA 0.1 s 2 mAs
Sensor Read 5 mA 0.5 s 2.5 mAs
LoRa TX 40 mA 0.1 s 4 mAs
Deep Sleep 10 µA 1799.3 s 18 mAs
Per cycle 1800 s 26.5 mAs

Average current: 26.5 / 1800 = 0.0147 mA = 14.7 µA

Battery life: 2000 mAh / 0.0147 mA = 136,054 hours = 15.5 years

Result: Battery life improved from 5 days to 15+ years—a 1,000× improvement.

4.5 Common Power Budget Mistakes

Alarm Bells: Critical Power Drains to Avoid

1. Ignoring Radio Idle Current

WRONG: "Radio off = 0 mA"
RIGHT: Check datasheet - many radios have 50-80 mA idle current!

2. Underestimating Wi-Fi Connection Time

WRONG: "Wi-Fi TX takes 100ms"
RIGHT: Connection + negotiation + TX can take 2-10 seconds

3. Forgetting Pull-up Resistors

10kΩ pull-up at 3.3V = 330 µA CONTINUOUS
This alone consumes 3× more than ESP32 deep sleep!

4. Assuming Datasheet Sleep Current

Datasheet: "10 µA deep sleep"
Reality: Add peripherals, pull-ups, LEDs = 100+ µA
ALWAYS MEASURE on actual hardware!

5. Ignoring Voltage Regulator Quiescent Current

LDO quiescent: 30-100 µA typical
Can exceed MCU deep sleep current!
Choose low-IQ regulators for battery designs.

6. Not Accounting for Peak Currents

Battery voltage drops under load
Brown-out resets cause device failure
Solution: Add bulk capacitor or choose battery with low ESR

4.6 Power Budget Calculator

Use this interactive calculator to estimate your device’s battery life:

4.6.1 Understanding the Calculation

The calculator uses the duty cycle formula:

\[I_{avg} = \frac{I_{active} \times T_{active} + I_{sleep} \times T_{sleep}}{T_{total}}\]

And battery life formula with efficiency factor:

\[Life = \frac{Capacity \times Efficiency}{I_{avg}}\]

The efficiency factor (default 0.7) accounts for:

  • Temperature effects on battery capacity
  • Voltage cutoff (can’t use full capacity)
  • Self-discharge over deployment lifetime
  • Battery aging/degradation
  • Non-ideal DC-DC converter efficiency

Scenario: A farm monitoring company deployed 200 soil moisture sensors powered by 2× AA alkaline batteries (3000 mAh total). The design target was 1-year battery life, but field reports show batteries dying after only 3 months.

Given Initial Design:

  • ESP8266 MCU with Wi-Fi
  • Soil moisture sensor: 30 mA active
  • Transmission every 15 minutes to cloud server
  • Expected deep sleep current: 10 µA

Investigation Steps:

  1. Check baseline sleep current: Used ammeter on lab device → measured 15 mA idle, NOT 10 µA

    • Root cause: Code never entered deep sleep mode due to missing ESP.deepSleep() call
    • Fix: Add proper sleep call after data transmission

  2. Measure actual Wi-Fi connection time: Expected 2s, measured 8s average

    • Root cause: Weak Wi-Fi signal in field required multiple connection retries
    • Fix: Add fixed IP configuration to avoid DHCP delay (reduces connection time to 3s)

  3. Calculate corrected power budget:

    State Current Duration Energy (mAs)
    Deep Sleep 0.010 mA 885 s 8.85
    Wake + Init 80 mA 0.5 s 40
    Sensor Read 30 mA 1 s 30
    Wi-Fi Connect 160 mA 3 s 480
    Wi-Fi TX 200 mA 0.5 s 100
    Total per cycle 900 s 658.85

    Average current: 658.85 / 900 = 0.732 mA Battery life: 3000 mAh / 0.732 mA = 4,098 hours = 5.7 months

  4. Compare to BROKEN design (no deep sleep):

    • Average: (160×11 + 15×889) / 900 = 16.73 mA
    • Battery life: 3000 / 16.73 = 179 hours = 7.5 days
    • Field reports showed 3 months → likely some devices entering sleep intermittently

Final Optimizations:

  • Switch from Wi-Fi to LoRa: 40 mA TX for 0.1s = 4 mAs (vs 580 mAs for Wi-Fi)
  • Increase interval to 30 minutes
  • New average: 0.041 mA → 7.3 years battery life

Key Lesson: Measure actual hardware, never trust datasheets alone. The difference between 10 µA sleep (spec) and 15 mA idle (reality) destroyed the power budget.

Before designing your power budget, choose the right communication technology based on these factors:

Factor Wi-Fi BLE LoRa Cellular (NB-IoT)
TX Energy/packet 1.58 mJ (high) 100 µJ (very low) 6.6 mJ (low) 660 mJ (high)
Range 50-100m 10-50m 2-15km Unlimited (tower)
Data Rate 1-100 Mbps 1 Mbps 0.3-50 kbps 10-100 kbps
Infrastructure Wi-Fi router needed Gateway within 50m Gateway within 15km Cellular subscription
Best For Mains-powered, high data Wearables, short range Agricultural, remote Mobile assets, wide area
Battery Life (1 reading/hour) 6 months 5+ years 3+ years 1 year

Decision Process:

  1. Range requirement → Rules out some options (BLE can’t reach 500m farm)
  2. Data volume → Sending images? Need Wi-Fi/Cellular. Sensor value? Any works.
  3. Power budget → Battery-powered? Avoid Wi-Fi/Cellular unless solar-powered
  4. Infrastructure → Have existing Wi-Fi? May reuse it despite power cost
  5. Total Cost → LoRa needs gateway ($200-500) but saves battery replacements

Example: For a parking lot sensor (100m from building, 1 status update/minute, 2-year battery target): - Wi-Fi: NO (too power-hungry, 6 month battery) - BLE: NO (range insufficient) - LoRa: YES (if gateway available) - NB-IoT: MAYBE (if cellular coverage and monthly fees acceptable)

Common Mistake: Forgetting Development/Debug Power Drains

The Problem: Your production power budget looks perfect on paper, but devices die fast in the field.

Hidden Power Drains During Development:

  1. USB serial connection: Keeps MCU from entering deep sleep (USB peripheral active)
    • Solution: Disable USB before measuring, or use hardware serial instead
  2. Debug LEDs: A single red LED at 20 mA × 1% duty cycle = 0.2 mA average
    • This alone can halve battery life on a 0.1 mA budget device
    • Solution: Disable all LEDs in production firmware, or use high-value resistors
  3. Pull-up resistors on unused GPIOs: 10kΩ at 3.3V = 330 µA EACH
    • Solution: Configure unused pins as outputs or use input with internal pull-down
  4. Voltage regulator quiescent current: Many LDOs draw 50-100 µA even with no load
    • Solution: Choose low-IQ regulators (MCP1700: 1.6 µA, AP2112: 55 µA)
  5. External peripherals: Sensor breakout boards often have power LEDs and regulators
    • Solution: Power sensors through a transistor switch controlled by MCU

Real Example: ESP32 deep sleep spec says 10 µA, but: - With USB connected: 15,000 µA (USB keeps chip awake) - With blue LED on GPIO: 20,000 µA - With external sensor board: 5,000 µA (board’s regulator + LED) - Properly configured: 12 µA (close to spec!)

Verification Protocol:

  1. Measure current with ammeter in series with battery
  2. Verify deep sleep is actually reached (should drop to µA range within seconds)
  3. If current high, disconnect peripherals one by one to find culprit
  4. Document actual measured current, not datasheet values

4.7 Knowledge Check

## How It Works

Power analysis breaks device operation into discrete states, measures each, then calculates weighted average:

State identification process:

  1. Map all states: Deep sleep, wake/init, sensor read, processing, radio TX, radio RX, shutdown
  2. Measure each state: Use power profiler to capture current draw and duration
  3. Calculate state energy: Energy = Current × Voltage × Time (mAs or mAh)
  4. Weight by frequency: Average current = Σ(State energy × Cycles per day) / 24 hours

Example calculation (environmental sensor, 1-hour cycle):

Deep sleep: 10µA × 3595s = 35.95 mAs
Sensor read: 5mA × 2s = 10 mAs
WiFi connect: 160mA × 1.5s = 240 mAs
WiFi TX: 200mA × 0.3s = 60 mAs
Total per cycle: 345.95 mAs

Average current: 345.95 mAs / 3600s = 0.096 mA = 96µA
Battery life (2000mAh): 2000 / 0.096 = 20,833 hours = 2.4 years

Hidden drains exposed: Pull-up resistors (10kΩ at 3.3V = 330µA each), voltage regulator quiescent current (50-100µA), peripheral standby current (sensors “off” but still powered). These continuous drains dominate low-duty-cycle devices.

4.8 Concept Check

## Concept Relationships

Power analysis provides the quantitative foundation for all energy optimization:

  • Validates: Theoretical calculations from Energy-Aware Introduction against real measured behavior
  • Guides: Identifies which states to optimize (80/20 rule: 80% energy from 20% of states)—optimize the biggest consumer first
  • Prerequisite For: Cannot size Energy Sources (battery capacity, solar panel) without accurate power profile
  • Measured By: Requires Energy Measurement tools to capture state transitions

Iteration loop: Analyze profile → Identify bottleneck (e.g., WiFi connection = 42% of energy) → Optimize (disable WiFi, use LoRa) → Re-analyze → Repeat. Never optimize blindly—let measurements guide priorities.

4.9 See Also

Analysis Tools & Methods:

What to Analyze:

Protocol-Specific Analysis:

Real-World Profiles:

4.10 Try It Yourself

4.10.1 Exercise 1: Calculate Break-Even Transmission Frequency

Scenario: Soil moisture sensor, 3000mAh battery, 2-year target.

Given:

  • Deep sleep: 10µA
  • Sensor read: 20mA for 500ms
  • LoRa TX (SF7): 40mA for 100ms
  • Target average current: 171µA (for 2 years)

Calculate: Maximum transmission frequency to stay under budget.

Steps:

  1. Per-reading energy: (20mA × 0.5s) + (40mA × 0.1s) = 14 mAs
  2. Sleep energy allowance: 171µA average - reading overhead = ?
  3. Daily sleep energy: 10µA × 86,400s = 864 mAs
  4. Daily energy budget: 171µA × 86,400s = 14,774 mAs
  5. Daily reading budget: 14,774 - 864 = 13,910 mAs
  6. Readings per day: 13,910 / 14 = 994 readings
  7. Interval: 86,400s / 994 = 87 seconds minimum

What to observe: Sleep energy is only 5.8% of budget. 94.2% goes to sensor+TX. Transmission frequency is the dominant design parameter.

4.10.2 Exercise 2: Hidden Drain Detective

Profile data:

State          | Current | Duration | Energy/cycle
Deep sleep     | 150µA   | 595s     | 89.25 mAs
Sensor read    | 15mA    | 2s       | 30 mAs
LoRa TX        | 40mA    | 3s       | 120 mAs
Total (10 min) |         | 600s     | 239.25 mAs
Average: 0.399mA

Problem: Expected deep sleep is 10µA but measuring 150µA (15× higher).

Your task: Investigate potential causes. Calculate battery life impact of fixing sleep current to 10µA.

Answer: 140µA excess × 595s = 83.3 mAs wasted per cycle. Fixed average: (10µA×595s + 30 mAs + 120 mAs) / 600s = 0.260mA (35% improvement). On 2000mAh battery: current life = 5,013 hours (7 months) vs fixed = 7,692 hours (10.6 months) = 53% longer.

4.10.3 Interactive Exercise: Transmission Frequency Calculator

Calculate the maximum sustainable transmission rate for your power budget:

4.11 Summary

Key takeaways from power consumption analysis:

  1. Sleep Dominates: For duty-cycled devices, sleep current × time often exceeds active consumption
  2. Radio Idle is Expensive: Radio idle mode can consume 1,000-10,000× more than deep sleep
  3. Calculate Average Current: Use the duty cycle formula to determine realistic battery life
  4. Watch for Hidden Drains: Pull-ups, LEDs, debug interfaces, and regulators all consume power
  5. Measure Real Hardware: Datasheet values are best-case; always measure actual consumption

Common Pitfalls

Many power budgets count only transmit current for the radio, but an idle radio waiting to transmit can draw 5–20 mA — comparable to or exceeding transmit current for short messages. Always add radio idle time to your current budget.

Measuring current with a multimeter gives the average over the meter’s response time (typically 100 ms–1 s). For devices with sub-second duty cycles, this misses the actual peak-and-sleep waveform. Use an oscilloscope with current probe or a dedicated power profiler.

A 10 kΩ pull-up resistor on a GPIO pin held low continuously draws 330 µA — more than a sleeping MCU. On boards with multiple communication interfaces (I2C, SPI, UART), total pull-up leakage can exceed 1 mA during sleep.

Measuring current for 10 minutes and extrapolating to 5 years misses infrequent high-current events (OTA updates, error retries, flash writes) that significantly affect average current. Profile across all operational states including exceptional cases.

4.12 What’s Next

If you want to… Read this
Understand how individual operations contribute to energy Energy Cost of Common Operations
Apply low-power design strategies Low-Power Design Strategies
Learn measurement tools and techniques Energy Measurement and Profiling
Use interactive power budget calculators Interactive Tools
See real-world power analysis examples Case Studies and Best Practices