WiFi for Embedded

Quick Cap

WiFi brings IP-based networking to embedded devices, enabling direct internet connectivity, cloud communication, and local network access without a gateway. Unlike BLE (optimized for low-power, low-data bursts) or Zigbee (optimized for mesh), WiFi provides high throughput and native TCP/IP support -- but at the cost of significantly higher power consumption, making power management the central challenge for battery-operated WiFi devices.

Interviewers test whether you understand embedded-specific WiFi concerns: provisioning (how does a headless device get WiFi credentials?), power management (how do you keep a WiFi device alive on batteries?), and the WiFi vs BLE vs cellular decision for IoT.

Key Facts:

• 802.11b/g/n at 2.4 GHz dominates embedded; 802.11ax (WiFi 6) is emerging for IoT with Target Wake Time (TWT)
• STA mode connects to an AP as a client; AP mode creates a network; STA+AP mode enables provisioning and connectivity simultaneously
• Provisioning: The hardest UX problem -- SmartConfig, SoftAP, WPS, and BLE-assisted provisioning each have trade-offs
• Power management: DTIM interval, listen interval, modem sleep, light sleep, and deep sleep can reduce WiFi power from ~160 mA to microamps
• Security: WPA2-PSK is the baseline; WPA3-SAE adds protection against offline dictionary attacks
• Embedded modules: ESP32 (lowest cost), CC3200/CC3235 (TI, industrial), ATWINC1500 (Microchip, offloaded stack)

Deep Dive

At a Glance

WiFi Standards for Embedded

Not all WiFi standards matter for embedded. Here is what is relevant:

Why not 5 GHz for embedded? Most embedded WiFi modules are 2.4 GHz only. The 2.4 GHz band has better wall penetration (longer range indoors), and adding 5 GHz support increases module cost and power consumption. The main downside of 2.4 GHz is congestion -- it shares the band with BLE, Zigbee, and microwave ovens.

802.11ax (WiFi 6) for IoT: The key feature is Target Wake Time (TWT), which lets the AP schedule specific wake-up times for each device. Instead of every device competing to wake up at every DTIM beacon, TWT assigns each device a specific time slot. This reduces contention, improves battery life, and allows APs to serve more IoT devices. TWT is why WiFi 6 is considered a potential challenger to BLE and Zigbee for some IoT use cases.

Station vs AP Mode

STA mode is the primary operating mode for most embedded devices. The device connects to an AP, obtains an IP via DHCP, and communicates over TCP/IP. The critical implementation concern is reconnection logic: WiFi connections drop due to AP restarts, range excursions, and interference. Robust firmware implements exponential backoff reconnection with configurable retry limits.

AP mode is primarily used for initial provisioning -- the device creates a temporary AP (often named after the product), the user connects to it with a phone, and configures WiFi credentials via a web page served by the device. After provisioning, the device switches to STA mode.

STA+AP mode is supported by modules like ESP32 and allows the device to run both modes simultaneously. This is useful during provisioning -- the device can maintain its AP for configuration while also connecting to the target network to verify the credentials before committing.

WiFi Provisioning

Provisioning -- getting WiFi credentials (SSID and password) onto a headless embedded device -- is one of the hardest UX problems in IoT.

SoftAP is the most common approach for consumer IoT devices because it works universally without extra hardware. The flow:

1. Device boots with no stored credentials and starts in AP mode (e.g., "SmartPlug-Setup")
2. User connects phone to the device's AP
3. User opens a web browser (or captive portal redirects automatically)
4. User enters home WiFi SSID and password in a form
5. Device stores credentials in NVS (non-volatile storage), switches to STA mode, and connects
6. On subsequent boots, device reads stored credentials and connects directly

BLE-assisted provisioning is increasingly popular because it avoids the awkward WiFi AP switch. ESP32 supports this natively -- the device advertises via BLE, the phone app sends WiFi credentials over the BLE connection, and the device connects to WiFi without the user ever leaving their home network.

Power Management

WiFi power management is the single most important topic for battery-operated WiFi devices. Without power management, a WiFi module draws 80-160 mA continuously -- a 2000 mAh battery lasts about 12-25 hours.

Power States

DTIM and Listen Interval

The AP buffers data for sleeping stations and announces it in Beacon frames. The DTIM interval (Delivery Traffic Indication Message) tells stations how often the AP sends a special beacon indicating buffered data is available.

Timeline (DTIM interval = 3):

  Beacon   Beacon   Beacon   DTIM     Beacon   Beacon   DTIM
    |        |        |       |          |        |       |
    v        v        v       v          v        v       v
  --[B1]----[B2]----[B3]----[B+D]------[B5]----[B6]----[B+D]--
                              ^                           ^
                      Station wakes,              Station wakes,
                      checks for data             checks for data

Listen Interval is the station's setting for how many beacon intervals it sleeps between wake-ups. A listen interval of 3 with a beacon interval of 100 ms means the station wakes every 300 ms. Higher listen intervals save more power but increase latency for receiving data.

Trade-off: Increasing DTIM interval and listen interval saves power but increases the latency for push data (the AP must buffer it longer). For a device that only sends data (sensor telemetry), high listen intervals are fine because the device controls when it transmits. For a device that must receive commands promptly (smart lock), listen intervals must be short.

Security: WPA2 and WPA3

WPA2-PSK is the minimum acceptable security for embedded devices. The PSK must be strong -- WPA2's vulnerability is that an attacker who captures the 4-way handshake can attempt offline brute-force against the PSK.

WPA3-SAE solves this by using the Dragonfly key exchange, which makes each handshake attempt interactive -- the attacker cannot capture the handshake and crack it offline. WPA3 also provides forward secrecy: compromising the PSK does not reveal past traffic. Most modern embedded modules (ESP32, CC3235) support WPA3.

Embedded-specific concern: Many IoT devices ship with a default or easily guessable PSK (like the device serial number printed on the label). This is a major security risk -- interviewers may ask how you would handle credential management for IoT devices.

Embedded WiFi Modules

Architecture choices:

• System-on-Chip (SoC): ESP32, CC3235 -- WiFi + application CPU integrated. Simplest design, lowest BOM cost. Application firmware and WiFi stack share resources.
• Network Co-Processor (NCP): ATWINC1500, ESP-AT -- WiFi handled by a dedicated chip connected via SPI/UART. Host MCU sends AT commands or API calls. The host MCU can be any Cortex-M; WiFi complexity is offloaded. Higher BOM cost, but cleaner separation of concerns.

WiFi vs BLE vs Cellular Decision Matrix

This is a common interview question: "When would you choose WiFi over BLE or cellular?"

Rules of thumb:

• WiFi when the device has a power supply (plugged in) OR needs high throughput OR needs direct cloud access without a gateway
• BLE when battery life is critical AND a phone or hub is nearby AND data volumes are small
• Cellular when the device is deployed remotely with no WiFi infrastructure AND needs IP connectivity

WiFi Direct and mDNS

WiFi Direct (P2P): Enables two WiFi devices to communicate without an AP. One device acts as a "Group Owner" (pseudo-AP) and the other connects as a client. Used for device-to-device file transfer, printer setup, and screen mirroring. Less common in embedded IoT because it requires WPS for setup and does not save power compared to using an AP.

mDNS (Multicast DNS): Enables zero-configuration device discovery on local networks. A device announces itself as devicename.local -- other devices on the same network can reach it by name without a DNS server. Critical for embedded devices that use DHCP (IP address changes across reboots). The ESP-IDF provides built-in mDNS support. Example: a smart plug registers as smartplug-123.local, and the phone app discovers it via mDNS browse for _http._tcp.local.

Debugging Story: The 3 AM WiFi Dropout

A smart irrigation controller connected to WiFi and reported soil moisture data to the cloud every 15 minutes. The device worked perfectly during the day but disconnected every night around 3 AM and failed to reconnect until manually power-cycled.

The root cause was the home router's nightly firmware auto-update. The router rebooted at 3 AM, and the irrigation controller's WiFi stack detected the disconnection -- but the reconnection logic had a bug: it scanned for the SSID, found it on a different channel (the router sometimes chose a different channel after reboot), and attempted to connect. However, the firmware stored the BSSID (MAC address) of the AP along with the SSID and used a "fast reconnect" path that skipped scanning if the BSSID was known. The fast reconnect tried the old channel with the old BSSID, failed, and never fell back to a full scan.

The fix was implementing a two-stage reconnection: first attempt fast reconnect with stored BSSID/channel, then fall back to a full scan on failure, then retry with exponential backoff up to 5 minutes, then finally power-cycle the WiFi subsystem if all retries exhausted.

Lesson: WiFi reconnection logic must handle AP reboots, channel changes, and BSSID changes. Never assume the AP will come back on the same channel with the same BSSID. Always implement a fallback from fast reconnect to full scan, and add a final "nuclear option" of resetting the WiFi hardware after sustained failure.

What interviewers want to hear: You understand that WiFi's main advantage for embedded is native IP connectivity and high throughput, but its main challenge is power consumption. You can explain provisioning methods and their trade-offs -- especially SoftAP vs BLE-assisted provisioning. You know the WiFi power management hierarchy (modem sleep, light sleep, deep sleep) and the role of DTIM/listen interval. You can articulate the WiFi vs BLE vs cellular decision with concrete criteria. You understand WPA2 vs WPA3 at the conceptual level and know that WPA3-SAE prevents offline dictionary attacks.

Interview Focus

Classic Interview Questions

Q1: "How would you get WiFi credentials onto a headless IoT device?"

Model Answer Starter: "This is the provisioning problem. The most common approach is SoftAP provisioning: the device creates a temporary WiFi access point, the user connects to it with their phone, and enters WiFi credentials via a captive portal web page. The device stores the credentials in non-volatile storage and switches to STA mode. The downside is the user must disconnect from their home WiFi to connect to the device's AP. BLE-assisted provisioning avoids this -- the device advertises via BLE, the phone app sends credentials over BLE, and the device connects to WiFi without the user ever switching networks. SmartConfig is another option where the phone broadcasts credentials encoded in packet lengths, but it is fragile and has security concerns."

Q2: "How do you manage WiFi power consumption on a battery-operated device?"

Model Answer Starter: "WiFi power management operates at multiple levels. At the MAC layer, the device uses DTIM and listen intervals to sleep between beacons -- increasing the listen interval from 1 to 10 reduces the wake-up frequency by 10x. At the system level, modem sleep turns off the radio while keeping the CPU active (15-20 mA), light sleep pauses the CPU as well (under 1 mA), and deep sleep turns off everything except the RTC (5-20 uA). The critical trade-off is that deep sleep loses the WiFi connection -- reconnection takes 1-5 seconds on wake-up. For a sensor that reports every 5 minutes, I would use deep sleep with fast reconnection (storing BSSID and channel in RTC memory to skip scanning)."

Q3: "What is the difference between WPA2-PSK and WPA3-SAE?"

Model Answer Starter: "Both encrypt WiFi traffic with AES, but they differ in how the key is established. WPA2-PSK uses a 4-way handshake based on the pre-shared key -- if an attacker captures the handshake, they can attempt offline dictionary attacks against the PSK. WPA3-SAE uses the Dragonfly key exchange, which is interactive -- each authentication attempt requires communication with the AP, making offline brute-force impossible. WPA3 also provides forward secrecy: if the PSK is later compromised, previously captured traffic cannot be decrypted. For embedded devices, WPA3 is preferred but WPA2 remains acceptable with a strong PSK."

Q4: "When would you choose WiFi over BLE for an IoT device?"

Model Answer Starter: "I choose WiFi when the device needs direct internet access without a gateway, when throughput requirements exceed what BLE can provide (more than a few hundred kbps), or when the device is mains-powered so power consumption is not a constraint. Examples: a security camera streaming video, a smart plug reporting energy usage to the cloud, or an OTA update endpoint. I choose BLE when the device is battery-operated with small, infrequent data transfers and a phone or gateway is nearby -- like a fitness tracker or environmental sensor. The key question is: does the device need IP connectivity, and can it afford the power?"

Q5: "What happens when a WiFi STA device wakes from deep sleep?"

Model Answer Starter: "On deep sleep wake-up, the WiFi state is completely lost. The device must go through the full connection sequence: scan for the target SSID, authenticate and associate with the AP (the 4-way WPA2 handshake), and then obtain an IP address via DHCP. This typically takes 1-5 seconds. To speed this up, I store the BSSID and channel in RTC memory before sleeping -- on wake-up, the device can skip the scan and connect directly to the known BSSID on the known channel, reducing reconnect time to under 1 second. Using a static IP further eliminates DHCP wait time."

Trap Alerts

• Don't say: "WiFi uses very little power" -- WiFi is the highest-power wireless option for embedded. Always discuss power management when recommending WiFi.
• Don't forget: Provisioning -- a WiFi device is useless if users cannot configure the credentials. Always mention provisioning when discussing embedded WiFi product design.
• Don't ignore: Reconnection robustness -- APs reboot, channels change, DHCP leases expire. Embedded WiFi firmware must handle all of these gracefully with exponential backoff.

Follow-up Questions

• "How does WiFi 6 Target Wake Time (TWT) improve IoT battery life compared to DTIM-based power save?"
• "What is the maximum number of stations a typical embedded AP can support?"
• "How would you implement OTA firmware updates over WiFi with rollback protection?"
• "What is the difference between WiFi Direct and SoftAP mode?"

Practice

Real-World Tie-In

Smart Plug with Cloud Reporting -- A WiFi-connected smart plug (mains-powered, no battery constraint) used SoftAP provisioning with a captive portal. During production, 15% of units failed provisioning because the captive portal did not trigger on certain Android phones. The fix was adding a fallback: if the captive portal detection failed, the device served a simple web page on a fixed URL (192.168.4.1) that the user could navigate to manually. The device also stored a provisioning retry counter in NVS -- if provisioning failed 3 times, it switched to BLE-assisted provisioning as a secondary method.

Battery-Powered Environmental Sensor -- An outdoor air quality sensor used an ESP32 with deep sleep, waking every 10 minutes to read sensors, connect to WiFi, publish MQTT data, and go back to sleep. Initial battery life was 8 days. Optimization reduced it to 45-day battery life: storing BSSID/channel in RTC memory cut reconnect time from 3.5 seconds to 0.8 seconds, switching to static IP eliminated DHCP (saving 0.5 seconds), and reducing TX power from 20 dBm to 13 dBm (sufficient for 15-meter range to the AP) cut TX current by 30%.

Industrial Gateway -- A factory gateway ran in STA+AP mode simultaneously: STA connected to the factory WiFi for cloud reporting, while AP mode created a local network for configuration tablets on the factory floor. The gateway used mDNS (gateway.local) so technicians could access the configuration web UI without knowing the IP address. WPA2-Enterprise with 802.1X was required by the factory IT policy, which necessitated provisioning a client certificate onto the gateway during manufacturing -- a step that added 45 seconds to the production line per unit.