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

%%{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

Figure 1602.1: Energy hierarchy showing orders of magnitude difference between operation types

1602.2.2 Detailed Operation Costs

Operation Energy Relative Cost
Computation
32-bit integer add 0.1 pJ
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

ImportantThe 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:

  1. Always process locally when possible - Filtering, aggregation, and compression before transmission saves tremendous energy
  2. Minimize payload size - Every byte costs as much as millions of operations
  3. Batch transmissions - Amortize connection overhead over multiple readings
  4. Use delta encoding - Send only changes, not absolute values
  5. 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

Figure 1602.2: Comparison showing how local processing dramatically reduces total energy consumption

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
2000 100× 1.5× 67:1
2010 10,000× 5,000:1
2020 1,000,000× 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 bubble

1602.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 pJ

Method 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:

  1. 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 mAh
  2. Per-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 mAh
  3. Total daily consumption:

    Base load: 0.96 mAh
    Motion events: 7.4 mAh
    Total: 8.36 mAh/day
  4. Battery 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:

  1. The Million-to-One Rule: Wireless transmission costs ~1 million CPU operations per byte
  2. Process Locally: Filtering, aggregation, and compression save significant energy
  3. Battery Gap is Real: Computing advances 100,000× faster than battery technology
  4. Batch Transmissions: Amortize connection overhead over multiple data points
  5. Choose Algorithms Wisely: O(n²) vs O(n) makes enormous difference in energy consumption
  6. 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.