Fall Detection System

بسم الله الرحمن الرحيم

Falls kill hundreds of thousands of people worldwide every year. The risk goes up sharply in rehabilitation and senior care contexts, where a patient can be alone in a room for hours and where a delayed response to a fall turns a manageable injury into a serious one. That was the problem statement my team and I picked up for our UofA capstone: build a wearable that catches a fall in real time and gets a caregiver's attention, without recording anything a patient wouldn't want recorded.

The result was the FDS pendant. It's small, it clips to a lanyard, it runs on a rechargeable Li-Ion cell, and it processes fall detection entirely on-device before firing a BLE alert to a caregiver's phone.

The sensor and processor choice

The core of the pendant is a Bosch BNO055 IMU. It gives us accelerometer data on three axes, gyroscope data on three more, and an on-chip sensor fusion output that lets us treat it as a black box for orientation. We looked at cheaper IMUs (BMI160, MPU6050) but the BNO055's fused output meant we could focus on the fall-detection algorithm instead of tuning our own Kalman filter for orientation drift, and the reduced processing load on the MCU was worth the extra dollar per unit.

For the processor we used an ATmega328. It's an 8-bit AVR, which sounds underpowered for a body-worn sensor node in 2025, but the algorithm we settled on is simple enough that a 328 handles it with cycles to spare. And the AVR toolchain in MPLAB is what my team was already comfortable with, so we could focus on the sensor pipeline and the BLE integration instead of learning a new stack under a deadline.

The algorithm

The fall detection logic is rule-based, not machine-learned. That was a deliberate choice. An ML model would probably be more accurate, but it would need training data we didn't have, and it would be harder to explain why it fired when it fired. For a medical-adjacent product, being able to reason about the code that decides an alert is worth a lot.

The rule looks for a signature: a brief impulse in the total acceleration magnitude, followed by a low-motion window. Standing up, sitting down, or leaning over gives you a slow ramp in acceleration. A fall gives you a sharp spike followed by stillness on the floor. Tunable thresholds set the impulse size, the debounce window before we consider it a real event, and the recovery-time expectation.

if (peak_accel > IMPULSE_THRESHOLD &&
    time_since_peak < RECOVERY_WINDOW &&
    current_accel < REST_THRESHOLD) {
  fire_alert();
}

Simplified, but that's the shape of it.

The wireless side

Alerts fire over BLE through an HM-11 module to a companion Android app. The app itself is minimal: a device list, a "connect" button, and a big status readout that turns red on a fall event and stays red until a caregiver acknowledges it. TinyDB (a Kivy-adjacent local storage layer) holds the acknowledgement log.

BLE was the right choice over WiFi or LoRa for two reasons. Range is short but adequate for a rehabilitation room. And power draw is low enough that the pendant runs for days on a small Li-Ion cell, which matters because a wearable that dies in the middle of a shift is worse than useless.

PCB design notes

The pendant is a custom two-layer PCB designed in KiCad. A few things I paid attention to:

• The BNO055 sits near the geometric centre of the board so orientation readings aren't biased by the pendant's own rotation. If the IMU were near the edge, the pendant swinging on a lanyard would give the fusion output a hard time.

• The HM-11 module goes at one edge with a clear-space keep-out around the antenna, otherwise nearby copper detunes it.

• The power circuit (MCP73832 charger, MIC5504 regulator) is tucked in a corner with bypass caps on every regulator input and output, and a physical gap between the analog and digital ground planes with a single tie-point under the MCU.

• The tactile switches for reset and calibration are debounced with an RC low-pass network on the input side, because a bounce that lines up with a fall event is exactly the wrong time to get a false trigger.

What we learned

Threshold calibration was harder than the hardware. Too sensitive and any sharp movement (sitting down heavily, dropping the pendant on a table) triggered an alert. Too loose and slow falls, which are the more dangerous kind because they usually involve losing balance rather than tripping, went undetected.

We spent most of the second semester logging raw IMU streams during simulated falls onto padded mats, and comparing them against the signatures of everyday movements. There's a bias in that data: our simulated falls were all controlled, deliberate drops. A real fall involves flailing arms, grabbing at something, and other body reactions that alter the acceleration signature. If I did this again, I'd want to partner with a rehabilitation clinic and log real events (with consent and privacy controls) before finalizing the thresholds.

The full report has the schematics, PCB layout, algorithm listings, and test results.

Salaam.