123 Main Street, New York, NY 10001

Indoor Air Quality Hub: PM/VOC/CO2 AFEs, Edge MCU & Gateway

← Back to: Smart Home & Appliances

An Indoor Air Quality (IAQ) Hub owns sense → infer → bridge: it turns PM/VOC/CO2 readings into local AQI, events, and trends with confidence and logs, then reliably reports them through a low-power wireless gateway. It focuses on sensor AFEs, duty-cycled power, coexistence, and evidence-based validation—not purifier airflow control, HRV/ERV actuation, or cloud architecture.

H2-1. Boundary & Job-to-be-Done: What an IAQ Hub Really Owns

An Indoor Air Quality (IAQ) Hub exists to make air data stable, explainable, and actionable at the edge: it senses reliably, infers user-level signals (AQI, events, trends), and bridges results to local ecosystems with controlled power. It does not own actuator control (purifier/ventilation), nor system-wide energy orchestration (HEMS), nor cloud architecture.

Sense Infer Bridge

Ownership rule: every design choice on this page must map to one of these three jobs and must be supported by a measurable evidence hook (waveform, status flag, trend feature, or power profile).


What “Sense → Infer → Bridge” means in engineering terms

  • Sense (PM/VOC/CO₂ inputs): control sampling windows, warm-up behavior, drift handling, cross-sensitivity awareness, and analog/digital integrity so raw signals are repeatable.
  • Infer (edge analytics): convert raw streams into AQI, events, and trends with confidence signals; separate “slow baseline” from “fast events” so updates remain stable.
  • Bridge (gateway role): publish results through multi-protocol radios and/or a local bridge with predictable latency and bounded energy cost, without requiring protocol-stack deep dives.
Two fastest proofs (recommended defaults):
(1) Capture domain current pulses (Sensor vs RF vs Core) to separate “heater/NDIR warm-up” from “radio TX bursts”.
(2) Inspect sensor status/confidence + trend features (spike / slope / recovery time) to distinguish real events from noise coupling.

Deliverables (what this page must output)

  • AQI + confidence: stable index presentation, plus a simple confidence/quality indicator.
  • Trends: smoothed long-term baseline and rate-of-change indicators (not raw jitter).
  • Events: spike/episode detection (cooking, cleaning agents, occupancy patterns) based on features, not guesswork.
  • Alerts: threshold + hysteresis + debounce rules with clear triggers.
  • Energy analytics: average vs peak cost per day and the biggest contributors (sensor warm-up vs RF TX).
  • Filter analytics (inference): an effectiveness index inferred from recovery/time-constant behavior—no purifier fan model required.
  • Local evidence log: timestamps, sensor status/confidence, and event markers for field diagnosis.
Input sensors Outputs Not in scope
PM (PM2.5/PM10)
VOC/TVOC (electrochemical or MOS)
CO₂ (NDIR module)
Optional: RH/T for compensation (only as supporting context)
AQI + confidence
Trends (baseline + slope)
Events (episodes + recovery)
Alerts (threshold + hysteresis)
Energy stats (mAh/day + peaks)
Filter effectiveness index (inference)
Local logs (timestamps + flags)
Purifier motor/fan control
ERV/HRV defrost & dual-fan control
Thermostat/HVAC relay control
HEMS branch switching
Cloud backend architecture
Protocol-stack deep dive
Figure F0 — IAQ Hub boundary: Sense, Infer, Bridge and what is out of scope Block diagram showing IAQ Hub ownership centered on Sense, Infer, Bridge, with deliverables and out-of-scope items. IAQ Hub (This Page Owns) Sense PM / VOC / CO2 Warm-up • Drift Infer AQI • Events Trends • Confidence Bridge Thread / Zigbee BLE / Wi-Fi Deliverables AQI + Confidence Trends Events + Alerts Energy Stats Filter Index Not in scope (do not expand here) Air Purifier Control ERV/HRV Controller HEMS Switching Cloud / Protocol Deep Dive ICNavigator
Cite this figure Figure ID: F0 · IAQ Hub Boundary · ICNavigator
Figure F0. Boundary map: the IAQ Hub owns Sense → Infer → Bridge and must not expand into purifier control, HRV/ERV control, HEMS switching, or cloud/protocol deep dives.

H2-2. System Block Diagram: Signal Chain + Power Chain + Radio Paths (Figure F1)

Figure F1 is the system map for this topic. Every later section should point back to a block in the diagram: the signal chain explains “what is being measured and inferred,” the radio path explains “how results move,” and the power chain explains “what costs energy and when.”

Three chains to read in Figure F1

  • Signal chain: PM/VOC/CO₂ → AFE/ADC or module interface → edge MCU → features → AQI / events / trends.
    Deep focus: drift, warm-up, humidity cross-effects, and confidence tagging.
  • Radio path: MCU ↔ radios (Thread/Zigbee/BLE/Wi-Fi) ↔ bridge outputs (local app / home hub).
    Deep focus: bounded latency + bounded energy (TX bursts vs reporting policy).
  • Power chain: input (mains adapter or battery) → PMIC → Sensor / RF / Core domains.
    Deep focus: duty cycling and evidence-first current profiling (peak vs sleep).

Usage rule: when a symptom appears (spikes, drift, short battery life, missing reports), first select a chain (Signal / Radio / Power), then capture two proofs: (1) a domain current pulse (Sensor/RF/Core), and (2) a sensor status or feature curve (spike/slope/recovery).

Domain Typical peak source First measurements (minimal tools)
Sensor
PM / VOC / CO₂
CO₂ warm-up pulses, MOS heater, PM module bursts 1) Domain current pulse shape (peak + duration)
2) Sensor status/confidence + raw/filtered deltas during the pulse
RF
Thread/Zigbee/BLE/Wi-Fi
TX burst current, scanning/keep-alive 1) TX burst cadence (time between bursts)
2) Report queue/log counters (drops, retries, backlog)
Core
MCU + storage
Wake-ups, local logging writes, feature computation 1) Wake-up count per hour/day (RTC schedule vs events)
2) Local log write rate and “event flag” density
Figure F1 — IAQ Hub: sensors, edge MCU, radios, and power domains Block diagram showing PM/VOC/CO2 sensing into AFE/ADC and an edge MCU, with multi-protocol radios and power-domain duty-cycle indicators. Indoor Air Quality Hub — System Map Sensors PM (PM2.5/PM10) drift warm-up RH VOC / TVOC drift warm-up RH CO2 (NDIR) drift warm-up RH Edge Processing Sensor AFE / ADC TIA • Bias • Sampling Window Edge MCU RTC Local Log Feature Engine (AQI / Events) Gateway / Bridge Radios Thread Zigbee BLE Wi-Fi Bridge Outputs Local App Home Hub / Gateway Power Domains (Duty Cycle) Sensor RF Core peak / sleep ICNavigator
Cite this figure Figure ID: F1 · IAQ Hub System Map · ICNavigator
Figure F1. System map: PM/VOC/CO₂ inputs feed the AFE/ADC and edge MCU for features/AQI/events, then publish through multi-protocol radios via a bridge. Bottom bar highlights Sensor/RF/Core duty-cycle cost.

H2-3. PM Sensing Path: Module vs Raw Optics, and What the “AFE” Means Here

In an IAQ Hub, PM sensing is usually delivered by a self-contained module. Even then, “AFE” still exists at the hub level: power cleanliness, interface robustness, and evidence-first spike discrimination determine whether PM data is trustworthy.

PM module (UART/I²C) Raw optics (rare) Hub-level AFE

Two implementation paths (engineering boundary)

  • PM module (UART/I²C / pulse output): the optical engine and analog front-end are inside the module. The hub must still ensure clean power, protected interfaces, and data integrity (frame checks, drop counters, resync).
  • Raw optics (rare in hubs): a photodiode + TIA + ADC chain exists, but optical mechanics and airflow design stay out of scope here.

Hub-level “AFE” definition for PM: (1) power ripple and ground reference control for the PM module, (2) UART/I²C robustness (ESD, level margins, frame validation), (3) sampling/denoise policy (deglitching and outlier tagging), (4) anomaly handling (drop-frame counters and safe fallback states).


Evidence chain: classify PM spikes before changing filters or thresholds

Symptom signature More likely “real dust event” More likely “power/fan/interface coupling” More likely “threshold/filter artifact”
Spike / step
unexpected peak or jump
Correlates with activity (cooking/cleaning/door opening).
Recovery time constant looks physical (not instantaneous).
Aligns with current pulses (warm-up, TX bursts, fan commutation).
Frame errors or resync events appear around the peak.
Trigger point appears at stable levels (repeatable “cliff”).
Changing window/threshold shifts the event timing sharply.
Two fastest proofs
minimal tools
PM curve + a simple activity marker (time-of-day, door open).
Optional: CO₂/VOC trend co-moves as an occupancy clue.
PM module supply ripple / transient + domain current pulse shape.
Frame error / drop counter increases during the event window.
Compare raw vs filtered stream deltas (pre/post filter).
Threshold-hit counters explain “why a step appears.”
Minimal measurement checklist (recommended defaults):
(1) PM module supply ripple/transient during events; (2) frame error rate / drop-frame counter; (3) alignment against RF TX bursts if spikes repeat on uploads.
Figure F2-A — PM module integration: power isolation, interface protection, and evidence hooks Block diagram showing a PM module connected to an IAQ hub through power filtering, load switch, ESD protection, UART/I2C guard, and edge MCU spike handling with counters. PM Path (Module Integration) — Hub-level AFE PM Module Optics + AFE internal engine Digital Output UART / I2C / Pulse Hub Integration Power Filter Load Switch ESD / TVS UART / I2C Guard frame check • resync Edge MCU Spike Reject Smoothing Drop Counter Evidence Log ripple + errors Two Evidence Hooks Supply Ripple / Current Pulse Frame Errors / Drop-Frame Count ICNavigator
Cite this figure Figure ID: F2-A · PM Module Integration · ICNavigator
Figure F2-A. PM modules may include optics and internal AFE, but hub-level AFE still matters: power filtering, load switching, ESD/interface guards, and evidence logs make spikes explainable before thresholds are changed.

H2-4. VOC/TVOC AFE: Electrochemical vs MOS, Bias/Heater/ADC, and Baseline Strategy

TVOC is only useful when it is explainable. VOC sensing must be engineered as an AFE + baseline system: the analog chain must remain stable, and the edge baseline must separate slow drift from fast events to avoid “over-correction.”

Electrochemical MOS (heater) Baseline (slow + fast)

Sensor route comparison (engineering boundary only)

  • Electrochemical: requires bias + TIA + ADC; sensitive to humidity/temperature and aging drift; leakage and offset directly distort micro-current readings.
  • MOS: requires heater drive and a controlled sampling window; cross-sensitive to alcohol/cleaning agents; stability depends on heater current regulation and warm-up policy.

AFE blocks that decide credibility: low-drift TIA/amp, ADC low-frequency noise, bias DAC stability, input protection leakage, and (for MOS) heater current stability + sampling window alignment.


Baseline strategy: “slow baseline” + “fast events” (prevents over-correction)

  • Slow baseline track: updates conservatively under stable conditions to absorb drift and seasonal shifts. Baseline update must be rate-limited so one anomaly cannot pull the baseline away.
  • Fast event track: captures short episodes (cooking/cleaners) and reports them without rewriting the long-term baseline. When cross-sensitivity is suspected, event reporting can continue while baseline updates are frozen.
  • Confidence gating: baseline updates should require “sensor status OK” and avoid periods of strong humidity swings or heater instability.

Evidence chain: what to inspect first when TVOC spikes

Suspected cause Observable First-order mitigation (edge-side)
Heater instability (MOS) Heater current deviates or shows ripple; spike aligns with warm-up windows Stabilize heater current; enforce warm-up time; mark low confidence during transient windows
Humidity cross-effect RH/T changes co-move with TVOC; event appears during humidity steps Gate baseline update during RH transients; delay event decision until RH settles
Power/ground coupling ADC codes jump with RF TX or load switching; ripple increases during reporting Separate sampling from TX windows; improve filtering; tag affected samples as outliers
Sensor aging / drift Slow baseline climbs over days/weeks; sensitivity changes; status flags degrade Rate-limit baseline; store long-term drift metrics; require stable conditions for baseline updates
Cross-sensitivity (alcohol/cleaners) Sharp spike + quick recovery; pattern repeats with cleaning events Label as event; prevent baseline adaptation; report with lower confidence until pattern clears
Two fastest proofs (recommended defaults):
(1) MOS heater current (or electrochemical TIA output stability) during the spike window;
(2) RH/T co-trend + supply ripple alignment (especially around radio uploads).
Figure F2-B — VOC/TVOC: electrochemical vs MOS routes, plus slow baseline and fast event tracks Diagram showing electrochemical sensor path with bias and TIA into ADC and MCU, MOS path with heater and sampling window, and a dual-track baseline strategy with confidence gating. VOC / TVOC — AFE Routes + Baseline Strategy Electrochemical Route Sensor Cell Bias DAC TIA / Amp ADC Edge MCU Confidence TVOC MOS Route MOS Sensor Heater Drive Sample Win ADC Edge MCU Confidence TVOC Baseline Strategy (Dual Track) Slow Baseline rate-limited • gated Fast Events spike • duration • recovery ICNavigator
Cite this figure Figure ID: F2-B · VOC Routes & Baseline · ICNavigator
Figure F2-B. VOC/TVOC engineering map: electrochemical sensing relies on bias + TIA + ADC stability; MOS sensing relies on heater drive + sampling windows. Dual-track baseline (slow + fast) prevents over-correction and keeps events explainable.

H2-5. CO2 Path: NDIR Module Integration, Sampling Window, and Self-Check

CO2 in an IAQ Hub is typically measured by an NDIR module. Credibility depends on three items that can be verified: (1) power pulse behavior during warm-up and measurement, (2) sampling window alignment, and (3) self-check signals that gate confidence.

NDIR (UART/I²C) Warm-up + Measure Confidence gating

NDIR integration: interface + power pulse signature

  • Interfaces: NDIR modules commonly expose I²C or UART. At the hub level, robustness comes from ESD protection, clean reference ground, and explicit handling of stale frames and resync events.
  • Power pulses: many NDIR modules show a recognizable current pattern: warm-up (lamp/IR source stabilization) followed by a measurement pulse. If supply impedance is too high, CO2 readings can appear “noisy” or drift-like during these windows.

Sampling window rule: CO2 samples should be taken only after warm-up completion and during a stable measurement window. If uploads (radio TX) coincide with measurement pulses, schedule sampling away from TX bursts or mark samples as low confidence.


Sampling strategies: fixed interval vs event-triggered

Strategy What it optimizes Trade-offs Evidence to log
Fixed interval Stable trends and baseline tracking Predictable but higher average energy Warm-up time, measure pulse timing, confidence flag
Event-triggered Lower average energy, faster response to occupancy events Non-uniform sampling; trend smoothing must handle missing points Trigger source, sample timestamp, confidence + status

Self-check: observable indicators that prevent silent drift

  • Status / confidence: many modules expose status bits or a confidence level that can gate trend updates.
  • Optics aging or cavity contamination: often shows up as longer warm-up, reduced stability, slower response, or persistent confidence degradation—signals that should reduce weighting in analytics.

Evidence chain: CO2 biased high/low—calibration vs ventilation vs aging

Observed pattern More consistent with calibration bias More consistent with real ventilation change More consistent with sensor aging/contamination
Long-term offset All-day level shifted; weak correlation to occupancy/door events Level follows daily routine; rise/recovery shape stays realistic Offset grows slowly; response becomes sluggish; confidence drops
Two fastest proofs Compare baseline vs known fresh-air periods; check confidence remains high Check correlation to event markers and recovery time constant Inspect warm-up/pulse timing drift + status/confidence degradation
Minimal measurement defaults:
(1) NDIR current pulse capture (warm-up + measure); (2) module status/confidence; (3) alignment against radio TX bursts during uploads.
Figure F3 — NDIR CO2 timeline: sleep, warm-up, measurement pulse, and sampling window Timeline diagram showing NDIR sleep, warm-up, measurement pulse, a stable sampling window, and optional radio TX burst, with confidence gating. CO2 (NDIR) — Sampling Window + Power Pulses Timeline Sleep Warm-up Measure Sample Win Current Warm-up Pulse TX Burst Confidence Gating Use samples only when warm-up done • status OK Down-weight or freeze when confidence low • pulses couple ICNavigator
Cite this figure Figure ID: F3 · CO2 NDIR Timeline · ICNavigator
Figure F3. NDIR modules commonly require warm-up and show measurement current pulses. Sampling should align to a stable window and use status/confidence to prevent silent drift from polluting trends.

H2-6. Edge Analytics: AQI, Events, Trends, and “Filter Analytics” Without Crossing Into Purifier Design

Edge analytics must be explainable. Outputs are best structured into three layers—raw signals, features, and user-level results—so events and trends remain stable even when sensors warm up, drift, or temporarily lose confidence.

Raw Features AQI / Events / Trends

Three-layer output model (keeps analytics explainable)

  • Raw: PM / VOC / CO2 / (optional RH/T). Raw values are always paired with status and confidence.
  • Features: moving averages, slopes, spike metrics, duration, recovery time, and outlier tags. Features allow events to be detected while trends remain stable.
  • User-level: AQI, events, trends, and alerts. User-level outputs must remain consistent when confidence drops (down-weighting and freezing rules).

Filter analytics boundary: this page treats “filter analytics” as an inference index derived from air-quality improvement rate, recovery time, and long-term baseline. It does not require airflow or motor-drive details and does not control any purifier mechanics.


Events: define trigger features and minimum sensor sets

Event type (label) Trigger features (edge-side) Minimum sensor set
Cooking-like PM fast rise + duration; recovery time; optional VOC co-rise PM (+ optional VOC)
Cleaner / alcohol-like VOC sharp spike; quick recovery; confidence gating against RH swings VOC + RH/T
Occupancy build-up CO2 slope + sustained duration; slow recovery after event ends CO2
Ventilation change (window) CO2 slope reversal + recovery acceleration; PM/VOC may drop CO2 (+ optional PM/VOC)

Trends: keep stable under non-uniform sampling and confidence drops

  • Confidence gating: if a sensor reports low confidence or self-check degradation, trend updates should be down-weighted or frozen for that channel.
  • Windowing: avoid sampling during known disturbance windows (NDIR pulses, radio TX bursts) or tag those points as outliers.
  • Missing points: event-triggered sampling must be handled by time-aware smoothing (avoid “false stability” from sparse updates).

Filter effectiveness index (inference): what it can and cannot claim

  • Inputs: improvement rate after events, recovery time, and long-term baseline drift.
  • Output: an effectiveness index suitable for comparison over time on the same deployment.
  • Non-goals: not a mechanical airflow model, not an absolute filter life estimate, and not a control loop for purification hardware.
Why the same event differs across rooms (evidence-first):
placement (distance to source), local flow path, and sensor-to-sensor consistency/confidence. Compare response time and confidence flags before changing event thresholds.
Figure F4 — Edge analytics pipeline: raw inputs to features to AQI, events, trends, and filter effectiveness index Block diagram showing raw sensor inputs (PM, VOC, CO2, RH/T) feeding feature extraction and confidence gating, then producing AQI, event labels, trend outputs, and an inferred filter effectiveness index. Edge Analytics — Raw → Features → Outputs Raw Inputs PM VOC / TVOC CO2 RH / T Status + Conf Feature Engine Outlier Tag Moving Avg Slope / Rate Duration Confidence Gate Outputs AQI Events Trends Filter Eff Index Edge Rules Confidence Gate Outlier Tag Windowing ICNavigator
Cite this figure Figure ID: F4 · Edge Analytics Pipeline · ICNavigator
Figure F4. A three-layer analytics pipeline keeps outputs explainable: raw signals feed feature extraction and confidence gates, then produce AQI, event labels, trends, and an inferred filter effectiveness index based on improvement and recovery behavior.

H2-7. Power & Energy Analytics: Duty-Cycling the Sensor Stack and Keeping Radios Honest

Low-power design becomes repeatable when energy is accounted by domain (Sensor / RF / Core), then verified with two traces: domain current pulses and radio TX duty. The goal is predictable mAh/day under stable data quality.

Sensor / RF / Core Batch + Buffer mAh/day budget

Domain split: ownership of energy and noise coupling

  • Sensor domain: PM, VOC bias/heater, CO2 NDIR warm-up and measurement pulses.
  • RF domain: scan, advertising, association, uplink bursts, retries, and backoff behavior.
  • Core domain: MCU wake, feature extraction, local buffering, and non-volatile writes.

Keep radios honest: treat TX as a budgeted resource. Compress telemetry into scheduled report windows, throttle background advertising, and enforce retry backoff so poor links do not convert directly into battery drain.


Low-power method: tiered wake + batch sampling + local buffer + report window

Mechanism What it changes What to measure Expected waveform signature
Tiered wake Expensive sensors run only when needed Wake count, warm-up completion, confidence flags Fewer large sensor pulses; fewer fragmented wake spikes
Batch sampling Short dense sample blocks, long sleep Batch duration, batch interval, peak current Pulse clusters separated by long flat sleep
Local buffer Store features/events locally, not raw streams Buffer fill level, write frequency Less frequent core write bursts
Report window RF bursts occur in scheduled windows TX duty, retry count, backoff events TX appears as a few concentrated bursts per day

Energy budgeting: peak current + average mAh/day

  • Peak current validates supply integrity during warm-up and TX bursts and prevents false sensor artifacts from droop coupling.
  • Average energy is expressed as mAh/day by summing (current × time) across recurring events: warm-up, sampling, compute, and reporting.
Two fastest proofs for fast battery drain:
(1) Domain current pulse trace (sensor pulses vs core wake bursts).
(2) Radio TX duty trace (burst count, duration, and retries/backoff).
Figure F5 — 24-hour duty cycle: sleep, sensing batches, compute, and scheduled reporting A 24-hour timeline with three lanes (Sensor domain, Core domain, RF domain) showing sleep periods, sampling batches, compute/log bursts, and report windows with peak vs average indicators. Power — 24h Duty Cycle (Sensor / Core / RF) 24h 0 6h 12h 18h 24h Sensor Batch Batch Batch Core Log Log Log RF TX Win TX Peak vs Avg Sensor RF Core ICNavigator
Cite this figure Figure ID: F5 · 24h Duty Cycle · ICNavigator
Figure F5. A practical duty-cycle layout: sensor work happens in short batches, core work is brief, and RF transmissions are compressed into report windows. Peak and average currents are tracked per domain to keep energy predictable.

H2-8. Wireless Gateway Role: Multi-Protocol Bridge Without Protocol-Stack Deep Dive

The IAQ Hub can operate as a pure node, a bridge, or a bridge with local rules. This section focuses on product-level role choices and measurable trade-offs (power, complexity, latency) without diving into protocol internals.

Node / Bridge / Rules Multi-radio OTA-ready

Three roles in a deployment (product-level)

  • Node: senses and reports; bridge and orchestration are handled elsewhere.
  • Bridge: routes summarized results (AQI/events/trends) across multiple radios at the product layer.
  • Bridge + Local rules: adds local thresholding and event actions while remaining explainable and energy-aware.

Coexistence engineering (high-level, measurable)

  • Goal: minimize simultaneous bursts across radios and avoid retry storms.
  • Measures: TX duty, retry count, packet loss indicators, and end-to-end update latency.
  • Behaviors: scheduled report windows, background advertising throttles, and enforced backoff on poor links.

OTA and security (capability list): secure storage, image integrity check, rollback protection, and secure-boot capability. These are hardware and platform requirements only; policy and backend design are outside this page boundary.

Bridge mode trade-offs

Mode Strength Cost What to verify
Node Lowest complexity; lowest RF activity Requires an external hub for aggregation Reporting interval, confidence metadata, latency
Bridge Better local interoperability; fewer integration steps Higher RF activity and scheduling complexity TX duty per radio, retries/backoff, report-window alignment
Bridge + Rules Fast local reactions; offline-friendly More compute and testing; careful explainability needed Rule-trigger traceability, energy impact, update safety (rollback)
Figure F6 — Deployment roles: Node, Bridge, and Bridge with local rules Block diagram showing an IAQ hub producing raw/feature/user outputs and operating in three roles (node, bridge, bridge+rules) across multiple radios, with trade-off tags for power, complexity, and latency. Wireless Role — Node vs Bridge vs Bridge + Rules Radios BLE Thread Zigbee Wi-Fi IAQ Hub Raw Features AQI / Events Confidence Role Options Node Report only Bridge Map outputs Rules Local actions Local Outputs Local App Home Hub Alerts Trade-offs Power Complexity Latency ICNavigator
Cite this figure Figure ID: F6 · Gateway Roles · ICNavigator
Figure F6. Product-level roles: a node reports only, a bridge maps outputs across radios, and bridge+rules adds local actions. Trade-offs are verified by TX duty, retry/backoff behavior, and end-to-end latency.

H2-9. Mixed-Signal Coexistence: Noise, EMC/ESD, and “What to Isolate First”

IAQ hubs combine sensitive analog AFEs, bursty sensor loads, and RF transmissions. The fastest path to stability is to classify coupling into three buckets (RF → AFE, ripple → ADC, ground bounce/ESD → reset), then prove the culprit with synchronized evidence before applying minimal isolation fixes.

RF → AFE Ripple → ADC ESD → Reset

Three common coupling paths (symptom signatures)

Coupling path Typical symptom Two fastest proofs First isolation move
RF TX → AFE Values jump during uplink windows; spikes repeat with TX bursts TX timing vs ADC codes; reduce TX power / shift report window Sample outside TX window; strengthen AFE supply/return isolation
DC/DC ripple → ADC / REF Code jitter aligns with load pulses; multi-sensor jitter appears together Ripple on AFE/REF rail; correlate jitter with load activity RC/π filtering into AFE/REF; separate noisy loads from reference rail
Ground bounce / ESD → MCU reset Reboots, “data gaps,” counters reset; often after touch/plug/ESD events Reset reason log; supply droop at event moment Improve return path and transient protection; harden reset/brownout thresholds

Isolation principles (engineering-focused, not a certification walkthrough)

  • Partition by function: keep analog reference and AFE returns out of high di/dt RF and load loops.
  • Schedule sampling: avoid RF TX windows and major load pulses during ADC capture/integration windows.
  • Stabilize references: isolate ADC/REF rails from pulsed loads using RC/π filtering and local decoupling.
  • Minimize coupling geometry: short sensitive nodes, small loops, and stable return paths.

Boundary: This page focuses on isolation tactics and evidence points. Deep EMC/safety details (TVS/ESD/EFT/surge, leakage/isolation verification, event recording) should be handled in the dedicated “EMC / Safety & Metering Subsystem” page.

Figure F7 — Mixed-signal coexistence: coupling paths and first isolation targets Block diagram showing RF TX coupling into analog AFE, DC/DC ripple coupling into ADC/reference, and ground bounce/ESD causing MCU reset. The diagram highlights isolation priorities and synchronized evidence points. Coexistence Map — Noise / EMC / ESD RF TX TX Window AFE + ADC Sensitive Node ADC REF Sample Window ADC Codes Power DC/DC Ripple Load Pulses MCU Reset Log Reason RF → AFE Ripple → ADC ESD → Reset Evidence TX Timing ADC Ripple Reset First Isolate 1 2 3 TX → AFE Ripple Reset ICNavigator
Cite this figure Figure ID: F7 · Coexistence Map · ICNavigator
Figure F7. Three practical coupling paths in an IAQ hub: RF bursts can inject artifacts into the AFE, pulsed loads can imprint ripple on ADC/reference rails, and ground bounce/ESD can trigger resets. Isolation starts with synchronized evidence (TX timing vs ADC codes) before layout or filtering changes.

H2-10. Validation & Field Debug: From Chamber Tests to On-Site Evidence

Validation becomes reliable when every test produces evidence that can be replayed on-site. The method is repeatable: Symptom → Evidence → Isolate → First Fix, supported by minimal tools and consistent logging fields.

Consistency Drift Power Coexistence

Validation layers (what each layer must output)

  • Sensor consistency: cross-unit and cross-node deltas with confidence metadata.
  • Environmental response: step/peak response time and recovery time, separated from transport delays.
  • Drift & aging: baseline drift rate plus status/confidence trends over time.
  • Power: peak current integrity and mAh/day budget repeatability (domain split).
  • Wireless coexistence: TX window alignment and retry/backoff behavior under weak links.

Minimal tools (evidence first)

  • DMM: basic rail sanity and battery condition trend (context, not the root proof).
  • Simple current sampling: pulse height/width/count for domain attribution.
  • Log export: timestamps, confidence/status bits, retries/backoff, reset reasons, and data-gap markers.

On-site symptom templates (each starts with two measurement points)

Symptom First two measurements Isolate by First fix
Spikes TX timing vs ADC codes; AFE/REF rail ripple Align spikes to TX window or load pulses Gate sampling outside TX; improve AFE rail filtering
Long-term drift Status/confidence trend; warm-up stabilization time Confidence degradation vs baseline update bias Slow baseline track + event track; limit update rate
Node mismatch Response time comparison; node confidence parity Placement/flow vs single-node sensor issue Compare synchronized event curves; down-weight low confidence
Battery drops fast Domain current pulse trace; RF TX duty and retries Retry storm vs excessive warm-up/sampling frequency Report window + backoff; batch sampling + buffering
Data gaps Reconnect/retry counters; buffer overflow markers Link quality vs aggressive reporting Backoff + aggregation; protect buffer and preserve timestamps
Evidence checklist (log fields):
timestamp · raw + features · confidence/status bits · TX window counter · retries/backoff · current-pulse stats · reset reason · gap markers
Figure F8 — Field debug decision tree: Symptom → Evidence → Isolate → First Fix A block-style decision tree with five symptom entries leading to two evidence checks, isolation conclusions, and first fixes, designed for minimal tools and on-site replay. Field Debug — Symptom → Evidence → Isolate → First Fix Symptom Evidence (2 checks) Isolate First Fix Spikes TX timing vs ADC REF ripple RF coupling Gate sample Filter AFE Drift Status/conf trend Warm-up time Baseline bias Dual-track Limit updates Mismatch Response time Conf parity Placement Sync compare Down-weight Battery Current pulses TX duty + retry Retry storm Backoff Batch + buffer Data gaps Reconnect count Buffer markers Link quality Aggregate Protect buffer Minimal tools · synchronized timing · replayable evidence ICNavigator
Cite this figure Figure ID: F8 · Debug Decision Tree · ICNavigator
Figure F8. A repeatable on-site method: each symptom starts with two evidence checks, isolates the dominant cause, and applies a minimal first fix. The same evidence fields (timing, confidence, retries, current pulses, reset reasons) support both chamber tests and field replay.

H2-11. IC & BOM Selection Map (Practical Part Buckets, With MPN Examples)

This map supports “bucket-based selection” for an IAQ hub: PM/VOC/CO₂ sensing paths, edge analytics, multi-radio bridging, energy accounting, and replayable field evidence. Each bucket lists representative part numbers and a single, IAQ-specific reason (noise, drift, Iq, logging, coexistence) without turning into a general encyclopedia.

Low drift Low noise Low Iq Replayable logs RF coexistence

How to use this map (fast)

  • Pick the bucket (Analog / MCU / Radios / Power / Memory / Protection).
  • Filter by IAQ constraints: baseline stability, warm-up behavior, duty-cycling, TX-window gating, and log evidence.
  • Validate with proof hooks (TX timing vs ADC codes, rail ripple/current pulses, status/confidence trends, retry/backoff counters).
Bucket Owns Key specs to prioritize Proof hook (tie back to this page)
AFE / Analog Baseline stability and event fidelity Low drift, low 1/f noise, stable reference path Baseline trend + spike correlation vs TX/load windows
MCU Duty-cycle control + logging ULP modes, RTC wake, SRAM for buffers, robust timestamping Replay logs: status bits, counters, reset reasons
Radios Bridge behavior (product-level) TX duty control, coexistence behavior, secure storage capability Retry/backoff + TX window alignment vs measurement artifacts
Power Clean analog rails + pulse handling Low Iq regulators, low-noise LDO for AFE, load switches Current pulses + rail ripple during sensing/report windows
Memory Evidence retention (local) Write endurance, low-power reads/writes, simple integrity checks Data gaps vs buffer full markers; post-OTA comparisons
Protection Interface robustness (point only) Low-cap ESD arrays for I/O, right TVS placement strategy Reset reasons vs ESD season; interface error counters

MPN scope rule: Each bucket lists representative part numbers/series for direction and alternates. The note beside each MPN is limited to IAQ-hub contribution (noise/drift/Iq/logging/coexistence), not generic theory. Deep EMC/safety design details belong to “EMC / Safety & Metering Subsystem”.


AFE / Analog bucket (TIA, ADC, bias DAC, analog switch/MUX)

Sub-bucket Representative MPN / series Why it fits an IAQ hub (one-line)
Zero-drift op-amp TI OPA388 · TI OPA333 · ADI ADA4528-2 · ADI LTC2057 · Microchip MCP6V51 Controls baseline drift and low-frequency noise so “slow baseline + fast event” separation remains stable over time.
Electrochemical gas AFE TI LMP91000 Integrates potentiostat-style front-end functions that reduce discrete analog risk for electrochemical VOC-type sensing paths.
Low-noise ADC TI ADS1220 · TI ADS1115 · ADI AD7124-4 · ADI AD7799 · Microchip MCP3421 Provides stable code repeatability for trend and event detection under duty-cycled sampling and noisy environments.
Bias DAC TI DAC60501 · TI DAC63204 · ADI AD5683R · Microchip MCP4728 Enables controlled bias / offset trim to keep baseline tracking predictable without “over-correcting into drift.”
Analog switch / MUX TI TMUX1108 · ADI ADG708 · ADI ADG704 · TI TS5A3359 Reduces leakage/injection artifacts so channel switching does not masquerade as VOC/PM “events.”

Sensor module (common IAQ BOM anchors): PM: Plantower PMSA003I, Sensirion SPS30. VOC: Sensirion SGP40, AMS CCS811, Bosch BME688. CO₂ (NDIR): Sensirion SCD41/SCD40, Senseair S8, Winsen MH-Z19C. (These are integration anchors; the hub still needs clean power, timing, and logging to make them trustworthy.)


MCU bucket (ULP control, buffering, timestamping, evidence logs)

Representative MPN / series Why it fits an IAQ hub (one-line) Evidence feature to require
ST STM32U5 series Balances low-power modes with enough compute and memory for features, buffering, and robust local logs. RTC + low-power wake + buffered logging with timestamps
ST STM32L4 series Strong ULP ecosystem for periodic sensing, event tagging, and field replay without power surprises. Sleep current + DMA/serial wake + reset reason capture
Microchip SAM L21 series ULP duty-cycling friendly; suitable when “sample → process → batch report” dominates the workload. Low-power timers + deterministic sampling window control
Renesas RA2L1 series ULP + practical peripherals; fits hubs that must log counters and handle multiple sensor interfaces. Event counters + brownout/reset logging
NXP K32L3 series Good match for multi-interface sensor hubs needing stable timing and on-device confidence bookkeeping. Timestamped logs + buffer watermark markers

Radios bucket (Thread/Zigbee/BLE/Wi-Fi, chosen by bridge role)

Radio need Representative MPN / series Why it fits an IAQ hub (one-line)
802.15.4 (Thread/Zigbee) TI CC2652R · TI CC1352P · Silicon Labs EFR32MG24 · Nordic nRF52840 · NXP JN5189 Supports low-power, local-ecosystem bridging while keeping TX behavior schedulable relative to sampling windows.
Wi-Fi (direct connect) Espressif ESP32-C6 · Espressif ESP32-S3 · TI CC3235SF Enables direct connectivity when no separate home hub exists; requires stricter TX-window gating and retry control.
BLE (provisioning/near-field) Nordic nRF52832 · Nordic nRF52840 · Silicon Labs EFR32BG22 Efficient for setup and local interactions while keeping average current predictable for battery-first IAQ hubs.

Power bucket (PMIC/LDO/DC-DC, load switches, current sensing)

Sub-bucket Representative MPN / series Why it fits an IAQ hub (one-line)
ULP buck / DC-DC TI TPS62743 · ADI LTC3331 · ADI LTC3337 Improves battery life under duty-cycled sensing while handling pulsed loads without collapsing the core rail.
Low-noise LDO (AFE/REF) TI TPS7A20 · TI TPS7A02 · ADI LT3042 Keeps analog rails quiet so RF bursts and load pulses do not turn into false VOC/CO₂/PM excursions.
Load switch TI TPS22916 · TI TPS22918 · onsemi NCP45520 Hard-disconnects sensor domains (NDIR/MOS heater/PM module) to enforce a measurable duty-cycle budget.
Current / power monitor TI INA219 · TI INA226 · TI INA233 Turns power into evidence: pulse attribution by domain and mAh/day accounting that matches field behavior.
Fuel gauge / battery monitor TI BQ27441 · Maxim MAX17048 Provides stable state-of-charge context so “battery drop” is traced to duty-cycle/retries rather than guesswork.

Memory bucket (local evidence: FRAM / Flash)

Memory type Representative MPN / series Why it fits an IAQ hub (one-line)
I²C FRAM Fujitsu MB85RC256V · Infineon/Cypress FM24CL64B Handles frequent small writes (counters, events, status snapshots) without endurance surprises.
SPI FRAM Infineon/Cypress FM25V02A Fast, durable evidence storage for “black box” style field replay when power is unstable.
SPI NOR Flash Winbond W25Q32JV · Macronix MX25R6435F · GigaDevice GD25Q32 Supports batch logging and trend buffers; pair with watermark markers to distinguish “link loss” vs “buffer full.”

Protection bucket (ESD/TVS for interfaces — point only)

Use case Representative MPN / series Why it fits an IAQ hub (one-line)
Low-cap ESD array (I/O) TI TPD4E1U06 · TI TPD1E10B06 · Nexperia PESD5V0S1UL · Semtech RClamp0524 Reduces “dry-season resets” and interface glitches while keeping high-impedance sensing nodes protected.
Power-entry TVS (typical series) Littelfuse SMBJ series · Vishay SMBJ series Clamps power surges at the boundary; detailed placement/standards belong to the EMC/safety subsystem page.
Figure F9 — IAQ Hub BOM Bucket Map Block diagram mapping IAQ hub sensing modules to analog AFE/ADC, edge MCU with logging memory, multi-radio bridge, power domains with current sensing, and interface protection. Designed for bucket-based part selection. BOM Bucket Map — Indoor Air Quality Hub Sensors PM Module VOC Sensor CO₂ NDIR AFE / ADC Zero-drift TIA / Op-amp Low-noise ADC Bias DAC MUX Edge MCU ULP + RTC Logs + Counters FRAM Flash Radios / Bridge 802.15.4 Thread/Zigbee BLE Provisioning Wi-Fi Direct connect Bridge Mode Node / Gateway Power Domains Sensor RF Core Load Switch Duty-cycle control Current Sense mAh/day evidence Protection ICNavigator
Cite this figure Figure ID: F9 · BOM Bucket Map · ICNavigator
Figure F9. A bucket-based BOM map: sensor modules feed the analog AFE/ADC, which is timed and logged by an edge MCU. Radios are chosen by bridge role (node vs gateway vs direct Wi-Fi). Power is split into domains with load switches and current sensing, turning energy into evidence (mAh/day) and making field debug repeatable.

H2-12. FAQs (12) — Collapsible, Each Answer Falls Back to This Page

Each FAQ is constrained to IAQ-hub evidence: synchronized timing, rail ripple/current pulses, status/confidence bits, retry/backoff counters, buffer watermarks, and reset reasons. No purifier mechanics, no protocol deep dives, and no cloud backend architecture.

VOC jumps when Wi-Fi transmits — RF coupling or rail ripple? What two proofs come first?
Start by proving timing. If VOC “events” align with TX bursts, RF coupling is likely; if they align with load pulses or DC/DC switching, rail ripple dominates.
  • Proof 1: log (or GPIO-mark) TX windows and overlay with ADC codes / VOC raw output.
  • Proof 2: measure AFE/REF rail ripple during TX and during quiet periods.
First fix: gate sampling outside TX windows and isolate the analog rail with RC/π filtering.
See: H2-9, H2-7.
CO₂ reads high for weeks — poor ventilation or NDIR drift? Which two curves/status bits matter?
Separate “environment shift” from “sensor health shift.” A real ventilation change usually shows consistent occupancy-linked patterns, while drift shows confidence/status degradation and baseline offset growth.
  • Proof 1: track NDIR status/quality flags (or confidence) versus time and temperature/humidity context.
  • Proof 2: compare long-term CO₂ baseline to event-driven rises (people/cooking windows) to check shape consistency.
First fix: enforce warm-up and sampling windows; trigger self-check and downgrade confidence if status indicates aging/contamination.
See: H2-5, H2-6.
PM spikes appear often — real dust events or power/algorithm artifacts?
Real dust spikes usually co-occur with stable module framing and plausible recovery; artifacts often align with power dips, fan pulses, or frame errors.
  • Proof 1: measure PM module supply ripple / droop during spikes (especially at fan or report activity).
  • Proof 2: log UART/I²C frame errors, dropped frames, or checksum faults around spikes.
First fix: add supply isolation for the PM module and treat error-bursts as “low confidence” instead of “events.”
See: H2-3, H2-10.
Same production batch, large reading differences — what three steps verify consistency fast?
Consistency failures must be separated into sensor spread, placement/airflow, and system artifacts.
  • Step 1: co-locate units for a controlled step event and compare response/recovery shapes (not only averages).
  • Step 2: compare confidence/status and warm-up time-to-stable for each unit.
  • Step 3: check coexistence correlation: do deviations align with TX windows or load pulses?
First fix: standardize warm-up/sampling schedules and downgrade low-confidence units rather than “forcing calibration.”
See: H2-10, H2-9.
Low-power design: which sensors need warm-up and which can be intermittent?
Warm-up depends on the sensor physics and module design. NDIR CO₂ and MOS VOC typically benefit from stabilized windows; many digital PM modules can be duty-cycled but require stable supply and settling time.
  • Proof 1: measure time-to-stable after wake (baseline convergence) for each sensor type.
  • Proof 2: quantify energy per sample: current pulse height × width × count per day.
First fix: tiered wake strategy: short wake for “sniff,” long wake only when event likelihood rises.
See: H2-7, H2-5, H2-4.
Battery life suddenly collapses — check radio retries or sensor heater first?
The fastest split is “RF retry storm” versus “sensor domain over-activation.” Both show distinct pulse signatures and counters.
  • Proof 1: compare RF retry/backoff counters and TX duty versus the last known-good period.
  • Proof 2: capture current pulses per domain: RF bursts vs heater/NDIR pulses vs PM module pulses.
First fix: throttle reporting with aggregation/backoff; hard-gate heater/NDIR windows and log wake causes.
See: H2-7, H2-8.
How to infer “filter life/effectiveness” without purifier airflow modeling?
Filter analytics can be expressed as an index derived from observed recovery dynamics, not actuator models. Use “improvement rate,” “recovery time,” and long-term baseline shifts as signals, while treating room-to-room variability as context.
  • Proof 1: compute recovery time after repeated, similar events (cooking/cleaner) under comparable occupancy.
  • Proof 2: track baseline drift and confidence to avoid confusing sensor aging with “filter aging.”
First fix: maintain dual tracks (slow baseline + fast events) and report a normalized effectiveness index with confidence.
See: H2-6, H2-10.
RH/T affects TVOC too much — what is the minimal compensation to avoid overfitting?
Minimal compensation should prevent obvious RH/T-induced baseline shifts without learning room-specific patterns. Use a slow baseline correction tied to RH/T and keep event detection primarily feature-based (slope/peak/duration) with confidence gating.
  • Proof 1: correlate RH/T ramps with TVOC baseline drift (slow track), separate from fast events.
  • Proof 2: verify event detection stability across multiple days using the same thresholds and confidence rules.
First fix: apply limited, bounded RH/T correction on the baseline track only; do not amplify fast-track events.
See: H2-4, H2-6.
After OTA, readings worsen — how to isolate sampling-window vs threshold changes using local logs?
Treat OTA debugging as a replay problem. Compare pre/post OTA traces using the same evidence fields: sampling schedule, TX windows, confidence/status, and feature outputs.
  • Proof 1: compare sampling timestamps and TX/report windows before and after OTA (schedule drift is a common culprit).
  • Proof 2: compare feature-level outputs (moving average, slope, spike flags) to see if thresholds shifted.
First fix: restore known-good windowing first, then tune thresholds; keep rollback markers and versioned configs in local logs.
See: H2-10, H2-9.
Dry season resets — ESD or supply droop? Two-step proof method?
Distinguish “transient shock” from “power integrity collapse.” ESD-like events often coincide with touch/plug activity and specific interface glitches; droop shows measurable rail sag and brownout markers.
  • Proof 1: read reset reason (brownout/watchdog) and check whether UART/I²C error counters spike at the same moment.
  • Proof 2: capture rail droop during the event window (even a simple min-hold measurement helps).
First fix: harden interface ESD protection and return paths, then adjust brownout thresholds; validate by event replay.
See: H2-9, H2-10.
Bridge latency is high — RF congestion or MCU buffering strategy?
Latency splits into “airtime/retries” and “local queueing.” A congested RF link shows retries/backoff growth; MCU queueing shows buffer watermark growth and delayed batch flush.
  • Proof 1: log per-packet retry/backoff and TX duty; look for bursts of retransmissions.
  • Proof 2: log queue depth / buffer watermark and batch-flush intervals.
First fix: cap burst reporting, enable aggregation, and align sensing/report windows so RF TX does not disturb sampling fidelity.
See: H2-8, H2-7.
Data is intermittent — link drop or local buffer full? Which two logs decide?
Intermittent data usually comes from either connectivity gaps or local storage pressure. The decision can be made with two log classes: link health and buffer health.
  • Proof 1: reconnect count + retry/backoff statistics (link health).
  • Proof 2: buffer watermark + “write failed / buffer full” markers (storage health).
First fix: apply backoff and aggregation first; protect buffer by batching and compressing, and preserve timestamps for replay.
See: H2-10, H2-7.
Figure F10 — FAQ Evidence Router (Q1–Q12 → 4 evidence blocks → isolate → first fix) Diagram showing twelve FAQ nodes (Q1–Q12) feeding four evidence blocks: TX timing, rail ripple/current pulses, status/confidence bits, and logs/counters. Evidence routes to isolate causes and first fixes. FAQ Evidence Router Each question starts with evidence, not opinions. Q1–Q12 Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11 Q12 Evidence Blocks TX Timing report / uplink window Rail Ripple + current pulses Status / Confidence health + drift flags Logs / Counters retry / buffer / reset Isolate RF Coupling Power Noise Baseline Bias Retry Storm Sensor Aging First Fix Gate Filter Dual-track Backoff Degrade ICNavigator
Cite this figure Figure ID: F10 · FAQ Evidence Router · ICNavigator
Figure F10. FAQs are forced back to evidence blocks (timing, ripple/current, status/confidence, logs/counters), then to isolate causes and minimal fixes (gating, filtering, dual-track baseline, backoff/aggregation, graceful degradation). This keeps answers deep and actionable without drifting into unrelated system pages.

Request a Quote

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

H2-12. FAQs (12) — Collapsible, Evidence-Driven, Scope-Locked

Each answer stays inside this IAQ Hub scope: sensor AFEs (PM/VOC/CO2), edge MCU, radios, duty-cycling, logs/counters, coexistence, and validation evidence. Every question starts with two measurements and ends with a minimal first fix.

Q1. TVOC jumps when Wi-Fi transmits: RF coupling or supply ripple?

Treat this as a timing problem first. If TVOC spikes align tightly with radio TX windows, RF injection is likely; if spikes align with load pulses and rail ripple, power integrity is dominant.

  • Check 1: TX timing vs ADC/TVOC raw (same timestamp base).
  • Check 2: AFE/REF ripple during TX vs quiet.

First fix: gate sampling outside TX windows + isolate the analog rail (RC/π + low-noise LDO). See: H2-9, H2-7, H2-4.

Q2. CO2 reads high for weeks: poor ventilation or NDIR drift?

Separate “baseline offset” from “event shape.” A stable event rise/fall with a constant offset suggests sensor baseline drift; changing shapes with occupancy often indicates real ventilation differences.

  • Check 1: NDIR status/confidence (health/self-check indicators).
  • Check 2: baseline trend vs occupancy event curve.

First fix: enforce warm-up + fixed sampling window; down-weight low confidence readings. See: H2-5, H2-6, H2-10.

Q3. PM shows frequent spikes: real dust events or artifacts?

PM modules can spike when their supply or interface is disturbed. Real dust events usually have coherent rise/decay without simultaneous frame corruption.

  • Check 1: PM supply ripple / droop during fan/measurement phases.
  • Check 2: frame error / drop counters (UART/I²C integrity).

First fix: isolate PM power + treat bad frames as low-confidence (do not trigger events). See: H2-3, H2-9, H2-10.

Q4. Same batch varies a lot: which 3 consistency checks come first?

Consistency must be proven in three layers: dynamic response, stabilization, and coexistence sensitivity. This avoids “calibrating away” a power/RF coupling problem.

  • Step 1: step response (rise/decay time under the same event).
  • Step 2: warm-up to stable + status/confidence parity.
  • Step 3: TX/load correlation (spikes align to windows?).

First fix: normalize sampling/report windows before any per-unit offsets. See: H2-10, H2-9, H2-6.

Q5. Low power: which sensors need warm-up and which can be duty-cycled?

Decide by measurement, not assumptions: “time-to-stable” and “energy-per-sample” determine whether a sensor should be continuous, short-sniffed, or batch-sampled.

  • Check 1: time-to-stable after wake (minutes/seconds).
  • Check 2: current pulse area per sample (mAs → mAh/day).

First fix: short sniff → decide long window only when events are likely. See: H2-7, H2-5, H2-4.

Q6. Battery life suddenly worse: radio retries or sensor heater pulses?

Split the culprit by “pulse shape + counters.” Retry storms show high TX duty and backoff/retry growth; heater/NDIR issues show repeatable large sensor-domain pulses even when the link is stable.

  • Check 1: retry/backoff + TX duty counters.
  • Check 2: domain current pulses (RF vs sensor heater/NDIR).

First fix: aggregate + backoff for RF; hard-gate heater/NDIR windows for sensors. See: H2-7, H2-8.

Q7. Filter life without airflow model: how to infer an effectiveness index?

Only infer a local “effectiveness index” from observable dynamics: improvement rate and recovery time across repeated event types, guarded by sensor health. This stays independent of purifier fan/airflow details.

  • Check 1: recovery time and improvement slope for repeated events.
  • Check 2: sensor confidence/health to avoid confusing drift with degradation.

First fix: dual-track baseline + event metrics; output index + confidence only. See: H2-6, H2-10.

Q8. RH/T distorts TVOC: minimal compensation without overfitting?

Keep compensation bounded and slow. Apply RH/T correction only to the slow baseline track, while event detection uses fast features and confidence gating. This prevents humidity swings from re-shaping event thresholds.

  • Check 1: RH/T slope vs slow TVOC baseline.
  • Check 2: event stability before/after correction (false triggers).

First fix: slow, bounded baseline correction + keep event features separate. See: H2-4, H2-6.

Q9. After OTA readings degrade: sampling window shift or threshold change?

Compare “timing first, math second.” Window shifts change correlation to TX/load timing; threshold/feature changes alter event marks even under identical windows.

  • Check 1: sampling/report timestamps vs TX windows (before/after OTA).
  • Check 2: feature outputs (moving average/slope/peak flags) for systematic shifts.

First fix: restore window schedule; version log key parameters for fast rollback. See: H2-6, H2-7, H2-10.

Q10. Dry season resets: ESD or brownout? Two-step proof.

Use reset evidence and rail evidence together. ESD-like resets often cluster around touch/plug events and show interface glitches; brownouts show rail droop aligned to load pulses or TX bursts.

  • Step 1: reset reason (brownout/watchdog) + error counters.
  • Step 2: rail droop at the event moment (domain attribution).

First fix: harden transient return/protection + tune brownout thresholds with evidence. See: H2-9, H2-10.

Q11. Gateway bridge latency is high: RF congestion or MCU queueing?

Airtime problems look like retries/backoff inflation; queueing problems look like growing buffers and long batch flush intervals. Both can co-exist, so isolate by counters and timestamps.

  • Check 1: retry/backoff + TX duty trend (congestion signature).
  • Check 2: buffer watermark + flush interval (queue signature).

First fix: aggregate reports + cap burst rate; align sampling/report windows. See: H2-8, H2-7.

Q12. Data becomes intermittent: link drops or local buffer full?

Two log families decide quickly. Link drops produce reconnect/retry spikes; buffer exhaustion produces full/watermark/write-fail markers and preserved timestamps without uplinks.

  • Check 1: reconnect/retry logs (link health).
  • Check 2: buffer full / write fail markers (storage health).

First fix: backoff + aggregation to relieve the link; protect buffer with batching and timestamps. See: H2-10, H2-7.

Figure F9 — FAQ Evidence Router: Questions → Evidence → Isolate → First Fix A block diagram routing Q1 to Q12 into four evidence blocks (TX timing, rail ripple/current pulses, status/confidence, logs/counters), then into isolation conclusions and minimal first fixes. FAQ Evidence Router Pick 2 proofs first → isolate → minimal fix (scope-locked to IAQ Hub) Questions Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11 Q12 Evidence Blocks (pick 2) TX timing / windows Rail ripple / current pulses Status / confidence Logs / counters Isolate RF coupling Power ripple Baseline bias Retry / buffer First Fix Gate sample Filter rail Dual-track Backoff+buffer ICNavigator
Cite this figure Figure ID: F9 · FAQ Evidence Router · ICNavigator
Figure F9. Every FAQ starts by selecting two proofs (timing, power, status, logs), then isolates the dominant cause and applies a minimal fix—without crossing into purifier/HEMS/protocol deep dives.