H2-1. Module Definition & Boundary: What “Audio–Haptic Sync” Means (and what it does NOT)

Audio–haptic sync is an engineering problem: align an audio event to a haptic actuation and quantify the error with latency, jitter, and a calibratable offset.

A practical sync definition requires explicit reference points: the audio side must expose an event marker (frame boundary / sample counter / timestamp), and the haptic side must define what “happened” means. Two common haptic reference points are:

• Driver-level execution point: driver output begins (enable-to-drive, or “energy injection start”).
• Actuator-level start: mechanical response becomes measurable (often slower and more variable, especially for ERM).

For deterministic system behavior, it is usually safer to control and validate against the driver-level point first (because it is electrical and timestampable), then optionally correlate it to mechanical onset during characterization.

Boundary (locked): This page focuses on timing anchors, timestamped triggering, deterministic execution on the module, and evidence-based validation. It does not cover the full audio decode chain, full product UX, or OS/driver tutorials.

H2-2. System Architecture: Timing Anchors (Audio Clock, USB SOF, BLE Events)

Reliable audio–haptic sync is built on a shared timing anchor. The primary goal is not “minimum delay,” but consistent alignment to the same timebase. Fixed offset can be calibrated; random jitter cannot.

Each anchor answers a different question and should be chosen deliberately:

• Hardware anchor proves deterministic execution on the module (best place to define the haptic “execution point”).
• Link anchor creates a shared cadence across devices (useful for timestamped scheduling and drift control).
• Audio-frame anchor turns “sound happened” into a stable, indexable event (frame/sample counter) without requiring audio algorithm details.

A robust architecture typically uses two layers: (1) align the module to a link cadence (USB SOF or BLE events), and (2) schedule haptic execution using a module-local hardware timer. This converts transport variability into a manageable offset + bounded jitter.

Evidence-first rule: every latency/jitter claim should map to timestamp taps (host event marker, link cadence marker, module timer marker, driver output marker). If taps disagree, the sync budget is not observable yet.

H2-3. Actuators 101 (Only What Matters for Sync): LRA vs ERM Latency & Variability

Two modules can trigger at the same timestamp yet “feel” misaligned because the actuator adds a mechanical start delay that is voltage-, temperature-, and load-dependent. Sync becomes controllable only after separating the electrical execution point from the mechanical onset.

From a sync perspective, ERM and LRA behave differently because their “start” is dominated by different physics:

• ERM (eccentric rotating mass) — high inertia, slower spin-up/spin-down. It is effective for sustained “buzz,” but short “click” sensations vary because the rotor needs time to build speed. Sync error often appears as mechanical spin-up delay with a wide spread.
• LRA (linear resonant actuator) — resonance-based motion suited for crisp, short “click” waveforms. However, it is sensitive to resonant frequency, drive waveform, and phase. Temperature drift and assembly tolerances shift resonance and damping, changing the time to reach a stable motion.

A practical definition of “when haptics happened” depends on the problem being solved: the driver output start is the best anchor to minimize jitter, while “felt onset” can be derived by correlating the driver output to a simple observation channel during characterization (without turning the design into a sensor project).

Debugging rule: if “sync jitter” disappears when measuring at the driver output (but remains at the mechanical onset), the primary error source is actuator physics or driver waveform/lock behavior, not BLE/USB scheduling.

H2-4. Driver Topologies & Waveform Shaping: What Determines Start-Time Repeatability

Start-time repeatability is usually determined less by the transport link and more by the power readiness and driver pipeline: when energy becomes available, how quickly it ramps, and whether closed-loop logic adds state-dependent delay.

LRA drivers often support both open-loop and closed-loop operation:

• Open-loop executes a predefined waveform immediately, making the electrical start more predictable. The trade-off is sensitivity to resonant frequency drift, which can change the mechanical onset/strength.
• Closed-loop (back-EMF sensing / auto-resonance) improves consistency of motion by tracking resonance, but it may introduce a detect/lock state machine whose duration depends on initial conditions (temperature, battery voltage, previous actuation, damping).

ERM drivers typically emphasize robustness and protection. The chosen control mode affects how “instant” the actuation looks:

• PWM / constant-voltage can start quickly at high VBAT but slows noticeably as VBAT drops.
• Current limiting stabilizes stress and improves safety margins, but increases spin-up time and spreads perceived onset.

Three hardware details most often decide whether a timestamped trigger produces a repeatable execution point:

• Drive ramp / slew: slow ramps delay energy injection; aggressive ramps reduce delay but can increase rail disturbance.
• Boost pre-charge: without pre-charge, first actuation often has extra delay and a larger rail dip (“first click is late”).
• Enable-to-drive pipeline: driver internal steps (mode set → safety checks → lock → drive) can add fixed and variable latency.

Measurement hint: capture VBAT/boost rail and driver output together. If “late haptics” correlates with rail dip, pre-charge and ramp strategy dominate. If rail is stable but delay varies, closed-loop lock/pipeline dominates.

H2-5. Sync Strategy #1: Timestamped Trigger (Host Event → Module Playback Time)

The cleanest way to minimize jitter is to convert “sync” into a scheduling contract: the host sends an event with a future target time, and the module executes at a local hardware timer-compare point (GPIO marker → driver enable). Link arrival jitter becomes harmless if it is absorbed by lookahead.

A deterministic module pipeline keeps the “execution point” stable even when packets arrive with variable delay:

• Receive: parse (event_id, anchor, t_target, ttl, profile_id).
• Validate: reject too-close targets (insufficient lookahead) or expired events (ttl).
• Queue: place into a time-ordered queue (earliest target first).
• Arm: convert target time into local timer ticks and arm timer compare.
• Trigger: at compare, toggle a GPIO marker and assert driver enable (execution point).

Three tactics reduce jitter without requiring any audio decoding or UX logic:

• Lookahead: enforce a minimum lead time so arrival jitter is absorbed before execution. Late arrivals are either dropped (ttl) or moved to the next safe slot (policy-defined).
• Local hard trigger: the timer compare ISR is kept minimal (marker + enable) to avoid software scheduling jitter.
• Double-buffer: one slot drives the current event while the next event is preloaded, preventing register/memory contention.

Jitter budgeting inside this strategy is explicit: link arrival variation is handled by lookahead; remaining jitter usually comes from ISR contention (firmware) or enable-to-drive variability (driver pipeline / supply readiness).

H2-6. Sync Strategy #2: Phase-Locked Scheduling (Align to Audio Frames / Samples)

Some use cases require haptics to align to the content phase (frame/sample boundaries or beat markers), not just a wall-clock time. The module does not need the full audio stream—only a frame_counter / sample_counter marker that can be mapped into local timer ticks.

A practical phase-locked workflow is built from three parts:

• Marker definition: the host sends frame_counter (or sample counter) plus a marker type (frame boundary / beat marker / transient marker).
• Linear mapping: the module maintains a mapping from counter-space to timer-space: slope (ticks per frame) and offset (counter origin alignment). This provides a deterministic timer target for future markers.
• Drift + re-sync: host and module clocks drift over time. The module monitors residual error and performs soft re-sync (small offset trims) and hard re-sync (re-anchor when errors exceed a threshold or counters become discontinuous).

Validation focus: log (frame_counter, predicted_ticks, actual_ticks_at_marker) and track residual drift. Frequent hard re-sync often indicates counter discontinuities or unstable cadence; stable systems rely mostly on soft re-sync.

H2-7. BLE/USB Bridging Details (Only for Timing): Where Jitter Comes From

“Wireless is unstable” is not actionable. Timing jitter becomes actionable only after it is split into measurable segments with explicit timestamp taps. This chapter focuses strictly on timing: discrete BLE scheduling, USB SOF timebase vs host delivery jitter, and how to instrument each segment.

BLE timing (discrete event grid): connection/ISO intervals form a discrete schedule. Even when average latency is small, deliveries can jump between events (“event slip”) due to retransmission, congestion, or slot contention.

• What causes jitter: event quantization (interval grid), retransmission shifting delivery to later events, congestion/overlap causing event slip.
• What reduces jitter: send earlier (lookahead) and schedule execution using local timer compare; late arrivals are dropped or moved by policy.
• What to log: arrival event index vs target event index; “late” counters and slip distribution.

USB timing (stable SOF, unstable delivery): SOF provides a stable cadence, but the host software stack can introduce variable delivery timing (driver scheduling, buffering, system load). SOF stability alone does not guarantee stable event delivery to the module.

• What causes jitter: host-side scheduling variance and buffering before the payload reaches the endpoint and user-space handler.
• What reduces jitter: anchor target times to SOF-derived timing and execute via module timer compare; do not “execute on arrival.”
• What to log: SOF index when message is produced vs SOF index when it is delivered; arrival-to-target slack.

The most useful output is a jitter attribution table (each segment has a tap, metric, and minimal fix action):

A minimal, high-signal tap set is TS2/TS4/TS5 (module-side). TS0/TS1 improves blame isolation when host/transport behavior is suspect.

H2-8. Firmware Timing Pipeline: Low-Power Without Losing Determinism

Low-power modes often degrade synchronization because they inject non-deterministic wake and execution delays. The fix is not “avoid sleep,” but to separate responsibilities into: keeping time, waking deterministically, and executing deterministically.

Common pitfalls that inflate jitter (and where they hurt):

• Tickless idle: wake/scheduling points become variable; compare ISR may be delayed by deferred work.
• DVFS / dynamic clock: ISR execution time varies; critical window shifts if frequency changes near compare.
• Power-domain wake latency: oscillator/startup/regulator ramp adds a wide distribution of wake delays.
• Flash wait-state / cache state: first instruction fetch after wake can vary; stalls appear as edge jitter.

A deterministic pipeline moves variability out of the execution path:

• Short compare ISR: do only marker + DMA start / driver trigger; avoid parsing, logging formatting, or table generation inside ISR.
• Precompute: prepare waveform tables (or register write sequences) during lookahead time; keep them in ready buffers.
• DMA/trigger: use DMA to push a waveform/register burst into the driver interface, avoiding CPU micro-jitter.
• Lock the critical window: freeze clock changes and prevent deep-sleep entry in a small window before compare fires.

If TS4→TS5 is wide, the execution path is not deterministic (ISR contention, DVFS, flash stalls). If events are missed, the wake budget is insufficient (deep sleep entry too close to compare).

H2-9. Power Integrity & Noise Coupling: When Sync Looks Bad but It’s Actually Brownout / Rail Sag

A module can appear to have “random delay” or “missed haptic hits” even when transport and firmware timing are correct. The most common reason is power integrity: the haptic transient current pulls down VBAT/BOOST, triggering clock disturbance, protection behavior, or driver derating. The goal here is simple: separate timing issues from power issues using two waveforms—and preferably four.

How power problems impersonate bad sync (three practical paths):

• Path A — MCU timing disturbed: VBAT/rail sag widens wake/ISR latency or causes reset → marker edges drift or disappear.
• Path B — Driver energy delayed: marker is on-time, but BOOST/driver rail hits limit/UVLO → actual drive output arrives late or shrinks.
• Path C — Protection causes “missed hits”: UVLO/OCP/thermal recovery creates gaps → looks like random misses.

Design checklist (module-level, directly tied to repeatable start-time):

• Input capacitance & path: reduce VBAT droop and its slope; keep high pulse current off the “quiet” supply segment.
• Soft-start & precharge: avoid “first-hit” collapse that causes a late or missing actuation.
• Current limit & UVLO thresholds: too tight → delayed energy injection; too high UVLO → frequent drop/recover cycles.
• Return path control: keep the high di/dt loop short; do not share critical ground segments with MCU/timebase reference.

H2-10. Reliability, EMC/ESD, and “Audio-Path Pollution” (Only at Coupling Level)

Sync modules are often embedded next to audio electronics. A haptic driver’s switching edges and high di/dt current loop can inject noise into shared rails or shared ground impedance. The result may look like a “sync problem” (pops, noise floor jumps, or transient artifacts), but the root cause is coupling. This chapter stays strictly at the module coupling level—no full audio-path design deep dive.

Why “audio pollution” is misdiagnosed as sync:

• Noise injection creates pops or baseline shifts that users perceive as “timing mismatch.”
• EMC/ESD stress can trigger protection or resets, causing missed hits that look like jitter.
• Measurement corruption: the marker/drive edges themselves can be disturbed if the return path is uncontrolled.

Module-level mitigation (practical, coupling-focused):

• Partition rails: separate (or isolate) haptic power from MCU/timebase and audio quiet rails; avoid shared narrow supply segments.
• Return-path isolation: keep the high di/dt loop compact and local; do not let coil current share the quiet ground reference path.
• Switching frequency planning (principle only): avoid placing dominant switching energy where it is most audible/sensitive; reduce low-frequency modulation.
• ESD placement + return control: place ESD close to the connector, and ensure ESD return current flows away from quiet ground.

The most valuable mental model is “current-loop drawing”: if the high di/dt loop is obvious and isolated, coupling symptoms collapse quickly. If ESD current returns through quiet ground, fixes that only add components will not stabilize behavior.

H2-11. Validation & Field Debug Playbook: Symptom → Evidence → Isolate → Fix

This SOP turns “sync feels random” into a measurable root cause. The workflow is always: define metrics → run repeatability matrix → capture 2 probes (minimum) → classify symptom path → apply first fix → re-test. Offset can be calibrated; jitter must be isolated.

1) Metrics definitions + logging sheet (make arguments measurable)

• Latency: time from event reference to action reference. Recommended: marker edge → drive-start edge.
• Jitter: repeatability spread under identical conditions (use p-p range over N=10–30 triggers).
• Offset: fixed bias between event and action that stays constant (can be calibrated if jitter is low).

Measurement reference must be explicit. Example references: (A) USB SOF-aligned marker, (B) BLE event-aligned marker, (C) MCU timer-compare marker. Action reference: (1) driver enable/drive-start pin, (2) H-bridge output proxy.

2) Repeatability matrix (temperature / battery / host)

Run a small matrix and record jitter p-p and miss rate. This converts “occasional” into a reproducible pattern. Each cell: N=10 triggers at the same configuration.

3) Minimal tools (two probes) — the fastest isolation method

Minimum setup: a 2-channel scope or logic analyzer. Capture one rail and one marker. This splits “timing chain” vs “power collapse” before deeper work.

• Probe #1 (rail): VBAT or BOOST/driver rail (choose the rail that feeds the driver energy).
• Probe #2 (timing): GPIO marker (timer-compare / execution marker).

Optional but high value: add a dedicated DRIVE_START test pin (or driver EN pin) to measure “marker → energy injection” directly.

4) Symptom library (S → E → I → F) — follow the same 4-step template

5) Root-cause buckets + “first-fix” BOM examples (MPNs)

After symptom classification, apply the smallest module-level fix and re-test the same cell in the repeatability matrix. Use these buckets to keep fixes scoped and measurable.

Note on MPN lists: these are reference options to speed early prototyping and debug. Final selection depends on voltage/current, package, availability, and actuator control requirements.