Anchor density, coverage gaps, and multipath: the real engineering challenges of deploying UWB at scale

Ultra wideband (UWB) location tracking has a reputation for precision that few technologies can match. Sub-10cm accuracy in controlled conditions is a genuine claim for most providers. But controlled conditions and real-world deployments are very different things.

The gap between a vendor’s spec sheet and a functioning system is where most RTLS projects run into trouble. Reflections from metal racking, competing radio traffic, poorly placed anchors, and NLOS conditions can all degrade accuracy to the point where the investment stops making sense.

This article walks through the real engineering decisions that determine whether a UWB deployment succeeds — from RF propagation fundamentals to anchor placement geometry to the role protocol design plays in resilience. Understanding these factors is critical to understand in order to build something that works.

Why UWB deployment is harder than vendors make it look

The pitch for UWB is straightforward: it uses wide-band radio pulses to measure time-of-flight between tags and anchors with exceptional accuracy. What the pitch omits is everything that can interfere with those measurements.

Real environments are not anechoic chambers. They contain metal, people, machinery, other radio systems, and geometry that no RF simulation fully predicts. The challenges fall into three main categories:

• propagation quality: what happens to the signal between transmitter and receiver,
• anchor placement: how you design coverage, and
• protocol behaviour under load: how the system performs when you scale beyond a handful of tags.

Getting all three right requires engineering judgment, not just hardware. And it requires a vendor who is willing to talk honestly about constraints rather than promise a number and disappear.

The vendors worth trusting are the ones who ask hard questions about your environment before they quote you an accuracy figure.

RF propagation basics: line-of-sight vs NLOS in real environments

UWB ranging works best when there is a clear line-of-sight (LOS) path between a tag and at least three anchors. In LOS conditions, the first-path signal — the direct pulse — arrives cleanly, and time-of-flight measurement is straightforward.

Non-line-of-sight (NLOS) conditions occur when that direct path is blocked or partially obstructed — by a person’s body being between a tag and an anchor, by a forklift, by a steel shelving unit, or simply by the geometry of a building with columns and walls.

In NLOS conditions, the receiver may pick up a reflected or diffracted signal rather than the direct path. Since reflected signals travel further, they arrive later — which the ranging system may misinterpret as the tag being further away than it actually is. This is the core source of NLOS error.

How much this matters depends on the environment. Open warehouse floors with high anchor mounting are forgiving. Dense factory cells with machinery, low ceilings, and frequent occlusion are much harder. Entertainment venues with crowds add a further variable — a packed audience attenuates UWB signals in ways an empty venue walk-through will not reveal.

Mitigation strategies include: raising anchor height to improve LOS angles, increasing anchor density to ensure each tag always has multiple LOS paths available, and using protocol-level NLOS detection to weight or discard corrupted measurements.

The multipath problem: how reflections corrupt ranging

Multipath is related to but distinct from NLOS. Even in environments with clear LOS paths, radio signals reflect off surfaces and arrive at the receiver from multiple directions — some slightly delayed, some at different angles. The receiver has to identify which arrival is the true first-path signal and which are echoes.

UWB handles multipath substantially better than narrowband technologies like Bluetooth or Wi-Fi, because its wide bandwidth allows it to resolve signals that are separated by very small time differences. But in highly reflective environments — metal-clad walls, low ceilings, dense racking — multipath can still degrade accuracy.

The practical implication fo deploying UWB at a scale: indoor environments with high metal content are harder to deploy in, and anchor placement geometry matters more. Anchors mounted close to large reflective surfaces behave differently from those with clear space around them. A deployment methodology that accounts for this during site survey — rather than discovering it during commissioning — avoids expensive remediation later.

Eliko’s UWB AP-TWR (active-passive two-way ranging) protocol is more immune to multipath compared to TDoA since two-way ranging is a more robust way of measuring distance between two devices. Also our deployment process includes RF site characterisation before anchor positions are finalised. We identify potential multipath zones and either avoid them or account for them in the anchor plan. 

Anchor density: how many do you actually need?

This is the question that most directly drives hardware (and often software license) cost, and the honest answer is: it depends on your accuracy requirements, your environment, and your tag update rate.

The minimum for 2D positioning is three anchors per zone, enough for trilateration. In practice, four or more anchors per zone is standard — it provides redundancy (if one anchor has a degraded signal path, others compensate), improves accuracy through overdetermination, and handles NLOS conditions more gracefully.

Factors that increase required anchor density include:

• Higher accuracy requirements (sub-20cm needs more anchors than sub-1m)
• Higher obstacle density (more occlusion means more anchors needed to maintain accuracy)
• Taller ceilings (longer ranges mean fewer anchors cover more area, but at the cost of geometry quality)
• Higher tag counts with low-latency requirements (protocol capacity becomes a constraint)
• 3D positioning requirements (adds a vertical dimension that needs adequate anchor spread)

A useful rule of thumb: in a straightforward open environment, a single anchor provides reliable coverage within roughly a 30–50m radius. In a complex environment, that radius may shrink to 10–15m or less before accuracy degrades. Your deployment plan should be based on a site survey, not a formula.

Coverage gap planning: dead zones and how to eliminate them

A dead zone is any area within your intended coverage where fewer than three anchors can get a accurate distance measurement to a tag. In a dead zone, position coordinate cannot be computed — or is computed with anchor-tag distances that are too long (for example due to multipath or penetrating a material). The longer than actual distances distort the end coordinate too much so that you will experience a coordinate “hop”.

Dead zones tend to emerge from three sources:

• Geometry: columns, walls, and corners that block signal paths from multiple directions simultaneously
• Anchor placement errors: anchors installed inbetween metal beams, or other obstacles
• Environment changes: machinery moved, racking reconfigured, new walls added after the original deployment

The most reliable way to identify dead zones before go-live is a site survey with temporary anchor placement and tag-in-hand measurement walks. This reveals real-world coverage quality rather than simulated estimates.

For environments where the layout changes frequently — a reconfigurable venue space, for example — anchor placement should be designed with that flexibility in mind. Fixed anchor positions that optimise for one layout may create dead zones in another.

Eliko’s AP-TWR protocol is designed with coverage reliability in mind. Due to a more flexible network setup that does not require wired synchronisation or visibility, it’s easy to add anchors in dead zones and instantly improve the positioning accuracy.

How protocol choice affects resilience in dense RF environments

The ranging protocol — the method by which tags and anchors exchange timing information — determines not just accuracy but how a system behaves under load, in interference-prone environments, and at scale. Two protocols dominate the RTLS market: standard two-way ranging (TWR) and time difference of arrival (TDoA). Both have meaningful limitations in real-world deployments.

Standard TWR works by having a tag initiate an exchange with each anchor in turn: the tag sends a poll, the anchor responds, and the tag sends a final message. The anchor can then compute the round-trip time and derive the distance between the two devices. The problem is protocol length. Each ranging exchange requires three messages per anchor pair, and the tag must complete this handshake with every anchor it needs to be located by. In a deployment with six anchors, that’s eighteen messages per position update — per tag. As tag counts grow, the channel fills up fast. Congestion leads to packet collisions, missed exchanges, and degraded update rates precisely when the system is under the most load.

TDoA takes a different approach: tags broadcast a single short pulse, and anchors record the time of arrival. Position is computed by comparing when that pulse arrived at different anchors. This solves the congestion problem — one message per tag per update cycle, regardless of anchor count. But TDoA introduces its own constraint: it requires all anchors to share a common, highly precise time reference. Maintaining tight time synchronisation across a large anchor network adds infrastructure complexity, and any synchronisation drift directly corrupts position accuracy. TDoA also shifts all compute burden to the infrastructure side, meaning a clock fault in one anchor can silently degrade accuracy across an entire zone without an obvious failure signal.

Eliko’s active-passive TWR (AP-TWR) protocol is designed to eliminate both shortcomings. Rather than having each tag initiate its own exchange sequence, the anchor network controls scheduling — anchors initiate ranging with tags on demand, and tags respond with a single short reply. This keeps protocol length short (comparable to TDoA’s channel efficiency) while preserving the clock independence of TWR. There is no requirement for nanosecond-level synchronisation across the anchor network, because each ranging exchange is self-contained and time references are local to each anchor pair. The result is a protocol that scales to high tag densities without congestion, maintains accuracy without fragile synchronisation infrastructure, and allows the network to intelligently prioritise which tags get updated most frequently — a forklift approaching a pedestrian zone over a stationary asset in a corner.

Eliko’s deployment methodology: site survey to go-live

A UWB deployment that works reliably is the product of a structured process, not a quick sell and a hope. Eliko’s methodology follows four phases:

• Site characterisation: RF walk-through, obstacle mapping, ceiling height assessment, identification of high-multipath zones and NLOS risks
• Anchor plan design: geometry optimisation for the required accuracy and coverage, with coverage gap analysis before any hardware is installed
• Pilot deployment: temporary anchor installation and measurement validation across the full coverage zone, with tag walk-through data to confirm real-world accuracy
• Production deployment and calibration: permanent anchor installation, system calibration, and handover with documentation of coverage quality and known limitations

That last point matters: every deployment has limitations. A site with structural steel columns will have positions where accuracy is lower. Documenting those honestly — rather than pretending they don’t exist — allows integrators and end users to design applications that account for real-world behaviour.

The best deployments are designed around a clear understanding of what the system will and won’t do in that specific environment. Honest characterisation upfront prevents costly surprises at go-live.

Working with Eliko on your deployment

If you’re evaluating UWB for a real deployment — whether in an industrial setting, a venue, or a complex mixed environment — the questions above are the ones worth asking every vendor you consider.

Eliko’s engineering team works with customers from initial site assessment through to production. We’re transparent about what our system handles well and where you’ll need to plan carefully. That conversation is worth having before you commit to an infrastructure decision.