The Coexistence Challenge
When a Bluetooth module shares a 2.4 GHz radio with Wi-Fi on the same PCB, the two protocols compete for airtime on overlapping channels. Without active coexistence management, BLE throughput can drop by 40–70%, and Wi-Fi latency can spike to hundreds of milliseconds. This is not a theoretical concern — it is the single most common integration issue in dual-mode designs.
This article covers the mechanisms, hardware signals, and firmware strategies that make coexistence work reliably.
Spectrum Overlap: Where Collisions Happen
Wi-Fi occupies 20 or 40 MHz channels in the 2.4 GHz ISM band. BLE uses 2 MHz channels spaced 1 MHz apart, hopping across 37 data channels.
| Wi-Fi Channel | Frequency Range (MHz) | BLE Channels Affected |
|---|---|---|
| Ch 1 | 2412–2432 | 0–7 |
| Ch 6 | 2437–2457 | 12–19 |
| Ch 11 | 2457–2477 | 22–27 |
When Wi-Fi is transmitting on Ch 6, BLE channels 12–19 experience elevated noise floor and packet loss. Adaptive frequency hopping (AFH) reclassifies these channels as “bad” and avoids them — but only after experiencing enough errors to trigger reclassification, which takes multiple connection intervals.
Hardware Coexistence Signals
The industry-standard approach uses three dedicated GPIO lines between the Wi-Fi and BLE chips (or within a combo chip):
| Signal | Direction | Function |
|---|---|---|
| WLAN_ACTIVE (PTA_REQ) | Wi-Fi → BLE | Wi-Fi is about to transmit; BLE should defer |
| BT_ACTIVE (PTA_PRI) | BLE → Wi-Fi | BLE has a high-priority event (scan, connection) |
| BT_PRIORITY (PTA_STATUS) | BLE → Wi-Fi | 1 = high priority (audio/HID), 0 = low priority (data) |
This 3-wire PTA (Packet Traffic Arbitration) interface is defined in IEEE 802.15.2 and supported by most modern combo chips (nRF5340 + nRF7002, ESP32, CYW43455, etc.).
Timing is critical. The Wi-Fi chip asserts WLAN_ACTIVE 30–50 μs before the RF transmission starts. The BLE controller must abort any pending TX within this window. If the signal arrives after the RF chain is already active, the packet is lost.
Coexistence Priority Schemes
Wi-Fi Priority (Default)
Wi-Fi always wins the arbitration. BLE defers every time Wi-Fi is active. This maximizes Wi-Fi throughput but causes BLE connection drops if Wi-Fi traffic is sustained (e.g., during a large download).
BLE Priority
BLE always wins. This guarantees BLE latency but severely degrades Wi-Fi throughput. Rarely used in practice.
Time-Division Arbitration (Recommended)
Both protocols alternate based on a negotiated schedule. The coexistence controller grants time slices. BLE gets priority during connection events and scan windows; Wi-Fi gets priority during beacon reception and data TX/RX. The key parameters:
- BLE connection interval: Set to 30–100 ms. Shorter intervals consume more airtime but reduce latency.
- Wi-Fi listen interval: Typically 100 ms (DTIM = 1) to 1000 ms (DTIM = 10). Longer intervals free airtime for BLE.
- Guard time: 150 μs minimum between protocol switches to allow RF settling.
Antenna Sharing vs. Separate Antennas
Single Antenna with SPDT Switch
A RF switch (e.g., Skyworks SKY13330) connects the antenna to either the Wi-Fi or BLE RF path. The switch control is driven by the coexistence logic. This saves BOM cost and PCB area but introduces insertion loss (0.5–0.8 dB) and requires careful timing — the switch must settle before RF transmission begins.
Dual Antennas
Each protocol has its own antenna with ≥ 20 dB isolation (typically achieved with orthogonal polarization or spatial separation of λ/4 ≈ 3 cm at 2.45 GHz). This avoids the switch entirely and allows simultaneous operation, but requires more PCB area and antenna tuning.
| Approach | BOM Cost | PCB Area | Isolation | Simultaneous Operation |
|---|---|---|---|---|
| SPDT switch | +USD 0.15–0.30 | Small | N/A (switched) | No |
| Dual antenna | +USD 0.30–0.50 | Large | 20–30 dB | Yes |
For most IoT gateways and smart home hubs, a single antenna with SPDT switch is sufficient. Dual antennas are warranted for applications requiring concurrent BLE audio and Wi-Fi streaming.
Software-Level Mitigations
When hardware PTA signals are unavailable (e.g., using two separate chips without coexistence GPIOs), software mitigations can partially recover performance:
- BLE AFH channel blacklist: Manually blacklist Wi-Fi channels in the BLE host. For example, if Wi-Fi is on Ch 6, disable BLE channels 12–19 at initialization. This avoids the error-based learning period.
- Wi-Fi power save with DTIM tuning: Increase DTIM interval to 3–10 to reduce Wi-Fi listen frequency, giving BLE more airtime.
- Staggered scan windows: Ensure BLE scan windows do not overlap with Wi-Fi TX bursts. On ESP32, configure BLE scan duration to 30 ms with 100 ms interval; Wi-Fi uses the gaps.
- Adaptive BLE connection interval: When Wi-Fi is active (detected via RSSI monitoring), increase BLE connection interval to 200+ ms. When Wi-Fi is idle, reduce to 30 ms for responsiveness.
These workarounds are never as effective as hardware PTA, but they can reduce BLE packet loss from 30% to under 10% in typical traffic conditions.
Measuring Coexistence Performance
The key metrics to validate in a coexistence design:
| Metric | Target | Measurement Method |
|---|---|---|
| BLE packet loss rate | < 2% (idle Wi-Fi), < 10% (sustained Wi-Fi) | BLE sniffer + Wi-Fi traffic generator |
| Wi-Fi throughput | > 85% of standalone | iperf3 with BLE active |
| BLE connection stability | No drops in 24h | Long-run logging |
| Wi-Fi association time | < 3 s with BLE scanning | Time from auth to connected |
Always test with realistic Wi-Fi traffic — not just beacon monitoring. Sustained TCP throughput (e.g., OTA firmware download) is the worst case for BLE coexistence.
Design Checklist
- Verify PTA signal routing: 3 wires, matched length (< 5 mm skew), no vias if possible
- Set BLE AFH blacklist to match the Wi-Fi channel at boot
- Configure BLE connection interval ≥ 30 ms; use 100 ms for background data
- Enable Wi-Fi power save; set DTIM ≥ 3 if BLE traffic is significant
- If using SPDT antenna switch: verify switch settling time < RF TX ramp-up time
- If using dual antennas: measure isolation with a VNA; target ≥ 20 dB
- Test with worst-case Wi-Fi load (iperf3 TCP stream) and verify BLE metrics
- Check power consumption: coexistence arbitration adds 1–3 mA average during dual-active periods
Getting coexistence right is not optional. In any Bluetooth module design that also runs Wi-Fi, the coexistence strategy must be defined before the schematic is finalized — retrofitting PTA signals after layout is exponentially harder.