What Is Wi-Fi?

Detailed Explanation

Wi-Fi is the dominant wireless connectivity solution for embedded and IoT products that require internet access or high-throughput local data transfer. Its ubiquity — virtually every home, office, and industrial facility has Wi-Fi infrastructure — means Wi-Fi-connected devices can be deployed without additional gateway hardware. The tradeoff is power consumption: Wi-Fi draws significantly more current than Bluetooth Low Energy or LoRa, making battery lifetime a critical design constraint for Wi-Fi IoT devices.

IEEE 802.11 generations

Wi-Fi evolves through successive generations of the IEEE 802.11 standard, each increasing maximum throughput via wider channels, higher-order modulation, and improved multiple-antenna (MIMO) techniques:

For embedded IoT products, 802.11n (Wi-Fi 4) 2.4 GHz is the most practical target: it is universally supported, offers adequate throughput for sensor data and OTA updates, and the 2.4 GHz band provides better range than 5 GHz for deployed devices.

Channel access: CSMA/CA

Wi-Fi uses Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA). Before transmitting, a station listens to confirm the channel is idle, then waits a random backoff interval before transmitting. If a collision does occur (two stations transmit simultaneously), both detect the failure via the absence of an ACK and retry after a randomised exponential backoff. This differs from Ethernet's CSMA/CD (Collision Detection), which is impractical in a radio environment where a transmitter cannot easily hear its own signal on the receive channel.

Security: WPA2 and WPA3

Modern Wi-Fi security uses:

• WPA2-Personal (PSK): a pre-shared key (the network password) is used in a 4-way handshake to derive session keys. AES-CCMP provides data confidentiality and integrity. Vulnerable to offline dictionary attacks against weak passphrases — captured 4-way handshakes can be brute-forced offline.
• WPA3-Personal (SAE): replaces PSK with Simultaneous Authentication of Equals, a Diffie-Hellman-based exchange resistant to offline dictionary attacks. Forward secrecy: capturing traffic and later obtaining the password does not decrypt previously captured sessions.

For embedded products, passphrase storage in firmware requires care — hardcoded credentials in device firmware are a common security vulnerability. Use provisioning flows (Wi-Fi provisioning apps, soft-AP setup portals) to avoid shipping devices with default or hardcoded passwords.

Power management modes

Wi-Fi power management is critical for battery-powered designs:

• Active / no power save: radio continuously active, best responsiveness, highest power (~100–200 mA average).
• Modem sleep / Light sleep: radio powers down between DTIM beacon intervals (DTIM = Delivery Traffic Indication Map, typically 100 ms). The AP buffers incoming packets until the station wakes at the next beacon. Average current: typically 10–20 mA on ESP32.
• Deep sleep: Wi-Fi stack powered down entirely; MCU wakes on a timer, reconnects, sends data, and sleeps again. Average current over the sleep-transmit cycle can be under 1 mA with infrequent wake-ups. Reconnection takes 1–5 seconds, which is too slow for latency-sensitive applications.

Practical Examples

An ESP32-based environmental monitor samples temperature, humidity, and CO₂ every 5 minutes, connects to the home Wi-Fi network, publishes the readings to an MQTT broker, and immediately enters deep sleep until the next sample interval. Average current over the cycle (5-minute sleep + ~3 second active Wi-Fi) is approximately 120 µA — achievable battery life on a 2000 mAh LiPo is many months. See ESP32 Wi-Fi setup and provisioning for the firmware implementation.

For real-world troubleshooting when Wi-Fi connections drop in deployed hardware, see the forum discussion on ESP32 Wi-Fi disconnecting in production — which covers DTIM beacon timeout, Wi-Fi reason codes, and reconnect strategies.

Design Considerations

• Wi-Fi vs BLE for your use case: Bluetooth Low Energy draws far less power and is appropriate when the device communicates with a smartphone rather than a router. Use Wi-Fi when internet connectivity, high data throughput (OTA firmware updates, video streaming), or local network access is required.
• Wi-Fi vs cellular: Wi-Fi requires existing infrastructure. For deployments in locations without Wi-Fi (remote assets, vehicles), Cellular IoT with LTE-M or NB-IoT is the appropriate alternative, at higher per-device data cost.
• Wi-Fi vs satellite: For truly remote deployments beyond cellular coverage — outback agricultural monitoring, maritime assets, or emergency telemetry infrastructure — satellite IoT using LEO constellations (Iridium, Swarm) is the only connectivity option available.
• Antenna placement: the Wi-Fi antenna (PCB trace or chip antenna on a module) must have a clear keepout area free of ground copper. Placing the module at the edge of the PCB with the antenna away from the board improves RSSI significantly.
• 2.4 GHz coexistence with BLE: both Wi-Fi 2.4 GHz and BLE operate in the same 2.4 GHz ISM band. Simultaneous operation requires coexistence management. On the ESP32, the Wi-Fi and BLE radios share the antenna and are time-multiplexed by the firmware; enabling both simultaneously reduces effective throughput of both.
• Regulatory compliance: Wi-Fi modules used in products sold in Australia must carry ACMA RCM certification. Using a pre-certified module (ESP32, ATWINC1510, CYW43xx) transfers the radio compliance burden to the module supplier; host PCB digital emissions still require independent assessment.

Common Mistakes

• Underestimating reconnection time: re-associating with a Wi-Fi network after deep sleep takes 1–5 seconds including DHCP negotiation. Applications that assume instant reconnection will miss data or time out.
• Blocking the antenna with ground copper: routing ground copper beneath or around a PCB trace Wi-Fi antenna creates a parasitic capacitance that detunes the antenna and reduces range significantly.
• Hardcoding network credentials in firmware: devices with hardcoded SSIDs and passwords cannot be deployed to different networks and expose credentials in binary firmware images. Use a provisioning mechanism from day one.
• Ignoring DTIM sleep and AP-side buffering limits: if the AP flushes buffered packets before the device wakes from modem sleep, packets are dropped silently. Test sleep-mode operation against the actual AP hardware, not just against a development router.