A wrist device produces a continuous multi-axis signal at tens or hundreds of hertz. Nothing about that stream resembles the single-image, single-inference shape that most on-device machine learning material assumes, and the differences decide the architecture.
Why the model has to be on the device
The argument is bandwidth and energy rather than privacy, though privacy is a real secondary reason. A three-axis accelerometer at 50 Hz with 16-bit samples produces 300 bytes per second of payload — about 25.9 MB per day before any framing overhead. Streaming that continuously over Bluetooth Low Energy means the radio is essentially never asleep, and on a device this size the radio, not the processor, is the dominant consumer. Computing a classification on-device and transmitting one label per window replaces that with a few bytes a minute.
The second reason is latency of a specific kind. A fall detector or an arrhythmia flag that depends on a round trip is a detector that stops working in a lift, on a plane, or when the phone is in another room. Anything whose value depends on firing within a second of the event has to run locally.
The window is the unit of inference
Time-series models on wearables do not classify samples, they classify windows. A window is a fixed span of consecutive samples treated as one example, and the two parameters are its length and its overlap.
The convention the public human-activity-recognition literature settled on is a window of a few seconds with fifty percent overlap. The widely used UCI Human Activity Recognition Using Smartphones dataset, published in the UCI Machine Learning Repository, uses 128-sample windows at 50 Hz — 2.56 seconds — with 50 percent overlap, and that combination is a reasonable starting point for gross activity because it comfortably contains two or three gait cycles.
The length is a real trade and not a convention to be copied blindly. Too short and a periodic activity does not fit inside one window, so the features that distinguish walking from cycling are not present in the data at all. Too long and the window straddles transitions, mixing two activities into one label, and inference latency rises because the decision cannot be made until the window fills. Overlap decouples those slightly: a 4-second window with 75 percent overlap still produces a decision every second, at four times the inference rate and therefore four times the compute energy.
Window lengths, overlaps and any published accuracy for a given configuration are properties of a specific dataset and model. Treat the figures above as a starting configuration to validate on your own signal, not as a specification.
Features against raw signal
There are two families and the choice is mostly about your compute budget. Hand-engineered features compress a window into a few dozen numbers — per-axis mean, variance, min, max, zero-crossing rate, signal magnitude area, correlation between axes, and the energy in a few frequency bands from an FFT — and feed a small classifier. A gradient-boosted tree or a shallow multilayer perceptron on forty features runs in microseconds on a Cortex-M class core and fits in a few kilobytes.
End-to-end models take the raw window. A small one-dimensional convolutional network learns the filters that the hand-engineered set approximates, and typically does better on subtle distinctions, at a cost measured in hundreds of kilobytes and a great deal more arithmetic per window. On a microcontroller running LiteRT for Microcontrollers — the runtime formerly published as TensorFlow Lite Micro — the practical constraint is usually the arena size rather than the FLOPs.
One rotation-invariance detail matters more than model choice for wrist-worn devices: raw per-axis values depend on how the device is oriented, which changes when the user puts the strap on differently. Including the magnitude of the acceleration vector, which is orientation-independent, is usually worth more than a larger model. Quantisation to int8 costs surprisingly little accuracy on these signals because the input is already integer-valued from the ADC; see quantisation for edge deployment.
The memory arithmetic
Work this out before choosing a model, because it frequently decides the answer. Assume a 6-axis IMU — three accelerometer, three gyroscope — at 50 Hz, held as int16, with a 4-second ring buffer:
samples in buffer = 50 Hz * 4 s = 200
values per sample = 6 axes = 6
bytes per value = 2 (int16)
ring buffer = 200 * 6 * 2 = 2,400 bytes
float32 copy for the model input
= 200 * 6 * 4 = 4,800 bytes
FFT scratch (one axis, 256-pt, float32)
= 256 * 4 * 2 = 2,048 bytes
--------
working set before the model ~9.2 kB
On a part with 64 kB of RAM that leaves roughly 50 kB for the model arena and everything else the firmware does. That number, not accuracy, is what rules out the architecture you were hoping to use. If it is tight, the two moves that actually help are running the model on int16 input directly rather than converting a float copy, and computing features incrementally as samples arrive so the full window never has to exist in float form.
PPG is a harder signal than acceleration
Photoplethysmography measures blood volume changes from how much light the tissue reflects, and its signal-to-noise ratio is far worse than an accelerometer’s. Motion moves the sensor against the skin and modulates the optical path, so the dominant artefact is correlated with the very activity you are also trying to classify. This is why devices that report heart rate from PPG almost always feed the accelerometer into the same estimator: the accelerometer provides a reference for the motion component, which can then be suppressed — an adaptive noise cancellation setup rather than a filter with fixed coefficients. That is a fusion problem, described generally in sensor fusion algorithms.
It also means anything derived from PPG needs an explicit signal-quality gate that suppresses output when the input is unusable, and validation against a reference instrument under motion, not at rest. Any wearable output presented as a physiological or clinical measurement is subject to medical device regulation in most jurisdictions; the modelling question and the regulatory question are separate and the second is not one a model architecture answers.
The cascade that saves the battery
The structural pattern that makes always-on wearables viable is a cascade of increasingly expensive stages, each gating the next.
- Stage 0, in the sensor. Most modern IMUs have hardware wake-on-motion and an internal FIFO. Sleep the host processor and let the sensor buffer samples, waking the core once per FIFO fill rather than once per sample. This alone changes the energy picture by an order of magnitude.
- Stage 1, a threshold. A variance check on the magnitude signal distinguishes “still” from “something is happening” in a handful of instructions. If the wearer has not moved, no model needs to run.
- Stage 2, the small model. Runs only on windows that pass stage 1, producing the routine classification.
- Stage 3, off-device. Only the rare, ambiguous or flagged window is transmitted for a larger model or for human review, which is the same reasoning as the edge and cloud preprocessing split.
The duty cycle that falls out of this cascade is what determines battery life, far more than the per-inference cost of the model itself. The arithmetic is worked through in how much battery an on-device model actually uses.
Top comments (0)