Wireless Alarm Repeater (Sub-GHz/LoRa/BLE)
← Back to: Security & Surveillance
A Wireless Alarm Repeater is built to extend alarm coverage without losing trust: it forwards events reliably through RF congestion and power interruptions by combining robust link design, replay-safe buffering, and brownout-proof backup power. This page shows what to measure (PER/RSSI/SNR, retries, queue depth, reset reasons) and how to fix failures fast in the field.
Scope, Roles, and Failure Modes This Page Owns
Definition for this page: a Wireless Alarm Repeater is a coverage extender that also acts as a
reliability node—it can buffer, retry, and de-duplicate event forwarding so short RF outages,
interference bursts, or brownouts do not silently drop critical alarms.
What this page covers (and what it refuses to cover)
Owned scope: Sub-GHz / LoRa / BLE radio + MCU low-power strategy, event buffering & forward control,
evidence logging, backup/hold-up supply, and field-proof debug signals.
Out of scope: alarm panel/gateway business logic, cloud/app tutorials, CCTV/NVR/VMS pipelines, PoE switch/PSE design,
and any deep timing infrastructure (no IEEE-1588 deep dives).
Typical deployments (why repeaters exist)
- Residential / small office: walls, metal doors, and appliance noise create shadow zones where direct links look “OK” but still fail under interference.
- Commercial buildings: dense nodes increase contention and retries; jitter and duplicates become the main risk rather than pure RSSI.
- Warehouse / campus: long paths, floor slabs, and moving machinery raise blocking and brownout risk during TX bursts.
Top failure modes (symptom → first evidence → fastest isolation)
- Dropped events: check PER + CRC fail vs queue overflow counters; isolate RF demod vs buffer depth.
- Latency spikes: check forward queue depth + retry count; isolate airtime contention vs store-and-forward backlog.
- Duplicate / false alarms: check seq window + dedup drops; isolate replay after reset vs TTL/ack policy.
- Battery drain: check RX window duty + retries per hour; isolate RF congestion vs sleep leakage.
- Resets / reboots: check reset reason + min system voltage during TX; isolate TX current spike vs watchdog.
PER
RSSI / SNR
Retry Count
Queue Depth
Brownout Count
Reset Reason
Minimum Evidence Set (must be measurable in the field)
The repeater should expose a small, stable set of counters/telemetry that makes failures provable, not guessable. These items are referenced throughout later chapters.
| Evidence item | What it proves | Where it comes from | Fast interpretation |
|---|---|---|---|
| PER (packet error rate) | Link reliability under real interference | Rx demod stats + CRC results | PER rises while RSSI stays stable → blocking/congestion likely |
| RSSI / SNR | Signal margin vs noise/interference | Radio RSSI/SNR registers | Same RSSI, lower SNR → in-band noise / co-channel contention |
| Retry count | Airtime pressure and collision severity | MAC/forward policy counters | Retries spike → latency spikes follow (queue backlog) |
| Forward queue max depth | Buffering vs overload/overflow risk | MCU ring/queue telemetry | Depth saturates → expect drops or delayed alarms |
| Brownout count + min Vsys | Power integrity under TX bursts | Supervisor + ADC min capture | Resets only during TX → rail dip / UVLO threshold |
| Reset reason | Whether reboot is power, WDT, or fault | MCU reset flags + supervisor | WDT resets → firmware latency; BOR resets → power tree |
Cite this figure
Figure F1 — Alarm network topology for wireless alarm repeater (direct vs via repeater, zones, shadow coverage, optional multi-hop).
System Architecture: Radio Front-End + MCU + Buffer + Backup Supply
Design objective: keep forwarding reliable under interference and power transients by organizing the repeater into
three power domains and four engineering chains (RF, Control, Data, Power). Every failure mode should map to
a measurable point in one of these chains.
Three domains (power + behavior)
| Domain | What stays alive | Why it exists | Typical evidence |
|---|---|---|---|
| Always-On | Wake sources, RTC timebase, minimal supervisor | Guarantees wake + timestamp continuity with ultra-low idle power | RTC drift, wake reason, min Vsys capture |
| Sleep | MCU retention (optional), light telemetry | Fast response without burning battery | Sleep current, wake latency, retention health |
| Burst | RF RX/TX, PA/LNA, high-rate NVM commits | Handles event receive/forward; highest brownout risk | TX current spike, brownout/reset reason, retry count |
Four chains (what to design, what to measure)
- RF chain: Antenna → Match → Filter → (LNA/PA) → Transceiver. Measure: RSSI/SNR vs PER, blocking symptoms, sensitivity at chosen data rate.
- Control chain: MCU ↔ Transceiver bus + IRQ. Measure: wake-to-RX time, ISR latency peaks, watchdog/reset flags under traffic bursts.
- Data chain: RX validate → buffer commit → forward queue → TX + ACK. Measure: queue depth, overflow drops, dedup hits, commit pointer recovery after reset.
- Power chain: Input/backup → regulation → supervisor → domain gating. Measure: Vsys min during TX, UVLO threshold behavior, brownout count.
Key modules (what must be explicit in the architecture)
RF front-end (FEM): matching network + filtering; optional external LNA/PA for harsh sites. The goal is not raw RSSI—it’s
robust demod under near-field interferers (blocking/intermod).
MCU low-power core: a deterministic state machine should bound RX windows, retries, and buffer commits so “interference storms”
do not turn into battery storms.
Event buffer: RAM ring buffer for short bursts; NVM journal if critical events must survive resets/brownouts.
The buffer must support dedup windows, TTL, and commit pointers.
Backup / hold-up supply: isolate “short hold-up” (finish safe commit + one forward) from “long backup” (hours/days).
The design must record min voltage and reset cause to make power faults provable.
Architecture checkpoints (fast, field-relevant)
- TX burst immunity: the power tree must tolerate peak TX current without crossing UVLO; log min Vsys during TX.
- Congestion containment: retries and queue depth must be bounded; log retry peaks and queue max.
- Reset-safe buffering: event commits must be atomic enough to recover after a reset; log recovery events and last commit pointer.
- RF front-end realism: range is limited by SNR + blocking, not marketing power; verify with a site walk and PER map.
Cite this figure
Figure F2 — Wireless alarm repeater block diagram (RF FEM + transceiver, MCU low-power state machine, event buffer with commit pointers, and backup/hold-up power with reset evidence).
RF Link Budget That Actually Predicts Range (Not Marketing)
Key idea: the field question is not “how far,” but how much Rx margin remains after real path losses and penalties.
A link fails immediately when margin < 0 dB; it becomes unstable long before that when margin is small and the environment is time-varying.
What must be quantified (minimum inputs)
- Tx EIRP: actual radiated power after antenna + matching losses (regulatory and duty-cycle constraints are noted but not expanded here).
- Rx sensitivity by mode: sensitivity changes with data rate (FSK) or SF/BW (LoRa), so “same hardware” can differ by many dB.
- Noise & efficiency: receiver NF, antenna efficiency, placement detune (near metal), and orientation/polarization mismatch.
- Site losses: walls/floors/metal doors/racks, plus human-body absorption and installation height.
Fast workflow (useful on-site)
- Step 1 — Lock the radio mode and rate Choose one operating point (FSK rate or LoRa SF/BW) and use its sensitivity. Changing rate changes margin.
- Step 2 — Build path loss as blocks Treat each obstacle as an additive block (wall, floor slab, metal door). Add penalties for placement and polarization.
- Step 3 — Compute margin and decide Margin = Tx EIRP − Path Loss − Penalties − (Rx Sensitivity threshold). If margin is negative, drops are guaranteed.
- Step 4 — Validate with statistics, not one reading Use RSSI/SNR distributions and PER vs RSSI curves to confirm whether failure is margin-limited (H2-3) or robustness-limited (H2-4).
Radio capability table (why “same repeater” behaves differently)
Fill this once per repeater platform. It prevents “rate drift” from silently changing range and reliability.
| Mode | Setting | Rx sensitivity (dBm) | Trade-off | Field note |
|---|---|---|---|---|
| FSK | Low rate | Fill from datasheet / measurement | Better sensitivity, longer airtime | More collision risk under congestion |
| FSK | High rate | Fill from datasheet / measurement | Lower latency, worse sensitivity | May “work on one floor, fail on another” |
| LoRa | High SF / narrow BW | Fill from datasheet / measurement | Max range, longest airtime | Duty-cycle and airtime budgeting become critical |
| LoRa | Low SF / wide BW | Fill from datasheet / measurement | Lower latency, less range | Often stable indoors only with good placement |
Site link budget worksheet (the “why A works, B fails” table)
This worksheet is built for on-site estimation. Use additive blocks so the cause of failure is visible.
| Item | Symbol | Value (dB / dBm) | How to obtain | Common mistake |
|---|---|---|---|---|
| Tx EIRP | EIRP | Fill | Radio output + antenna gain − matching/placement loss | Using “PA rating” instead of radiated EIRP |
| Path loss blocks | PL | Fill | Sum wall/floor/metal blocks on the path | Ignoring floor slab / steel reinforcement |
| Penalties | PN | Fill | Polarization mismatch, near-metal detune, body absorption | Mounting too close to metal surfaces |
| Rx sensitivity | SENS | Fill | From capability table at the chosen rate/SF/BW | Changing rate without updating sensitivity |
| Rx margin | M | M = EIRP − PL − PN − (SENS) | Compute once, then validate with PER statistics | Using single RSSI reading as “margin” |
Evidence-based validation (three field plots)
- RSSI/SNR histogram: shows whether the link is stable or has long tails (time-varying environment).
- PER vs RSSI curve: distinguishes margin-limited failure (PER rises only when RSSI drops) from robustness-limited failure (PER rises at the same RSSI).
- Retry rate vs time: identifies interference windows and congestion bursts that create latency and duplicates.
Margin
RSSI/SNR
PER
Retries
Cite this figure
Figure F3 — RF link budget meter for wireless alarm repeater (EIRP, path-loss blocks, placement penalties, sensitivity by mode, and Rx margin drop zone).
Receiver Robustness: Blocking, Intermod, Co-Channel Congestion
Reality check: a “good RSSI” can still produce high PER. Receiver robustness is limited by
SNR, front-end headroom (compression/AGC), and airtime contention.
This chapter provides discriminators that map symptoms to measurable evidence.
Three failure classes (and how to tell them apart quickly)
- Blocking / compression: a strong interferer drives the front-end into compression. Evidence: SNR drops while RSSI stays high; preamble miss / sync lost rises.
- Intermodulation: two (or more) strong signals create in-band products due to nonlinearity. Evidence: failures appear only when specific devices are active together; spectrum shows unexpected in-band energy.
- Co-channel congestion: too many nodes share airtime; collisions and retries dominate. Evidence: retry count and channel busy (if available) rise with time-of-day and traffic; PER rises at similar RSSI.
Hardware levers inside a repeater (no platform scope creep)
- Front-end filtering: SAW/BAW/LC filtering improves adjacent rejection and reduces out-of-band energy that causes blocking.
- LNA linearity: improved headroom reduces compression under near-field interferers.
- PA harmonics control: harmonics can self-pollute or desense; filtering and layout discipline reduce self-interference.
- Antenna placement: near-metal detune and near-field coupling can reduce effective sensitivity and worsen selectivity in practice.
Evidence chain (minimum tools to maximum certainty)
- Level 1 — Counters + statistics (no spectrum analyzer required) Use PER + retries + queue depth + SNR/RSSI distributions to decide whether the issue is margin (H2-3) or robustness (H2-4).
- Level 2 — Simple spectrum sweep Look for strong peaks, raised in-band noise floor, or time-of-day patterns that correlate with retry bursts.
- Level 3 — Demod failure classification (chip dependent) Compare CRC fail vs preamble miss vs sync lost to distinguish low SNR from front-end saturation or interference-driven sync loss.
Demod failure classifier (fast diagnosis table)
| Primary counter | Most likely cause | What to check next | First fix (within repeater scope) |
|---|---|---|---|
| Preamble miss ↑ | Front-end saturation, AGC behavior, strong interferer | SNR histogram tail, spectrum peaks near band | Improve filtering / placement; reduce near-field coupling |
| Sync lost ↑ | Interference bursts, timing recovery instability | Time-of-day correlation, interference on/off tests | Harden front-end headroom; adjust RX window strategy |
| CRC fail ↑ | Low effective SNR or collision-driven corruption | PER vs RSSI at stable RSSI; retry bursts | Reduce congestion impact (retry bounds), refine channel plan |
| Retry ↑ with stable RSSI | Co-channel contention / collision | Queue depth peaks, channel busy indicators | Backoff/slotting, cap retries, prioritize critical events |
Typical near-field interferers: VFD motors, switching supplies, other Sub-GHz devices, and strong LTE/5G proximity energy. The key is to treat “strong nearby” as a headroom problem, not a raw RSSI problem.
Cite this figure
Figure F4 — RF interference storyboard for wireless alarm repeater (wanted + interferer, noise floor rise, headroom/AGC saturation, and demod failure counters).
Multi-Radio Strategy (Sub-GHz + LoRa/FSK + BLE) Without Burning Power
Goal: multi-radio support must behave like a time-sliced system with clear roles:
LoRa for coverage, FSK for latency/throughput, and BLE only for local maintenance.
The strategy is validated with a power budget and a latency bill of materials.
Protocol roles (keep BLE out of the main alarm path)
- LoRa: best when penetration and link budget dominate (weak-signal zones, multi-floor shadows). Expect longer airtime.
- FSK: best when lower latency and higher throughput matter (denser deployments, higher event rate). Expect lower sensitivity at high rates.
- BLE (strict scope): provisioning, near-field diagnostics, and short-range bypass only. No phone/app workflow content.
Decision policy (inputs → actions)
A repeater should decide using measurable inputs, not “default to the longest range.” Use link margin and congestion indicators to pick the primary path.
| Input (measurable) | Indicator | Action | Reason |
|---|---|---|---|
| Weak link margin | Low SNR / high PER at stable RSSI | Select LoRa (higher link budget) | More demod margin under penetration loss |
| High event density | Queue depth rising, airtime busy | Select FSK (higher throughput) | Shorter airtime reduces collision pressure |
| Congestion window | Retry bursts vs time-of-day | Cap retries, enforce backoff, prioritize alarms | Avoid retry storms that create latency spikes |
| Local maintenance mode | Physical presence / service flag | Enable BLE in a time-limited window | Prevent background BLE scanning from draining battery |
Power budget template (sleep / wake / RX windows / TX bursts)
Power is dominated by time spent in RX windows and TX airtime under retries. Treat each radio as a duty-cycle contributor.
| State | Symbol | Current | Time / count | Energy driver | Mitigation lever |
|---|---|---|---|---|---|
| Sleep | Islp | Measure | tslp | Baseline drain | Reduce always-on peripherals |
| Wake overhead | Iwk | Measure | Nwk × twk | Frequent wakeups | Batch work; stabilize scheduling |
| RX window | Irx | Measure | Nwin × twin | Window frequency dominates | Adaptive windowing by risk/traffic |
| TX burst | Itx | Measure | (tair × (1+retries)) | Retries create spikes | Retry cap; better demod margin |
| BLE maintenance | Ible | Measure | tble (time-limited) | Scanning is expensive | Enable only on service trigger |
Latency decomposition (the “alarm response bill”)
Tdetect
Time to catch the event in a listen window (window schedule dominates)
Twake
MCU + radio wake and readiness time (clock/PLL + firmware path)
Tair
On-air time (LoRa SF/BW or FSK rate determines airtime)
Tqueue
Queueing delay (event rate, prioritization, congestion)
Tretry
Retry delay (collisions/interference; bounded by retry policy)
Evidence to log (so the strategy is provable)
- Power: sleep_ms_total, rx_window_total_ms, tx_airtime_total_ms, wake_count, ble_on_ms
- Latency: detect_ts, forward_ts, queue_depth_peak, retry_count, per_est
- Mode selection: primary_radio, fallback_reason, margin_est, congestion_flag
Duty-cycle
Airtime
Latency BOM
Retry cap
Cite this figure
Figure F5 — Multi-radio state machine timeline for a wireless alarm repeater (sleep/wake/RX window/buffer/forward/ACK with radio slots and power level).
Event Buffering & Replay-Safe Forwarding (What to Store, For How Long)
Core requirement: alarms must be durable (not lost on fades/reboots), ordered (no confusing reordering),
and non-duplicating (no repeated triggers), while limiting replay risk using a minimal on-repeater policy.
What to store (event record fields)
Store a minimal persistent record for durability and deduplication. Keep diagnostics to the extent flash endurance and memory allow.
| Field | Purpose | Persistent? | Notes |
|---|---|---|---|
| event_id | Stable identity for dedup and audit | Yes | May be hash(source_id, seq, ts, type) |
| source_id | Per-sensor identity | Yes | Used for seq window and replay checks |
| timestamp | Ordering and TTL expiry | Yes | RTC or monotonic tick (with epoch mapping) |
| seq | Ordering + dedup window | Yes | Use sliding window per source_id |
| type | Alarm vs status vs tamper | Yes | Allows priority and retention differences |
| RSSI/SNR | Diagnostics | Optional | Helps root-cause poor links and congestion |
| retry_count | Diagnostics and health metric | Optional | Useful for “retry storms” evidence |
| battery_state | Context for brownouts | Optional | Snapshot on store/forward |
How to store (ring buffer + journal + commit pointer)
- Append-only slots: write events sequentially to fixed-size slots to avoid in-place corruption under power loss.
- Commit pointer (CP): advance only after the record and its integrity check (CRC) are fully written.
- Boot recovery: after a reset/brownout, scan the last few slots to find the most recent valid commit and rebuild the forward queue.
Replay-safe forwarding (dedup, TTL, and minimal replay window)
- Dedup window: per source_id, keep a sliding window of recent seq numbers (or a bitmask) to drop duplicates.
- Ack bitmap/map: mark forwarded events by event_id to prevent re-trigger during retries and after reboot recovery.
- TTL: discard events past retention to avoid stale alarms firing after long outages.
- Replay window: accept only seq/nonce values inside a bounded window; reject old replays even if RF delivers them again.
Evidence chain (what must be provable after a power cut)
- Reset cause: reset_reason + brownout flag.
- Recovery: recovered_commit_pointer and recovered_slot_count.
- Behavior: forward_queue_length, resend_count, dedup_drop_count, ttl_drop_count.
- Integrity: “last committed pointer” never moves backward; duplicates are suppressed by ack/dedup.
Cite this figure
Figure F6 — Event buffering and replay-safe forwarding model for a wireless alarm repeater (ring buffer journal with commit pointer, forward queue, ack bitmap, and replay window).
Backup Supply & Brownout Immunity: Battery, Supercap, Hold-Up Done Right
Objective: keep the repeater stable during mains loss and TX current spikes:
no brownout resets, no corrupted event pointers, and no “ghost repeats” after reboot.
Validation must rely on two waveforms and reset/brownout counters.
Supply modes (define “hold-up” vs “backup”)
- Hold-up (seconds): ride through short dropouts and switching gaps using a supercap or small reserve.
- Backup (minutes–hours): battery supports continued operation, but requires stricter duty-cycle and retry limits.
- Hybrid: supercap absorbs spikes and switch gaps; battery provides longer runtime.
Why brownouts happen (the repeatable failure mechanism)
- UVLO/BOR thresholds: resets trigger when Vcore crosses a threshold, not only when input collapses.
- TX burst step load: PA ramp causes a fast ΔI; input-path impedance (ESR/Rds_on/trace) turns it into ΔV.
- Switching gap: ORing/ideal diode switchover can create a short dip that coincides with TX activity.
- Unsafe writes: flash/journal updates during power-fail edges can corrupt commit pointers and re-trigger events after reboot.
Design anchors (hardware + firmware hooks)
ORing / ideal diode
Supervisor / BOR
Power-fail interrupt
Safe commit
- Ideal-diode ORing: ensure one-way conduction and controlled switchover (avoid reverse feed and negative dips).
- Supervisor reset: clean reset behavior and a reliable reset-cause register (POR/BOR/WDT/SW).
- Power-fail path: a fast “power-fail” indication (supervisor flag or ADC threshold) to enter a safe mode.
- Last safe commit: on power-fail, stop non-essential TX, write only the minimal journal metadata (pointer + CRC), then forbid further flash writes.
- Telemetry hooks: brownout_count, last_reset_reason, min_voltage_logged, tx_abort_on_pfail_count.
Validation evidence (must capture)
- Waveform #1: VBUS/VBAT (input node) during mains loss and ORing switchover.
- Waveform #2: Vcore (or main DC/DC rail) during TX burst; compare the minimum to the UVLO/BOR threshold.
- Log counters: brownout_count, last_reset_reason, min_voltage_logged; optionally tx_retry_count and commit_on_pfail_count.
| Symptom | First two checks | Most likely root cause | First fix lever (repeater-side) |
|---|---|---|---|
| Resets only when TX happens | Vcore dip vs UVLO, TX ramp timing | Input-path impedance too high, DC/DC headroom low | Lower Zpath, add hold-up, tune TX ramp / cap retries |
| Resets right after mains loss | VBUS/VBAT switchover dip, ORing behavior | ORing gap or reverse feed causing transient dip | Ideal diode ORing, faster switchover, add local bulk |
| Events duplicated after reboot | Reset reason + commit pointer recovery log | Unsafe write during power-fail | Power-fail ISR: minimal safe commit + write lockout |
Cite this figure
Figure F7 — Wireless alarm repeater power tree and hold-up validation (mains/backup ORing, DC/DC rails, supervisor, and Vcore sag vs UVLO during TX burst).
Timebase, Timestamping, and “Good-Enough” Sync for Alarm Networks
Goal: make event ordering and deduplication reliable without entering PTP/1588 complexity.
The repeater needs monotonic timestamps, wrap-around safe counters, and a bounded error budget for dedup/replay/TTL windows.
Clock sources (what matters for alarm semantics)
- 32 kHz RTC crystal: higher drift; long outages can stretch or shrink time windows.
- TCXO: lower drift; improves window stability when timestamp-based merging and TTL are strict.
- Key point: drift is not “accuracy”; it changes window decisions (dedup/replay/TTL) over time.
Timestamp strategy (repeater-side, implementation-friendly)
- Capture t_rx: timestamp the moment the event is received (per radio) for ordering evidence.
- Capture t_fwd: timestamp the moment the event is forwarded; helps estimate hop delay and queue pressure.
- Optional correction hook: store a coarse offset (offset_correction) received from upstream; apply slowly and never break monotonicity.
- Do not depend on absolute time: use monotonic ticks plus an epoch mapping if needed; keep algorithms robust to missing “wall time”.
Monotonicity & wrap-around (two pitfalls that break dedup)
- Monotonicity: timestamps must not move backward; otherwise replay/dedup windows misfire.
- Wrap-around: tick counters overflow; comparisons must use wrap-safe arithmetic (extended counters or modular compare rules).
- Window margins: dedup/replay/TTL windows must include drift + hop-delay jitter margin to avoid false drops.
Evidence to log (so “good-enough” is provable)
- Monotonicity: timestamp_backstep_count (or log markers) + last_ts_seen per source_id.
- Wrap handling: wrap_event_count + extended_tick_highword.
- Hop delay proxy: (t_fwd − t_rx) stats: min/avg/max, queue_depth_peak, retry_count.
- Window outcomes: dedup_drop_count, replay_reject_count, ttl_drop_count.
Cite this figure
Figure F8 — Alarm-network timestamp chain and error budget for a wireless alarm repeater (monotonic timestamps, drift + hop-delay jitter, and window margin sizing).
Validation & Site Survey: Prove Coverage, Capacity, and Battery Life
Pre-deployment requirement: coverage must be mapped, capacity must be stress-tested, power must be budgeted, and resilience must be proven.
Every result should be tied to measurable KPIs (RSSI/SNR/PER, airtime, queue overflow, latency percentiles, brownout/reset logs).
What this validation package must prove
CoverageRSSI/SNR distribution + PER heatmap
Capacityevents/sec, airtime, collision, queue stability
PowerI_sleep, daily energy, TX/retry share
Resiliencemains loss, interference, temperature drift
Site survey workflow (minimal but sufficient)
- Step 1 — Baseline: fix radio mode (rate/SF/BW), TX power profile, retry policy, and RX window schedule.
- Step 2 — Walk path: measure at representative points (corridors, corners, stairwells, elevator shafts, metal doors).
- Step 3 — Time slicing: repeat measurements across at least two time windows (quiet vs busy) to expose congestion/interference.
- Step 4 — Stress: inject traffic up to the expected peak event rate; log queue depth and latency percentiles.
- Step 5 — Resilience: run mains-loss switchover and strong-interferer tests; verify no brownout resets or unsafe commits.
- Step 6 — Report: produce a coverage map + capacity envelope + daily energy estimate + resilience checklist.
Validation matrix (recommended table format)
| Group | Goal | Data to log (minimum) | Procedure (minimum) | Pass gate (example) | Failure signature (what it looks like) |
|---|---|---|---|---|---|
| Coverage | Predict where packets drop and why | RSSI, SNR, PER, retry_count, point_id, time_slice | Walk path; sample per point; repeat across time windows | Worst-zone PER below target; no “unknown” blind spots | Low RSSI+SNR in zones (shadowing) vs normal RSSI but low SNR (interference) |
| Capacity | Prove events/sec without queue collapse | events_in, events_fwd, queue_depth_max, overflow_count, airtime_busy, P95 latency | Step-load traffic; hold each level long enough to stabilize | No overflow; P95 latency within gate at peak load | Queue depth spikes, overflow, latency tails, retry storms |
| Power | Estimate battery life with real duty cycles | I_sleep, I_rx_window, TX_burst_energy, retry_ratio, daily_energy_est | Measure sleep + RX window + TX burst; compute daily sum | Daily energy within budget for target runtime | High retry share; unexpected always-on current; TX dominates energy |
| Resilience | Survive dropouts, interference, temperature | brownout_count, last_reset_reason, min_voltage_logged, PER vs time, timestamp monotonicity markers | Mains loss + TX burst; strong interferer; temperature sweep/cycle | No BOR resets; safe commit on power-fail; stable ordering windows | BOR increments, reset loops, duplicated events, timestamp backsteps |
Note: pass gates should be chosen to match the deployment risk tolerance. The key is that each gate is tied to measurable counters and waveforms.
Cite this figure
Figure F9 — Wireless alarm repeater validation matrix: RF/Power/Time/Buffer KPIs and a practical pre-deployment workflow (survey, stress, resilience, report).
Field Debug Playbook: Symptom → Evidence → Isolate → Fix
Format rule: every symptom below lists First 2 measurements, a discriminator (RF vs power vs buffer/time), and a first fix.
This playbook is designed to work with minimal tools: a scope, a basic spectrum scan (optional), and firmware counters/logs.
Symptom A — Zone-specific dropouts / time-of-day packet loss
- First 2 measurements: (1) PER vs RSSI/SNR by point_id and time_slice, (2) retry_count distribution + (optional) spectrum snapshot for in-band noise/bursts.
- Discriminator: low RSSI+low SNR → coverage shadow/antenna placement; normal RSSI but low SNR + CRC fails → interference/blocking; strong time-of-day pattern → co-channel congestion or periodic interferers.
- First fix: move/raise antenna away from metal and wiring; adjust channel/mode; cap retry storms; add front-end filtering if blocking is repeatable.
Symptom B — Latency jitter / bursty delay
- First 2 measurements: (1) latency split: Tdetect + Twake + Tair + Tqueue + Tretry, (2) queue_depth and retry_count correlated to P95 latency.
- Discriminator: queue_depth spikes → buffering/scheduling bottleneck; retry_count spikes → RF collisions/interference; Twake variance → RX window / multi-radio slot conflicts.
- First fix: introduce priority queue for alarm-critical events; bound retries; reduce airtime per event; reshape RX windows to avoid overlap and long wake gaps.
Symptom C — Post-outage false alarms / missed alarms
- First 2 measurements: (1) Vcore vs UVLO during mains-loss switchover and TX burst, (2) last_reset_reason + brownout_count + buffer recovery markers (commit pointer, replay rejects).
- Discriminator: BOR resets + min_voltage dips → power path/hold-up weakness; duplicated events after reboot → unsafe writes / commit policy; missed events exactly at switchover → ORing gap or power-fail handling latency.
- First fix: improve ORing and hold-up; enforce power-fail safe commit (minimal pointer+CRC then write lockout); suppress non-essential TX during power-fail mode.
Symptom D — Fast battery drain / reboot loops
- First 2 measurements: (1) daily energy breakdown: sleep + RX windows + TX + retries, (2) brownout_count vs TX share/retry ratio vs min_voltage_logged.
- Discriminator: high retry share → RF quality drives energy collapse; frequent BOR during TX → input impedance/ESR too high or hold-up insufficient; high sleep current → always-on domain leakage or peripherals not gated.
- First fix: cap retry storms and reduce airtime; restore link margin (antenna placement/mode/channel); strengthen hold-up and input path; verify low-power gating and wake schedule.
Cite this figure
Figure F10 — Wireless alarm repeater field debug decision tree (symptoms → evidence gates → isolate → first fix actions).
H2-11. IC Selection (MPN Examples) — Repeater-Grade BOM
Goal: pick parts that survive real alarm deployments (congested RF + brownouts + burst traffic) and still preserve event integrity (no loss, no reorder, no replay). This chapter lists concrete MPN examples by block, plus “what must be measured” to validate the choice.
MPNs below are reference candidates; always verify regional band, output power limit, package suffix, temperature grade, and availability before freezing a BOM.
11.1 BOM decision map (fast routing)
Short-range / low-latency repeater: Sub-GHz (FSK) + tight RX windows + small buffer → prioritize blocking/selectivity + brownout logs.
Long-range / penetration-first: LoRa (SX/BW/SF tuned) + larger buffering → prioritize TX burst current + NVM endurance.
BLE role (repeater-side only): provisioning + near-field diagnostics + local RSSI/PER readout → prioritize sleep current + secure key storage.
11.2 Reference BOM table (by functional block)
Where available, ordering-code examples are included (package/reel suffixes vary by vendor).
| Block | Primary MPN examples | Alternatives | Why it fits a repeater (selection notes) |
|---|---|---|---|
| Sub-GHz LoRa/FSK transceiver |
Semtech SX1262 (e.g., SX1262IMLTRT) :contentReference[oaicite:0]{index=0}
|
Semtech SX1276 :contentReference[oaicite:1]{index=1} | Use when a discrete radio + MCU architecture is preferred (buffer-first firmware, flexible clocks, external security element). SX1262 supports LoRa plus (G)FSK use cases. :contentReference[oaicite:2]{index=2} |
| Sub-1 GHz “radio MCU” (single-chip) | TI SimpleLink CC1312R :contentReference[oaicite:3]{index=3} |
TI CC1352R (Sub-1 + 2.4 GHz) :contentReference[oaicite:4]{index=4} Silicon Labs EFR32FG23 :contentReference[oaicite:5]{index=5} |
Best when the repeater must be compact and power-predictable (fewer chips, simpler RF routing). CC1352R is a common path for “Sub-1 + BLE/2.4” in one MCU. :contentReference[oaicite:6]{index=6} |
| BLE / multiprotocol SoC (2.4 GHz) |
Nordic nRF52840 (example order code: nRF52840-QIAA-R) :contentReference[oaicite:7]{index=7}
|
TI CC2642R / CC2652R family (when TI ecosystem preferred) :contentReference[oaicite:8]{index=8} | Use when BLE is heavy (commissioning, diagnostics, local tools). Ensure that BLE activity never starves Sub-GHz RX windows (schedule BLE in “quiet gaps”). |
| LPWAN/Sub-GHz FEM | Skyworks SKY66420-11 :contentReference[oaicite:9]{index=9} | Skyworks SKY66421-11 (860–930 MHz) :contentReference[oaicite:10]{index=10} | Use when link budget is dominated by RX margin and out-of-band energy (urban congestion / harsh industrial RF). FEM helps with PA/LNA integration and repeatable performance across builds. :contentReference[oaicite:11]{index=11} |
| Event buffer NVM | Fujitsu MB85RS64V (SPI FRAM) :contentReference[oaicite:12]{index=12} | SPI NOR: Winbond W25Q64JV (log/journal with wear leveling) | FRAM is ideal for “journal/commit pointer” writes on every event with minimal wear concerns; SPI NOR is cheaper but needs careful endurance strategy (batch commits, wear leveling, CRC). |
| Fuel gauge | ADI/Maxim MAX17048 :contentReference[oaicite:13]{index=13} | TI BQ27441 (alt ecosystem) |
Use when “battery-life proof” and field logs matter; log SOC, min_voltage, and TX_burst_sag around alarms.
|
| Charger + power path | TI BQ24074 :contentReference[oaicite:14]{index=14} | TI BQ25185/BQ25188 family (newer power-path variants) :contentReference[oaicite:15]{index=15} | Use when the repeater runs from a primary source but must seamlessly charge and run the system while keeping load stable during TX bursts (avoid “charge-loop induced dips”). |
| Power mux / seamless switchover | TI TPS2121 :contentReference[oaicite:16]{index=16} | ADI LTC4412 (ideal diode controller) :contentReference[oaicite:17]{index=17} | Use when two sources exist (main + backup) and the design must ride through fast transients with minimal hold-up capacitance; log switchover and brownout counters. |
| Voltage supervisor | TI TPS3839 :contentReference[oaicite:18]{index=18} | Microchip MCP1316 family (simple reset IC) |
Supervisor choice is a “truth source” for brownout evidence. Prefer a part with low IQ and clean reset behavior; always record last_reset_reason.
|
| Secure element (optional but recommended) |
Microchip ATECC608B (example: ATECC608B-TCSM) :contentReference[oaicite:19]{index=19}
|
NXP SE050 family (if NXP stack is used) | Use when the repeater must protect keys for replay resistance and provisioning (without exposing secrets in MCU flash). Keep the integration repeater-side: key storage + signing + monotonic counters. |
| LoRa “MCU + radio in one” (integration path) | ST STM32WLE5 family :contentReference[oaicite:20]{index=20} | Discrete SX1262 + MCU (higher flexibility) | Use when reducing BOM/PCB complexity matters, while retaining a LoRa-capable radio subsystem in one silicon family. |
Practical rule: if the field log must prove “no event loss under brownout,” prioritize supervisor + journaled NVM + switchover IC before chasing the last 1–2 dB of RF sensitivity.
11.3 Selection depth notes (what to check before locking a part)
A) Radio / SoC decision (single-chip vs discrete):
- Single-chip “radio MCU” (CC1312R / CC1352R / EFR32FG23): best for predictable sleep and fewer RF failure surfaces (fewer oscillators, fewer buses). :contentReference[oaicite:21]{index=21}
- Discrete transceiver + MCU (SX1262 + Cortex-M0/M4/M33): best when buffering/journaling is heavy and radio timing must be isolated from other stacks (BLE, diagnostics). SX1262 is explicitly positioned as LoRa + (G)FSK capable. :contentReference[oaicite:22]{index=22}
- Dual-band in one MCU (CC1352R): best when BLE/2.4 coexistence must be “built-in” and scheduling is managed by one stack. :contentReference[oaicite:23]{index=23}
B) FEM / filter decision:
- Use an integrated FEM (e.g., SKY66420-11 / SKY66421-11) when the site has strong nearby interferers and the failure mode is “RSSI looks OK but packets fail” (front-end compression / blocking). :contentReference[oaicite:24]{index=24}
- For “clean rural RF,” a simpler matching network may be enough—then prioritize brownout immunity and buffering.
C) Buffer NVM choice (FRAM vs NOR):
- FRAM (MB85RS64V): easiest path for per-event journal writes with low write-energy and high endurance characteristics; ideal for
commit_ptrandack_bitmap. :contentReference[oaicite:25]{index=25} - SPI NOR (W25Qxx class): workable but needs (1) wear leveling, (2) page-aligned journal design, (3) recovery scans on boot (CRC + last-good pointer).
D) Power path / backup: make TX bursts boring:
- Charger + power path (BQ24074) keeps the system rail stable while charging and supplying the load—useful when input sources are noisy or limited. :contentReference[oaicite:26]{index=26}
- Seamless switchover (TPS2121) or ideal-diode control (LTC4412) helps prevent resets during brief mains dips, connector bounce, or battery droop. :contentReference[oaicite:27]{index=27}
- Supervisor (TPS3839) defines the “brownout truth.” Always log:
brownout_count,min_voltage_logged,last_reset_reason. :contentReference[oaicite:28]{index=28}
E) Security (repeater-side only):
- For replay resistance and provisioning, a secure element such as ATECC608B is a common hardware root-of-trust option. :contentReference[oaicite:29]{index=29}
- Keep the scope local: key storage + message auth/sign + monotonic counters; avoid panel/cloud workflows.
Figure F11 — IC selection decision map (3:2 inline SVG)
Cite this figure (copy-ready block below the SVG).
Cite this figure
ICNavigator — Security & Surveillance — Wireless Alarm Repeater — Figure F11 “IC Selection Map” (accessed 2026-01-28).
The MPN examples shown inside the figure are based on publicly available vendor product pages and datasheets (Semtech SX1262/SX127x, TI CC13xx and TPS/BQ parts, Skyworks FEMs, ADI/Maxim fuel gauge, Microchip secure element, Fujitsu FRAM). Always validate the exact orderable suffix, frequency band, and temperature grade for your region.
Request a Quote
H2-12. FAQs ×12 (Accordion; evidence-based)
Each answer stays inside the repeater’s scope and points to measurable evidence (PER/RSSI/SNR, retries, queue depth, brownout/reset reason, buffer pointers, and timestamp behavior). No panel/cloud/app workflows.
Answer length ~40–70 words each. Format short answer → what to measure → first fix → chapter mapping.
1) RSSI looks fine but events still drop—blocking or congestion?
RSSI can look “good” while SNR collapses or the channel is simply busy. Measure (1) SNR distribution and PER vs RSSI, and (2) channel busy time / retry_count during failures. If SNR falls with stable RSSI, suspect blocking/adjacent interferers; if busy time spikes, suspect congestion/airtime saturation. First fix: improve filtering/placement or reduce airtime (rate/slots/backoff).
Maps to: → H2-4 / H2-9
2) Range is good at night but bad in daytime—what changed?
Treat this as a time-correlated interference/attenuation problem. Measure (1) PER, retry_count, and SNR histograms by hour, and (2) a quick spectrum snapshot/noise-floor indicator during “bad” periods. Daytime machinery, inverters, moving metal, or occupancy can raise noise or create new multipath nulls. First fix: relocate antenna away from noise sources, adjust channel/rate, and re-run a short site survey route.
Maps to: → H2-4 / H2-9
3) Latency spikes only during bursts—airtime or queueing?
Split latency into Tair (on-air time + retries) and Tqueue (buffer/forward delay). Measure (1) queue_depth_max and overflow counters, and (2) airtime utilization / retry_count during bursts. If queue grows while airtime is stable, it is scheduling/CPU/buffer; if airtime and retries spike, it is RF contention. First fix: add backoff, enlarge buffer headroom, and align listen/forward windows to traffic peaks.
Maps to: → H2-5 / H2-6
4) After a power outage, why do I see duplicate alarms?
Duplicates usually mean the repeater rebooted and replayed buffered events without a persistent ACK/sequence state. Measure (1) brownout_count + last_reset_reason around the outage, and (2) buffer recovery logs: last_committed_ptr, replay_window_hits, and seq/ack bitmap restore status. First fix: journal commit pointers atomically, persist a minimal ACK/seq window, and enforce a boot-epoch rule that suppresses already-acked events.
Maps to: → H2-6 / H2-7
5) Battery drains fast even when nothing happens—what to measure first?
Start with “idle truth” rather than event traffic. Measure (1) sleep current and wakeups per hour (RX window duty cycle), and (2) rail leakage / DC-DC light-load efficiency, plus any BLE advertising/scan cadence if enabled. If wakeups dominate, tighten schedules; if baseline current is high, fix power domains (always-on peripherals, pull-ups, regulators). First fix: reduce RX window duty, disable unused radios, and audit always-on loads.
Maps to: → H2-5 / H2-7
6) Repeater reboots only when transmitting—rail dip or watchdog?
TX bursts create the worst current step; this is often a brownout, not “random.” Measure (1) VBAT/VIN and Vcore droop during TX bursts, and (2) last_reset_reason plus min_voltage_logged (or supervisor flag). If voltage crosses UVLO, it is rail dip; if rails stay solid but resets persist, watchdog/firmware stalls are likely. First fix: improve power path/hold-up capacitance, limit TX power/burst length, and log watchdog status consistently.
Maps to: → H2-7 / H2-10
7) How big should the event buffer be for a site?
Size the buffer from measurable peaks, not average traffic. Estimate: buffer_events ≥ (peak_events_per_sec × worst_link_outage_sec) × (1 + retry_factor) + dedupe_window_events. Measure (1) peak events/sec and retry_count during stress tests, and (2) queue_depth_max and overflow rate in the field. First fix: raise ring-buffer slots and commit strategy (FRAM/journal for frequent writes), then validate recovery after forced resets.
Maps to: → H2-6 / H2-9
8) Do I need LoRa or is FSK enough?
Decide from link margin and latency budget. If the link budget shows negative margin with FSK at required install constraints, LoRa may be needed; if latency and event throughput are tight, FSK often wins. Measure (1) PER vs RSSI/SNR at candidate placements and (2) airtime/latency per event (Tair + retries). First fix: support dual-mode profiles and select per zone based on measured margin and burst behavior.
Maps to: → H2-3 / H2-5
9) Why does coverage change after moving the device 30 cm?
Small moves can cross deep multipath fades or detune the antenna near metal, cables, or ground references. Measure (1) SNR and PER at a small grid of positions/orientations, and (2) a simple “link stability” metric: retries per event and handshake success rate. If SNR swings sharply with position, multipath dominates; if performance follows proximity to metal, detuning dominates. First fix: increase clearance, change mounting height, and use a repeatable ground plane/antenna orientation.
Maps to: → H2-3 / H2-9
10) What’s the minimum logging I should keep for field forensics?
Keep the smallest set that can separate RF vs buffer vs power. Minimum fields: event_id, source_id, seq, local_timestamp, RSSI, SNR, retry_count, queue_depth_max, buffer_commit_ptr, brownout_count, last_reset_reason, and firmware_version. This enables duplicate/replay detection, outage correlation, and “why it dropped” classification without external tools. First fix: implement a ring log with periodic checkpoints and an export method (wired/near-field) that does not block RX windows.
Maps to: → H2-6 / H2-10
11) How to avoid replay/duplicate forwarding without heavy crypto?
Use lightweight state, not heavy handshakes. Store a sliding seq window per source, an ACK bitmap (or last_acked_seq), and a TTL for events; persist a boot_epoch counter so resets cannot reopen the replay window. Measure replay_window_hits and duplicate_drop_count to confirm behavior. First fix: reject duplicates before enqueueing, atomically commit the minimal state (seq/ACK/epoch), and bound retries so old events cannot reappear as “new.”
Maps to: → H2-6
12) Timestamps drift across devices—what’s “good enough” sync?
“Good enough” means event ordering and dedupe remain correct within an agreed error budget. Measure (1) timestamp monotonicity and drift rate (ppm) per device, and (2) hop_delay variability through the repeater under load. If drift breaks ordering, improve the timebase (better 32 kHz crystal or TCXO) or apply periodic correction from upstream, without requiring PTP. First fix: log drift, clamp outliers, and store both local_timestamp and corrected_timestamp for forensics.
Maps to: → H2-8
