UWB vs BLE vs Wi-Fi for Indoor Location Tracking: A Firmware Engineer's Decision Framework
The accuracy spec is the easiest part of choosing an indoor positioning radio. “UWB gives you centimeters. BLE gives you meters. Wi-Fi lands somewhere between.” That comparison fits on one slide and takes five minutes to present. What does not fit on that slide is the six months of firmware work that follows. Each radio creates a different engineering reality.
Ultra-Wideband (UWB) needs precise timing, factory calibration for every unit, and a ranging protocol you build yourself. Bluetooth Low Energy (BLE) hands you a working radio stack in days, then buries your team in signal processing and filter tuning for months. Wi-Fi reuses infrastructure you already have, but its software footprint is the heaviest of the three and its long-term stability problems show up only after deployment.
This article is for firmware teams building custom devices: asset tags, medical equipment trackers, vehicle-mounted sensors, consumer products like Apple’s AirTag. If you own the radio stack, the power budget, and the hardware integration, this framework will help you choose. If you are deploying a vendor platform like Cisco DNA Spaces or Aruba RTLS on existing infrastructure, the firmware decisions described here do not apply to you.
What People Actually Build With Indoor Positioning
Indoor positioning is not one problem. It is several distinct product categories, each with different accuracy needs, infrastructure assumptions, and radio choices. The technology makes more sense when you see what real deployments look like.
a) Factory asset tracking (UWB): Volkswagen Slovakia runs a UWB-based real-time location system (RTLS) built with Qorvo/Decawave radios to track machines and vehicles across its production floor. The system refreshes positions every 333 ms with 99.98% reliability, and tags last over a year on battery. VELUX deployed a similar UWB system and reported a 10% productivity increase and 50% improvement in maintenance performance. These are production systems running at factory scale, not pilot projects..
b) Hospital equipment tracking (BLE): The U.S. Department of Veterans Affairs tracks high-value medical equipment across seven Florida hospitals using BLE tags and gateways from Kontakt.io. Room-level accuracy of roughly 3 meters answers “which room is this infusion pump in?” at lower cost than the active RFID network it replaced.
c) Digital car keys and consumer tags (UWB + BLE): Apple CarKey, BMW Digital Key Plus, and Hyundai/Genesis all use UWB transceivers in the vehicle to range against the owner’s phone, enabling passive entry as you walk up. Apple’s AirTag pairs UWB precision finding (~10 cm at short range) with a BLE discovery mesh for broader coverage. In both cases, firmware handles UWB ranging sessions, BLE advertising, power management, and secure protocol execution.
d) Smart building presence (Wi-Fi): For zone-level occupancy detection, many buildings already have the infrastructure. Cisco DNA Spaces and Aruba RTLS use existing enterprise access points to locate Wi-Fi devices and tags without custom firmware on the APs. The location engine runs in cloud software. But when you are building the tag or sensor node itself, firmware complexity returns.
These products span a wide range of requirements. What determines which radio fits is not just the accuracy spec. It is how each radio measures position, what infrastructure it needs, and what that means for the firmware your team writes.
How Each Radio Measures Position
Every indoor positioning system has the same basic physical setup. Anchors are small radio units mounted at fixed, known positions on ceilings or walls. Tags are small devices attached to the things you want to track: forklifts, infusion pumps, people wearing badges.
The anchors and tags exchange radio signals, and a location engine calculates the tag’s position from those exchanges. Signals radiate in all directions (omnidirectional), not as a focused beam. No single anchor can determine position on its own. It takes at least 3 anchors with good geometry to fix a 2D position, 4 for 3D.
When this article talks about firmware, it means the software running on your tag: managing when the radio wakes, how it transmits, and how aggressively it sleeps between sessions. Most teams buy vendor-supplied anchor hardware and concentrate their custom engineering on the tag side.
Here is what each radio actually does to measure position:
i) UWB measures time-of-flight: A tag sends a signal, an anchor responds, and the system calculates distance from the round-trip time. Under good conditions, this delivers 10–30 cm accuracy. UWB’s biggest physical constraint is line-of-sight. Through drywall and lightweight partitions, the signal passes with minimal loss. Through concrete, metal shelving, or steel racks, it degrades severely.
Even a single person standing between tag and anchor can add roughly a meter of position error. This is why anchor placement and redundancy matter more for UWB than for the other two radios. Qorvo recommends deploying at least 4 anchors so the tag always has clear sightlines to 3, even when one path is blocked.
The effective range per anchor is roughly 50–100 m indoors with clear sightlines, but drops sharply with obstructions.
Deployment guides recommend 15–20 m spacing between anchors, with tighter spacing around steel racks or thick walls. For a 10,000 ft² warehouse, that means roughly 12–20 anchors in a perimeter-plus-interior pattern. Not millions, as you might fear, but still a significant dedicated infrastructure investment because UWB networks do not already exist in most buildings.
ii) BLE measures signal strength or signal direction: Two modes serve different accuracy needs. RSSI-based positioning (received signal strength indicator) maps signal strength to approximate distance zones: “immediate” (under 0.5 m), “near” (0.5–3 m), or “far” (beyond 3 m). Inherently noisy. Best suited for room-level presence detection, not precise ranging. Bluetooth 5.1 direction finding takes a different approach: multi-antenna locators mounted in the ceiling estimate the angle of arrival (AoA) from simple BLE tags, reaching sub-meter accuracy (around 0.5 m) in well-engineered setups.
The infrastructure trade-off between these two modes matters. RSSI zoning needs many cheap beacons spread across rooms. AoA needs fewer but more expensive multi-antenna locators (Quuppa-class hardware), each covering a cone-shaped area. Some buildings already have BLE infrastructure from existing IoT deployments, which lowers the barrier further. Of the three radios, BLE has the lowest entry cost for zone-level positioning.
iii) Wi-Fi trades accuracy for ease of deployment: The IEEE 802.11mc standard defines fine timing measurement (FTM) for distance estimation between APs and clients. With cooperating access points and wide (80 MHz) channels, 802.11mc achieves 1–2 m accuracy. Legacy RSSI triangulation with narrower channels lands at 5–10 m in cluttered environments. Both good enough for many “find large recognizable objects in large spaces” think hospital, not warehouse.
Wi-Fi has one practical advantage the other radios cannot match: it handles walls and obstructions better. At 2.4 GHz, Wi-Fi signals pass through concrete and brick with far less loss than UWB at 6–8 GHz. Wi-Fi access points also transmit at far higher power than BLE beacons, giving them more headroom to punch through dense materials. Check out this post for some creative non- data transmission uses of Wi-Fi.
BLE operates at the same 2.4 GHz frequency and penetrates walls just as well physics-wise, but its lower transmit power means it runs out of range sooner through heavy construction. The result: Wi-Fi is the most forgiving radio in buildings with thick walls or concrete corridors.
Wi-Fi’s range per AP matches normal coverage: tens of meters indoors. Cisco recommends APs every 15–23 m for location-grade density, covering 2,500–5,000 ft² each, with at least 3 APs hearing each device. Many enterprise buildings are already close to this density. Reaching 1–3 m accuracy with round-trip time often requires a few additional APs at the perimeter, but in most brownfield buildings, positioning is achievable with incremental changes rather than a full infrastructure overhaul.
All three radios solve the same geometric problem, but they live with different physical constraints. UWB delivers the best accuracy and needs the clearest sightlines. Wi-Fi handles walls and obstructions best and reuses existing infrastructure. BLE sits between: easier on power than either, but noisier in its measurements. Those trade-offs carry directly into the firmware your team writes.
Why the Radio Choice Shapes Your Firmware
Each radio’s physics creates a different engineering workload on the tag side. Here is what that looks like in practice.
UWB firmware is dominated by timing discipline: Because UWB measures nanosecond round-trip times, your firmware owns the hard real-time path: precise timestamps read over a high-speed serial link from a dedicated ranging chip (like Qorvo’s DW3xxx series), the full ranging protocol (message ordering, timeouts, retries across multiple peers), and per-unit antenna delay calibration stored in non-volatile memory.
A one-nanosecond calibration error translates to roughly 30 cm of position error, so factory calibration flows must be explicit and repeatable. The radio’s software footprint is light. The engineering discipline is heavy.
BLE firmware shifts the work from the radio to the algorithms: Chip vendors like Nordic Semiconductor provide stable, well-documented software stacks that handle the radio complexity. Getting “BLE works” to a demo is fast.
The hard part is what sits on top: scan scheduling, RSSI smoothing or AoA data processing, anomaly rejection, 2.4 GHz coexistence with other devices sharing the band, and the battery-versus-update-rate trade-off that never fully resolves. BLE’s stack can consume 80–150 KB of flash depending on profile complexity. The radio is easy. The positioning algorithms are where the months go.
Wi-Fi firmware carries the heaviest software footprint: But how heavy depends on what your tag does. A tag that only needs to be found can be simpler: it broadcasts, the infrastructure listens, and the location engine does the math. But most embedded Wi-Fi devices are not just being located. They also send sensor data, receive commands, and need firmware updates over the air. That is where the full stack hits: TCP/IP, TLS, device provisioning, and OTA update support all come with the radio.
Memory management issues like fragmentation and slow leaks pass every bench test and then surface as unexplained connectivity drops months into deployment. Provisioning across WPA2/WPA3 networks, captive portals, or enterprise setups is a major support burden. True low power is hard because Wi-Fi’s listen windows, keepalive requirements, and encrypted sessions all fight aggressive sleep.
Certification adds weeks per radio per region: UWB requires IEEE 802.15.4z compliance and often FiRa consortium interoperability testing. BLE needs Bluetooth SIG qualification plus profile-level testing with phones and gateways. Wi-Fi involves regulatory RF certification, Wi-Fi Alliance programs, and possibly protocol certifications like Matter. UWB’s regional band differences can force multiple hardware variants where BLE or Wi-Fi would need only one.
Three Inputs That Shape the Final Decision
The use cases and radio characteristics (above) help narrow the field. To make your final decision, you must consider these three additional inputs:
1. Battery budget
A tag that must last two years on a coin cell rules out Wi-Fi as a primary radio and limits UWB to short, scheduled ranging bursts. The firmware job is turning that business requirement into concrete rules: how often the radio wakes, how long it stays active, and how aggressively it sleeps between sessions. BLE’s low-power architecture gives it the most flexibility here.
2. Smartphone involvement
If a phone is the primary locating device, you inherit its OS constraints, background execution limits, and whatever radios that phone generation supports. Apple and Android handle background BLE and UWB differently, and those limits shape what tags broadcast, at what interval, and how much processing gets pushed to the cloud. This is a distinct architectural constraint that changes your firmware design.
3. Infrastructure ownership
Own the anchors and gateways, and you control calibration, duty cycle, and roaming end-to-end. Depend on building IT’s Wi-Fi or BLE beacons, and you inherit their configuration and maintenance practices. Shared infrastructure may cap achievable accuracy and add firmware complexity for edge cases you cannot predict. This distinction often matters more than the radio’s theoretical performance.
Hybrid Patterns: What Real Products Actually Ship
No single radio handles discovery, accuracy, and power well at the same time.That is why production tags almost always carry more than one radio.
The most common pattern is BLE for discovery plus UWB for precision ranging. Tags broadcast low-power BLE signals continuously for rough proximity, and the system activates UWB only when centimeter-class accuracy is needed. A sensor fusion algorithm blends BLE signal strength with UWB distance measurements, holding accuracy while keeping average power draw low.
Other patterns include Wi-Fi for network backhaul with BLE for proximity detection, and continuous BLE tracking with periodic UWB “truthing” events, where a short burst of precise UWB measurements resets any drift that has accumulated in the BLE estimates.
Each hybrid adds complexity in cross-radio scheduling, managing shared timebases, and collecting unified diagnostics. The teams that invest early in cross-radio logging and a shared power management layer tend to be the ones whose products survive past pilot.
Where Schedules Actually Slip: Certification
Regulatory certification is the milestone that most consistently pushes firmware project timelines past their original estimates.
Pre-certified radio modules reduce the burden. If you use a module that already passed RF testing, your remaining work is mainly electromagnetic compatibility (EMC), safety, and labeling at the finished-product level. But final-product EMC and safety testing are still mandatory, and teams routinely underestimate the scope until they are already in the test queue.
Custom RF designs require full FCC (US) or CE/ETSI (Europe) testing. A seemingly small change to antenna length or enclosure material can void results and force costly retesting. UWB adds a layer here: its stricter band-specific rules and line-of-sight sensitivity mean antenna placement choices that affect range and accuracy in the field also affect what you must certify and where.
You NEED to build certification milestones into your sprint planning from the start. Map out which regions you need to ship to, which test labs have availability, and what your module vendor’s pre-certification actually covers. A two-week certification delay discovered in month one is a planning adjustment. The same delay discovered in month six, when production tooling is already committed, is a project crisis.
Decision Matrix
| Use Case | Recommended Tech | Firmware Shape | Biggest Risk |
|---|---|---|---|
|
Warehouse asset tracking (cm) |
UWB + BLE discovery |
Timing-dominant RTOS, calibration manager, ranging scheduler |
Anchor calibration ops and test fixture investment |
|
Retail zone analytics |
BLE fingerprinting |
Scan scheduler, filter/estimator tasks, power policy loop |
Data quality decay as environment changes |
|
Hospital staff badges |
BLE AoA + Wi-Fi backhaul |
Hybrid coexistence scheduler, shared power manager |
2.4 GHz coexistence and array calibration |
|
Smart building presence |
Wi-Fi RSSI / RTT |
Network-stack-heavy RTOS, provisioning service, OTA pipeline |
Long-term memory stability and reconnect storms |
|
Consumer indoor navigation |
BLE + Wi-Fi (phone-centric) |
Lightweight tag firmware, cloud-side fusion |
Phone OS background execution limits |
Start With Architecture, Not Marketing
Platform vendors highlight scenarios that showcase their chipsets. Their comparison charts are built for marketing, not your firmware integration roadmap. The moment you adopt an SDK, you inherit its integration debt, its toolchain assumptions, and its backend dependencies.
You NEED to start from your desired firmware architecture (tasks, interrupts, queues, power manager, diagnostics). Map technologies into that structure, instead of letting any vendor SDK dictate it. Check SDK coupling, backend dependencies, and migration paths before you commit.
If your team is evaluating indoor positioning stacks and wants to stress-test the architecture before locking in, embedUR runs 30-minute architecture reviews. We are not a radio vendor and have no chipset to sell. The review maps your requirements to firmware topology, models your power budget, and flags certification risks with no vendor stack attached.
Having this conversation (with us) is worth more than a sprint of rework.
