Architecting Multi-Radio Embedded Devices with BLE, Wi-Fi, LTE, and UWB
Every embedded product that needs to talk to the outside world starts with the same question: which radio?
For a long time, the answer was simple, because the product usually only needed to do one thing. A fitness tracker needed BLE to sync with a phone. A factory sensor needed LTE to report back to a server. One job, one radio, done.
Today the answer is more complicated, and more consequential. Because the right answer isn’t just a technical choice, it’s arguably the highest-stakes decision you’ll make on the entire product.
Get it right and you have a device that works reliably in the field for a decade. Get it wrong and you’re looking at a board respin, a recertification cycle, and a failure mode your customers will find before you do. And unlike most decisions in a product’s life, this one is nearly impossible to undo once silicon is chosen.
So the answer is no longer “which radio.” It’s increasingly “which radios, in what combination, and have you thought through everything that combination is going to cost you — in power, in board space, in firmware complexity, and in the years of maintenance that follow.”
That’s what this article is about.
Why Connectivity Decisions Matter Early
Most engineering decisions in a product’s lifecycle can be revisited. A firmware bug gets patched over the air. A mechanical tolerance gets adjusted in the next molding run. Even a processor choice, painful as it is to change, can often be recovered through a firmware port and board revision, especially when the software is built on a portable platform such as Zephyr.
Radio selection doesn’t work that way, because a radio isn’t really one decision. Radio selection is a stack of decisions that get poured into the board layout and never separated again.
Choosing BLE plus Wi-Fi plus UWB means choosing a chipset (or combination of chipsets) that supports that exact set, an antenna configuration that gives each radio enough isolation to not desensitize the others, a power budget that assumes certain radios are off most of the time, and a certification path that covers every one of those radios in every region the product ships to.
Each of those downstream decisions assumes the radio set is fixed. If a customer asks six months into development for UWB ranging that wasn’t in the original spec, the answer usually isn’t “we’ll add a UWB chip.” It’s closer to “we need a new board revision, a new antenna layout, a new RF coexistence study, and a new certification cycle” — months of work triggered by a requirement that, on paper, looks like adding one part to a BOM.
The reverse is just as costly. Overprovisioning — adding LTE “just in case,” or UWB because a competitor’s spec sheet has it, means paying for certification, power budget, and board space for a radio that may never get used. On a product shipping in volume, that’s not a rounding error; it’s margin, gone, on every unit, for the life of the product.
Understanding the Role of Each Radio
Once the product features are clear, the next step is to match each feature to the radio that solves it, and resist the temptation to make one radio do a job it wasn’t built for. Each of these technologies has a narrow zone (sweet spot) where it’s the ideal answer, a much wider zone where it’s just ok, and a wide zone where it’s the wrong choice.
1. Bluetooth Low Energy (BLE)
BLE is the default for short-range, low-power interaction between a device and a phone. It’s good at presence detection in a loose sense, pairing, small data exchanges, and running for years on a coin cell.
What it’s not good at is precision. BLE signal strength (RSSI) can tell you roughly whether something is near or far, but “roughly” can mean several meters of error depending on the environment. A closed door, a person’s body, a metal cabinet can all shift the reading enough to make an access-control decision unreliable. BLE answers “is a known device: somewhere nearby vs at this specific point in space.”
2. Ultra-Wideband (UWB)
UWB exists for the question BLE can’t answer: precise distance and, with the right setup, direction. Using time-of-flight measurements across a wide spectrum band, UWB can resolve position to within centimeters, largely independent of the interference and multipath issues that make BLE’s RSSI unreliable indoors.
This is why it has become the standard for secure ranging, proving a credential is physically at the door, not just somewhere in the building. It is used for spatial awareness use cases like asset tracking or hands-free unlock.
The tradeoff is power and cost. UWB radios draw more current than BLE and add bill-of-material cost, so they show up only when the product genuinely needs spatial precision, not as a general-purpose connectivity radio.
3. Wi-Fi
Wi-Fi is the high-bandwidth, infrastructure-dependent option. It’s the right choice when a device needs to move real data, such as firmware updates, video, logs, large configuration syncs, and when it can rely on existing network infrastructure being present and powered.
Wi-Fi’s weaknesses are exactly its dependencies: it needs an access point in range, it draws meaningfully more power than BLE (especially when maintaining an active connection), and it inherits whatever reliability problems exist on the local network. A device that only has Wi-Fi has no story for “what happens when the network is down,” which is precisely the gap LTE fills.
4. LTE
LTE (or cellular more broadly) is the answer to “this device needs to reach the outside world regardless of what local infrastructure does or doesn’t exist.” It doesn’t depend on a router, a switch, or anyone’s IT configuration. It depends on a SIM and a cell tower. That independence is also its cost.
Cellular modules are more expensive, carry recurring data plan costs, and consume more power than any of the other three radios discussed here. LTE earns its place on a board when a device going silent because someone unplugged a switch is unacceptable.
5. Thread
Thread is worth understanding separately from BLE and Wi-Fi, even though it often ships on the same combo silicon. It’s a low-power, IPv6-based mesh networking protocol built specifically for IoT devices. Where BLE connects a device to a phone and Wi-Fi connects it to the internet, Thread connects groups of devices to each other and to a border router, forming a self-healing mesh that doesn’t depend on a central access point staying online.
Its sweet spot is dense deployments of battery-powered nodes that need to communicate reliably without individually maintaining a Wi-Fi connection — think building sensors, industrial monitoring arrays, or smart lighting grids.
Many modern Wi-Fi combo chips from Silicon Labs, Nordic, and NXP already include Thread support alongside BLE, so the incremental BOM cost is often minimal. The decision is less about hardware and more about whether your application architecture can take advantage of the mesh.
6. Zigbee
Zigbee occupies similar territory to Thread — low power, mesh networking, short-range IoT — but with a longer installed base and deeper penetration in industrial and building automation markets. Where Thread is IP-native and designed with future interoperability in mind, Zigbee has decades of deployed infrastructure behind it, particularly in smart energy, HVAC, and industrial control environments where ripping out existing infrastructure is not an option.
Like Thread, Zigbee frequently ships bundled on combo chips alongside Wi-Fi and BLE. For products intended for environments where a Zigbee coordinator is already present or where the customer base expects Zigbee compatibility, it earns its place without adding significant BOM cost. For greenfield deployments with no existing Zigbee infrastructure, Thread’s IP-native architecture is generally the more future-proof choice.
Summary Pattern — Which Radio Answers Which Question:
- BLE answers presence and pairing
- UWB answers precise location
- Wi-Fi answers high-bandwidth data movement
- LTE answers infrastructure independence
- Thread answers low-power mesh networking in IPv6-native environments
- Zigbee answers mesh networking in established IoT and building automation ecosystems
There’s a lot more interesting comparisons and contrasts in our previous post – UWB vs BLE vs Wi-Fi for Indoor Location Tracking.
Common Multi-Radio Architectures
In practice, most multi-radio products fall into a handful of recognizable patterns, and which pattern fits depends less on what the radios do individually and more on how tightly they need to be coordinated. Here are four common multi radio approaches:
i) Single SoC, Multiple Integrated Radios.
Many modern wireless SoCs bundle BLE and Wi-Fi (and sometimes Thread or Zigbee) into a single chip with shared RF front-end logic. This is the simplest path when the radio set aligns with what the SoC vendor offers: one part number, one toolchain, one set of drivers, and coexistence handled to varying degrees by the vendor’s firmware.
The constraint is that the product’s radio requirements must fit within what the SoC was designed to support. If the access controller needs UWB and the SoC doesn’t include it, this pattern stops being an option for that radio, no matter how convenient it is for the other two.
ii) Host Processor Plus Discrete Radio Modules
Here, a main application processor (often running Linux or a heavier RTOS) talks to separate modules for each radio it doesn’t have natively — a Wi-Fi/BLE combo module over SPI or UART, a UWB module over SPI, an LTE module over a serial AT-command interface.
This is the most flexible pattern and the one that scales best to four radios, because each module can be sourced, certified, and swapped somewhat independently. The cost is integration complexity: every module has its own driver and power sequencing requirements, and the host processor has to arbitrate between them — including managing which radios can be active at the same time without desensitizing each other.
iii) Tiered Architecture with a Connectivity Co-Processor
In more constrained designs, a small microcontroller is dedicated solely to managing radios — handling BLE and UWB, for instance — while a separate, more capable processor handles the application logic and interfaces with Wi-Fi and LTE.
This splits the problem along power and real-time boundaries: the radio co-processor can stay in a low-power state managing BLE advertising or UWB ranging windows, while the main processor only wakes for higher-level tasks.
It adds a second processor and an inter-processor communication layer, but it can meaningfully reduce overall power draw in products where BLE or UWB need to be active far more often than Wi-Fi or LTE.
iv) Cellular-Centric Architecture
For products where LTE is the primary link and everything else is secondary — remote sensors with a BLE configuration interface, for example — the LTE module often becomes the de facto main processor, running application logic on its embedded MCU and treating BLE as a peripheral feature rather than a full radio stack.
This minimizes part count and cost but constrains how much local processing or radio coordination the product can do, since the cellular module’s MCU is typically far less capable than a dedicated application processor.
Engineering Challenges in Multi-Radio Designs
Picking the right radios and the right architecture pattern gets a design to the starting line. What happens when four radios have to share one board and operate at the same time is where most of the real engineering effort goes, and where most of the surprises show up late.
i) RF Coexistence
BLE, Wi-Fi, and parts of UWB all operate in or near the 2.4 GHz band, and when they’re on the same board, they interfere with each other. A Wi-Fi transmission can desensitize a BLE receiver sitting a few millimeters away on the same PCB, causing dropped connections or missed packets that have nothing to do with either radio’s actual range.
Solving this isn’t a matter of picking good chips; it requires coexistence schemes — time-division arbitration between radios, frequency planning, and sometimes dedicated coexistence signaling lines between chips — that have to be designed in from the start and validated with real RF measurements.
ii) Antenna Placement and Isolation
Four radios usually means four antennas (or, at minimum, several), and on a small board there often isn’t a clean way to place them all without some degree of mutual coupling. An antenna tuned for UWB’s wide bandwidth has different placement and ground-plane requirements than a BLE antenna, and putting them too close together degrades both.
This is one of the reasons radio decisions can’t be deferred. Antenna placement is decided at board layout, and a layout designed for three antennas doesn’t have a clean path to “just add a fourth” without redoing the RF design around it.
iii) Power Budget and Duty Cycling
Each radio has a different power profile, and the difference between “available” and “active” matters enormously. UWB ranging and active Wi-Fi connections can draw an order of magnitude more current than BLE in a low-power advertising state.
A device that needs to run on battery for months, but also needs to maintain a UWB ranging session for security, has to carefully duty-cycle which radios are active when — UWB only during the ranging window, Wi-Fi only during sync windows, LTE only as a fallback — and the firmware managing that duty cycling has to be correct, because a bug that leaves one radio on continuously can turn a multi-month battery life into a multi-day one.
iv) Certification Across Radios and Regions
Every radio on the board needs regulatory certification, such as FCC and CE, for every region the product ships to, and these certifications aren’t independent of each other. Adding a radio, or even changing antenna placement for an existing one, can require recertifying the whole RF system.
For a product shipping to multiple regions, this multiplies: four radios across, say, North America, Europe, and a few other markets can mean a dozen or more separate certification efforts, each with its own timeline and cost, and each one that has to be redone if the RF design changes after the fact.
v) Software Abstraction
The application layer generally shouldn’t need to know whether a connection came over Wi-Fi or LTE, or whether a presence signal came from BLE or UWB. But someone has to build that abstraction, and it has to handle radios with very different connection models, latencies, and failure modes underneath a single interface.
Getting this wrong creates products where switching between radios (say, falling back from Wi-Fi to LTE when the network drops) introduces visible delays, dropped data, or inconsistent behavior that the end user experiences as the product simply being unreliable.
None of these is a separate workstream that can be solved in isolation and then assembled; they have to be reasoned about together, from early in the design, by people who understand how each piece constrains the others
Where the Industry Is Heading
A few trends are starting to reshape how these tradeoffs get made, and most of them point toward pushing more of the multi-radio complexity off the board designer’s plate and into silicon, software stacks, and standards that didn’t exist a few years ago.
1. Combo Chips are Absorbing More Radios.
The first wave of combo chips merged BLE and Wi-Fi because they were the most common pairing and shared enough RF infrastructure to make integration worthwhile. The newer wave is starting to add UWB into that mix, and a few vendors are exploring tighter integration with cellular as well.
As this continues, some of the products described earlier, like the access controller that needs BLE, UWB, Wi-Fi, and LTE, may eventually be built around two chips instead of four, with much of the coexistence work handled inside the combo part rather than designed from scratch on the board.
2. Coexistence is Moving from Board-Level Workaround to Chip-Level Feature
Coexistence between radios was something board designers solved after the fact — adding coexistence signaling lines between separately-sourced chips, tuning time-division schedules in firmware.
Newer silicon is starting to build coexistence arbitration in as a designed feature, with chips that are aware of each other’s activity and negotiate airtime automatically rather than requiring a board-level protocol to be designed and validated independently for each combination of parts.
3. UWB is Becoming Less of a Specialty Add-on
UWB’s role was usually kept as a radio added only when a product specifically needed that capability. As UWB chips get cheaper and smaller, and as ecosystems (particularly around digital car keys and access control) standardize on UWB for proximity verification, it’s increasingly showing up as a default inclusion in certain product categories. This shifts UWB from “the radio you add if you need precise ranging” toward “the radio you include by default in this category, the way BLE became default a decade ago.”
4. Software Abstraction Layers are Maturing
The idea of a connectivity manager — a software layer that gives the application a single “connected/disconnected” interface regardless of which radio underneath provides it — isn’t new, but until recently most of these were built in-house, per product, with all the inconsistency that implies.
Some RTOS vendors and silicon vendors are starting to ship more complete connectivity stacks as part of their SDKs, covering radio selection, fallback logic, and power state management together. This is reducing the amount of glue code a multi-radio product needs to write from scratch.
Closing Thoughts
BLE, Wi-Fi, LTE, and UWB modules are well-documented, widely sourced, and individually well understood. What’s hard is the part that doesn’t show up on any single chip’s datasheet: how they behave once they’re sharing a board, a power budget, and an antenna layout — and how that combination holds up across years of firmware updates and certification cycles in the field.
That’s the gap between a product that works in a lab demo and one that works on a loading dock in winter, on a battery that has to last a year, and on a network connection that drops without warning. Closing that gap isn’t a single decision. It’s dozens of smaller ones, made early, by people who’ve seen where these designs tend to go wrong before they go wrong.
This is the kind of problem embedUR works on with clients — taking a product from “here’s what it needs to do” to a board and firmware architecture that holds up once it’s shipped, across the radios, the power budget, and the years of updates that follow.
If you’re working through a multi-radio architecture decision and want a second set of eyes before it’s locked into silicon, talk to embedUR’s connectivity team. The earlier this conversation happens, the more options stay open.
