H2-3. Sensor Modality & Selection (Why wet/dry/glove behaves differently)

Selection principle: Stability across wet fingers, dry cracks, low temperature, or gloves is primarily a SNR + failure-mode problem. Modality choice and matrix sizing must be justified by measurable outcomes: quality codes, retry counts, and FAR/FRR under controlled finger-condition sweeps.

A. Use one common comparison coordinate (signal → noise → failure)

• Signal source: what physical contrast is measured (capacitance / reflectance / acoustic impedance).
• Noise sources: what degrades that contrast (contact variation, ambient light, coupling/temperature/packaging).
• Failure modes: how the degradation presents in logs (low quality, saturation, drift, high retries).

B. Modality notes (engineering-level, not marketing)

• Capacitive: strong when skin contact is consistent; weak when dielectric/contact changes dominate (dry cracks, gloves, thick cover). Watch for baseline drift and contact-driven SNR collapse.
• Optical: relies on illumination uniformity and surface cleanliness; weak when ambient light or contamination reduces ridge/valley contrast. Watch for low-contrast frames and stray light artifacts.
• Ultrasonic: can tolerate certain surface conditions better; sensitive to coupling stack, temperature drift, and mechanical packaging consistency. Watch for coupling-related attenuation and temperature-dependent offsets.

C. Matrix size / resolution / frame rate → FAR/FRR behavior

• Matrix size: increases usable features and tolerance to partial contact/offset; typically reduces FRR in marginal fingers but may increase cost/power/scan time.
• Resolution: improves separability until the chain becomes noise-limited; beyond that point, higher resolution mostly amplifies noise and processing load rather than adding reliable features.
• Frame rate & capture strategy: higher rate helps motion/placement variability (shorter time-to-decision), but can stress AFE settling and power rails; multi-frame fusion can lower FRR without raising FAR if the quality gate is strict.

D. Cover material, ESD, contamination constraints (what must be specified)

• Cover stack: thickness/material affects coupling (capacitive/ultrasonic) and surface optics (optical). Treat as a design input, not an afterthought.
• ESD return path: define where discharge energy goes; if it enters the AFE reference or scan lines, expect post-ESD instability even when lab tests “pass”.
• Contamination: distinguish instant failures (low contrast) from slow drift (baseline shifts). Logs must separate these with quality codes and trend counters.

E. Evidence deliverable: “failure-rate matrix” template (device-local)

Each cell should be populated from repeated attempts per condition (not single trials). Use the same enrollment set and threshold policy during the sweep.

H2-4. Fingerprint AFE Deep Dive (Excite, amplify, sample, noise budget)

Goal: map “false accepts / high rejects / all-black or all-white frames / slow drift / post-ESD instability” to measurable circuit evidence. Each symptom must be isolatable using a minimal set of test points and counters.

A. Excitation & scan timing (what must be stable)

• Excitation waveform must be repeatable across rows/columns; jitter or amplitude sag directly lowers contrast and inflates retries.
• Scan-to-sample alignment must ensure AFE settling before ADC capture; misalignment commonly appears as stripes/texture artifacts.
• Evidence: correlate capture quality drops with TP_EXCITE amplitude/phase drift during a burst.

B. Input protection & ESD return path (why “passes lab” still fails in field)

• ESD energy path must avoid injecting into AFE reference, scan lines, or bias networks; otherwise expect long-tail instability and intermittent lockups.
• Protection capacitance is not “free”: added C can reduce effective signal contrast (especially for capacitive sensing).
• Evidence: compare post-ESD capture: baseline shift, increased low-frequency noise, and abnormal I²C/SPI error counts (if the sensor is digital after AFE).

C. Noise budget (the four buckets that explain most “noisy images”)

• kT/C & bandwidth noise: set by sampling capacitance and front-end bandwidth; appears as broadband grain and raises the quality gate threshold.
• 1/f & slow drift: shows up as baseline wander and condition-dependent FRR (often worse at low temperature or after contamination).
• Coupled noise: RF TX bursts, backlight PWM, touch scan, DC/DC switching; diagnose via correlation (noise grows only when aggressor toggles).
• Reference movement: VREF ripple or bias drift can masquerade as “sensor problem”; always check TP_VREF alongside AFE output.

D. ADC dynamic range, saturation, and calibration boundaries

• Saturation must be detectable (counter/flag). “All-white/all-black” frames typically correspond to saturate states or reference collapse.
• AGC / offset correction can stabilize amplitude and centering, but cannot recover lost information when the chain is noise-limited or clipped.
• Evidence: track saturation counter, VREF stability, and AGC/offset trajectories across temperature and finger conditions.

E. Minimal test-point set (TP) for field isolation

• TP_EXCITE: excitation amplitude and timing stability.
• TP_AFE_OUT: noise RMS, drift trend, clipping/rail hits.
• TP_ADC_IN (if accessible): verify front-end headroom and settling.
• TP_VREF: ripple, load steps, and post-ESD bias shifts.

F. Fast mapping (symptom → discriminator → first fix)

• High FRR only on wet fingers: discriminator = quality code drop + AFE contrast collapse; first fix = tighten quality gate + verify excitation stability and cover stack behavior.
• “All black/white” intermittently: discriminator = saturation counter spikes + VREF event; first fix = increase headroom / improve reference decoupling / confirm scan timing.
• Drift over hours/days: discriminator = baseline trend in TP_AFE_OUT vs temperature; first fix = bias stabilization + slow recalibration policy (without touching templates).

H2-5. Image/Feature Pipeline & Matching (Score distribution, thresholds)

Why scores drift: match_score stability depends on (1) capture quality, (2) pre-processing staying within its “repair boundary”, and (3) a threshold policy aligned with the genuine vs impostor score distributions under real finger conditions. This chapter keeps the discussion device-local: quality gates, score histograms, reject reasons, and retry patterns.

A. End-to-end chain (capture → quality gate → feature → score → decision)

• Capture quality gate first: if the input is noise-limited, no amount of post-processing can reliably recover discriminative detail.
• Feature stability second: the same user should produce a tight “genuine” distribution when quality is within spec.
• Threshold last: decision threshold must sit between the genuine and impostor distributions; a single fixed threshold often fails across wet/dry/low-temp.

B. Pre-processing boundary (what it may fix vs what it must not hide)

• Permitted fixes: mild denoise, local equalization, fixed-pattern removal, sparse bad-pixel mapping, gentle ridge enhancement.
• Do not mask hardware faults: AFE saturation, reference collapse, scan timing misalignment, large-area contamination, baseline drift after ESD.
• Practical rule: if processing “improves” the image but reject_reason and retry_count remain abnormal, the root cause is upstream (H2-3/H2-4 evidence).

C. Match score distributions and FAR/FRR trade-off (how to read the histogram)

• Genuine scores: same user vs enrolled template. Expect a cluster at higher scores when quality is good; drift/widening indicates unstable capture.
• Impostor scores: different users. Expect a low-score cluster; overlap with genuine scores is what drives FAR.
• Threshold position: raising threshold typically reduces FAR but increases FRR; lowering threshold does the opposite. The correct threshold is the one that meets the required FAR while keeping FRR acceptable under target conditions.

D. Evidence: “reject reasons” and “retry patterns” (make every failure explainable)

Use short enumerations so every reject maps to a measurable cause and a chapter evidence chain.

E. Lightweight liveness (engineering boundary)

• Scope: fingerprint-only, device-local checks that add friction to static spoofing without requiring heavy models or cross-modal fusion.
• Integration rule: liveness is an additional reject reason, not a replacement for template encryption or anti-replay.
• Safety rule: if liveness_fail spikes under wet/low-temp, treat it as a tuning/quality-gate issue to avoid usability collapse.

H2-6. Template Security Model (Encryption, key ownership, anti-clone)

Security objective: templates must not be readable, exportable, clonable, or replayable. The enforceable boundary is device-local: secure boot checkpoints, key ownership in a Secure Element (SE), wrapping, attestation, counters/nonces, and auditable template versioning.

A. Template export policy (the first question auditors ask)

• Default stance: template export is disabled. If export exists (service/backup), it must require explicit authorization and produce a wrapped blob only.
• No plaintext on bus: templates must not appear as plaintext over debug ports or field interfaces.
• Evidence: export path audit record + template blob format (encrypted + versioned + integrity protected).

B. Key ladder (device-unique → wrap key → session key)

• Device-unique key (DUK): bound to the device/SE; not readable; used as the root for wrapping.
• Wrap key: encrypts (wraps) the template blob for storage; supports rotation without re-enrolling users if designed with a re-wrap mechanism in SE.
• Session key: protects per-transaction operations (e.g., MAC/sign) to reduce long-term key exposure and enable anti-replay.

C. Anti-clone (why copying flash should not work)

• Binding rule: a template blob encrypted under device-owned keys is useless on another device.
• Attestation rule: template operations should require SE attestation (device state OK, rollback counter OK) before unwrap/match.
• Evidence: attestation result field logged during enroll/verify or during key use (pass/fail + reason).

D. Anti-replay (counter/nonce/signature — device-local only)

• Nonce/challenge: each verification session uses a fresh nonce; responses are authenticated (MAC/signature) using a session key.
• Monotonic counter: stored in SE or protected storage; prevents rolling back to older states or replaying older authorization contexts.
• Evidence: counter increments + replay detection flag; secure-boot checkpoints ensure firmware/state not downgraded.

E. Template integrity and versioning (tamper visibility)

• Blob metadata: template_version + algo_version + policy_version + integrity tag (CRC/MAC).
• Rotation & erase: support secure erase (and optional rotation) with auditable event logs.
• Evidence: template CRC/version checks and failure codes; erase events stored in an append-only local log (device-local).

H2-7. Secure Element / TEE Integration (Make SE non-cosmetic)

Goal: prevent “keys/templates dumped” and “board swap breaks rollback protection” by enforcing a hard trust boundary: keys never leave SE/TEE, template wrap/unwrap happens only in trusted code, and monotonic counters are stored in non-rollbackable protected storage.

A. Responsibility split (SE vs MCU) — the boundary must be testable

• SE/TEE MUST own: device identity, device-unique key root, template wrap/unwrap, attestation, monotonic counter.
• MCU MUST own: enroll/verify state machine, policy (when to allow operations), UI prompts, retries/lockout, local logging.
• Red-line rule: plaintext templates and long-term keys must not appear in normal RAM, debug ports, or field interfaces.

B. Command channel (I2C/SPI) and the “no-secret-on-the-bus” rule

• Transport: MCU issues signed/authorized commands; SE returns status + wrapped blobs only.
• Data types allowed outside SE: template_blob (wrapped), attestation_result, policy/version metadata, failure codes.
• Data types forbidden outside SE: device private keys, plaintext template, raw key ladder material.

C. Monotonic counter placement (rollback protection that survives power loss and cloning)

• Where it lives: inside SE or protected non-rollbackable storage; never in MCU flash where images can be rolled back.
• What it gates: firmware accept, key usage, template unwrap, and any privileged export/maintenance operation.
• What to log: expected_counter vs observed_counter, rollback_detected flag, deny_reason code.

D. Board swap / field replacement (rebind policy that does not brick devices)

• When MCU changes but SE stays: require secure rebind (attestation + policy match + counter continuity) before enabling unwrap/match.
• When SE changes: device identity changes; templates wrapped for the old SE must become unusable by design (re-enroll required).
• Evidence metric: successful recovery rate after controlled board swap tests and clear failure codes when recovery is rejected.

E. Debug states (dev → production lock) — enforceable and auditable

• State model: define dev / test / production. Production state disables sensitive reads and requires signed updates.
• Lock proof: readback of lock state (fuse/secure state register) is recorded in manufacturing log.
• Field service boundary: allow health diagnostics and signed firmware update; disallow any template/key extraction path.

H2-8. Touch Display & HMI (Touch noise, ESD black screen, coupling paths)

Goal: eliminate “ghost touch”, “I2C lockups”, and “ESD black screen” by separating HMI into three domains (touch, display, backlight), then controlling power/ground reference and ESD return paths. Every failure must map to counters and test points.

A. Split HMI into 3 domains (touch / display / backlight)

• Touch domain: touch controller + I2C/SPI + INT/RESET. Sensitive to ground bounce and conducted noise.
• Display domain: panel interface (DSI/SPI/RGB) + reset/enable. Sensitive to ESD-induced latchup and I/O damage.
• Backlight domain: boost/constant-current driver + PWM dimming + LED strings. Primary noise injector if not contained.

B. Three coupling paths that explain most “random” HMI failures

• Power coupling: backlight switching ripple modulates HMI rails → touch baseline drifts → ghost touches.
• Interface coupling: ESD on I2C lines causes NACK/bus hang → touch freezes or spams interrupts.
• Ground/reference coupling: ESD return current takes the wrong path → reference shifts → display black / MCU reset.

C. Evidence counters to require in firmware logs (device-local)

• I2C health: NACK_count, bus_hang_count, recovery_count, max_stretch_time_us.
• Backlight health: led_current_mA, boost_ovp_flag, ocp_flag, dimming_freq_Hz.
• Touch noise: noise_metric, baseline_drift, ghost_rate_per_min, frame_drop_count.

D. Minimal 2-point isolation (fast triage without scope overload)

• Ghost touch: correlate touch_noise_metric with backlight_pwm and HMI rail ripple (TP_HMI_3V3).
• ESD black screen: distinguish “backlight still on” (TP_BL_I) vs “panel interface dead” (reset/enable/IRQ flags).
• I2C lock: detect SCL stuck low; record recovery attempts and whether ESD event preceded it.

H2-9. Connectivity & Interfaces (BLE/Wi-Fi + port-level access interfaces)

Goal: make “dropouts / slow provisioning / unstable links” explainable by hardware evidence (RF, power, antenna, coexistence) while keeping access interfaces strictly at port level (protection, isolation boundary, grounding, ESD localization).

A. Wireless evidence chain (RF / power / antenna / coexistence)

• Coexistence: Wi-Fi Tx bursts and scan/associate phases can disturb BLE through current spikes and in-band coupling.
• Power-to-RF coupling: RF_VDD droop during peak current → PER/retry increases → disconnect events.
• Antenna detune: enclosure/hand/metal shifts matching → RSSI variance rises and retry patterns become posture-dependent.
• EMI injectors: backlight switching and long interface cables can inject noise into RF ground/reference if boundaries are weak.

B. Required device-local metrics (no cloud dependency)

• RF link: rssi_min, rssi_avg, rssi_std, retry_rate, per, disconnect_reason.
• Provisioning: assoc_time_ms, scan_time_ms, auth_fail_count (reason codes only).
• Power correlation: peak_current_mA, min_rf_vdd_mV, brownout_count with aligned timestamps.

C. Port-level access interfaces (RS-485 / OSDP / Wiegand) — electrical only

• Protection chain: connector → TVS → common-mode choke/series R → transceiver → (optional) isolation barrier.
• Grounding rule: define a single reference and control return current paths; avoid ESD current crossing RF/HMI sensitive grounds.
• Isolation decision: use isolation when ground potential difference or surge environment can exceed transceiver common-mode limits.
• ESD localization: identify damage side by clamp behavior (TVS), leakage/short at connector pins, and transceiver thermal signature.

D. Minimal 2-point triage (fast, repeatable)

• Wireless dropout: measure TP_RF_VDD droop + log retry_rate/disconnect_reason at the same timestamp.
• Slow provisioning: compare assoc_time_ms against peak_current_mA (scan/associate power event).
• RS-485 instability: capture differential waveform at TP_485_A/B + check clamp/ESD stress around the connector.

H2-10. Power Tree & Low-Power Operation (domains, transients, wake state machine)

Goal: solve “high standby current / reboot on unlock event / colder weather failures” by defining power domains (RF/MCU/Sensor/HMI), capturing inrush/UVLO/brownout evidence, and enforcing a low-power state machine with measurable wake sources.

A. Domain partition (each domain must have a switch strategy and a test point)

• RF domain: BLE/Wi-Fi module + RF LDO/DC-DC; sensitive to droop during Tx peaks.
• MCU domain: MCU/MPU + storage; brownout/reset reason must be logged.
• Sensor domain: fingerprint sensor/AFE; requires clean reference and controlled ramp.
• HMI domain: touch/display/backlight; major transient and noise injector if not isolated.

B. Transients and protection (inrush → UVLO → brownout)

• Inrush: simultaneous rail enable (RF + backlight + sensor) can exceed source impedance → voltage sag → reboot.
• UVLO behavior: define UVLO thresholds and holdoff; record uvlo_flag and reset_reason.
• Brownout counters: brownout_count must align with event_id (unlock, report, scan, etc.).

C. Low-power state machine (power domains per state)

• Deep sleep: MCU retention on; RF/sensor/HMI off.
• Idle standby: MCU on; sensor periodic or interrupt-armed; RF off.
• Verify: sensor + MCU on; HMI optional; RF off.
• Report/sync: RF short-duty on; measure Tx peak current and RF_VDD droop.
• Update/maintenance: RF on longer + storage writes; requires droop margin and rollback-safe policy.

D. Evidence set (scope + logs) to make failures repeatable

• Current waveforms: startup, verify, report, HMI on/off (capture peak and average).
• Reset telemetry: reset_reason, brownout_count, min_sys_vdd_mV.
• Wake statistics: wake_source histogram (finger touch / touch / GPIO / timer).
• Cold behavior: compare min_sys_vdd and brownout_count at low temperature vs room.