Home Security Hub: AFEs, Multi-Protocol Radio, Backup Alarm Chain
← Back to: Smart Home & Appliances
Home Security Hub is the local “decision-and-alarm core” that collects zone sensors (PIR/contact/glass), verifies events with measurable evidence (test points + counters), records tamper-proof logs, and drives siren/strobe reliably—even under EMI, radio bursts, and power loss.
This page focuses on hub-side input AFEs, multi-protocol coexistence, backup power continuity, rugged EMC protection, diagnostics, and a field debug playbook that turns symptoms into repeatable measurements and first fixes.
H2-1. Definition & System Boundary
What a Home Security Hub is (engineering definition)
A Home Security Hub is a local decision and alarm endpoint that turns mixed sensor evidence into traceable events and reliable alarm outputs, while keeping communication alive during power faults.
- Inputs: PIR / contact / glass-break evidence, tamper loop, and received wireless sensor events.
- Outputs: local siren/strobe/relay actions and a verifiable event record (timestamp + sequence).
- Hard constraints: low false-alarm tolerance, power-loss survival, RF coexistence, hub-side EMC robustness.
The boundary is defined by measurable evidence points (TPs) and failure modes, not by app features or cloud workflows.
This page covers / does not cover (mechanically checkable)
Covers (in-scope)
- PIR/contact/glass-break AFEs (hub-side), input filtering and diagnostics hooks
- Tamper and fail-safe alarm logic tied to physical evidence
- Multi-protocol radio hardware coexistence (2.4G + optional Sub-GHz)
- Backup battery path, charger, power-path behavior under brownout
- Siren/strobe drive chain, protection, and self-test direction
- Event log/RTC, reset reasons, fault counters, field-debug evidence points
- Hub-side ESD/surge/EMC entry points (zone + alarm ports)
Does not cover (out-of-scope)
- Cloud backend architecture, subscriptions, or mobile app workflows
- Doorbell/intercom A/V pipeline (image/ISP/audio/video/PoE specifics)
- Matter gateway routing/bridge deep dive (protocol-stack details)
- Home UPS inverter/transfer topology and high-power backup design
- Battery sensor-node lifetime tricks (coin-cell optimizations)
Hub vs Gateway vs Doorbell vs UPS (only the differences that matter)
| Device | Primary role | Must-survive scenario | Key evidence points |
|---|---|---|---|
| Security Hub | Local sensing decisions + alarm outputs + event traceability | False-alarm stress, power loss, RF coexistence, tamper attempts | Zone AFE outputs, power-path nodes, TX-burst rail droop, alarm drive current, event log continuity |
| Gateway | Network bridging/routing for home devices | Link stability and throughput under network variations | Link metrics, routing state, network diagnostics (stack-level; not expanded here) |
| Doorbell | Real-time A/V capture and transport | A/V latency, low-light imaging, echo/noise and connectivity | ISP rails, sensor clocks, audio paths, PoE/power noise coupling (not expanded here) |
| UPS | High-power energy storage + inverter + transfer | Load transfer and runtime under high power | Inverter waveforms, transfer timing, thermal, battery pack safety (not expanded here) |
This page treats communication and UI as interfaces; the core is the local evidence-to-alarm reliability loop.
H2-2. Reference Architecture (evidence chain: inputs → alarm)
One architecture, three chains (so every chapter can “fall back” to evidence)
- Signal chain: zone inputs → AFE/filter → comparator/ADC → decision logic (false vs real event).
- Power chain: mains DC + battery path → rails → brownout handling (no reset during TX burst or alarm).
- Trust chain: RTC + event log + key storage → traceable records (tamper-attribution and continuity).
The reference view below places testpoints (TPs) on the shortest path to isolate faults: input integrity, RF coexistence, power stability, alarm delivery, and logging continuity.
Critical testpoints (TPs) that make field debugging deterministic
| TP | Measure | What it proves |
|---|---|---|
| TP1 | Zone AFE output (PIR/contact/glass) around threshold crossing | False trigger vs real event; drift/noise injection vs inadequate filtering/hysteresis |
| TP2 | Comparator threshold / hysteresis node (or ADC reference window) | Threshold instability, biasing issues, and debounce/decision margin problems |
| TP3 | Radio TX burst current & system rail droop (SYS/3V3) during transmit | Coexistence failures caused by power integrity and ground bounce (not “protocol” issues) |
| TP4 | Siren/strobe drive current and clamp node during switching | Alarm dropouts, overcurrent/thermal limiting, and surge/back-EMF problems |
| TP5 | Reset reason + monotonic event counter continuity across power events | Whether missing logs are caused by brownout, watchdog, or improper write/commit strategy |
H2-3. Zone Inputs & Sensor AFEs (hub-side stability)
Design target: trustworthy evidence (low false alarms, low misses)
Zone inputs must be converted into stable, repeatable evidence before any “alarm decision” is made. The hub-side front-end is responsible for rejecting noise injection, keeping thresholds deterministic, and exposing test hooks that make field debugging measurable.
- In-scope: hub-side AFEs, comparator/ADC decision margin, filtering, diagnostics injection, and zone integrity checks.
- Out-of-scope: battery sensor-node lifetime tricks and sensor-side wireless protocol behavior.
PIR input (bandwidth, bias stability, low-frequency drift)
What to measure
- TP1: PIR AFE output around “near-threshold” conditions (drift amplitude + noise bandwidth).
- TP2: threshold / reference node stability (whether threshold moves with rails or temperature).
- Correlation hint: check whether anomalies align with high-current activity (e.g., radio TX bursts) to detect coupling.
What it proves
- AFE drift present but threshold stable → likely environment/bias/bandwidth configuration, not “logic failure”.
- Threshold node moves or compresses decision margin → likely reference/bias network or power injection.
- Events only occur during high-current bursts → likely ground bounce / rail droop coupling into the AFE.
First fix
- Set AFE bandwidth so slow drift cannot look like an event (filter corner chosen from measured drift spectrum).
- Add deterministic hysteresis/windowing at the comparator/ADC decision stage (margin resistant to ripple).
- Keep AFE reference return and input protection loop compact; avoid sharing noisy return paths with high-current blocks.
- Provide a simple Test-In point to validate AFE gain/offset without relying on ambient motion.
PIR reliability improves when drift is treated as a measurable signal class (slow), separated from intrusion-like changes (fast), and guarded by a stable threshold path.
Contact input (reed / dry-contact / wired loop integrity)
What to measure
- TP1: input pin waveform during “no motion” and during transitions (bounce count and duration).
- TP2: pull-up/pull-down node level (how strongly the input is biased against injected noise).
- Loop integrity: detect open/short/tamper by observing controlled bias response (windowed thresholds).
What it proves
- Short, dense edge chatter → inadequate debounce partitioning (hardware vs firmware responsibility unclear).
- Mid-level “floating” behavior → weak biasing or injected common-mode from long wiring.
- Open/short indistinguishable from “normal” → integrity window too narrow or diagnostics stimulus missing.
First fix
- Split debounce: small RC for edge shaping + deterministic firmware debounce for event confirmation.
- Strengthen biasing so the input does not hover near the decision threshold during noise injection.
- Support loop integrity states (normal / open / short / tamper) by defining distinct threshold windows; EOL concepts may be used without expanding sensor-node design.
- Place input protection and return reference to avoid long, shared loops that convert ESD/EMI into false edges.
Wired loops fail in the field mostly due to bias and return-path issues, not because the contact “switch” is wrong.
Glass-break input (acoustic / piezo: band-pass + envelope + dual features)
What to measure
- TP1: band-pass output energy (target band) and envelope timing response.
- TP2: gain/limit behavior (whether impulses saturate and recover slowly).
- Feature counters: separate “impact” and “shatter-band” evidence windows (measured as two independent thresholds).
What it proves
- Impact-only energy without sustained shatter-band evidence → typical false alarms (door slam/metal hits).
- Shatter-band energy present but flattened → dynamic-range or limiter recovery issue.
- Energy rises with rail disturbance → AFE coupling (power/ground), not true acoustic evidence.
First fix
- Choose band-pass + envelope time constants to reject short impulses while keeping shatter signatures detectable.
- Use dual-feature gating (impact + shatter-band) so “one loud event” cannot satisfy the alarm condition alone.
- Control limiter/clip behavior so the AFE returns to normal quickly after large impulses.
- Add a simple Test-In path to validate frequency response and envelope behavior during production or service.
Glass-break reliability improves when evidence is defined as two measurable features rather than a single amplitude threshold.
H2-4. Tamper, Interlocks & Fail-Safe Alarm Logic
Fail-safe principle: local safety must not depend on UI or cloud
A security hub must remain “safe by default” under predictable failures: firmware hangs, radio loss, and mains power loss. Tamper signals are treated as high-priority evidence and must trigger local actions with traceable records.
Priority table (actions + minimum log fields)
| Event class | Local action (minimum) | Record fields (minimum) |
|---|---|---|
| Tamper | Immediate local alarm or “tamper mode” indication; keep alarm chain powered if possible | tamper_reason, zone_id, timestamp, seq_counter, power_state, reset_reason (if any) |
| Intrusion | Confirm evidence window then trigger alarm output chain | zone_id, evidence_level, timestamp, seq_counter, radio_state |
| Low-batt | Degrade non-critical loads first; preserve logging + alarm capability | battery_v, rail_status, load_state, timestamp, seq_counter |
| Comms loss | Local-only mode; do not suppress local safety actions | radio_link_state, retries, timestamp, seq_counter |
The priority system is effective only when actions and records remain valid during brownout and reboot sequences.
Compact decision tree (event → action → record)
- Tamper evidence → local alarm indication (and optional siren enable) → log(tamper_reason, time, seq, power_state).
- Intrusion evidence confirmed → alarm chain trigger → log(zone, evidence_level, time, seq).
- Brownout / power loss → switch to backup path → preserve log continuity → log(power_state, reset_reason, time, seq).
- Radio down → local-only safety mode → log(radio_state, retries, time, seq).
This structure prevents “silent failures”: if an alarm cannot be delivered, the reason must still be traceable.
H2-5. Multi-Protocol Radio Stack (hardware coexistence)
Why radios “fight” inside one enclosure
Most coexistence failures are not protocol mysteries. They are measurable coupling paths: (1) antenna/front-end isolation limits, (2) TX-burst rail ripple and ground bounce, and (3) control-line coupling (PA enable / RF switch control) into sensitive nodes.
- Architecture options: dual/multi-radio SoC vs host + external radios (separate RF islands).
- Isolation first: antenna spacing/keep-out, front-end filters/switches, and clean RF return paths.
- Coexistence evidence: correlate packet loss/RSSI jumps with TX burst current and rail ripple.
Symptoms → evidence → where to look
| Symptom | Evidence to capture | Most likely area |
|---|---|---|
| Packet loss spikes | TP-R1 rail ripple during TX bursts; retry counters rising | Radio rail decoupling, power routing, shared return |
| RSSI “jumps” | Receiver baseline noise floor vs time; proximity to other TX windows | Antenna spacing/keep-out, front-end switch/filter isolation |
| Frequent reconnect | TP-R2 control-line coupling into RX/AFE nodes; reset reasons | PA_EN / RF switch control routing, ground reference coupling |
| Only fails in certain installs | Baseline VSWR/antenna detune signs; enclosure ground contact changes | Mechanical grounding, enclosure/antenna detuning sensitivity |
Coexistence debugging becomes deterministic when link symptoms are time-aligned with TP-R1/TP-R2 evidence.
First fixes (hardware-side)
Antenna / front-end isolation
- Separate 2.4G and Sub-GHz RF islands with clear keep-out zones and controlled return paths.
- Use front-end filters/switches to avoid “shared paths” that let one transmitter desense the other receiver.
TX burst → rail ripple / ground bounce
- Increase local decoupling at the PA rail; minimize loop area from regulator to PA load.
- Keep RF rails away from sensitive AFE/reference routes; treat return paths as part of the RF design.
Control-line coupling (PA_EN / SW_CTRL)
- Route enables/controls away from high-impedance nodes; add edge-rate control where needed.
- Verify TP-R2: coupling signatures should not coincide with RSSI baseline shifts.
H2-6. Power Tree + Backup Battery Path (no-break alarm chain)
Reliability root cause: brownout behavior during 0–500 ms
The most expensive field failures look like “random reboots” or “alarm missed once”. The hub must preserve two things during power events: (1) event traceability (log continuity), and (2) local alarm capability. Everything else is staged off.
- In-scope: charger + storage concept, power-path OR-ing/ideal diode/load switch, staged load shedding, brownout early warning.
- Out-of-scope: inverter/transfer topologies used by home UPS systems.
0–500 ms outage timeline (minimum sequence)
Two waveforms to capture first: TP-P1 (main 5V) and TP-P2 (SYS/power-path output). If TP-P2 dips through reset threshold, “random reboot” is expected behavior.
First fixes (measurable)
Power-path switching stability
- Minimize OR-ing/ideal-diode loop impedance; keep SYS hold-up capacitance close to the power-path output.
- Verify TP-P2 during a forced drop: SYS should not show double-dip or oscillation.
Staged load shedding
- Define a deterministic order: disable radios/backlight first, keep alarm driver + logging rails alive.
- Log power_state transitions so “missed alarm” has a traceable root cause.
Charger + storage (concept only)
- Battery/supercap selection affects instantaneous droop and available hold-up time; validate with TP-P2 under load.
- Keep charging paths from injecting noise into SYS (separate sensitive rails from charge current loops).
H2-7. Alarm Output Chain (siren / strobe / relay)
Design goals: last-mile reliability with measurable self-test
The alarm chain is a high-current, high-dI/dt subsystem. It must remain functional under EMI and backup-limited power, and it must be diagnosable: open/short/overcurrent conditions should be observable and recordable.
- Robust drive: low-side / high-side / H-bridge choices depend on load type and wiring return constraints.
- Protection first: define a safe flyback/clamp path for inductive loads; avoid dumping energy into sensitive ground.
- Self-test evidence: detect open/short/overcurrent at the driver stage and log a fault code with timestamp + sequence.
Checklist (mechanically verifiable)
Protection parts
- Flyback path defined (diode/clamp) for inductive loads (siren/relay coil).
- TVS or clamp sized for surge energy; clamp return path is short and intentional.
- Overcurrent limit / fuse or eFuse policy is defined for the alarm rail (if used).
Return path & grounding
- High-current loop is localized; do not share return with AFE references or RF rails.
- Kelvin sense (if used) references the correct node (TP-A2 at the return/current path).
- Ground boundary between “quiet” and “noisy” zones is explicit on the PCB.
EMC control
- Edge-rate control (gate resistors / slew control) for switch nodes that radiate.
- Snubber strategy (where needed) targets ringing at TP-A1 without overheating the driver.
- PWM frequency placement avoids creating broad-band interference into RF/AFE bands.
Self-test & diagnostics (concept-level)
- Open-load detect (load absent) vs short detect (fault current) are distinguishable.
- Fault flags map to log fields (alarm_fault_code, timestamp, sequence, power_state).
- Backup-limited mode enforces current/duty constraints while preserving “detectable” alarm patterns.
Backup-limited alarm behavior (keep meaning, reduce power)
| Output | Power-friendly strategy | Evidence to record |
|---|---|---|
| Siren / Buzzer | Short bursts + spacing (duty control); reduce peak current when on backup | alarm_mode, duty_level, TP-A2 current evidence snapshot |
| Strobe / LED | Lower current + wider pulses; edge control to reduce EMI | strobe_mode, driver_fault, RF/AFE disturbance correlation tag |
| Relay / SSR (if present) | Minimize chatter; only switch when needed; ensure coil flyback is controlled | switch_event, coil_fault (open/short), timestamp + sequence |
Backup-limited output should preserve interpretability: reduced power must not look like “no alarm”.
H2-8. Secure Identity & Anti-Tamper (hardware trust chain)
Scope: hardware-rooted identity and evidence, no cloud/platform details
The goal is a hardware trust anchor for keys, counters, and evidence. The hub should be able to sign and sequence event records so tamper incidents remain traceable even across resets and power events.
- Placement: trust anchor within the board security boundary; clean reset/power domains and controlled bus routing.
- Minimal abilities: store, sign, count, and detect anomalies (high-level only).
- Evidence contract: event records carry immutable fields that prevent “it never happened” narratives.
Event record fields (engineering-ready)
| Field | Why it exists | Source (hub-side) |
|---|---|---|
| device_id | Stable identity bound to the trust anchor; enables provenance | SE/TPM-derived ID |
| timestamp | Time ordering for investigations and correlation | RTC domain |
| sequence | Monotonic continuity to detect deletion/rollback across resets | Trust anchor counter |
| event_type | Stable classification (tamper / intrusion / fault / comms loss) | MCU event engine |
| tamper_reason | Forensic granularity (case open / wall remove / line cut) | Tamper inputs |
| power_state | Disambiguates behavior under main vs backup vs low-voltage | PMIC/power-path state |
| reset_reason | Separates watchdog vs brownout vs software resets | MCU reset flags |
| alarm_action | Shows whether local alarm was asserted/degraded | Alarm chain state |
| signature | Authenticates record integrity (tamper-evident) | SE/TPM signing |
These fields intentionally support Ctrl+F verification and later mapping to validation and field debug playbooks.
Minimal trusted boot & evidence flow (three steps)
Step 1 — Validate boot state
- Establish a known-good boot state before enabling alarm and event pipelines.
Step 2 — Counter & anti-rollback check
- Confirm monotonic continuity to prevent “rewind” narratives after resets or power events.
Step 3 — Sign & commit event records
- Sign immutable fields and commit to storage; tie tamper inputs to sequence + timestamp.
Anomaly sensing (voltage/clock) is referenced at a high level only; implementation details are intentionally omitted.
H2-9. Rugged I/O Protection & EMC (hub-side)
What “rugged” means at the hub interface level
Robustness is proven at cable entries and high-current ports. The goal is to control where surge/ESD energy goes, keep common-mode return paths intentional, and prevent ground bounce from turning into false triggers or radio instability.
- Zone cable entry: TVS/ESD + RC limiting + controlled common-mode return path.
- High-current ports: surge/flyback energy must close locally and avoid “quiet” references.
- RF coupling loop: TX bursts can create rail ripple and bounce that shifts thresholds and causes mis-detection.
Cable entry evidence: zone inputs (PIR / contact / acoustic)
What to verify
- TP-E1 shows residual spike after TVS/ESD clamping (not just the connector pin).
- TP-E2 shows threshold stability (comparator/ADC node should not shift with disturbances).
- Common-mode behavior is assessed at the cable entry (return path is intentional, not accidental).
What it proves
- If TP-E1 is clean but TP-E2 shifts, coupling is likely via reference/return, not “lack of TVS”.
- If TP-E1 has large residual spikes, entry clamping/placement is insufficient or return path is long.
First fix (prioritized)
- Shorten and localize the clamp return loop; keep the surge loop away from AFE references.
- Add/adjust RC limiting near the entry to slow edges before comparator/ADC stages.
High-current ports: siren / relay return control (without repeating driver topology)
Evidence points
- TP-E3 at clamp/switch node: peak + ringing indicates where energy is released.
- TP-E4 at return node: ground bounce magnitude correlates with false triggers/resets.
What it proves
- Large TP-E4 bounce implies the high-current loop shares return with “quiet” domains.
- Large TP-E3 ringing implies the clamp/snubber loop is not localized or edge rate is too fast.
First fix (prioritized)
- Close the surge/flyback loop locally (clamp return is short, not crossing system ground).
- Control edge rate and add snubbing only after return/loop integrity is corrected.
RF ↔ power coupling: TX burst → ripple/bounce → false trigger
A reliable debug pattern is correlation: align radio TX bursts with AFE reference stability. If thresholds shift during TX activity, the root cause is usually rail impedance or return coupling rather than “protocol issues”.
- Measure: overlay TP-R1 (TX rail ripple) with TP-E5 (AFE reference/threshold) in time.
- Proves: synchronous drift indicates coupling via supply/return impedance, not sensor physics.
- First fix: local decoupling and return isolation around RF rails and AFE references before software coexistence tuning.
3 field symptoms → 1 evidence point → 1 first fix
| Field symptom | One evidence point | One first fix |
|---|---|---|
| False intrusion / random zone triggers | TP-E2 threshold shifts during disturbances | Fix return/clamp loop first, then add entry RC limiting near the connector |
| Frequent radio drop / reconnect storm | TP-R1 rail ripple aligns with reconnect events | Improve RF rail impedance + decoupling and isolate return from noisy loops |
| Alarm-on causes reboot / system freeze | TP-E4 ground bounce spikes when siren/relay toggles | Localize high-current loop and clamp return path; control edge rate afterward |
H2-10. Built-in Diagnostics & Event Telemetry
Make field failures observable (not guesswork)
Diagnostics should map directly to actionable isolation paths. Counters, reset reasons, and event records turn “random” failures into measurable signals that point back to power, radio coexistence, zone integrity, or alarm-chain disturbances.
- Always record: timestamp, sequence, power_state, reset_reason, and a compact event_type.
- Always count: brownout events, watchdog resets, join/rejoin attempts, zone open/short, alarm driver faults.
- Export path: local readout is required; remote uplink is optional and kept architecture-neutral.
Diagnostic field table (name → meaning → trigger → where it points)
| Field | Meaning | Trigger | Abnormal points to |
|---|---|---|---|
| reset_reason | Why the system restarted | boot event | WDT vs BOR vs SW reset → isolate power (H2-6) or EMI (H2-9) |
| brownout_count | Low-voltage/rail drop occurrences | voltage monitor trip | Power-path switching / rail impedance → measure main vs SYS (H2-6), check TP-E4 bounce (H2-9) |
| wdt_count | Watchdog resets over time | WDT timeout | EMI-induced lockup, noisy reset, or software stalls → correlate with alarm/radio activity |
| radio_reset_reason | Radio subsystem reset classification | radio reset event | TX burst droop / control coupling → verify TP-R1 ripple, control lines (H2-5) |
| rejoin_count | Network rejoin attempts | reconnect sequence | Desense or supply droop → correlate with TP-R1 and TP-E5 drift (H2-9) |
| zone_open_short_count | Cable integrity flags | open/short detect | Entry protection/return coupling → verify TP-E1/TP-E2 stability (H2-9) |
| tamper_count | Tamper incidents over time | tamper input trip | Tamper input integrity and event logging continuity (H2-8) |
| alarm_fault_code | Driver-level open/short/OC flags | alarm self-test or runtime fault | Alarm chain protection/return issues → verify TP-A1/TP-A2 and TP-E4 bounce (H2-7/H2-9) |
| event_seq | Monotonic continuity marker | every event record | Rollback/deletion suspicion if discontinuities appear (H2-8/H2-10) |
The “points to” column is intentionally actionable: it directs measurement back to earlier TP nodes and subsystem chapters.
Minimal power-on self-test sequence (field-friendly)
POST-1: time base & continuity
- RTC status check → record rtc_status and timestamp.
- Sequence continuity check → record event_seq and continuity flag.
POST-2: input sanity
- Zone baseline read → record a compact zone_sanity summary.
- Tamper input read → record tamper_state snapshot.
POST-3: radio & alarm quick checks
- Radio basic status (no architecture assumptions) → record radio_status + radio_reset_reason if any.
- Alarm chain lightweight check → record alarm_fault_code (avoid disruptive patterns).
POST-4: commit boot record
- Write a boot event into the ring buffer: boot_count, reset_reason, power_state, timestamp, event_seq.
H2-11. Validation & Field Debug Playbook (SOP)
How this SOP is used (fast isolation with minimal tools)
Each fault class follows the same 4-line structure: Symptom → First 2 measurements → Discriminator → First fix. The first two measurements are chosen to separate signal-chain vs power/return vs EMI/coupling quickly.
- Minimal toolset: 2-ch scope + DMM. Optional: current probe, differential probe, near-field probe.
- Always correlate: align waveforms with event_seq, timestamp, and the moment of TX burst / alarm toggle / power drop.
- Always snapshot counters: brownout_count, wdt_count, rejoin_count, zone_open_short_count, alarm_fault_code, reset_reason.
Evidence-first capture (the minimum diagnostic record)
| Record | timestamp + event_seq + power_state + reset_reason |
|---|---|
| Counters | brownout_count, wdt_count, rejoin_count, zone_open_short_count, alarm_fault_code |
| Waveforms | One “suspect node” + one “coupling source” (examples below per fault class) |
| Pass criteria | Fix is accepted only when the symptom cannot be reproduced and counters stop increasing abnormally |
This chapter stays hub-side: diagnostics map back to measurable rails, thresholds, returns, and driver nodes.
A) PIR false alarms (random triggers, HVAC airflow sensitivity)
| Symptom | Static scene still triggers; triggers increase with airflow/sunlight; false alarms cluster around radio TX or alarm activity. |
|---|---|
| First 2 measurements | (1) PIR AFE output / threshold node (TP-E2). (2) AFE reference stability vs TX burst (TP-E5) or rail ripple during events. |
| Discriminator | If TP-E2 drifts slowly without supply correlation → bias/bandwidth/windowing issue. If TP-E2 shifts in sync with TX burst or high-current toggles → return/supply coupling. |
| First fix | (1) Stabilize references/returns (quiet vs noisy boundary, local decoupling). (2) Add/adjust RC limiting before comparator/ADC. (3) Apply hysteresis and time-window debounce only after electrical stability is proven. |
Concrete MPN examples (hub-side)
TLV9062MCP6002OPA333Op-amps for AFE/filter stages
TLV3201TLV3702LMV331Comparators / threshold stages
PESD5V0S1ULESD9B5.0ST5GSMF5.0AESD/TVS at cable entry (select per interface)
TPS7A02MIC5504AP2112K-3.3Low-noise LDO examples for AFE/reference rails
B) Contact input chatter / open-short mis-detect (dry contact, long cable)
| Symptom | Door/window events “bounce”; false open/close; long cable increases errors; faults spike during storms or high-current actions. |
|---|---|
| First 2 measurements | (1) Raw input edge shape before debounce (TP-E2 at the GPIO/threshold). (2) Cable entry post-TVS node (TP-E1) or common-mode behavior at entry during disturbances. |
| Discriminator | Slow edges + bounce with stable TP-E1 → debounce/threshold margin. Clean edges but sporadic spikes aligned with disturbances → entry/return coupling and common-mode path issues. |
| First fix | (1) Localize clamp return and add RC edge limiting near entry. (2) Add hysteresis (Schmitt behavior via comparator or GPIO Schmitt input) after noise is controlled. (3) Implement open/short/tamper decision windows with counters. |
Concrete MPN examples (hub-side)
SN74LVC1G17SN74LVC2G17Schmitt-trigger buffers (clean up slow/noisy edges)
TLV3201MCP6561Comparator options when a discrete threshold stage is preferred
PESD5V0S1ULSMF05CESD arrays / TVS options at zone cable entry
BLM18AG601SN1BLM21PG221SN1Ferrite beads (return/cable noise damping, pick per impedance/EMI target)
C) Glass-break false alarms (acoustic triggers from doors, bangs, resonance)
| Symptom | False triggers from door slams, loud sounds, or room resonance; false alarms correlate with certain environments. |
|---|---|
| First 2 measurements | (1) Bandpass/envelope energy output (AFE output). (2) Impact-event counter / dual-feature gate state (impulse + shatter-band window). |
| Discriminator | High band energy without impulse gate → resonance/noise. High impulse counts without band energy → mechanical shocks. Both increase during TX or alarm toggles → electrical coupling into AFE/reference. |
| First fix | (1) Prove AFE reference stability first (TP-E5). (2) Harden bandpass/envelope with predictable biasing and time windows. (3) Add conservative dual-feature gating before lowering thresholds. |
Concrete MPN examples (hub-side)
MAX9814TLV9062OPA1678Mic/analog AFE building blocks (AGC mic amp / op-amp stages)
TLV3201LMV331Comparators for envelope/threshold stages
PESD5V0S1ULESD9B5.0ST5GESD protection for any external acoustic input wiring
D) Drop / reconnect storm (multi-protocol coexistence symptoms)
| Symptom | Rejoin spikes; RSSI jumps; radio resets; failures only during TX bursts or when siren/relay toggles. |
|---|---|
| First 2 measurements | (1) Logs: RSSI/SNR snapshot + rejoin_count + radio_reset_reason. (2) TX burst rail ripple at TP-R1 (and check TP-E5 threshold drift correlation). |
| Discriminator | Good RSSI but frequent reset reasons → supply/control coupling. Large RSSI variance aligned with high-current actions → EMI/return contamination near antenna/reference. |
| First fix | (1) Improve RF rail impedance (local decoupling, short return). (2) Isolate RF return from high-current loops. (3) Fix control-line coupling (PA_EN / switch controls) before software coexistence tuning. |
Concrete MPN examples (hub-side)
nRF52840EFR32MG24CC2652R72.4G multi-protocol SoC examples (BLE/Thread/Zigbee class)
CC1312RSX1262EFR32FG23Sub-GHz radio examples
2450FB15L0001SKY13385-679LF2.4G front-end filter / RF switch examples (use per RF design)
TPS7A02MIC5504LDO examples for quiet RF rails
E) Power-loss missed alarm / missed log (brownout continuity)
| Symptom | Power drop causes no event record; alarm does not fire on outage; reboot occurs with missing “why/when” evidence. |
|---|---|
| First 2 measurements | (1) Power-path switch node SYS (TP-P2) during outage. (2) reset_reason + brownout_count + power_state transition record. |
| Discriminator | TP-P2 crosses BOR threshold → energy/power-path issue. TP-P2 stable but records missing → commit/write ordering issue (check commit/sequence continuity). |
| First fix | (1) Fix power-path OR-ing/mux stability and staged load shedding (keep log + alarm first). (2) Prioritize log commit order: timestamp + seq + power_state + reset_reason. (3) Validate under worst-case battery/line sag. |
Concrete MPN examples (hub-side)
TPS2121TPS2113ALTC4412Power mux / ideal-diode controller examples
BQ24074MCP73831MAX17048Li-ion charger + fuel gauge examples
TPS25940TPS2595eFuse / inrush limiting examples for SYS robustness
F) Alarm silent / abnormal alarm (driver faults, flyback, bounce)
| Symptom | Alarm does not sound; stops midway; triggers unexpectedly; alarm-on causes reboot or radio drop. |
|---|---|
| First 2 measurements | (1) Load/driver current at TP-A2. (2) Clamp/switch node behavior (TP-A1 / TP-E3) and return bounce TP-E4 during toggles. |
| Discriminator | Current never rises → open/UVLO/limit/fault. Current rises but large clamp ringing + TP-E4 bounce → return/clamp loop issue causing resets or misbehavior. |
| First fix | (1) Localize flyback/clamp loop return (avoid crossing quiet references). (2) Add snubber/edge-rate control only after return is correct. (3) Use driver fault flags and current sense to verify “load present” in self-test. |
Concrete MPN examples (hub-side)
DRV8876DRV8871ULN2003ADriver building blocks (H-bridge / low-side array)
AO3400AIRLML6344Logic-level MOSFET examples for low-side/high-side stages
SMBJ58ASMF24ATVS examples for higher-energy ports (select per voltage/energy)
SS14SS34Schottky flyback diode examples (select per current/energy)
Post-fix validation (prove the failure cannot return)
- Reproduce test: run the original trigger (TX bursts, alarm toggles, power pulls, cable disturbance) and confirm symptom cannot be triggered.
- Counter stability: brownout_count / rejoin_count / alarm_fault_code stop increasing abnormally.
- Correlation broken: TP-R1 ripple and TP-E5 drift no longer align with events; TP-E4 bounce stays below threshold shift sensitivity.
- Record continuity: event_seq remains monotonic; each critical event produces a committed record with timestamp + reset_reason.
Request a Quote
H2-12. FAQs (12) — Evidence-Locked, No Scope Creep
Each answer is constrained to hub-side evidence: two measurements, a discriminator, and a first fix. UI and cloud are intentionally minimized; every FAQ links back to the chapter evidence chain.
Scope Guard (mechanically checkable)
This FAQ covers
- Hub-side test points (TP-E*/TP-R1/TP-P2/TP-A*/TP-D*) and counters (reset_reason, brownout_count, rejoin_count…)
- Zone AFE/threshold stability, cable-entry protection and return paths
- Multi-protocol radio symptoms explained via power/return/EMI evidence
- Power-path continuity, staged load shedding, alarm chain robustness
- Secure identity verification (anti-clone evidence) and event log integrity
This FAQ does NOT cover
- Cloud/backend architecture, dashboards, or mobile app workflows
- Protocol-stack deep dives (Thread/Zigbee/BLE internals)
- Sensor-node battery-life design or endpoint firmware tuning
- UPS inverter topology, mains PFC/LLC deep design, certification procedures
Sensors & Zone Inputs
1) “Night-only false alarms”: PIR drift or power ripple? What two points first?
Measure (1) the PIR threshold/AFE node at TP-E2 and (2) the reference/rail stability at TP-E5 during the same time window. If TP-E2 shows slow baseline drift without a correlated TP-E5 shift, treat it as bias/bandwidth drift. If TP-E2 shifts in sync with ripple or TX bursts, treat it as return/supply coupling. First fix: stabilize references and local returns, then tune hysteresis/windowing.
2) Door contact sporadic “chatter”: weak debounce or cable common-mode? How to tell?
Capture (1) the raw input edge at TP-E2 and (2) the cable-entry post-protection node at TP-E1 during the event. If the edge is slow/bouncy but TP-E1 is quiet, the issue is threshold margin/debounce. If TP-E1 shows spikes aligned with the chatter, the cause is common-mode injection and clamp/return behavior. First fix: localize the clamp return, add entry RC limiting, then apply Schmitt/hysteresis and debounce counters.
3) Glass-break false alarms increased: check bandpass threshold or structural shock coupling first?
Check (1) bandpass/envelope energy at the acoustic AFE output and (2) the dual-feature gate evidence (impulse window vs shatter-band window counters). High band energy with low impulse gating suggests resonance/noise; high impulse gating with low band energy suggests structural shocks. If both rise during radio TX or siren toggles, suspect electrical coupling into the AFE reference. First fix: prove TP-E5 stability, then tighten dual-feature windows before lowering thresholds.
Radio & Coexistence
4) Drops only when multiple protocols run: coexistence scheduling or antenna/ground-bounce coupling?
Start with (1) rejoin_count and radio_reset_reason snapshots and (2) TP-R1 TX-burst rail ripple captured at the same moment. If resets/rejoins align with TP-R1 droop, treat it as rail impedance/return coupling. If TP-R1 is clean but RSSI/SNR swings during siren/relay activity, treat it as EMI/antenna-reference contamination. First fix: improve RF rail decoupling and isolate high-current returns before adjusting coexistence timing.
9) RSSI looks strong but packets still drop: TX rail dip or multipath/antenna placement?
Measure (1) TP-R1 ripple during TX bursts and (2) retry/CRC/rejoin counters in the same interval. If error counters spike when TP-R1 dips, the root is supply/return coupling rather than “RF strength.” If counters rise with no TP-R1 correlation, suspect local EMI or antenna placement effects (kept at the evidence level). First fix: lower RF rail impedance, keep antenna reference quiet, and prevent siren/relay return currents from crossing RF/AFE grounds.
Power & Alarm Continuity
5) “Battery shows charge, but outage still reboots”: power-path or battery ESR first?
Capture (1) the system node TP-P2 across the AC removal edge and (2) reset_reason with brownout_count. If TP-P2 crosses BOR/UVLO, treat it as power-path stability and/or battery ESR under dynamic load. If TP-P2 stays above threshold yet evidence is missing, suspect commit ordering in event logging. First fix: stabilize power mux/ideal-diode behavior and staged load shedding (preserve log + alarm first), then re-validate worst-case battery ESR at alarm current.
6) Alarm sounds, then stops: power-budget limiting or driver OC/OT?
Measure (1) load current at TP-A2 and (2) the driver’s fault evidence (alarm_fault_code, plus clamp behavior at TP-A1 if available). If TP-A2 folds back and a fault code asserts, treat it as overcurrent/thermal protection or wiring/short issues. If TP-A2 is stable but stop events align with SYS sag, treat it as power-budget limiting and staged shedding errors. First fix: localize the flyback/clamp loop return, then set a bounded duty/current profile validated under backup power.
10) After adding TVS, false triggers get worse: added capacitance or bad return path?
Compare (1) the threshold node edge behavior at TP-E2 and (2) the post-clamp node at TP-E1 under the same disturbance. If TP-E2 edges become slow/rounded after TVS insertion, extra capacitance is reducing margin (fix with series-R/RC and Schmitt/hysteresis). If TP-E1 clamps but TP-E2 still shifts in sync with high-current activity, the clamp return path is injecting bounce. First fix: keep the clamp loop short and local, then choose low-cap TVS and re-tune RC limiting.
Tamper, Logs, Secure Identity, Factory Test
7) Tamper triggers are unstable: wiring approach or protection clamp side-effects?
Capture (1) the tamper input threshold at TP-E2 and (2) the entry node at TP-E1 during a controlled tamper toggle. If TP-E2 is slow or hovers near threshold while TP-E1 is quiet, treat it as wiring/threshold margin and debounce. If TP-E1 shows clamp charge/discharge that shifts TP-E2 timing, treat it as protection capacitance/return interaction. First fix: localize clamp return, add controlled RC limiting, then enforce hysteresis and a tamper decision window with counters.
8) After reboot, an event segment is missing: RTC/timestamp or ring buffer overwrite?
Check (1) event_seq monotonicity and (2) timestamp continuity across the reboot boundary. If timestamp jumps while event_seq remains monotonic, treat it as RTC/backup-domain instability. If event_seq shows a gap or wrap while timestamp is stable, treat it as ring buffer overwrite or commit ordering under brownout. First fix: commit the minimal record (timestamp + event_seq + reset_reason) before heavy writes, protect the monotonic counter (via secure element if used), and size/evict the ring buffer deterministically.
11) Suspected “cloned/replaced” hub: which three hardware trust evidences first?
Verify three hub-side evidences: (1) secure element/TPM device identity (unique ID or certificate fingerprint), (2) a monotonic counter / anti-rollback state, and (3) a signed event-log digest linked to timestamp and event_seq. A mismatch between identity and monotonic history suggests replacement or re-provisioning. First fix: lock debug ports, confirm secure boot flags, and re-provision keys only via controlled manufacturing/service flow (verification only; no attack methods).
12) “Minimal factory self-test”: how to avoid mass false alarms or missed alarms?
Use a six-step minimum test with recorded evidence: (1) RTC/timestamp OK, (2) event_seq monotonic, (3) zone inputs sanity at TP-E2 (open/short/tamper checks), (4) radio basic TX with bounded TP-R1 ripple, (5) power-path switchover at TP-P2 without BOR, and (6) a short alarm pulse proving TP-A2 current and no alarm_fault_code. First fix for any failure is mapped to the linked chapter (power/return/EMC/driver/log).
