H2-1. Definition & System Boundary: Tag vs Anchor vs Gateway

Intent: align every reader to the same “map” in under a minute—what counts as a Tag, what counts as an Anchor, what a Gateway/Controller does, and what is explicitly out of scope for this page.

Owned responsibilities (what this page explains deeply)

• Tag hardware behaviors: duty-cycled radio activity (UWB/BLE), wake reasons, peak current events, anti-tamper triggers, secure identity.
• Anchor trust primitives: where the time stamp is taken, sync input/holdover path, timestamp jitter budget, anchor identity & anti-replacement signals.
• Inputs to positioning: ranging frames, time stamps, IQ samples—treated as engineering artifacts with measurable quality.

Referenced only (no deep expansion)

• Location engine: shown as an output consumer (it turns evidence into coordinates), but internal math/filters are out of scope.
• Network/PoE infrastructure: anchor may be PoE-powered, but only PD-side power-tree impact and measurement points appear here.

Typical topologies (what moves, what is trusted, what is measured)

Why boundary clarity matters in security RTLS: if identity, time stamps, or anti-tamper signals are not device-owned and verifiable, the final “position” can be spoofed or made non-repeatable. The page therefore treats time and trust as first-class engineering signals, not as software conveniences.

Evidence checklist (deployment inputs that must exist before design freeze)

These items become the “ground truth contract” used later by time-sync, calibration, validation, and field debug chapters.

H2-2. Positioning Methods: UWB TWR/TDoA vs BLE AoA (When & Why)

Intent: convert method names into engineering choices. Each method is judged by (1) who pays the energy cost, (2) who pays the synchronization/calibration cost, (3) the dominant error sources, and (4) the device-side evidence that proves or falsifies performance.

UWB Two-Way Ranging (TWR): trade power for lower sync dependence

• Why it works: distance is derived from two-way packet timing; anchors do not need a tight shared time base to produce a valid range.
• Cost: Tag power increases (extra RX/TX windows, crypto per exchange); air-time scales with Tag count and update rate.
• Best fit: fewer Tags, stronger anti-spoof constraints, environments where infrastructure sync cannot be guaranteed.
• Evidence to capture: per-exchange retry count, ToF consistency, CIR quality vs range, peak current events during ranging bursts.

UWB Time Difference of Arrival (TDoA): trade sync complexity for Tag battery life

• Why it works: Tag can transmit short beacons; multiple anchors time-stamp the same packet; time differences yield geometry constraints.
• Cost: anchors must maintain a trusted time base; small time-offset errors directly map into large position errors.
• Best fit: large Tag populations, long battery targets, deployments where anchors can be powered and periodically verified.
• Evidence to capture: anchor time-offset & jitter histograms, holdover drift vs temperature, “visible anchors per event” stats.

BLE AoA (Angle of Arrival): trade array calibration for cost-effective directionality

• Why it works: AoA anchors sample IQ across an antenna array and infer direction from phase differences.
• Cost: requires stable array geometry and calibration; reflective scenes create phase ambiguity (multipath dominates).
• Best fit: “direction of approach” use-cases, doorway/zone determination, cost-sensitive anchors with controlled installation geometry.
• Evidence to capture: phase residual metrics, per-antenna gain/phase health, IQ buffer overrun counters, angle variance vs RSSI.

Hybrid (UWB distance + BLE AoA angle): constrain AoA multipath with a range sanity check

• Why it helps: UWB range provides an independent constraint; AoA provides direction. When multipath inflates AoA variance, range gating rejects implausible angles.
• Device-side implication: both evidence streams must be time-aligned and tagged with trust quality (time stamp quality + IQ quality).
• Evidence to capture: matched time stamps between UWB events and AoA captures, range/angle consistency counters, NLOS flags.

Error sources → device-side evidence (turn “mystery drift” into measurable causes)

H2-3. RF Front-End & Antenna Architecture (UWB + BLE AoA Array)

Intent: explain why “bad positioning” is often not an algorithm problem. If the RF evidence (packets, CIR, IQ phase) is unstable, software can only amplify the instability. This chapter treats antennas, coupling, and the capture chain as the accuracy ceiling.

UWB chain (ranging evidence depends on spectrum + antenna + CIR)

• TRX + matching network: a poor match reduces link margin and makes CIR “noisy” (less reliable ToF peaks).
• Filter / SAW: sets out-of-band rejection; prevents adjacent radios and digital noise from lifting the noise floor.
• Antenna options (chip / PCB / external): choose by repeatability and detune risk (plastic, metal, human proximity).
• Spectral constraints: keep margin for mask/shape changes caused by layout, enclosure, and temperature (avoid “works in lab only”).

BLE AoA chain (angle evidence depends on multi-channel phase consistency)

• Antenna array geometry: spacing and polarization dominate systematic angle bias; enclosure metal creates strong reflections.
• RF switch + IQ sampling: channel-to-channel insertion loss and switching timing directly impact phase residual.
• Shielding & keep-outs: array needs stable near-field environment; ground return and nearby cables can create “moving reflectors.”

Shared antenna vs separated antennas (use measurable pass/fail rules)

Evidence to collect (turn “it drifts” into measurable RF causes)

H2-4. Time Sync & Timestamp Quality (Anchor-Side “Truth Clock”)

Intent: make time sync an engineering object—not a networking slogan. For TDoA and any fusion that depends on anchor time stamps, the anchor clock is the measurement ruler. If the ruler jitters, offsets, or drifts, the final position becomes noisy, biased, or time-dependent.

Anchor internal clock chain (where errors are introduced)

• Clock source: TCXO for cost/power; OCXO for higher stability in critical anchors. Selection is driven by required holdover drift and allowed jitter.
• PLL / jitter cleaning: shapes and distributes the clock; poor configuration can trade spur/jitter for “looks stable” but harms timestamp quality.
• Divider / clock tree: routes clocks to timestamp hardware; gating and domain crossings can introduce capture latency variation.
• Timestamp unit: the capture point must be explicit (e.g., UWB RX/TX event edges). If capture point is ambiguous, root cause cannot be proven.

Sync sources (reference only; keep focus inside the anchor)

• Wired sync input (e.g., from local controller): preferred when physical infrastructure allows periodic verification.
• Over-air sync (UWB): can reduce wiring but still requires anchor-side integrity monitoring and holdover behavior.
• Boundary: this page does not cover network switch timing architecture—only the anchor’s sync ingest, monitoring, and holdover.

Evidence to log (make time integrity auditable in the field)

H2-5. Security Model: Identity, Keys, Encryption, Replay Protection

Intent: in security RTLS, the goal is not only “can locate,” but “the location evidence cannot be forged.” Each ranging/angle/timestamp record must be bound to a verified device identity, a valid key generation, and a trusted firmware state.

Identity model (device-side only)

• Device identity should be verifiable and stable across resets; avoid relying on public radio identifiers as the trust anchor.
• Anchor identity is higher impact (it defines the “reference ruler”), so it must expose a verifiable identity plus a trust state (e.g., boot verified, key generation, sync state).
• Boundary: certificate issuance and cloud PKI workflows are out of scope; only device-side storage, verification, and audit signals are covered.

Key strategy (what matters is lifecycle, not jargon)

Encryption & integrity for UWB and BLE payloads

• UWB ranging exchanges: protect the fields that define the measurement (challenge/response, timing-critical data). The critical requirement is tamper-evidence (integrity) and optional confidentiality.
• BLE advertising payload: treat it as public and recordable. If advertising carries identity or session evidence, bind it to a fresh nonce/counter and authenticate it (so it cannot be replayed).
• Binding: cryptographic protection must bind identity + message type + nonce/counter + timestamp (if present) to prevent cut-and-paste forgeries.

Replay protection (make it power-loss safe)

• Rolling counter / nonce: tag increments a counter (or derives a nonce) per message; anchors reject repeats or out-of-window values.
• Power-loss behavior: replay defense fails if counters reset. Use a protected monotonic counter (typically inside Secure Element/OTP) or a robust “resume” rule that cannot be exploited.
• Window + reason codes: use a replay window with explicit reject reasons (duplicate, stale, counter rollback, nonce reuse).

Secure boot, firmware signing, rollback protection

• Secure boot: verify the boot chain before radios produce security evidence. If verification fails, enter a fail-secure mode (no trusted positioning evidence).
• Firmware signing: signature verification must occur in a trusted stage (ROM/immutable bootloader). Log verification outcomes.
• Rollback protection: prevent loading older vulnerable images by enforcing a monotonic version counter.

Evidence to log (auditable security, not “trust me”)

H2-6. Anti-Tamper & Physical Attack Surfaces (Tag vs Anchor)

Intent: close real-world threats (open, block, replace, spoof, jam) with hardware-visible evidence and policy actions. Anti-tamper is a closed loop: trigger → detect → decide → zeroize/degrade → log. The system must fail-secure rather than silently producing forged “trusted” location evidence.

Tag anti-tamper (mobile, near-field attack is common)

• Case-open switch: high-confidence trigger; requires mechanical integration and clear “open → untrusted” policy.
• Multi-sensor tamper: accelerometer/light/magnetic reed can cover bypass attempts; use thresholds to avoid transport/maintenance false alarms.
• Encapsulation / mesh: goal is not “never open,” but “opening is detectable and leaves evidence.”
• Zeroize policy: on tamper, erase secrets or lock them inside SE; then enter fail-secure mode (alarm-only or stop evidence).

Anchor anti-tamper (replace & port attacks are higher impact)

• Anti-replacement: anchor identity must not be clonable. Treat a new anchor as untrusted until it proves identity + trusted boot + key generation.
• Port protection: debug/maintenance interfaces should trigger state changes (port open → higher scrutiny / log events / limited function).
• Fail-secure behavior: if anchor trust is uncertain (tamper, boot fail, key error), mark outputs untrusted or stop producing trusted timestamps.

RF jamming/spoofing closure (evidence-based flags, device-side)

• RF anomaly indicators: sudden RSSI floor rise, CIR flattening, AoA variance explosion, or retry/CRC error spikes.
• Policy actions: mark measurement windows untrusted, throttle updates, and raise alarm events rather than outputting “normal-looking” but forged data.
• Audit requirement: record anomaly flags with timestamps to correlate with site incidents.

Evidence to record (prove the loop executed)

H2-7. Power Architecture: Battery Tag vs PoE Anchor (Budget First)

Intent: design from a power budget, not from a feature wish-list. For tags, update rate and security features must fit an energy envelope. For anchors, supply transients must not distort timestamps or RF waveforms, otherwise “trust clocks” and ranging evidence degrade.

Battery tag: build an “energy ledger” before choosing rails

Tag rail partition: domain split is for transients + noise + controllable shutdown

• Always-on domain: Secure Element / monotonic counter / minimal RTC or wake logic (must survive short dips without state corruption).
• Radio burst domain: UWB/BLE rails sized for peak current and short load steps; isolation reduces burst noise coupling into clocks and ADC paths.
• MCU domain: can be gated aggressively; keep wake latency predictable if it participates in timestamping or AoA capture coordination.
• Buck vs LDO: the selection is driven by peak droop margin, PSRR/noise into timing/RF blocks, and efficiency under the real duty cycle.

PoE anchor: treat load steps as a timestamp/RF integrity risk

• PoE PD → DC/DC rails: define which rail supplies clock/PLL, which supplies radio front-end, and which supplies MCU/log. Integrity problems often occur when these rails share impedance.
• Hold-up (supercap / small battery): not for uptime. It is for power-loss logging and time/state hold so the anchor does not reboot into an untrustworthy timestamp regime.
• Transient chain: burst current → PD/load-step → rail droop/ripple → timestamp capture quality and RF pulse shape distortion.

Evidence to capture (prove the budget is real)

H2-8. Scheduling & Coexistence: UWB + BLE AoA + Crypto + Logging

Intent: explain why higher update rates often “drift” even with the same RF hardware. The bottleneck is frequently scheduling: timestamp windows and IQ captures are real-time evidence. Interrupt latency, DMA contention, and storage writes can break evidence integrity and appear as positioning error.

Timeslot model (queue the evidence producers)

• UWB ranging window: schedule TX/RX events so timestamp capture occurs with minimal jitter and stable ISR latency.
• BLE advertising + AoA IQ capture: AoA capture is more fragile than plain advertising because DMA and sample timing must not slip.
• Crypto: message authentication/encryption must fit inside slack time, otherwise it steals time from capture windows.
• Logging: log writes should be buffered and flushed outside capture windows; avoid flash writes during AoA or timestamp-critical edges.

Two dominant failure modes (and what to measure)

• Interrupt latency → timestamp bias: delayed ISR/service time shifts capture points. Measure worst-case IRQ latency and missed-event counters, not just average CPU load.
• DMA contention → IQ overrun: bus/DMA conflicts drop or delay IQ samples. Measure IQ buffer overrun, DMA error counts, and AoA variance spikes correlated to load.

Storage atomicity (device-side): calibration, key version, event logs

• Calibration data: must be written atomically (CRC + swap), but never at the expense of real-time capture. Prefer deferred commit after windows.
• Key versions/counters: atomic update protects replay defenses. Counter rollback due to partial writes creates a replay window.
• Event logs: use a RAM ring buffer + deferred flush. Log flush bursts should be measurable and rate-limited.

Evidence counters (prove the scheduler is the root cause)

H2-9. Calibration & Production Test (AoA Phase / Ranging Bias / Time Offset)

Intent: turn “factory consistency” into a repeatable SOP. Without calibration, stable positioning is not achievable. This chapter defines what must be measured, how calibration is sealed and audited on-device, and how runtime applies parameters without breaking security or consistency.

AoA calibration: phase, gain, and array geometry

• What to measure: reference angle sweeps (or fixed known angles) to estimate per-path phase and gain mismatch; validate residual phase error after calibration.
• What to store: phase_offset[], gain_trim[], and a compact geometry_model (or factory-measured spacing parameters). Add band_id and temp_model_id for runtime selection.
• Runtime apply: apply phase/gain corrections before AoA estimation; expose counters such as aoa_apply_ok, aoa_phase_residual_p95, aoa_variance.

UWB calibration: ranging bias, antenna delay, and CIR quality gates

• Ranging bias SOP: measure at known distances; compute a per-config bias (single offset) or a small fitted curve. Store as uwb_bias_model.
• Antenna delay SOP: measure board-specific TX/RX delays; store tx_ant_delay and rx_ant_delay.
• CIR gating: define “good evidence” thresholds from factory statistics (e.g., minimum CIR quality score). Expose cir_quality and reject_reason counters at runtime.

Anchor time calibration: offset initialization and temperature drift compensation

• Offset initialization: measure each anchor’s timestamp offset to a reference during production; store time_offset_init.
• Drift model: store a compact temperature drift coefficient or LUT identifier as drift_model; expose offset_hist_p95 and jitter_hist to prove stability.
• Apply point: apply corrections at the timestamp unit boundary (before evidence is emitted to the gateway boundary) and log apply status.

Calibration storage contract (sealed, CRC, and write-protected)

H2-10. Validation Metrics & Test Plan (Security RTLS-Focused)

Intent: define acceptance KPIs that are testable and auditable. Validation should align scenarios × metrics × thresholds × evidence fields so accuracy, latency, robustness, power, and security claims can be verified up to the gateway boundary.

Core KPI groups (gateway-boundary)

Acceptance test matrix (scenario × metric × threshold × evidence)

Key measurement points (power/clock/RF/log) for repeatable validation

• Power points: tag PMIC output rails; anchor PD input and clock/radio rails during bursts.
• Clock/timestamp points: timestamp capture boundary (track jitter/offset histograms).
• RF evidence points: CIR quality, AoA IQ overrun/late capture, retry/missed response counters.
• Log points: diagnostic port or structured counters for reject_reason, apply_ok, and security events.

H2-11. Field Debug Playbook: Symptom → Evidence → Isolate → Fix

Intent: this is the strongest EEAT module—engineers should be able to diagnose fast using a strict evidence chain. Each symptom starts with the first 2 measurements, then a discriminator, then a first fix that can be verified immediately.