Can I use my existing routers for fall detection? And how hard is it really with 4 ESP32‑S3 nodes?
Notice Board #23 deep-dive. Two questions, one honest answer for each: can the WiFi routers already in the house do this work, and what does a realistic 4‑node RuView setup actually look like for catching a fall.
Executive verdict
Existing routers: almost certainly no. Reliable CSI extraction needs a very specific chipset + patched firmware (Atheros ath9k via Atheros‑CSI‑Tool, Broadcom via Nexmon‑CSI on a small allow‑list of devices, or Intel 5300 NICs). A typical modern WiFi‑6 home router does not expose CSI, and RuView is built around ESP32‑S3 nodes anyway, not routers.
Four ESP32‑S3 nodes for fall detection: technically possible, practically a research project. ~$40–80 in hardware, but weeks of careful work on placement, calibration, data capture, labeling, retraining, and tuning false‑positive thresholds. Lab papers cite 89‑99% accuracy; in your living room expect noticeable drift and a non‑trivial false‑alarm rate that resets every time furniture moves or RF neighbours change.
Recommendation: No‑go as a fall detection system for someone you actually care about. Yes as a bounded hobby spike for ambient presence/motion, with fall detection as a stretch‑goal experiment never relied on for safety. If the real goal is fall safety, buy a mmWave sensor or a wearable.
1. Can normal existing consumer routers be used?
RSSI vs CSI — why this distinction matters
Every WiFi device reports RSSI, a single signal‑strength number per packet. RSSI can tell you "something changed in the room" in a crude way, but it cannot reliably distinguish "person fell" from "someone walked past" or "the fridge compressor turned on". Commercial WiFi‑sensing systems (Origin Wireless, Linksys Aware, Hex Home) achieve their results using CSI: amplitude and phase per OFDM subcarrier per antenna pair per packet. CSI gives you tens to hundreds of measurement points per frame instead of one. RuView assumes CSI. Without CSI, you are doing motion detection with the resolution of a cheap PIR sensor, not fall detection.
The actual list of devices that expose CSI
| Path | Hardware | Status in 2026 |
|---|---|---|
| Intel 5300 NIC (Linux 802.11n CSI Tool) |
Mini‑PCIe card in an old laptop / NUC running a patched kernel. | Workhorse of academic CSI papers. Old, 802.11n only, but solid. |
| Atheros ath9k (Atheros‑CSI‑Tool, OpenWrt build) |
AR9580 / AR9590 / AR9344 / QCA9558 chipsets. Routers like Netgear WNDR3700v4, TP‑Link Archer C7, some legacy WNDR series. | Works, but those routers are end‑of‑life. You probably do not own one. |
| Broadcom via Nexmon‑CSI | BCM4366c0 (ASUS RT‑AC86U), Raspberry Pi 3B+ / Pi 4, Nexus 5/6P, a few other Broadcom/Cypress chips. | Active project. Tied to a specific allow‑list of devices — modern WiFi‑6 / WiFi‑7 routers are not on it. |
| ESP32‑S3 CSI (what RuView actually uses) |
~$10 dev boards with PSRAM. Espressif's CSI API exposes per‑subcarrier data natively. | The default RuView path. Cheap, supported, but it is a sensor node, not your home router. |
| Your current home router | Most likely Qualcomm / Broadcom WiFi‑6 SoC with closed firmware. | No public CSI extraction. Even if you flash OpenWrt, the chip almost certainly does not export CSI through any maintained tool. |
What people get wrong here
- "Linksys Aware does motion detection on my router" — yes, but it uses Origin Wireless' proprietary firmware on specific Linksys models. You cannot get the raw CSI back out, and you cannot point it at RuView.
- "OpenWrt can extract CSI" — only on a small list of older Atheros boards. OpenWrt by itself is not a CSI tool.
- "Monitor mode is enough" — monitor mode gives you packet headers, not CSI. Different layer.
- "WiFi 6 / 7 will be better" — newer standards have richer beamforming feedback in theory, but consumer drivers do not expose it. Newer routers are typically worse for CSI sensing today, not better.
2. What "4 of these" actually means
In RuView's documentation, the unit of deployment is an ESP32‑S3 CSI node: a small dev board with PSRAM that streams CSI frames to a Rust sensing server (a Pi or laptop on your LAN). "4 of these" means 4 such nodes, not 4 routers.
The node
ESP32‑S3 dev board with PSRAM (e.g. ESP32‑S3‑DevKitC, Seeed XIAO ESP32‑S3, M5Stack ATOM‑S3). USB power, ~$10–15 each. Flashed with RuView's CSI firmware. Reports CSI frames over WiFi or serial to the aggregator. ESP32‑C3 and the original single‑core ESP32 are explicitly unsupported by RuView (insufficient cores for the DSP).
The aggregator
A Pi 4 / Pi 5 or any Linux box running RuView's Rust sensing server. It does Hampel filtering, phase unwrap, coherence gating, multistatic fusion across links, then feeds downstream detectors / models. This is where the live model loader gap (JSONL RVF vs binary RVF) bites — verify model‑backed vs heuristic output before trusting it.
Why 4 nodes specifically
Each pair of nodes forms a "link" — one transmitter, one receiver — and the body moving through that link distorts CSI on it. With 4 nodes you get up to 6 unordered pairs, so 6 independent geometric perspectives on the same room. That redundancy is what lets the multistatic fusion stage tell "person changed posture in front of one link" apart from "person fell across the room intersecting three links simultaneously". One node by itself is essentially useless for fall detection; the README itself flags "limited spatial resolution" with a single ESP32.
Realistic 4‑node placement
Two nodes at ceiling height, two at waist height, opposite corners. The dashed lines are the six CSI links — a fall that crosses several of them simultaneously is what fusion treats as a candidate event.
3. How feasible is fall detection with 4 nodes, honestly?
What works reasonably well with 4 ESP32‑S3 nodes
- Presence: someone vs no one in the room. High signal‑to‑noise, robust, the easiest win.
- Coarse motion: stationary vs walking vs running. Also robust.
- Breathing rate when subject is still in line of sight of at least one strong link. Plausible after calibration.
- "Big sudden event" — distinguishing a fall‑like impulse from background hum is feasible. Distinguishing a fall from sitting down hard, throwing a bag on the sofa, or a door slam plus the dog jumping off the couch is the actual hard problem.
What is genuinely difficult
| Difficulty | What it means in practice |
|---|---|
| Environment‑specific calibration | Every CSI model is trained or tuned against a specific room geometry. RuView itself documents a 60‑second ambient calibration step. Move a sofa, add a houseplant, retrain or recalibrate. |
| RF interference floor | Microwaves, fans near antennas, neighbours' APs and 2.4 GHz devices, Bluetooth, smart bulbs — all of them inject motion‑like variance into CSI. RuView's own README warns that the presence indicator will false‑positive without re‑running ambient calibration after such events. |
| Domain shift | Models trained on volunteers in a university lab degrade sharply on a different person in a different room. Recent papers (XFall, ARC‑Fi, physics‑driven attention transformers) are explicitly about fixing this, which tells you how unsolved it still is. |
| Labeled fall data | You need real falls (or a stunt‑mat / cushioned simulated falls) plus a lot of "fall‑like negatives" (sit down hard, drop a box, kid jumping). Collecting hundreds of labeled samples per environment is a real chunk of work. Public datasets exist but are tiny and from other rooms. |
| False positives, daily | Even at 13% false alarm rate, a continuously monitoring system can fire many wrong alerts per day. Alert fatigue kills trust in days. Tuning thresholds higher reduces false positives but also reduces recall on real falls — the worst direction. |
| False negatives | The fall that matters happens once. If the subject is in a CSI‑shadow zone (behind a metal cabinet, in the bathroom you didn't instrument), the system silently misses it. You will not know it missed it. |
| Live model loader gap (RuView‑specific) | The pretrained weights ship as JSONL RVF; the binary RVF loader in the live sensing server does not yet accept that container. The fall‑detection output may quietly fall back to heuristics rather than the model. Verify before drawing conclusions. |
4. Cost and time estimate
Hardware (one‑time)
4× ESP32‑S3 dev boards with PSRAM: ~$40–80.
USB power supplies + cables: ~$20.
Pi 4 / 5 or repurposed laptop as aggregator: $0 if reused, ~$80–120 new.
Mounts / enclosures: ~$20.
Total: roughly $60–250 depending on what you already own.
Labor (the real cost)
Hardware bring‑up + Docker simulated path: 1 weekend.
Stable presence/motion in one room: ~1–2 more weekends.
Breathing rate with calibration: +1 weekend.
Any usable fall detection beyond "loud impulse on multiple links": weeks to months, with iterative data collection, labeling, and retraining.
Maintenance: recurring — every meaningful room change triggers recalibration.
The hardware is the cheap part. The expensive parts are your time, your patience for false alarms, and your willingness to redo calibration each time the room changes.
5. The minimum success metric to use
Suggested ladder, in order:
- Presence stability — over 7 days, the system correctly reports occupied vs empty for one room with <2% time‑weighted error and no more than one missed transition per day. If this fails, stop.
- Motion class — stationary vs walking distinguishable with >90% accuracy across at least three different people on at least three different days.
- Breathing rate — sitting still in line of sight, reported rate within ±2 breaths/min of a chest‑belt or smartwatch reference for 5 minutes.
- Fall‑like impulse — a deliberate cushioned simulated fall (knee‑to‑ground or onto a mat) triggers an event within 2 seconds, while sitting down hard, dropping a 5 kg bag, and a door slam do not trigger it. Measured over 30 staged events.
- Real‑world false‑positive rate — fewer than one false fall alert per week over a 4‑week passive monitoring window in your actual home.
If you cannot consistently hit step 4 and step 5, you do not have a fall detector. You have a motion sensor with a fall‑shaped logo. That is fine as a hobby project. It is not fine as a safety system.
6. Safety disclaimer
7. Alternatives, ranked by "would I bet someone's safety on it"
| Option | Cost | Honest take |
|---|---|---|
| Apple Watch / Pixel Watch with Fall Detection | $250–500 + cellular plan | Mature, validated, calls emergency services on its own. Requires the person to wear it. Best default for actual fall safety. Limitation: people don't wear watches in bed or in the shower. |
| Dedicated medical alert pendant (Lively, Bay Alarm Medical, Kanega) |
$30–60/month | Boring, works. Cellular, 24/7 monitoring, fall detection on pendant. Less stylish than a watch, more reliable for elderly users. |
| mmWave radar sensor (TI IWR6843, Vayyar, Aqara FP2 successors) |
$70–300 | Genuinely good at fall detection — direct range / velocity / angle, much higher SNR than CSI for impulse events. Privacy‑preserving. The right "ambient, no‑wearable" choice if you have ~$200 to spend. |
| Commercial WiFi sensing (Origin Wireless / Linksys Aware, Hex Home) |
$100–300 router + sub | Calls fall detection their "killer app". Real, but a closed proprietary box. You get the alert, not the raw signal. Hex Home reviews described it as motion detection that "feels very first‑gen". |
| Camera + on‑device vision (Frigate, Reolink AI, Apple HomeKit Secure Video pose models) |
$50–200 per camera | Most accurate when allowed. Loses on privacy, bathrooms, bedrooms, lighting. The tradeoff people exist specifically to avoid. |
| 4× ESP32‑S3 + RuView (this question) | $60–250 + many weekends | The right answer if the goal is "explore CSI sensing as a research thread and maybe surface room state to Dab". The wrong answer if the goal is "catch a fall". |
8. Practical go / no‑go
Go — if your real intent is…
"I want to play with WiFi sensing, see CSI traces from my own room, and maybe surface
presence/motion to Mission Control as ambient context. Fall detection is a stretch
experiment I will never rely on."
Then yes: order 4 ESP32‑S3 boards, do the bounded weekend spike, write down the metrics
from §5, stop at the first one that fails. Total downside ≈ a tank of petrol.
No‑go — if your real intent is…
"I want a system that will tell me if a specific person has fallen, in this house, with
reliability I can trust to call for help."
Then no, not with RuView in its current state. Spend the same money on an Apple Watch
(if they'll wear one), a mmWave sensor (if they won't), or a medical alert pendant
(mature, boring, works). Revisit CSI‑based fall detection in 2–3 years when
domain‑general models and validated commercial offerings are further along.
If you go: minimum viable path
Buy 4 ESP32‑S3 boards with PSRAM
ESP32‑S3‑DevKitC or Seeed XIAO ESP32‑S3 are safe picks. Avoid ESP32‑C3 and original ESP32 — unsupported.
Stand up the Docker simulated path first
Confirms the dashboards / API surface work end to end before any hardware is involved.
Flash one node, get a single CSI stream to the aggregator
Stop here for a day. Look at the raw CSI traces. If they look like noise, the downstream model results will also look like noise — fix the basics before scaling.
Scale to 4 nodes in one room
Two ceiling, two waist, opposite corners. Plug into power, not battery — power draw is continuous.
Walk the §5 ladder
Presence → motion → breathing → fall‑like impulse → false‑positive rate. Each one is a gate. Do not skip ahead.
Document and stop
Whichever gate fails first is your answer. Write it up in a Notice Board project page, archive the rest. Do not let this become an unbounded project.
Uncertainty and what I'm not sure about
- Exact false‑positive rate of RuView's specific fall detector in a home like yours — unknown; depends on which detector is wired up at the time you try it, and the live model loader gap may degrade output to heuristics. Verify against the README's current "works today" list.
- Whether 4 nodes is meaningfully better than 3 or 6 in your room. Multistatic fusion benefits saturate at some point but the curve depends on geometry.
- Whether any specific home router you own happens to be Nexmon‑compatible. The list is small but not empty — worth a one‑line check (see Sources).
- Long‑run robustness over months. Almost no academic CSI work runs longer than a few days in‑lab; multi‑week home deployments are the rare case.
- How the 2.4 GHz vs 5 GHz choice affects sensitivity to falls specifically vs breathing specifically. RuView mostly uses 2.4 GHz on the ESP32‑S3 path because that's what the radio supports.
Sources
- RuView repo: github.com/ruvnet/RuView — README, ESP32 CSI node firmware, ADR‑018 tutorial, multistatic fusion notes, RF‑interference / calibration caveats.
- RuView ESP32‑S3 CSI node README: firmware/esp32-csi-node/README.md — multi‑node config (
CONFIG_CSI_NODE_ID), 60‑second ambient calibration, ESP32‑C3 / original ESP32 unsupported note. - Atheros CSI Tool (OpenWrt): github.com/xieyaxiongfly/Atheros_CSI_tool_OpenWRT_src — chipset support list (AR9580/9590/9344, QCA9558).
- Atheros CSI for Netgear WNDR3700v4: weisgroup/Openwrt-Atheros-CSI-Tool-for-Netgear-WNDR3700v4.
- Nexmon CSI: github.com/seemoo-lab/nexmon_csi — supported Broadcom/Cypress devices including BCM4366c0 (ASUS RT‑AC86U) and Raspberry Pi 3B+/4.
- Anti‑Fall (CSI fall detection, 89% precision / 13% false alarm rate baseline): arxiv.org/pdf/1507.01057.
- "Why Commodity WiFi Sensors Fail at Multi‑Person Gait Identification (ESP32 study)": arxiv.org/pdf/2601.02177.
- ESP32‑based IoT framework for fall detection and caregiver notification (claims 96–99% in‑sample accuracy with real‑time false positives): rsisinternational.org.
- XFall — domain‑adaptive CSI fall detection: tns.thss.tsinghua.edu.cn — Paper‑XFall.pdf. Documents the domain‑shift problem.
- "Robust Cross‑Domain WiFi Fall Detection via Physics‑Driven Attention‑Enhanced Transformers": arxiv.org/abs/2605.00869.
- Cross‑Domain WiFi Sensing with CSI — survey: dl.acm.org/doi/10.1145/3570325.
- Origin Wireless interview — "fall detection is the killer app for WiFi sensing": wifinowglobal.com.
- Gizmodo review of Hex Home (commercial WiFi‑sensing): gizmodo.com — useful reality‑check on consumer‑grade WiFi sensing UX.
- TI IWR6843 mmWave fall detection: ti.com/video/6074838932001 and IWR6843 datasheet.
- Parent Notice Board artifact: projects/ruview.html.
Quoted accuracy figures come from cited papers and are mostly in‑sample / single‑environment; treat them as ceiling values, not what you should expect at home. Statements like "your existing routers almost certainly don't expose CSI" are editorial conclusions from the chipset / firmware support lists above, not a check of any specific router you own.