Scope contract

A glass-break & shock sensor is an evidence-driven classifier at the sensor node: it converts two raw signals (acoustic + structural) into an explainable decision with enough context to support validation and field debugging.

• Acoustic evidence chain: a time-windowed acoustic event (impact-like onset + shatter-like content) expressed as band energies, event order, and duration.
• Structural evidence chain: vibration/shock signatures (peak/RMS, ring time, repetition) that depend on mounting coupling and enclosure mechanics.
• Decision philosophy: detect-and-reject, not “always alarm”—every alarm should be explainable, and every reject should have a reason code.

What must be “proven” (not merely detected)

A robust detector proves consistency between what was sensed and what was decided. The minimum proof is not the raw waveform; it is the combination of feature scores, threshold profile identity, and health state at decision time.

• Event type: glass / shock / both / unknown (or vendor-specific classes).
• Confidence: per-path scores and fused confidence (to separate “weak evidence” from “strong evidence”).
• Profile integrity: threshold/profile ID + version + CRC (to prevent “silent” behavior changes).
• Health integrity: last self-test state + fail code + timestamp, plus tamper status if present.

What this page intentionally does not cover

To avoid scope creep and content overlap with sibling pages, only the sensor-node evidence chain is discussed here. System integration is limited to generic “outputs” (alarm line, relay driver, or radio uplink) without platform or panel architecture.

• Not covered: alarm panel/VMS/NVR architecture, cloud dashboards, OS/app tutorials, PoE switching/PSE, timing-grandmaster design.
• Only referenced (one-liners): output interface types and how to log/encode the explainable fields.

Three architectures and how they fail

Selecting where “truth” comes from determines whether the product will be stable in the field. Single-path systems typically fail in predictable ways; dual-path systems fail in ways that can be explained and fixed.

• Mic-only: vulnerable to “glass-like” sounds (metal clicks, sharp impacts, certain audio content). False alarms rise when background noise changes.
• Accel-only: highly dependent on mounting coupling and enclosure mechanics. Same thresholds behave differently across installations.
• Mic + Accel: use one path as a discriminator for the other. Design focuses on fused confidence + explicit reject reasons.

Where fusion happens (and where it does not)

Fusion should happen at the node’s DSP/MCU decision layer so that the alarm is explainable without relying on a backend. This page covers DSP-level fusion only: per-path feature vectors produce per-path scores, then a fused decision is computed.

Fusion policy is typically one of: AND (conservative), OR (sensitive), or weighted vote (field-tunable). Weighted vote is usually preferred because it can be tuned using validation datasets without changing hardware.

Minimum decision inputs (feature vectors) for explainability

To stay robust and debuggable, the decision input set must be small, measurable, and logged. A minimal feature set should cover energy distribution, time order, and mechanical impulse characteristics.

• Acoustic: band energies (low/high), energy ratio, envelope duration, event-order score, ADC clip count.
• Structural: peak and RMS acceleration, ring time, trigger count, impulse repetition.
• Context: noise-floor estimate, mount/profile identifier, self-test freshness (time since last pass).

The same fields also enable fast triage: high clip count indicates front-end saturation; abnormal ring time indicates mounting coupling shift; frequent triggers indicate wake-threshold drift or mechanical vibration sources.

Event model: three windows that make the decision explainable

A practical edge model separates the acoustic stream into three windows so that the classifier can explain what happened and why it was accepted or rejected.

• Impact window: short onset search for an impulse-like trigger (often broad/low-weighted energy and sharp envelope rise).
• Shatter window: limited-time follow-on search for dense high-band micro-bursts and consistent “shatter-like” energy distribution.
• Decision window: aggregate evidence into score_mic, then emit score_fused and reject_reason.

Three verifiable indicators (minimum set)

Detection should rely on a small feature set that is stable across rooms and background noise. These three families provide a compact, measurable evidence chain.

• Energy ratio (E_high / E_low): reduces sensitivity to absolute gain and distance by comparing bands.
• Event order (impact → shatter): requires high-band density to occur after an onset within a valid time gap.
• Window density: burst_count, burst_spacing, and duration_ms reject sparse “clicks” and isolated noise.

How common confusers fail the evidence chain

False alarms often look “energetic” but fail one of the three constraints. Using explicit reject reasons prevents chasing random noise sources.

• Sharp metal click: may have high-band energy but typically low burst density (fails burst_count).
• Loud shout / bark: energy may be strong but order and shatter-window density do not match (fails order_score).
• Door slam: strong onset but high-band signature may be weak (fails E_ratio or shatter-window rules).

Signal-chain intent: produce features that stay stable across environments

The AFE should deliver a predictable digital stream where the same real-world event produces similar feature values. The core trade-off is noise floor vs headroom—too much gain raises false alarms; too little gain increases misses.

• Bias path: stable mic bias and bias health check reduce silent failures and drift.
• Low-noise preamp: sets the noise floor that drives noise_floor_est and affects threshold stability.
• Band-pass: aligns energy buckets (e.g., low vs high band) to the acoustic feature model.
• Limiter/AGC (optional): prevents overload while preserving time-order and burst density.

Why clipping breaks detection (even when “energy looks high”)

ADC clipping does not only distort amplitude; it can reshape the envelope and spectral distribution that the DSP uses. In practice, clipping can create two bad outcomes: false positives (distorted bursts look “dense”) and false negatives (order/duration becomes inconsistent).

• Mandatory evidence: log clip_count per window and treat it as a distortion flag in reject_reason.
• Headroom rule: ensure expected impact peaks do not sit near full-scale; keep margin so order and density remain valid.
• Fast triage: rising clip_count after installation changes usually indicates gain/bias changes or EMI coupling, not “new glass behavior”.

Where to measure (minimum 3 points) and what each proves

Debug should be anchored to measurable points that map directly to failure mechanisms. This avoids tuning thresholds blindly.

• Point A — AFE output (pre-ADC): verify noise floor, DC offset/bias health, overload behavior, and filter shaping.
• Point B — ADC/digital stats: verify clip_count, max-abs, and per-window saturation duration.
• Point C — background estimate: verify noise_floor_est stability (drift here destabilizes thresholds).

Mounting coupling is the hidden transfer function

The same real-world shock can look completely different after it passes through the enclosure, bracket, and fastening method. Treat mounting as a “transfer function” that changes peak, ringing duration, and band energy distribution.

• Placement: closer to glass/frame vs deep in the housing shifts the dominant resonance and peak shape.
• Fixation: screw / adhesive / foam changes damping; damping mainly controls ring_time_ms.
• Axis & range: axis alignment and full-scale range control saturation risk (acc_sat_flag).

Filtering that serves features (not “pretty waveforms”)

Filters exist to make shock evidence consistent under gravity drift and environmental vibration, so peak/RMS/ring-time remain comparable between units.

• High-pass (HP): removes gravity/slow drift so shocks become sharp and comparable in peak/RMS.
• Low-pass (LP): suppresses high-frequency noise that inflates RMS and causes false wakeups.
• Optional band buckets: if needed, compute a small set of band energies to separate “single hit” vs “resonant rattle”.

Interrupt + second-stage capture: the low-power pattern

A power-efficient shock detector uses a two-stage workflow: a tiny always-on threshold interrupt to wake the system, followed by a short capture window to classify the event with stable features.

1. Stage 1 (always-on): threshold interrupt with hysteresis and debounce to reduce chatter.
2. Stage 2 (short capture): sample for a bounded window, compute peak/RMS/ring-time and (optional) band energies.
3. Stage 3 (classify): output score_accel, then pass to fusion with mic evidence.

What to log so field behavior is diagnosable

Shock decisions must be explainable without streaming raw data. Log a compact record per event so installers can identify mounting changes, saturation, and vibration environments quickly.

• Core evidence: acc_peak_g, acc_rms_g, ring_time_ms
• Health flags: acc_sat_flag, selftest_state
• Counts: trigger_count, wake_count (per hour/day bins)
• Config identity: profile_id, profile_ver, profile_crc

Pipeline overview: raw → features → score → fusion → decision

The DSP pipeline should be built as stages with explicit health gates and outputs. Each stage must produce fields that can be logged so failures are diagnosable.

1. Windowing: impact/shatter windows (mic) and capture windows (accel).
2. Prechecks: noise floor estimation, clipping/saturation flags, self-test state.
3. Feature extraction: acoustic family + shock family features.
4. Per-path scoring: score_mic, score_accel with confidence modifiers.
5. Fusion policy: AND/OR/weighted vote → score_fused, confidence, event_type.
6. Explainability record: emit reject_reason + profile identity (profile_id/profile_ver/profile_crc).

Acoustic feature family (mic): minimal set that stays stable

Acoustic features should match the event model from H2-3 and remain robust under gain changes and background noise. Keep the set small and loggable.

• Band energies: E_low, E_high, E_ratio (ratio reduces absolute-level sensitivity).
• Envelope: duration_ms, burst_count, burst_spacing (density rejects isolated clicks).
• Spectral centroid (optional): centroid as a compact “brightness” indicator.
• Event order: order_score to enforce impact → shatter structure.

Shock feature family (accel): structure-coupled but explainable

Shock features must handle enclosure-dependent resonance. Favor metrics that explain what changed when installation changes.

• Magnitude: acc_peak_g and acc_rms_g separate impulses from continuous vibration.
• Ring-down: ring_time_ms is a mounting fingerprint (damping/looseness detection).
• Optional band energies: coarse energy buckets can separate “rattle” patterns from single hits.
• Counts: trigger_count/wake_count for power and nuisance-rate diagnosis.

Fusion policy: AND / OR / weighted vote with confidence

Fusion must be a policy that produces both a decision and a reason. Choose the policy by product risk (false alarm tolerance vs miss tolerance), and always emit a fused confidence.

• AND (conservative): lowest false alarms; requires both paths to agree (may increase misses).
• OR (sensitive): catches more events; requires stronger reject rules and nuisance control.
• Weighted vote (recommended): compute score_fused from score_mic and score_accel, then apply a confidence threshold.

Explainability contract: reject reasons + profile identity

A detector is maintainable only when every “no alarm” is explainable. Use a compact reject taxonomy and tie decisions to the configuration identity.

Always include profile_id, profile_ver, and profile_crc in the event record so field data can be compared across installs and firmware releases without ambiguity.

Multi-threshold state machine (trigger / confirm / release)

Use three thresholds to separate “wake up quickly” from “confirm reliably” and “return safely”:

• Trigger threshold: low-power wake gate (may allow more candidates).
• Confirm threshold: applied to score_mic, score_accel, or score_fused inside a short decision window.
• Release threshold: lower boundary to prevent chatter and repeated alarms during decay (hysteresis).

Hysteresis + cooldown: nuisance control without “turning sensitivity down”

Hysteresis and cooldown reduce nuisance events without destroying detection sensitivity. The goal is to stop repeated triggers from the same physical decay (ring-down, echo, enclosure rebound).

• Hysteresis: require the signal/score to fall below release before arming again.
• Cooldown: a short lockout timer after ALARM/REJECT to avoid rapid retriggers (cooldown_ms).
• Debounce: ignore micro-bursts that do not meet minimum duration/density gates.

Adaptation layers: noise floor, mode, and mount profile

Adaptation should be bounded and auditable. Use slow-tracking baselines and explicit modes rather than “auto-magic” thresholds that drift unpredictably.

• Noise floor tracking: estimate noise_floor_mic and vib_baseline_rms with rate limits and outlier rejection.
• Mode selection: e.g., day/night or armed/disarmed modes; log mode_id to make field data comparable.
• Mount profile binding: thresholds and weights depend on profile_id (mounting variant) to handle coupling changes.
• Freeze-on-event: hold baseline updates during candidate events to prevent baseline “learning the alarm.”

Environment immunity: reject rules must be explicit and explainable

Immunity is implemented as reject rules that invalidate unreliable evidence chains. Every reject should have a reason code.

• Too noisy: noise_floor_mic above limit → ENV_TOO_NOISY
• Audio clipped: clip_count high → CLIPPED_AUDIO (reduce mic confidence or hard reject)
• Order/density mismatch: missing impact→shatter structure or burst density → BAD_ORDER / NO_SHATTER_DENSITY
• Continuous vibration: elevated acc_rms_g baseline with long duration → CONTINUOUS_VIBRATION
• Low confidence: fused score below gate → LOW_CONFIDENCE (with sub-reasons preserved)

Reproducibility: versioning, CRC, and environment statistics

Threshold tuning must be traceable across firmware releases and installations. Record configuration identity and a compact environment summary so event logs remain comparable.

• Policy identity: policy_ver, policy_crc, threshold_set_id
• Profile identity: profile_id, profile_ver, profile_crc
• Noise/vibration stats: noise_floor_mic, noise_p95, vib_baseline_rms, wake_rate

Closed-loop self-test: stimulus → response → verdict

Self-test should validate the critical chain used by detection, not just “register access.” A minimal implementation runs: (1) inject a known stimulus, (2) measure response metrics, (3) compare against acceptance windows, (4) emit verdict + reason.

Microphone self-test: acoustic injection vs electrical injection

Two complementary approaches prove different parts of the chain:

• Acoustic injection (beeper/speaker tone): covers the physical acoustic path + microphone + AFE + DSP; more environment-sensitive.
• Electrical injection (test tone into AFE/ADC): stable and repeatable; proves the electronics path and DSP gating.

Use response metrics that match the detector’s features: band-energy ratio, SNR, and clipping flags.

Accelerometer self-test: built-in excitation + acceptance windows

Many accelerometers provide an internal self-test excitation. Validate that the measured response falls within per-axis windows and that noise/baseline metrics remain plausible.

• Response window: acc_st_resp must be inside acc_st_min…acc_st_max.
• Saturation awareness: reject self-test results when acc_sat_flag is set.
• Sanity checks: baseline RMS and axis consistency checks can detect stuck or severely degraded sensors.

Tamper and abnormal conditions: detect health anomalies, not “attack narratives”

Tamper-related changes often appear as measurable health anomalies:

• Mic occlusion / blockage: injected response drops, band-energy ratios shift, noise floor changes.
• Cover removed / loosened mounting: vibration baseline and ring-time signatures drift; wake rate spikes.
• Potting / strong damping: ring-down shortens and peak reduces; shock signatures become inconsistent with the selected profile.

Health record: make failures diagnosable and actionable

A health system is only useful when failures are explainable and comparable across firmware builds. Always include identity/version and a compact response summary.

• Verdict: selftest_pass + fail_reason
• Response summary: resp_level, resp_snr, resp_in_window
• Identity: health_ver, policy_ver, policy_crc, profile_id
• Policy reaction: degrade confidence or block alarms when health is failing, and emit HEALTH_BLOCKED in logs.

Energy budget template (reproducible)

Compute daily consumption from an always-on baseline plus event-driven energy. Keep the budget auditable by logging the effective thresholds/modes used during the measurement period.

Measure I_AO as the current in the “armed but idle” condition, then validate N_wake and E_event using counters and timing logs.

Always-on inventory: what stays awake when “sleeping”

Identify the always-on blocks and pin their contribution first—this is often the #1 determinant of battery life.

• Accel interrupt: threshold interrupt / wake-on-motion (typical always-on anchor).
• Mic bias / ULP gate: bias + simple envelope/energy gate, or duty-cycled listen windows.
• Retention + time base: RTC / retention RAM required for timestamps and health state.

Wake-on-event timeline: wake → capture → classify → report

Break event handling into states and measure both current and duration. The fastest wins often come from reducing N_wake (immunity rules) and shortening capture/classify windows.

• Wake: domain bring-up and clock settle (t_wake_ms).
• Capture: short audio/accel windows (t_capture_ms), freeze baseline updates during capture.
• Classify: feature extraction + scoring + fusion (t_classify_ms).
• Report/Log: store event record; optional uplink (t_report_ms).

Logging and reporting: the silent battery killer

Write logs in layers. Always keep a compact event record, and only capture heavy payloads (raw snippets) by sampling or in a diagnostic mode. Reporting spikes can dominate energy even when classification is efficient.

• Always: small event record (tens of bytes).
• Sampled: store a short snippet or feature vector every N events.
• Diagnostic: temporarily increase detail when FAR rises (record mode_id and policy_crc).

Field evidence: counters that explain battery drain

• Daily wakes: wake_count_day, trigger_count_day
• Processing load: event_count_day, avg_t_classify_ms
• Resets: brownout_count, reset_reason, uvlo_events
• Environment: noise_floor_mic, vib_baseline_rms (correlate with wake spikes)

SOP overview: what to prove and what to export

The output of validation is not “it seems OK.” Export a comparable package per build: TPR, FAR, latency distribution, and reject_reason histogram, all tied to the exact policy/profile identity.

Coverage matrix: structured, not combinatorial explosion

Cover primary variables fully, sample secondary variables, and keep control variables fixed per run.

• Primary (must cover): glass type, distance, angle, room acoustics, background noise, mounting profile_id.
• Secondary (sample): temperature, supply voltage level, unit-to-unit variation.
• Control (fixed): sampling rates, window lengths, policy thresholds and weights.

Metrics: definitions that can be computed

• TPR (detection rate): fraction of defined glass-break events that reach ALARM within the allowed latency.
• FAR (false alarm rate): false alarms per hour/day, reported per environment and per profile.
• Latency: event timestamp → alarm timestamp (distribution, not just average).
• Robustness: delta of TPR/FAR under noise, temperature drift, and mounting change.

Data capture: event record + snippet hash + optional raw fragments

Store enough evidence to replay decisions without always storing large payloads.

• Always: compact event record: event_ts, scores, verdict, reject_reason, identity fields.
• Always: input_snippet_hash (hash of raw snippet or feature vector).
• Sampled: store short raw audio/accel windows every N events or in diagnostic mode.

Test report template: make failures diagnosable

For each scenario, include: event counts, TPR/FAR, latency distribution, and the top few misclassified cases with their input_snippet_hash and reject reasons. This enables threshold tuning without guesswork.