SDK and documentation for 60GHz mmWave radar sensors.
by
Fall detection is one of the most requested features in elderly care sensing, and one of the least straightforward to deliver. The name suggests a single clear event — a person falls, an alarm fires — but the sensing problem behind it has three distinct failure modes, and each one behaves differently in a real room.
This article describes those three modes: two kinds of false alarm and one kind of missed event. It also covers a problem that sits above all of them, which is that “a fall” is not a precisely defined acceptance criterion. Understanding these four things is the difference between a fall radar that works in a deployment and one that generates complaints.
For an elderly person with reduced mobility — unsteady gait, a cane, limited strength, or partial loss of independence — a fall is not a health metric. It is an event where somebody needs to know, quickly, so that the person can be helped up.
That is a different requirement from sleep monitoring or presence detection. Nobody is harmed by a sleep score that arrives late. A person lying on a bathroom floor for forty minutes is harmed by an alarm that did not fire, and by an alarm that fired three times the previous night for no reason.
So the sensing requirements are strict in both directions at once: 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 the alarm is trusted. Those two requirements pull against each other, and that tension is the source of everything below.
The first failure mode is an alarm raised in an empty room.
A bathroom is full of things that move without a person present. An open window lets a curtain or a towel move in the air flow. A leaking container drips. A toilet flushes. An extractor fan vibrates. Each of these produces a radar return, and a return from a low, stationary-looking target is exactly what a fall looks like.
The sequence is:
This is the failure 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 continuous stream of notifications that nobody acts on — and once occupants learn that the alarm is usually wrong, they stop responding to it, including when it is right.
Reducing this mode is mostly about the room, not the algorithm. Knowing whether a person is actually present — through entry and exit tracking, or through a corroborating signal — removes most of the candidates before the posture judgement runs. That is why a single-door bathroom is a much easier sensing problem than an open room, and why the scene matters as much as the sensor.
The second failure mode is an alarm raised while a person is present and doing something entirely normal.
Three examples, all of them ordinary activities:
| Activity | What the Radar Sees | What It Concludes |
|---|---|---|
| Squatting to wash clothes | Hand and arm movement at low height, head relatively still | A person struggling on the floor |
| Mopping the floor | A moving object at floor level, low and wide | A low, moving target |
| Sitting on the toilet, swinging a leg | Foot movement at low height, torso still | Movement near the floor without a head |
The common mechanism is a mismatch between what the radar weights and where the person’s mass actually is. A radar that over-weights low-level movement and under-weights the position of the torso will read a squatting person as a collapsed one, because the hands are moving and the head is not.
This mode is harder to remove than the first one, because the person really is there. Entry and exit tracking does not help — the person never left. What helps is judging posture from the whole target rather than from a single region: height, centroid, and the ratio of movement at different heights together, rather than any one of them alone.
The third failure mode is the one nobody wants to talk about, because it is the one that matters most.
A fall detector’s most reliable trigger is a rapid descent: a tall target collapses into a wide, low one within about a second. That transition is distinctive, and it is what most detection chains are built around.
Not every fall produces it.
A person sitting on a toilet who slowly slides sideways and comes to rest on the floor has not descended in the radar’s sense. Their height changed, but gradually, and without the rapid motion the detector is looking for. The same applies to a slow slump against a wall, or a controlled lowering after dizziness.
The result is a missed event in exactly the scenario where the person is least able to get up.
This is a genuine limitation of the approach, not a tuning problem. A detector that requires a rapid descent will miss slow descents. A detector that does not require one will report every sitting-down and lying-down motion as a fall. There is no setting that gives both.
Above the three failure modes sits a problem that is easier to state than to solve: nobody agrees on what counts as a fall.
Consider the questions a real deployment has to answer:
Every one of these is a real scenario, and every one is answered differently by different vendors, different products, and different care providers. The word “fall” in a specification covers all of them and none of them.
The practical consequence is that two products with the same quoted capability can behave completely differently on site, and a buyer cannot tell which from the specification. It also means that a requirement written as “detects falls” cannot be verified on delivery, because there is no shared definition of the thing being verified.
This is why scenario-based acceptance matters more in this category than in any other sensing category. “Detects a person lying flat on the floor within 10 seconds in a 2 m × 3 m bathroom with the door closed” is testable. “Fall detection” is not.
Five checks that separate a product with real deployment experience from one with a specification sheet.
The fifth point is the one that changes outcomes. It moves the conversation from what the product claims to what the product does in your room.
Three things in this category do not have clean answers, and it is worth being explicit about them.
None of these are solved by a better algorithm alone. They are solved by matching the detection logic to the room, by writing acceptance criteria that can actually be tested, and by being explicit about which cases a given product is and is not specified for.
Fall detection has three failure modes, and they are different problems with different causes. Empty-room alarms come from interference that resembles a low, stationary person. Misread postures come from weighting low-level movement over the position of the torso. Missed events come from requiring a rapid descent that a slow collapse does not produce.
Above all three sits the definition problem: “a fall” is not a precisely defined event, so a specification that says “detects falls” cannot be verified.
Evaluate a fall radar by asking for the empty-room test, the normal-activity test, and the slow-descent test, and by writing your acceptance criteria as scenarios rather than capabilities. The products that survive those four questions are the ones that have been deployed rather than only specified.
tags: fall detection - false alarm - missed detection - acceptance criteria - mmwave radar