Operator's household environment showed CSI-variance presence detection failing — empty room produced HIGHER variance than an occupied room because ambient WiFi noise (neighbour APs, retransmits, BT-coex) dominated the broadband-variance signal at multi-meter range. Deployed a TP-Link TL-WR841N in WISP mode as a dedicated isolated AP for the sensors: * Sensors associate only with TP-Link_8340 (clean channel) * TP-Link bridges to the household AP, NAT-forwards sensor UDP to the Mac * Mac keeps its primary household-AP association — no LAN reconfig needed * Empty-room variance dropped 50.7 → 35.8 (-30%) Replaced presence classification with RSSI MAD-Δ override: * Per-node rolling 120-sample (~10 s @ 12 Hz) window of frame RSSI * Metric: mean(|Δrssi|) between consecutive frames — robust to int8 quantisation jitter * Thresholds tuned for the operator's geometry: d < 0.20 → absent < 0.55 → present_still < 1.10 → present_moving >= 1.10 → active * Confidence field temporarily carries raw d for in-field threshold tuning * CSI-based features (variance, motion_band_power, spectral_power) remain in features.* for vital-sign signal-quality and multi-node fusion paths UI / tooling: * New static/spectrum.html — live signal console: combined classification, all host-computed features (variance, motion_band, spectral, breathing band, RSSI, dominant_freq, change_points), per-node FW signals, and a 60-second variance trace. Served via `python -m http.server 8091`. * static/calibrate.html — simpler per-node motion/presence/RSSI bars with peak-hold. Desktop UI / discovery hardening (rolled in here because they came up during this debug session): * commands/discovery.rs: HTTP sweep limited to 2..=60 hosts (was 1..=254), mDNS + UDP-broadcast paths disabled (current RuView FW doesn't advertise them and they were burning CPU every poll cycle). Per-request timeout set to 1500 ms with overall budget enforced via tokio::time::timeout + futures::join_all (replaces the previous sequential select loop that blocked on slow IPs). * ui/hooks/useNodes.ts: poll interval 10 s → 30 s. * ui/pages/Dashboard.tsx + NetworkDiscovery.tsx: merge new scan results into existing list instead of replacing — discovery races sometimes miss a node that was found a moment ago. Firmware tuning: * edge_processing.c: broadband-variance divisor /3.0 → /30.0 → /5.0 iterated; final /5.0 chosen for multi-meter geometry (sensor 1-3 m from activity zone). DEBUG_MOTION_DSP scaffolding removed. * csi_collector.c: CSI_MIN_SEND_INTERVAL_US 20 ms → 4 ms so the host can see every available frame (real ceiling is the WiFi CSI callback rate). Documentation: * docs/adr/ADR-099 — full forensic write-up: measurement tables for sit/ walk/empty, the RSSI-Δ rationale, the WISP setup procedure, calibration protocol for new deployments, and open items. Verified end-to-end on hardware (sensors at 192.168.1.17/.19 → TP-Link at 192.168.1.14 → Mac at 192.168.1.21): * UDP/5006 packets arrive ~12 Hz combined from both nodes * Empty-room baseline d ≈ 0.49 measured (next: capture sit + walk to finalize thresholds) * Vital signs continue to populate (breathing 9–11 BPM stable) * Two consecutive OTA round-trips remain functional after the change Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| src | ||
| static | ||
| tests | ||
| Cargo.toml | ||
| README.md | ||
README.md
wifi-densepose-sensing-server
Lightweight Axum server for real-time WiFi sensing with RuVector signal processing.
Overview
wifi-densepose-sensing-server is the operational backend for WiFi-DensePose. It receives raw CSI
frames from ESP32 hardware over UDP, runs them through the RuVector-powered signal processing
pipeline, and broadcasts processed sensing updates to browser clients via WebSocket. A built-in
static file server hosts the sensing UI on the same port.
The crate ships both a library (wifi_densepose_sensing_server) exposing the training and inference
modules, and a binary (sensing-server) that starts the full server stack.
Integrates wifi-densepose-wifiscan for multi-BSSID WiFi scanning per ADR-022 Phase 3.
Features
- UDP CSI ingestion -- Receives ESP32 CSI frames on port 5005 and parses them into the internal
CsiFramerepresentation. - Vital sign detection -- Pure-Rust FFT-based breathing rate (0.1--0.5 Hz) and heart rate (0.67--2.0 Hz) estimation from CSI amplitude time series (ADR-021).
- RVF container -- Standalone binary container format for packaging model weights, metadata, and
configuration into a single
.rvffile with 64-byte aligned segments. - RVF pipeline -- Progressive model loading with streaming segment decoding.
- Graph Transformer -- Cross-attention bottleneck between antenna-space CSI features and the
COCO 17-keypoint body graph, followed by GCN message passing (ADR-023 Phase 2). Pure
std, no ML dependencies. - SONA adaptation -- LoRA + EWC++ online adaptation for environment drift without catastrophic forgetting (ADR-023 Phase 5).
- Contrastive CSI embeddings -- Self-supervised SimCLR-style pretraining with InfoNCE loss, projection head, fingerprint indexing, and cross-modal pose alignment (ADR-024).
- Sparse inference -- Activation profiling, sparse matrix-vector multiply, INT8/FP16 quantization, and a full sparse inference engine for edge deployment (ADR-023 Phase 6).
- Dataset pipeline -- Training dataset loading and batching.
- Multi-BSSID scanning -- Windows
netshintegration for BSSID discovery viawifi-densepose-wifiscan(ADR-022). - WebSocket broadcast -- Real-time sensing updates pushed to all connected clients at
ws://localhost:8765/ws/sensing. - Static file serving -- Hosts the sensing UI on port 8080 with CORS headers.
Modules
| Module | Description |
|---|---|
vital_signs |
Breathing and heart rate extraction via FFT spectral analysis |
rvf_container |
RVF binary format builder and reader |
rvf_pipeline |
Progressive model loading from RVF containers |
graph_transformer |
Graph Transformer + GCN for CSI-to-pose estimation |
trainer |
Training loop orchestration |
dataset |
Training data loading and batching |
sona |
LoRA adapters and EWC++ continual learning |
sparse_inference |
Neuron profiling, sparse matmul, INT8/FP16 quantization |
embedding |
Contrastive CSI embedding model and fingerprint index |
Quick Start
# Build the server
cargo build -p wifi-densepose-sensing-server
# Run with default settings (HTTP :8080, UDP :5005, WS :8765)
cargo run -p wifi-densepose-sensing-server
# Run with custom ports
cargo run -p wifi-densepose-sensing-server -- \
--http-port 9000 \
--udp-port 5005 \
--static-dir ./ui
Using as a library
use wifi_densepose_sensing_server::vital_signs::VitalSignDetector;
// Create a detector with 20 Hz sample rate
let mut detector = VitalSignDetector::new(20.0);
// Feed CSI amplitude samples
for amplitude in csi_amplitudes.iter() {
detector.push_sample(*amplitude);
}
// Extract vital signs
if let Some(vitals) = detector.detect() {
println!("Breathing: {:.1} BPM", vitals.breathing_rate_bpm);
println!("Heart rate: {:.0} BPM", vitals.heart_rate_bpm);
}
Architecture
ESP32 ──UDP:5005──> [ CSI Receiver ]
|
[ Signal Pipeline ]
(vital_signs, graph_transformer, sona)
|
[ WebSocket Broadcast ]
|
Browser <──WS:8765── [ Axum Server :8080 ] ──> Static UI files
Related Crates
| Crate | Role |
|---|---|
wifi-densepose-wifiscan |
Multi-BSSID WiFi scanning (ADR-022) |
wifi-densepose-core |
Shared types and traits |
wifi-densepose-signal |
CSI signal processing algorithms |
wifi-densepose-hardware |
ESP32 hardware interfaces |
wifi-densepose-wasm |
Browser WASM bindings for the sensing UI |
wifi-densepose-train |
Full training pipeline with ruvector |
wifi-densepose-mat |
Disaster detection module |
License
MIT OR Apache-2.0