A fall-detection wearable has an unusually hard specification. It must watch motion all day without draining its battery, react in well under the time it takes someone to need help, almost never miss a real fall, and almost never cry wolf, because a device that raises false alarms gets taken off. Those goals pull against each other, and the architecture that reconciles them is a cascade, not a single model.
This note describes how we structure an always-on motion pipeline and where the real engineering effort goes. It draws on our on-device fall-detection wearable work, where detection ran locally on a Cortex-M-class MCU with only events, not raw streams, sent over BLE. For the wider constraints on wearable firmware, see wearable device firmware design constraints.
What a fall looks like to an accelerometer
A fall is a sequence, and good detection uses the sequence rather than a single spike:
- Pre-fall motion. A loss of balance or a stumble, which may or may not be distinguishable.
- Descent. A period where measured acceleration drops below normal as the body accelerates toward the ground.
- Impact. A short, sharp spike in acceleration.
- Aftermath. A change in body orientation and often a period of little or no movement.
No single phase is reliable alone. Many everyday actions produce an impact-like spike, and a person can fall and get up immediately. Combining the phases, impact plus a preceding descent plus the aftermath, is what separates falls from the look-alikes.
The cascade: spend energy only when there is a reason
Running a classifier on every sample would waste the battery on a device that spends nearly all its time doing nothing interesting. The standard structure is a tiered pipeline where each stage is more expensive and more selective than the last.
Stage 0 IMU, hardware always on, accelerometer only, interrupt on motion
| wakes only when something happens
Stage 1 MCU, cheap checks impact spike? preceding free-fall? orientation change?
| only candidates pass
Stage 2 MCU, classifier features from the buffered window -> fall / not fall
| only positives pass
Stage 3 Policy post-event stillness, user cancel window, then alert
|
BLE: send the event, not the raw stream- Stage 0 lives in the sensor. Modern IMUs can watch for motion themselves and raise an interrupt, letting the MCU sleep. Use accelerometer-only operation for the always-on path, since adding the gyroscope typically costs more power, and wake it only when a candidate event needs more context.
- Stage 1 is cheap arithmetic. Checks on the buffered samples, such as magnitude and the presence of a preceding low-acceleration phase, reject most false triggers at almost no cost.
- Stage 2 is the classifier. It runs only on candidates, so it can be more capable than if it had to run continuously.
- Stage 3 is policy. The decision to alert is a product and safety decision that sits after detection. It deserves its own design.
Buffering: you have to look backward
By the time an impact is detected, the descent that preceded it is already over. The pipeline therefore keeps a rolling buffer of recent samples, ideally in the IMU's own FIFO or a small ring buffer, so that when the trigger fires it can examine the seconds before and after. The buffer length is set by how long the pre-fall and aftermath phases are, and it directly costs RAM.
// illustrative: a ring buffer lets stage 1 look back before the trigger
on_impact_interrupt():
window = ring_buffer.snapshot(pre = T_before, post = T_after) // wait for post
f = extract_features(window) // magnitude, jerk, orientation delta, stillness
if cheap_reject(f): return // e.g. no preceding free-fall, tiny impact
p = classifier(f)
if p >= threshold: start_confirmation_window()Sampling and range choices
- Full-scale range. Impacts can be large. If the sensor range is set too low, the peak clips and the feature you most want is distorted. If it is too high, you lose resolution on gentle motion. Choose it against recorded data, not by guess.
- Sample rate. Fast enough to capture the impact shape and the dynamics of the descent, no faster. Higher rates cost power in the sensor and processing in the MCU.
- Timing. Rely on the sensor FIFO and hardware timestamps so that irregular MCU wakeups do not smear the timing of samples.
Features that carry the signal
On a constrained device the classifier works from a small set of engineered features rather than raw samples. Typical candidates are the overall acceleration magnitude, its rate of change (jerk), the depth and duration of the low-acceleration phase, the size of the impact, the change in orientation between before and after, and the amount of motion in the period afterwards. Each is cheap to compute on a window of buffered samples, and each can be inspected by an engineer, which matters when you need to explain a false alarm.
This approach also suits the compute limits. A lightweight model, whether a small decision-tree ensemble or a compact neural network, can run within a sub-second budget on a small MCU. Techniques for fitting a model on-device are covered in edge AI quantization.
The real problem: what looks like a fall but is not
Recall on real falls is the easy half to explain and the hard half to guarantee. The daily engineering struggle is false positives from ordinary movement:
- Sitting down abruptly, or dropping into a chair or onto a bed.
- Clapping, hitting a table, or an arm swinging into something, especially on a wrist-worn device.
- Dropping or knocking the device itself.
- Stumbling and recovering without falling.
The remedy is data, not cleverness: a labeled dataset that contains plenty of these near-miss activities alongside falls, so that the model and thresholds are tuned against them. We treat the recall versus false-alarm trade-off as the central tuning problem of the project, and we validate it against a labeled motion dataset covering both falls and fall-like everyday movements.
Datasets, and the honest limits of them
- Simulated falls are not real falls. Much public and in-house data comes from volunteers falling onto mats under supervision, usually younger and more agile than the target users. Real falls by older or frail people can look different. Treat simulated data as necessary and insufficient.
- Placement changes everything. A model trained for a wrist is not valid on a chest or a pendant. Collect data from the actual device, worn as the product will be worn.
- Collect everyday data too. Hours of ordinary wear are what tell you how often the device would false-alarm, and ordinary activity from the real user group is what you cannot simulate.
- Keep a shadow mode. Where the programme allows, run detection silently in the field and log what it would have flagged, then review. It is the cheapest way to measure false-alarm rate on real life.
Measuring it properly
Accuracy is a misleading metric here, because falls are rare and a detector that never fires scores well. Report sensitivity on real or realistic falls, and the false-alarm rate per unit of wear time, for example per day or per week of wear. Those two numbers are what a customer and a clinician actually care about, and the pair should be reported with the dataset it was measured on and how it was collected.
Policy: what happens after detection
Detection is not the same as alerting. After a candidate passes, the device can check for post-impact stillness, give the wearer a short window to cancel a false alarm with a gesture or button, and only then notify. That layer can recover much of the cost of an imperfect classifier, at a price in the time before help is called, which is itself a product decision.
Keep this logic in firmware where possible, so that the safety-critical path does not depend on the phone or the network being present. Our design sends only classified events over BLE, with timestamps generated locally to preserve ordering, which also keeps radio use and battery draw low. The sync side is covered in BLE throughput and sync protocol design.
Fail-safe behavior and claims
- If the IMU stops responding, the device should notice and report that it is not protecting the user.
- Low battery should produce a warning early enough to act on, since a dead device detects nothing.
- Be careful with claims. What a product says it detects, and how reliably, affects how it is regulated and what evidence is required. See fail-safe design for medical wearables and connected medical device regulatory basics.
Checklist
- Is the always-on path accelerometer-only and interrupt-driven?
- Does a ring buffer give the classifier the seconds before the trigger?
- Was the sensor range chosen against recorded impacts?
- Does the dataset include near-miss activities from the intended wear location?
- Are sensitivity and false alarms per day reported, not just accuracy?
- Does the alert policy include a cancel window, and does it work without the phone?
- What does the device do when the sensor fails or the battery is low?
Common questions
How does a fall-detection wearable work?
It watches motion with an accelerometer, often with the sensor itself waking the processor on significant movement. A cascade of checks looks for a fall's sequence, a descent, an impact and an aftermath such as a change of orientation and stillness, then a lightweight classifier and an alert policy decide whether to notify.
Why do fall detectors give false alarms?
Everyday actions such as sitting down hard, clapping, bumping the arm into something or dropping the device can look like an impact. The fix is a labeled dataset that includes these near-miss activities, careful feature design, and an alert policy such as a short cancel window.
Should fall detection run on the device or in the cloud?
For a safety function it should run on the device, so that detection speed and reliability do not depend on network or phone availability. Only classified events then need to cross the radio, which also saves battery.
What metrics matter for fall detection?
Sensitivity on realistic falls and the false-alarm rate per day or week of wear, reported with the dataset they were measured on. Overall accuracy is misleading because falls are rare.