What this chapter decides

Establish a system-level view that stays consistent across debugging: block ownership, three system tensions, and a symptom → evidence → likely block index. This prevents “random guessing” and keeps later chapters anchored to measurable proof.

Core blocks (system boundaries)

Use this set as the fixed “ownership map” for the whole page:

Rule: When a problem appears “software-like”, first verify whether a physical coupling path exists: power rail, ground return, radiated EMI, or thermal throttling.

The 3 tablet-specific tension lines

• Power & thermal: higher refresh / brightness / compute / RF duty cycle → higher power → hot spots → throttling or performance cliffs (throughput drops, frame stutter, audio artifacts).
• Noise coupling: backlight switching + Class-D edges + PMIC harmonics → rail/ground/EMI injection → touch/pen jitter, audio noise floor rise, or intermittent resets.
• RF coexistence: thin form factor + near-field coupling + shared ground/power domains → Wi-Fi/BT instability that correlates with brightness, audio load, or temperature.

Evidence checklist (what to capture first)

• System power trace: segment by scenarios (idle / video / meeting / gaming) and look for abnormal tail current.
• Thermal hot spots: SoC zone vs Wi-Fi zone vs backlight zone; record the “performance cliff” temperature.
• Symptom classification: whether the symptom tracks a controllable knob: brightness steps, RF load, audio volume steps, charging vs battery.
• Quick A/B isolation: fixed brightness, toggle Wi-Fi band, mute audio path, reduce refresh, repeat and compare.

Symptom → likely block → fastest A/B check

How to use this section

For each experience area, capture: (1) a metric → (2) a fast measurement → (3) abnormal patterns → (4) likely coupling path. Later chapters expand each block, but this metric dictionary keeps decisions consistent.

Battery life & standby (power segmentation)

• Metric: average power per scenario + tail current in idle/deep sleep.
• Fast measurement: record four segments (idle, video, meeting, gaming) with temperature trend.
• Abnormal patterns: high tail current; step-like spikes during “sleep”; power rises with brightness unexpectedly.
• Likely direction: PMIC rail state transitions, backlight injection, RF duty cycle under retries.

Touch & pen interaction (latency & jitter)

• Metric: latency stability (not just average) and jitter/“broken strokes”, especially at screen edges.
• Fast measurement: repeat a fixed drawing pattern while sweeping brightness and RF load (A/B tests).
• Abnormal patterns: edge drift; intermittent drop touches; pen jitter that tracks brightness or charging.
• Likely direction: backlight switching noise, ground return, digitizer noise baseline shifts.

Display stability (brightness steps & flicker symptoms)

• Metric: stability under brightness/refresh changes; presence of flicker/stripes/blank events.
• Fast measurement: brightness step test (20%→80%→20%) and light flex/temperature correlation.
• Abnormal patterns: flicker tied to dimming; stripes tied to pressure/temperature; blank with audio/touch still alive.
• Likely direction: display link integrity, backlight driver behavior, panel power sequencing.

Wireless stability (throughput ↔ thermal ↔ retries)

• Metric: throughput stability + retry/packet loss trend vs temperature (look for “cliff points”).
• Fast measurement: compare 2.4 GHz vs 5 GHz under fixed brightness; record throughput + temperature.
• Abnormal patterns: throughput jumps with normal RSSI; BT audio stutter when Wi-Fi is busy; heat drives drops.
• Likely direction: RF coexistence, in-band EMI from switching blocks, thermal throttling behavior.

Audio quality (noise floor & pop/click events)

• Metric: noise spectrum (hiss/buzz) and transient artifacts (pop/click) tied to state changes.
• Fast measurement: record spectrum at multiple brightness levels; perform volume step and wake/sleep transitions.
• Abnormal patterns: narrowband buzz aligned with switching harmonics; pop/click during wake or rail switching.
• Likely direction: shared rails/ground reference shifts, backlight coupling, RF interference into analog paths.

Metric-to-block navigation (keep it disciplined)

Use the metric that changed first to decide “where to look next”: power/standby → PMIC rails, pen jitter → backlight + digitizer, flicker → display chain + backlight, throughput cliffs → RF coexistence + thermal, buzz/pop → audio rails/ground + coupling sources.

What this chapter decides

Identify which budget hits first: Memory bandwidth, Thermal headroom, Display pipeline, or I/O service. The goal is to stop “model-number talk” and prioritize measurable constraints.

Bottleneck 1 — LPDDR bandwidth ↔ heat coupling

• System behavior: higher bandwidth demand raises SoC/memory power, increases hot spots, then triggers frequency limits or performance “cliffs”.
• Typical triggers: high refresh + heavy UI composition, gaming, video + background tasks, meeting workloads with wireless activity.
• Symptom signature: performance drops sharply after temperature crosses a repeatable point, then recovers after cool-down.
• Evidence to capture: frame stutter vs temperature curve, power segmentation by scenario, and repeatability under controlled ambient.

Fast A/B: lower refresh rate or reduce background load; if the “cliff” shifts or disappears, bandwidth/thermal budget is the primary suspect.

Bottleneck 2 — Display pipeline load (MIPI-DSI + internal composition)

• System behavior: display always-on load can dominate the power envelope in tablets, especially at high brightness and high refresh.
• Symptom signature: brightness/refresh changes affect not only battery/heat, but also touch stability and wireless throughput (through coupling).
• Evidence to capture: brightness-step power delta, temperature rise rate, and correlation to touch jitter or throughput dips.
• Boundary reminder: focus on observable power/thermal impact rather than protocol or driver internals.

Bottleneck 3 — Peripheral I/O service pressure (touch, audio, Wi-Fi/BT)

• System behavior: bursts of events (touch samples, audio streams, RF activity) can create short “service spikes” that look like random UI hiccups.
• Symptom signature: short glitches that correlate with a specific activity (BT audio + Wi-Fi load, heavy pen input, scanning/retry bursts).
• Evidence to capture: activity correlation (RF load / audio volume / pen usage), repeated A/B isolation, and “glitch probability” statistics.
• Boundary reminder: keep proof at system evidence level; avoid OS/kernel deep-dive.

Fast A/B: lock brightness + disable one activity path (e.g., BT audio) and repeat the same workload; if glitch probability collapses, I/O service pressure is implicated.

Symptom → primary bottleneck → first evidence

Boundary (what this chapter covers)

This chapter covers board-level rails, power domains, noise/return paths, and sleep/wake evidence. It does not discuss charger PSU topologies (PFC/LLC/flyback equations).

Typical rail tiers (tablet-centric)

Rule: sensitive analog domains should avoid sharing noisy return paths with backlight switching loops, class-D edges, and RF burst currents.

Sleep / wake rail transitions (where “random” lives)

• High-risk window: the wake-up moment is a short transient problem (ms–hundreds of ms) that may look like intermittent software failure.
• Typical triggers: display/backlight ramp, RF re-attach, audio path enable, and digitizer re-baselining.
• Symptom signature: black screen, partial wake (touch alive but display dead), pop/click on wake, or Wi-Fi reconnect loops.
• Evidence to capture: wake transient rails, brownout/UVLO flags, and correlation between power events and crashes.

Noise & ground-return coupling (the hidden root cause)

• Rail injection: shared input filtering or insufficient isolation allows switching harmonics to ride into sensitive domains.
• Return path pollution: high di/dt loops push ground bounce into digitizer/audio reference points.
• Radiated coupling: switching nodes and fast edges couple near-field into touch or RF areas.

Fast confirmation: if a symptom tracks a controllable knob (brightness, volume, RF load), a coupling path exists. The task is to prove whether it is rail, return, or radiation.

Evidence checklist (minimum set that resolves debates)

• Key rail ripple: capture ripple under high brightness, high volume, and RF busy states.
• Wake transients: check droop/overshoot around wake and backlight ramp; align with “black screen / reboot”.
• Brownout/UVLO alignment: correlate events/flags with crash timestamps; prioritize repeatability over anecdotes.
• A/B isolation: lock brightness, mute audio, change Wi-Fi band, and compare failure probability.

Display chain blocks (system view)

• SoC display engine — composition output that drives a high-speed pixel stream.
• MIPI / bridge (optional) — high-speed lane transport; bridges appear when routing or interface conversion is needed.
• Connector / flex — mechanical weak point; intermittent contact can mimic “random” graphics failures.
• TCON / panel timing — timing coordination and panel driving; many fixed-pattern artifacts originate here.

Guardrail: brightness-linked flicker is usually backlight-related (handled in H2-6). H2-5 focuses on timing/link/connector/panel-power evidence, and refresh-policy transitions as system-level triggers.

Symptom → first suspects → fast evidence

Refresh strategy: when “mode switching” looks like a fault

• Fixed vs dynamic refresh: transitions can introduce short artifacts (stutter or brief flicker) that disappear when refresh is locked.
• Power-aware behavior: low-battery or thermal conditions can trigger refresh/pipeline adjustments that change the symptom probability.
• Evidence priority: treat repeatability as truth—if locking refresh collapses the issue, the path is policy/transition rather than random silicon failure.

Minimum experiment: hold brightness constant, lock refresh, and repeat the same UI/video loop for 10–20 cycles to compare artifact probability.

EMI view: high-speed edges + connector geometry → cross-domain effects

• High-speed edges: imperfect return paths create common-mode radiation that can disturb touch baselines or wireless stability.
• Connector/flex as an antenna: cable posture changes and bending can shift coupling and make faults appear “random”.
• Evidence to capture: correlation to grip/cover/grounding and to mechanical posture; avoid protocol-level explanations.

Tell-tale: if the symptom depends on hand position, cover type, or chassis grounding, coupling is involved (rail/return/radiation).

Noise features (what changes with brightness)

• Switching frequency & harmonics: edges and harmonics can land inside sensitive measurement or audio bands as spurs.
• Dimming mode: PWM, analog dimming, or hybrid modes reshape the spectrum and the probability of interference.
• Operating point shifts: certain brightness bands can be noticeably “noisier” due to control-loop behavior and current pulses.

Key idea: if a symptom tracks brightness steps, a coupling path exists. The task is to prove which path dominates.

Three coupling paths (diagnose like a map)

Object symptoms (turn “experience” into evidence)

• Touch / Pen: jitter, intermittent missed touches, pen drift—often strongest in certain brightness bands or with PWM.
• Audio: hiss/buzz spurs, pop/click at brightness transitions, noise that follows a fixed tone in the spectrum.
• Wi-Fi: throughput oscillation and retry bursts that correlate with brightness changes or display/backlight activity.

Do not overfit: correlation must be repeatable. Use repeated loops and compare probability, not single anecdotes.

Evidence checklist (the minimum set that settles debates)

• Brightness-step correlation: step brightness A→B and observe touch noise, audio spurs, and throughput statistics in the same time window.
• Spectrum alignment: confirm spurs align with switching frequency, PWM rate, or harmonics (even a coarse spectrum is useful).
• A/B validation knobs: change PWM frequency, switch dimming mode, or temporarily disable backlight while keeping other loads stable.

Fast triage: if PWM frequency change moves the spur frequency, the backlight is the source and the path is rail/return/radiation.

System split (no algorithm deep dive)

• Mutual-cap touch: ITO electrode grid → flex/connector → touch controller AFE → host interface.
• Active pen: pen excitation/return → receive channels → synchronization window (timing-sensitive).
• Shared sensitivities: reference ground stability, stack-up dielectric variation, and near-field coupling from display/backlight/wireless.

Guardrail: keep analysis at the signal-chain and hardware consistency level. Avoid gesture/palm-rejection algorithm details; focus on evidence that differentiates stack-up/grounding/EMI causes.

Symptom → first suspects → evidence that proves it

Mechanical stack-up variables (turn “assembly” into measurable causes)

• Stack-up & adhesives: glass/OCA thickness and dielectric variation shift capacitance baselines and coupling margins.
• Metal frame & grounding springs: contact force and oxidation change reference stability and batch-to-batch behavior.
• Flex routing posture: bend radius and proximity to noisy nets can move a design from “marginal” to “unstable”.

Production reality: a “good design” can still fail by distribution. When the tail of the distribution crosses a noise margin, problems appear as intermittent and device-specific.

Evidence checklist (minimum set to settle root-cause debates)

• Noise baseline: compare baseline under open-air vs hand-grip vs chassis-ground contact vs charging.
• Scan band / timing knob: change scan band or a sync-related setting and observe whether the failure probability moves (no algorithm details needed).
• Batch statistics: compare defect rate by assembly batch, adhesive lot, grounding spring revision, and bezel/frame variant.

Good proof is repeatable probability change under a controlled A/B knob, not a single “it happened once” observation.

Batch-driven consistency method (from anecdote to distribution)

• Define pass/fail metrics: edge drift limit, missed-touch event rate, pen jitter index, and tilt stability threshold.
• Group by controllables: assembly batch, adhesive lot, grounding hardware revision, bezel/frame vendor.
• Report percentiles: prioritize p95/p99 behavior and defect rate over averages to avoid missing tail failures.

Common conflict scenarios (what to reproduce)

• BT audio stutter vs Wi-Fi throughput: simultaneous 2.4 GHz activity exposes coexistence margins.
• Hotspot or gaming thermal soak: rising temperature narrows RF and power margins and triggers drops.
• High brightness + loud audio: backlight and amp noise sources stack with wireless bursts and raise retry probability.

Goal: reproduce under controlled knobs; capture throughput, retries, temperature, and a simple ripple indicator in the same time window.

Board-level coexistence model (no protocol stack deep dive)

• RF module: Wi-Fi/BT SoC + RF FEM (PA/LNA/switch) with burst current draw.
• Antenna near-field: grip, metal frame, and flex posture change coupling and effective SNR.
• Noise sources: backlight driver, audio amp, PMIC harmonics, and display high-speed edges can inject spurs or raise noise floor.
• Thermal limit: headroom shrinks; marginal links become unstable under sustained load.

Interference sources checklist (prioritize fast A/B knobs)

• Backlight: brightness step and PWM mode/frequency are strong isolation knobs.
• Audio amp: volume step or mute helps identify coupling and supply stress.
• PMIC harmonics: state changes can move spurs; focus on evidence alignment, not internal firmware.
• Display edges: refresh/mode changes can shift emissions; keep settings controlled during tests.

Evidence chain: RSSI/SNR → retries → temperature → supply ripple

Rule: prioritize repeatable correlations. A/B knobs should move the probability of retries/drops, not just “feel different.”

Minimal isolation experiments (fastest route to root cause)

• Band A/B: compare 2.4 GHz vs 5 GHz for the same workload; large improvement suggests 2.4 coexistence sensitivity.
• Load A/B: fix brightness, mute audio, and keep CPU load stable while repeating the same network test loop.
• Posture A/B: vary grip/cover/chassis contact; strong dependence implies near-field/antenna coupling involvement.

Output: keep a single timeline with throughput, retries, temperature, and knob states so evidence stays auditable.

System split (keep it hardware-auditable)

• Capture path: Mic → bias network → codec AFE/ADC → digital interface.
• Playback path: Codec DAC → amp (speaker / headphone) → transducer.
• Primary sensitivities: ground/return, supply ripple, routing/shield, load steps.

Guardrail: focus on hardware signatures and correlations. Avoid DSP topics such as AEC/NR implementation details; keep analysis at supply/ground/routing and reproducible A/B evidence.

Symptom → first suspects → evidence that settles debates

Four-quadrant hardware cause model (standardize root-cause language)

• Supply injection: ripple or burst-current stress on codec AVDD / amp PVDD raises noise and causes clicks.
• Ground/return path: shared returns or “ground bounce” translate load steps into audible artifacts.
• EMI coupling: backlight switching nodes, display edges, and RF bursts raise the noise floor or create tonal spurs.
• Load & route switching: speaker/headphone routing and mute/enable edges create repeatable transient signatures.

Practical outcome: each quadrant has a distinct “signature” that can be confirmed by a minimal A/B knob.

Minimum test set (five actions that end circular arguments)

• Mute/unmute edge: capture time waveform around the edge and verify repeatability of pop/click signature.
• Volume step: observe whether noise or squeal scales with load step (amp/return path suspicion).
• Brightness step: check whether tonal peaks shift with PWM settings (backlight spur evidence).
• Path differential: compare speaker vs headset path; divergence isolates amp/return vs codec/mic chain.
• Spectrum fingerprint: identify stable peaks/harmonics and align them to switching sources (without deep DSP theory).

Rule: a useful test changes probability or amplitude under a single controlled knob, not a “try many things at once” experiment.

Correlation validation with backlight / touch / wireless (do not repeat other chapters)

• Lock non-audio variables: keep brightness, refresh mode, and network band fixed unless they are the test knob.
• Single-knob A/B: change only one knob (brightness, network load, touch activity) and keep the audio pattern constant.
• Evidence alignment: prove timing alignment between knob state and spectral/time-domain signatures.

Goal: turn “seems related” into auditable correlation that predicts when failures happen.

Field stress map (three axes that drive most returns)

• ESD/EMI: touch edge/bezel, USB-C, headset jack, display frame.
• Drop/flex: connector loosening, flex micro-cracks, shield/ground spring contact shifts.
• Thermal drift: touch baseline drift, RF derating and drop probability, backlight efficiency and noise signature changes.

Key idea: many devices remain functional after stress but suffer measurable performance degradation (higher retries, higher noise, larger drift).

ESD trigger points and “works but worse” degradation patterns

Rule: do not stop at “still works.” quantify the probability shift or margin loss after stress.

Drop/flex failures: connectors and flex cables dominate intermittent faults

• Connector loosening: tap/twist can trigger failures; location sensitivity often points to a single interface.
• Flex micro-cracks: angle-dependent and temperature-dependent intermittency; harder to catch without a controlled posture.
• Ground/shield contact shifts: changes EMI and noise margin, affecting touch/wireless/audio across the board.

Evidence signature: failures correlate with posture or mechanical stimulus, not with time-in-software.

Thermal drift: convert “it gets worse when hot” into curves

• Touch: baseline and edge drift grow with temperature, narrowing effective noise margin.
• Wireless: RF front-end derating shrinks SNR headroom; retries and drops rise after a thermal knee.
• Backlight: efficiency/workpoint shifts can change spur signatures and coupling probability.

Minimum output: plot or log throughput-vs-temperature and drift-vs-temperature under fixed settings.

Minimal reproduction workflow (make intermittency auditable)

• Find the trigger: ESD touch point, flex direction, or thermal threshold that changes failure probability.
• Lock variables: fix brightness, audio path, band, and workload unless one is the test knob.
• Align evidence: record symptom + trigger state on one timeline; repeat to confirm probability shift.

Outcome: “random” becomes conditional and predictable, which is the only reliable path to fixing field failures.

Triage priority (avoid blaming the SoC too early)

• First: connectors, flex cables, ground/shield contacts (highest leverage, most common in thin tablets).
• Second: rail stability and return paths under heat/flex (margin shrink often reveals latent design risk).
• Third: module-level issues (RF/touch/backlight/audio) after mechanical and power integrity evidence is clean.