%% fig-alt: "Dual-path edge processing architecture showing 100 critical safety sensors with maximum 100ms latency requirement flowing through a high-priority queue with 50% reserved CPU, and 200 massive monitoring sensors (delay-tolerant) flowing through a batch buffer with 50% best-effort CPU allocation."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1'}}}%%
flowchart TB
subgraph Input["Incoming Sensors"]
Critical[100 Critical<br/>Safety sensors<br/>Max 100ms latency]
Massive[200 Massive<br/>Monitoring sensors<br/>Delay tolerant]
end
subgraph Processing["Dual-Path Processing"]
Path1[Priority Queue<br/>50% CPU<br/>Reserved]
Path2[Batch Buffer<br/>50% CPU<br/>Best-effort]
end
subgraph Output["Results"]
Fast[100 critical<br/>100ms latency<br/>Met]
Batch[40/200 processed<br/>5s batches<br/>Acceptable]
end
Critical -->|High Priority| Path1 --> Fast
Massive -->|Low Priority| Path2 --> Batch
style Critical fill:#E67E22,stroke:#2C3E50,color:#fff
style Massive fill:#7F8C8D,stroke:#2C3E50,color:#fff
style Path1 fill:#E67E22,stroke:#2C3E50,color:#fff
style Path2 fill:#16A085,stroke:#2C3E50,color:#fff
style Fast fill:#27AE60,stroke:#2C3E50,color:#fff
style Batch fill:#27AE60,stroke:#2C3E50,color:#fff
1323 Edge Review: Power Optimization
1323.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
1323.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)
TipFor 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.1 mA, it lasts 25,000 hours (nearly 3 years)!
1323.3 Power Profile Fundamentals
1323.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 |
1323.3.2 The Power Budget Equation
Average Current = (Active_mA x Active_time + Transmit_mA x Transmit_time + Sleep_mA x Sleep_time) / Total_cycle_time
Battery Life = Battery_Capacity_mAh / Average_Current_mA
1323.4 Deep Sleep Trade-off Analysis
The key question: Is the wake-up penalty worth the sleep savings?
Question: A remote environmental monitoring station uses a 2500 mAh battery. Power profile: active 25 mA, transmit 120 mA, sleep 1 mA, deep sleep 0.01 mA. Current design uses sleep mode (1 mA) between readings. Switching to deep sleep would require 2-second wake-up time (at 25 mA) vs 0.1-second for sleep mode. If readings occur every 10 minutes, should they switch to deep sleep?
Explanation: This deep sleep trade-off analysis is critical for Level 1 Device Power Management.
Current Design - Sleep Mode (1 mA):
Activity per 10-minute cycle (600 seconds):
- Active (sensing): 0.1 seconds at 25 mA
- Transmit: 0.5 seconds at 120 mA
- Sleep: 599.4 seconds at 1 mA
Average current calculation:
I_avg = (25 x 0.1 + 120 x 0.5 + 1 x 599.4) / 600
= (2.5 + 60 + 599.4) / 600
= 661.9 / 600 = 1.103 mASince sleep dominates (599.4 out of 600 seconds), average is approximately 1 mA.
Battery life: 2500 mAh / 1 mA = 2,500 hours = 104 days
Proposed Design - Deep Sleep Mode (0.01 mA):
Activity per 10-minute cycle:
- Wake-up: 2 seconds at 25 mA (penalty)
- Active (sensing): 0.1 seconds at 25 mA
- Transmit: 0.5 seconds at 120 mA
- Deep sleep: 597.4 seconds at 0.01 mA
The dominant term shifts from sleep current to wake-up overhead:
- Wake-up overhead: (50 + 2.5 + 60) / 600 = 0.1875 mA
- Deep sleep contribution: approximately 0.01 mA
- Total: approximately 0.1 mA
Battery life: 2500 mAh / 0.1 mA = 25,000 hours = approximately 2.85 years
For the 24x improvement (6.8 years), the active/transmit times would need to be even shorter, which is achievable with optimized firmware.
The Key Lesson:
For low-duty-cycle IoT (readings every 10+ minutes), the wake-up penalty (2 seconds) is negligible compared to the cumulative sleep savings (598 seconds per cycle x 99% current reduction). Always use deep sleep for infrequent sensing applications.
1323.5 Deep Sleep Decision Matrix
1323.5.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 |
1323.5.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 |
1323.6 Battery Life Comparison
1323.6.1 Scenario: Environmental Monitor
| Parameter | Value |
|---|---|
| Battery capacity | 2500 mAh |
| Sampling interval | 10 minutes |
| Active duration | 0.1 seconds |
| Transmit duration | 0.5 seconds |
| Power Mode | Avg Current | Battery Life | Battery Changes/Year |
|---|---|---|---|
| Always Active (25 mA) | 25 mA | 4 days | 91 |
| Sleep (1 mA) | 1 mA | 104 days | 3.5 |
| Deep Sleep (0.01 mA) | 0.1 mA | 2.85 years | 0.35 |
| Optimized Deep Sleep | 0.04 mA | 6.8 years | 0.15 |
1323.6.2 Cost Impact
For 1000-device deployment over 5 years:
| Mode | Battery Changes | Cost @ $25/replacement |
|---|---|---|
| Sleep (1 mA) | 3.5/year x 1000 x 5 = 17,500 | $437,500 |
| Deep Sleep | 0.35/year x 1000 x 5 = 1,750 | $43,750 |
| Savings | 15,750 fewer replacements | $393,750 |
Plus: Reduced technician visits to remote sites
1323.7 Priority-Based Processing for Mixed Deployments
Industrial facilities often have mixed requirements: some sensors are safety-critical, others are monitoring-only.
Question: An industrial facility has 300 sensors: 100 critical safety sensors (must process 100% of data, latency < 100ms) and 200 non-critical monitoring sensors (can tolerate 20% data loss, latency < 5 seconds). The edge gateway has limited CPU. How should Level 3 evaluation prioritize?
Explanation: This priority-based edge processing addresses Critical IoT vs Massive IoT requirements.
Optimal Architecture - Dual-Path Processing:
The gateway maintains two separate processing paths:
- Critical Queue: Limited size (100 readings), processes immediately with zero buffering delay
- Normal Buffer: Variable size, buffered with adaptive sampling (drops 20% during system overload)
Critical Sensors (100 devices) - Real-Time Path:
- Bypass queue: No buffering delay
- Dedicated CPU allocation: Reserve 50% CPU for critical processing
- Immediate evaluation: Check safety thresholds instantly
- Priority transmission: LoRa high-priority channel or dedicated network
- Guaranteed latency: < 100ms from sensor to decision
Non-Critical Sensors (200 devices) - Best-Effort Path:
- FIFO buffer: 1000-element buffer for smoothing bursts
- Adaptive sampling: During CPU overload, sample 80% (drop 20%)
- Batch processing: Process in groups of 50 every 5 seconds
- Aggregation: Combine into statistical summaries
- Acceptable latency: < 5 seconds, as specified
Why Other Options Fail:
Option B - Single FIFO: Critical sensor at position 150 waits for 100 non-critical sensors. Latency: 100 x 10ms = 1000ms = 1 second. Violates 100ms requirement.
Option C - Round-robin: Critical sensor at position 200 waits for 199 sensors. Latency: 1,990ms. Drops critical data during overload.
Option D - Critical batching: Critical sensor waits for batch of 10 to fill. Worst case: 9 sensors in batch, adds 900ms latency.
The Critical Lesson:
Do not treat all IoT data equally. Safety-critical systems require deterministic latency guarantees, priority CPU allocation, zero data loss, and immediate action on threshold violations.
1323.7.1 Dual-Path Processing Architecture
1323.7.2 Adaptive Sampling Under Load
The system adjusts sampling rates based on CPU utilization:
| CPU Load | Data Retention |
|---|---|
| Low (<50%) | Keep 100% of data |
| Medium (50-70%) | Keep 90% of data |
| High (70-85%) | Keep 80% of data |
| Overload (>85%) | Keep 70% of data |
1323.8 Event-Driven Architecture Benefits
Comparing polling vs event-driven approaches:
| Approach | Description | Battery Life (2500 mAh) |
|---|---|---|
| High-frequency polling | Sample continuously at 10 Hz | 9 days |
| Periodic polling | Sample every 10 minutes | 104 days |
| Event-driven + deep sleep | Wake on threshold events | 686 days (1.88 years) |
| Optimized event-driven | Minimal wake-up overhead | 2,500+ days (6.8 years) |
Event-driven architectures with deep sleep can achieve battery lifetimes of 686 days (1.88 years), compared to just 9 days for high-frequency polling without deep sleep optimization.
1323.9 Chapter Summary
Deep sleep mode (0.01 mA) provides 100x power reduction over regular sleep (1 mA), making the 2-second wake-up penalty negligible for sampling intervals of 10+ minutes.
Battery life calculations show deep sleep extends deployment from 104 days to years, reducing battery replacement costs by $375,000 over 5 years for 1000-device deployments.
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 686+ days battery life compared to 9 days for high-frequency polling.
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.
1323.10 Whatβs Next
Continue to Edge Review: Storage and Economics to learn about tiered storage strategies, ROI calculations, and total cost of ownership analysis for edge computing deployments.
Related chapters in this review series: