RF Coexistence in Multi-Radio Embedded Devices: Why Your BLE Stack Drops When Wi-Fi Gets Busy
Put BLE and Wi-Fi on the same board, run them both under load, and something often happens that no bench test predicted. BLE connections start dropping. Not randomly, and not because either radio has a defect. They drop specifically during Wi-Fi bulk transfers, OTA updates, large telemetry syncs, and video uploads, and they recover once the Wi-Fi traffic quiets down.
This is RF coexistence, and it is one of the most consistently under-planned aspects of multi-radio embedded design. Not because engineers don’t know about it, but because it almost never surfaces in a lab environment. We’ve covered more on this in a previous post – UWB vs BLE vs Wi-Fi.Â
Basically, labs don’t generate the kind of sustained, simultaneous radio demand that a product sees in actual use. So the problem ships, and it gets diagnosed from field reports rather than from a test pass.
Why This Matters More Now
For most of embedded hardware’s history, putting multiple radios on one board was a specialized design decision, something that gateway and hub teams dealt with. Ordinary products carried one radio, and there was nothing to arbitrate.
That has changed. BLE combined with Wi-Fi is now close to a default configuration across consumer electronics, industrial IoT, and commercial connected hardware. In most of these designs, both radios live on a single combo chip with one shared RF front-end.Â
The shared front-end is what creates the coexistence problem, and it exists regardless of which vendor’s silicon is on the board and regardless of how capable that silicon is.
How the Shared Radio Front-End Actually Works
A combo chip with BLE and Wi-Fi does not let both radios transmit at the same time. An arbitration layer sits between the two radio stacks and the shared hardware, deciding on a millisecond timescale which radio gets access to the front-end at any given moment.
The diagram below shows the full structure:
As Espressif’s ESP-IDF coexistence documentation describes, the allocation shifts across four defined states: idle, connected, scanning, and connecting, with each state carrying a different time-slice proportion between Wi-Fi and BLE.Â
When Wi-Fi is idle, BLE gets a generous slice. When Wi-Fi is actively transferring data, its slice expands and BLE’s contracts. The arbitration layer adjusts this continuously based on real-time conditions.
But the problem is that BLE has firm timing requirements at the protocol level. A BLE peripheral that misses its scheduled connection interval can be treated as disconnected by the central device, because the central has no way to distinguish between a missed packet and a dropped link.
Wi-Fi during a bulk transfer holds the front-end for longer continuous windows than BLE’s connection intervals can accommodate. When arbitration is not tuned to protect BLE’s timing, Wi-Fi takes precedence by default, and BLE pays for it, in dropped connections.
The symptom shows up in three recognizable ways in production. BLE connections drop during Wi-Fi OTA updates or large data syncs. Wi-Fi throughput falls noticeably when BLE begins scanning. And in some designs, the failures are intermittent enough that they only emerge under real sustained load, making them hard to reproduce in normal testing.
Where the Industry Is Heading on This Problem
Solving coexistence has historically meant firmware work. Engineers enable Packet Traffic Arbitration between the BLE and Wi-Fi cores, adjust BLE scan windows and connection intervals to create gaps that Wi-Fi can use without disrupting BLE’s timing, and validate the results under a realistic combined load.
That approach still applies, but silicon vendors are increasingly building coexistence arbitration into hardware. NXP’s IW612 and IW623 parts both implement a central hardware Packet Traffic Arbiter that provides real-time arbitration between Wi-Fi and Bluetooth on a per-packet basis, with software algorithms available to tune its behavior. This is a meaningful shift in who carries the base responsibility for solving the problem.
The important practical detail is that enabling this hardware capability is not automatic. NXP’s own application note states that the hardware PTA arbitration can be statically enabled or disabled. Espressif’s documentation for the ESP32-C3 explicitly states that coexistence must be enabled through menuconfig, otherwise the coexistence function cannot be used.Â
A team that integrates one of these chips, validates it in a quiet RF environment, and ships without configuring the coexistence hardware is shipping a product that has the capability to manage the problem correctly, but is not using it.
This is the most common source of coexistence failures on modern silicon. It is not a hardware limitation. It is a configuration step that did not happen.
What Edge AI Adds to This Picture
On-device inference does not directly compete for radio time. Modern edge AI hardware is increasingly built around dedicated inference cores or micro-NPUs that run alongside the main MCU specifically to avoid that kind of contention. The inference workload itself does not draw on the radio front-end.
What draws on the radio is what the inference result decides to do. When a model detects an anomaly, recognizes a keyword, or crosses a threshold, it typically triggers a transmission: an alert over BLE, a compressed event clip over Wi-Fi, a status update over LTE. That transmission enters the same arbitration queue as every other radio event on the board.
Research on edge AI scheduling increasingly treats inference timing and radio access as a joint coordination problem, because separating them creates edge cases where an inference-triggered event competes poorly for radio time at exactly the moment when timely delivery matters most.
For teams designing a coexistence policy, this is worth planning for. A policy tuned around predictable periodic telemetry and scheduled OTA windows will behave differently once an inference layer adds an event-driven, unpredictable source of radio demand. The arbitration parameters that work well in one traffic model may not hold in the other.
The Cost of Finding This After the Board Is Locked
Coexistence problems found early are configuration problems. Coexistence problems found after a board is finalized are much harder to resolve cleanly. Firmware workarounds can reduce the severity, usually by sacrificing some performance on one radio to protect the other.Â
If the antenna layout does not provide adequate physical isolation between the two radio paths, firmware tuning alone may not be sufficient, and the fix requires a board revision with the associated schedule and recertification cost.
What Smart Teams Do
The teams that ship clean multi-radio products tend to follow a few practices that are not complicated but are easy to skip under schedule pressure.
1. They read the coexistence section of the vendor SDK documentation before bring-up, not during debugging. Every major combo silicon vendor, including Espressif, Silicon Labs, Nordic, and NXP, publishes application notes and SDK configuration guides specifically for coexistence.
These documents describe which registers to enable, which parameters to tune, and which traffic scenarios to validate against. Most of the configuration that teams discover they needed during field escalations was already documented before the product shipped.
2. They configure the coexistence hardware explicitly, rather than leaving it at SDK defaults. As discussed earlier, most vendor SDKs do not enable coexistence arbitration by default. Treating a default configuration as a validated configuration is where most avoidable coexistence problems begin.
3. They test under simultaneous, sustained load before the board is locked. This means running a BLE connection and a Wi-Fi bulk transfer at the same time, at the data rates and packet sizes the product will actually see in the field, not in isolation on a quiet bench. A spectrum analyzer during this test is not optional. It is what makes the arbitration behavior visible rather than inferred from symptoms.
4. They account for event-driven radio demand if the product includes any form of on-device inference. A model that triggers transmissions changes the traffic profile the arbitration system has to manage. Teams that model only their periodic telemetry and OTA traffic when tuning coexistence parameters, and then add inference later, often find that the parameters need revisiting.
5. They treat coexistence validation as a gate in the design process, not a checkbox after the fact. The engineers who avoid field escalations are not necessarily more skilled than the ones who don’t. They are more deliberate about when in the schedule this validation happens.
Conclusion
RF coexistence is not an exotic problem, but it’s one that’s hard to avoid these days with multi-radio chips increasingly becoming the norm. It is a predictable consequence of putting multiple radios on shared silicon without a deliberate coordination strategy.Â
The tools to manage it are well documented, the silicon to handle it is widely available, and the validation process is straightforward. What it requires is that the work gets done at the right point in the design cycle, before the board is locked rather than after the product is in the field.
The products that handle this well are not the ones built by teams with access to better components. They are the ones built by teams who treated radio coordination as a critical design requirement from the beginning.
If your team is working through a coexistence problem on a current design, or planning a product that will combine radios on shared silicon for the first time, embedUR’s engineering team is happy to take a look.Â
We have worked through this class of problem dozens of times across BLE and Wi-Fi combo designs from several silicon vendors, and we can help identify where the gap is and what it takes to close it. Get in touch with us here.