841  Wi-Fi Power Consumption and Battery Optimization

Prerequisites: Wi-Fi Standards Evolution | Wi-Fi Frequency Bands

This enables: Wi-Fi Deployment Planning | Power Management Strategies

841.1 Learning Objectives

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

• Calculate power consumption for Wi-Fi IoT devices
• Compare Wi-Fi power consumption with other wireless protocols
• Optimize Wi-Fi settings for battery-powered devices
• Understand Wi-Fi 6 TWT benefits and limitations
• Make informed protocol decisions based on power requirements
• Design power budgets for battery-operated Wi-Fi sensors

841.2 The Wi-Fi Power Challenge

Wi-Fi was designed for laptops and phones with large batteries and frequent charging. For IoT sensors that need to run for years on batteries, Wi-Fi presents significant challenges:

Factor	Wi-Fi	BLE	Zigbee	LoRaWAN
TX Current	200-300 mA	10-15 mA	25-35 mA	40-120 mA
RX Current	100-150 mA	10-15 mA	20-25 mA	10-15 mA
Sleep Current	10-150 uA	1-2 uA	1-2 uA	1-2 uA
Connection Time	2-10 sec	20-50 ms	20-50 ms	<1 sec
Battery Life (sensor)**	3-12 months	2-5 years	2-5 years	5-10 years

*Approximate, sending 100 bytes every 15 minutes on 3000 mAh battery

WarningKey Insight

Wi-Fi’s power problem isn’t the transmission - it’s the connection overhead.

A Wi-Fi device sending 100 bytes: - BLE: Wake up, TX for 2ms, sleep = ~0.02 mAh - Wi-Fi: Wake up, associate (2-5s), TX for 2ms, sleep = ~0.15-0.4 mAh

Wi-Fi uses 10-20x more energy per transmission for the same payload!

841.3 Wi-Fi Power States

Understanding power states is crucial for optimization:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1', 'fontSize': '12px'}}}%%
stateDiagram-v2
    [*] --> DeepSleep: Power on

    DeepSleep --> Connecting: Wake trigger
    note right of DeepSleep: 10 uA<br/>Wi-Fi OFF

    Connecting --> Active: Associated
    note right of Connecting: 160 mA<br/>2-10 seconds

    Active --> ModemSleep: No traffic
    note right of Active: 120-200 mA<br/>TX/RX active

    ModemSleep --> Active: Traffic detected
    note right of ModemSleep: 15-20 mA<br/>Wi-Fi connected

    ModemSleep --> LightSleep: PS-Poll enabled
    note right of LightSleep: 0.8-2 mA<br/>Beacon tracking

    LightSleep --> ModemSleep: Data buffered
    LightSleep --> DeepSleep: Disconnect

    Active --> DeepSleep: Disconnect
    ModemSleep --> DeepSleep: Timeout

Figure 841.1: Wi-Fi power states from Deep Sleep (10 uA) through Active mode (200 mA)

841.3.1 Power State Details (ESP32 Example)

State	Current	Description	Wake Time
Deep Sleep	10 uA	CPU off, Wi-Fi off, RTC only	100-200 ms
Light Sleep	0.8-2 mA	CPU paused, Wi-Fi tracking beacons	1-10 ms
Modem Sleep	15-20 mA	CPU active, Wi-Fi listening	Instant
Active RX	100-150 mA	Receiving data	-
Active TX	200-300 mA	Transmitting data	-
Connecting	150-200 mA	Scanning + associating	2-10 sec

841.4 Calculating Battery Life

841.4.1 Step-by-Step Calculation

Scenario: ESP32 temperature sensor sending 100 bytes every 15 minutes

Power Budget Calculation:

GIVEN:
- Battery: 2 x AA (3000 mAh @ 3V)
- Transmission interval: 15 minutes (96 times/day)
- Payload: 100 bytes
- Wi-Fi module: ESP32 (Wi-Fi 4)

STEP 1: Deep Sleep Time
- 23 hours 52 minutes per day in deep sleep
- Current: 10 uA
- Daily usage: 23.87h x 0.01mA = 0.24 mAh/day

STEP 2: Connection Overhead
- Time to connect: 3 seconds average
- Current during connect: 160 mA
- Per connection: 160mA x 3s / 3600 = 0.133 mAh
- Daily (96 connections): 0.133 x 96 = 12.8 mAh/day

STEP 3: Data Transmission
- TX time: 5 ms per 100 bytes
- Current: 200 mA
- Per transmission: 200mA x 0.005s / 3600 = 0.00028 mAh
- Daily: 0.00028 x 96 = 0.027 mAh/day (negligible!)

STEP 4: Total Daily Consumption
- Deep sleep: 0.24 mAh
- Connecting: 12.8 mAh
- Transmitting: 0.03 mAh
- TOTAL: 13.07 mAh/day

STEP 5: Battery Life
- Battery: 3000 mAh
- Daily usage: 13.07 mAh
- Battery life: 3000 / 13.07 = 230 days (7.6 months)

ImportantKey Observation

98% of power is spent on connection overhead, not data transmission!

• Connection: 12.8 mAh/day (98%)
• Actual TX: 0.03 mAh/day (0.2%)
• Sleep: 0.24 mAh/day (1.8%)

Optimization strategy: Reduce connection events, not transmission time.

841.5 Wi-Fi 6 TWT: The Battery Saver

841.5.1 How TWT Changes the Equation

Without TWT (Wi-Fi 4/5):

Device must wake for every beacon (every 100ms typically)
- Beacon wakeups: ~864,000/day
- Even with DTIM skip, still ~100,000 wakeups/day
- Each wakeup: 1-5 ms at 15-20 mA
- Idle listening overhead: 5-15 mAh/day

With TWT (Wi-Fi 6):

Device negotiates specific wake times with AP
- Wake only when scheduled (e.g., 4x/day)
- AP buffers all data until wake window
- No beacon listening required between sessions
- Idle overhead: <0.1 mAh/day

841.5.2 TWT Battery Impact Example

Scenario	Without TWT	With TWT	Improvement
Sensor (4 readings/day)	6 months	5+ years	10x
Door sensor (event-based)	3 months	2+ years	8x
Thermostat (hourly)	4 months	3 years	9x
Camera (continuous)	Same	Same	0x

WarningTWT Requirements

TWT only works when: 1. Access Point supports Wi-Fi 6 (802.11ax) 2. IoT device has Wi-Fi 6 chip 3. Both have TWT enabled in firmware 4. Device workload allows scheduled wake times

Current ESP32 TWT Support: - ESP32 (original): No Wi-Fi 6 - no TWT - ESP32-S2, S3, C3: No Wi-Fi 6 - no TWT - ESP32-C6: Wi-Fi 6 - TWT supported!

841.6 Protocol Comparison for Battery IoT

841.6.1 Detailed Power Comparison

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1', 'fontSize': '12px'}}}%%
graph TB
    subgraph WIFI["Wi-Fi (802.11n)"]
        W1[TX: 200-300 mA]
        W2[Connect: 2-10 sec]
        W3[Energy/TX: 400-800 mJ]
        W4[Battery Life: 3-12 months]
    end

    subgraph BLE["BLE (Bluetooth 5)"]
        B1[TX: 10-15 mA]
        B2[Connect: 20-50 ms]
        B3[Energy/TX: 0.5-2 mJ]
        B4[Battery Life: 2-5 years]
    end

    subgraph ZIGBEE["Zigbee"]
        Z1[TX: 25-35 mA]
        Z2[Connect: 20-50 ms]
        Z3[Energy/TX: 1-3 mJ]
        Z4[Battery Life: 2-5 years]
    end

    subgraph LORA["LoRaWAN"]
        L1[TX: 40-120 mA]
        L2[Connect: <1 sec]
        L3[Energy/TX: 30-100 mJ]
        L4[Battery Life: 5-10 years]
    end

    style WIFI fill:#E74C3C,stroke:#2C3E50,stroke-width:2px
    style BLE fill:#16A085,stroke:#2C3E50,stroke-width:2px
    style ZIGBEE fill:#16A085,stroke:#2C3E50,stroke-width:2px
    style LORA fill:#27AE60,stroke:#2C3E50,stroke-width:2px

Figure 841.2: Power consumption comparison: Wi-Fi vs BLE vs Zigbee vs LoRaWAN

841.6.2 Decision Matrix

Requirement	Best Protocol	Avoid
Battery life >2 years	BLE, Zigbee, LoRaWAN	Wi-Fi (unless Wi-Fi 6 TWT)
High bandwidth (>1 Mbps)	Wi-Fi	LoRaWAN, Sigfox
Long range (>1 km)	LoRaWAN, Sigfox	Wi-Fi, BLE
Low latency (<100 ms)	Wi-Fi, BLE	LoRaWAN
Mesh networking	Zigbee, Thread	Wi-Fi (without mesh)
Existing infrastructure	Wi-Fi	LoRaWAN (needs gateway)

841.7 Power Optimization Strategies

841.7.1 Strategy 1: Batch Transmissions

Instead of sending each reading immediately, batch multiple readings:

BEFORE (send every 5 min):
- 288 connections/day
- 288 x 0.133 mAh = 38.3 mAh/day

AFTER (batch hourly, 12 readings at once):
- 24 connections/day
- 24 x 0.133 mAh = 3.2 mAh/day

IMPROVEMENT: 12x better battery life!

841.7.2 Strategy 2: Static IP Instead of DHCP

DHCP adds 0.5-2 seconds to connection time:

BEFORE (DHCP):
- Connection time: 4 seconds
- Energy: 4s x 160mA = 0.178 mAh per connection

AFTER (Static IP):
- Connection time: 2.5 seconds
- Energy: 2.5s x 160mA = 0.111 mAh per connection

IMPROVEMENT: 38% energy savings

841.7.3 Strategy 3: Reduce TX Power

Many devices default to maximum TX power. Reducing it saves energy:

ESP32 TX Power Settings:
- +20 dBm (max): 200 mA
- +15 dBm: 160 mA (-20%)
- +10 dBm: 120 mA (-40%)
- +5 dBm: 80 mA (-60%)

Trade-off: Lower power = shorter range
Use minimum power that maintains reliable connection

841.7.4 Strategy 4: Light Sleep Between Transmissions

For devices sending multiple packets per session:

// Instead of staying in active mode between packets
void sendMultipleReadings() {
    for (int i = 0; i < 10; i++) {
        sendReading(i);
        // Bad: busy wait
        // delay(100);  // 20 mA for 100ms

        // Good: light sleep
        esp_light_sleep_start();  // 0.8 mA for 100ms
        // 25x less power between packets!
    }
}

841.7.5 Strategy 5: Use Wi-Fi 6 TWT (When Available)

For ESP32-C6 or other Wi-Fi 6 devices:

// Enable TWT in ESP32-C6
wifi_config_t wifi_config = {
    .sta = {
        // ... SSID and password
        .twt = {
            .twt_enable = true,
            .twt_wake_interval = 300,  // Wake every 5 minutes
            .twt_wake_duration = 5,    // Stay awake 5 TUs
        }
    }
};

841.8 Knowledge Check

{
  const container = document.getElementById('kc-power-1');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "An agricultural IoT company deploys 100 soil moisture sensors across a 50-acre farm. Each sensor sends 100 bytes every 15 minutes. Sensors are solar-powered with 3000 mAh battery backup. The company chose Wi-Fi because 'everyone knows Wi-Fi.' What is the PRIMARY problem with this choice?",
      options: [
        {text: "Wi-Fi has insufficient bandwidth for 100-byte payloads", correct: false, feedback: "Incorrect. Wi-Fi has orders of magnitude more bandwidth than needed. 100 bytes every 15 minutes is trivial for any Wi-Fi standard."},
        {text: "Wi-Fi connection overhead drains battery 10-20x faster than LPWAN alternatives", correct: true, feedback: "Correct! Wi-Fi's 2-10 second connection establishment uses 200-800 mJ per transmission versus 30-100 mJ for LoRaWAN or <2 mJ for BLE. On cloudy days when solar can't keep up, the battery backup will drain in weeks instead of months."},
        {text: "Wi-Fi range of 50-100m cannot cover 50 acres without hundreds of APs", correct: false, feedback: "This is also a problem, but not the PRIMARY one. While coverage would require many APs, the question focuses on power consumption which is the fundamental mismatch."},
        {text: "Wi-Fi security is insufficient for agricultural data", correct: false, feedback: "Incorrect. WPA2/WPA3 provides excellent security. Security is not the limiting factor for this use case."}
      ],
      difficulty: "medium",
      topic: "wifi-power"
    }));
  }
}

{
  const container = document.getElementById('kc-power-2');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A developer is optimizing a Wi-Fi temperature sensor's battery life. Currently it sends readings every 5 minutes (288/day). They propose batching 12 readings per hour (24 transmissions/day). Assuming connection overhead dominates power consumption, what improvement should they expect?",
      options: [
        {text: "12% improvement (12 fewer readings per batch)", correct: false, feedback: "Incorrect. The improvement comes from fewer connections, not fewer data bytes. Each connection costs the same regardless of payload size."},
        {text: "50% improvement (half the total data)", correct: false, feedback: "Incorrect. Data transmission energy is negligible compared to connection overhead. Sending 12 readings uses almost the same energy as sending 1."},
        {text: "Approximately 10-12x improvement (1/12 the connections)", correct: true, feedback: "Correct! If connection overhead dominates (98% of power), reducing from 288 to 24 connections/day gives roughly 12x battery life improvement. The extra payload per connection is negligible."},
        {text: "No improvement - same total data transferred", correct: false, feedback: "Incorrect. The key insight is that connection establishment (2-10 seconds at 160 mA) uses far more energy than data transmission (milliseconds at 200 mA)."}
      ],
      difficulty: "medium",
      topic: "power-optimization"
    }));
  }
}

841.9 Worked Example: Power Budget Analysis

Scenario: Design a battery-powered Wi-Fi environmental sensor with 2-year target battery life.

Requirements: - Temperature + humidity reading every 30 minutes - 2 x AA batteries (3000 mAh) - Wi-Fi 4 module (no TWT) - Target: 2 years minimum battery life

Analysis:

STEP 1: Power Budget (2 years)
- Available: 3000 mAh
- Duration: 730 days
- Daily budget: 3000 / 730 = 4.1 mAh/day

STEP 2: Current Wi-Fi Design (every 30 min)
- Transmissions: 48/day
- Per transmission (3s connect + 5ms TX):
  - Connect: 3s x 160mA = 480mAs = 0.133 mAh
  - TX: 0.005s x 200mA = 1mAs = 0.0003 mAh
  - Total: 0.133 mAh
- Daily: 48 x 0.133 = 6.4 mAh/day

PROBLEM: 6.4 mAh/day > 4.1 mAh budget!
Expected life: 3000/6.4 = 469 days (1.3 years)

Solution Options:

Option	Change	New Daily Usage	Battery Life
Baseline	Every 30 min	6.4 mAh	1.3 years
Batch hourly	24 TX/day	3.2 mAh	2.6 years
Batch 2-hourly	12 TX/day	1.6 mAh	5.1 years
Use BLE instead	N/A	0.3 mAh	27 years
Wi-Fi 6 + TWT	Scheduled wake	1.2 mAh	6.8 years

Recommendation: - For Wi-Fi constraint: Batch readings every 2 hours - Better solution: Use BLE beacon or Zigbee for this use case - If Wi-Fi required: Upgrade to Wi-Fi 6 device with TWT

841.10 Wi-Fi vs Alternatives: When to Choose What

841.10.1 Summary Flowchart

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#ecf0f1', 'fontSize': '11px'}}}%%
flowchart TD
    START[What type of IoT device?]

    START --> POWER{Power Source?}

    POWER -->|Mains/USB| MAINS[Wall-powered device]
    POWER -->|Battery| BATT{Battery Life Goal?}

    MAINS --> MAINS_BW{Bandwidth Need?}
    MAINS_BW -->|>1 Mbps| WIFI_OK[Wi-Fi - Ideal]
    MAINS_BW -->|<1 Mbps| MAINS_INFRA{Existing Wi-Fi?}
    MAINS_INFRA -->|Yes| WIFI_CONV[Wi-Fi - Convenient]
    MAINS_INFRA -->|No| CONSIDER_OTHER[Consider Zigbee/Thread]

    BATT -->|<1 year OK| SHORT_BATT[Short battery life acceptable]
    BATT -->|2-5 years| MEDIUM_BATT[Multi-year requirement]
    BATT -->|>5 years| LONG_BATT[Ultra-long life]

    SHORT_BATT --> WIFI_TWT{Wi-Fi 6 Available?}
    WIFI_TWT -->|Yes + TWT| WIFI6[Wi-Fi 6 with TWT]
    WIFI_TWT -->|No| WIFI_LEGACY[Wi-Fi 4/5 - Limited]

    MEDIUM_BATT --> RANGE{Range Needed?}
    RANGE -->|<100m| BLE_ZIG[BLE or Zigbee]
    RANGE -->|100m-1km| WIFI_HALOW[Wi-Fi HaLow or Thread]
    RANGE -->|>1km| LORA_CELL[LoRaWAN or LTE-M]

    LONG_BATT --> ULTRA_RANGE{Range?}
    ULTRA_RANGE -->|Short| LORA_ULP[LoRaWAN (Class A)]
    ULTRA_RANGE -->|Long| SIGFOX[Sigfox or NB-IoT]

    style WIFI_OK fill:#16A085,stroke:#2C3E50,stroke-width:3px,color:#fff
    style WIFI_CONV fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style WIFI6 fill:#27AE60,stroke:#2C3E50,stroke-width:2px,color:#fff
    style WIFI_LEGACY fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style BLE_ZIG fill:#3498DB,stroke:#2C3E50,stroke-width:2px,color:#fff
    style LORA_CELL fill:#9B59B6,stroke:#2C3E50,stroke-width:2px,color:#fff
    style LORA_ULP fill:#9B59B6,stroke:#2C3E50,stroke-width:2px,color:#fff

Figure 841.3: Protocol selection flowchart based on power requirements and use case

841.10.2 Quick Reference Table

Use Case	Power Source	Recommended	Avoid
Security camera	Mains	Wi-Fi 5/6	LPWAN
Smart thermostat	Mains/battery	Wi-Fi or Zigbee	LoRaWAN
Door/window sensor	Battery (5+ years)	Zigbee, Z-Wave	Wi-Fi 4/5
Soil moisture sensor	Solar + battery	LoRaWAN, BLE	Wi-Fi
Wearable fitness	Battery (1 week)	BLE	Wi-Fi
Industrial pressure	Mains	Wi-Fi 6	-
Smart meter	Battery (10 years)	LoRaWAN, NB-IoT	Wi-Fi, BLE

841.11 What’s Next

Continue to Wi-Fi Deployment Planning to learn about capacity planning, common deployment mistakes, and real-world case studies for Wi-Fi IoT implementations.

NoteRelated Chapters

• Wi-Fi Overview - Introduction and basics
• Wi-Fi Standards Evolution - 802.11 generations
• Wi-Fi Frequency Bands - Channel planning
• Wi-Fi Deployment Planning - Capacity and case studies
• Power Management - General power optimization