H2-1. What a Motion Coach Chest Strap Is (and isn’t)

Definition (engineering-only): A motion-coach chest strap is a chest-mounted electrode interface that measures R-R interval via an ECG HR AFE, captures motion events via an IMU, extracts on-device features on an edge MCU, and delivers time-stamped packets over BLE—while meeting strict low-power and traceability requirements.

What “motion coach” means here: local, testable computations such as quality gating, event detection, and feature summarization (e.g., cadence/impact markers), not cloud training plans or app UX workflows.

Typical data path (testable signal chain):

• Electrodes → HR AFE → R-peak / R-R + quality flags (lead-off/saturation counters).
• IMU → motion features/events (clip count, RMS, orientation stability).
• Edge MCU → aligned feature packets (timestamp + sequence + quality).
• BLE → realtime notifications and/or batch sync; local log remains the source of truth for gaps.

H2-2. Target Metrics & Real Failure Modes (spec the problem correctly)

Chest-strap performance should be specified as an engineering contract: what “good” looks like, what evidence proves failure, and which root-cause bucket it belongs to. Three metric families are sufficient to drive the entire design and debug loop:

• Accuracy: R-R stability during motion without being dominated by contact-induced artifact.
• Continuity: data arrives complete and time-consistent (no silent gaps, no drifted alignment, controlled latency).
• Power: average current meets battery-life targets and peak events do not trigger brownout / reboot / reconnection storms.

Metric matrix (what to measure, and what it proves):

Engineering rule of thumb: many “accuracy” complaints are actually continuity or alignment failures. Always prove the bucket using counters and timestamps before changing algorithms.

H2-3. End-to-End Architecture (signal chain you can test)

Goal: define a complete signal chain that can be measured, time-aligned, and root-caused. A chest-strap “motion coach” is not validated by a single heart-rate number; it is validated by a chain of events + timestamps + quality flags that remain consistent from sensor front-ends to BLE packets and local logs.

Data model (what the system really outputs):

• R-R events: time-stamped intervals and R-peak markers, accompanied by quality flags (lead-off state, saturation count, contact score).
• Motion features: time-stamped cadence/impact markers, with integrity flags (IMU clip count, RMS intensity, orientation stability).
• Transport frames: BLE payloads that include sequence counter + timestamp + mode (realtime notify vs batch sync) so gaps and reordering are provable.
• Log records: durable entries with time + seq + CRC and an explicit commit marker to survive resets without duplication/holes.

H2-4. HR Front-End on a Chest Strap (electrode contact is everything)

The chest-strap HR front-end is dominated by the electrode–skin interface. When motion begins, contact impedance and micro-slip change faster than most people expect, and those changes can push the AFE into baseline drift, transient saturation, or repeated lead-off toggling. If these states are not observable, the system will mislabel contact artifact as “heart-rate variability.”

Input protection and RFI/ESD hardening (engineering meaning): protection networks must prevent damage without consuming the usable input range or introducing non-linear rectification paths that turn RF events into low-frequency drift. A robust design separates “survivability” from “signal integrity” by ensuring that protection does not dominate the waveform during motion.

AFE parameter priorities (what they influence in practice):

• Input range / recovery: determines whether impact-induced transients cause extended saturation (and long false gaps).
• CMRR + reference strategy: determines how well common-mode disturbances are rejected when contact changes.
• Input noise: determines detection margin for small R-peaks under high-impedance contact conditions.
• Lead-off / contact sensing: provides the only reliable way to gate output when the interface is not trustworthy.

H2-5. IMU Subsystem for Coaching (sampling, bias, and shock)

Goal: treat the IMU as a coaching sensor, not a generic motion chip. The output is only useful when it consistently produces time-stamped events/features (cadence/impact/swing/stillness) with explicit quality flags (clip, RMS intensity, bias health, temperature drift). Without quality, high-energy motion turns into believable—but wrong—features.

Sampling rate & bandwidth (spec from the feature need): coaching features are driven by two regimes: (1) lower-frequency cadence/swing patterns and (2) fast transients at impact. If the bandwidth is too low, impacts smear into slow ramps and event timing drifts; if bandwidth is high but quality flags are missing, high-frequency vibration becomes false triggers. Configuration must be validated via event timing stability and false-trigger rate, not by “nice-looking” waveforms.

Dynamic range & clipping (the most common root cause of fake events): impact can exceed IMU range during running, jumping, or abrupt torso motion. Once clipped, many features appear artificially “consistent,” and threshold crossings shift in time. A coaching pipeline must treat clip_count as a first-class input—otherwise “more motion” can look like “better cadence.”

Mounting & coordinate drift (chest strap specific): strap tension changes, sweat lubrication, and fabric movement can cause small rotations/offsets of the IMU module. This changes axis projection and can drift feature thresholds over a session. Drift must be observable using simple indicators: axis energy ratio, gravity direction consistency, and sudden orientation jumps that correlate with false cadence/impact events.

Self-check & consistency (bias / temperature / stillness): bias and temperature drift show up first in “quiet” segments. A robust system validates itself continuously: during stillness windows, RMS should drop near the motion floor and bias health should remain stable; during motion windows, RMS and clip_count should rise in predictable ranges, not explode unpredictably.

H2-6. IMU-HR Time Alignment (the silent killer)

Goal: make “coaching feel” measurable. HR events (R-peak / R-R) and IMU events (impact/cadence) can each be correct yet still fail coaching if they are not mapped onto the same time axis. Misalignment produces believable but wrong causality: impact appears to “cause” a heart-rate change too early/late, and cadence markers drift relative to R-R trends over a session.

Timestamps: single-clock vs dual-clock: single-clock systems stamp every event in the MCU timebase; dual-clock systems must map IMU time (FIFO sample counter or internal timestamp) into MCU time. Dual-clock mapping is never “set once”: drift (ppm-level), temperature changes, and resynchronization events shift the mapping, causing step errors in alignment unless drift and resync are explicitly tracked.

Buffers & queues (where fake delay is born): even with a perfect clock model, queueing can dominate. FIFO depth, task preemption, and packetization schedules introduce variable latency between “sample happened” and “event got stamped/sent.” If alignment error correlates with queue depth or task latency, the root cause is local scheduling—not the sensor.

H2-7. Edge MCU & On-Device Features (what runs locally, why)

Goal: define a strict engineering boundary for “edge intelligence” on a motion-coach chest strap. The device runs feature/event extraction, quality control, and data integrity locally. It does not implement training plans, app tutorials, or cloud-driven coaching content. The priority is simple: never output believable-but-wrong events when contact, motion sensing, or timing integrity is compromised.

Task layering (a testable pipeline): the firmware should be structured as a measurable pipeline with explicit boundaries. Each stage emits counters so field failures can be attributed to sampling, scheduling, detection, or transport—not guessed.

Quality gating (degrade, don’t hallucinate): edge logic must treat sensor health as an input. When contact is poor, IMU is clipped, or alignment error rises, the system should reduce or suppress misleading outputs and instead report explicit quality state and reason codes. This prevents “confident” but incorrect cadence/impact cues.

Firmware robustness (watchdog + recovery with data semantics): a reset is not just a reboot. A chest strap must resume without silently corrupting session history. On restart, firmware should record reset_reason, restore sequence counters safely, and ensure logs are atomic (commit marker + CRC) so sync does not create duplicates, gaps, or reorder confusion.

H2-8. Bluetooth LE Link for Sports Data (low power, not low rigor)

Goal: treat BLE as a sports-data transport with two distinct operating modes. Real-time coaching requires predictable latency and cadence; post-workout sync requires throughput and recoverability. In both modes, the link must be provably complete using timestamps, sequence counters, and recovery behavior—without deep protocol-stack exposition.

Connection parameters (engineering meaning, not a stack lecture): connection interval controls the density of transmit opportunities and average current; slave latency saves power but risks jitter and delayed delivery; MTU and packetization determine per-transaction overhead and the balance between throughput and peak current. In motion devices, these choices couple directly into dropouts because RF retries and CPU wakeups amplify peak current, which can trigger brownouts or scheduling backlog if margins are thin.

Data integrity (detect → mark → recover): completeness must be verifiable. Every record frame includes timestamp + seq + flags + CRC. The receiver detects gaps (seq discontinuity), the device marks events (gap_count / retry_count / reconnect_count), and recovery resumes from a known seq/offset using the local log without creating duplicates (commit marker + dedup rules).

H2-9. Power Architecture & Battery Life (budget-first design)

Goal: treat battery life as a measurable current budget. A chest strap succeeds when average current is controlled for long life and peak current events (TX bursts, storage writes, high-ODR windows) never push rails into UVLO/brownout behavior. This chapter focuses on chest-strap patterns only and avoids charger-topology derivations.

Peak events (the three pulses that break wearables): in chest straps, most unexpected resets or dropouts correlate with a few repeatable pulses. TX retries amplify RF peak demand; log writes create short but sharp write-current spikes; IMU high-ODR windows raise CPU and sensor duty cycle and can indirectly increase queue latency and radio contention.

Power-domain partitioning (AFE/IMU/Radio): domain control is not only about saving energy; it protects data trust. If the radio domain browns out, link counters and reconnects must be visible. If sensor domains are unstable, quality gating must prevent plausible-but-wrong events. A practical approach is to make rail-good and UVLO evidence first-class telemetry and align domain transitions with the logging commit boundary.

Low-power state machine (wake sources and wake storms): battery life collapses when wake sources are not budgeted. Typical wake sources are motion triggers (IMU), periodic timers, HR events, and BLE link activity. The critical failure mode is an erroneous wake storm: noisy thresholds or aggressive link activity causes excessive wakeups, raising Iavg and increasing peak-event collisions that produce UVLO signatures.

H2-10. Logging & Data Integrity (you can’t coach what you can’t trust)

Goal: make local logging a closed engineering loop: data remains complete and interpretable even with disconnects, resets, and power loss. A motion-coach strap depends on sequence continuity, timestamps, and atomic commit so downstream analysis never has to guess whether a gap is real behavior or a transport artifact.

Storage choice (FRAM vs flash — tradeoffs that matter here): FRAM favors frequent small writes with low write energy and strong power-fail behavior; flash offers capacity but imposes program/erase constraints and can create higher write pulses and endurance pressure. The right choice depends on record rate, retention window, and how aggressively peak current must be controlled.

Structured record (minimum fields that make trust verifiable): every record must carry enough structure to detect duplication, reorder, and gaps. The minimum is timestamp + sequence + CRC + quality flags. If a quality gate was active, the record must carry that evidence so the stream remains interpretable across sessions and reconnects.

Power-loss and reset handling (atomic commit + checkpoint): logging must be resistant to partial writes. A robust approach is two-phase commit: write payload first, then write CRC/header, and only then write a small commit marker as the final step. On boot, recovery scans the tail region to find the last committed record, restores the write pointer, and sets seq_next without creating duplicates or holes.

Validation (statistics, not promises): integrity should be verified under randomized power cuts while writing and transmitting. Metrics must explicitly count duplicates, reorders, and gaps, and correlate these with reset_reason and commit_fail evidence. The acceptance goal is not “mostly okay” but “explainable and bounded.”

H2-11. Validation & Field Debug Playbook (symptom → evidence → isolate → fix)

Intent: convert Chapters H2-1~H2-10 into a field-ready SOP. Each symptom starts with two measurements that separate contact vs timing vs link vs power vs logging. Fix actions aim to stop wrong outputs first (quality gates), then restore stable operation (state recovery), then harden evidence (seq/CRC/commit).