31 UWB Indoor Positioning Systems

31.1 Start With the Story

Prove the Position Before Acting on It

Ultra-wideband (UWB) is a radio method that uses very short signals to measure distance. Picture a lift truck moving near workers in a busy warehouse. A dot on a map may look exact, yet a poor anchor layout or blocked path can place that dot on the wrong side of an aisle.

Start with the action. Decide whether the system will guide a driver, slow a vehicle, or only record a trip. Name the largest error that action can accept. Place fixed reference points around the real work area, then test the tag at edges, behind stock, and while people move.

Keep each result with its time, visible reference points, estimated error, and actual checked position. When confidence falls, the safe response may be to warn, slow down, or ask for another source instead of guessing.

One site test cannot promise the same result in every room or season. The deeper sections explain timing, geometry, filtering, and blocked paths so the final claim stays tied to measured evidence.

A positioning system turns many ranges into a location claim. That claim depends on anchor placement, synchronization, geometry, line-of-sight quality, filtering, confidence, and how the application reacts when uncertainty grows.

Read this chapter from the map backward. Decide where the position will be used, what accuracy and confidence are needed, how anchors create or weaken the geometry, and what evidence says the location is safe to act on.

31.2 In 60 Seconds

UWB positioning is not “indoor GPS.” It is a measurement system that estimates a tag position from timed radio observations, anchor geometry, clock quality, and environmental evidence. A good design records which anchors were visible, whether measurements looked line-of-sight, how geometry amplified error, and how much confidence the application should place in the estimate.

Eddie’s Math Bridge: Link Budget Before Geometry

The mathematical gist. The chapter’s 30 m by 20 m floor has a 36.06 m diagonal. With -14.3 dBm total UWB EIRP, a 4.62 cm wavelength, and free-space exponent 2, that corner sees about 79.8 dB path loss and -94.1 dBm received power: 9.1 dB below the named -85 dBm sensitivity. Geometry cannot amplify a range measurement that the anchor never detected.

Math Bridge · guided foundationsIs the far-corner error weak geometry, or no detectable first path?Let Eddie screen link margin before GDOP gets a vote. Learn the maths

31.3 Learning Objectives

By the end of this chapter, you should be able to:

• Explain why anchor geometry and line-of-sight quality can matter more than nominal radio precision.
• Compare TWR, TDoA, and angle-assisted UWB architectures without treating any one mode as universally best.
• Use GDOP as an error-amplification signal rather than as a magic accuracy guarantee.
• Design a site survey that records anchor coordinates, visibility, obstruction classes, calibration evidence, and retest triggers.
• Specify the quality fields that a positioning engine should expose to downstream IoT applications.

31.4 Quick Check: UWB Positioning

31.5 Prerequisites

Review these chapters before working through the design process:

• UWB Fundamentals for impulse radio, channel behavior, and standards context.
• UWB Ranging Techniques for TWR, TDoA, and angle-related measurements.
• Wireless Channel Characteristics for multipath, fading, and line-of-sight limits.
• IoT Reference Models as Responsibility Maps for evidence records and integration boundaries.

31.6 Position Estimates as Evidence

A UWB location estimate should be treated as an evidence record, not as the exact physical truth. The record should say what was measured, which assumptions were used, and how confident the engine is in the result.

Important fields include:

• Tag identifier and timestamp.
• Position estimate in the chosen coordinate frame.
• Anchors used, anchors rejected, and anchor geometry quality.
• Measurement mode such as TWR, TDoA, or angle-assisted measurement.
• Line-of-sight or non-line-of-sight indicators where available.
• Residual error after solving the position.
• Confidence or quality class exposed to the application.
• Age of the estimate and filter state.

Applications should respond differently to high-confidence, low-latency estimates than to stale or low-confidence estimates. For example, an asset map can show a broad uncertainty area, while a robot safety workflow may require a recent estimate with enough visible anchors and a low residual before it acts.

31.7 Anchors Turn Ranges Into Coordinates

A UWB positioning system is a set of fixed anchors at known coordinates and mobile tags to be located. Ranging gives distances or arrival-time differences; the positioning system combines several of those measurements into an (x, y) or (x, y, z) estimate. How it combines them depends on whether the measurement method is two-way ranging, TDoA, angle-assisted measurement, or a hybrid.

The two big system questions are geometry and capacity. Geometry asks whether anchor placement gives the solver enough independent viewpoints. Capacity asks how many tags can be located at the required update rate without exhausting airtime, battery, or timing quality. Both are system decisions, not properties of UWB alone. A tag can produce a precise-looking coordinate in a demo and still be unreliable at the edge of a warehouse if all anchors sit on one wall or if forklifts block the strongest paths.

A positioning estimate is therefore an evidence packet: anchors used, rejected anchors, timestamp age, line-of-sight indicators, residual, confidence class, and policy action. For an asset map, a broad low-confidence region may be acceptable. For a robot stop zone or a secure handoff, the same low-confidence estimate should deny automation or trigger fallback.

31.8 Anchor Geometry and GDOP

Anchor placement sets the shape of the positioning problem. Good geometry surrounds the working area; poor geometry puts anchors along one wall or in a narrow line. Collinear or near-collinear anchors can make a small distance error appear as a large position error in the weak direction.

Inspect Geometry Affects Positioning Accuracy and Small in Figure 31.1 for anchor geometry and gdop. To challenge the claim in anchor geometry and gdop, locate Geometry Affects Positioning Accuracy beside Small on it. Keep GPS receivers calculate GDOP to estimate position quality with the decision.

Read Geometry Affects Positioning Accuracy with Small in Figure 31.1 for anchor geometry and gdop. Compare its states by comparing Geometry Affects Positioning Accuracy with Small before interpreting GPS receivers calculate GDOP to estimate position quality. The GPS receivers calculate GDOP to estimate position quality inference is bounded by the Geometry Affects Positioning Accuracy observation. Attach the next action in anchor geometry and gdop to GPS receivers calculate GDOP to estimate position quality.

Use GDOP as a review signal:

position_uncertainty ~= range_uncertainty * geometry_factor + environment_bias + timing_bias + filter_lag

The geometry factor is not the whole error budget, but it is a useful warning sign. If the geometry factor is high, improving firmware or filter settings may not fix the installation. Move anchors, add viewing angles, or reduce the area claimed by that anchor group.

Use a simple coordinate example. A 30 m x 20 m work area might use anchors at known map coordinates and a tag mounted on a cart. If the cart is near the middle, several anchors may see it from different angles and a 0.20 m range error may stay near that scale in the final position. If the same cart moves outside the anchor hull or all useful anchors are on one side, geometry can amplify that same range error. With a geometry factor of 3, the review should expect about 0.20 m x 3 = 0.60 m of position uncertainty before adding environment bias, clock error, or filter lag. GDOP does not predict every error; it warns when the installation makes small timing errors expensive.

Good anchor layouts usually follow these principles:

• Surround the area instead of placing every anchor on one side.
• Keep enough independent anchor visibility at the edges and corners, not only in the center.
• Place anchors high enough to reduce obstruction, but not so high that horizontal geometry becomes weak.
• Use height diversity for 3D estimates and for tall workspaces.
• Recompute geometry when walls, racks, machines, or anchor locations change.

31.9 Measurement Quality Pipeline

UWB systems produce timed observations first. A positioning engine turns those observations into an estimate only after filtering poor measurements, solving the geometry, and assigning quality.

Inspect Raw times and usable views in Figure 31.2 for measurement quality pipeline. While tracing measurement quality pipeline, put Raw times and usable views into the same reading of it. Use fallback as the boundary.

Read Raw times with usable views in Figure 31.2 for measurement quality pipeline. Check it with Raw times as one fact, usable views as another, and fallback as the closeout. Keep fallback separately reviewable. Use that distinction when deciding measurement quality pipeline.

Review each stage:

• Raw observation: Capture timestamp, anchor ID, channel/profile, received signal indicators, sequence number, and clock status where available.
• Quality check: Mark likely NLOS, stale, inconsistent, or missing observations before solving position.
• Anchor selection: Prefer diverse anchors with compatible timing and line-of-sight evidence.
• Solver: Estimate position and calculate residuals or consistency checks.
• Filter: Smooth motion without hiding jumps, blocked anchors, or stale data.
• Confidence class: Publish a confidence label and uncertainty estimate with the position.
• Application policy: Decide whether the estimate is good enough for display, logging, automation, or safety-related action.

This pipeline prevents a common failure: a location server publishes a coordinate even when the underlying evidence is weak, and the application treats the coordinate as certain.

Publish coordinates with confidence, update age, anchors used, and residual evidence. A coordinate without quality fields is not enough for automation or safety decisions.

31.10 Architecture Choices

Choose the architecture from the workflow, scale, update behavior, wiring constraints, and evidence needs. Avoid selecting a mode only because a demonstration kit makes it easy.

Inspect tag exchanges and clear distance in Figure 31.3 for architecture choices. To place architecture choices on firm evidence, separate tag exchanges from clear distance using it. anchor clock identifies the later check.

Read tag exchanges with clear distance in Figure 31.3 for architecture choices. Test it by setting tag exchanges against clear distance under anchor clock. anchor clock turns categories into a decision. Preserve the anchor clock condition in the handoff for architecture choices.

TWR positioning uses message exchanges between a tag and anchors. It is straightforward to reason about because each distance estimate comes from an exchange with a known anchor. It can be a good fit for smaller systems, commissioning, peer distance checks, or systems where synchronized anchor timing is not available. The trade-off is that tags and anchors spend airtime on each exchange, so update rate and tag count must be planned.

TDoA positioning lets a tag transmit a short blink observed by synchronized anchors. It can scale better when many tags report periodically because the tag does not have to range with each anchor. The trade-off is that anchor timing, cabling or timing distribution, calibration, and timestamp quality become part of the position evidence.

Angle-assisted positioning adds direction estimates from antenna arrays or phase information. It can help in constrained layouts, but it introduces its own calibration and multipath sensitivity. Treat angle evidence as another measurement with quality, not as a replacement for line-of-sight review.

31.11 Try Angle of Arrival in the Workbench

31.12 Capacity Often Picks the Positioning Method

The reason large deployments often favor TDoA over TWR is channel airtime. In TWR, every position needs a back-and-forth exchange between the tag and each anchor, so airtime scales with tags x anchors x update rate. In TDoA, a tag transmits one blink and synchronized anchors listen, so one short transmission can support the fix. That is why asset-tracking systems with many tags often lean TDoA, while a smaller set of high-accuracy robots or tools may afford TWR.

Capacity belongs in the same evidence record as geometry. If 200 tags need a 1 Hz update, the system must budget about 200 tag reports per second before retries, management frames, and rejected observations. If the workflow can accept 0.2 Hz for slow-moving assets, the load drops to 200 x 0.2 = 40 reports per second. That change may decide whether TDoA blinks are sufficient, whether TWR exchanges are practical only for a smaller tool fleet, or whether the project needs smaller zones with different update policies.

Compare two rough budgets. In a TWR design with 80 active tags, 4 anchors per position, and 1 update per second, the system asks for about 80 x 4 x 1 = 320 tag-anchor ranging exchanges per second. If a commissioning mode uses only 10 tools at 2 Hz, the request is 10 x 4 x 2 = 80 exchanges per second, which may be more manageable and gives each tool stronger per-anchor evidence. In a TDoA design, 80 tags at 1 Hz can be closer to 80 tag transmissions per second because synchronized anchors listen to the same blink. The tradeoff is that anchor synchronization, timestamp quality, and calibration become release-critical evidence.

The solver then turns accepted observations into position with an error budget, not a guarantee. A practical record might say: range uncertainty 0.15 m, geometry factor 2.5, expected environment bias 0.20 m, and filter lag allowance 0.10 m. A simple review estimate is 0.15 x 2.5 + 0.20 + 0.10 = 0.675 m. If the application needs only room-level asset awareness, that may be acceptable. If it needs a robot safety boundary at 0.30 m, the same evidence is not good enough.

Architecture review questions:

• How many tags may be active in the same area at peak load?
• What update rate is required, and what happens when updates are delayed?
• Can anchors share a reliable timing reference?
• Does the application need a position, a zone, a direction, or a confidence class?
• What fields will be exposed when the engine rejects an estimate?
• Which physical changes require retesting?

31.13 Site Survey and Deployment Process

A site survey should produce an installable coordinate system and an evidence trail. It is not just a count of anchors.

Inspect output and anchors in Figure 31.4 for site survey and deployment process. Before accepting site survey and deployment process, separate output from anchors using it. and owner limits the claim.

Read output with anchors in Figure 31.4 for site survey and deployment process. Review it from the output field to anchors, then the and owner disposition. Both output and anchors need evidence. Reopen site survey and deployment process whenever anchors changes.

Use that route to organize the survey rather than treating the following outputs as an inventory. Establish the coordinate frame before judging anchor candidates; document obstructions and tag mounting before setting acceptance zones; then bind calibration, positive and negative trials, and retest triggers to the same installed geometry. A later change to shelving, timing, firmware, or tag placement therefore reopens the affected evidence instead of silently inheriting the original acceptance.

Minimum survey outputs:

• Coordinate frame origin, axes, units, floor level, and map reference.
• Anchor candidate positions with height, mounting surface, orientation, and service access.
• Obstruction notes for metal, water, machinery, people flow, doors, vehicles, and moving fixtures.
• Expected tag mounting positions and body or asset shadowing risks.
• Measurement mode, update policy, timing source, and channel/profile settings.
• Calibration path or reference measurements used to verify the coordinate frame.
• Acceptance zones with expected confidence, residual limits, and update-age limits.
• Retest triggers for anchor movement, new shelving, changed tag mounting, firmware changes, or timing-source changes.

Acceptance testing should include both positive and negative cases:

• Known points near the center, edges, corners, and obstruction boundaries.
• Moving paths at realistic speeds.
• Temporary anchor loss and recovery.
• NLOS conditions that should lower confidence or reject the estimate.
• Neighboring zones where a tag should not be accepted as inside the wrong area.
• Application behavior when the estimate is stale or low confidence.

31.14 Worked Design Review

Consider a warehouse that needs to locate tagged carts on a floor with tall shelving and moving vehicles. A weak review asks, “How many anchors do we need?” A stronger review asks, “Which positions can see enough independent anchors, what evidence proves the estimate quality, and what does the application do when the estimate is weak?”

A practical review sequence:

1. Define the required output as a zone, 2D coordinate, 3D coordinate, or motion track.
2. Choose acceptance metrics such as maximum update age, minimum visible anchors, residual threshold, and confidence class.
3. Draw the coordinate frame and mark shelves, doors, workcells, vehicle paths, and likely tag mounting heights.
4. Place candidate anchors to surround the operating area and to preserve visibility at edges.
5. Simulate or sample geometry quality across the floor.
6. Walk test known points and moving paths, saving raw observations and solved estimates.
7. Tune rejection rules before smoothing rules, so the filter does not hide bad measurements.
8. Document the release record and retest triggers.

The output is not only a map. It is a repeatable evidence package that explains where the system is trustworthy, where it is degraded, and where the application should fall back.

31.15 Knowledge Check

31.16 Capacity Check

31.17 Matching Review

31.18 Deployment Sequence Review

31.19 Common Review Failures

Treating accuracy as a fixed product property: Position quality changes with geometry, line-of-sight, mounting, timing, update rate, and filtering. Publish confidence instead of only a coordinate.

Accepting coordinates without raw evidence: Keep raw measurements, anchors used, residuals, and rejected-anchor reasons so field problems can be reproduced.

Optimizing the center and ignoring edges: Edges, corners, doorways, lifts, racks, and vehicle paths often have weaker geometry than the open middle of a room.

Hiding NLOS with smoothing: Filters can make bad data look stable. Reject weak measurements first, then smooth accepted estimates.

Forgetting the coordinate frame: A precise tag estimate is useless if the anchor map, floor level, axis direction, or application map is misaligned.

31.20 Plain Sources

• IEEE 802.15.4z-2020.
• FiRa Consortium technical materials on UWB ranging and interoperability.
• Indoor Positioning and Indoor Navigation survey literature.
• UWB RTLS deployment and calibration guides from equipment manufacturers.

31.21 Summary

UWB positioning design is an evidence problem. A useful deployment records anchor coordinates, measurement quality, geometry, timing, calibration, confidence, and application behavior. The best systems do not simply claim precision; they explain when estimates are trustworthy, when confidence should fall, and which physical changes require retesting.

Key takeaways:

• Anchor geometry controls how measurement errors are amplified.
• TWR, TDoA, and angle-assisted modes have different evidence and infrastructure needs.
• Line-of-sight, timing quality, and residual checks should be visible to the application.
• Acceptance tests must include weak areas, motion paths, NLOS cases, and stale estimates.
• Retest whenever anchors, tags, maps, timing, firmware, or the physical layout changes.

31.22 What’s Next

• UWB Applications and Security - Apply positioning evidence to practical UWB workflows and risk reviews.
• UWB Ranging Techniques - Review the measurement methods used by positioning engines.
• UWB Fundamentals - Revisit the radio behavior behind UWB measurement quality.
• NFC Fundamentals - Compare deliberate tap workflows with continuous location evidence.
• RFID Design and Deployment - Compare RFID deployment evidence with UWB positioning evidence.