Wi-Fi CSI fall detection: low-frequency features, false alarms and evidence limits

By Wu Jun · Updated 2026-10-29 · 7 min read

Fall detection is a valuable Wi-Fi sensing application and one of the easiest places to turn "large signal change" into the unsupported claim "reliable fall recognition." WiFall and WiCare demonstrate that CSI can capture fall-related wireless changes ^{[1] [2]}, but their hardware, sampling rates, rooms and subjects do not transfer automatically to a home router producing about 12.64 independent snapshots/s.

This article defines an honest baseline: use slow motion envelopes, pre-event context and the recovery period to detect suspected fall-like events. It does not claim medical accuracy, and it does not treat eight chain records as a 95 Hz micro-Doppler timeline.

1. Establish the capability boundary first

Our 10-minute capture demonstrates stable 256-subcarrier CSI, with 57,293 chain records yielding 7,609 grouped measurements and about 12.64 independent snapshots/s ^{[3] [4]}. It has no fall-event labels, so it cannot be used to compute fall accuracy.

2. Why 95.5 records/s is not the sampling rate

One CSI measurement can contain up to eight tx/rx chain records at almost the same instant. The chains provide spatial and frequency diversity; they are not consecutive time samples. Concatenating all 57,293 records as a 95.5 Hz phase series creates two errors:

1. the Nyquist range is expanded artificially;
2. simultaneous link differences are misread as time evolution.

The correct sequence is:

1. close measurements on chain_info bit 15;
2. select one valid chain per group or construct a stable multi-chain feature;
3. sort by file_ts and resample;
4. report independent snapshot rate, maximum gap and usable-group ratio.

A 12.64 Hz sequence can describe body-motion envelopes lasting hundreds of milliseconds to seconds. It cannot recover the roughly 33 Hz micro-Doppler of 1 m/s motion at 5 GHz. Algorithms must respect that limit rather than changing a FS=95 constant.

3. Interpretable event features

A fall is not one isolated frame. It is an interval:

before: walking or standing
event:  short, large motion change
after:  sitting may keep adjusting; a fall may be followed by low motion

Features therefore need context and recovery, not just one variance peak. The code below assumes H is an amplitude matrix with one selected chain per measurement, t contains timestamps and event_t is a candidate:

import numpy as np

def resample_rows(H, t, fs=20.0):
    t = np.asarray(t, dtype=float)
    order = np.argsort(t)
    t, H = t[order], np.asarray(H)[order]
    tu = np.arange(t[0], t[-1], 1.0 / fs)
    Hu = np.column_stack([
        np.interp(tu, t, H[:, i]) for i in range(H.shape[1])
    ])
    return Hu, tu

def event_features(H, t, event_t, fs=20.0):
    H, t = resample_rows(H, t, fs)
    motion = np.abs(np.diff(H, axis=0)).mean(axis=1)
    tm = t[1:]

    pre = motion[(tm >= event_t - 8) & (tm < event_t - 2)]
    event = motion[(tm >= event_t - 1) & (tm <= event_t + 1.5)]
    post = motion[(tm > event_t + 1.5) & (tm <= event_t + 5)]
    if min(len(pre), len(event), len(post)) < 10:
        return None

    baseline = float(np.median(pre))
    peak = float(np.max(event))
    quiet = float(np.mean(post))

    # Low-frequency event-band share, not micro-Doppler.
    x = event - event.mean()
    power = np.abs(np.fft.rfft(x * np.hanning(len(x)))) ** 2
    freqs = np.fft.rfftfreq(len(x), 1.0 / fs)
    mask = (freqs >= 0.5) & (freqs <= 4.0)

    return {
        "pre_motion": baseline,
        "event_peak": peak,
        "peak_ratio": peak / (baseline + 1e-9),
        "recovery_ratio": quiet / (peak + 1e-9),
        "low_band_ratio": float(power[mask].sum() / (power.sum() + 1e-12)),
    }

low_band_ratio is the share of 0.5-4 Hz motion energy. It is not Doppler spread. Real Doppler requires a sufficient independent snapshot rate, a known geometry and reference velocities/events.

4. From features to a state machine

Start with an interpretable state machine rather than an opaque deep model:

1. sustained walking/standing exists 2-8 seconds before the event;
2. event peak is significantly above that session's still baseline;
3. the rise is abrupt but allows a human movement lasting 0.4-1.5 seconds;
4. motion 1.5-5 seconds after the event falls below the peak, forming a recovery;
5. trigger a 30-second refractory period to avoid duplicate alerts;
6. emit suspected_fall_event, evidence fields and ten seconds of raw data on each side;
7. require human review or a separate controlled rule before alerting.

Thresholds must come from labelled data:

limits = {
    "min_peak_ratio": 0,      # calibrate from negatives
    "max_recovery_ratio": 1,  # calibrate from positives/negatives
    "min_low_band_ratio": 0,
}

The 0/1 values are placeholders, not deployment settings. Use empty-room, sitting, bag-drop, door-slam, pet and simulated-fall data to choose thresholds, then report false positives and misses.

5. Capture protocol

Safety and human factors come first. Use a padded mat and simulated falls; never ask a participant to perform a dangerous real fall.

5.1 Minimum dataset

5.2 Scene variables

• at least two subjects, two body-size ranges and two positions;
• at least two furniture layouts and two link directions;
• record AP height, distance, orientation, channel, bandwidth and TX power;
• record RSSI, SNR, independent snapshot rate, maximum gap and usable-group ratio;
• label event start, peak, recovery and whether a human reviewed it;
• split by session and subject; never randomly place overlapping windows in both train and test.

5.3 Label example

session,subject,event_t,class,position,recovered_s,reviewed
s01,u01,2026-11-01T10:03:22Z,simulated_fall,p1,3.8,true
s01,u01,2026-11-01T10:06:10Z,sit,p1,,true

Keep the raw CSI, timestamps and quality statistics. Processed features alone cannot prove that sampling and grouping were correct.

6. Evaluation metrics

Falls are rare events, so accuracy alone is misleading. Report:

• event precision, recall and F1;
• a confusion matrix for fall, sitting, bag drop, door slam and empty room;
• false alarms per day;
• misses and detection latency;
• monitored hours and valid coverage;
• results by subject, room and distance;
• confidence intervals and failed sessions.

If a system produces twenty alerts per day, 95% offline accuracy will not make it usable. The operational burden of human review matters as much as the classifier score.

7. Common failure modes

8. Evidence and compliance boundary

WiFall and WiCare show that the research direction is credible ^{[1] [2]}, and the CSI sensing survey provides the wider feature context ^[5]. None of those papers replaces validation on your hardware, rooms and population.

Product wording should be:

• "detects a suspected fall-like event", not "confirms a fall";
• "research/assistive feature", not "medical device";
• "requests human review", not a guaranteed emergency response;
• explicit consent, retention, deletion and an off mechanism;
• clear notice that sensing without a camera is still monitoring.

9. Data needed next

The current public capture can test motion envelopes and the parser, but it cannot establish fall accuracy. The next capture should include:

1. at least five subjects, two rooms and three positions;
2. simulated falls on a mat plus sitting, bag-drop, door-slam and pet negatives;
3. synchronised video or human event marks as ground truth, with consent and restricted access;
4. raw CSI, firmware version, snapshot rate and a quality report for every session;
5. an event-level rule baseline first, then comparison with a learned model.

10. Conclusion

• a 12.64 Hz independent snapshot rate supports event envelopes, not full impact micro-Doppler;
• useful features are pre-event activity, abrupt energy, recovery and multi-link consistency;
• start with interpretable rules and event-level metrics before complex models;
• false alarms per day, misses and review cost matter more than a polished offline accuracy number;
• without labelled data and compliance review, do not market medical-grade fall detection.

Related: respiration detection · CSI radar limits · Home Assistant integration