57 Edge Review: Power Optimization
57.1 Learning Objectives
By the end of this chapter, you will be able to:
- Calculate Battery Life: Compute expected battery duration for various power profiles and duty cycles
- Evaluate Sleep Mode Trade-offs: Compare deep sleep vs regular sleep including wake-up penalties
- Design Duty Cycling Strategies: Determine optimal sampling intervals for different applications
- Quantify Cost Savings: Calculate battery replacement savings from power optimization
Key Concepts
- Power consumption profile: A characterisation of a device’s energy draw across all operating modes (active, idle, sleep, transmit) including the time spent in each mode during normal operation.
- Energy budget: The maximum energy available to an edge device per unit time (from battery or harvesting), constraining the sum of all activities (sensing, processing, communication) to a sustainable average power.
- Transmission power scaling: Adjusting radio transmit power to the minimum needed to achieve reliable communication with the gateway, saving energy on links that are shorter than the radio’s maximum range.
- Adaptive sampling for power reduction: Reducing sensor sampling rate during quiet periods and increasing it when signals are changing rapidly, balancing data fidelity against energy consumption dynamically.
- Power profiling tool: Hardware or software instruments (current probes, power monitors like Nordic PPK2, Nordic Energy Profiler) used to measure actual device current consumption across operating modes.
57.2 Prerequisites
Before studying this chapter, complete:
- Edge Review: Architecture and Reference Model - Reference model context
- Edge Review: Data Reduction Calculations - Bundling benefits
- Basic understanding of electrical current (mA) and battery capacity (mAh)
For Beginners: Understanding IoT Power
IoT devices are like hibernating bears:
- Active mode (25 mA): Bear is hunting - uses lots of energy
- Transmit mode (120 mA): Bear is running - uses MOST energy
- Sleep mode (1 mA): Bear is napping - uses some energy
- Deep sleep mode (0.01 mA): Bear is hibernating - uses almost no energy
The trick is keeping the bear in deep hibernation as much as possible, only waking it briefly to check things and report back.
A 2500 mAh battery is like 2500 hours worth of 1 mA activity. If your device averages 0.2 mA, it lasts 12,500 hours (over 1.4 years).
57.3 Power Profile Fundamentals
57.3.1 Typical IoT Device Power States
| State | Current Draw | Duration | Activity |
|---|---|---|---|
| Deep Sleep | 0.01 mA | 99% of time | RTC running, RAM retained |
| Sleep | 1 mA | N/A | Peripherals standby |
| Active | 25 mA | Milliseconds | Sensing, processing |
| Transmit | 120 mA | Milliseconds | Radio transmission |
57.3.2 The Power Budget Equation
The average current over a duty cycle determines battery life:
\[I_{\text{avg}} = \frac{I_{\text{active}} \times t_{\text{active}} + I_{\text{tx}} \times t_{\text{tx}} + I_{\text{sleep}} \times t_{\text{sleep}}}{t_{\text{cycle}}}\]
\[\text{Battery Life (hours)} = \frac{\text{Battery Capacity (mAh)}}{I_{\text{avg}} \text{ (mA)}}\]
57.4 Deep Sleep Trade-off Analysis
The key question: Is the wake-up penalty worth the sleep savings?
## Deep Sleep Decision Matrix
57.4.1 When to Use Deep Sleep
| Condition | Recommendation |
|---|---|
| Long sleep intervals (>10 minutes) | Use deep sleep |
| Low duty cycle (<1% active) | Use deep sleep |
| Remote deployments | Use deep sleep |
| Battery replacement costly | Use deep sleep |
57.4.2 When NOT to Use Deep Sleep
| Condition | Recommendation |
|---|---|
| Frequent wake-ups (<1 minute) | Use regular sleep |
| High duty cycle (>10% active) | Active current dominates anyway |
| Low-latency requirements | 2-second wake-up too slow |
| Always-on peripherals needed | Sleep mode retains peripherals |
57.5 Battery Life Comparison
57.5.1 Scenario: Environmental Monitor
| Parameter | Value |
|---|---|
| Battery capacity | 2500 mAh |
| Sampling interval | 10 minutes |
| Active duration | 0.1 seconds |
| Transmit duration | 0.5 seconds |
57.5.2 Cost Impact
Putting Numbers to It
The battery life extension from deep sleep mode demonstrates the power of low-duty-cycle operation:
\[\text{Battery Life (hours)} = \frac{\text{Battery Capacity (mAh)}}{\text{Average Current (mA)}}\]
For a 2500 mAh battery with 10-minute sampling intervals:
Sleep mode calculation:
- Active: 0.1 sec at 25 mA = 2.5 mA-sec
- Transmit: 0.5 sec at 120 mA = 60 mA-sec
- Sleep: 599.4 sec at 1 mA = 599.4 mA-sec
- Total: \((2.5 + 60 + 599.4) / 600 = 1.103\) mA average
- Battery life: \(\frac{2500}{1.103} = 2{,}266 \text{ hours} \approx 94 \text{ days}\)
Deep sleep mode calculation:
- Wake-up: 2 sec at 25 mA = 50 mA-sec
- Active: 0.1 sec at 25 mA = 2.5 mA-sec
- Transmit: 0.5 sec at 120 mA = 60 mA-sec
- Deep sleep: 597.4 sec at 0.01 mA = 5.97 mA-sec
- Total: \((50 + 2.5 + 60 + 5.97) / 600 = 0.197\) mA average
- Battery life: \(\frac{2500}{0.197} = 12{,}690 \text{ hours} \approx 1.45 \text{ years}\)
\[\text{Life Extension} = \frac{I_{\text{sleep}}}{I_{\text{deep}}} = \frac{1.103}{0.197} \approx 5.6\times \text{ improvement}\]
Fleet-scale savings (1,000 devices over 5 years):
- Sleep mode: 3.9 changes/yr per device \(\times\) 1,000 \(\times\) 5 = 19,500 changes at $25 = $487,500
- Deep sleep: 0.69 changes/yr per device \(\times\) 1,000 \(\times\) 5 = 3,450 changes at $25 = $86,250
- Savings: $401,250
The 2-second wake-up penalty adds only 50 mA-sec to a 600-second cycle – less than 0.1 mA to the average.
57.6 Priority-Based Processing for Mixed Deployments
Industrial facilities often have mixed requirements: some sensors are safety-critical, others are monitoring-only.
### Dual-Path Processing Architecture
57.6.1 Adaptive Sampling Under Load
The system adjusts sampling rates based on CPU utilization:
| CPU Load | Data Retention | Rationale |
|---|---|---|
| Low (<50%) | Keep 100% of data | Capacity available for all sensors |
| Medium (50-70%) | Keep 90% of data | Minor shedding of redundant readings |
| High (70-85%) | Keep 80% of data | Per non-critical sensor tolerance |
| Overload (>85%) | Keep 70% of data | Maximum acceptable data loss |
57.7 Event-Driven Architecture Benefits
Comparing polling vs event-driven approaches for a 2500 mAh battery:
| Approach | Description | Avg Current | Battery Life |
|---|---|---|---|
| High-frequency polling | Sample at 10 Hz, always active | ~12 mA | ~9 days |
| Periodic polling | Sample every 10 min, sleep between | ~1.1 mA | ~94 days |
| Event-driven + deep sleep | Wake on threshold events only | ~0.2 mA | ~1.4 years |
| Optimized event-driven | Minimal wake, low-power comparators | ~0.05 mA | ~5.7 years |
Event-driven architectures with deep sleep can achieve battery lifetimes exceeding a year, compared to just 9 days for high-frequency polling.
Worked Example: Wildlife Tracking Collar Power Optimization
Scenario: Biologists deploy GPS collars on 100 elk to study migration patterns. Collars must last 2 years without battery replacement.
Initial Design (Fails Requirement):
- GPS sampling: Every 5 minutes (288 readings/day)
- Cellular transmission: Immediate upload after each reading
- Battery: 6,000 mAh
- Power profile:
- GPS fix: 50 mA for 30 seconds (cold start)
- Cellular TX: 200 mA for 5 seconds
- Sleep: 2 mA between readings
- Cycle time: 300 seconds (5 minutes)
- Average current: \((50 \times 30 + 200 \times 5 + 2 \times 265) / 300 = (1500 + 1000 + 530) / 300 = 10.1\) mA
- Battery life: 6,000 / 10.1 = 594 hours = 24.7 days (fails 2-year requirement)
Optimized Design:
Change 1: Event-Driven GPS
- Only activate GPS if accelerometer detects movement
- Elk stationary 70% of time (grazing, resting)
- GPS activations reduced to 30% of readings
Change 2: Hot-Start GPS
- Cache satellite ephemeris data for hot-start fixes
- GPS fix time reduced from 30 seconds to 3 seconds
- Power per fix: 50 mA for 3 seconds = 150 mA-sec (vs 1,500 mA-sec)
Change 3: LoRaWAN Instead of Cellular + Daily Batch Upload
- Store GPS fixes locally, upload once per day
- LoRaWAN: 40 mA for 1 second per packet
- Daily upload: 12 packets at 1 second each = 12 seconds/day
Change 4: Deep Sleep
- Replace 2 mA sleep with 0.01 mA deep sleep
New Power Calculation:
Per day (86,400 seconds):
- GPS fixes: 288 readings \(\times\) 0.3 (moving) \(\times\) 50 mA \(\times\) 3s = 12,960 mA-sec
- LoRaWAN TX: 12s \(\times\) 40 mA = 480 mA-sec
- Deep sleep: ~86,376s \(\times\) 0.01 mA = 864 mA-sec
- Total: 14,304 mA-sec per day = 3.97 mAh/day
Battery life: 6,000 mAh / 3.97 mAh/day = 1,511 days = 4.1 years (exceeds 2-year requirement)
Cost Savings:
| Approach | Battery Life | Collar Replacements/2yr | Cost @ $150/replacement |
|---|---|---|---|
| Original | 24.7 days | 100 collars x 30 replacements = 3,000 | $450,000 |
| Optimized | 4.1 years | 0 (no replacement needed) | $0 |
| Savings | - | - | $450,000 over 2 years |
Additional benefits:
- No capture/recollaring stress to animals
- Continuous multi-year migration data
- Remote collar activation/deactivation via LoRaWAN downlink
Decision Framework: Battery Life Trade-offs
| Optimization | Battery Life Gain | Latency Cost | Data Quality Cost | When to Use |
|---|---|---|---|---|
| Deep sleep (0.01 mA) | 5-10x | +2s wake-up | None | Sampling interval >5 min |
| Event-driven sampling | 3-10x | None (faster) | May miss slow changes | Threshold-based monitoring |
| Batch transmission | 5-20x | Hours (deferred) | None | Non-real-time applications |
| Lower-power radio | 3-5x | None | Shorter range | LoRa vs cellular |
| Reduce sampling rate | Linear with reduction | None | Lower resolution | Slow-changing phenomena |
| Local processing | 2-10x (avoid TX) | None | Must have edge compute | High data volume |
Selection guidance:
- Need <2x improvement: Reduce sampling rate
- Need 2-10x improvement: Add deep sleep and reduce sampling
- Need 10-50x improvement: Combine deep sleep, event-driven sensing, and batch transmission
- Need >50x improvement: All optimizations plus energy harvesting (solar, vibration)
Common Mistake: Forgetting Always-On Sensor Power in Event-Driven Designs
The Mistake: Students assume event-driven sensing eliminates all active power, forgetting that the accelerometer or comparator itself consumes power continuously.
Example Calculation Error:
Student calculates:
- “Deep sleep 99.9% of time at 0.01 mA = 0.01 mA average”
- Forgets: Accelerometer running 24/7 at 0.2 mA
Actual average current: 0.01 + 0.2 = 0.21 mA (21x higher than calculated)
Battery life impact:
- Calculated: 6,000 / 0.01 = 600,000 hours = 68.5 years
- Actual: 6,000 / 0.21 = 28,571 hours = 3.26 years
The Lesson: Event-driven systems still need always-on sensors or comparators. Include their power consumption in calculations. Choose ultra-low-power accelerometers (<0.05 mA) or use external hardware wake interrupts where possible.
57.8 Chapter Summary
Deep sleep mode (0.01 mA) provides a 5.6x power reduction over regular sleep (1 mA) for a typical 10-minute sampling cycle, extending battery life from 94 days to 1.45 years with a 2500 mAh battery.
Battery life calculations must account for all phases: wake-up penalty, active sensing, transmission, and sleep current. The wake-up penalty (50 mA-sec per cycle) is negligible compared to the sleep savings (from 599 mA-sec to 5.97 mA-sec per cycle).
Dual-path processing separates critical safety sensors (deterministic latency, zero data loss) from monitoring sensors (best-effort, adaptive sampling) to optimize mixed deployments.
Event-driven architectures with deep sleep achieve over a year of battery life compared to 9 days for high-frequency polling, but designers must account for always-on sensor power (accelerometers, comparators).
The decision matrix guides sleep mode selection: use deep sleep for long intervals, low duty cycles, and remote deployments; use regular sleep for frequent wake-ups or low-latency requirements.
Key Takeaway
Deep sleep mode is the single most impactful power optimization for low-duty-cycle IoT devices. At 0.01 mA (compared to 1 mA for regular sleep and 120 mA for transmitting), deep sleep extends battery life from 94 days to over a year for devices sampling every 10 minutes. The 2-second wake-up penalty adds only 0.083 mA to the average current across a 600-second cycle. For mixed deployments, dual-path processing separates safety-critical sensors (zero data loss, under 100ms latency) from monitoring sensors (best-effort, adaptive sampling). Always include always-on sensor power in event-driven designs.
For Kids: Meet the Sensor Squad!
“Bella’s Big Sleep!”
Bella the Battery was worried. “At this rate, I’ll be completely empty in just 94 days! That’s only about three months!”
“What’s using all your energy?” asked Sammy the Sensor.
“The sleep mode! Even when nobody’s doing anything, the device is still using 1 milliamp of power. It’s like leaving a night light on 24 hours a day.”
Max the Microcontroller had an idea. “What if we use DEEP sleep instead? It’s like hibernation! Instead of 1 milliamp, we’d only use 0.01 milliamp. That’s 100 times less!”
“But there’s a catch,” Lila the LED warned. “Waking up from deep sleep takes 2 whole seconds. Regular sleep only takes 0.1 seconds.”
“That’s okay!” Max calculated quickly. “We only check the temperature every 10 minutes. So we’re asleep for 597 seconds and awake for about 3 seconds. The wake-up penalty is tiny compared to all that sleeping time!”
Bella did the math. “Wait… instead of 94 days, I’d last over a YEAR AND A HALF?!”
“That’s right – more than five times longer!” Max said. “And if we only wake up when something important happens, like a temperature spike, we can save even MORE energy!”
Bella beamed. “Deep sleep is my new best friend! It’s like the difference between a cat nap and full-on bear hibernation!”
The Sensor Squad learned: For IoT devices that don’t need to check things very often, deep sleep is like a superpower. A tiny wake-up delay is a tiny price to pay for over a year of extra battery life!
57.9 Concept Relationships
Power optimization builds on:
- Edge Architecture - Level 1 (device) power states and Level 3 (gateway) bundling strategies
- Data Reduction - Bundling 60 transmissions into 1 reduces power consumption by reducing radio-on time
Power optimization enables:
- Edge Deployments - Deep sleep extends battery life from days to years, enabling remote deployments
- Storage Economics - Reduced battery replacement costs (saving over $400,000 over 5 years for 1,000 devices)
Parallel concepts:
- Deep sleep trade-off analysis and edge vs cloud decision framework: Both balance competing constraints (wake-up penalty vs power savings; latency vs capability)
- Dual-path processing and tiered storage: Both separate critical (real-time) from non-critical (best-effort) workloads
57.10 See Also
Related review chapters:
- Edge Review: Architecture - Architecture principles driving power decisions
- Edge Review: Data Reduction - Bundling reduces transmission count by 60x
- Edge Review: Storage Economics - Power optimization contributes to TCO savings
Foundational chapters:
- Energy & Power Management - Comprehensive power management strategies
- Design Methodology - System-level design considerations
Next topic:
- Edge Review: Storage Economics - ROI and TCO analysis
57.11 What’s Next
| Direction | Chapter | Link |
|---|---|---|
| Next | Edge Review: Storage and Economics | edge-review-storage-economics.html |
| Previous | Edge Review: Gateway and Security | edge-review-gateway-security.html |
| Related | Edge Review: Architecture and Reference Model | edge-review-architecture.html |
| Related | Edge Review: Data Reduction Calculations | edge-review-data-reduction.html |
Common Pitfalls
1. Optimising sleep current without measuring active current
For devices with long sleep periods and short active bursts, active current dominates energy consumption despite the short duration. Use power profiling to identify whether sleep optimisation or active-phase optimisation delivers more benefit.
2. Assuming manufacturer datasheet sleep currents are achievable
Datasheet sleep currents assume all peripherals are properly disabled and no floating inputs are drawing current. Achieving datasheet sleep current in real hardware requires careful board design and software configuration.
3. Ignoring the energy cost of failed transmissions and retries
A radio transmission that fails and requires 3 retries consumes 4× the expected transmission energy. Design communication protocols to minimise retransmissions through appropriate retry limits, backoff algorithms, and link quality monitoring.