RTLS / Geofencing at the Edge with UWB, BLE AoA & IMU Fusion
← Back to: IoT & Edge Computing
Edge RTLS and geofencing turn UWB/BLE measurements + timing/quality evidence into reliable zone events (enter/exit/dwell) under NLOS, link loss, and battery constraints. The key is engineering the whole chain—method choice, calibration/sync, fusion, hysteresis/dwell/gating, and replayable logs—so results are provable on site.
H2-1｜What RTLS & Geofencing at the Edge really solve (and the clean boundary)
Edge RTLS is about repeatable positioning under real site physics. Edge geofencing is about reliable zone events (enter/exit/dwell) under uncertainty, latency limits, and intermittent backhaul.
RTLS vs GNSS tracking
GNSS is optimized for open-sky. Indoor, cold-room corridors, metal racks, and dense machinery produce frequent dropouts and biased fixes. RTLS trades infrastructure (anchors + calibration + logs) for controllable coverage and accuracy.
UWB ranging node vs RTLS system
A ranging link is not a system. RTLS must handle multi-anchor geometry, NLOS/multipath detection, calibration IDs, measurement-to-decision pipelines, and evidence logs for debugging and acceptance.
Edge geofence vs cloud geofence
Edge geofencing reduces event latency, survives backhaul loss, and keeps sensitive location processing local. Cloud can remain for reporting/analytics, while the edge makes time-critical decisions.
- Continuous coordinates (RTLS) vs event correctness (geofencing): optimize for the output that matters.
- Choose the technology track early: UWB ranging/TDoA, BLE AoA, or hybrid with IMU constraints.
- Define acceptance metrics up front: zone event false alarms, misses, and recovery after occlusion or reboot.
H2-2｜System roles & data paths: Tag / Anchor / Gateway / Edge Compute
A shippable RTLS/geofence design is a pipeline: measurements are captured close to RF/PHY, fused at the edge, then converted into auditable events with durable logs.
Tag (mobile, power-limited)
Generates UWB/BLE bursts, runs ULP state machines, and samples IMU for wake/constraints. Key blocks: UWB/BLE radio, ULP MCU, IMU, power-path/PMIC, brownout-safe event buffer.
Anchor / Locator (RF accuracy + calibration)
Captures ToF/phase/IQ close to the RF chain and attaches timestamps with minimal skew. Key blocks: antenna array, RF switch/LNA, IQ/phase capture or UWB ToF, calibration storage (cal ID), health flags.
Gateway (aggregation + survivability)
Aggregates multi-anchor measurements, buffers during backhaul loss, and enforces version/log consistency. Key blocks: local cache, time-ordering, quality flag propagation, minimal replay logs.
Edge compute (fusion + geofence engine)
Fuses RTLS measurements with IMU constraints, smooths trajectories, and emits zone events with confidence gating. Key blocks: fusion filters, geofence hysteresis/dwell, alarm logic, durable logs/alerts.
- Measurement layer (thin arrows): IQ/phase/ToF/timestamps + quality flags + calibration ID.
- Decision layer (thick arrows): position → trajectory smoothing → geofence events → logs/alerts.
- Non-negotiables for real sites: clock/sync discipline (high-level), calibration traceability, and NLOS/multipath awareness flags.
H2-3｜Positioning modes that can ship: UWB (TWR/TDoA) + BLE AoA (and hybrid)
Mode selection is not a feature checklist. Each option assigns cost to a different place: tag power, anchor synchronization, or array calibration under multipath. The goal is stable position outputs that can support geofence events, not a demo-only “best-case” accuracy.
UWB TWR (Two-Way Ranging)
Simple to deploy and tolerant to weak infrastructure timing. The tag participates in round trips, so tag energy and retry behavior dominate lifetime. Best when anchors are sparse and synchronization is limited.
UWB TDoA (Time Difference of Arrival)
Scales better for low-power tags because the tag can transmit once while anchors observe. Requires stronger anchor-to-anchor timestamp discipline and consistent calibration IDs to keep bias under control.
BLE AoA (Angle of Arrival)
Cost-effective and ecosystem-friendly, but stability depends on array geometry, RF channel matching, and multipath behavior. Works well when meters-level accuracy is acceptable and calibration can be maintained.
H2-4｜RF & antenna array realities: making AoA & UWB stable (layout, calibration, coexistence)
Stable performance comes from channel consistency + calibration traceability + measurable evidence. When angles drift or ranges bias, the root cause is usually visible in repeatable symptoms and site-dependent physics, not in abstract algorithms.
AoA #1 — Array geometry & spacing
Symptom: angle jumps or direction-dependent error.
Evidence: side-lobe patterns, ambiguous peaks, inconsistent bearings across anchors.
Fix: geometry choice matched to expected field-of-view, controlled spacing, and restricted sectors when needed.
AoA #2 — RF chain consistency (gain/phase matching)
Symptom: slow drift with temperature or time.
Evidence: channel-to-channel phase/gain deltas changing with temperature.
Fix: phase/gain calibration, temperature-aware correction, and health flags to gate low-confidence bearings.
AoA #3 — Switch, routing symmetry & reference return
Symptom: step changes during switching, motion, or bursty coexistence.
Evidence: phase jitter spikes, repeatable discontinuities tied to switching events.
Fix: symmetric routing, stable reference return, reduced coupling, and controlled switching schedules.
AoA #4 — Calibration strategy (factory vs field)
Symptom: good in lab, degraded after installation; bias grows with temperature or replacement.
Evidence: angle bias correlates with installation pose, temperature, or calibration ID mismatch.
Fix: calibration traceability (cal ID), field recalibration triggers, and drift monitoring.
UWB #1 — Antenna/matching → ToF bias
Symptom: distance consistently high/low across the site.
Evidence: bias remains after filtering; changes with temperature or hardware revision.
Fix: calibration against known references and strict RF path consistency across units.
UWB #2 — Multipath/NLOS symptoms
Symptom: sudden jumps, long tails, zone event false alarms.
Evidence: quality flags degrade; first-path capture fails; bias appears only in certain regions.
Fix: redundancy, quality gating, and site-aware validation plans.
UWB/BLE #3 — Coexistence principles
Symptom: loss spikes when multiple radios transmit; AoA noise increases.
Evidence: blocking/overload indications, higher retry rate, correlated packet loss windows.
Fix: front-end filtering, blocking margin planning, and time-slot discipline (principles only).
H2-5｜Timing & timestamps: “how good is good enough” (without PTP algorithms)
Edge RTLS timing is about consistency that can be validated. Different modes “pay” timing cost in different places: anchor-to-anchor time alignment (TDoA), sampling/phase consistency (AoA), or timestamp-path jitter (TWR).
TDoA — strong dependency
Anchor clocks must remain mutually consistent because inter-anchor time deltas directly affect range differences. Typical failures show up as region-dependent bias and long-tail errors that track temperature or resets.
AoA — strong dependency
Stable AoA requires consistent sampling phase and channel timing inside the receiver chain. Typical failures show up as angle drift, direction-dependent error, and bursty noise under coexistence.
TWR — weak to medium dependency
Round-trip helps tolerate weak infrastructure timing, but timestamp placement and runtime jitter can still dominate. Typical failures show up as noisy ranges, retries, and unstable event latency.
| Error source | Where it appears | Typical symptom | What to log | Primary fix |
|---|---|---|---|---|
| Oscillator ppm | Clock | Slow drift; temperature-correlated bias | Offset trend vs time/temperature; reboot markers | Better reference; temperature-aware correction; drift monitoring |
| PLL jitter | Clock | Short-term noise; widened tails; unstable AoA | Jitter proxy metrics; noise increase during coexistence windows | Cleaner clocking; isolate noisy rails; stable reference routing |
| Timestamp quantization | Timestamp | Resolution floor; step-like error patterns | Timestamp resolution, tick rate, quantization steps | Higher-resolution timestamping; prefer lower-layer capture points |
| Interrupt latency | Timestamp path | Random jitter; bursty errors under CPU load | ISR latency stats; CPU load; queue depth at capture time | Hardware timestamping; isolate real-time path; bounded queues |
| RF path delay skew | RF path | Systematic bias; unit-to-unit mismatch | Calibration ID; known-distance checks; temperature correlation | Calibration traceability; consistent RF path; re-cal triggers |
- Anchor offset trend: look for monotonic drift vs step jumps (resets, coexistence, swaps).
- Temperature correlation: verify offset/bias tracks temperature windows (cold-room transitions are revealing).
- Loss-induced time discontinuity: check whether packet loss windows inflate tails and whether recovery returns to the stable band.
- Restart recovery time: measure time-to-stable after power cycle; check if re-alignment or re-cal is required.
- Log consistency: verify cal ID / firmware version / sequence continuity for reproducible replay.
H2-6｜IMU fusion that helps (and when it hurts): sync, calibration, filters, constraints
IMU fusion helps when it converts multipath-driven jumps into bounded, explainable behavior. Fusion hurts when prerequisites are missing: time misalignment, weak calibration traceability, or constraints that do not match the motion.
Gate 1 — Time alignment
IMU and radio positions must live on the same time axis. Misalignment shows up as lag, overshoot on turns, and false boundary events. Evidence should include alignment checks around sharp motion transitions.
Gate 2 — Calibration traceability
Bias/scale/misalignment must be known and versioned. Poor calibration shows up as slow drift that grows with time and temperature. Evidence should include static stability checks and temperature correlation.
Gate 3 — Mounting & frame consistency
Sensor axes must match the assumed coordinate frame. Bad mounting definitions show up as directional errors (turning “wrong way”) and unstable speed estimates.
| Item | What goes wrong | How it shows up | How to verify |
|---|---|---|---|
| Bias | Non-zero output at rest integrates into drift | Trajectory slowly slides; geofence “creep” | Static test over time; bias vs temperature |
| Scale | Amplitude error misstates motion intensity | Speed/turn magnitude wrong; zone dwell time skew | Known motion pattern comparison; consistency across units |
| Misalignment | Axis coupling during turns and vibration | Directional errors; cornering artifacts | Turn test; cross-axis correlation under controlled motion |
| Temp drift | Bias/scale vary with temperature windows | Cold-room transitions create step bias | Temp sweep or field temp logging; drift vs °C trend |
| Vibration noise | Spectral content shifts with forklifts/AGVs | Noisy headings; unstable constraints | Vibration markers; noise proxy vs operating modes |
- Level 0: quality gating + smoothing (lowest compute; fast win).
- Level 1: complementary filtering (low compute; stable dynamics).
- Level 2: EKF-style state filtering (common in shipping products).
- Level 3: UKF / heavier models (only if compute and validation budget exist).
| Scene | Motion traits | Useful constraints | Risk if wrong |
|---|---|---|---|
| Walking | Frequent starts/stops; turning; moderate vibration | Speed bounds; turn-rate sanity; dwell gating | Over-smoothing hides real exits/entries |
| Forklift | Strong accel/brake; vibration; tight maneuvers | Turn radius bounds; vibration-aware gating | False constraints cause “snap” artifacts |
| AGV | Predictable routes; repeatable profiles | Map/route constraints; bounded speed plan | Map mismatch creates systematic bias |
| Pallet | Long static intervals; occasional moves | Static detection; event-triggered updates | Over-tracking drains battery and amplifies noise |
H2-7｜Error budget & site physics: NLOS / multipath / geometry (prove the root cause)
“One area is always inaccurate” is rarely a mystery. Most field failures are explainable as a combination of geometry, NLOS/multipath, timing consistency, and RF channel consistency. The goal is a proof chain: symptoms → measurable indicators → targeted actions → repeatable re-test.
| Bucket | Typical symptom | Measurable indicators | Primary actions |
|---|---|---|---|
| Geometry / DOP | Area-specific error; elongated error ellipse; direction-dependent bias | Anchor visibility count; coverage gaps; ellipse axis direction; repeatability per path | Add cross-view anchors; change height/angle; close blind spots; re-test on the same reference path |
| NLOS / Multipath | Sudden jumps; stable bias near shelves/walls; sensitive to moving metal or doors | Quality flags; first-path confidence proxy; residual spikes; delay-spread proxy metrics | Improve line-of-sight; add redundancy; enable NLOS gating; re-test before/after obstruction changes |
| Timing consistency | Slow drift over time; temperature-correlated bias; step change after restart | Offset trend vs time/temp; restart convergence time; drift slope stability | Run temperature/restart checks; verify stable trend bands; escalate only if timing artifacts dominate tails |
| RF / AoA chain | Angle drift; unit-to-unit mismatch; noise bursts during coexistence windows | Channel gain/phase stats; AoA quality; cal ID mismatch; event correlation with RF states | Verify calibration traceability; check channel health; validate static-angle stability; re-test in controlled RF modes |
Step 1 — Is it area-specific?
Repeat the same path and check whether errors cluster in zones. If “badness” is local, prioritize geometry and NLOS hypotheses before timing.
Step 2 — Is it temperature/time correlated?
Plot error vs temperature/time markers. Strong correlation suggests drift-style causes (timing consistency, RF temperature drift, calibration stability).
Step 3 — Compare a reference trajectory
Use a fixed reference walk/drive and compare residual shapes. Local bias implies physics/geometry; time drift implies system consistency.
- Phenomenon: which zone / which time window / what triggers it (doors, metal racks, coexistence, restarts).
- Evidence A (area-specific): heat-zone or error-ellipse pattern; anchor visibility changes by zone.
- Evidence B (temperature/restart): slow drift vs step jump; convergence after restart.
- Evidence C (reference path): repeatable residual shape; before/after obstruction change.
- Conclusion: primary bucket (geometry / NLOS / timing / RF chain) or a ranked combination.
- Action + re-test: change one hypothesis at a time; record the same reference path again.
H2-8｜Geofencing engine at the edge: rules, hysteresis, dwell time, false alarms
A reliable geofence is an event engine, not a single threshold. The practical goal is stable enter / exit / dwell decisions under noise, NLOS, and short-term jumps, with logs that explain why an event fired (or was suppressed).
Core outputs
Enter Exit Dwell Events must include timestamp, zone ID, and confidence context for audit/replay.
Common rule extensions
Speed threshold Route deviation Use these to prevent false alarms from fast pass-throughs and to flag forbidden routes without increasing noise sensitivity.
| Tool | Why it exists | Typical symptom it fixes | What to log |
|---|---|---|---|
| Smoothing | Reduce short-term jitter near boundaries | Rapid enter/exit flips (“flapping”) on a static tag | Raw vs filtered position; window length; filter state |
| Hysteresis band | Create a transition band instead of a single line | Boundary-line dithering causing repeated triggers | Distance-to-boundary; current state; band width |
| Dwell time | Confirm presence over time before committing | Pass-through triggers that should not count as “inside” | Dwell timer; confirm timestamp; re-arm/cooldown |
| Confidence gating | Suppress events when measurement quality is low | NLOS jumps directly firing alarms | Quality score; NLOS flag; gating decision reason |
| Parameter | Typical range | Increase when | Decrease when | Side-effect |
|---|---|---|---|---|
| Smoothing window | 0.5–3 s | Boundary jitter dominates | Fast reactions required | More latency / lag on turns |
| Hysteresis band | 0.5–2 m | Flapping at the boundary | Zones are tight / narrow | Later transitions |
| Dwell time | 2–30 s | Pass-through false alarms | Short visits are meaningful | Delayed confirmation |
| Confidence threshold | Low/Med/High tiers | NLOS-heavy environments | Measurements are stable | Potential missed events |
| Cooldown / re-arm | 0–10 s | Repeated alerts are noisy | Rapid re-entry matters | Suppresses rapid sequences |
H2-9｜Gateway aggregation (RTLS-specific): what to send, what to log, and how to survive link loss
Gateway design for RTLS is mostly a trade between network cost and replayability. The best deployments treat reporting as a layered data model: send just enough to run operations, but keep a minimal evidence set so field issues can be reproduced and explained.
| Granularity | Payload content | Network cost | Replayability | Best fit |
|---|---|---|---|---|
| Send position | Position + quality fields + anchor/locator set summary | Low | Medium (depends on quality/trace fields) | High-volume tracking where bandwidth/fees dominate |
| Send measurement | ToF / phase / timestamps + participating anchors set (per fix) | High | High (best for deep field root-cause) | Hard environments (NLOS/multipath) with strong audit/debug needs |
| Hybrid | Events + position stream + sampled measurement windows (for replay) | Medium | High (targeted replay without full streams) | Most practical systems: stable operations + explainable incidents |
Link-loss survival strategy (principles)
Use a layered degradation path: buffer downsample event-only recover & backfill. Prioritize durability for events and minimal replay evidence, not raw streams.
- Store-and-forward buffer: ring buffer with priority (events > evidence > trajectories).
- Downsampling: reduce position rate; keep measurement only as samples or “event windows”.
- Event-only mode: keep enter/exit/dwell plus the replay kit fields.
- Power-loss awareness: atomic/validated log writes; avoid partial corruption (principle-level only).
Minimum replayable log set (the “field evidence kit”)
The smallest set that enables replay-style debugging without shipping full raw streams:
timestamp anchor set quality flags firmware version calibration ID profile ID
- timestamp: consistent time base for correlation and ordering.
- anchor set: which anchors/locators contributed (and how many).
- quality flags: confidence/NLOS indicators used by gating logic.
- versions: tag/anchor/gateway/edge compute firmware identifiers.
- calibration ID: array/RF/time-delay calibration traceability.
- profile ID: which fusion/geofence parameter set produced the decision.
H2-10｜Power & lifetime: duty-cycling, wake triggers, and battery math that matters
Lifetime is dominated by average current, which is the sum of short high-current bursts weighted by duty cycle. A useful power plan starts with an energy ledger (Tx/Rx/IMU/compute/log/sleep) and then optimizes the few parameters that drive the largest swing in average current.
| Block | What it includes | Current level | Active time | Rate |
|---|---|---|---|---|
| Radio Tx bursts | UWB/BLE transmissions, retries, preambles | High (range) | ms-scale bursts | per interval / per event |
| Radio Rx windows | Listening, scan windows, sync checks | Medium–High | ms–s windows | per interval / per retry |
| IMU sampling | Accel/gyro sampling, wake classification | Low–Medium | continuous or bursts | per second / per wake |
| MCU compute | fusion, geofence rules, quality gating | Medium | ms–100ms | per fix / per event |
| Log write | flash/FRAM writes, commit + checksum | Medium–High | short pulses | per event / per batch |
| Sleep leakage | MCU + PMIC + sensors residual | Very low (range) | most of the time | continuous |
Top 5 lifetime-sensitive parameters
Tx interval Rx window Sync retry Temperature Sleep IQ
- Tx interval: biggest lever when tracking rate is flexible.
- Rx window: silent drain; keep windows short and purposeful.
- Sync retry: failures multiply cost; optimize for “first-time success”.
- Temperature: impacts effective capacity and error-driven retries.
- Sleep IQ: sets the long-term floor for multi-month/annual targets.
Wake triggers (selection principles)
Wake triggers reduce “wasted radio time” by aligning activity with meaningful motion or access events. Keep trigger logic minimal and loggable.
- Accelerometer: best for mobile assets; manage vibration false wakes with thresholds.
- Door / contact: best for cold rooms/containers; installation-dependent.
- Light: useful for open/close detection; sensitive to obstruction and ambient changes.
- Timer: simplest; can waste energy if not coupled with motion context.
H2-11｜Deployment & validation playbook: site survey, calibration, golden-path tests, troubleshooting
A repeatable delivery flow for RTLS + edge geofencing: predict site physics risks early, validate layer-by-layer, and keep a replayable evidence chain (timestamps, anchor sets, quality flags, versions, calibration/profile IDs).
1) Day-0 readiness: classify the site and draw a risk map
Purpose: avoid “one parameter set for every building”. RTLS success depends on geometry, NLOS/multipath, and drift behaving differently across site types.
Typical site types (use one row per deployment):
- Cold storage: big temperature spans, reflective doors/panels, strong drift coupling.
- Warehouse aisles: repeating occlusions (racks), fixed NLOS hotspots, long corridors.
- Metal-dense shopfloor: strongest multipath, higher AoA instability risk, RF coexistence risk.
- Semi-open areas: boundary reflections; treat transitions (doorways) as event-critical zones.
Outputs (store with version control):
- Risk map: mark likely NLOS zones, high-reflection surfaces, and “event-critical” boundaries.
- Golden path: a repeatable reference route (start/stop points + dwell points + turn points).
- Anchor candidate list: candidate mounting points with constraints (height/LOS/coverage priority).
2) Site survey checklist: geometry coverage + NLOS hotspots + a reference track
Purpose: convert “walk around and guess” into a repeatable survey artifact that predicts blind spots and unstable zones.
- Coverage skeleton: corners, long aisles, tight turns, doorway transitions, loading bays.
- Line-of-sight reality: identify consistent occluders (racks, machines, cold-room doors).
- NLOS hotspot marking: walls/behind-rack zones; label “expected bias” vs “expected jump”.
- Golden path definition: fixed route + fixed speed ranges + fixed dwell points.
- Anchor participation targets: define a minimum anchor-set size for event-critical zones (use ranges, not single numbers).
- Coexistence flags: mark “high RF noise” zones for additional gating/logging (principles only).
Survey pass criteria should be written as a short statement: “Blind spots are known, event-critical boundaries have redundancy, and the golden path is repeatable.”
Tip: store the survey output as a versioned artifact so later tuning can be traced back to the exact site assumptions.
3) Calibration strategy: factory vs field vs hybrid (and how to keep it traceable)
Purpose: calibration is not optional if the deployment needs stability across temperature, reboots, and partial occlusions.
| Strategy | Best for | Tradeoffs | Required traceability fields |
|---|---|---|---|
| Factory calibration | Hardware channel consistency, controlled conditions | May miss site-specific bias; install can still shift offsets | cal-id, fixture ID, temperature window, firmware version |
| Field calibration | Site-specific bias removal, anchor geometry alignment | Process variance across teams; needs strict checklists | cal-id, site map version, operator checklist, anchor-set snapshot |
| Hybrid (recommended) | Scale: stable channels + minimal site correction | Requires both artifacts (factory + field) kept together | cal-id, factory cal reference, field delta reference, fw-ver |
4) Acceptance tests: validate in layers (L1 → L4)
Purpose: avoid “it looks accurate” by enforcing a layered pass/fail table where each layer has inputs, metrics, and evidence.
| Layer | What is being validated | Pass statement (use ranges) | Evidence to capture |
|---|---|---|---|
| L1 — Measurement health | ToF/phase/timestamp stability and quality marking | No unexplained jumps; degraded states are flagged | measurement summary, anchor-set, quality flags |
| L2 — Geometry coverage | Anchor participation in critical zones | Critical zones meet minimum anchor-set target | coverage map, blind-spot list, anchor participation stats |
| L3 — Fusion stability | Temperature, reboot, partial occlusion robustness | Recovery time + drift bound remain within target ranges | reboot logs, temp sweep snapshots, quality-gated output |
| L4 — Geofence events | enter/exit/dwell correctness and false alarms | Golden-path script meets miss/false bounds | event timeline, profile-id, replay kit bundle |
“Pass statement” is intentionally written as a range so it can be tuned per site type without rewriting the acceptance framework.
5) Golden-path scripts: make acceptance repeatable (not anecdotal)
Purpose: the same actions must produce the same event outcomes across operators and days, otherwise tuning cannot converge.
Golden-path actions (treat each as a scripted test step):
- Straight walk through open LOS zone → verify stability and event latency ranges.
- Corner turn near rack/metal → verify NLOS marking and confidence gating behavior.
- Doorway transition (event-critical boundary) → verify enter/exit hysteresis behavior.
- Dwell at boundary for a defined time → verify dwell timing window and false alarm bounds.
- Fast pass-through (no dwell) → verify dwell does not trigger.
- Controlled occlusion (brief block) → verify recovery time and quality-flag behavior.
6) Troubleshooting evidence chain: symptoms → evidence → ruling tests
Purpose: reduce “arguing by opinion” by forcing every issue into a short evidence chain with ruling tests.
| Symptom | Most likely class | Fast evidence to check | Ruling test |
|---|---|---|---|
| Only one zone is inaccurate | Geometry or NLOS hotspot | anchor participation; NLOS flags; zone map | Move the golden path slightly; compare anchor-set + bias behavior |
| Slow drift with temperature | Clock/sync drift or calibration aging | temp vs offset trend; reboot recovery time; cal-id age | Repeat baseline at two temperature points; compare drift signature |
| Sudden step after reboot/update | Calibration/profile mismatch | fw-ver, cal-id, profile-id consistency | Rollback to prior artifact set; verify if step disappears |
| AoA angle “wobbles” | Array channel mismatch / RF switching / calibration | channel gain/phase checks; array temperature; switch state logs | Run a static tag test; check angle variance under fixed geometry |
7) Reference parts (BOM) for deployment & validation kits (example options)
Purpose: accelerate bring-up with known-good silicon/modules and keep logs traceable. Part numbers below are representative; validate bands, regional rules, and supply.
| Block | Part number(s) | Where it fits in the playbook | Why it helps validation |
|---|---|---|---|
| UWB anchor/tag IC | DW3110 | L1 measurement health; L2 coverage; TWR/TDoA trials | Second-gen UWB transceiver used across TWR/TDoA evaluation flows |
| UWB infrastructure IC | NXP Trimension SR150 | Anchor-side infrastructure deployments | Anchor-grade UWB IC option for scalable indoor localization |
| Known-good UWB + BLE module | DWM3001C | Golden path scripts; baseline + tuning; quick A/B comparisons | Integrated module (UWB + BLE SoC + antenna) reduces RF bring-up variance |
| BLE direction finding SoC | nRF52833 | AoA/AoD IQ sampling control; array switching control | Common BLE direction-finding SoC used to sample packets and extract IQ |
| IMU for motion gating / fusion | LSM6DSOX / LSM6DSOXTR | Golden path repeatability; motion-triggered testing; drift signatures | Stable IMU reference reduces “motion noise” differences between runs |
| Antenna array RF switch (AoA) | SKY13418-485LF | AoA channel selection; static-tag angle variance tests | Provides deterministic antenna switching; supports channel consistency checks |
| Stable reference oscillator | SiT5356 (example ordering: SiT5356AC-FQ-33VT-32.000000) | Temperature drift studies; reboot recovery reproducibility | Improves frequency stability under environmental stressors for repeatable baselines |
| Clock distribution / jitter attenuation | Si5341 family (example: SI5341A-…) | Anchor clock tree robustness (principle-level) | Low-jitter clocking option for multi-output distribution and controlled skew |
| Durable log storage (SPI NOR) | W25Q64JV (and ordering variants such as W25Q64JVSFIQ) | Replay kit persistence; link-loss survivability | Stores trace logs + IDs to enable post-mortem root-cause replay |
Procurement note: distributors often add package suffixes (tape/reel, temperature grade). Keep the “manufacturer part number” in the replay kit alongside the firmware/calibration/profile IDs.
Request a Quote
H2-12｜FAQs ×12
These FAQs focus on shippable decisions and field-proof evidence for RTLS + edge geofencing: boundaries, method choice (UWB/BLE AoA), sync indicators (no PTP algorithms), fusion prerequisites, site physics, logging for replay, power/lifetime, and acceptance playbooks.
1 What is the practical boundary between RTLS and geofencing? When is “geofence-only” enough?
RTLS is continuous positioning (trajectory and uncertainty), while geofencing is event classification (enter/exit/dwell) using position and quality. “Geofence-only” is enough when the requirement is zone events with tolerant accuracy and predictable latency, not precise paths. The decision hinge is the cost of false alarms vs misses, and whether site physics (NLOS, geometry gaps) can be gated reliably.
- Evidence: event latency distribution, false alarm rate near boundaries, quality flags behavior in NLOS zones.
- Action: implement hysteresis + dwell first; add confidence gating before demanding higher positioning accuracy.
2 UWB TWR vs TDoA: if tag battery life is the top priority, which should be chosen and what is the tradeoff?
For tag battery life, TDoA is usually favored because the tag can transmit short beacons and avoid frequent receive windows. The tradeoff shifts burden to the infrastructure: anchors need tighter time consistency, and the system must monitor drift and recovery after reboots. TWR is easier to deploy but costs more tag energy because it requires round trips and more radio-on time per update.
- Evidence: tag radio-on budget (Tx + Rx windows), anchor-to-anchor offset trend vs temperature, retry rate.
- Action: pick TDoA when infrastructure can be controlled; pick TWR when anchors cannot be tightly managed.
3 Why does BLE AoA “angle wobble” in the field? What are the first three consistency checks?
Field AoA instability typically comes from inconsistency, not “lack of algorithms”. Start with (1) array geometry and spacing that avoid ambiguity, (2) channel gain/phase matching across the RF paths, and (3) switching/routing/ground reference issues that inject phase jitter or crosstalk. Treat temperature as a forcing function: stable lab angles that drift with temperature point to calibration and RF path skew.
- Evidence: static-tag angle variance, per-channel phase delta statistics, temperature-correlated drift signature.
- Action: lock down calibration ID + channel checks before changing anchor placement.
4 After moving installation positions, error suddenly increases—geometry or NLOS? How to decide quickly?
Separate geometry from NLOS using a three-step field method: (1) check if the problem is zone-local (geometry coverage or persistent occlusion), (2) test temperature correlation (drift suggests timing/calibration; sudden jumps suggest NLOS or anchor-set changes), and (3) replay a golden-path reference track and compare anchor participation and quality flags. Geometry issues track anchor-set size; NLOS issues track bias/jump signatures near obstacles.
- Evidence: anchor-set size distribution in the bad zone, jump/bias patterns, golden-path replay kit.
- Action: fix coverage first; then apply gating/hysteresis before re-tuning fusion.
5 How good does anchor sync need to be? If it is insufficient, does it look like drift or jumps?
“Good enough” sync is defined by stability under temperature and reboots, not by a single headline number. Insufficient consistency often shows as slow drift when oscillators move with temperature, and as step changes when anchors reboot or lose their reference and recover with a new offset. The most useful indicator is the time-offset trend plus the recovery time after disturbances. TWR tolerates looser sync; TDoA demands tighter control.
- Evidence: offset trend vs temperature, reboot recovery time, timestamp-layer placement (PHY/MAC/ISR level).
- Action: enforce traceable clock artifacts (fw-ver, cal-id) and re-run baseline after any recovery event.
6 What is the most common reason IMU fusion becomes worse—time alignment or calibration?
The most common failure is time misalignment: IMU samples, radio measurements, and geofence evaluation occur on different clocks or with variable latency, so the filter “corrects” the wrong moment and creates apparent drift or overshoot. Calibration is the next culprit (bias/scale/misalignment, temperature), especially when mounting changes. A practical rule: fix timing first (timestamps, interpolation, latency bounds), then validate calibration with static and controlled-motion tests.
- Evidence: lag between IMU and position updates, jitter in sample intervals, temperature-dependent bias signature.
- Action: gate fusion updates by synchronized timestamps; only then tune filter gains/constraints.
7 Geofence false alarms are too frequent—hysteresis, dwell, or confidence gating: which works first?
Use the lowest-cost fixes in order: start with hysteresis (a boundary band that prevents rapid toggling), then add dwell (require sustained presence before “inside” is accepted), and finally add confidence gating (block events when NLOS/low-quality flags are present). This order reduces false alarms without masking real moves. After that, adjust smoothing windows only if event latency is still within acceptable ranges.
- Evidence: boundary flip frequency, dwell-trigger misses/false triggers, event correctness under golden-path scripts.
- Action: lock a profile-id per site type and verify with the same acceptance script.
8 Should the gateway upload positions or raw measurements? How to balance bandwidth and replayable evidence?
Uploading positions is bandwidth-efficient and sufficient for most applications if each position includes quality metrics and the anchor set. Raw measurements enable deeper replay and root-cause proof but cost bandwidth and storage. A practical compromise is “hybrid reporting”: always upload events + sampled measurements, and keep a minimal replay kit locally so link loss does not destroy evidence. The minimal set is: timestamp, anchor-set, quality flags, firmware version, calibration ID, and profile ID.
- Evidence: availability of replay kit after outages, ability to reproduce a disputed event with the same artifacts.
- Action: define reporting granularity per site type; keep firmware/calibration/profile IDs in every log bundle.
9 In cold rooms or metal racks, what are typical NLOS/multipath symptoms and how to prove them in logs?
NLOS/multipath often appears as (a) sudden jumps near reflective boundaries, (b) persistent bias in a fixed zone, or (c) unstable angle estimates when the array sees competing paths. Proving it requires correlating symptoms to place and quality flags: show that errors cluster in the same physical region, worsen under specific occluders (doors/racks), and coincide with degraded first-path/quality indicators or reduced anchor participation. A golden-path replay with identical artifacts is the strongest “proof package”.
- Evidence: zone-local clustering, jump/bias signatures, quality flags + anchor-set snapshots over time.
- Action: apply confidence gating and add redundancy at event-critical zones before increasing update rate.
10 Tag lifetime misses the target—reduce transmit rate, receive windows, or fusion compute first?
Start with the dominant radio duty terms: reduce transmit rate and retry behavior, then shrink receive windows (or eliminate them when possible), and only then optimize fusion compute frequency. In most tag designs, compute is not the first-order drain compared to radio-on time, especially when retries and scanning windows expand under poor RF conditions. After radio duty is controlled, check sleep leakage and temperature impact, because cold and aging can change battery behavior and apparent “lifetime math”.
- Evidence: per-state current budget (Tx/Rx/compute/sleep), retry counts, scanning window utilization.
- Action: add motion-triggered wake and event-driven bursts; keep a stable baseline profile per site type.
11 Factory calibration or field calibration? How do temperature drift and part replacement affect validity?
Factory calibration is best for channel-to-channel consistency under controlled conditions; field calibration is best for site-specific bias and installation effects. A scalable approach is hybrid: factory calibration sets a stable baseline, while field calibration applies a small delta tied to the site map. Calibration validity is conditional: any antenna/array replacement, anchor relocation, major temperature regime change, or firmware update can invalidate assumptions. That is why calibration must be versioned (cal-id) and always paired with firmware version and profile-id in logs.
- Evidence: cal-id age vs drift, temperature-sweep baseline, step changes after replacement/reboot.
- Action: define “recal triggers” as a checklist, not a calendar date.
12 How to run a “golden path” acceptance so stakeholders immediately trust RTLS/geofence reliability?
A credible acceptance is a scripted, repeatable route with expected event outcomes and a replayable evidence bundle. Define a golden path containing straight segments, corners, doorway transitions, boundary dwell points, and fast pass-throughs. For each step, record expected enter/exit/dwell events, latency ranges, and quality constraints. Deliver a package: survey report, anchor map snapshot, baseline pass table, event timeline, and replay kit (timestamp, anchor-set, quality flags, fw-ver, cal-id, profile-id). If a dispute happens, replay must reproduce the same conclusion.
- Evidence: same script → same event timeline across days/operators; replay kit survives link loss.
- Action: lock acceptance artifacts as the “golden baseline” before tuning production thresholds.
