Fall detection in elderly care homes is a question of response time. An unwitnessed fall can progress from an incident into a medical emergency in the minutes before anyone notices. This project addresses that gap with a real-time, server-side detection pipeline that monitors residents through their smartphones and alerts staff the moment a fall is confirmed. It was developed as the term project for the Internet of Things course at Sabancı University.

The problem

Elderly care facilities operate under a difficult constraint: residents move independently through large spaces, and staff cannot watch everyone at once. When a fall occurs, the window for effective intervention is narrow. Continuous manual monitoring does not scale, and many existing wearable solutions struggle with accuracy, battery life, or resident adoption.

The harder problem sits underneath all of this, in the classification itself. Falls are rare events with asymmetric costs. A missed fall, which is a false negative, is the failure the entire system exists to prevent. But a system that raises false alarms is equally dangerous in a subtler way: staff learn to distrust it, and a distrusted alert is no better than no alert at all. Compounding this, models trained on public datasets tend to degrade sharply once deployed, because real facilities introduce variation the training data never captured, such as different phone placements, different resident mobility, and different physical environments.

Reconciling those competing failure modes is where most of the engineering effort went.

What it does

A distributed fall detection system designed to run continuously within an elderly care home. Residents carry smartphones that stream accelerometer and barometer data at roughly 100 Hz to a multi-threaded Flask server. The server buffers the incoming data into fixed windows, applies preprocessing, passes each window through a trained GRU network, and runs a sequence of verification checks before raising an alert. Once a fall is confirmed, a live dashboard surfaces the resident’s location, floor, and battery level alongside the alert so staff can respond immediately.

The architecture is deliberately local-first. The server runs on the facility’s own network, sensor data stays on-site, and inference happens without a cloud round-trip, a decision driven as much by latency and reliability as by the privacy expectations around health data.

Architecture and data pipeline

Sensor collection. Smartphones running the Sensor Logger app capture three-axis accelerometer readings, barometric pressure, GPS coordinates, and battery level. At a 100 Hz sampling rate, each seven-second analysis window holds roughly 700 accelerometer samples, which is dense enough to capture the brief, high-frequency signature of an impact without producing unmanageable data volumes.

Server design. The server is built on Flask with Flask-SocketIO to handle concurrent clients. Each incoming POST to the /stream endpoint appends data to a per-resident buffer. A background worker monitors buffer state; once seven seconds of data has accumulated, it triggers inference. From there, a sliding-window mechanism discards the oldest three seconds and admits the newest three, producing a 57% overlap between consecutive predictions. That overlap is intentional, ensuring a fall occurring near a window boundary is not split across two analyses and missed.

The multi-threaded design is load-bearing here, not incidental. A single-threaded server would block on disk I/O or model inference, serializing requests and introducing latency that the application cannot tolerate. Multiple residents stream simultaneously, and connection events have to be serviced without starving the inference path. Flask-SocketIO’s concurrency model keeps those workloads from contending with one another.

Preprocessing. Raw acceleration is noisy and three-dimensional. Each reading reduces to a single magnitude value, the Euclidean norm of the three axes, which collapses orientation-dependent motion into one signal. A Butterworth low-pass filter then removes high-frequency noise while preserving the lower-frequency dynamics that characterize a fall. The result is a clean 700-point time series suitable for the model.

GRU model and training strategy

Early prototypes using standard feedforward networks and LSTMs did not reach the reliability the task demanded. The final model uses a GRU-based recurrent network: it carries fewer parameters than an LSTM while still modeling the temporal dependencies that distinguish a fall from ordinary movement. The architecture is intentionally compact, with two GRU layers feeding two fully connected layers and a softmax output.

Training data was collected specifically for this deployment context. Public fall-detection datasets predominantly use wrist-worn sensors, and a model trained on that data transfers poorly to a phone carried in a pocket or bag. Closing that gap meant building a custom dataset: controlled falls performed across varied directions, speeds, and landing surfaces, alongside a wide range of non-fall activities such as walking, climbing stairs, sitting, standing, jumping, and dropping the phone.

The class balance was a deliberate modeling decision rather than an artifact of the data. In any real facility, falls are vastly outnumbered by ordinary activity. A naively balanced dataset would let the model achieve high headline accuracy by leaning toward the majority class, which is precisely the behavior that produces missed falls. Training on a 1:3 ratio of falls to non-falls accepts a cost in aggregate accuracy in exchange for stronger sensitivity to the event that actually matters.

A note on the reported test accuracy. The model reached 1.0 on the held-out test set, and that figure deserves scrutiny rather than celebration. The custom dataset, however carefully constructed, was recorded by young and able-bodied volunteers in controlled conditions. Actual residents are older, move differently, and fall in ways the training distribution does not fully represent, including partial falls, slow collapses, and falls involving furniture. A perfect score under those constraints reflects a clean, separable test set more than it predicts field performance. The realistic expectation is meaningful degradation in deployment, and the verification layer described below exists precisely because the raw classifier output should not be relied on by itself.

Verification and latency tradeoffs

Classifying a window as a fall is only the first half of the problem. Confirming it without generating false alarms is the half that determines whether the system is usable.

When the GRU flags a fall, the system does not alert immediately. It collects an additional six seconds of data and evaluates whether the resident has gone still, using the standard deviation of the acceleration magnitude as the measure. Near-zero variation is consistent with a person lying motionless after a fall; continued movement suggests the original prediction was triggered by a hard but benign motion.

A second check uses barometric pressure as a proxy for altitude. A genuine fall does not change the resident’s elevation, since they come to rest on the floor they were already on. A phone dropped on a staircase, by contrast, can register a pronounced altitude change. Confirming that elevation remained stable filters out a meaningful class of false positives.

These checks come at the cost of latency. The first prediction arrives around three seconds in, and confirmation adds roughly six more, putting worst-case detection latency near nine seconds. That is a deliberate trade. In this setting, an alert that arrives a few seconds later but can be trusted is far more valuable than an instantaneous one that conditions staff to ignore it.

Real-time dashboard

The dashboard, served by the same Flask process, presents every monitored resident with their current GPS location plotted on an OpenStreetMap layer, their detected floor, battery level, and fall status. Updates are pushed over WebSocket rather than polled, so the view reflects state changes as they happen. When a fall is confirmed, the resident’s entry is highlighted with a clear alert and their position is immediately visible.

The interface is intentionally minimal. Care staff are working under time pressure and cannot be asked to interpret a complex display: status is legible at a glance, location is always visible, and there are no secondary menus standing between an alert and a response.

Scalability and real-world constraints

The system was containerized with Docker to keep deployment portable across facility networks. CPU-based inference is adequate for a single facility on the order of twenty to thirty residents. Beyond that, meaning larger facilities or multiple sites monitored centrally, CPU inference becomes the bottleneck, and the path forward is GPU acceleration or distributing inference toward the edge.

Access is controlled through token-based authentication, so resident location and health data are visible only to authorized staff. The server is intended to run behind the facility firewall with no public internet exposure, and backups are encrypted at rest.

Key takeaways

The individual technical components here are well-established, since a GRU is a standard architecture and Flask is a standard framework. What made the project demanding was the requirement to reason across every layer at once: sensor characteristics, network behavior, concurrency, latency budgets, verification logic, the realities of how staff would actually use the system, and the failure modes that carry genuine human cost.

The most important lesson was epistemic. A high accuracy score is straightforward to produce and should not be taken at face value. The verification layer and the deliberately skewed class balance both look like compromises against the headline metric, and both are the decisions that would actually make the system trustworthy in the field. Designing for the failure that matters, rather than for the number that looks good, was the central discipline of the project.

A natural next step would move inference toward dedicated wearable devices running the model locally and contacting the server only on a confirmed event, removing the dependence on a carried smartphone and the failure mode of a device left behind on a table.