Wearable Fall Detection for Older Adults Living Independently

The problem for older people living alone

A fall is dangerous on its own, and much worse when nobody knows it happened. An older person who lives alone, or is alone during the day while family is at work, can be on the floor for hours. Families worry about this constantly, and the usual answer is a phone call twice a day.

Detection devices exist, and many end up in a drawer. The most common reason is false alarms: the device fires when the wearer sits down heavily or drops it on a table, the family panics, and after a week everyone agrees to stop using it. Anyone building in this space has to optimise for trust first.

What already exists and the gap

• Apple Watch has built-in fall detection: after a hard fall it alerts, waits, and if the wearer is still, runs a countdown before calling emergency services. Apple itself states it cannot detect all falls and may treat high-impact activities as falls.
• Pendant medical alarm services combine a neck pendant with a monitored call centre, usually on a monthly subscription and mostly in the US and Europe.
• Research datasets such as SisFall provide labelled falls and daily activities from young and older volunteers, and are used to benchmark detection algorithms.

The gap is a low-cost, open, private device that a family can buy once, that works with the phone already in the house, and whose false alarm rate is measured and published rather than hidden. A smartwatch is expensive, needs daily charging and a compatible phone; call-centre services are not available or affordable in many countries.

What you build

• Wearable: a microcontroller with an IMU, a vibration motor, a button and a small battery, in a wrist strap.
• On-device pipeline: a cheap impact trigger that wakes a small classifier, which decides fall or not-fall from a short window around the impact.
• Alert flow: the device vibrates and beeps, the wearer has a short window (for example 30 seconds) to press cancel, and only then is the phone told.
• Phone app: pairs over BLE, stores contacts, sends the alert by SMS or push, and keeps a history of alerts and cancellations.

The technically interesting part

The metric. Report false alarms per day of normal wear first and sensitivity second. A device that catches every fall but fires twice a day will be removed within a week, and then its sensitivity is zero. Choose the decision threshold by plotting both across thresholds and justify where you land.

The data, handled ethically. You cannot ask older people to fall. Standard practice is simulated falls onto crash mats by young volunteers, with the limitation stated honestly because real falls in older adults have different dynamics. Combine your recordings with a public dataset for falls, but collect your own daily-activity data realistically, since that is where false alarms come from: sitting down hard, lying on a bed, clapping, dropping the device, a bumpy rickshaw ride.

On-device inference. Streaming raw IMU data over Bluetooth drains the battery and exposes private movement data. A two-stage design (a threshold trigger, then a quantised model only when triggered) keeps the radio quiet and the battery lasting. Show measured current in each state.

How to evaluate it

• False alarms per day across at least 7 days of real wear by several volunteers, with every false alarm and its cause listed.
• Sensitivity and specificity on held-out simulated falls, including leave-one-person-out results so the model is not memorising your volunteers.
• End-to-end alert latency from impact to a contact's phone.
• Battery life measured, not estimated.
• Usability: ask 5 older adults (or their family) to wear it for a day and to cancel an alert, and report whether they could.

Suggested plan

1. Weeks 1 to 3: hardware choice, sensor logging, BLE link to a phone.
2. Weeks 4 to 7: data collection protocol, ethics approval from your department, record falls and daily activities.
3. Weeks 8 to 12: feature baseline, then a small neural model, quantisation and deployment on the device.
4. Weeks 13 to 16: alert flow, cancellation window, phone app.
5. Second semester: multi-day wear trials, threshold tuning, battery measurements, write-up.

Path to a product

The first customer is a family with an elderly parent, reached through a clinic, a physiotherapist or a care home that recommends it. A one-time device price plus an optional small subscription for SMS alerts and history is realistic; care homes and home-nursing agencies can be B2B pilots with many devices at once. To scale you need a certified enclosure, a charging dock and clear honesty about limits: it is an alerting aid, not a medical device, unless you later go through the regulatory route.

Scope warning

Detection and alerting only. Do not build a care platform, medical records, GPS tracking, or heart-rate monitoring. Do not design custom hardware before the algorithm works on a dev board. Never claim clinical accuracy from simulated falls.

Learn what you need on Sefism

• Machine learning roadmap : the evaluation and model basics the classifier depends on.
• Machine learning cheat sheet : precision, recall and threshold choice in one place.
• Mobile roadmap : for the companion app and its BLE link.
• Google Colab : train and quantise the model without a GPU at home.
• Kaggle Datasets : find public human-activity data to extend your own recordings.

Get help with this idea

This is a strong project if the false alarm evaluation is honest and the data collection is planned early. Tauseef can help you scope the hardware, set up an evaluation that stands up to examiners, and decide what to leave out. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session