0) Problem Restatement
Apple asked a systems-level question: design the sensing subsystem of a smartwatch. Choose sensors, decide sampling rates, decide where processing happens (on the watch, on the phone, in the cloud), and balance accuracy against battery life (the watch should last all day or more). Features include step counting, workouts, heart rate, sleep and fall detection.
1) Sensors and Typical Rates
| Sensor | Used for | Typical rate |
|---|---|---|
| Accelerometer | Steps, activity type, fall detection, wrist raise | 25–100 Hz (bursts up to 800 Hz for falls) |
| Gyroscope | Workout form, gestures | 50–100 Hz, only when needed (power-hungry) |
| Optical heart rate (PPG) | Heart rate, blood oxygen | 25–100 Hz while measuring, periodic in background |
| Barometer | Floors climbed, elevation | ~1 Hz |
| GPS | Outdoor workout routes | 1 Hz during workouts only (very power-hungry) |
| Skin temperature | Sleep, cycle tracking | Every few minutes |
Rule: sample only as fast as the feature needs, and turn expensive sensors on only when needed.
2) Architecture (on the device)
Architecture Diagram
flowchart LR
S["Sensors"] --> HUB["Low-power sensor hub (always-on coprocessor)"]
HUB -->|"buffered batches / events"| AP["Main processor - apps, algorithms"]
HUB -->|"wake on event: fall, raise"| AP
AP --> STORE[("Local health store")]
AP -->|"sync when connected"| PHONE["Phone app"]
PHONE -->|"encrypted backup / sync"| CLOUD["Cloud"]- Sensor hub: a tiny low-power chip that reads sensors continuously and runs simple algorithms (step counting, wrist-raise detection, fall-detection triggers). The main processor sleeps most of the time, which is the biggest battery saver.
- Batching: the hub buffers samples and hands them over in batches (e.g., every few seconds or minutes) instead of waking the main CPU for each sample.
- Event wake-ups: important events (a possible fall, a workout start) wake the main processor immediately.
3) Where to Process
- On the watch (low latency, works without the phone, private): steps, heart rate, fall detection, workout metrics shown live.
- On the phone (more compute and battery): longer trend analysis, sleep stages from the night's data, and syncing.
- In the cloud (optional, with consent): long-term history, backups, and population-level model improvements.
4) Algorithms (simple explanations)
- Step counting: filter the accelerometer signal, detect peaks with a regular rhythm (about 1–3 steps per second), and ignore arm movements that aren't walking.
- Heart rate (PPG): green LEDs light the skin, and a sensor measures reflected light that pulses with blood flow. Motion adds noise, so use the accelerometer to cancel motion artifacts and track the heart-rate frequency over time.
- Fall detection: a hard impact (high acceleration spike) followed by no movement → ask the user "Are you OK?" and call emergency services if there's no response.
- Adaptive sampling: higher rates during workouts, lower rates during rest or sleep.
5) Battery, Accuracy and Privacy
- Battery budget per feature: GPS and continuous PPG are the biggest costs, so use them only when needed (workouts, and periodic background checks).
- Accuracy is validated against reference devices (chest straps, lab equipment) across skin tones, wrist positions and activities.
- Health data is encrypted on the device and in sync, and the user controls what is shared.
6) Wrap-Up
Choose sensors and sampling rates per feature, and run always-on sensing on a low-power sensor hub that buffers data in batches and wakes the main processor only for important events. Process on the watch for real-time features (steps, heart rate with motion-artifact removal, fall detection), on the phone for heavier analysis, and in the cloud only for opt-in history. Adapt sampling to activity, use GPS and PPG sparingly for battery, validate accuracy broadly, and protect health data end to end.