RF gets worse in certain grip/angles — antenna issue or RF rail droop? How to validate?

Capture (1) RSSI trend with retries across repeatable poses and (2) TP_VBAT (or RF rail) droop aligned to RF TX events in the same poses. RSSI drops without rail change indicates antenna/body blocking; retries spiking with droop indicates domain/peak contention. First fix: improve antenna margin if RSSI-driven, otherwise isolate RF burst domain and de-conflict peaks; verify retry reduction in the problematic pose.

Smart Remote: Low-Power MCU, BLE/IR/RF, Voice Front-End

Q: Battery drops fast even with light use — which two current evidence points first?

Start by separating idle leakage from burst energy. Capture (1) true idle I_AON plateau and (2) one real action’s current×time area (voice or IR). A high plateau indicates something never fully gates off; a large event area indicates burst averaging or retries are dominating. First fix: hard-gate burst rails with a load switch and cap retry/voice window, then re-measure.

Q: Standby current looks low, yet battery dies in weeks — is burst averaging wrong?

This is usually tail behavior: long reconnects, retry storms, or voice sessions longer than assumed. Capture daily event counts (voice sessions, retries) and burst duration p50/p95, not only averages. If p95 is large, the tail dominates energy. First fix: enforce retry/time budgets and verify p95 shrinks and daily burst area drops.

Q: Key sometimes fails to wake — GPIO leakage/ESD or matrix scan strategy? What evidence separates them?

Capture (1) the GPIO_WAKE edge at the MCU pin and (2) WAKE_CAUSE for the same press. If an edge exists but WAKE_CAUSE is missing, suspect leakage/ESD clamp/threshold or return path. If no edge exists, suspect matrix/scan/debounce policy. First fix: move critical keys to true wake-capable pins and harden exposed lines with ESD parts; re-test wake error rate.

Q: Voice turns on and noise jumps — mic AFE issue or power-ripple coupling? Which two waveforms first?

Capture (1) audio-rail ripple (e.g., TP_1V8_AUD) plus MIC_BIAS stability and (2) pre-AEC PCM stats (noise floor delta, clipping count) while toggling backlight/RF/haptics. If noise tracks PWM/RF windows, it is coupling; if clipping/DR shifts without ripple correlation, it is gain/biasing. First fix: de-conflict RF/IR peaks from capture and harden the audio rail (isolation or low-noise regulation), then verify noise floor drops.

Q: Voice sometimes becomes choppy — check RF retries first or audio buffer underrun?

Measure one RF metric and one audio continuity metric in the same voice window: (1) retry counter + latency p95 and (2) PDM/I2S continuity or buffer-underrun logs. Continuous audio with exploding retries/p95 points to RF transport; local underruns/gaps point to DMA/clock/buffer scheduling. First fix: cap RF tail (retry/time budgets) if RF is guilty, otherwise stabilize audio DMA/buffer and prove gaps disappear.

Q: IR works nearby but fails far away — peak drive not enough or modulation distortion? How to measure?

Capture (1) TP_BOOST_IR and TP_VBAT droop (depth and recovery) and (2) an IR pulse monitor aligned to the droop. Deep droop with stable timing indicates peak headroom/current limit; stable rails with unstable pulse width/duty indicates driver/modulation integrity. First fix: increase peak headroom (boost/switch path/storage) or stabilize the driver chain, then verify shallower droop and repeatable pulses.

Q: Remote reboots on rapid presses/long press — brownout or watchdog? How to capture all evidence at once?

Capture (1) RESET_REASON plus any UVLO/PG flags and (2) TP_VBAT droop aligned to event GPIOs (IR burst, RF TX, backlight/haptics enable). Brownout flags with synchronous droop prove peak-power contention; watchdog resets without droop point to scheduling/lockup evidence. First fix: de-conflict peaks and add brownout-proofing (domain isolation/soft-start/supervisor), then confirm reset count drops.

Q: Adding backlight/haptics suddenly increases standby current — where is the most common leakage path?

This usually means a domain never truly powers down: PWM still toggles, driver bias stays on, or pull-ups leak through drivers/ESD. Capture (1) I_AON plateau before/after and (2) PWM/enable activity (or load-switch EN) in idle. Periodic current steps matching PWM indicate gating failure; a constant plateau raise indicates shutdown leakage. First fix: hard-gate the rail with a load switch and stop PWM in idle, then verify I_AON drops.

Q: Passes lab ESD tests, but still freezes in the field — return path issue or reset pin sensitivity? Evidence approach?

Use reset-cause statistics and touch-point correlation. Capture (1) RESET_REASON distribution (pin reset vs brownout vs watchdog) across repeated stress attempts and (2) which exposed point most reliably triggers the event. Pin-reset dominated points to reset pin sensitivity/filtering; brownout dominated points to return-path/rail upset. First fix: add proper ESD clamps and controlled return paths near entry points, and harden reset pin filtering; verify event rate drops.

← Back to: Consumer Electronics

A smart remote succeeds when it is engineered around evidence-first power domains: minimize true-idle leakage, control RF/IR/voice bursts, and validate every symptom with measurable probes (current plateaus, rail droop, reset/wake causes, retries, and audio stats).

H2-1 · System Boundary & Use Cases

System Boundary & Use Cases: What “Smart Remote” Actually Is

This page treats the remote as a self-contained hardware system: user input → local processing → IR/RF actuation, with voice capture as an optional burst workload. It does not cover Smart TV / set-top-box software, cloud speech pipelines, or protocol-stack tutorials. The design goal is to balance sleep longevity, wake latency, and field reliability using measurable evidence.

Four Functional Surfaces

Each surface maps to a distinct power burst and evidence set.

Keys / Touch / Encoder
Voice Input (Mic AFE)
IR Transmit (IR LED + Driver)
RF Link (BLE / 2.4G RF)

Evidence anchors

Wake evidence: GPIO / scan window / debounce timing, wake-cause register
Voice evidence: mic-bias, PDM/I2S activity, clipping/noise statistics
IR evidence: IR pulse amplitude, peak current, VBAT droop during bursts
RF evidence: RSSI trend, retry counters, latency p50/p95 under interference

Mode A — Idle Deep Sleep (dominant state)

Objective: minimize leakage while preserving deterministic wake.

Evidence to capture

Sleep current at rail or shunt (AON domain only)
Unexpected leakage paths: pulls, ESD structures, wet contamination
Wake pin integrity: floating/noise/ESD susceptibility

Mode B — Key/Touch Wake (instant, short)

Objective: fast wake + clean intent classification with minimal scan energy.

Evidence to capture

Wake latency breakdown: debounce → MCU start → RF/IR action
False wakes: GPIO glitch rate, scan duty cycle vs noise
Key ghosting / touch drift indicators (baseline, thresholds)

Mode C — Voice Session (high-power burst)

Objective: stable audio capture + bounded burst energy.

Evidence to capture

Mic-bias stability and AFE headroom (no clipping on loud speech)
PDM/I2S clocks and buffer underrun markers
Power integrity during voice+RF uplink (droop, resets, retries)

Mode D — Pairing / OTA / Diagnostics (rare)

Objective: reliable link establishment without draining battery.

Evidence to capture

Time-to-pair, retry counts, connection interval impacts
RSSI under user grip/orientation; antenna detuning markers
Reset reasons and watchdog triggers during long radio activity

Typical Power Sources (constraints only)

Coin-cell: high internal resistance; IR/voice bursts can cause VBAT droop → prioritize domain gating and burst shaping.
AAA: better burst headroom; leakage and scan strategy dominate battery life.
Li-ion: wide voltage range; UVLO/brownout boundaries and rail sequencing become primary reliability gates.

Figure F1. Mode-to-evidence map. Each operating mode is tied to concrete probes (rail current, wake cause, audio activity, IR pulse, RF counters, reset reasons) for fast validation and field debugging.

Reuse tip: cite as “ICNavigator, Smart Remote Figure F1 (Modes → Evidence Map)”. Cite this figure →

H2-2 · Architecture Map

Architecture Map: Blocks, Signals, and Power Domains

The architecture must be read in three layers: (1) signal paths (input/voice → MCU → IR/RF), (2) power domains (always-on vs burst rails), and (3) evidence probes that prove whether a failure is caused by wake logic, power integrity, audio headroom, IR drive, or radio robustness.

Layer 1 — Signal Paths (what moves when a command happens)

Keys/Touch → MCU: deterministic intent capture (debounce/scan window) before any high-power rail is enabled.
Voice → Mic AFE → MCU: PDM/I2S activity gates the voice session window; capture quality is validated by clipping/noise statistics.
MCU → IR: IR bursts are encoded pulses with peak-current demands; range failures correlate with pulse amplitude and rail droop.
MCU → RF: command delivery is validated by retry counters and latency distribution (not just “connected/disconnected”).

Layer 2 — Power Domains (why battery life and reliability are coupled)

AON domain (always-on): RTC, wake detect, minimal GPIO; must meet the sleep-current budget.
Switched domains (burst): RF, Audio, IR, Haptics; enabled only when needed, with controlled ramp and verified by rail probes.
Brownout boundary: IR peak + RF TX + audio clocks can stack into a droop that triggers reset; reset reasons must be captured.

Layer 3 — Evidence Probes (how to make debugging fast)

Use probes that answer “what domain turned on, what failed, and why” in one capture.

TP_VBAT / I_VBAT
TP_AON / I_AON
TP_RF / RF_RETRY
TP_IR_BOOST / IR_PULSE
TP_MIC_BIAS / PDM_CLK
RESET_REASON

Figure F2. Architecture mother-map. Read as (1) signal paths, (2) AON vs burst domains, and (3) evidence probes (TPs + counters) that pinpoint power, wake, audio, IR, or RF causes.

Reuse tip: cite as “ICNavigator, Smart Remote Figure F2 (Architecture Map)”. Cite this figure →

H2-3 · Power Budget First

Power Budget First: Sleep Current, Leakage, and “Burst” Math

Battery life for a smart remote is rarely limited by “average use” alone. It is dominated by sleep leakage (always present), periodic housekeeping (small but frequent), and interactive bursts (short but high power). A reliable budget ties each bucket to measurable evidence: rail current waveforms, activity windows, and counters that explain why bursts grow.

Three-Part Power Model (measure each bucket separately)

Sleep leakage: baseline current while the remote is “doing nothing”.
Periodic housekeeping: scan windows, timers, link keep-alive (if any), watchdog, sensor checks.
Interactive bursts: key press → action, voice session, IR transmit, RF reconnect/retry.

Evidence anchors

Sleep: I_AON (or I_VBAT) plateau + WAKE_CAUSE histogram (false wake rate)
Housekeeping: repeating “mini-steps” in current waveform (period + width)
Bursts: burst width + RF_RETRY + PDM/I2S activity window + IR_PULSE amplitude

Sleep Current Composition (typical hidden contributors)

MCU retention + RTC: lowest-power state must be proven, not assumed.
Wake pin network: pullups/pulldowns, dividers, floating pins, EMI/ESD sensitivity.
Key matrix/touch biasing: scan bias or leakage through membrane/contamination paths.
ESD/leakage paths: TVS/leakage, wet contamination, connector leakage, PCB residue.
Always-on regulator Iq: quiescent current can dominate on long sleep timelines.

Burst Math (turn “a few seconds” into average mAh)

The goal is to measure burst amplitude and time width, then convert into daily average. No protocol theory is required—only current waveforms and event counters.

Formulas (use measured values)
Burst charge: Q_burst(mAh) = I_burst(mA) × t(s) / 3600
Daily charge: Q_day = Σ(Q_burst × N_per_day) + I_sleep(mA) × 24(h)

Voice example: 2 s per session × N/day → measure I during PDM/I2S window and its width.
IR example: peak current spike + VBAT droop → measure IR burst peak and its repetition.
RF example: retries stretch time width → use RF_RETRY and latency tail as “burst inflators”.

Power Budget Card (ranges + measurement method)

Contributor	Typical Range	Active When	How to Measure	Pass/Fail Evidence
Sleep leakage (AON)	µA → low mA	Deep sleep	I_AON or I_VBAT plateau	Stable plateau + low false wake count
Housekeeping windows	tens µA → mA	Periodic	Waveform mini-steps (period + width)	Period matches design; width bounded
Voice session (AFE + DSP)	mA → 10s mA	Interactive burst	PDM/I2S window + I_RAIL	No clipping spikes; burst width controlled
IR transmit (peak)	10s → 100s mA	Short peak	IR_PULSE + VBAT droop + peak I	Pulse amplitude stable; no brownout/reset
RF retries / reconnect	mA → 10s mA	Interactive burst	RF_RETRY + latency tail + burst width	Retries bounded; p95 latency controlled

Common “Battery Life Collapse” Patterns (evidence-driven)

IR peak collapses VBAT: IR range degrades + RESET_REASON shows brownout → correlate with VBAT droop during IR spikes.
RF retries stretch bursts: same user action consumes more charge → correlate RF_RETRY growth with wider burst plateaus.
Mic AFE never truly sleeps: PDM clocks remain active → sleep plateau rises permanently.

Figure F3. Current waveform evidence. Sleep plateau, periodic housekeeping pulses, voice burst plateau, and IR peak spikes show where battery life collapses and where to probe (TP_VBAT, I_RAIL, PDM/I2S, RF_RETRY, RESET_REASON).

Reuse tip: cite as “ICNavigator, Smart Remote Figure F3 (Current Waveform & Mode Transitions)”. Cite this figure →

H2-4 · Wake-Up Design

Wake-Up Design: Keys, Touch/Motion, Voice Trigger, and Latency Tradeoffs

Wake-up is not a “feature checkbox”. It is a measurable engineering module that determines user-perceived latency, false wake rate, and sleep longevity. A robust design classifies wake sources, breaks latency into segments, and proves behavior using WAKE_CAUSE, rail probes, and activity windows (RF, IR, audio).

Wake Source Taxonomy (source → cost → evidence)

GPIO / Key matrix: predictable intent; cost is scan/debounce energy → evidence: WAKE_CAUSE + scan window steps.
Cap-touch interrupt: sleek UI; cost is baseline tracking + susceptibility → evidence: baseline drift stats + false trigger count.
IMU interrupt (optional): lift-to-wake; cost is periodic sampling or always-on motion → evidence: IMU interrupt count + added housekeeping steps.
RF wake: remote events / keep-alive; cost is radio windows → evidence: connection event timing + retry counters.
Voice trigger: hands-free; highest cost unless tightly gated → evidence: PDM/I2S window + mic-bias stability + burst width.

Latency Breakdown (from user intent to command delivery)

Each segment has a different root cause and a different probe. Do not treat “latency” as one number.

t1 Detection: scan interval or interrupt detect → probe: GPIO edge vs scan window timing.
t2 Debounce/Filter: intent confirmation → probe: debounce window and mis-detect statistics.
t3 MCU Resume: clocks/rails/state restore → probe: AON→burst rail enable time, RESET_REASON.
t4 Link Readiness: RF connection interval / retry tail → probe: latency p50/p95 + RF_RETRY.
t5 Actuation: IR pulse train or RF TX complete → probe: IR_PULSE monitor or TX-done flag.

Low-Power Strategies (choose with measurable tradeoffs)

Keys: Duty-Cycled Scan vs Always-On Interrupt

Duty-cycled scan: lowest sleep current; latency depends on scan period → evidence: periodic scan mini-steps + t1 distribution.
Always-on interrupt: fastest wake; sensitive to leakage/ESD/noise → evidence: sleep plateau rise + false wake histogram.

Voice Trigger: AFE Always-On vs MCU Low-Power DSP vs External Wake

AFE always-on: simplest, robust trigger; highest steady cost → evidence: PDM/I2S constant activity + elevated sleep plateau.
MCU low-power DSP window: bounded duty cycle; tradeoff is complexity → evidence: defined audio window + controlled burst width.
External wake IC: isolates always-on trigger; reduces MCU duty → evidence: wake-source stats shift + overall sleep plateau reduction.

Wake evidence checklist (minimum set)

WAKE_CAUSE: which source fired (GPIO/touch/IMU/RF/voice)
I_AON & TP_AON: whether sleep truly meets the budget
PDM/I2S window: whether voice trigger is gated as intended
RF_RETRY & latency tail: whether the “link readiness” segment dominates
IR_PULSE amplitude: whether actuation is limited by power/drive

Figure F4. Wake sources and latency chain. Wake correctness is proven by WAKE_CAUSE and rail probes (AON vs burst). Speed is improved by targeting the dominant segment (t1..t5) using evidence windows (PDM/I2S, RF_RETRY, IR_PULSE).

Reuse tip: cite as “ICNavigator, Smart Remote Figure F4 (Wake Sources & Latency Breakdown)”. Cite this figure →

H2-5 · Wireless Link Strategy

Wireless Link Strategy (BLE / Proprietary RF) for Remote Controls

Remote controls do not need “always-high throughput”. They need predictable latency, bounded retries, and a power strategy that prevents short interactions from becoming long bursts. This section stays strictly within the remote-control hardware evidence loop: connection behavior, retry growth, RSSI trends, and latency distribution (p50/p95).

Remote-Link Workload Profile (what matters in this device class)

Button/DPAD control: short packets, “hand-feel” sensitive to latency tail.
Voice session (if present): multi-second uplink activity where retries expand energy cost.
Idle: dominated by sleep leakage and any periodic radio windows (if connection is kept).

Minimum evidence set

Latency histogram: p50 vs p95 (tail is the “stutter” users notice)
Retry counters: per interaction and per minute
RSSI trend: over time and with hand/pose changes
Connection interval: configured vs observed (if applicable)

Keep Connected vs Fast Reconnect (power–latency tradeoffs)

The choice is not philosophical. It is measured by waveform “mini-steps”, retry growth, and latency tail.

Option A — Keep Connected

Benefit: smaller “link-ready” time, more stable p95 latency for button control.
Cost: periodic connection events add housekeeping steps even in idle.
Evidence: connection interval aligns with periodic current mini-steps; p95 latency stays bounded.

Option B — Disconnect + Fast Reconnect

Benefit: cleaner deep sleep with fewer periodic radio windows.
Cost: each interaction pays reconnect overhead; retries can stretch burst width.
Evidence: RF_RETRY increases correlate with wider bursts and worse p95 latency.

Latency Distribution & Retry Growth (why “average” misleads)

p50 latency: typical response; often looks “fine”.
p95 latency: tail events users feel as stutter; usually driven by retries, reconnect, or coexistence hits.
Retry inflation: a small increase in retry count can multiply burst time width and energy cost.

Evidence anchors

Latency histogram: compare p50 vs p95 before/after environment changes
Retry counter: track as “per interaction” (button press) and “per minute” (background)
Burst width: correlate the on-air window with current waveform step width

Interference Resilience (remote-only scope)

Antenna placement & ground reference: avoid hand-blocked locations; keep a stable RF ground reference.
Human-body blocking: RSSI may swing with grip/pose; design for margin at low RSSI.
2.4 GHz coexistence: Wi-Fi and other 2.4 GHz activity can increase retries; treat retry spikes as the primary symptom.

This section intentionally avoids protocol-stack tutorials and router/mesh content.

Field Evidence Card (copy/paste template)

RSSI trend: stable / drifting / grip-sensitive
Retry counter: baseline vs spike windows
Connection interval: configured vs observed (if applicable)
Latency: p50 / p95 and “spike count per minute”
Conclusion hint: RSSI↓ + retries↑ → link margin/placement/coexistence; RSSI ok + p95↑ → strategy/interval/reconnect tail

Figure F5. RF evidence chain for remote controls. Use counters, latency distribution (p50/p95), retry growth, and RSSI trend to classify link-margin issues versus strategy-driven tail latency—without protocol tutorials.

Reuse tip: cite as “ICNavigator, Smart Remote Figure F5 (RF Evidence Chain)”. Cite this figure →

H2-6 · IR Subsystem

IR Subsystem: IR LED Driver, Modulation Integrity, Range & Eye-Safety

An IR remote succeeds when modulation integrity is preserved at the LED, peak current is delivered without collapsing the battery rail, and repeat transmissions remain consistent under temperature. This section focuses on hardware-only levers: IR LED, current limiting/boost, driver devices, and evidence probes (IR pulse amplitude, peak current, VBAT droop, and LED temperature rise).

Modulation Integrity (hardware impact only)

Carrier frequency: drives switching loss and edge-rate needs; weak edges reduce effective range.
Duty cycle: sets LED peak/average stress; incorrect duty shifts thermal and rail droop behavior.
Pulse coding density: dense bursts behave like a longer load; rail recovery and current limit become dominant.

Evidence anchors

IR_PULSE: amplitude and pulse shape at the driver output
I_PEAK: peak current per burst and its repeatability
TP_VBAT droop: depth + recovery time during bursts

Key Hardware Blocks (responsibility boundaries)

IR LED: optical intensity, viewing angle, and thermal limits determine achievable margin.
Current limiting / boost: delivers peak current and controls rail collapse; may clamp during repeats.
Driver device: transistor or dedicated IR driver determines pulse edges and peak delivery.

Range & Angle Symptoms (evidence-driven diagnosis)

Near OK, far fails: usually IR_PULSE amplitude is low or droops under load → compare IR_PULSE + TP_VBAT during a standard command.
Angle-sensitive failure: LED optics + enclosure shadowing reduce margin → test with controlled pose while logging IR_PULSE stability.
Fast repeat drops codes: boost/current-limit clamps or rail does not recover → observe IR_PULSE decay across repeat presses.

Burst Repetition, Rail Recovery, and Thermal Drift

Repeat pressing increases average load: peak delivery may clamp, reducing IR_PULSE amplitude.
Insufficient recovery time: supply capacitors and boost loop may not recharge between bursts.
Thermal rise: LED intensity can drop and driver resistance can change, reducing margin over time.

Evidence anchors

IR_PULSE vs time: track pulse amplitude across 10–20 repeats
I_PEAK stability: detect clamp onset
TEMP_LED: temperature rise during dense usage

Eye-Safety Boundary (engineering controls)

Bound peak and duty: cap maximum drive settings to prevent extreme optical output.
Bound continuous transmit: limit maximum continuous burst window; enforce cool-down if needed.
Thermal-aware derating: reduce drive when TEMP_LED rises beyond a safe threshold.

This is an engineering boundary section, not a regulatory tutorial.

Figure F6. IR subsystem evidence chain. Preserve IR pulse integrity and deliver peak current without VBAT collapse. Diagnose range/angle/repeat failures using IR_PULSE, I_PEAK, VBAT droop, and TEMP_LED probes.

Reuse tip: cite as “ICNavigator, Smart Remote Figure F6 (IR Subsystem Evidence Chain)”. Cite this figure →

H2-7 · Voice Front-End

Voice Front-End: Mic AFE, PDM/I2S, Noise, AGC, and “Always-On” Reality

Voice remotes succeed or fail at the front-end. The hard problems are measurable: noise floor, SNR, clipping, pop/click events, and the “always-on” cost (mic bias, clocks, DMA/buffers, and wake-word windows). This section stays at device front-end scope: microphone paths, evidence probes, and power/EMI realities.

Two Mic Paths (Analog + AFE vs Digital PDM)

Analog mic + AFE: bias + gain chain is controllable; vulnerable to rail ripple and ground return injection.
Digital mic (PDM): better immunity to analog pickup; risks come from PDM clock edge noise and clock “always-on” leakage.
System boundary: focus on front-end integrity and evidence; avoid cloud and model-level discussions.

Evidence anchors

MIC_BIAS: bias stability and activity window
PDM/I2S stream: clock/data gating and burst windows
PRE-AEC stats: raw amplitude/peak/crest/clipping before echo canceller

Core Metrics (engineering-grade, evidence-driven)

Noise floor: baseline in a controlled “quiet” condition; compare with backlight/RF/haptics on/off.
SNR: signal level vs baseline noise; validate at near-field and typical room distance.
Clipping: saturation count/ratio in raw stream; tracks lost intelligibility and AGC mis-tuning.
Pop/click: event count and timestamp; often aligned to domain enable/clock gating transitions.
Pre-AEC dynamic range: raw amplitude headroom (peak and crest factor) before downstream processing.

“Always-On” Reality (why it inflates sleep current)

Mic bias: constant bias can dominate leakage when rails are otherwise quiet.
Clocks: PDM/I2S clocks left running create edge activity and power draw.
DMA/buffers: ring buffers and periodic DMA wakeups add housekeeping current steps.
Wake-word windows: short periodic listen windows can still build significant daily energy.

Power evidence anchors

I_AON plateau: compare with mic subsystem disabled/enabled
PDM_CLK window: measure duty and correlate to current mini-steps
Wake counter: periodic wakeups per minute during “idle”

Noise & Coupling Paths (remote scope only)

Rail ripple injection: RF bursts, backlight PWM, and haptics transients can modulate AFE noise floor.
Digital edge injection: PDM clocks and SPI bursts can inject into analog regions via ground return.
Ground return sensitivity: enclosure and hand contact can change coupling and cause intermittent events.

Diagnosis is evidence-based: correlate pop/click and clipping spikes with rail or clock windows.

AGC Boundary (no algorithm tutorial, only measurable effects)

Over-aggressive AGC: raises noise in pauses and causes “pumping”; increases crest-factor instability.
Too conservative AGC: far-field speech falls into noise floor; raises failure rate at low SNR.
Evidence: raw amplitude histogram, peak/crest factor shift, clipping count changes.

Minimum Field Evidence Set (copy/paste template)

Raw PCM snippet (short): 0.5–1.0 s, pre-AEC if possible
Noise floor: measured in “quiet” and compared with backlight/RF/haptics toggles
Peak / RMS / Crest factor: indicates headroom and dynamic range
Clipping count: saturation events per second or per snippet
Pop/click events: timestamped count; correlate with rail/clock gating transitions

Figure F7. Audio chain and evidence probes for voice remotes. Measure MIC_BIAS, DIGITAL_STREAM activity, and PRE-AEC amplitude statistics, and correlate pop/clipping with RF burst and backlight PWM windows.

Reuse tip: cite as “ICNavigator, Smart Remote Figure F7 (Audio Chain & Probes)”. Cite this figure →

H2-8 · Input & UX Hardware

Input & UX Hardware: Key Matrix, Touch, Haptics, and Backlight

Input and UX hardware frequently becomes the root cause of sleep-current inflation, false wakes, and ESD-triggered resets. Key matrices, capacitive touch, haptics drivers, and backlight PWM also create coupling paths into RF and mic front-ends. This section focuses on measurable failure modes and isolation evidence rather than feature descriptions.

Key Matrix: Pull Strategy, Ghosting, ESD Path, Debounce

Pull strategy: always-on pull-ups can dominate leakage; gate scan windows where possible and verify I_AON plateau impact.
Ghosting: matrix return paths can create phantom presses; detect via inconsistent WAKE_CAUSE patterns and scan logs.
ESD path: external key surfaces can inject into MCU IO; poor return routing leads to resets or lockups.
Debounce: longer debounce reduces false triggers but increases latency and scan energy; validate with event timing evidence.

Evidence anchors

GPIO_WAKE / WAKE_CAUSE: wake-source distribution
SCAN_WINDOW: current mini-step width and frequency
RESET_REASON: correlation after ESD events

Capacitive Touch: Baseline Drift, Ripple Sensitivity, Wet-Hand False Triggers

Baseline drift: temperature/humidity and enclosure changes shift baseline and increase false triggers.
Ripple sensitivity: backlight PWM or boost ripple can modulate thresholds; verify by toggling rails while logging baseline.
Wet-hand false triggers: leakage paths change effective capacitance; guard with evidence-driven threshold settings.

Evidence anchors

BASELINE trend: drift over time
FALSE_TRIG count: triggers per hour in controlled conditions
THRESH jitter: threshold stability under PWM/ripple

Haptics: ERM/LRA Drivers and Power Transients

Transient load: haptics activation can create VBAT droop and rail ripple that increases RF retries or causes audio pops.
Return-path injection: driver current loops can inject ground noise into sensitive AFE regions.
Repeat patterns: frequent haptics pulses may create periodic interference windows.

Evidence anchors

TP_VBAT droop: depth + recovery time
RAIL_RIPPLE: ripple amplitude during haptics events
RF_RETRY / pop events: correlate spikes to haptics timestamps

Backlight PWM: Coupling Risk into Mic/RF (evidence + isolation only)

PWM edges: fast edges and harmonics can raise mic noise floor or increase RF retry probability.
Isolation goal: keep PWM current loops away from AFE and RF ground references; verify with toggled A/B evidence.
Validation method: compare noise floor and p95 latency with backlight on/off at the same pose.

Evidence anchors

NOISE_FLOOR delta: backlight on/off
RF retry delta: backlight on/off
p95 latency delta: tail sensitivity to PWM windows

Fast Diagnostic Loop: Leakage, False Wakes, ESD-Triggered Resets

Sleep current ↑: disable UX blocks one-by-one and observe I_AON plateau change.
False wake ↑: review WAKE_CAUSE distribution (key/touch/IMU/RF/voice) to find dominant source.
Random resets: correlate RESET_REASON with ESD exposure and key/touch activity.

Figure F8. Input & UX evidence chain. Key/touch/haptics/backlight can inflate sleep current, trigger false wakes, or inject noise into RF and mic AFE. Use scan windows, baseline trends, VBAT droop, ripple, noise-floor deltas, retry spikes, WAKE_CAUSE, and RESET_REASON to close the loop.

Reuse tip: cite as “ICNavigator, Smart Remote Figure F8 (Input & UX Evidence Chain)”. Cite this figure →

H2-9 · Power Tree & Energy Management

Power Tree & Energy Management: Buck/Boost/LDO, Load Switch, Brownout Proofing

A smart remote is a power-domain product: an ultra-low AON (always-on) base with short, high-current burst domains (RF, IR, Audio). Robust energy management is proven with evidence—UVLO flags, reset reasons, rail droop depth and recovery time, and peak-current snapshots—rather than assumptions.

Why Split Domains (AON vs Burst)

AON domain: retention/RTC/wake logic must stay stable at the lowest possible plateau current.
Burst domains: RF, IR boost, and audio front-end should be switched on only when needed.
Failure mode: no domain split inflates sleep current; weak domain control causes brownout resets during peaks.

Power Tree Backbone (remote-scale, evidence-ready)

Battery → Protection: reverse/short/over-current protection with minimal drop.
Main conversion: buck/boost/LDO chosen for light-load efficiency and low quiescent current.
AON rail: stable base rail with verified plateau current.
Load switch rails: switch burst domains (RF / Audio / IR boost) with controlled inrush and low off-leakage.

Key Component Classes (explained by remote needs)

Buck: efficient main rail at light load; verify Iq and light-load efficiency with AON plateau evidence.
Boost: supports IR peak current or special rails; verify peak-current headroom and recovery time under bursts.
LDO: isolates noise-sensitive audio/reference rails; verify noise-floor delta and ripple attenuation in burst conditions.
Load switch: domain gating; verify off-leakage, soft-start behavior, and droop during enable transitions.
Battery protection: avoids destructive faults; ensure low drop and predictable behavior under pulse loads.
Fuel gauge (optional): aligns “battery remaining” with burst capability; validate under transient loads and temperature shifts.

Brownout Proofing (IR/Voice peaks) — Patterns & Evidence

IR peak: short high-current pulses can create deep VBAT droop → IR range loss, fast-repeat drop, or resets.
Voice peak: audio + RF burst overlap widens current steps → tail-latency spikes, pops/clicks, and occasional resets.
Proof method: correlate droop depth + recovery time with UVLO/reset logs and peak-current snapshots.

Minimum brownout evidence set

UVLO flag / power-good: converter or supervisor indicators
RESET_REASON: brownout vs watchdog vs pin reset
RAIL_DROOP: TP_VBAT + key rails (AON / Audio / IR boost)
I_PEAK: peak current during IR/voice/RF bursts

Countermeasures (remote-scale) — Tie Each Fix to Evidence

De-conflict bursts: avoid IR + voice + RF peak overlap; confirm with narrower combined current steps.
Soft-start / current limit: tame inrush on burst rails; confirm droop is shallower and recovery is faster.
AON priority: preserve AON stability during bursts; confirm AON rail stays inside margin while burst rails move.
Peak headroom: ensure IR boost and switches sustain peak current; confirm with I_PEAK evidence under worst case.

One-Minute Field Triage

Step 1: check RESET_REASON concentration (brownout vs others).
Step 2: capture TP_VBAT while triggering IR repeat and voice session.
Step 3: compare “IR only” vs “IR + RF” vs “Voice + RF” droop depth and recovery time.

Figure F9. Power tree and probe points for domain management. Use TP_VBAT, TP_3V3_AON, TP_1V8_AUD, TP_BOOST_IR plus UVLO/RESET_REASON/I_PEAK to prove brownout root cause and validate fixes.

Reuse tip: cite as “ICNavigator, Smart Remote Figure F9 (Power Tree + Probes)”. Cite this figure →

H2-10 · Selection Guide (BOM-Level)

Selection Guide (BOM-Level): MCU, Wireless, Mic AFE, Power — Evidence-Driven Choices

Component selection should close a measurable loop: targets → evidence → gate thresholds → pick. The goal is to choose MCU, wireless, audio front-end, and power parts that hit sleep-current, voice SNR, IR peak-current, and RF retry/latency constraints without turning this page into a procurement list.

Evidence-Driven Selection Inputs (targets) → Outputs (proof)

Sleep target: plateau current (I_AON) and wake-source distribution (WAKE_CAUSE).
Voice target: noise floor, peak/crest factor, clipping count in pre-AEC raw stream.
IR target: I_PEAK capability and TP_BOOST_IR / TP_VBAT droop depth + recovery time.
Wireless target: retry ceiling and latency tail (p95) under coexistence and hand-block conditions.

MCU (ULP + wake + concurrency)

Requirement: ultra-low AON plateau, reliable wakes, and enough headroom for RF + audio windows without inflating housekeeping.

Key metrics: standby/retention current, wake latency, peripheral gating, RAM/flash headroom, DMA behavior.
How to validate: I_AON plateau in real idle, WAKE_CAUSE distribution, current mini-steps during scan/audio windows.
MPN examples (directional): ULP BLE-capable MCU/SoC families, ULP MCU families with strong sleep + wake; choose by measured plateau and window cost.

Wireless (BLE / Proprietary RF)

Requirement: stable user-perceived response (p95 tail control) and bounded retries without overspending energy.

Key metrics: retry behavior, reconnect time, latency p50/p95, RSSI margin under hand block, coexistence sensitivity.
How to validate: retry counter, latency histogram, RSSI trend vs pose; measure burst-width growth in weak conditions.
MPN examples (directional): BLE SoC families; proprietary 2.4 GHz transceiver families (choose by tail-latency and retry ceiling evidence).

Audio (Mic AFE / Digital Mic PDM)

Requirement: meet voice SNR targets with controlled clipping and minimal pop/click under burst coupling.

Key metrics: noise floor, dynamic range, bias current, PDM/I2S gating capability, susceptibility to PWM/RF coupling.
How to validate: pre-AEC raw snippet stats (peak/crest/clipping), noise floor delta with backlight/RF/haptics toggles.
MPN examples (directional): digital PDM mic families; analog mic AFE families (select by measured noise floor + always-on cost).

Power (Buck/Boost/LDO / Load Switch / Gauge)

Requirement: low quiescent current at idle, stable rails under IR/voice peaks, and predictable brownout behavior.

Key metrics: Iq, peak current capability, soft-start/inrush control, UVLO/PG visibility, off-leakage of load switches.
How to validate: TP_VBAT droop depth + recovery time, RESET_REASON and UVLO flags, I_PEAK under worst-case bursts.
MPN examples (directional): low-Iq buck families; pulse-capable boost families; low-leak load switch families; optional fuel gauge families.

Figure F10. Evidence-driven selection loop. Define targets, capture evidence, apply gates, and then pick MCU/wireless/audio/power parts using measurable thresholds rather than spec-sheet averages.

Reuse tip: cite as “ICNavigator, Smart Remote Figure F10 (Selection Loop)”. Cite this figure →

H2-11 · Validation & Field Debug Playbook

Validation & Field Debug Playbook: Symptom → Evidence → Isolate → Fix

This SOP turns “remote feels unreliable” into a repeatable workflow. Each symptom is handled with: First 2 measurements (fast capture) → Discriminator (one decisive proof) → First fix (the first action to validate).

MPN policy: Part numbers below are concrete, representative examples (directional BOM hints). Final choice must match voltage, peak current, footprint, and measured evidence.

Minimum Evidence Toolkit (Remote-Scale, Field-Friendly)

Rails: TP_VBAT, TP_3V3_AON, TP_1V8_AUD, TP_BOOST_IR (droop depth + recovery time).
Logs: RESET_REASON, WAKE_CAUSE, UVLO/PG flags, RF retry counter, latency p95.
Audio probes: MIC_BIAS stability, PDM/I2S activity window, pre-AEC PCM stats (noise floor, clipping).
IR probes: IR pulse monitor + I_PEAK aligned with TP_VBAT droop.

Common “instrumentation-friendly” parts (optional on-board hooks):
INA219INA226MAX17048TPS3839MCP1316TPD4E1U06PESD5V0S1ULWSL2512

Examples: current monitor (INA219/INA226), fuel gauge (MAX17048), supervisor (TPS3839/MCP1316), ESD (TPD4E1U06/PESD5V0S1UL), shunt resistor family (WSL2512 series).

Symptom A — Standby current is too high (battery drains in idle)

Maps to: Sleep leakage / Always-on reality / Domain gating (H2-3, H2-4, H2-9)

First 2 measurements

I_AON plateau in true idle (display off, RF not maintained, audio clock gated).
Wake window evidence: periodic toggles (PDM_CLK / scan window) or wake counter increments.

Discriminator

Plateau vs steps: if current shows periodic steps, a burst-domain is not fully gated (clock/DMA/scan).

First fix

Enforce hard domain-off for non-AON rails using a load switch; validate a flat, lower I_AON.
Gate PDM/I2S clocks outside the voice window; validate periodic steps disappear.

MPN hints (low-Iq + gating):
TPS22910ATPS22916TPS62840TPS62841MAX17048

Load switch examples (TPS22910A/TPS22916), low-Iq buck examples (TPS62840/TPS62841), fuel gauge example (MAX17048).

Symptom B — Key wake is slow or intermittently fails

Maps to: Wake design / key matrix / debounce / ESD path (H2-4, H2-8)

First 2 measurements

GPIO_WAKE edge at MCU pin (confirm the edge arrives when the key is pressed).
WAKE_CAUSE + wake latency timestamp (edge → command send) to locate the delay segment.

Discriminator

Edge present but WAKE_CAUSE missing points to pin/ESD/leak/threshold issues, not “scan timing”.

First fix

Promote critical wake paths to true interrupt/wake-capable pins; shorten scan duty-cycle only after proof.
Strengthen ESD return path at exposed key lines; validate reduced false/failed wakes after ESD stress.

MPN hints (ESD + supervisor):
TPD4E1U06TPD2E001PESD5V0S1ULTPS3839MCP1316

ESD protection examples (TPD4E1U06/TPD2E001/PESD5V0S1UL), reset supervisor examples (TPS3839/MCP1316).

Symptom C — Voice is noisy, choppy, or recognition quality is poor (hardware angle)

Maps to: Mic front-end / always-on traps / coupling (H2-7, H2-8, H2-9)

First 2 measurements

MIC_BIAS + TP_1V8_AUD ripple during voice window (look for burst-correlated noise).
PDM/I2S activity window (clock/data continuity; detect gaps or frame loss).

Discriminator

Pre-AEC PCM stats (noise floor delta, clipping count) that correlate with backlight PWM or RF bursts proves coupling.

First fix

Isolate coupling sources first: shift/soften backlight PWM edges, de-conflict RF bursts from voice window, verify noise floor drops immediately.
Harden the audio rail: separate/load-switch burst rails and validate lower ripple at TP_1V8_AUD.

MPN hints (digital mic / analog AFE examples):
ICS-41350SPH0645LM4H-1MAX9814TLV320ADC3101TPS73618

Digital mic examples (TDK ICS-41350, Knowles SPH0645LM4H-1), analog mic AFE example (MAX9814), audio ADC/AFE example (TLV320ADC3101), low-noise LDO example (TPS73618).

Symptom D — IR works at short range but fails at long range

Maps to: IR driver integrity / peak current / droop (H2-6, H2-9)

First 2 measurements

TP_BOOST_IR + TP_VBAT droop (depth + recovery) under single press and fast-repeat presses.
IR pulse monitor (timing stability + pulse amplitude proxy) aligned to droop events.

Discriminator

Deep droop with stable pulse timing indicates peak-power limitation (boost/switch/current limit), not “protocol”.

First fix

Increase peak headroom: boost peak capability + storage + switch path; prove with shallower droop and higher repeatable I_PEAK.
Stabilize pulse integrity via proper driver device and layout; prove with consistent pulse shape across repeats.

MPN hints (IR LED / boost / switch examples):
TSAL6400SFH 4545TPS61023TPS61291AO3400AMMBT2222A

IR LED examples (Vishay TSAL6400, OSRAM SFH 4545), boost examples (TPS61023/TPS61291), small switch device examples (AO3400A MOSFET, MMBT2222A BJT).

Symptom E — RF disconnects often, reconnect is slow, packets are lost

Maps to: Link strategy evidence chain (H2-5) + power/domain interactions (H2-9)

First 2 measurements

Retry counter + latency histogram (p50/p95) during real usage poses.
RSSI trend versus hand block / distance / orientation (simple repeatable poses).

Discriminator

RSSI stable but p95 tail grows indicates strategy/burst contention; RSSI drop + retries spike indicates margin/antenna/coexistence.

First fix

Tail-first tuning: adjust “keep connected vs fast reconnect” strategy and scheduling to cap p95 and retries; prove with improved histogram and lower burst width.
Protect RF rail from IR/Audio peaks; prove with reduced retries during peak events.

MPN hints (BLE SoC / 2.4G examples):
nRF52832nRF52840CC2642REFR32BG22CC2500

BLE SoC examples (Nordic nRF52832/nRF52840, TI CC2642R, Silicon Labs EFR32BG22). Proprietary 2.4G example (TI CC2500).

Symptom F — Reboot/lockup during rapid key repeats (brownout / ESD suspects)

Maps to: brownout proofing + ESD pathways (H2-9, H2-8)

First 2 measurements

RESET_REASON + UVLO/PG flags around the event (log or sticky registers).
TP_VBAT droop aligned with IR/RF/backlight/haptics triggers during repeat presses.

Discriminator

RESET_REASON=brownout with synchronized droop proves peak-power contention; abnormal reset patterns under ESD exposure indicates protection/return-path issues.

First fix

De-conflict peaks: prevent IR + RF + backlight/haptics from overlapping; validate fewer resets and shallower droop.
Harden exposed lines with proper ESD parts and return path; validate improved behavior after ESD stress.

MPN hints (supervisor / e-fuse / ESD / load switch examples):
TPS3839MCP1316TPS2595TPD4E1U06TPS22916

Supervisor examples (TPS3839/MCP1316), eFuse example (TPS2595), ESD example (TPD4E1U06), load switch example (TPS22916).

Figure F11. Field-debug SOP flow: each symptom maps to two fast captures, one decisive discriminator, and one first fix. Evidence tags unify power, wake, RF, IR, and audio debugging.

Reuse tip: cite as “ICNavigator, Smart Remote Figure F11 (Field Debug SOP)”. Cite this figure →

Request a Quote

Name

Company

Part Number(s) / BOM

Quantity & Target Lead Time

Alternates Allowed

Temperature Grade

Package / Footprint

Compliance

Budget Window

Lot Size / Qty

Message

Attachment

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

H2-12 · FAQs ×12

FAQs: Evidence-First Troubleshooting for Smart Remotes

Each answer stays inside the smart-remote evidence chain: low-power MCU, BLE/IR/RF, mic AFE, energy domains, and validation/field proof. Every question includes two fast captures, one decisive discriminator, and one first fix.

Power I_AON · TP_VBAT · UVLO Wake WAKE_CAUSE · GPIO_WAKE RF RSSI · retry · p95 Audio MIC_BIAS · PCM stats IR TP_BOOST_IR · IR pulse

1) Battery drops fast even with light use — which two current evidence points first?

What it usually is

The root cause is almost always either (a) an elevated idle baseline (something never fully turns off), or (b) a few high-energy bursts (voice/RF retries/IR peak) whose “area under the curve” is larger than expected.

First 2 captures

I_AON plateau in true idle (screen/RF maintain/audio clocks fully gated).
Event charge: capture one typical voice or IR action and integrate current × time (burst width + peak).

Discriminator

Flat high plateau → idle leakage; short low plateau but huge event area → burst math error or retries.

First fix

Hard-gate burst rails with a load switch and verify I_AON drops; then cap burst width (retry limit / voice window discipline) and re-measure event area.

MPN examples: INA226INA219TPS22916TPS62840MAX17048

Maps to: H2-3, H2-9

2) Standby current looks low, yet battery dies in weeks — is burst averaging wrong?

What it usually is

Most “weeks-to-empty” surprises come from tails, not averages: RF retry storms that stretch bursts, voice sessions that run longer than assumed, or an “almost-always-on” mic bias/clock that quietly raises the baseline.

First 2 captures

Counts: voice_session_count + RF_retry_count (or equivalent event counters) per day.
Duration distribution: burst width p50/p95 (voice window length, reconnect time), not mean.

Discriminator

p95 burst width ≫ expected (tail dominates energy) even if the idle plateau is fine.

First fix

Enforce hard limits (max retries, reconnect budget, voice window cap) and prove with reduced p95 width and lower “daily burst area”.

MPN examples: nRF52832CC2642REFR32BG22MAX17048

Maps to: H2-3

3) Key sometimes fails to wake — GPIO leakage/ESD or matrix scan strategy? What evidence separates them?

What it usually is

Intermittent wake failures split into two buckets: a physical wake path issue (leakage/ESD clamp/threshold/return path), or a timing policy issue (scan duty-cycle, debounce window, or domain power-up gating).

First 2 captures

GPIO_WAKE edge at the MCU pin during the failed press (edge present or not).
WAKE_CAUSE (sticky register/log) aligned with the same press.

Discriminator

Edge present but WAKE_CAUSE missing → pin/ESD/leak/threshold. No edge → matrix/scan or wiring path.

First fix

Promote critical keys to true wake-capable pins (interrupt wake) and harden exposed lines with proper ESD + return path; re-run ESD/press stress and verify wake error rate drops.

MPN examples: TPD4E1U06TPD2E001PESD5V0S1ULTPS3839

Maps to: H2-4, H2-8

4) Voice turns on and noise jumps — mic AFE issue or power-ripple coupling? Which two waveforms first?

What it usually is

If noise rises only when other subsystems are active, it is often coupling (backlight PWM edges, RF bursts, haptics) rather than “bad mic”. The fastest proof is correlation between audio metrics and rail ripple/event windows.

First 2 captures

TP_1V8_AUD ripple (or the audio rail) + MIC_BIAS stability during voice.
Pre-AEC PCM stats: noise floor delta and clipping count while toggling backlight/RF/haptics.

Discriminator

Noise floor tracks PWM/RF windows → coupling; noise floor constant but clipping changes → gain/DR biasing.

First fix

De-conflict scheduling (avoid RF/IR peaks during capture) and harden the audio rail (low-noise LDO / domain isolation); verify immediate noise-floor drop.

MPN examples: ICS-41350SPH0645LM4H-1TLV320ADC3101TPS73618

Maps to: H2-7, H2-9

5) Voice sometimes becomes choppy — check RF retries first or audio buffer underrun?

What it usually is

Choppiness is either transport jitter (retries/latency tails) or local stream continuity (PDM/I2S gaps, DMA starvation, buffer underruns). The key is to capture one RF metric and one audio continuity metric in the same window.

First 2 captures

RF retry counter + latency p95 during the voice window.
PDM/I2S continuity or an underrun counter (buffer/DMA logs) during the same window.

Discriminator

Audio stream continuous but retries/p95 explode → RF; underruns/gaps exist even with stable RF → local scheduling/clocking.

First fix

Cap RF tail (retry limits, reconnect budget) if RF is guilty; otherwise prioritize audio DMA/buffer sizing and clock gating discipline and prove “no gaps” in continuity logs.

MPN examples: nRF52840CC2642REFR32BG22

Maps to: H2-5, H2-7

6) IR works nearby but fails far away — peak drive not enough or modulation distortion? How to measure?

What it usually is

Long-range failures come from either insufficient peak optical power (current limit/droop) or pulse integrity issues (modulation timing/driver saturation). Measuring only IR timing is not enough; peak current and rail droop must be aligned.

First 2 captures

TP_BOOST_IR and TP_VBAT droop (depth + recovery) during single press and fast repeats.
IR pulse monitor (pulse width / duty / stability) aligned with the droop event.

Discriminator

Deep droop with stable pulse timing → peak headroom issue; stable rails with unstable pulse widths → driver/modulation integrity.

First fix

Increase peak headroom (boost peak capability + switch path + local storage) or stabilize the driver chain; prove by shallower droop and repeatable pulses.

MPN examples: TSAL6400SFH 4545TPS61023TPS61291AO3400A

Maps to: H2-6

7) Remote reboots on rapid presses/long press — brownout or watchdog? How to capture all evidence at once?

What it usually is

The fastest split is brownout vs watchdog using reset cause plus rail droop alignment. Many “random resets” are peak-contention events: IR + RF + backlight/haptics overlapping.

First 2 captures

RESET_REASON (brownout/WDT/pin reset) plus any UVLO/PG flags if available.
TP_VBAT droop aligned with event GPIOs (IR burst, RF TX, backlight PWM enable, haptics enable).

Discriminator

Brownout flag + synchronous droop → power peak; no droop but WDT resets → scheduling/lockup evidence path.

First fix

De-conflict peaks (avoid overlapping domains) and add brownout-proofing (domain isolation / soft-start / supervisor); prove by reset-count drop and shallower droop.

MPN examples: TPS3839MCP1316TPS22916TPS2595

Maps to: H2-9, H2-11

8) RF gets worse in certain grip/angles — antenna issue or PA/RF rail droop? How to validate?

What it usually is

Grip sensitivity is typically either link margin (antenna detuning/body blocking) or power-domain interaction where IR/voice peaks cause RF rail droop and retries. Separating them needs one RF metric and one rail metric captured in the same pose.

First 2 captures

RSSI trend across repeatable poses (open hand vs tight grip) plus retry count.
TP_VBAT (or RF rail if exposed) droop aligned to RF TX events under the same poses.

Discriminator

RSSI drops with no rail change → antenna/body; retries spike with rail droop → domain/peak contention.

First fix

Improve margin (antenna placement/ground keepout) if RSSI-driven; otherwise isolate RF burst domain and de-conflict peaks; prove by retry reduction in the problematic pose.

MPN examples: nRF52832CC2642RTPS22916TPS62840

Maps to: H2-5, H2-9

9) Adding backlight/haptics suddenly increases standby current — where is the most common leakage path?

What it usually is

Standby jumps after adding peripherals usually means a domain that never truly powers down (PWM still toggling, driver bias not gated, or a pull-up path through the driver/ESD structures). The key is distinguishing a constant plateau raise vs periodic steps.

First 2 captures

I_AON plateau before/after enabling backlight/haptics feature.
Enable/PWM activity in idle (backlight PWM pin, haptics enable) or load-switch EN state.

Discriminator

Periodic current steps matching PWM/window → gating failure; constant plateau raise → shutdown leakage or pull-ups/ESD path.

First fix

Hard-gate backlight/haptics rails (load switch) and stop PWM in idle; prove by removing steps and lowering I_AON plateau.

MPN examples: TPS22910ATPS22916DRV2605L

Maps to: H2-8, H2-3

10) Passes lab ESD tests, but still freezes in the field — return path issue or reset pin sensitivity? Evidence approach?

What it usually is

Field freezes after ESD-like events are often either (a) return-path problems causing rail upset/brownout, or (b) an overly sensitive reset pin (noise injection / insufficient filtering). The quickest proof is reset-cause statistics and the “most-triggering” touch point.

First 2 captures

RESET_REASON distribution (pin reset vs brownout vs WDT) across repeated stress attempts.
Touch-point correlation: which exposed line/area triggers the event most often (key bezel, metal ring, battery door, etc.).

Discriminator

Pin-reset dominated → reset pin sensitivity; brownout dominated → return-path/rail upset.

First fix

Add proper ESD clamps and controlled return path near the entry point, and harden reset pin filtering; prove by reduced event rate and a shift in reset-cause statistics.

MPN examples: TPD4E1U06PESD5V0S1ULTPS3839MCP1316

Maps to: H2-11

11) Pairing is always slow — optimize connection parameters first, or check RSSI/retries first?

What it usually is

Pairing slowness is either a margin issue (low RSSI → retries → long tails) or a strategy issue (reconnect window/timeout behavior creating large p95). Evidence should decide before any parameter tuning.

First 2 captures

Pairing latency distribution (p50/p95), not a single “typical” time.
RSSI + retry counter during the same pairing attempts.

Discriminator

Low RSSI with high retries → fix margin first; normal RSSI but long p95 tails → fix strategy/scheduling first.

First fix

Address the dominant cause and re-measure the p95 tail: improve margin (placement/keepout) or tighten retry/time budgets; prove with histogram improvement.

MPN examples: nRF52832CC2642REFR32BG22

Maps to: H2-5

12) Swapping coin-cell to AAA makes it less stable — what power/impedance assumption is wrong?

What it usually is

If AAA “gets worse”, the chemistry is rarely the true culprit; it is commonly contact resistance, protection-path voltage drop, or a burst-domain peak that was tuned around a different impedance profile. The proof is droop depth + recovery time under the same IR/voice stress.

First 2 captures

TP_VBAT droop (depth + recovery) under identical IR burst and voice burst patterns.
RESET_REASON / UVLO flags aligned to those bursts (to confirm brownout vs other reset causes).

Discriminator

Deeper droop with AAA strongly suggests contact/path resistance or current limiting, not “AAA is weaker”.

First fix

Reduce series drop (contacts, protection, switch path) and add peak headroom on burst rails; prove by shallower droop and fewer brownout resets.

MPN examples: TPS22916TPS61023TPS3839TPS62840

Maps to: H2-3, H2-9

Figure F12. FAQ evidence map: domains (AON/RF/IR/Audio) and the probe set used to answer and validate each FAQ quickly.

Reuse tip: cite as “ICNavigator, Smart Remote Figure F12 (FAQ Evidence Map)”. Cite this figure →