title: "Three Ways mmWave Fall Detection Goes Wrong (and Why 'Detects Falls' Is Not a Spec)"
tags: mmwave, radar, iot, homeassistant, embedded
canonical_url: https://249263431.github.io/60GHz-Radar-SDK/fundamentals/2026/10/17/fall-detection-failure-modes.html
You would think "fall detection" is a solved problem. A person falls, the sensor notices, an alarm fires. In practice, the sensing problem behind that sentence has three distinct failure modes, and each one behaves differently in a real room.
This post is a field note from building 60GHz mmWave radar modules for elderly care. No marketing claims — just the failure modes, why they happen, and how to evaluate a device before you put it in someone's bathroom.
Why the demand is real
For an elderly person with reduced mobility — unsteady gait, a cane, limited strength — a fall is not a health metric. It is an event where somebody needs to know, quickly, so the person can be helped up.
That requirement is strict in both directions: the false alarm rate has to be low enough that the alarm is believed, and the missed-event rate has to be low enough that it is trusted. Those two pull against each other, and that tension is the source of everything below.
Failure mode 1: nobody is there, but the radar reports someone
A bathroom is full of things that move without a person present. An open window lets a curtain move. A leaking container drips. A toilet flushes. An extractor fan vibrates. Each produces a radar return, and a return from a low, stationary-looking target is exactly what a fall looks like.
The sequence is:
- An interference source produces a return.
- The radar classifies it as a target rather than clutter.
- The target is low and does not move.
- A low, stationary target is the signature the detector looks for.
- An alarm fires — in an empty room.
This is the mode that matters most at scale. A single false alarm is an inconvenience. A deployment of hundreds of units, each producing occasional empty-room alarms, produces a stream of notifications nobody acts on — and once occupants learn the alarm is usually wrong, they stop responding to it, including when it is right.
What helps: knowing whether a person is actually present (entry/exit tracking, or a corroborating signal) removes most candidates before the posture judgement runs. A single-door bathroom is a much easier problem than an open room.
Failure mode 2: someone is there, but the posture is misread
Three ordinary activities that get misclassified:
| Activity | What the radar sees | What it concludes |
|---|---|---|
| Squatting to wash clothes | Hand/arm movement at low height, head still | A person struggling on the floor |
| Mopping the floor | A moving object at floor level | A low, moving target |
| Sitting, swinging a leg | Foot movement low, torso still | Movement near the floor without a head |
The common mechanism: the radar over-weights low-level movement and under-weights where the person's mass actually is. Judging posture from the whole target — height, centroid, and movement at different heights together — is what reduces this, not any single threshold.
Failure mode 3: when there is no descent
The most reliable trigger for a fall detector is a rapid descent: a tall target collapses into a wide, low one within about a second. That transition is distinctive, and most detection chains are built around it.
Not every fall produces it. A person who slowly slides off a toilet and comes to rest on the floor has not descended in the radar's sense — height changed, but gradually, without the rapid motion the detector expects. Same for a slow slump against a wall.
The result is a missed event in exactly the scenario where the person is least able to get up. This is a limitation of the approach, not a tuning problem: a detector that requires a rapid descent will miss slow ones; one that does not will report every sit-down as a fall. No setting gives both.
The problem above all three: "a fall" is not a spec
Consider what a real deployment has to answer:
- Lying flat is clearly a fall. Is lying prone also a fall?
- Is a person sitting on the floor against a wall a fall, or a rest?
- Is a slow slide from seated a fall, or a collapse?
- Is a person who falls and gets up unaided a reportable event?
Every one is a real scenario, and every one is answered differently by different vendors. "Detects falls" in a spec covers all of them and none of them. The practical fix is to write acceptance criteria as scenarios, not capabilities:
Detects a person lying flat on the floor within 10 seconds, in a 2 m × 3 m bathroom with the door closed.
That is testable. "Fall detection" is not.
Before you buy or deploy
- Ask for the empty-room test. Running fan, hanging cloth, dripping tap, toilet flush, nobody present. If it alarms, mode 1 is unaddressed.
- Ask for the normal-activity test. Squatting, mopping, sitting and leg-swinging. These are mode 2.
- Ask specifically about slow descents. Not "does it detect falls" — ask whether it reports a person who slowly slides from seated to the floor.
- Ask what environment the false-alarm rate was measured in. A rate from an empty, interference-free room is not a rate.
- Write acceptance as scenarios, not capabilities. A product that passes a scenario list can be verified on delivery.
Where this comes from
I maintain the documentation and SDK for a line of 60GHz mmWave radar modules (fall detection, sleep monitoring, presence detection) that speak Wi-Fi + MQTT and integrate with Home Assistant. The full write-up of these three failure modes, including the acceptance-criteria section, is here:
Docs and guides: https://249263431.github.io/60GHz-Radar-SDK/
If you are evaluating mmWave radar for a care deployment, the setup guide and MQTT topic reference there are the practical starting point.
Top comments (0)