How Do Wi-Fi and BLE Coexist in the 2.4 GHz Band?

Detailed Explanation

The 2.4 GHz ISM band is shared by Wi-Fi, BLE, Zigbee, Thread, and microwave ovens. Products that combine Wi-Fi and BLE in the same hardware — which is now the default for connected consumer IoT products — must actively manage coexistence to prevent the two radios from degrading each other. The mechanisms available depend on whether the radios are integrated on the same die or implemented as separate chips.

2.4 GHz Channel Structure and Overlap

Understanding how the two protocols use the spectrum is the foundation for designing around the interference.

Wi-Fi 2.4 GHz (IEEE 802.11b/g/n):

• 13 channels (Australia/EU) spaced 5 MHz apart, each 20 MHz wide
• Three non-overlapping channels: 1 (2412 MHz), 6 (2437 MHz), 11 (2462 MHz)
• In Australia, channel 13 (2472 MHz) is also permitted

BLE 2.4 GHz:

• 40 channels × 2 MHz each, spanning 2402–2480 MHz
• 3 advertising channels: 37 (2402 MHz), 38 (2426 MHz), 39 (2480 MHz)
• 37 data channels: 2404–2478 MHz, accessed via adaptive frequency hopping

BLE advertising channels 37, 38, and 39 were deliberately placed to sit between the Wi-Fi channels 1, 6, and 11. However, BLE data channels (used during connected communication) span the full band and overlap with any active Wi-Fi channel.

Overlap summary:

Frequency planning recommendation: prefer Wi-Fi channel 11 over channel 1 for dual-radio products. Wi-Fi channel 1 directly overlaps BLE advertising channel 37, degrading BLE discovery and connection establishment. Channel 11 leaves a clear gap to channel 39. If using a private AP that can be configured, set it to channel 11.

Coexistence Mechanisms

Time-Division Multiplexing (TDM)

The most common mechanism in integrated dual-radio SoCs. A hardware or firmware arbiter grants exclusive antenna access to one radio at a time. The two radios cannot transmit simultaneously; the arbiter schedules grants based on pending traffic and priority configuration.

At any instant, the radio either:

• Runs a Wi-Fi transaction (beacon, data frame, ACK exchange)
• Runs a BLE transaction (advertising packet, connection event)
• Is idle (no pending traffic from either radio)

The duty cycle each radio receives depends on how often each requests the channel and how long each transaction takes. A BLE connection event at 500 ms interval takes approximately 0.5 ms of channel time; a Wi-Fi TCP ACK exchange takes approximately 0.5–2 ms. At these rates, BLE at 500 ms CI takes less than 0.1% of channel time, leaving Wi-Fi largely unaffected. At 20 ms CI, BLE takes approximately 2.5% of channel time — still manageable. The problem arises when BLE scanning (continuous channel monitoring) or dense BLE advertising is used simultaneously with Wi-Fi bulk transfer.

Packet Traffic Arbitration (PTA)

PTA is a hardware signalling interface between two independent radio chips that allows each to inform the other of pending transmissions. A typical PTA interface has three signals:

• REQUEST: from BLE chip to Wi-Fi chip — "I need the channel"
• PRIORITY: from BLE chip — indicates urgency (high: connection event, low: advertising)
• GRANT: from Wi-Fi chip back to BLE chip — "channel is yours for N µs"

The Wi-Fi chip defers its own transmission when GRANT is asserted for BLE, and vice versa. The arbiter policy (which radio wins when both request simultaneously) is configurable.

ESP32 Coexistence

The ESP32 integrates both Wi-Fi and BLE on a single die with a single shared antenna. Coexistence is managed by Espressif's software coexistence framework (accessed via esp_coex.h).

Default behaviour: Wi-Fi station mode + BLE enabled simultaneously. The firmware arbiter uses a time-sharing scheme where BLE and Wi-Fi alternate channel access. BLE receives guaranteed time slots for connection events; Wi-Fi receives the remaining time.

Configuring coexistence preference:

#include "esp_coexist.h"

/* Prefer Wi-Fi over BLE when both contend for the channel */
esp_coex_prefer_t preference = ESP_COEX_PREFER_WIFI;
esp_coex_preference_set(preference);

/* Or prefer BLE for latency-sensitive applications */
esp_coex_preference_set(ESP_COEX_PREFER_BT);

/* Or balanced (default): */
esp_coex_preference_set(ESP_COEX_PREFER_BALANCE);

Coexistence performance on ESP32 (typical, from Espressif application note):

These are order-of-magnitude figures based on Espressif's published coexistence application note under typical conditions. Actual performance depends on router proximity, network congestion, and BLE activity pattern.

ESP32 antenna sharing: the ESP32 has a single PCB trace or connector for the shared RF front-end. A hardware RF switch (internal to the ESP32 module) selects between BLE and Wi-Fi paths under arbiter control. The antenna should be designed for the 2.4 GHz band (not narrowband), with keepout zones respected for both protocols.

nRF52 + nRF7002 Coexistence (Separate Dies)

Nordic's nRF7002 is a dedicated Wi-Fi 6 companion chip intended for use alongside an nRF52 or nRF53 BLE host SoC. Because the two radios are on separate dies, they can in principle operate concurrently — they need separate antennas or careful RF isolation.

PTA hardware interface (nRF Connect SDK):

Enable in prj.conf:

CONFIG_WIFI_NRF700X_COEX=y

The nRF7002 and nRF52 communicate via a 3-wire PTA interface (GRANT, REQUEST, PRIORITY) wired between their GPIO pins. Zephyr's coexistence layer handles the arbitration: when a BLE connection event is scheduled, it asserts REQUEST to the nRF7002, which defers its transmit until after the BLE event completes.

Antenna isolation: with separate antennas, target a minimum of 20 dB isolation between the BLE and Wi-Fi antenna ports. On a 2-layer PCB at 2.4 GHz, 20–25 mm between antennas typically provides 20–25 dB isolation. An RF metal shield between the two antenna areas increases isolation to 40+ dB.

Zigbee and Thread Interaction

Zigbee (IEEE 802.15.4) also operates in the 2.4 GHz band and uses 16 channels at 5 MHz spacing between 2405–2480 MHz. Zigbee channel 26 (2480 MHz) coincides with BLE advertising channel 39; Zigbee channels 11–14 overlap with Wi-Fi channel 1; Zigbee channels 23–26 overlap with Wi-Fi channel 11.

For products combining Wi-Fi and Zigbee or Thread, the coexistence challenge is similar to Wi-Fi + BLE but without the same level of mature TDM firmware support. Thread and Matter devices increasingly rely on dedicated co-processor chips (such as the Silicon Labs MGM210P or Nordic nRF21540 PA/LNA) with PTA support to manage this.

Design Considerations

• Choose a dedicated Wi-Fi channel: if you control the AP configuration (private IoT network or managed deployment), fix the Wi-Fi channel to channel 11 (AU) and document this in the deployment guide. Avoid auto-channel selection on private networks where BLE coexistence matters.
• Increase BLE connection interval during Wi-Fi bulk transfers: during OTA firmware downloads, video streaming, or large data uploads, increase the BLE connection interval to 500 ms or longer via bt_conn_le_param_update(). This reduces the BLE slot request rate and frees more channel time for Wi-Fi.
• Use ESP_COEX_PREFER_WIFI during throughput-critical operations: if the application has burst Wi-Fi events (OTA, sensor data upload), set esp_coex_prefer_t preference to ESP_COEX_PREFER_WIFI for the duration and restore balance or BLE preference when done.
• Separate antennas for high-isolation designs: if BLE link reliability is critical (e.g. a BLE medical device that must also maintain Wi-Fi connectivity), specify separate antennas with explicit RF keepout zones and verify antenna-to-antenna isolation with a VNA or spectrum analyser. 25 dB isolation is a reasonable target.
• Test coexistence with both radios active simultaneously: most firmware QA tests BLE and Wi-Fi independently. The coexistence failures — BLE connection drops during Wi-Fi OTA, Wi-Fi disconnects during dense BLE advertising — only appear under simultaneous operation. Build a coexistence test: run iperf3 UDP over Wi-Fi while maintaining a BLE connection with 100 ms interval and active notifications; measure packet loss on both sides.
• Zeus Design designs dual-radio IoT products combining Wi-Fi and BLE on ESP32, nRF, and custom platforms — covering RF layout, antenna selection, coexistence configuration, and production RF testing.

Common Mistakes

• Using Wi-Fi channel 1 for a product that also uses BLE: Wi-Fi channel 1 (2402–2422 MHz) directly overlaps BLE advertising channel 37 (2402 MHz), causing advertising failures and slow BLE discovery. Use channel 11 whenever dual-radio operation is in scope.
• Enabling BLE scanning simultaneously with Wi-Fi bulk transfer: BLE scanning places the BLE radio in near-continuous receive mode, requesting channel access at a very high rate and substantially reducing Wi-Fi throughput. If the product needs to scan for nearby BLE devices, do it during Wi-Fi idle periods rather than during active transfers.
• Testing BLE and Wi-Fi independently and assuming coexistence works: the coexistence problems — dropped BLE connections, degraded Wi-Fi throughput, missed BLE notifications — are only observable when both radios are active simultaneously. Always run a combined coexistence stress test as part of firmware qualification.
• No antenna keepout zone for the PCB trace antenna: placing components or copper pours in the keepout area of a PCB trace antenna detunes it and reduces range. For dual-radio modules where BLE and Wi-Fi share an antenna, the keepout zone is doubly important. Follow the module manufacturer's reference layout exactly.
• Not accounting for coexistence in the BLE connection parameter negotiation: requesting a 7.5 ms or 20 ms BLE connection interval on a product that also runs active Wi-Fi causes the BLE radio to request channel access every 7.5–20 ms. This is manageable for light Wi-Fi use but severely limits Wi-Fi throughput during data-intensive operations. Design the BLE connection interval for the worst-case simultaneous Wi-Fi load, not the best-case idle state.
• Assuming the ESP32 coexistence framework handles everything automatically: the default ESP_COEX_PREFER_BALANCE is a reasonable starting point, but the right configuration depends on the application's priorities. An IoT product that occasionally streams video clips over Wi-Fi while maintaining a BLE debug connection has different needs from a wearable that primarily uses BLE with occasional Wi-Fi OTA. Profile the application behaviour and tune the coexistence preference accordingly.