Accelerometer for Activity and Fall Detection

Why accelerometers matter for patient monitoring and elderly care

An accelerometer turns the mechanical event of a fall — a rapid change in velocity followed by an impact — into an electrical signal that a microcontroller can reason about, and that reasoning is what separates a wearable that merely logs motion from one that saves a life. Roughly one in four adults over 65 falls each year, and the time between a fall and discovery is often the variable that determines outcome, not the fall itself.

Clinical need: fall risk stratification and activity assessment

Clinicians use accelerometer data two ways: retrospectively, to score gait variability and fall risk during a clinic visit, and in real time, to trigger an alert when a fall actually occurs. The two use cases demand different sampling strategies — risk stratification can tolerate batched, low-rate data, while real-time detection cannot tolerate missed samples during the 300–500 ms impact window.

Wearable deployment: placement, form factor, and battery constraints

Waist-worn sensors near the center of mass give the cleanest fall signature, wrist-worn units are better tolerated but produce noisier data from arm swing, and chest patches combine accelerometry with ECG at the cost of adhesive wear time. Every placement choice trades signal quality against the thing that actually determines whether the device gets worn: comfort and battery life measured in days, not hours.

Signal interpretation: from raw acceleration to clinical decision

Raw acceleration is a three-axis vector sampled at some rate; a clinical decision is a binary (or graded) alarm. Everything between those two points — filtering, feature extraction, thresholding, confirmation — is where false positives and missed falls actually get decided, far more than in the choice of sensor part number.

How to select accelerometer range, bandwidth, and sensitivity for fall detection

Dynamic range requirements: normal activity vs. impact acceleration

A fall detection accelerometer needs a full-scale range of at least ±8 g, and many designs use ±16 g. Normal daily activity (walking, sitting, rolling over) stays within ±2 g, but the impact phase of a fall can produce transients of 6 g to 10 g for tens of milliseconds, and clipping that peak destroys the one feature most algorithms rely on most heavily.

Bandwidth and sampling rate: aliasing risk and latency trade-offs

Human movement and fall impacts carry most of their energy below 20 Hz, but the impact itself has faster edges, so a sampling rate of 50–100 Hz with an analog or digital bandwidth of 25–50 Hz is the usual working point. Sampling below 20 Hz risks aliasing impact transients into false low-frequency content; sampling above 200 Hz mostly burns power without adding detection value.

Output resolution and noise floor: distinguishing falls from false positives

12-bit resolution over the chosen range is normally the floor for usable precision — at ±16 g and 12 bits, each LSB represents about 7.8 mg, fine enough to separate postural sway from genuine instability. Noise floor matters more than resolution on paper: a part with 12-bit output but 50 mg·rms noise will bury the low-amplitude pre-fall sway that some algorithms use as an early warning feature.

Orientation sensitivity and multi-axis vs. single-axis tradeoffs

Single-axis accelerometers are cheaper but orientation-dependent, which fails the moment the device is worn slightly differently or the patient changes posture; three-axis MEMS devices are now the default for any device that has to work regardless of mounting angle. Three-axis sensing also enables the vertical-component isolation technique described below, which single-axis designs cannot do at all.

Signal conditioning chain: from sensor output to feature extraction

Anti-aliasing filter design and cutoff frequency selection

An anti-aliasing filter with a cutoff near 25 Hz, implemented as a 2nd- or 3rd-order low-pass ahead of the ADC, prevents higher-frequency mechanical noise (fabric rustle, sensor resonance) from folding into the band of interest. Discrete analog designs built around a two-stage op-amp with differential input and common-source output can implement this filtering stage when the accelerometer's own internal filter bandwidth is too wide for the application.

Analog-to-digital conversion: resolution, sampling strategy, and timing

Most modern accelerometers integrate the ADC and output digital data over I²C or SPI, which removes external conversion error but shifts the timing responsibility to the MCU: the interrupt-driven FIFO read must keep pace with the sensor's internal sample clock or samples get overwritten. For fall detection, a FIFO depth of at least 32 samples at 100 Hz gives roughly 320 ms of buffering margin against bus latency or MCU wake delay.

High-pass filtering to remove gravity offset and DC drift

A high-pass filter with a cutoff around 0.25–0.5 Hz removes the constant 1 g gravity offset and slow sensor drift from the signal used for dynamic feature extraction, while a separate low-pass branch preserves the gravity vector for orientation. Running both branches in parallel, rather than discarding gravity entirely, is what makes vertical-axis isolation possible later in the pipeline.

Normalization and sensor fusion when multiple axes are used

The sum vector magnitude, SVM = √(ax² + ay² + az²), collapses three axes into one orientation-independent scalar and is the single most common first-stage feature in published fall algorithms. Fusing accelerometer data with a gyroscope adds angular velocity for orientation tracking, at the cost of roughly 2–5x the current draw of the accelerometer alone.

Algorithm design: distinguishing falls from stumbles and normal motion

Threshold-based detection: acceleration magnitude and jerk thresholds

A basic detector flags an event when SVM exceeds a fixed threshold, typically in the 2 g to 3 g range, for the free-fall phase, followed by an impact spike above 6 g within 1 second. Jerk — the derivative of acceleration — adds a second filter: genuine falls show jerk spikes above roughly 10 g/s where sitting down abruptly does not, though the exact value must be tuned per sensor placement.

// Pseudocode: two-stage threshold detector
svm = sqrt(ax*ax + ay*ay + az*az)
if svm < FREEFALL_THRESH:       // e.g. 0.6 g
    freefall_timer_start()
if freefall_active and svm > IMPACT_THRESH:   // e.g. 6.0 g
    if elapsed_since_freefall < 1000_ms:
        candidate_fall = true

Time-domain features: peak detection, zero-crossings, and slope changes

Peak count, zero-crossing rate, and slope reversal frequency in the post-impact window distinguish a fall (sharp peak, rapid settling to near-zero motion) from an active stumble recovery (multiple smaller peaks, sustained motion). A fall followed by 2–3 seconds of near-stillness is itself a strong feature, since conscious recovery movement almost never produces that signature.

Vertical component isolation: using gravity as an orientation reference

Because gravity's low-pass component gives a stable reference vector, the angle between the device's vertical axis before and after the event reveals whether the body changed orientation — a tilt change greater than 60–80° combined with an impact spike is far more specific than magnitude alone. This is the step that most cuts false positives from dropping the device or sitting down hard.

Temporal windows and confirmation logic to reduce false alarms

A confirmation window of 2–5 seconds after impact, checking for sustained stillness plus failure to respond to a vibration prompt, converts a raw threshold trigger into a clinically usable alarm. Published sensitivity/specificity figures vary widely by dataset and algorithm, so any number quoted for a specific product should be checked against its own validation study, not assumed from the literature.

Power budget and data flow in battery-operated wearables

Continuous sampling vs. event-triggered wake-up strategies

Continuous sampling at 50–100 Hz with the accelerometer's own internal activity-interrupt feature typically draws 5–20 µA in the sensor itself (check the specific datasheet's low-power mode current, since this varies by vendor and output data rate), but waking the MCU on every sample multiplies system current by 10x or more. Using the sensor's built-in motion/no-motion interrupt to gate MCU wake-up is the single biggest lever for multi-day battery life.

On-device processing: where to compute features (sensor, MCU, or cloud)

Computing SVM and threshold logic on the MCU, rather than streaming raw samples to a phone or cloud service, cuts radio airtime — and therefore power — by an order of magnitude, since a fall event only needs a few bytes of alert payload instead of a continuous raw stream. Reserve cloud or phone-side processing for secondary analytics (gait trends, long-term risk scoring) that don't carry a real-time latency requirement.

Wireless transmission timing: immediate alert vs. periodic reporting

A confirmed fall event should transmit immediately, with a radio wake-latency budget under 1 second; routine activity summaries can batch every 1–15 minutes without clinical cost. Designing two separate transmission paths — urgent and routine — in the firmware keeps the common case cheap and the rare case fast.

Duty cycling and sleep modes for extended battery life

A typical wearable budget looks like this:

A device that averages one wake event per minute and one alert per day can realistically target 5–7 days on a 100 mAh cell; the dominant drain is almost always the radio, not the accelerometer.

Integration with body area networks and remote monitoring systems

Data format and protocol for fall event transmission

A fall alert payload should carry a timestamp, event type, confidence score, and device battery/health status in a compact binary frame rather than a verbose JSON structure, since every extra byte costs radio-on time. Devices operating as part of a larger patient-worn network commonly follow the Body Area Network (BAN) IEEE 802.15.6 standard, which defines the MAC-layer priority classes that let a fall alert preempt routine telemetry.

Latency requirements for emergency alerting

End-to-end latency from impact to caregiver notification should stay under 10–15 seconds for a credible emergency response pathway, which means the confirmation window, radio wake time, and gateway relay all need to be budgeted explicitly rather than measured after the fact.

Edge vs. cloud processing and HIPAA-compliant data handling

Processing the fall decision at the edge — on the wearable or a bedside hub — keeps raw motion data off external networks and simplifies compliance, since only the event summary needs to cross a HIPAA-regulated boundary. Deployment context changes the engineering priorities too: a hospital-grade system behaves more like the deterministic, centrally-managed networks described in Industrial IoT (IIoT) vs. Consumer IoT differences, while a consumer fall-detection wearable tolerates best-effort connectivity and looser latency guarantees.

Practical implementation considerations and validation

Sensor calibration and drift compensation over time

MEMS accelerometers drift with temperature and age; a one-time factory calibration is not sufficient for a multi-year clinical device. Periodic zero-g offset recalibration, performed automatically during known-still periods (e.g., overnight), keeps threshold-based detectors from gradually drifting into false-positive or false-negative territory.

Environmental interference: temperature, vibration, and magnetic fields

Temperature coefficients on offset and sensitivity (check the specific part's datasheet, typically specified in mg/°C) matter for devices that move between a warm body and a cold room; vehicle or treadmill vibration can mimic low-amplitude activity signatures and should be filtered or flagged separately. Magnetic field sensitivity is only a concern if the design pairs the accelerometer with a magnetometer for heading reference.

Testing protocols: phantom falls, real-world validation, and sensitivity tuning

Validation needs three tiers: lab-based phantom falls using a mannequin or trained volunteer on crash mats to generate repeatable impact signatures, semi-controlled trials with older adults performing scripted activities of daily living, and longer-term field deployment to capture the false-positive rate under real, unscripted conditions. Sensitivity tuned purely on phantom-fall data almost always overfits — real deployments turn up motion patterns (dropping the device, vigorous exercise) that lab protocols don't anticipate.

Safety margins and fail-safe behavior when processing fails

Any wearable medical device needs a defined fail-safe state: if the accelerometer stops responding or the algorithm firmware faults, the device should alert low-battery/fault status rather than silently stopping detection. Hardware-level safety obligations — isolation, leakage current limits — still apply to any patient-worn electronics with external connections or charging contacts, and designs should be checked against standards covering electrical safety, protective earth, and leakage even in battery-only wearables that charge through exposed contacts.