dearsky/wifi-densepose
1
0
Fork 0
Code Issues 20 Pull Requests 5 Actions Packages Projects Releases 1 Wiki Activity

How can I enable real detection on my laptop using its Wi-Fi adapter? #65

New Issue
Open
opened 2026-03-01 23:14:42 +08:00 by yruson · 4 comments
yruson commented 2026-03-01 23:14:42 +08:00 (Migrated from github.com)
Copy Link

This is an interesting project, and I'm trying to test it using Docker on my laptop running Ubuntu 24-bit.

It started successfully as instructed, but it always uses simulated data. How can I use real human detection data to verify the results? Thank you.

$ docker run -p 3000:3000 -p 3001:3001 ruvnet/wifi-densepose:latest
2026-03-01T15:11:19.108589Z INFO sensing_server: WiFi-DensePose Sensing Server (Rust + Axum + RuVector)
2026-03-01T15:11:19.108756Z INFO sensing_server: HTTP: http://localhost:3000
2026-03-01T15:11:19.108787Z INFO sensing_server: WebSocket: ws://localhost:3001/ws/sensing
2026-03-01T15:11:19.108789Z INFO sensing_server: UDP: 0.0.0.0:5005 (ESP32 CSI)
2026-03-01T15:11:19.108805Z INFO sensing_server: UI path: /app/ui
2026-03-01T15:11:19.108824Z INFO sensing_server: Source: simulated
2026-03-01T15:11:19.108834Z INFO sensing_server: Data source: simulated
2026-03-01T15:11:19.108845Z INFO sensing_server: Vital sign detector sample rate: 10.0 Hz
2026-03-01T15:11:19.109296Z INFO sensing_server: Simulated data source active (tick=100ms)
2026-03-01T15:11:19.109828Z INFO sensing_server: WebSocket server listening on 0.0.0.0:3001
2026-03-01T15:11:19.110210Z INFO sensing_server: HTTP server listening on 0.0.0.0:3000
2026-03-01T15:11:19.110218Z INFO sensing_server: Open http://localhost:3000/ui/index.html in your browser

This is an interesting project, and I'm trying to test it using Docker on my laptop running Ubuntu 24-bit. It started successfully as instructed, but it always uses simulated data. How can I use real human detection data to verify the results? Thank you. $ docker run -p 3000:3000 -p 3001:3001 ruvnet/wifi-densepose:latest 2026-03-01T15:11:19.108589Z INFO sensing_server: WiFi-DensePose Sensing Server (Rust + Axum + RuVector) 2026-03-01T15:11:19.108756Z INFO sensing_server: HTTP: http://localhost:3000 2026-03-01T15:11:19.108787Z INFO sensing_server: WebSocket: ws://localhost:3001/ws/sensing 2026-03-01T15:11:19.108789Z INFO sensing_server: UDP: 0.0.0.0:5005 (ESP32 CSI) 2026-03-01T15:11:19.108805Z INFO sensing_server: UI path: /app/ui 2026-03-01T15:11:19.108824Z INFO sensing_server: Source: simulated 2026-03-01T15:11:19.108834Z INFO sensing_server: Data source: simulated 2026-03-01T15:11:19.108845Z INFO sensing_server: Vital sign detector sample rate: 10.0 Hz 2026-03-01T15:11:19.109296Z INFO sensing_server: Simulated data source active (tick=100ms) 2026-03-01T15:11:19.109828Z INFO sensing_server: WebSocket server listening on 0.0.0.0:3001 2026-03-01T15:11:19.110210Z INFO sensing_server: HTTP server listening on 0.0.0.0:3000 2026-03-01T15:11:19.110218Z INFO sensing_server: Open http://localhost:3000/ui/index.html in your browser
ruvnet commented 2026-03-01 23:40:42 +08:00 (Migrated from github.com)
Copy Link

Thanks for trying it out. The Docker image defaults to --source simulated because it can't access the host's WiFi hardware from inside the container. To get real human detection data, you need CSI-capable hardware — here are your options from most to least capable:

Option 1: ESP32-S3 mesh (recommended — full CSI, ~$24-54)

This gives you real 56-subcarrier CSI at 20 Hz — the only path to actual pose estimation and vital signs.

# Flash 3x ESP32-S3 boards with pre-built firmware
# https://github.com/ruvnet/wifi-densepose/releases/tag/v0.1.0-esp32

# Run the server in ESP32 mode (--network host so UDP:5005 reaches the container)
docker run --network host ruvnet/wifi-densepose:latest --source esp32

The ESP32 nodes stream binary CSI frames over UDP to port 5005. See Tutorial #34 for the full flashing + provisioning walkthrough.

Option 2: Intel 5300 or Atheros AR9580 NIC (~$15-20, Linux native CSI)

If you have one of these research NICs with the CSI-extraction firmware/driver patch installed (iwl-csi for Intel 5300, ath9k patched for Atheros), you can feed CSI data to the ESP32 ingestion path. These are Linux-native and would work on your Ubuntu machine.

Option 3: Linux RSSI scanning (not yet implemented)

You're on Ubuntu, so the Windows netsh RSSI path (ADR-022) doesn't apply directly. A Linux equivalent using iw dev wlan0 scan or nmcli would follow the same subprocess pattern, but this adapter doesn't exist yet. It's a natural follow-up to:

  • ADR-022 (Windows netsh RSSI adapter — implemented)
  • ADR-025 (macOS CoreWLAN RSSI adapter — proposed, #56)

A Linux iw-based adapter would be the third platform in the same pattern: subprocess → parse → BssidObservation → 8-stage RSSI pipeline. This would give you presence and motion detection from your laptop's built-in WiFi (no extra hardware), but not pose estimation or vital signs — RSSI is too coarse for that.

What you can verify right now (no hardware)

The deterministic reference signal proves the signal processing pipeline is real:

# Inside the repo
python v1/data/proof/verify.py

This runs the full CSI → phase sanitization → feature extraction → motion detection chain on a known input and verifies the output matches expected values.

TL;DR: Simulated mode is expected without CSI hardware. For real detection: ESP32-S3 mesh ($24-54) is the recommended path. A Linux RSSI adapter (iw dev based) would let your laptop do coarse presence/motion detection — that's a good candidate for a future PR if you're interested in contributing.

Thanks for trying it out. The Docker image defaults to `--source simulated` because it can't access the host's WiFi hardware from inside the container. To get **real** human detection data, you need CSI-capable hardware — here are your options from most to least capable: ### Option 1: ESP32-S3 mesh (recommended — full CSI, ~$24-54) This gives you real 56-subcarrier CSI at 20 Hz — the only path to actual pose estimation and vital signs. ```bash # Flash 3x ESP32-S3 boards with pre-built firmware # https://github.com/ruvnet/wifi-densepose/releases/tag/v0.1.0-esp32 # Run the server in ESP32 mode (--network host so UDP:5005 reaches the container) docker run --network host ruvnet/wifi-densepose:latest --source esp32 ``` The ESP32 nodes stream binary CSI frames over UDP to port 5005. See [Tutorial #34](https://github.com/ruvnet/wifi-densepose/issues/34) for the full flashing + provisioning walkthrough. ### Option 2: Intel 5300 or Atheros AR9580 NIC (~$15-20, Linux native CSI) If you have one of these research NICs with the CSI-extraction firmware/driver patch installed (`iwl-csi` for Intel 5300, `ath9k` patched for Atheros), you can feed CSI data to the ESP32 ingestion path. These are Linux-native and would work on your Ubuntu machine. ### Option 3: Linux RSSI scanning (not yet implemented) You're on Ubuntu, so the Windows `netsh` RSSI path (ADR-022) doesn't apply directly. A Linux equivalent using `iw dev wlan0 scan` or `nmcli` would follow the same subprocess pattern, but **this adapter doesn't exist yet**. It's a natural follow-up to: - ADR-022 (Windows `netsh` RSSI adapter — implemented) - ADR-025 (macOS CoreWLAN RSSI adapter — proposed, [#56](https://github.com/ruvnet/wifi-densepose/issues/56)) A Linux `iw`-based adapter would be the third platform in the same pattern: subprocess → parse → `BssidObservation` → 8-stage RSSI pipeline. This would give you **presence and motion detection** from your laptop's built-in WiFi (no extra hardware), but not pose estimation or vital signs — RSSI is too coarse for that. ### What you can verify right now (no hardware) The deterministic reference signal proves the signal processing pipeline is real: ```bash # Inside the repo python v1/data/proof/verify.py ``` This runs the full CSI → phase sanitization → feature extraction → motion detection chain on a known input and verifies the output matches expected values. --- **TL;DR:** Simulated mode is expected without CSI hardware. For real detection: ESP32-S3 mesh ($24-54) is the recommended path. A Linux RSSI adapter (`iw dev` based) would let your laptop do coarse presence/motion detection — that's a good candidate for a future PR if you're interested in contributing.
ruvnet commented 2026-03-02 00:06:06 +08:00 (Migrated from github.com)
Copy Link

Update: Linux WiFi adapter now available!

Good news — we just merged cross-platform RSSI support. You now have a native Linux path:

Linux iw adapter (new)

# Build from source
cd rust-port/wifi-densepose-rs
cargo build --release -p wifi-densepose-sensing-server

# Run with Linux WiFi (requires root for active scanning)
sudo ./target/release/sensing-server --source linux --http-port 3000 --ws-port 3001 --tick-ms 500

The LinuxIwScanner adapter parses iw dev wlan0 scan output. It supports:

  • Active scan (iw dev <iface> scan) — requires CAP_NET_ADMIN / root
  • Cached scan (iw dev <iface> scan dump) — reads cached results, may work without root

Note: This gives you RSSI-only sensing (presence/motion detection). For full pose estimation you still need CSI-capable hardware (ESP32-S3 at ~$8 is the cheapest path).

See the updated User Guide for setup instructions.

## Update: Linux WiFi adapter now available! Good news — we just merged cross-platform RSSI support. You now have a native Linux path: ### Linux `iw` adapter (new) ```bash # Build from source cd rust-port/wifi-densepose-rs cargo build --release -p wifi-densepose-sensing-server # Run with Linux WiFi (requires root for active scanning) sudo ./target/release/sensing-server --source linux --http-port 3000 --ws-port 3001 --tick-ms 500 ``` The `LinuxIwScanner` adapter parses `iw dev wlan0 scan` output. It supports: - **Active scan** (`iw dev <iface> scan`) — requires `CAP_NET_ADMIN` / root - **Cached scan** (`iw dev <iface> scan dump`) — reads cached results, may work without root **Note:** This gives you RSSI-only sensing (presence/motion detection). For full pose estimation you still need CSI-capable hardware (ESP32-S3 at ~\$8 is the cheapest path). See the updated [User Guide](https://github.com/ruvnet/wifi-densepose/blob/main/docs/user-guide.md) for setup instructions.
qhyou11 commented 2026-03-02 17:46:11 +08:00 (Migrated from github.com)
Copy Link

I have just build the new rust code, but it still actived with simulated data source.
$ sudo ./sensing-server --source linux --tick-ms 500 --ui-path ./ui --http-port 3000 --ws-port 3001

2026-03-02T09:40:40.401242Z INFO sensing_server: WiFi-DensePose Sensing Server (Rust + Axum + RuVector)
2026-03-02T09:40:40.401279Z INFO sensing_server: HTTP: http://localhost:3000
2026-03-02T09:40:40.401289Z INFO sensing_server: WebSocket: ws://localhost:3001/ws/sensing
2026-03-02T09:40:40.401304Z INFO sensing_server: UDP: 0.0.0.0:5005 (ESP32 CSI)
2026-03-02T09:40:40.401309Z INFO sensing_server: UI path: ./ui
2026-03-02T09:40:40.401316Z INFO sensing_server: Source: linux
2026-03-02T09:40:40.401326Z INFO sensing_server: Data source: linux
2026-03-02T09:40:40.401335Z INFO sensing_server: Vital sign detector sample rate: 2.0 Hz
2026-03-02T09:40:40.401382Z INFO sensing_server: Simulated data source active (tick=500ms)
2026-03-02T09:40:40.401417Z INFO sensing_server: WebSocket server listening on 0.0.0.0:3001
2026-03-02T09:40:40.401582Z INFO sensing_server: HTTP server listening on 0.0.0.0:3000
2026-03-02T09:40:40.401589Z INFO sensing_server: Open http://localhost:3000/ui/index.html in your browser
^C2026-03-02T09:40:41.041667Z INFO sensing_server: Shutdown signal received
2026-03-02T09:40:41.041806Z INFO sensing_server: Server shut down cleanly

The prompt of the cli show that --source only accept: auto, wifi,esp32,simulate

      --source <SOURCE>
          Data source: auto, wifi, esp32, simulate [default: auto]

And in the main.rs:

    match source {
        "esp32" => {
            tokio::spawn(udp_receiver_task(state.clone(), args.udp_port));
            tokio::spawn(broadcast_tick_task(state.clone(), args.tick_ms));
        }
        "wifi" => {
            tokio::spawn(windows_wifi_task(state.clone(), args.tick_ms));
        }
        _ => {
            tokio::spawn(simulated_data_task(state.clone(), args.tick_ms));
        }
    }
I have just build the new rust code, but it still actived with simulated data source. $ sudo ./sensing-server --source linux --tick-ms 500 --ui-path ./ui --http-port 3000 --ws-port 3001 2026-03-02T09:40:40.401242Z INFO sensing_server: WiFi-DensePose Sensing Server (Rust + Axum + RuVector) 2026-03-02T09:40:40.401279Z INFO sensing_server: HTTP: http://localhost:3000 2026-03-02T09:40:40.401289Z INFO sensing_server: WebSocket: ws://localhost:3001/ws/sensing 2026-03-02T09:40:40.401304Z INFO sensing_server: UDP: 0.0.0.0:5005 (ESP32 CSI) 2026-03-02T09:40:40.401309Z INFO sensing_server: UI path: ./ui 2026-03-02T09:40:40.401316Z INFO sensing_server: Source: linux 2026-03-02T09:40:40.401326Z INFO sensing_server: Data source: linux 2026-03-02T09:40:40.401335Z INFO sensing_server: Vital sign detector sample rate: 2.0 Hz 2026-03-02T09:40:40.401382Z INFO sensing_server: Simulated data source active (tick=500ms) 2026-03-02T09:40:40.401417Z INFO sensing_server: WebSocket server listening on 0.0.0.0:3001 2026-03-02T09:40:40.401582Z INFO sensing_server: HTTP server listening on 0.0.0.0:3000 2026-03-02T09:40:40.401589Z INFO sensing_server: Open http://localhost:3000/ui/index.html in your browser ^C2026-03-02T09:40:41.041667Z INFO sensing_server: Shutdown signal received 2026-03-02T09:40:41.041806Z INFO sensing_server: Server shut down cleanly The prompt of the cli show that --source only accept: auto, wifi,esp32,simulate ``` --source <SOURCE> Data source: auto, wifi, esp32, simulate [default: auto] ``` And in the main.rs: ``` match source { "esp32" => { tokio::spawn(udp_receiver_task(state.clone(), args.udp_port)); tokio::spawn(broadcast_tick_task(state.clone(), args.tick_ms)); } "wifi" => { tokio::spawn(windows_wifi_task(state.clone(), args.tick_ms)); } _ => { tokio::spawn(simulated_data_task(state.clone(), args.tick_ms)); } } ```
👍 1
utrack commented 2026-03-02 20:13:36 +08:00 (Migrated from github.com)
Copy Link

I just hit the same issue.
It seems like the whole project is full of promises made into facts by AI agents, jfyi. https://github.com/ruvnet

I just hit the same issue. It seems like the whole project is full of promises made into facts by AI agents, jfyi. https://github.com/ruvnet
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something isn't working
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 question
Further information is requested
 security
Security-related issues and hardening
 wontfix
This will not be worked on
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dearsky
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dearsky/wifi-densepose#65
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?