The wrist is the most demanding edge AI deployment in consumer electronics: continuous biosensing at single-digit milliwatt budgets, medical-adjacent accuracy expectations, and health data users absolutely do not want in a cloud they don't control.
This guide covers the biosignal processing patterns — PPG, ECG, IMU — and the models that run them on the device.
The biosignal pipeline
PPG (the optical heart-rate sensor) is the workhorse: green-light reflectance modulated by blood flow, sampled at tens of Hz. From clean PPG, on-device models derive heart rate, HRV features, rhythm irregularities, and — fused with IMU — sleep stages and activity states. ECG (where present) adds morphology detail for arrhythmia classification.
The engineering challenge is motion artifact: PPG is exquisitely sensitive to movement, and a running wearer's signal is mostly noise. The standard fix is sensor fusion — accelerometer channels fed to the model (or an adaptive filter) as motion reference, letting the pipeline subtract or ignore corrupted windows rather than report garbage.
Anomaly detection on the body's baseline
Health features are individual: resting HR, HRV range, sleep architecture vary person to person. The winning pattern is personalized baselining — models that learn the individual's normal and flag deviations (elevated resting HR, HRV suppression, arrhythmia episodes) rather than apply population thresholds.
This mirrors the pet-device playbook at higher stakes: anomaly detection first (flag drift from personal baseline), supervised classifiers for the specific known patterns (AFib detection, fall detection) trained on clinical and fleet data. Events escalate to the app; the raw biosignal stays on the wrist.
- PPG: HR, HRV, rhythm flags, SpO2-adjacent features
- IMU fusion: motion-artifact rejection + activity context
- Anomaly baselines: personal normal, flag the deviation
- On-device = health data stays on the wrist
Sleep, activity, and context fusion
Sleep staging from a wrist device is pure edge fusion: IMU (movement) + PPG (heart rate, HRV) + sometimes temperature, classified into wake/light/deep/REM by models small enough to run continuously overnight at microwatts. The classifier sees windows of features and temporal context — sleep architecture is a sequence problem, not a single-window one.
Activity recognition provides context for everything else — 'resting HR elevated while sitting' means something different from 'elevated while running'. The activity model isn't just a feature; it's the context conditioner for every other inference on the device.
Regulatory reality and privacy
Health features sit on a spectrum: wellness metrics (resting HR, sleep scores) ship freely; medical claims (AFib detection, apnea screening) trigger regulatory pathways (FDA clearance, CE marking) that take years and clinical trials. Products architect the edge pipeline so wellness insights ship now and cleared features land via OTA later.
On-device processing is the regulatory and trust accelerant: health inferences that never transmit raw biosignals have a fundamentally easier privacy story — GDPR, HIPAA-adjacent obligations, and consumer trust all favor 'the sensor data stays on your body'.
Where it shows up
Arrhythmia flagging
PPG + ECG rhythm analysis detects irregular episodes on the wrist — raw biosignals never leave the device.
Fall detection
Impact signature plus post-impact stillness triggers alerts, with multi-signal confirmation to kill false alarms.
Sleep & recovery tracking
IMU + PPG fusion stages sleep overnight at microwatts, building personal baselines for recovery metrics.
Frequently Asked Questions
How accurate is on-device heart monitoring?
Continuous PPG heart rate is production-mature — within a few percent of chest-strap ECG for rest and moderate activity, degrading under high motion (which is why artifact rejection matters more than model quality). Arrhythmia detection (AFib) achieves high sensitivity/specificity in cleared devices; the limiting factor is signal quality during episodes, not the classifier.
What's the battery impact of continuous biosensing?
The optical sensor dominates the budget — LEDs and photodiodes draw more than the inference. Duty-cycling the PPG (sample bursts every few minutes rather than continuous) plus always-on IMU at low rate is the standard compromise, with continuous PPG reserved for workouts or medical-grade modes.
Can wearables detect falls reliably?
Yes — impact signature plus post-impact stillness is a well-defined pattern, and fall detection ships broadly. The engineering is false-alarm management (a slammed arm is not a fall) through multi-signal confirmation, and the hard part is coverage of slow collapses vs impact falls — handled by behavior-anomaly models on top of the impact detector.
Why process biosignals on-device instead of phone or cloud?
Three reasons: privacy (health data is the most sensitive telemetry users carry), battery (streaming continuous PPG over BLE costs more than inferring it), and reliability (the device keeps monitoring when the phone's away). The phone syncs compact insights — the device is the sensor, the analyst, and the privacy boundary.
Building something that should run AI on-device?
Edgehound designs, compresses, and deploys TinyML models on microcontrollers — from feasibility audit to field-ready firmware.