%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#2C3E50', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TB
subgraph Compute["Computation (picojoules)"]
C1["32-bit ADD<br/>0.1 pJ"]
C2["32-bit MULTIPLY<br/>3 pJ"]
C3["Floating Point<br/>10 pJ"]
end
subgraph Memory["Memory Access (nanojoules)"]
M1["SRAM Read<br/>10 pJ"]
M2["Flash Read<br/>100 pJ"]
M3["DRAM Access<br/>1-10 nJ"]
end
subgraph IO["I/O Operations (microjoules)"]
I1["GPIO Toggle<br/>1-10 nJ"]
I2["ADC Conversion<br/>100 nJ - 1 µJ"]
I3["Sensor Read<br/>1-100 µJ"]
end
subgraph Wireless["Wireless (millijoules)"]
W1["BLE Packet<br/>10-50 µJ"]
W2["LoRa Packet<br/>1-10 mJ"]
W3["Wi-Fi Packet<br/>10-100 mJ"]
end
C1 --> C2 --> C3
M1 --> M2 --> M3
I1 --> I2 --> I3
W1 --> W2 --> W3
style Compute fill:#16A085,stroke:#2C3E50
style Memory fill:#27AE60,stroke:#2C3E50
style IO fill:#E67E22,stroke:#2C3E50
style Wireless fill:#E74C3C,stroke:#2C3E50
1602 Energy Cost of Common Operations
1602.1 Learning Objectives
By the end of this chapter, you will be able to:
- Quantify energy costs for digital operations (computation, memory access)
- Compare energy requirements across different operations
- Apply the “million-to-one” rule for IoT energy optimization
- Make informed decisions about local processing vs. transmission
- Understand the battery technology gap and its implications
1602.2 Energy Cost of Common Operations
Understanding the energy cost of individual operations helps prioritize optimization efforts. The differences span multiple orders of magnitude.
1602.2.1 Digital Operations Energy Hierarchy
1602.2.2 Detailed Operation Costs
| Operation | Energy | Relative Cost |
|---|---|---|
| Computation | ||
| 32-bit integer add | 0.1 pJ | 1× |
| 32-bit integer multiply | 3 pJ | 30× |
| 32-bit floating point op | 10 pJ | 100× |
| AES-128 encryption (16 bytes) | 100 nJ | 1,000,000× |
| Memory Access | ||
| SRAM read (32-bit) | 10 pJ | 100× |
| Flash read (32-bit) | 100 pJ | 1,000× |
| DRAM access (32-bit) | 3 nJ | 30,000× |
| Flash write (32-bit) | 10 nJ | 100,000× |
| I/O and Sensing | ||
| GPIO toggle | 5 nJ | 50,000× |
| 12-bit ADC conversion | 500 nJ | 5,000,000× |
| Temperature sensor read | 10 µJ | 100,000,000× |
| Wireless Communication | ||
| BLE advertising packet | 30 µJ | 300,000,000× |
| LoRa packet (SF7) | 2 mJ | 20,000,000,000× |
| Wi-Fi packet (with connect) | 50 mJ | 500,000,000,000× |
1602.2.3 The Million-to-One Rule
Key Insight: Transmitting 1 byte over wireless costs approximately the same energy as 1 million 32-bit CPU operations.
This fundamental ratio has profound implications:
- Always process locally when possible - Filtering, aggregation, and compression before transmission saves tremendous energy
- Minimize payload size - Every byte costs as much as millions of operations
- Batch transmissions - Amortize connection overhead over multiple readings
- Use delta encoding - Send only changes, not absolute values
- Consider compression - Even expensive algorithms save energy if they reduce TX bytes significantly
1602.2.4 Communication vs. Computation Trade-off
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#2C3E50', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart LR
subgraph Input["Raw Data"]
D1["1000 bytes<br/>sensor readings"]
end
subgraph Option1["Option A: Transmit Raw"]
T1["TX 1000 bytes<br/>~50 mJ"]
end
subgraph Option2["Option B: Process + Transmit"]
P1["Filter/Aggregate<br/>10,000 operations<br/>~0.1 µJ"]
T2["TX 50 bytes<br/>~2.5 mJ"]
end
Input --> Option1
Input --> P1 --> T2
style Input fill:#7F8C8D,stroke:#2C3E50
style Option1 fill:#E74C3C,stroke:#2C3E50
style Option2 fill:#16A085,stroke:#2C3E50
Example: Smart Agriculture Sensor
| Approach | Processing | Transmission | Total Energy |
|---|---|---|---|
| Raw data (60 readings/hour) | 0 | 60 × 50 µJ = 3 mJ | 3 mJ |
| Local average (1 value/hour) | 60 × 10 pJ = 0.6 nJ | 1 × 50 µJ = 50 µJ | 50 µJ |
| Energy saved | 60× |
Example: Motion Detection Camera
| Approach | Processing | Transmission | Total Energy |
|---|---|---|---|
| Stream all frames (10 fps) | 0 | 10 × 100 KB × 8 = 8 Mbps | 800 mW |
| Edge detection + TX changes | 10 ms × 50 mA = 0.5 mJ/frame | 1 KB when motion | 5.5 mW |
| Energy saved | 145× |
1602.3 The Battery Technology Gap in Numbers
Battery energy density improves slowly compared to computing:
| Decade | Transistor Density | Battery Energy Density | Ratio |
|---|---|---|---|
| 1990 | 1× | 1× | 1:1 |
| 2000 | 100× | 1.5× | 67:1 |
| 2010 | 10,000× | 2× | 5,000:1 |
| 2020 | 1,000,000× | 3× | 333,333:1 |
Implication: Software cannot assume energy abundance. Every new feature must be evaluated against its energy cost.
1602.3.1 Why This Matters for IoT
1990s laptop: 10W power budget, plenty for full functionality
2020s IoT sensor: 10µW average budget, every operation counts
1 hour of IoT sensor operation uses less energy than
1 second of laptop operation in the 1990s
1602.4 Energy-Efficient Coding Practices
1602.4.1 Compiler Optimization Flags
| Flag | Description | Energy Impact |
|---|---|---|
-O0 |
No optimization | Baseline (slowest, most energy) |
-O1 |
Basic optimization | 20-40% reduction |
-O2 |
Standard optimization | 40-60% reduction |
-O3 |
Aggressive optimization | 50-70% reduction (larger code) |
-Os |
Optimize for size | 40-60% reduction, better cache usage |
-Ofast |
Fastest execution | 60-80% reduction (may break IEEE floats) |
Recommendation for IoT: Use -Os when code size matters (flash-constrained), -O2 otherwise. Avoid -O3 on memory-limited devices as larger code may cause cache thrashing.
1602.4.2 Algorithm Selection
// BAD: O(n²) bubble sort - energy proportional to n²
void bubble_sort(int arr[], int n) {
for (int i = 0; i < n-1; i++)
for (int j = 0; j < n-i-1; j++)
if (arr[j] > arr[j+1])
swap(&arr[j], &arr[j+1]);
}
// BETTER: O(n log n) quicksort - energy proportional to n log n
// For n=1000: bubble=1,000,000 ops, quicksort=10,000 ops = 100× savings
// BEST for IoT: Don't sort at all - send summary statistics
// Max, min, average require O(n) = 1,000 ops = 1000× savings vs bubble1602.4.3 Data Type Selection
| Type | Size | Operations Energy |
|---|---|---|
| uint8_t | 1 byte | 1× (baseline) |
| uint16_t | 2 bytes | 1.2-1.5× |
| uint32_t | 4 bytes | 1.5-2× |
| float | 4 bytes | 10-20× |
| double | 8 bytes | 20-40× |
Recommendation: Use smallest sufficient data type. Fixed-point arithmetic instead of floating-point where precision permits.
1602.4.4 Worked Example: Energy Cost of Different Averaging Methods
Scenario: Calculate average of 100 temperature readings
Method 1: Floating Point
float sum = 0.0f;
for (int i = 0; i < 100; i++) {
sum += (float)readings[i]; // 100 float adds = 1000 pJ
}
float avg = sum / 100.0f; // 1 float divide = 20 pJ
// Total: ~1020 pJMethod 2: Integer with Final Division
int32_t sum = 0;
for (int i = 0; i < 100; i++) {
sum += readings[i]; // 100 int adds = 10 pJ
}
int16_t avg = sum / 100; // 1 int divide = 10 pJ
// Total: ~20 pJ (50× more efficient!)Method 3: Bit-Shift Division (power of 2)
int32_t sum = 0;
for (int i = 0; i < 128; i++) { // Use 128 samples
sum += readings[i]; // 128 int adds = 13 pJ
}
int16_t avg = sum >> 7; // Shift = 1 pJ
// Total: ~14 pJ (70× more efficient than float!)1602.5 Wireless Camera Power Analysis
1602.5.1 Worked Example: Wireless Camera Power Analysis
Scenario: You are designing a wildlife camera that must operate for 6 months on 4× D batteries (8000 mAh total). The camera should capture and transmit images when motion is detected.
Given:
- Camera module: OV2640 (50mA active, 20µA standby)
- PIR motion sensor: 10µA continuous
- MCU: ESP32 (80mA active with image processing, 10µA deep sleep)
- Wi-Fi transmission: 200mA average during TX
- Expected motion events: 20 per day average
- Image size: 640×480 JPEG = 50KB compressed
Analysis:
Continuous loads (per day):
PIR sensor: 10µA × 24h = 0.24 mAh ESP32 deep sleep: 10µA × 24h = 0.24 mAh Camera standby: 20µA × 24h = 0.48 mAh Daily base: 0.96 mAhPer-event energy (20 events/day):
Wake from sleep: 80mA × 0.1s = 8 mAs Camera capture: 50mA × 0.5s = 25 mAs Image processing: 80mA × 0.3s = 24 mAs Wi-Fi connect: 160mA × 3s = 480 mAs Wi-Fi transmit: 200mA × 4s (50KB @ 100kbps) = 800 mAs Per event: 1,337 mAs = 0.37 mAh Daily events: 20 × 0.37 = 7.4 mAhTotal daily consumption:
Base load: 0.96 mAh Motion events: 7.4 mAh Total: 8.36 mAh/dayBattery life calculation:
Available: 8000 mAh × 0.7 (efficiency) = 5,600 mAh Life: 5,600 / 8.36 = 670 days = 22 months
Result: Design exceeds 6-month target with 4× margin.
Optimization opportunities if battery size needs reduction:
- Use LoRa instead of Wi-Fi (10× less TX energy, but slower)
- Reduce image resolution (320×240 = 4× smaller)
- Transmit only when motion is “interesting” (AI classification)
- Use edge computing to detect false positives (leaves, shadows)
1602.6 Energy Calculation Worksheets
1602.6.1 Worksheet: Solar-Powered Environmental Sensor
Design a solar-powered outdoor sensor with these requirements:
Given:
- Location: Seattle, WA (48°N latitude)
- Data transmission: Every 5 minutes via LoRa
- Sensors: Temperature, humidity, barometric pressure
- Autonomy required: 7 days without sun (cloudy winter)
Your Task: Size the solar panel and battery
Step 1: Calculate daily energy consumption
MCU active (reading + TX): 50mA × 2s × 288 readings = 28,800 mAs = 8 mAh
MCU deep sleep: 10µA × 86,400s = 864 mAs = 0.24 mAh
LoRa TX: 40mA × 0.5s × 288 = 5,760 mAs = 1.6 mAh
Sensors: 5mA × 0.5s × 288 = 720 mAs = 0.2 mAh
Daily total: _______ mAh
Step 2: Calculate battery size for 7-day autonomy
7-day energy: _______ mAh
With 80% DoD: _______ mAh battery required
Step 3: Calculate solar panel size
Seattle winter: ~2 hours equivalent full sun per day
Daily harvest needed: _______ mAh × 1.5 (margin) = _______ mAh
Panel current required: _______ mAh / 2h = _______ mA
At 6V panel: _______ mA × 6V = _______ mW panel
1602.6.2 Worksheet: Multi-Protocol Power Comparison
Compare three connectivity options for an indoor asset tracker:
| Metric | Wi-Fi | BLE | Zigbee |
|---|---|---|---|
| TX current | 180 mA | 15 mA | 20 mA |
| Connection time | 3 s | 0 s | 0.1 s |
| TX time per packet | 50 ms | 5 ms | 10 ms |
| Sleep current | 10 µA | 1 µA | 2 µA |
| Range | 30m | 10m | 30m |
Calculate energy per transmission:
Wi-Fi: (180mA × 3s) + (180mA × 0.05s) = ______ mAs
BLE: (15mA × 0.005s) = ______ mAs
Zigbee: (20mA × 0.1s) + (20mA × 0.01s) = ______ mAs
For 100 transmissions per day, calculate daily energy:
Wi-Fi: ______ mAs × 100 + (10µA × 86,400s) = ______ mAs
BLE: ______ mAs × 100 + (1µA × 86,400s) = ______ mAs
Zigbee: ______ mAs × 100 + (2µA × 86,400s) = ______ mAs
Calculate battery life with 1000 mAh:
Wi-Fi: _______ hours = _______ days
BLE: _______ hours = _______ days
Zigbee: _______ hours = _______ days
1602.7 The Amortization Advantage
1602.7.1 Energy-per-Bit: The Amortization Advantage
Batching transmissions amortizes connection overhead:
| Scenario | Energy | Energy per Byte |
|---|---|---|
| Wi-Fi: 1 byte, 1 connection | 540 mAs | 540 mAs/byte |
| Wi-Fi: 100 bytes, 1 connection | 550 mAs | 5.5 mAs/byte |
| Wi-Fi: 1000 bytes, 1 connection | 650 mAs | 0.65 mAs/byte |
| LoRa: 1 byte | 20 mAs | 20 mAs/byte |
| LoRa: 100 bytes | 80 mAs | 0.8 mAs/byte |
| BLE: 1 byte | 0.075 mAs | 0.075 mAs/byte |
| BLE: 20 bytes (max packet) | 0.1 mAs | 0.005 mAs/byte |
Key insight: For Wi-Fi, sending 1000 bytes is 830× more efficient per byte than sending 1 byte. Always batch!
1602.8 Knowledge Check
Question 1: According to the “million-to-one” rule, transmitting 1 byte over wireless costs approximately the same energy as how many CPU operations?
The million-to-one rule states that transmitting 1 byte costs approximately 1 million 32-bit CPU operations worth of energy. This is why local processing and filtering before transmission is so critical for IoT energy efficiency.
Question 2: When should you prefer local processing over cloud offloading for an IoT sensor?
Local processing saves energy when it reduces transmission volume. Since transmission costs ~1 million× more energy per byte than computation, even complex local processing is worthwhile if it reduces payload by 10× or more. The break-even point is typically around 100-1000 operations per byte saved.
1602.9 Summary
Key takeaways from energy cost analysis:
- The Million-to-One Rule: Wireless transmission costs ~1 million CPU operations per byte
- Process Locally: Filtering, aggregation, and compression save significant energy
- Battery Gap is Real: Computing advances 100,000× faster than battery technology
- Batch Transmissions: Amortize connection overhead over multiple data points
- Choose Algorithms Wisely: O(n²) vs O(n) makes enormous difference in energy consumption
- Use Appropriate Data Types: Smaller types and fixed-point math save energy
1602.10 What’s Next
Continue to Low-Power Design Strategies to learn practical techniques for reducing power consumption in IoT devices.