Electronics Design AU
Wireless

Wi-Fi

Wi-Fi (IEEE 802.11) design for embedded and IoT products: protocol fundamentals, provisioning, power management, and coexistence.

Wi-Fi is the default choice when an embedded product needs internet access or high-throughput local data transfer, but shipping it well requires more than picking a module: credential provisioning, power management, and 2.4 GHz coexistence with BLE all have to be designed deliberately. This subtopic covers Wi-Fi at the implementation level, below the protocol-selection decision.

What Is Wi-Fi Implementation?

This subtopic covers what it takes to actually ship a Wi-Fi-connected product: how a device gets network credentials without a keyboard (provisioning), how it manages power when Wi-Fi is one of the most power-hungry radios available to an embedded design, how it shares the 2.4 GHz band cleanly with a BLE radio, and how to choose between an integrated Wi-Fi SoC and a companion chip. For the protocol fundamentals (IEEE 802.11 generations, CSMA/CA, WPA2/WPA3), see What Is Wi-Fi?.

This subtopic is part of the Wireless topic.

Why Wi-Fi Implementation Matters

  • A device with no way to enter Wi-Fi credentials can't be provisioned in the field — hardcoding an SSID and password only works for a single fixed network; every other deployment needs a provisioning flow designed before the product ships, not bolted on afterward.
  • Wi-Fi's power budget can dominate a battery-powered product's entire design — active transmission draws 100–200 mA on a typical module, orders of magnitude more than BLE; getting sleep-mode power management wrong can turn a multi-month battery life into a multi-day one.
  • BLE and Wi-Fi sharing the same 2.4 GHz radio on one chip will silently degrade each other — without explicit coexistence handling, enabling both simultaneously reduces the effective throughput and reliability of both, in a way that's easy to miss during bring-up with only one radio active.
  • Module architecture is a decision, not a spec-sheet comparison — an integrated SoC and a companion chip added to an existing host MCU solve the same problem with very different firmware and BOM implications.

Key Concepts

  • Provisioning — the process of getting Wi-Fi credentials onto a device with no keyboard or display: SoftAP captive portal, BLE-assisted provisioning, SmartConfig/ESP-TOUCH, or Matter's PASE/CASE commissioning flow. See Wi-Fi provisioning for embedded IoT devices.
  • DTIM interval — the beacon interval multiple at which an access point buffers and delivers broadcast/multicast traffic to sleeping stations; the primary lever for modem-sleep power consumption. See Wi-Fi power management.
  • Target Wake Time (TWT) — a Wi-Fi 6 mechanism letting a station negotiate specific wake times with the AP, avoiding the DTIM-interval compromise between latency and power that older Wi-Fi generations require.
  • Coexistence (TDM / PTA) — the arbitration mechanism that lets a Wi-Fi radio and a BLE radio share a 2.4 GHz antenna or band without corrupting each other's transmissions: time-division multiplexing on integrated SoCs, or a Packet Traffic Arbiter (PTA) hardware interface on separate-chip designs. See Wi-Fi and BLE 2.4 GHz coexistence.
  • Integrated SoC vs companion chip — an integrated Wi-Fi SoC (ESP32) runs application firmware on the same chip as the radio; a companion chip (ATWINC1510, CYW43xx) adds Wi-Fi to an existing host MCU over SPI/UART, keeping the radio stack off the main application processor.

Common Mistakes

  • Hardcoding network credentials in firmware — devices with a fixed SSID/password can't be deployed to a customer's own network and expose credentials in the firmware binary. Design a provisioning flow from day one.
  • Assuming instant reconnection after sleep — re-associating with a Wi-Fi network after deep sleep takes 1–5 seconds including DHCP negotiation; firmware that assumes an immediate connection will miss data or time out.
  • Testing sleep-mode power only on the bench, against a lab router — DTIM buffering behaviour varies meaningfully between AP vendors and firmware versions; a device that sleeps correctly against one router can drop packets against a customer's actual AP hardware.
  • Enabling Wi-Fi and BLE simultaneously without coexistence configuration — on integrated SoCs this silently halves effective throughput on both radios; on separate-chip designs with no PTA wiring, it can cause outright packet corruption rather than just a throughput hit.

Common Questions

Do I need a provisioning app, or can SoftAP alone handle credential setup?

A SoftAP captive portal (the device broadcasts its own temporary access point with a web form) needs no companion app and works on any phone or laptop with a browser, making it the simplest option to ship. BLE-assisted provisioning and Matter commissioning require a companion app or ecosystem app, but give a smoother end-user flow and can carry additional setup data (device identity, room assignment) alongside the Wi-Fi credentials. See Wi-Fi provisioning for embedded IoT devices for the full comparison.

Is Target Wake Time worth implementing over standard DTIM tuning?

TWT is worth the implementation effort mainly when the access point genuinely supports Wi-Fi 6 and the product's wake schedule is predictable. It removes the classic DTIM trade-off where a longer interval saves power but adds latency to every downlink packet. On a mixed-AP-vendor deployment where some access points are still Wi-Fi 4/5, DTIM interval tuning remains the more portable lever since it works on every generation. See Wi-Fi power management for the detailed trade-off.

Should I choose an integrated Wi-Fi SoC or a companion chip for a new design?

An integrated SoC (ESP32) is the simpler default for new designs: one chip, one toolchain, a large existing ecosystem of examples. A companion chip becomes the better choice when the product already has a strong host MCU commitment (an existing STM32 codebase, a certified safety-related MCU that can't be swapped) and Wi-Fi needs to be added without replacing the application processor. See Wi-Fi module selection: ESP32 vs ATWINC1510 vs CYW43xx for the full architecture comparison. Zeus Design designs Wi-Fi hardware and firmware, including provisioning and power management, for embedded products.

Knowledge Base

Wi-Fi Fundamentals

  • What Is Wi-Fi? — IEEE 802.11 standards, 2.4 GHz vs 5 GHz bands, CSMA/CA, WPA2/WPA3 security, and power management for IoT

Provisioning

Power Management

Coexistence

Module Selection

Security

Platform Implementation

For ESP32-specific Wi-Fi setup and provisioning firmware, see ESP32 Wi-Fi setup and provisioning in the ESP32 topic.

Forum Discussions

Forum Discussions

ESP32 IoT device stops sending data after 6–8 hours but shows as connected on the AP — DHCP lease expired?

Deployed an ESP32-S3 sensor node at a customer's warehouse last week. It reads temperature and humidity every 5 minutes and POSTs the data t

Forum

Related Topics