I Built a Fall Detector. The Data Killed It.

I set the watch down on my desk, face up, the way you’d put down a phone. Ten seconds later it buzzed, lit up, and started counting down to calling my family.

Nothing had happened. Nobody had fallen. And it took me longer than I’d like to admit to accept that the detector had not malfunctioned — it had done exactly what I built it to do. A watch dropped onto a hard desk is a fall, as far as an accelerometer strapped to a wrist can tell. There was a sharp deceleration, the orientation changed from upright to flat, and then it lay perfectly still. Every stage of my carefully staged detection cascade fired in order, and the cascade was right about every one of them.

This is what came of building a wrist-worn fall detector, measuring it properly, and concluding that it should never be allowed to page anyone. I’ll walk through how these things are supposed to work, the two numbers that killed mine, and the part I genuinely did not expect: the published research has been saying the same thing since 2008, and mostly nobody acts on it.

What I was building, and why

A family member has limited mobility and lives at home. The goal was unglamorous — a watch that notices a fall, waits a few seconds in case it’s wrong, and escalates to a small relay server that texts and calls a list of family contacts if nobody cancels.

The hardware is a LilyGO T-Watch Ultra: an ESP32-S3, a Bosch BHI260AP motion sensor, a screen, a vibration motor, a LoRa radio, and a battery. The firmware is mine. The detection logic lives in plain C with no Arduino or FreeRTOS dependencies, so it compiles on my laptop and I can replay recorded motion through it in a test harness. There are signed over-the-air updates that refuse to install older versions, HMAC-signed alerts with replay protection, and a journal that writes an alert to flash before it tries to send it, so a network outage can’t quietly swallow one.

All of that works. None of it is what went wrong.

How fall detection is supposed to work

Nearly every accelerometer-based fall detector is a state machine looking for the same four-part signature, in order. Mine was built from the published descriptions, and it looks like this.

The logic is sound and the staging genuinely helps. A gesture that spikes past 4 g does nothing, because no free-fall preceded it. A free-fall with a soft landing does nothing, because no impact followed. Getting straight back up after a stumble cancels the whole thing at stage four.

Read the sequence again, though, and notice what it actually describes: an object that dropped, hit something hard, ended up at a different angle, and then stopped moving. A person collapsing on a kitchen floor fits. So does a watch meeting a desk.

The first number: how often it cried wolf

I wore it for a day and logged every verdict.

Twenty-five alerts in five hours and twenty minutes. One false alarm every thirteen minutes.

The same watch, left on a table for fifteen hours, produced zero. Every one of those alarms was caused by ordinary living — setting a mug down hard, dropping my arm onto the armrest of a chair, putting the watch on and taking it off, resting a hand flat on a table and leaving it there.

Any one of those, on its own, would be a tuning problem. You raise a threshold, you lengthen a window, you move on. Twenty-five an hour and a half is a different kind of message.

The second number: how often it caught an actual fall

The false alarm rate is the easy half to measure, because you only have to wear the thing. Measuring the other half — how many real falls it catches — means having real falls, and I am not going to produce those on demand.

So I used a public research dataset, FallAllD, which recorded 15 volunteers performing falls and everyday activities with sensors at the wrist, the waist, and on a neck pendant simultaneously. I pulled the wrist channel, converted every trial into my replay format, and ran the exact production detection code over all of it.

258 of 523 falls reached the alerting verdict. 49.3%.

Where that data comes from, exactly

Since the whole argument rests on this dataset, here is precisely what it is.

FallAllD was collected by Majd Saleh and Régine Le Bouquin Jeannes, published open-access on IEEE DataPort in April 2020, and described in IEEE Sensors Journal the following year. Fifteen participants wore three data-loggers simultaneously — waist, wrist, and neck — each carrying an accelerometer, gyroscope, magnetometer, and barometer. It runs to 26,420 files.

Reading the archive rather than trusting a description of it, the structure is:

• One file per sensor per trial, named like S01_D1_A013_T01_A.dat — subject, device, activity, trial, sensor. Accelerometer and gyroscope arrive as separate files and have to be paired; there is no combined record.
• Each is a headerless three-column CSV of raw 16-bit integers, exactly 4,760 rows — 20.000 seconds at 238 Hz, constant across every file I checked.
• Activity IDs split cleanly: 001–044 are everyday activities, 101–135 are the 35 fall types. Seventy-nine IDs across fifteen subjects.

Three things about it are worth stating plainly, because each one could have quietly produced a wrong headline number.

The falls are simulated. Participants fell deliberately, knowing it was coming. This is standard practice and it is the only ethical way to build a dataset like this, but it is exactly the gap Bagalà’s study is about.

No README ships in the archive, so which device is the wrist is inferred. I worked it out from three independent signals that agree: twelve activities exist only on device 2 and are all wrist-specific gestures the torso mounts never saw; device 2 has the highest gyroscope RMS of the three; and device 2 shows by far the widest spread of mean gravity direction across trials, which is the signature of a mount that rotates freely. Waist and neck mounts do not do that. Reading the wrong device would have silently produced a waist-mounted recall figure and I would never have known.

The raw values are integers, and the scale factor is not given. My converter refuses to run without an explicit scale, and there is a separate step that infers it from physics — a resting wrist must read 1 g — and reports every candidate against that standard. The scale turned out to be 1/4096 g per count. Getting this wrong by a factor of 4096 produces a perfectly plausible-looking recall number computed from nonsense, with nothing on the surface to show it.

I also left the data at its native 238 Hz rather than resampling to the 100 Hz my firmware runs at. I tried resampling first, and measuring it showed the interpolation was quietly shaving peaks off impacts — the thing the detector keys on.

It missed slightly more than half. And here is the detail that mattered most to me: of the falls it missed completely, 61% had an impact peak comfortably above the 4 g threshold. The detector saw the impact perfectly well. It threw the event away at the orientation stage.

Both numbers at once

Either number alone leaves you somewhere to go.

A detector that catches 49% of falls but is otherwise silent is a weak safety net that might still be worth wearing. A detector that catches nearly everything but shouts too often is annoying, and you tighten the thresholds and trade some sensitivity for quiet.

Mine did both simultaneously. It missed half of what it existed for while paging roughly three times an hour. There’s no threshold adjustment that resolves that, because the two problems pull in opposite directions and neither one has any slack. Tightening it to silence the false alarms pushes recall below 49%. Loosening it to catch more falls makes an already unusable alarm rate worse.

There is no operating point. That’s the whole finding, and it took measuring both axes to see it — which is precisely why I think most people never see it.

Why it misses: your wrist doesn’t know what your body is doing

Stage three is where the falls died, and stage three is the one carrying an assumption I’d never examined: that the sensor’s orientation tells you the body’s orientation.

Strap a sensor to somebody’s waist and that assumption is close enough to true. The torso is upright when standing and horizontal when lying down, and the gravity vector rotates roughly 90° between the two.

Your wrist does no such thing. Your arm rotates through most of that range while you’re making a sandwich. It can end a genuine fall pointing in almost any direction, including the one it started in — if you fall while reaching for a railing, your forearm may finish more or less where it began, and the stage sees nothing worth reporting.

I could test this directly, because FallAllD recorded all three sensor positions during the same falls. Same subjects, same events, matched trial by trial.

Nineteen points sitting in the mounting position tells you the orientation stage was the problem all along. It also tells you that relocating the sensor doesn’t rescue the idea — a pendant still misses more than a third of falls, and comes with its own well-known problem, which is that people don’t wear pendants. Stigma, forgetting, taking it off in the shower and leaving it there, leaving it on the charger through the night.

Wear rate doesn’t sit beside the recall number; it multiplies against it. Fleming and Brayne followed 110 people over ninety for a year and found that 82% of falls happened while the person was alone, and that 80% of those who fell and had a call button did not use it — not wearing it, knocked unconscious, or too shaken by the fall to press. Those were manual buttons, so the figure measures wearing and not detecting, but it’s the same term in the same product: whatever recall you achieve, you multiply it by the fraction of falls where the device was on the body at all.

I haven’t measured that fraction for my own watch and I’m not going to invent one, but the direction is clear without it. The pendant’s nineteen-point lead survives only if the pendant is worn, and the best real-world evidence says it mostly isn’t — which is exactly why wrist devices dominate the market despite worse physics. Neither mount produces a number you’d stake someone’s safety on.

None of this was new, either. In 2008, Kangas and colleagues ran essentially the same comparison — accelerometers at the waist, the wrist and the head, threshold algorithms simpler than mine — and got 97–98% sensitivity at the waist and the head against staged falls by three middle-aged volunteers. Those top-line numbers carry exactly the caveat this article is about. Their finding on the third position needs no such caveat: the wrist, they concluded, “did not appear to be an applicable site for fall detection.” Eighteen years before I measured 44.4%, that sentence was sitting in Gait & Posture.

This is not just my detector

Here’s the part I wasn’t expecting, and the reason I’m writing this up rather than quietly deleting the repo.

In 2012, Fabio Bagalà and colleagues published a study in PLOS ONE, Evaluation of Accelerometer-Based Fall Detection Algorithms on Real-World Falls, that took thirteen already-published fall detection algorithms — algorithms with strong reported results — and ran them against real falls recorded from high-fall-risk patients going about their lives.

Sensitivity collapsed to 57.0% on average, with the best of the thirteen reaching 82.8%. And when they monitored three representative fallers for a day each, the algorithms produced between 3 and 85 false alarms per day.

Set that beside my results:

	Bagalà 2012, thirteen published algorithms	Mine, 2026
Falls caught	57.0% average	49.3%
False alarms	3–85 per day	~25 in 5h20m

I landed inside their range on both axes, at the wrist, fourteen years later, with a considerably better sensor. I had independently reproduced a result that was already in the literature — which is reassuring about my measurement and depressing about the state of the field.

Two details make my number worse:

• My 49.3% was measured against staged falls. FallAllD volunteers fell deliberately onto padding. Bagalà’s central point is that staged falls are the easy case: real fallers grab furniture, twist, brace, and half-catch themselves, and those compensatory movements smear the clean signature the cascade is looking for. My 49.3% is a ceiling, and real-world performance would be lower. Staged data is also the field’s normal practice, which is the problem with the field’s numbers: Chaudhuri, Thompson and Demiris reviewed more than a hundred fall-detection papers in 2014 and found most of them built on simulated falls, concluding that a system trained that way cannot reach the reliability of one built on real ones.
• Their algorithms were mostly waist-mounted. As my own three-mount comparison shows, that’s the easier position by about nineteen points.

So how do the commercial ones manage?

They engineer around the problem rather than solving it.

Apple biases hard toward severe impacts, waits about a minute for immobility, and requires you to confirm before it calls anyone. It still famously triggers on roller coasters and ski slopes. Medical alert pendants get better numbers largely by sitting on the torso, the mount my own data says is worth nineteen points.

That confirmation prompt is doing enormous work. It converts an unsolved detection problem into a “prompt the human” problem, which is tractable. When a vendor advertises 95% accuracy, ask two questions: measured against staged falls or real ones, and what was the false alarm rate over the same period? The second number is almost never printed beside the first, and the pair is what tells you whether the thing works.

Note: None of this is medical advice, and it isn’t an argument against buying a fall-detecting device. A detector that catches half of falls is better than nothing, and the confirmation prompt makes the false alarms survivable. It is an argument against believing the marketing number, and against relying on automatic detection as the only safety net for someone who lives alone.

What survived

The detector is dead. I set a compile-time flag that lets the cascade keep running, keep recording, and keep filling the corpus, while making it structurally incapable of summoning anyone.

What’s left turns out to be most of the value.

The escalating check-in. A far simpler idea, and it needs no training data at all: if the watch has seen no movement for a long time on a wrist it knows is being worn, ask. Buzz, put a prompt on screen, wait a minute, ask harder, and only escalate to family after several increasingly insistent prompts all go unanswered. It catches the slow collapses the cascade is structurally blind to — sliding out of a chair, not getting up in the morning — and it doesn’t need to recognise a fall to work.

It also failed on its first real day: thirteen pages in fifteen hours, three of them for the crime of sitting at a desk for two hours. The difference is that the cascade failed on physics, which no amount of design fixes, and the check-in failed on an unfinished design, which is an ordinary engineering problem.

Knowing whether it’s on a wrist. This one I did solve, and cleanly. Measured over minutes, a worn wrist and a tabletop separate by a factor of about 350 in angular movement — 80.96° against 0.21°. I was worried a sleeping arm would look like a nightstand; the quietest five-minute window in an entire night of sleep still read 1.67°, eight times the tabletop. That’s a real discriminator with margin on both sides, and it kills the desk problem I opened this article with.

The instrument. Detection logic in plain C, a replay harness that runs recorded motion through the exact production code on a laptop, CI that gates every push, and a dataset importer with a units-verification step you can’t skip. Building that took longer than building the detector, and it’s the only reason any of the numbers above exist.

That last part is now on GitHub as detector-replay, generalised so the detector is pluggable — you point it at your own C code, tell it which of your verdicts count as alarms, and it scores recall and false alarms separately. It ships with the cascade above as the worked example, defects and all, the 23 labelled traces including the table set-down that started this, and the FallAllD converter with its units gate. Everything in this article is reproducible from it.

I also wrote down a stopping condition before collecting the data: if the redesigned check-in produces more than about one false page per week over a seven-day trial, the project stops. Deciding that in advance matters, because I know exactly how persuasive I’d find my own excuses afterwards.

What I’d tell you if you’re starting this

Measure both axes, or you’ve measured nothing. Recall alone and false-alarm rate alone each have a story where things are basically fine. Together they closed the question in an afternoon. I spent weeks tuning against a number I hadn’t paired with anything.

Staged data flatters you. Every fall in my dataset was performed on purpose by someone who knew it was coming. Real falls are messier and partially caught, and the published research is unambiguous that performance drops when you move from one to the other. Treat any result from staged falls as an upper bound.

Check what your sensor can physically know. My orientation stage rested on an assumption about wrists that ten minutes of thought would have refuted. It survived for months because I’d written it down confidently, in a design document, where it looked like a decision instead of a guess. The three-mount comparison that finally settled it was an afternoon’s work on data I already had.

Read your own instruments. My firmware printed a hardware capability bitmask on every single boot for nineteen days. I decoded two bits of it. When I finally read the rest, I discovered the board had GPS and an NFC reader on it — both of which my design document explicitly claimed were absent. A number nobody reads isn’t observability; it just looks like it.

The working rule I’ve ended up with, and the one thing here I’d defend without qualification: build the instrument, wear the thing, read the data. Every failure in this project was a plausible premise that nobody had checked, and every one of them was cheap to check the moment I stopped arguing about it and went to measure.

The code

github.com/tiarno/detector-replay — the measurement bench, the fall cascade as its worked example, the trace corpus, and the dataset converter. MIT.

If you’re building a detector of your own — falls, seizures, gestures, machine faults, anything that watches a motion stream and occasionally decides something happened — it’s built to be pointed at your code rather than mine. The README covers what to change. FallAllD isn’t redistributed there; you download it yourself and convert it.

Sources

• Bagalà, F. et al., Evaluation of Accelerometer-Based Fall Detection Algorithms on Real-World Falls, PLOS ONE, 2012 — the thirteen-algorithm study, and the source of the simulated-versus-real gap.
• Chaudhuri, S., Thompson, H. and Demiris, G., Fall detection devices and their use with older adults: a systematic review, Journal of Geriatric Physical Therapy, 2014 — over a hundred papers, most of them measured on simulated falls.
• Fleming, J. and Brayne, C., Inability to get up after falling, subsequent time on floor, and summoning help, BMJ, 2008 — 110 people over ninety, followed for a year; 80% of those who fell and had a call button didn’t use it.
• Kangas, M. et al., Comparison of low-complexity fall detection algorithms for body attached accelerometers, Gait & Posture, 2008 — waist, wrist and head compared directly, and the wrist ruled out.
• Saleh, M. and Le Bouquin Jeannes, R., FallAllD, IEEE DataPort, 2020 — 15 participants, simultaneous wrist, waist and neck loggers. Described in IEEE Sensors Journal, 2021.