45  Wi-Fi Power Optimization

In 60 Seconds

Wi-Fi power optimization transforms battery life from hours to years. Active Wi-Fi TX draws 120-260 mA (8-17 hours on 2000 mAh), while deep sleep drops to 10 uA (2.3 years). Key strategies: deep sleep between transmissions (2000x idle current reduction), static IP to skip DHCP (saves 1.7 seconds per connection), reduced TX power when close to AP (up to 60% savings), and batching readings. A worked example shows a vineyard sensor achieving 18.7 months on 2xAA batteries using deep sleep + static IP (93x improvement over always-on Wi-Fi). Wi-Fi 6 TWT eliminates beacon listening entirely, enabling 6.7-year battery life for occupancy sensors.

Sensor Squad: Power Optimization

Bella the Battery had a BIG problem – Wi-Fi was draining her too fast!

“With always-on Wi-Fi, I lasted only 6 DAYS on 3000 mAh,” Bella sighed. “Active Wi-Fi drinks 20 milliamps even when just LISTENING. That is like leaving a faucet running all day!”

Max the Microcontroller had a plan: “We use DEEP SLEEP! Instead of keeping Wi-Fi on all the time, you wake up, connect quickly, send your data, and go back to sleep. Deep sleep uses only 10 microamps – that is 2000 times less than modem sleep!”

“But connecting takes 3 seconds with DHCP,” worried Sammy the Sensor. Max smiled: “We use a STATIC IP address! Instead of asking the router ‘What is my address?’ every time (which takes 2.5 seconds), we already know our address. Connection drops to 0.8 seconds!”

Bella did the math: “With deep sleep + static IP, sending every 15 minutes, I use only 4.27 mAh per day. My 3000 mAh battery now lasts 562 DAYS – that is 18.7 months! From 6 days to 562 days, a 93x improvement!”

“And when we upgrade to Wi-Fi 6 with TWT,” added Lila the LED, “the router tells us EXACTLY when to wake up, so we never waste energy listening for beacons. That could mean 6+ YEARS of battery life!”

Putting Numbers to It

Deep sleep battery life calculation:

For a sensor reporting every 15 minutes (96 times/day) using 2×AA batteries (3000 mAh at 3.3V):

Daily energy consumption:

\[E_{daily} = E_{sleep} + E_{connect} + E_{transmit}\]

Deep sleep energy:

• Time in deep sleep: \(24\ \text{h} - 96 \times 3\ \text{s} = 24\ \text{h} - 288\ \text{s} = 23.92\ \text{h}\)
• Current: 10 μA \[E_{sleep} = 23.92\ \text{h} \times 0.01\ \text{mA} = 0.239\ \text{mAh}\]

Connection energy (with DHCP):

• Time per connection: 2.5 seconds
• Current: 160 mA \[E_{connect} = 96 \times 2.5\ \text{s} \times 160\ \text{mA} \times \frac{1}{3600} = 10.67\ \text{mAh}\]

Transmission energy:

• Time per transmission: 0.5 seconds
• Current: 120 mA \[E_{transmit} = 96 \times 0.5\ \text{s} \times 120\ \text{mA} \times \frac{1}{3600} = 1.6\ \text{mAh}\]

Total daily: \(E_{daily} = 0.239 + 10.67 + 1.6 = 12.51\ \text{mAh/day}\)

Battery life (80% depth of discharge): \[\text{Life} = \frac{3000 \times 0.8}{12.51} \approx 192\ \text{days} \approx 6.3\ \text{months}\]

With static IP (0.8s connection): \[E_{connect} = 96 \times 0.8 \times 160 \times \frac{1}{3600} = 3.41\ \text{mAh}\] \[E_{daily} = 0.239 + 3.41 + 1.6 = 5.25\ \text{mAh/day}\] \[\text{Life} = \frac{2400}{5.25} \approx 457\ \text{days} \approx 15\ \text{months}\]

Static IP provides 2.4× longer battery life by eliminating DHCP overhead.

45.1 Learning Objectives

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

• Configure Power-Saving Modes: Select and implement Wi-Fi modem sleep, light sleep, and deep sleep modes on ESP32 devices
• Calculate Battery Life: Derive battery consumption estimates for different Wi-Fi duty cycles using current draw and timing analysis
• Design Connection Patterns: Architect efficient wake-transmit-sleep cycles that balance latency requirements against battery constraints
• Implement Deep Sleep Firmware: Program ESP32 for ultra-low-power periodic data transmission with static IP and RTC memory persistence
• Evaluate Wi-Fi 6 TWT: Analyze Target Wake Time scheduling to determine when TWT outperforms legacy power-save modes for IoT deployments

For Beginners: Why Power Optimization Matters

What is this chapter? Techniques to extend battery life for Wi-Fi IoT devices from days to years.

The Problem: Wi-Fi is power-hungry. An always-on Wi-Fi connection can drain a 2000mAh battery in less than a day. For battery-powered sensors, this is unacceptable.

The Solution: Strategic use of sleep modes and duty cycling can extend battery life from days to years.

Key Concepts:

Mode	Current Draw	Battery Life (2000mAh)
Active Wi-Fi TX	~120-260 mA	~8-17 hours
Wi-Fi Modem Sleep	~10-25 mA	~3-8 days
Light Sleep	~0.8 mA	~104 days
Deep Sleep	~100 uA	~2.3 years

45.2 Prerequisites

Before diving into this chapter, you should be familiar with:

• Wi-Fi Implementation: ESP32 Basics: Basic Wi-Fi connection and configuration
• Wi-Fi Fundamentals and Standards: Understanding of Wi-Fi power states

45.3 Wi-Fi Power-Saving Modes

45.3.1 Power-Saving Mode Configuration

// ESP32 Wi-Fi Power-Saving Modes
#include <Wi-Fi.h>

void setup() {
  Serial.begin(115200);

  Wi-Fi.begin("SSID", "password");
  while (Wi-Fi.status() != WL_CONNECTED) {
    delay(500);
  }

  // Power-saving modes
  // 1. Wi-Fi Modem Sleep (default) - radio turns off between DTIM beacons
  Wi-Fi.setSleep(true);

  // 2. Light sleep - CPU can sleep, wakes on Wi-Fi activity
  Wi-Fi.setSleep(WIFI_PS_MIN_MODEM);  // Minimum power save
  // Wi-Fi.setSleep(WIFI_PS_MAX_MODEM);  // Maximum power save

  Serial.println("Wi-Fi power-saving enabled");
}

Try It: Power Mode Comparison

Compare the current draw and estimated battery life across different Wi-Fi power-saving modes. Select your board’s battery capacity and see the impact of each mode.

viewof pwrBattery = Inputs.range([500, 10000], {
  value: 2000, step: 100, label: "Battery capacity (mAh)"
})
viewof pwrShowAll = Inputs.checkbox(["Show all modes side-by-side"], {value: ["Show all modes side-by-side"]})

pwrModeResult = {
  const cap = pwrBattery;
  const usable = cap * 0.8;
  const modes = [
    {name: "Active Wi-Fi TX", current: 190, color: "#E74C3C"},
    {name: "Active Wi-Fi RX", current: 100, color: "#E67E22"},
    {name: "Modem Sleep", current: 17.5, color: "#3498DB"},
    {name: "Light Sleep", current: 0.8, color: "#9B59B6"},
    {name: "Deep Sleep", current: 0.01, color: "#16A085"}
  ];
  const showAll = pwrShowAll.includes("Show all modes side-by-side");
  const maxCurrent = 200;
  const barAreaWidth = 280;
  const rows = modes.map(m => {
    const lifeDays = usable / (m.current * 24);
    let lifeStr;
    if (lifeDays < 1) {
      lifeStr = (lifeDays * 24).toFixed(1) + " hours";
    } else if (lifeDays < 60) {
      lifeStr = lifeDays.toFixed(1) + " days";
    } else if (lifeDays < 730) {
      lifeStr = (lifeDays / 30.44).toFixed(1) + " months";
    } else {
      lifeStr = (lifeDays / 365.25).toFixed(1) + " years";
    }
    const logScale = m.current > 0 ? Math.log10(m.current + 1) / Math.log10(maxCurrent + 1) : 0;
    const barW = Math.max(logScale * barAreaWidth, 2);
    return {name: m.name, current: m.current, color: m.color, lifeStr: lifeStr, barW: barW, lifeDays: lifeDays};
  });
  if (!showAll) {
    const best = rows[rows.length - 1];
    const worst = rows[0];
    return html`<div style="background: #f8f9fa; border-radius: 8px; padding: 16px; font-family: Arial, sans-serif;">
      <div style="display: grid; grid-template-columns: 1fr 1fr; gap: 12px;">
        <div style="background: white; border-radius: 6px; padding: 12px; border-left: 4px solid #E74C3C;">
          <div style="color: #7F8C8D; font-size: 0.85em;">Worst: ${worst.name}</div>
          <div style="font-size: 1.2em; font-weight: bold; color: #E74C3C;">${worst.lifeStr}</div>
          <div style="color: #7F8C8D; font-size: 0.8em;">${worst.current} mA</div>
        </div>
        <div style="background: white; border-radius: 6px; padding: 12px; border-left: 4px solid #16A085;">
          <div style="color: #7F8C8D; font-size: 0.85em;">Best: ${best.name}</div>
          <div style="font-size: 1.2em; font-weight: bold; color: #16A085;">${best.lifeStr}</div>
          <div style="color: #7F8C8D; font-size: 0.8em;">${best.current < 1 ? (best.current * 1000).toFixed(0) + " uA" : best.current + " mA"}</div>
        </div>
      </div>
      <div style="margin-top: 10px; color: #7F8C8D; font-size: 0.85em;">
        Deep sleep extends battery life by <strong>${(worst.current / best.current).toFixed(0)}x</strong> compared to active TX. Check "Show all modes" for the full comparison.
      </div>
    </div>`;
  }
  const svgH = rows.length * 44 + 10;
  return html`<div style="background: #f8f9fa; border-radius: 8px; padding: 16px; font-family: Arial, sans-serif;">
    <svg width="480" height="${svgH}" style="overflow: visible;">
      ${rows.map((r, i) => {
        const y = i * 44 + 5;
        return html`<g>
          <text x="0" y="${y + 14}" fill="#2C3E50" font-size="12" font-family="Arial" font-weight="bold">${r.name}</text>
          <rect x="130" y="${y}" width="${r.barW}" height="22" rx="4" fill="${r.color}" opacity="0.85"/>
          <text x="${130 + r.barW + 6}" y="${y + 15}" fill="#2C3E50" font-size="11" font-family="Arial">${r.current < 1 ? (r.current * 1000).toFixed(0) + " uA" : r.current + " mA"}</text>
          <text x="130" y="${y + 36}" fill="#7F8C8D" font-size="10" font-family="Arial">Battery life: ${r.lifeStr}</text>
        </g>`;
      })}
    </svg>
    <div style="margin-top: 8px; color: #7F8C8D; font-size: 0.85em;">
      Bar scale: logarithmic (current draw spans 4 orders of magnitude). Battery: ${cap} mAh (${usable.toFixed(0)} mAh usable at 80% DoD).
    </div>
  </div>`;
}

45.3.2 Deep Sleep with Periodic Wake

// ESP32 Deep Sleep with Wi-Fi (Ultra Low Power)
#include <Wi-Fi.h>
#include "esp_sleep.h"

#define uS_TO_S_FACTOR 1000000ULL
#define TIME_TO_SLEEP  60  // Sleep 60 seconds

const char* ssid = "YourSSID";
const char* password = "YourPassword";

void setup() {
  Serial.begin(115200);

  // Configure wake-up timer
  esp_sleep_enable_timer_wakeup(TIME_TO_SLEEP * uS_TO_S_FACTOR);

  // Quick Wi-Fi connection
  Wi-Fi.mode(WIFI_STA);
  Wi-Fi.begin(ssid, password);

  int timeout = 0;
  while (Wi-Fi.status() != WL_CONNECTED && timeout < 20) {
    delay(500);
    timeout++;
  }

  if (Wi-Fi.status() == WL_CONNECTED) {
    // Send sensor data
    Serial.println("Connected! Sending data...");
    // Your MQTT/HTTP code here

    delay(1000);  // Allow transmission to complete
  }

  // Disconnect and enter deep sleep
  Wi-Fi.disconnect(true);
  Wi-Fi.mode(WIFI_OFF);

  Serial.println("Entering deep sleep for 60 seconds...");
  esp_deep_sleep_start();
}

void loop() {
  // Never reached - device resets after deep sleep
}

Try It: ESP32 Deep Sleep Power Measurement

Objective: Observe the wake-transmit-sleep cycle on an ESP32 and measure connection times. Compare DHCP vs static IP connection speeds.

Code to Try – This sketch demonstrates the deep sleep wake-send-sleep cycle: boot, connect Wi-Fi, read sensor, transmit, then enter deep sleep for 10 seconds. Uses RTC memory to survive across sleep cycles.

Expand Full Deep Sleep Code (~64 lines)

#include <WiFi.h>
#include "esp_sleep.h"

#define uS_TO_S_FACTOR 1000000ULL
#define TIME_TO_SLEEP  10  // 10 seconds (short for demo)

RTC_DATA_ATTR int bootCount = 0;

void setup() {
  unsigned long startTime = millis();
  Serial.begin(115200);
  bootCount++;

  Serial.printf("\n=== Boot #%d (Deep Sleep Wake) ===\n", bootCount);

  // --- Method 1: DHCP (slower) ---
  unsigned long wifiStart = millis();
  WiFi.mode(WIFI_STA);
  WiFi.begin("Wokwi-GUEST", "");

  while (WiFi.status() != WL_CONNECTED) {
    delay(100);
  }
  unsigned long connectTime = millis() - wifiStart;
  Serial.printf("Wi-Fi connected in %lu ms (DHCP)\n", connectTime);
  Serial.printf("IP: %s | RSSI: %d dBm\n",
    WiFi.localIP().toString().c_str(), WiFi.RSSI());

  // Simulate sending sensor data
  unsigned long sendStart = millis();
  float temp = 22.0 + random(-30, 30) / 10.0;
  Serial.printf("Sensor reading: %.1f C\n", temp);
  // In real code: MQTT publish or HTTP POST here
  delay(100);  // Simulate network send
  unsigned long sendTime = millis() - sendStart;
  Serial.printf("Data sent in %lu ms\n", sendTime);

  // Power budget calculation
  unsigned long awakeTime = millis() - startTime;
  float activeCurrent = 120.0;  // mA during Wi-Fi TX
  float sleepCurrent = 0.01;    // mA during deep sleep (10 uA)
  float sleepTime = TIME_TO_SLEEP;
  float avgCurrent = (activeCurrent * awakeTime / 1000.0 +
    sleepCurrent * sleepTime) / (awakeTime / 1000.0 + sleepTime);

  Serial.printf("\n--- Power Budget ---\n");
  Serial.printf("Awake time:  %lu ms\n", awakeTime);
  Serial.printf("Sleep time:  %d s\n", TIME_TO_SLEEP);
  Serial.printf("Avg current: %.2f mA\n", avgCurrent);
  Serial.printf("Battery life (2000mAh): %.0f days\n",
    2000.0 / avgCurrent / 24.0);

  // Disconnect and sleep
  WiFi.disconnect(true);
  WiFi.mode(WIFI_OFF);

  Serial.printf("\nEntering deep sleep for %d seconds...\n", TIME_TO_SLEEP);
  esp_sleep_enable_timer_wakeup(TIME_TO_SLEEP * uS_TO_S_FACTOR);
  esp_deep_sleep_start();
}

void loop() {
  // Never reached -- ESP32 resets after deep sleep
}

What to Observe:

1. Each boot is a fresh wake from deep sleep – bootCount persists in RTC memory across resets
2. The power budget calculation shows how duty cycling extends battery life from hours to months
3. Wi-Fi connection time (DHCP) is typically 1-3 seconds – static IP would save ~1.5 seconds per wake cycle
4. Try changing TIME_TO_SLEEP to 60 or 300 and watch the estimated battery life increase dramatically

45.3.3 Battery Life Estimation

Mode	Power Consumption	Battery Life (2000mAh)
Active Wi-Fi TX	~120-260 mA	~8-17 hours
Active Wi-Fi RX	~80-120 mA	~16-25 hours
Wi-Fi Modem Sleep	~10-25 mA	~3-8 days
Light Sleep	~0.8 mA	~104 days
Deep Sleep (board dependent)	~100 uA (0.1 mA)	~2.3 years

Actual current draw varies widely by module/board (regulators, LEDs, sensors) and Wi-Fi conditions (RSSI, retransmissions, DTIM). Treat these as order-of-magnitude estimates.

Try It: Battery Life Calculator

Adjust the sleep mode, transmission interval, and battery capacity to see how each parameter affects estimated battery life for an ESP32-based Wi-Fi sensor node.

viewof battCalcMode = Inputs.select(
  ["Active Wi-Fi TX", "Wi-Fi Modem Sleep", "Light Sleep", "Deep Sleep"],
  {value: "Deep Sleep", label: "Sleep mode between transmissions"}
)
viewof battCalcInterval = Inputs.range([1, 120], {
  value: 15, step: 1, label: "Transmission interval (minutes)"
})
viewof battCalcCapacity = Inputs.range([500, 10000], {
  value: 2000, step: 100, label: "Battery capacity (mAh)"
})
viewof battCalcConnType = Inputs.select(
  ["DHCP (2.5s)", "Static IP (0.8s)"],
  {value: "Static IP (0.8s)", label: "Connection method"}
)

battCalcResult = {
  const sleepCurrents = {
    "Active Wi-Fi TX": 160,
    "Wi-Fi Modem Sleep": 15,
    "Light Sleep": 0.8,
    "Deep Sleep": 0.01
  };
  const sleepCurrent = sleepCurrents[battCalcMode];
  const txCurrent = 180;
  const connectTime = battCalcConnType === "DHCP (2.5s)" ? 2.5 : 0.8;
  const connectCurrent = 150;
  const txTime = 0.3;
  const cyclesPerDay = (24 * 60) / battCalcInterval;
  const activeSecondsPerCycle = connectTime + txTime;
  const sleepSecondsPerCycle = (battCalcInterval * 60) - activeSecondsPerCycle;
  const activeEnergyPerCycle = (connectTime * connectCurrent + txTime * txCurrent) / 3600;
  const sleepEnergyPerCycle = (sleepSecondsPerCycle * sleepCurrent) / 3600;
  const dailyEnergy = cyclesPerDay * (activeEnergyPerCycle + sleepEnergyPerCycle);
  const batteryLifeDays = (battCalcCapacity * 0.8) / dailyEnergy;
  const batteryLifeMonths = batteryLifeDays / 30.44;
  const batteryLifeYears = batteryLifeDays / 365.25;
  const activePercent = ((activeSecondsPerCycle * cyclesPerDay) / 86400 * 100).toFixed(3);
  const sleepPercent = (100 - parseFloat(activePercent)).toFixed(3);
  let lifeDisplay;
  if (batteryLifeYears >= 1) {
    lifeDisplay = batteryLifeYears.toFixed(1) + " years";
  } else if (batteryLifeMonths >= 1) {
    lifeDisplay = batteryLifeMonths.toFixed(1) + " months";
  } else {
    lifeDisplay = batteryLifeDays.toFixed(1) + " days";
  }
  const barMax = 3000;
  const barWidth = Math.min(dailyEnergy / barMax * 300, 300);
  const barColor = dailyEnergy < 5 ? "#16A085" : dailyEnergy < 50 ? "#E67E22" : "#E74C3C";
  return html`<div style="background: #f8f9fa; border-radius: 8px; padding: 16px; font-family: Arial, sans-serif;">
    <div style="display: grid; grid-template-columns: 1fr 1fr; gap: 12px; margin-bottom: 16px;">
      <div style="background: white; border-radius: 6px; padding: 12px; border-left: 4px solid #2C3E50;">
        <div style="color: #7F8C8D; font-size: 0.85em;">Sleep Current</div>
        <div style="font-size: 1.3em; font-weight: bold; color: #2C3E50;">${sleepCurrent < 1 ? (sleepCurrent * 1000).toFixed(0) + " uA" : sleepCurrent.toFixed(1) + " mA"}</div>
      </div>
      <div style="background: white; border-radius: 6px; padding: 12px; border-left: 4px solid #16A085;">
        <div style="color: #7F8C8D; font-size: 0.85em;">Cycles Per Day</div>
        <div style="font-size: 1.3em; font-weight: bold; color: #16A085;">${cyclesPerDay.toFixed(0)}</div>
      </div>
      <div style="background: white; border-radius: 6px; padding: 12px; border-left: 4px solid #E67E22;">
        <div style="color: #7F8C8D; font-size: 0.85em;">Daily Consumption</div>
        <div style="font-size: 1.3em; font-weight: bold; color: #E67E22;">${dailyEnergy.toFixed(2)} mAh</div>
      </div>
      <div style="background: white; border-radius: 6px; padding: 12px; border-left: 4px solid #3498DB;">
        <div style="color: #7F8C8D; font-size: 0.85em;">Estimated Battery Life</div>
        <div style="font-size: 1.3em; font-weight: bold; color: #3498DB;">${lifeDisplay}</div>
      </div>
    </div>
    <div style="margin-bottom: 12px;">
      <div style="color: #2C3E50; font-weight: bold; margin-bottom: 4px;">Daily Energy Budget</div>
      <svg width="320" height="30">
        <rect x="0" y="5" width="300" height="20" rx="4" fill="#ecf0f1"/>
        <rect x="0" y="5" width="${barWidth}" height="20" rx="4" fill="${barColor}"/>
        <text x="${Math.min(barWidth + 5, 250)}" y="19" fill="#2C3E50" font-size="11" font-family="Arial">${dailyEnergy.toFixed(2)} mAh/day</text>
      </svg>
    </div>
    <div style="color: #7F8C8D; font-size: 0.85em;">
      Duty cycle: <strong>${activePercent}%</strong> active, <strong>${sleepPercent}%</strong> sleep | Connection: ${connectTime}s per wake | Usable capacity: ${(battCalcCapacity * 0.8).toFixed(0)} mAh (80% DoD)
    </div>
  </div>`;
}

Maximizing Battery Life

Strategies:

1. Minimize connection time - Connect, transmit, disconnect quickly
2. Use deep sleep between transmissions (seconds to minutes)
3. Batch data - Send multiple readings at once
4. Reduce transmission power if close to AP
5. Use static IP to avoid DHCP negotiation
6. Only disable Wi-Fi sleep if you need low-latency/throughput; otherwise keep power save enabled

45.4 Knowledge Check

Test your understanding of Wi-Fi power optimization with these questions.

Knowledge Check: Wi-Fi Power Optimization Test Your Understanding

Interactive Quiz: Match Concepts

Interactive Quiz: Sequence the Steps

Decision Framework: Wi-Fi vs LoRaWAN for Battery-Powered Sensors

Scenario: A smart agriculture company needs to deploy soil moisture sensors across a 50-hectare vineyard. Sensors must report every 15 minutes and achieve 2+ year battery life on 2xAA batteries (3000 mAh). Should they use Wi-Fi or LoRaWAN?

Key Decision Factors:

Factor	Wi-Fi (with Deep Sleep)	LoRaWAN
Range	50-100m indoor, 200-300m outdoor	2-5 km rural, 500m-2km urban
Battery Life	6-18 months (aggressive deep sleep)	2-10 years (LPWAN optimized)
Data Rate	1 Mbps+ (overkill for sensors)	250 bps - 50 kbps (sufficient)
Latency	<1 second (with connection)	1-5 seconds (duty cycle)
Infrastructure	Wi-Fi AP every 100-200m	Single gateway for 2-5 km
Connection Overhead	0.8-3 seconds per wake (DHCP/auth)	<100 ms (pre-synchronized)
Power per Transmission	800-2000 mAs (connect + send)	50-150 mAs (send only)
Idle Current	10-100 uA (deep sleep)	1-5 uA (sleep mode)
Cost per Node	$5-10 (ESP32)	$15-25 (LoRa module)
Infrastructure Cost	$3,000-5,000 (15-25 APs)	$300-800 (1 gateway)

Calculation: Wi-Fi Deep Sleep Strategy

Battery: 3000 mAh at 3V = 9 Wh

Per transmission cycle (every 15 minutes): 1. Deep sleep: 899 sec @ 10 uA = 8,990 uA-sec = 2.5 uAh 2. Wake + connect (static IP): 0.8 sec @ 150 mA avg = 120 mA-sec = 33.3 uAh 3. Read sensor: 0.1 sec @ 5 mA = 0.5 mA-sec = 0.14 uAh 4. Transmit data: 0.1 sec @ 240 mA = 24 mA-sec = 6.67 uAh 5. Disconnect: 0.05 sec @ 50 mA = 2.5 mA-sec = 0.69 uAh

Total per cycle: 43.3 uAh Cycles per day: 96 (every 15 min) Daily consumption: 96 × 43.3 = 4.16 mAh/day

Battery life: 3000 mAh ÷ 4.16 = 721 days = 19.8 months (with 80% usable capacity = 15.8 months)

Calculation: LoRaWAN Strategy

Per transmission cycle (every 15 minutes): 1. Sleep: 899.9 sec @ 1 uA = 899.9 uA-sec = 0.25 uAh 2. Wake + stabilize: 0.01 sec @ 10 mA = 0.1 mA-sec = 0.03 uAh 3. Read sensor: 0.1 sec @ 5 mA = 0.5 mA-sec = 0.14 uAh 4. Transmit (SF7, 20 bytes): 0.05 sec @ 120 mA = 6 mA-sec = 1.67 uAh

Total per cycle: 2.09 uAh Cycles per day: 96 Daily consumption: 96 × 2.09 = 0.20 mAh/day

Battery life: 3000 mAh ÷ 0.20 = 15,000 days = 41 years (realistically 5-7 years with self-discharge and 80% DoD)

Comparison Summary:

Metric	Wi-Fi Deep Sleep	LoRaWAN	Winner
Battery Life	15.8 months	5-7 years	LoRaWAN (4-5x longer)
Connection Energy	33.3 uAh (77% of cycle)	0.03 uAh (1% of cycle)	LoRaWAN (1100x less)
Infrastructure Cost	$4,000 (20 APs × $200)	$600 (1 gateway)	LoRaWAN (7x cheaper)
Latency	<1 second	1-5 seconds	Wi-Fi
Bandwidth	1+ Mbps	5 kbps	Wi-Fi
Maintenance	High (20 APs to manage)	Low (1 gateway)	LoRaWAN

Decision: LoRaWAN for this deployment

Why LoRaWAN wins:

1. Battery Life: 5-7 years vs 15 months (4-5x improvement) - eliminates maintenance visits
2. Infrastructure: 1 gateway ($600) covers entire 50-hectare vineyard vs 20 APs ($4,000)
3. Connection Overhead: LoRa avoids Wi-Fi’s 0.8-second reconnection penalty each cycle
4. Range: 2-5 km covers entire vineyard from central gateway vs 100-200m per Wi-Fi AP
5. Power per TX: 50-150 mAs (LoRa) vs 800-2000 mAs (Wi-Fi) - 10-20x less

When Wi-Fi IS the Better Choice:

Scenario	Why Wi-Fi Wins
Greenhouse with existing Wi-Fi	Infrastructure already paid for, sensors <50m from AP
High-bandwidth sensors (cameras)	LoRa max 50 kbps vs Wi-Fi 1+ Mbps
Sub-second latency required	Real-time alerts, robot control
Firmware OTA updates	500 KB firmware takes 10+ minutes on LoRa vs 30 seconds on Wi-Fi
IP connectivity required	Direct internet access, no gateway translation

Hybrid Approach: Wi-Fi + LoRaWAN

Deploy LoRa sensors (80% of nodes) + Wi-Fi cameras (20% of nodes): - LoRa: Soil moisture, temperature (every 15 min) - 5+ year battery - Wi-Fi: Time-lapse cameras (solar powered, daily images) - high bandwidth

Key Insight: Wi-Fi’s Achilles’ heel for battery power is connection overhead - the 0.8-3 second reconnection process consumes 800-2000 mAs per wake cycle, dominating the energy budget. LoRaWAN’s pre-synchronized network avoids this entirely, reducing per-transmission energy by 10-20x. For soil moisture sensors reporting every 15 minutes, this translates to 4-5x longer battery life. The break-even point is around 5-minute update intervals in strong-signal areas with static IP - faster updates favor Wi-Fi, slower updates overwhelmingly favor LoRaWAN. Always calculate the energy budget before choosing a protocol.

45.5 Troubleshooting Wi-Fi IoT Issues

45.5.1 Common Problems and Solutions

1. Connection Failures

Symptoms: Device will not connect to Wi-Fi

Checklist:

- Verify SSID and password are correct
- Check 2.4 GHz is enabled (many IoT devices don't support 5 GHz)
- Ensure router not in 5 GHz-only mode
- Check MAC filtering is not blocking device
- Verify WPA2 is used (some devices don't support WPA3)
- Check router is not at max device limit
- Ensure router broadcast SSID (not hidden)

2. Weak Signal / Dropped Connections

Solutions:

// Monitor Wi-Fi signal strength
void checkSignal() {
  long rssi = Wi-Fi.RSSI();
  Serial.print("Signal strength: ");
  Serial.print(rssi);
  Serial.print(" dBm - ");

  if (rssi > -50) {
    Serial.println("Excellent");
  } else if (rssi > -60) {
    Serial.println("Good");
  } else if (rssi > -70) {
    Serial.println("Fair");
  } else {
    Serial.println("Weak - consider repositioning");
  }
}

Signal Improvement Strategies:

• Reduce distance to access point
• Add Wi-Fi extender or mesh node
• Change Wi-Fi channel (avoid congestion)
• Use external antenna (if supported)
• Switch to 2.4 GHz for better penetration

3. High Power Consumption

Optimization:

// Implement aggressive power saving
Wi-Fi.setSleep(WIFI_PS_MAX_MODEM);  // Max modem sleep
Wi-Fi.setTxPower(WIFI_POWER_7dBm);  // Reduce TX power if close to AP

// Or use deep sleep for battery devices
esp_sleep_enable_timer_wakeup(60 * 1000000);  // 60 seconds
esp_deep_sleep_start();

Try It: TX Power vs Distance Trade-off

Explore how reducing Wi-Fi TX power saves energy when you are close to the access point. Adjust the distance and see the recommended TX power level and estimated energy savings.

viewof txDistance = Inputs.range([1, 100], {
  value: 10, step: 1, label: "Distance to access point (meters)"
})
viewof txEnvironment = Inputs.select(
  ["Open air", "Indoor (light walls)", "Indoor (concrete walls)"],
  {value: "Indoor (light walls)", label: "Environment type"}
)

txPowerResult = {
  const dist = txDistance;
  const env = txEnvironment;
  const pathLossExponent = env === "Open air" ? 2.0 : env === "Indoor (light walls)" ? 2.8 : 3.5;
  const wallLoss = env === "Open air" ? 0 : env === "Indoor (light walls)" ? 3 : 8;
  const pathLoss = 40.0 + 10 * pathLossExponent * Math.log10(Math.max(dist, 1)) + wallLoss;
  const rxSensitivity = -85;
  const margin = 10;
  const minTxPower = rxSensitivity + pathLoss + margin;
  const txLevels = [
    {label: "2 dBm (lowest)", dbm: 2, current: 120},
    {label: "5 dBm", dbm: 5, current: 140},
    {label: "7 dBm", dbm: 7, current: 160},
    {label: "11 dBm", dbm: 11, current: 190},
    {label: "15 dBm", dbm: 15, current: 220},
    {label: "19 dBm", dbm: 19, current: 250},
    {label: "20 dBm (max)", dbm: 20, current: 260}
  ];
  let recommended = txLevels[txLevels.length - 1];
  for (let i = 0; i < txLevels.length; i++) {
    if (txLevels[i].dbm >= minTxPower) {
      recommended = txLevels[i];
      break;
    }
  }
  const maxTx = txLevels[txLevels.length - 1];
  const savingsPercent = ((1 - recommended.current / maxTx.current) * 100).toFixed(1);
  const estimatedRSSI = recommended.dbm - pathLoss;
  const signalQuality = estimatedRSSI > -50 ? "Excellent" : estimatedRSSI > -60 ? "Good" : estimatedRSSI > -70 ? "Fair" : estimatedRSSI > -80 ? "Weak" : "Very Weak";
  const qualityColor = estimatedRSSI > -50 ? "#16A085" : estimatedRSSI > -60 ? "#3498DB" : estimatedRSSI > -70 ? "#E67E22" : "#E74C3C";
  const barMaxW = 250;
  const recBarW = (recommended.current / maxTx.current) * barMaxW;
  const maxBarW = barMaxW;
  return html`<div style="background: #f8f9fa; border-radius: 8px; padding: 16px; font-family: Arial, sans-serif;">
    <div style="display: grid; grid-template-columns: 1fr 1fr 1fr; gap: 12px; margin-bottom: 16px;">
      <div style="background: white; border-radius: 6px; padding: 12px; border-left: 4px solid #2C3E50;">
        <div style="color: #7F8C8D; font-size: 0.85em;">Recommended TX Power</div>
        <div style="font-size: 1.3em; font-weight: bold; color: #2C3E50;">${recommended.label}</div>
      </div>
      <div style="background: white; border-radius: 6px; padding: 12px; border-left: 4px solid ${qualityColor};">
        <div style="color: #7F8C8D; font-size: 0.85em;">Est. Signal Quality</div>
        <div style="font-size: 1.3em; font-weight: bold; color: ${qualityColor};">${signalQuality}</div>
        <div style="color: #7F8C8D; font-size: 0.8em;">${estimatedRSSI.toFixed(0)} dBm RSSI</div>
      </div>
      <div style="background: white; border-radius: 6px; padding: 12px; border-left: 4px solid #16A085;">
        <div style="color: #7F8C8D; font-size: 0.85em;">TX Current Savings</div>
        <div style="font-size: 1.3em; font-weight: bold; color: #16A085;">${savingsPercent}%</div>
        <div style="color: #7F8C8D; font-size: 0.8em;">${recommended.current} vs ${maxTx.current} mA</div>
      </div>
    </div>
    <div style="margin-bottom: 8px;">
      <div style="color: #2C3E50; font-weight: bold; font-size: 0.9em; margin-bottom: 4px;">TX Current Comparison</div>
      <svg width="400" height="52">
        <text x="0" y="14" fill="#7F8C8D" font-size="10" font-family="Arial">Max (${maxTx.dbm} dBm)</text>
        <rect x="80" y="2" width="${maxBarW}" height="16" rx="4" fill="#E74C3C" opacity="0.3"/>
        <text x="${80 + maxBarW + 4}" y="14" fill="#7F8C8D" font-size="10" font-family="Arial">${maxTx.current} mA</text>
        <text x="0" y="40" fill="#2C3E50" font-size="10" font-family="Arial" font-weight="bold">Optimal (${recommended.dbm} dBm)</text>
        <rect x="80" y="28" width="${recBarW}" height="16" rx="4" fill="#16A085" opacity="0.85"/>
        <text x="${80 + recBarW + 4}" y="40" fill="#2C3E50" font-size="10" font-family="Arial">${recommended.current} mA</text>
      </svg>
    </div>
    <div style="color: #7F8C8D; font-size: 0.85em;">
      Path loss model: ${pathLossExponent.toFixed(1)} exponent | Estimated path loss: ${pathLoss.toFixed(1)} dB | Safety margin: ${margin} dB
    </div>
  </div>`;
}

4. IP Address Conflicts

Solutions:

// Use static IP to avoid DHCP issues
// Tip: Reserve this address in your router DHCP settings to avoid conflicts.
IPAddress local_IP(192, 168, 1, 100);
IPAddress gateway(192, 168, 1, 1);
IPAddress subnet(255, 255, 255, 0);
IPAddress primaryDNS(8, 8, 8, 8);

if (!Wi-Fi.config(local_IP, gateway, subnet, primaryDNS)) {
  Serial.println("Static IP configuration failed");
}

Wi-Fi.begin(ssid, password);

5. Slow Performance / Latency

Diagnostics:

// Ping test (install the ESP32Ping library)
#include <ESP32Ping.h>

IPAddress ip(192, 168, 1, 1);  // Gateway
if (Ping.ping(ip)) {
  Serial.print("Ping time (avg): ");
  Serial.print(Ping.averageTime());
  Serial.println(" ms");
} else {
  Serial.println("Ping failed");
}

Common causes:

• Channel congestion (switch to less crowded channel)
• Too many devices on network
• Interference (microwaves, Bluetooth)
• Old router firmware
• QoS settings prioritizing other traffic

45.6 Worked Examples

Apply Wi-Fi implementation knowledge to real-world IoT device design.

Worked Example: Power Save Mode Configuration for Battery Sensor

Scenario: A smart agriculture company deploys 200 soil moisture sensors across a vineyard. Each sensor measures moisture, temperature, and conductivity every 15 minutes and transmits data to a central gateway via Wi-Fi. The sensors must operate for 12 months on 2x AA batteries (3000 mAh at 3V). Initial testing shows only 3-week battery life with always-on Wi-Fi.

Given:

• Battery capacity: 3000 mAh at 3V = 9 Wh total energy
• Target runtime: 12 months = 8,760 hours
• ESP32 current consumption (datasheet):
  • Active Wi-Fi TX (13 dBm): 240 mA
  • Active Wi-Fi RX: 95 mA
  • Wi-Fi modem sleep: 20 mA
  • Light sleep: 0.8 mA
  • Deep sleep: 10 uA (0.01 mA)
• Data payload: 50 bytes per transmission
• Wi-Fi connection time: 3 seconds (DHCP) or 0.8 seconds (static IP)
• Transmission interval: 15 minutes (96 times per day)

Steps:

1. Calculate baseline (always-on Wi-Fi):

   • Wi-Fi modem sleep average: 20 mA continuous
   • Daily consumption: 20 mA x 24h = 480 mAh/day
   • Battery life: 3000 / 480 = 6.25 days
   • Problem confirmed: Always-on Wi-Fi drains battery in ~1 week

2. Design deep sleep duty cycle:

   • Active period: Connect, Transmit, Disconnect
   • Sleep period: 15 minutes - active time
   • Target: Maximize sleep time while meeting 15-minute interval

3. Optimize connection time with static IP:

   • DHCP handshake: ~2.5 seconds of Wi-Fi active

   • Static IP: Skip DHCP, connect in ~0.8 seconds

   • Configuration:

     IPAddress staticIP(192, 168, 1, 150);
     IPAddress gateway(192, 168, 1, 1);
     IPAddress subnet(255, 255, 255, 0);
     Wi-Fi.config(staticIP, gateway, subnet);

   • Connection time saved: 2.5 - 0.8 = 1.7 seconds per cycle

4. Calculate active period energy:

   • Wake from deep sleep: 50 ms at 40 mA = 0.56 mAs
   • Wi-Fi connect (static IP): 800 ms at 150 mA avg = 120 mAs
   • Wi-Fi TX (50 bytes): 100 ms at 240 mA = 24 mAs
   • Wi-Fi RX (ACK): 50 ms at 95 mA = 4.75 mAs
   • Wi-Fi disconnect: 50 ms at 50 mA = 2.5 mAs
   • Total active: 151.81 mAs = 0.042 mAh per transmission

5. Calculate sleep period energy:

   • Sleep duration: 15 min - 1.05 sec = 898.95 seconds
   • Deep sleep current: 0.01 mA
   • Sleep energy: 898.95 s x 0.01 mA / 3600 = 0.0025 mAh per cycle

6. Calculate daily energy consumption:

   • Active energy: 96 cycles x 0.042 mAh = 4.03 mAh/day
   • Sleep energy: 96 cycles x 0.0025 mAh = 0.24 mAh/day
   • Total daily: 4.27 mAh/day

7. Estimate battery life:

   • Usable capacity (80% efficiency): 3000 x 0.8 = 2400 mAh
   • Battery life: 2400 / 4.27 = 562 days = 18.7 months
   • Exceeds 12-month target with 56% margin

8. Implement in ESP32 code:

   #define uS_TO_S_FACTOR 1000000ULL
   #define SLEEP_DURATION 900  // 15 minutes in seconds
   
   void setup() {
     // Static IP for fast connection
     Wi-Fi.config(staticIP, gateway, subnet);
     Wi-Fi.begin(ssid, password);
   
     // Wait max 2 seconds for connection
     int timeout = 0;
     while (Wi-Fi.status() != WL_CONNECTED && timeout < 20) {
       delay(100);
       timeout++;
     }
   
     if (Wi-Fi.status() == WL_CONNECTED) {
       sendSensorData();  // Quick HTTP POST or MQTT publish
     }
   
     // Disconnect cleanly
     Wi-Fi.disconnect(true);
     Wi-Fi.mode(WIFI_OFF);
   
     // Enter deep sleep
     esp_sleep_enable_timer_wakeup(SLEEP_DURATION * uS_TO_S_FACTOR);
     esp_deep_sleep_start();
   }

Result:

Configuration	Daily Consumption	Battery Life	Improvement
Always-on Wi-Fi	480 mAh	6 days	Baseline
Modem sleep	120 mAh	25 days	4x
Deep sleep + DHCP	6.5 mAh	369 days	60x
Deep sleep + Static IP	4.27 mAh	562 days	93x

Key Insight: The biggest power savings come from eliminating idle Wi-Fi time through deep sleep (20 mA to 0.01 mA = 2000x reduction). The second optimization is static IP configuration, which cuts connection time from 3 seconds to 0.8 seconds, reducing active energy by 73%. For 15-minute intervals, Wi-Fi is active only 0.1% of the time. If even longer battery life is needed, consider batching multiple readings and transmitting every 2-4 hours, or switching to a lower-power protocol like LoRaWAN.

Worked Example: Wi-Fi 6 TWT Configuration for Smart Building Sensors

Scenario: A commercial building deploys 150 occupancy sensors for HVAC optimization. Sensors detect room occupancy and report status changes in real-time for demand-controlled ventilation. Each sensor is powered by a 2000 mAh lithium battery. The building uses Wi-Fi 6 (802.11ax) infrastructure with TWT (Target Wake Time) support. The challenge is balancing real-time responsiveness (<30 second delay) with battery life (>2 years).

Given:

• Sensors: 150 PIR occupancy sensors, ESP32-C6 (Wi-Fi 6 capable)
• Battery: 2000 mAh lithium, 3.7V nominal
• Wi-Fi 6 AP: Enterprise-grade with TWT enabled
• Occupancy events: 10-20 per hour during business hours (8am-6pm)
• Latency requirement: <30 seconds from detection to HVAC response
• Current consumption (ESP32-C6):
  • Active Wi-Fi TX: 320 mA
  • Active Wi-Fi RX: 110 mA
  • TWT sleep (radio off, RTC on): 5 uA
  • Light sleep: 130 uA
• Target battery life: 24 months (2 years)

Steps:

1. Understand TWT operation modes:
   • Individual TWT: Sensor negotiates specific wake schedule with AP
   • Broadcast TWT: AP announces common wake windows for all devices
   • Triggered TWT: AP polls devices during their TWT window
   • For occupancy sensors: Individual TWT with event-driven wakeup
2. Calculate baseline without TWT (legacy power save):
   • Listen interval (legacy): 100ms DTIM beacons
   • Wake to check beacon: 10 wakes/second x 5ms x 30mA = 1.5 mAh/hour
   • Daily beacon listening: 1.5 x 24 = 36 mAh/day
   • Event transmissions (20/day): 20 x 0.05 mAh = 1 mAh/day
   • Total: 37 mAh/day = 54 days battery life (fails 2-year target)
3. Design TWT schedule for 30-second latency:
   • Maximum acceptable sleep: 30 seconds (latency requirement)
   • TWT Service Period: 30 seconds (wake every 30s to check/send)
   • TWT Wake Duration: 10ms (time window to transmit)
   • During TWT sleep: Radio completely off, GPIO interrupt enabled
4. Configure event-driven wake with GPIO:
   • PIR sensor triggers GPIO interrupt
   • ESP32-C6 wakes from TWT sleep immediately
   • Sensor transmits event, then returns to TWT sleep
   • No waiting for next TWT window for urgent events

   // Configure PIR as wake source
   esp_sleep_enable_ext0_wakeup(GPIO_NUM_4, HIGH);
   
   // Also configure TWT timer wake
   wifi_config_twt(TWT_INTERVAL_30S);

5. Calculate TWT power consumption:

   • TWT sleep current: 5 uA = 0.005 mA

   • Sleep time per hour: 3600 - (120 wakes x 0.01s) = 3598.8 seconds

   • Sleep energy: 3598.8 x 0.005 / 3600 = 0.005 mAh/hour

   • Scheduled TWT wakes: 120/hour (every 30 seconds)

   • Wake + beacon check: 120 x 10ms x 40mA = 48 mAs = 0.013 mAh/hour

   • Event transmissions: 20/day average, ~1/hour during business

   • TX energy: 1 x 100ms x 320mA = 32 mAs = 0.009 mAh/hour

   • Hourly total: 0.027 mAh/hour = 0.65 mAh/day

6. Estimate battery life with TWT:
   • Daily consumption: 0.65 mAh
   • Usable battery (80%): 2000 x 0.8 = 1600 mAh
   • Battery life: 1600 / 0.65 = 2461 days = 6.7 years
   • Exceeds 2-year target by 3.4x margin
7. Optimize further if needed:
   • Increase TWT interval to 60 seconds: +40% battery life
   • Batch non-urgent status reports: +20% battery life
   • But keep 30-second interval for HVAC responsiveness

Result:

Configuration	Daily Consumption	Battery Life	Latency
Legacy PS (100ms DTIM)	37 mAh	54 days	100ms
Wi-Fi 6 TWT (30s interval)	0.65 mAh	6.7 years	30s max
Wi-Fi 6 TWT + event wake	0.65 mAh	6.7 years	<1s (events)

Parameter	Value	Notes
TWT Service Period	30 seconds	Matches latency requirement
TWT Wake Duration	10 ms	Minimal on-air time
GPIO wake source	PIR sensor	Immediate event response
Beacon interval	N/A	Not needed with TWT

Key Insight: Wi-Fi 6 TWT fundamentally changes battery calculus for Wi-Fi IoT. By eliminating mandatory beacon listening (the dominant power drain in legacy Wi-Fi), TWT reduces idle power from 30+ mA (frequent wakes) to 5 uA (true sleep). The key design pattern is combining scheduled TWT windows (for periodic reporting and downstream commands) with GPIO-triggered wakeups (for real-time event response). This “sleep-until-event-or-timeout” model provides both low latency and multi-year battery life. Ensure both the sensor module and AP support TWT - many Wi-Fi 6 APs have TWT disabled by default.

45.7 Python Power Analysis Tools

45.7.1 Wi-Fi Power Consumption Calculator

Example Output Format (illustrative):

=== Wi-Fi Power Consumption and Battery Estimator ===

Inputs:
  Battery capacity: <mAh>
  Wi-Fi strategy: <stay connected | connect/send/sleep>
  Duty cycle: <events/day>, <time connected>, <sleep mode>
Assumptions (from datasheets/measurements):
  TX/RX current peaks: <mA>
  Idle/modem-sleep current: <mA>
  Deep-sleep current: <uA>

Outputs:
  Estimated average current: <mA>
  Estimated battery life: <days> (based on your assumptions)
  Dominant energy costs: association/DHCP, TX bursts, idle listening, sleep
  Optimization ideas: reduce reconnects (when acceptable), reduce transmit frequency, tune sleep mode, and only reduce TX power when you have RSSI/SNR margin

Key Concepts Demonstrated:

• Deep sleep vs modem sleep: Deep sleep is often orders of magnitude lower idle current than an active Wi-Fi stack (validate on your board)
• Battery life estimation: Average current is driven by duty cycle (time in each state times current in that state)
• Usage pattern impact: Frequent reconnects and frequent transmissions can dominate energy use
• Optimization strategies: Sleep modes, reduced reconnect frequency, batching, and (sometimes) static IP/DHCP tuning; validate with real measurements

45.7.2 Wi-Fi Signal Strength Analyzer

Example Output Format (illustrative):

=== Wi-Fi Signal Strength and Channel Analyzer ===

Signal Strength (sample):
Location: Living Room (near AP)
  RSSI: -45 dBm
  Quality: Excellent
  Recommendation: No action needed

Location: Garage (behind racks/walls)
  RSSI: -75 dBm
  Quality: Weak
  Recommendation: Consider moving device, adding an AP/mesh node, or switching bands

Channel Plan (2.4 GHz, 20 MHz):
Candidate channels: 1, 6, 11
  Ch 1: <networks detected nearby>
  Ch 6: <networks detected nearby>
  Ch 11: <networks detected nearby>
Recommendation: Choose the least-congested candidate and validate with a quick throughput/packet-loss test.

Key Concepts Demonstrated:

• RSSI to Signal Quality: -45 dBm (Excellent) to -85 dBm (Unusable)
• RSSI is not throughput: Use RSSI as a coarse indicator; verify with packet loss/latency/throughput tests
• Channel overlap: In many regions (20 MHz), channels 1/6/11 are typical non-overlapping choices - validate for your region and channel width
• Congestion scoring: Network count + observed signal levels can help prioritize candidates (but real performance requires measurement)

Try It: Duty Cycle Energy Budget Visualizer

Visualize how energy is distributed across different phases of a Wi-Fi wake-transmit-sleep cycle. Adjust timing for each phase to see which dominates your energy budget.

viewof dcConnTime = Inputs.range([0.2, 5.0], {
  value: 0.8, step: 0.1, label: "Connection time (seconds)"
})
viewof dcTxTime = Inputs.range([0.05, 2.0], {
  value: 0.3, step: 0.05, label: "Data transmission time (seconds)"
})
viewof dcSleepMin = Inputs.range([1, 60], {
  value: 15, step: 1, label: "Sleep interval (minutes)"
})
viewof dcConnCurrent = Inputs.range([80, 300], {
  value: 150, step: 10, label: "Connection current (mA)"
})

dcResult = {
  const connTime = dcConnTime;
  const txTime = dcTxTime;
  const sleepMin = dcSleepMin;
  const connCurrent = dcConnCurrent;
  const txCurrent = 240;
  const sleepCurrent = 0.01;
  const sleepSec = sleepMin * 60 - connTime - txTime;
  const connEnergy = connTime * connCurrent;
  const txEnergy = txTime * txCurrent;
  const sleepEnergy = sleepSec * sleepCurrent;
  const totalEnergy = connEnergy + txEnergy + sleepEnergy;
  const connPct = (connEnergy / totalEnergy * 100).toFixed(1);
  const txPct = (txEnergy / totalEnergy * 100).toFixed(1);
  const sleepPct = (sleepEnergy / totalEnergy * 100).toFixed(1);
  const cyclesPerDay = 1440 / sleepMin;
  const dailyMAh = (totalEnergy * cyclesPerDay / 3600).toFixed(2);
  const phases = [
    {name: "Connection", energy: connEnergy, pct: connPct, color: "#E67E22", time: connTime},
    {name: "TX Data", energy: txEnergy, pct: txPct, color: "#E74C3C", time: txTime},
    {name: "Sleep", energy: sleepEnergy, pct: sleepPct, color: "#16A085", time: sleepSec}
  ];
  const pieTotal = connEnergy + txEnergy;
  const activeTotal = pieTotal;
  const svgW = 320;
  const svgH = 140;
  const cx = 70;
  const cy = 70;
  const r = 60;
  const connAngle = (connEnergy / (activeTotal > 0 ? activeTotal : 1)) * 2 * Math.PI;
  const txAngle = (txEnergy / (activeTotal > 0 ? activeTotal : 1)) * 2 * Math.PI;
  function arcPath(startAngle, endAngle, color) {
    const x1 = cx + r * Math.cos(startAngle - Math.PI / 2);
    const y1 = cy + r * Math.sin(startAngle - Math.PI / 2);
    const x2 = cx + r * Math.cos(endAngle - Math.PI / 2);
    const y2 = cy + r * Math.sin(endAngle - Math.PI / 2);
    const largeArc = (endAngle - startAngle) > Math.PI ? 1 : 0;
    return `M ${cx} ${cy} L ${x1} ${y1} A ${r} ${r} 0 ${largeArc} 1 ${x2} ${y2} Z`;
  }
  const dominant = phases.reduce((a, b) => a.energy > b.energy ? a : b);
  return html`<div style="background: #f8f9fa; border-radius: 8px; padding: 16px; font-family: Arial, sans-serif;">
    <div style="display: flex; gap: 20px; align-items: flex-start; flex-wrap: wrap;">
      <div>
        <div style="color: #2C3E50; font-weight: bold; font-size: 0.9em; margin-bottom: 6px;">Active Phase Energy Split</div>
        <svg width="${svgW}" height="${svgH}">
          <path d="${arcPath(0, connAngle)}" fill="#E67E22" opacity="0.85"/>
          <path d="${arcPath(connAngle, connAngle + txAngle)}" fill="#E74C3C" opacity="0.85"/>
          <circle cx="${cx}" cy="${cy}" r="25" fill="white"/>
          <text x="${cx}" y="${cy - 4}" text-anchor="middle" fill="#2C3E50" font-size="10" font-family="Arial" font-weight="bold">Active</text>
          <text x="${cx}" y="${cy + 8}" text-anchor="middle" fill="#7F8C8D" font-size="9" font-family="Arial">${(connTime + txTime).toFixed(1)}s</text>
          <rect x="160" y="20" width="14" height="14" rx="3" fill="#E67E22" opacity="0.85"/>
          <text x="180" y="32" fill="#2C3E50" font-size="11" font-family="Arial">Connect: ${connPct}% (${connEnergy.toFixed(1)} mAs)</text>
          <rect x="160" y="46" width="14" height="14" rx="3" fill="#E74C3C" opacity="0.85"/>
          <text x="180" y="58" fill="#2C3E50" font-size="11" font-family="Arial">TX: ${txPct}% (${txEnergy.toFixed(1)} mAs)</text>
          <rect x="160" y="72" width="14" height="14" rx="3" fill="#16A085" opacity="0.85"/>
          <text x="180" y="84" fill="#2C3E50" font-size="11" font-family="Arial">Sleep: ${sleepPct}% (${sleepEnergy.toFixed(2)} mAs)</text>
          <text x="160" y="112" fill="#2C3E50" font-size="11" font-family="Arial" font-weight="bold">Total: ${totalEnergy.toFixed(1)} mAs/cycle</text>
          <text x="160" y="128" fill="#7F8C8D" font-size="10" font-family="Arial">Daily: ${dailyMAh} mAh (${cyclesPerDay.toFixed(0)} cycles)</text>
        </svg>
      </div>
    </div>
    <div style="margin-top: 10px; padding: 10px; background: white; border-radius: 6px; border-left: 4px solid ${dominant.color};">
      <span style="color: #2C3E50; font-weight: bold;">Dominant cost:</span>
      <span style="color: ${dominant.color}; font-weight: bold;"> ${dominant.name}</span>
      <span style="color: #7F8C8D;"> accounts for ${dominant.pct}% of cycle energy.
      ${dominant.name === "Connection" ? "Tip: Use static IP to reduce connection time." : dominant.name === "TX Data" ? "Tip: Batch readings or reduce payload size." : "Sleep energy is negligible - this is an efficient duty cycle."}</span>
    </div>
  </div>`;
}

45.8 Concept Relationships

Understanding how these concepts relate helps you optimize power consumption effectively:

Concept	Depends On	Enables	Trade-off
Deep Sleep Mode	RTC memory, wake sources	Long battery life	Wake latency vs power savings
DTIM Beacon Interval	AP configuration, network sync	Sleep between beacons	Latency vs power consumption
Connection Keepalive	Application requirements	Network persistence	Power overhead vs reconnect delay
Wi-Fi 6 TWT	AP support, scheduling	Predictable wake cycles	Protocol complexity vs efficiency
Data Batching	Buffer management	Reduced TX/RX cycles	Memory usage vs radio-on time

Common Pitfalls

1. Not Measuring Before Optimizing

Power optimization without baseline measurement wastes effort. Measure current consumption in each state (TX, RX, idle, sleep) before any optimization. Post-optimization measurements verify improvements. Without measurement, claimed power savings may be illusory or the wrong bottleneck was targeted.

2. Enabling Deep Sleep Without Implementing Persistent State

Deep sleep resets RAM. Application state (connection credentials, cached values, pending transmissions) must be saved to non-volatile storage before sleeping. Devices that lose state on each sleep cycle spend excessive energy re-establishing context after every wake cycle.

3. Optimizing RF Power Without Measuring System Power

Reducing TX power from +20 dBm to +10 dBm saves RF power but may have minimal impact on total system consumption if the MCU and sensors dominate. Profile the complete power budget: RF, MCU, sensors, display, and peripherals. Attack the largest consumers first.

4. Forgetting That Power Saving Increases Latency

Modem sleep, light sleep, and deep sleep all increase response latency. A device in deep sleep that wakes only every 10 minutes cannot respond to commands sooner than 10 minutes. Design power levels with explicit latency requirements — “must respond within X seconds” determines the maximum allowable sleep interval.

🏷️ Label the Diagram

💻 Code Challenge

45.9 Summary

This chapter covered Wi-Fi power optimization for battery-powered IoT devices:

• Power-Saving Modes: Wi-Fi modem sleep, light sleep, and deep sleep configurations to dramatically reduce power consumption
• Battery Life Calculations: Duty cycle analysis showing how to extend battery life from days to years
• Deep Sleep Implementation: ESP32 code patterns for periodic wake-transmit-sleep cycles
• Static IP Optimization: Eliminating DHCP overhead to reduce connection time and energy
• Wi-Fi 6 TWT: Target Wake Time for next-generation power optimization with sub-second latency
• Troubleshooting Guide: Common Wi-Fi issues and solutions for IoT deployments

45.10 See Also

For deeper exploration of related topics:

• Wi-Fi Power Consumption - Battery life calculations and power state modeling
• Wi-Fi 6 Dense Deployment Review - TWT scheduling in high-density networks
• HTTP/WebSocket Implementation - Protocol efficiency for power-constrained devices
• Energy Harvesting{target=“_blank”} - Solar/RF energy for battery-free operation

45.11 What’s Next

If you want to…	Read this
Review theoretical Wi-Fi power consumption	Wi-Fi Power Consumption
Learn HTTP and WebSocket communication	Wi-Fi HTTP & WebSocket
Work through comprehensive lab	Wi-Fi Comprehensive Lab
Understand security for power-constrained devices	Wi-Fi Security and Provisioning
Compare power with other wireless	Mobile Wireless Technologies Basics