H2-1. Definition & Boundary: what this module covers

This page treats the Cam-Audio Module as the capture core of smart glasses: it connects image sensor I/F + ISP/SoC + storage with mic-array + audio codec, and keeps timestamps and capture stability intact under USB 5V power disturbances.

Boundary rule (scope lock)

Only hardware evidence that changes capture fidelity is covered: link margin, buffering/latency, clock/timestamp behavior, power integrity, and storage integrity. Any topic outside the module boundary is intentionally excluded to avoid scope creep.

The five problems this page must solve (engineer-facing)

• Frame drops / stutter: burst drops, periodic drops, temperature-correlated drops, or drops triggered by hot-plug / touch.
• Pops / clicks / noise jumps: start/stop artifacts, pops during storage write, noise floor rising under load.
• A/V drift: audio gradually leads/lags video; drift changes after PLL relock, thermal rise, or resync events.
• Random reboot / reset: brownout, UVLO, or host current limit events that reset ISP/SoC or storage.
• Corrupt / truncated files: missing tail segments, CRC/ECC errors, filesystem/journal faults, retry storms.

Included vs Excluded (fast checklist)

• Included: Sensor I/F margin (CSI errors), ISP/encode buffering, storage worst-case latency, codec clocking & pop evidence, USB 5V droop/inrush, reset/UVLO counters.
• Excluded: Any end-to-end AR user experience, display optics tuning, wireless audio ecosystem design, cloud delivery, or haptics driver circuits.

H2-2. Pass/Fail metrics: turn complaints into measurable checks

Capture problems become solvable only after translating them into measurable metrics and linking each metric to a minimal evidence point (scope, counter, or log). This chapter defines the “scoreboard” used by every later section.

How this chapter is used (repeatable workflow)

• Step 1 — Name the symptom: frame drops, pops, drift, reboot, corrupt file.
• Step 2 — Pick the metric: choose a single metric that rises/falls with the symptom.
• Step 3 — Record the evidence: scope at the right point + the right counter/log in the same time window.
• Step 4 — Correlate: align timestamps across logs and waveforms (the root cause is usually the correlated one).
• Step 5 — Decide directionally: worst-case spikes matter more than averages (latency spikes, droop spikes, error bursts).

Video metrics (frame stability and link health)

• Dropped frames (burst count)
  Symptom: visible stutter or missing frames, often clustered in bursts.
  Metric: frame counter gaps per minute; burst length distribution (not just total).
  Where to measure: encoder output timestamps, frame sequence numbers, capture pipeline counters.
• CSI error count
  Symptom: intermittent video glitches, “works at 30 fps but fails at 60 fps”.
  Metric: CRC/ECC/deskew errors per time window; error bursts vs temperature/hot-plug.
  Where to measure: CSI/PHY error counters; log of link state transitions.
• ISP overflow / backpressure
  Symptom: stable link but frames still drop when load rises (HDR/NR/encode).
  Metric: FIFO/line-buffer overflow events; backpressure rate.
  Where to measure: ISP status registers; overflow interrupt counters.
• Encode underrun
  Symptom: video drops aligned with heavy CPU/storage activity.
  Metric: encode buffer underrun / emergency rate-control events.
  Where to measure: encoder logs and timestamps aligned to storage write bursts.

Audio metrics (noise, stability, and clock events)

• Noise floor shift
  Symptom: background hiss increases under certain load/conditions.
  Metric: RMS of a “silent” segment; noise-floor delta between idle and load.
  Where to measure: codec digital samples; correlate with rail noise and storage activity.
• Clip headroom / clipping flags
  Symptom: harsh distortion on loud sound, especially after gain changes.
  Metric: peak-to-RMS, clipping counters, limiter engagement (if available).
  Where to measure: codec status flags + captured waveform peaks.
• PLL unlock / relock events
  Symptom: pops/clicks or short gaps, often around hot-plug or droop.
  Metric: PLL lock-loss count; relock duration distribution.
  Where to measure: codec PLL lock status logs aligned to USB 5V droop.
• Buffer underrun (audio xrun)
  Symptom: periodic ticks or gaps during heavy pipeline activity.
  Metric: DMA ring underrun count; time between underruns.
  Where to measure: audio DMA counters + CPU/ISR load markers (only as timestamps, no OS deep dive).

Sync metrics (drift and timestamp trust)

• Drift ppm (audio vs video)
  Symptom: lip-sync slowly walks off over minutes.
  Metric: delta between (audio sample count / fs) and (video frame count / fps) over long windows.
  Where to measure: mux timestamps; periodic checkpoints (e.g., every N seconds).
• Timestamp monotonicity
  Symptom: A/V suddenly jumps or repeats for a short segment.
  Metric: non-monotonic timestamp events; duplicate timestamps count.
  Where to measure: mux/file timestamp stream; resync markers.
• Resync events
  Symptom: drift “fixes itself” but creates a visible audio or video discontinuity.
  Metric: resync count + resync magnitude; correlation with PLL relock or brownout.
  Where to measure: pipeline logs aligned to power events.

Power metrics (USB 5V reality check)

• USB 5V droop at two points
  Symptom: errors/pops/reboots that coincide with plug-in or load bursts.
  Metric: minimum voltage and droop duration at (A) connector and (B) PMIC input.
  Where to measure: scope probes at both points in the same event window.
• Inrush peak
  Symptom: device resets on hot-plug; host limits current; unstable startup.
  Metric: peak current/droop during the first milliseconds; repeatability across cables/hosts.
  Where to measure: hot-plug waveform capture + event counter.
• Reset/UVLO counters
  Symptom: “random” reboot that is actually deterministic under droop.
  Metric: reset reason histogram; UVLO trip count; brownout flags.
  Where to measure: reset reason register + persistent log counter.

Storage metrics (determinism and integrity)

• Worst-case write latency
  Symptom: frame drops or audio ticks during writes even if “average speed” is fine.
  Metric: latency histogram; 99.9th percentile; stall duration distribution.
  Where to measure: write timestamp logs around capture bursts.
• ECC/CRC/fs errors
  Symptom: corrupted or truncated files; missing tail; retry storms in field conditions.
  Metric: ECC correction count, CRC errors, fs/journal errors, retries per minute.
  Where to measure: storage driver logs + file integrity checks aligned to power dips/ESD events.

H2-3. System architecture: two pipelines sharing resources

The cam-audio module behaves like two real-time pipelines (video + audio) that must survive the same shared resources: clocks, power rails, memory bandwidth, and thermal headroom. Many “single-domain” symptoms are actually cross-domain coupling.

Pipeline view (what must be kept deterministic)

• Video pipeline: image sensor produces a fixed-rate frame stream; CSI-2 link integrity and ISP/encoder buffering decide whether frames are delivered or dropped.
• Audio pipeline: mic-array and codec produce a continuous sample stream; codec clock events (PLL unlock/relock) and DMA ring health decide whether audio stays gap-free and pop-free.
• Mux/file boundary: both streams are written into a file/container; any timestamp discontinuity or burst stall can appear as drift, jumps, or missing segments.

Shared resources (the common root-cause pool)

• Clocks: reference stability and PLL lock behavior; relock events can cause pops, short discontinuities, or resync markers.
• Power rails: USB 5V droop and rail partitioning; one droop can simultaneously trigger CSI errors, codec clock events, and storage retries.
• Memory bandwidth: ISP/encode + audio DMA + storage writes compete; worst-case latency spikes matter more than average throughput.
• Thermal headroom: temperature can reduce link margin, increase leakage, and force throttling; thermal-driven transitions often look “random” without correlation.

Top coupling paths (symptom → evidence → likely domain)

H2-4. Image sensor interface (CSI-2) margin: what breaks first and why

CSI-2 failures in smart glasses are rarely “random”. They usually follow a small set of margin killers that become visible as error bursts, temperature correlation, or touch/hot-plug triggers. This section focuses on module-level evidence, not generic protocol theory.

Module constraints that reduce CSI margin

• Flex + connector realities: bend radius, connector transitions, and ground discontinuities often dominate over ideal routing.
• Lane rate pressure: moving from 30 fps to 60 fps raises lane rate and shrinks eye margin; “works at low fps” is a key signature.
• Return-path continuity: breaks in reference ground or shield gaps inject common-mode noise and amplify sensitivity to disturbances.

Failure signatures (what is observable)

• CRC/ECC bursts aligned to frame drops or brief link retraining.
• Deskew fail / retrain loops when lane rate is high or when conditions change (touch/plug/temperature).
• Temperature-correlated errors: error rate increases after warm-up; “cold boot OK, hot fails”.
• Touch-triggered errors: touching frame/hinge/USB cable triggers errors within a repeatable window.
• Hot-plug-triggered errors: plugging USB or starting a heavy write burst increases CSI errors.

Likely root causes (mapped to engineering levers)

• Return-path discontinuity: shield/ground breaks, connector ground bounce, or flex crossing splits.
• Impedance discontinuity: connector/transition steps, sharp bends, via stubs (module-level transitions matter most).
• Rail noise / common-mode injection: switching noise or USB transient lifts common-mode, reducing receiver margin.
• ESD loading or leakage: TVS capacitance or leakage shifts with temperature; can create “warm-up failures”.
• Reference clock jitter: ref clock or PLL supply noise turns into timing uncertainty under load.

Fast validation (minimal actions → discriminator)

• Reduce fps/resolution: if errors collapse, suspect pure margin (impedance/jitter/return path) rather than ISP load.
• Stabilize USB 5V (short cable / stronger source): if errors collapse, suspect rail noise or droop-driven common-mode injection.
• Disable or throttle storage writes: if errors collapse, suspect bandwidth/ground noise coupling during write bursts.
• Temperature step test: if errors track temperature strongly, suspect ESD leakage, mechanical stress, or thermal drift of margin.
• Touch/hot-plug repeatability: if highly repeatable, prioritize return-path/ESD path investigation.

H2-5. ISP/SoC load + memory bandwidth + latency spikes (why stutter happens)

Stutter, pops, drift, and “random” resets often share a single mechanism: latency spikes that propagate through buffers while video + audio + storage compete for the same memory bandwidth. Average throughput can look fine while worst-case stalls destroy real-time capture.

Where buffers exist (and what fails first)

• Sensor / CSI receive FIFO: sensitive to short disturbances; error bursts and brief retraining show up as drops.
• ISP line/tile buffers: sensitive to compute load; overflow/backpressure grows when processing cannot keep pace.
• Encoder buffer (VBV / output queue): sensitive to downstream stalls; underrun indicates backpressure from storage/bus contention.
• Audio DMA ring buffer: sensitive to bus contention and service latency; underrun (xrun) is often the earliest warning sign.
• Mux / file write queue: sensitive to storage determinism; long-tail stalls propagate upstream as drops/pops.

Latency spike sources (the usual suspects)

• Storage GC / wear leveling: long-tail write stalls (rare but large) that align with drop bursts.
• fsync / journal commits: periodic stalls that look “every N seconds” under certain write patterns.
• Thermal throttling: sustained slowdown after warm-up; latency distribution shifts upward, not just a single spike.
• Power droop → retry/reset: droop causes retries, ECC bursts, or brief resets that create compound stalls.
• Bus contention: encode + audio DMA + storage bursts collide, creating frequent medium spikes that starve the audio ring.

Fixed SOP: Symptom → shared resource → discriminator evidence → first mitigation

H2-6. Audio codec + mic-array AFE: noise & pops as hardware evidence

In compact wearables, “noise floor rising” and “start/stop pops” are often the fastest hardware evidence for bias routing, ground reference, codec rail cleanliness, and PLL lock stability. This section focuses on measurable hardware triggers rather than DSP algorithm details.

Mic array physical realities (what changes the analog input)

• Mic port / duct / membrane: mechanical changes alter sensitivity and channel matching; can look like “one mic is bad”.
• Bias routing: mic-bias impedance and decoupling shape how rail noise becomes audible noise.
• Shield + ground reference: small ground shifts become common-mode injection in tight layouts and flex transitions.

Codec clock domain (hardware-trigger paths only)

• MCLK/BCLK/LRCLK stability: any lock-loss or relock can create discontinuities that appear as pops/clicks.
• PLL sensitivity to rail noise: rail ripple and droop can trigger unlock/relock events.
• Start/stop pop mechanisms: bias settling, mute/unmute edges, and rail ramp behavior can inject an impulse if timing is wrong.

Pop/Noise triage SOP (symptom → first 2 measurements → discriminator → first fix)

H2-7. A/V sync & timestamps: drift budget, resync evidence

“Audio/video out of sync after a few minutes” is solvable only when sync is treated as a measurable quantity: timebase + timestamp meaning + drift shape (continuous drift vs discrete jumps). This chapter builds a minimal log set and a fast computation method to classify root causes.

Timestamp origins (what each timestamp actually represents)

• Video timestamps: may represent frame start (sensor/ISP side) or encode output (SoC side). Buffering can shift “when it was captured” vs “when it was written”.
• Audio timestamps: may represent sample count (codec clock domain) or a DMA/system timebase. Service latency and underruns can break continuity.
• Mux/file boundary: the container is only as correct as its inputs; discontinuity or resync markers must be logged, not guessed.

Where drift comes from (two shapes, different diagnostics)

• Continuous drift: ppm mismatch between clocks, temperature-driven frequency drift, slow load/thermal changes.
• Discrete jumps: PLL unlock/relock, resync events, brownout/reset time jumps, discontinuity insertion after xrun.

What to log (minimal, high-signal checklist)

H2-8. Storage choices & integrity: deterministic write matters more than peak speed

Storage selection for continuous A/V capture is not about peak MB/s. The deciding factors are worst-case write latency, error-retry cost, power-event behavior, and temperature stability. Most field failures are predictable when logs focus on long-tail latency and integrity signatures.

What to compare (capture determinism dimensions)

• Worst-case write latency: long-tail stalls cause upstream buffer starvation (drops/pops) even when average speed is high.
• Power-event consistency: behavior under droop/reset determines file tail loss vs clean recovery.
• Error retry / ECC cost: retries and correction bursts translate into stalls and timing discontinuities.
• Temperature stability: write behavior can shift with heat/cold; margins shrink and long-tail expands.
• File-integrity signature: truncate/corrupt/stutter/fail-with-space are the meaningful outcomes, not datasheet numbers.

Common field signatures (and what they usually imply)

• Missing file tail (truncate): reset/brownout or unflushed tail; confirm with reset reason and last flush timing.
• Corrupted file / decode errors: ECC/CRC bursts or fs errors; confirm with retry/ECC counters and fs error logs.
• Stutter tied to writes: long-tail latency stall; confirm with write latency histogram aligned to frame drops/pops.
• Write fails despite free space: allocation/timeout behavior under temperature or power instability; confirm with error codes + droop/temp alignment.

Three-bucket selection summary (engineering-first)

H2-9. USB 5V power entry: inrush, droop, and cross-domain failures

USB 5V is the most common root of “cross-domain” failures: a single droop event can trigger MIPI errors, codec PLL unlock pops, and storage stalls or resets. The only reliable approach is to treat power as evidence: two-point probing, event counters, and timestamp alignment to symptoms.

USB 5V in the real world (why “5V” rarely behaves like 5V)

• Cable and contact loss: long/thin cables and connector resistance create droop under bursts (encode + write + RF spikes).
• Host/hub current limit: foldback can produce repeated droop-recover cycles that look like random instability.
• Hot-plug transient: plug-in charging of bulk caps causes inrush and ground bounce, creating short but harmful disturbances.
• ESD / plug events: can cause soft faults (noise/error bursts) before any hard failure appears.

Power tree view (where a 5V event turns into multiple symptoms)

• Entry: USB-C/connector → protection (TVS / fuse / eFuse / load switch) → PMIC input.
• Conversion: 5V → buck(s) → LDOs to separate domains (sensor, CSI/IO, codec analog, storage, SoC I/O).
• Dependencies: POR/UVLO thresholds and rail sequencing decide whether the failure becomes a hard reset or a soft corruption.

Inrush: why “bigger cap” can be worse at the USB entry

• What creates inrush: large entry bulk caps + simultaneous rail bring-up + hot-plug charging current.
• Common outcome: host limit/foldback → voltage collapses → repeated retries → “works on some ports/cables only”.
• Engineering levers: soft-start and current limiting (load switch/eFuse/PMIC), staged enable of heavy loads, and distributed capacitance.

Cross-domain coupling paths (droop → symptom chains)

• Droop → CSI margin shrink → MIPI CRC/deskew failures → frame drops (often induced by touch/plug events or heavy load edges).
• Droop → codec rail/clock perturbation → PLL unlock/relock → pops/clicks and elevated noise during capture transitions.
• Droop → storage rail reset / retry burst → write stall / long-tail latency → stutter + file tail loss under sustained record.

H2-10. EMI/ESD + thermal in glasses form factor: practical hooks (not a compliance tutorial)

In a glasses form factor, short flex runs, dense returns, and close switching sources make EMI/ESD/thermal issues appear as “random errors” unless the diagnosis is anchored to vulnerable nodes and quick validation hooks. This chapter uses a strict engineering template: Threat → vulnerable node → symptom → quick validation.

Key coupling realities in a compact module

• Switching EMI is often the hidden driver of CSI error bursts and codec PLL instability during load steps.
• ESD targets cluster around external touch/openings: USB port, FFC/flex connectors, mic openings and shields.
• Thermal drift changes margins: CSI link gets weaker, clock mismatch increases, and throttling creates latency spikes.