When two render frames land in the same performance.now() tick,
`currentTime - lastFrameTime === 0`, so `fps = 1000 / 0 = Infinity`,
and `averageFps = averageFps * 0.9 + Infinity * 0.1 = Infinity` poisons
the EMA forever after a single zero-dt tick. The UI then displays
"Infinity FPS" until reload.
Floor deltaTime at 1 ms before the division. That caps displayed FPS at
1000 (far above any real render rate so the cap is never observed in
practice) but keeps the EMA finite.
Reported in #519 ("Bug 2 — FPS shows Infinity") by @kapilsoni2013 on a
3-node ESP32-S3-WROOM multi-node setup with edge-tier 1 + 2.
Each of these crates was a single-line doc-comment placeholder:
v2/crates/wifi-densepose-api/src/lib.rs: //! WiFi-DensePose REST API (stub)
v2/crates/wifi-densepose-db/src/lib.rs: //! WiFi-DensePose database layer (stub)
v2/crates/wifi-densepose-config/src/lib.rs: //! WiFi-DensePose configuration (stub)
with empty [dependencies] in their Cargo.toml and zero references from any
source file or Cargo.toml in the workspace (verified by `grep -rln
wifi-densepose-api/-db/-config` across `v2/`). They were reserved early for
an envisioned REST/database/config split that never materialised.
The functionality these would have provided is covered today by:
- REST/WS: wifi-densepose-sensing-server (Axum)
- Config: per-crate config + CLI args in sensing-server and desktop
- DB: no persistent state; system is real-time
Removal prevents `cargo` from listing dead crates, shipping empty published
artifacts to crates.io, or wasting reviewer attention. If any of these names
is needed in the future, reintroduce them with a real implementation.
Per the issue reporter (@bannned-bit / Matad0r) #578 explicitly listed
"OR be removed from workspace members until implementation starts" as an
acceptable resolution.
Updated:
- `v2/Cargo.toml`: drop the three members (with inline comment explaining why)
- `v2/Cargo.lock`: regenerated by cargo check
- `CLAUDE.md`: drop the three rows from the crate table and the publishing
order list
- `CHANGELOG.md`: add an `[Unreleased] / Removed` entry
Verified:
- `cd v2 && cargo check --workspace --no-default-features` -> finished
in 48s, no errors (warnings unchanged)
Docker Desktop on Windows demultiplexes inbound UDP from multiple source
IPs onto a single virtual socket, silently dropping packets from all but
one ESP32 node. This makes multi-node sensing setups appear to work
(WebSocket connects, packets flow on the host) while only one node's CSI
ever reaches the container.
Adds scripts/udp-relay.py (stdlib only) which collapses multi-source UDP
to a single loopback source so Docker's forwarding accepts every packet.
Verified locally: 6 packets from 3 distinct source ports all arrive at
the receiver from a single relay socket.
Updates docker/docker-compose.yml with an inline comment pointing
Windows users at the relay + 5006:5005 mapping. Linux/macOS hosts are
unaffected and need no changes.
Also documents the workaround alongside fixes for #188 (UI 404 from
relative --ui-path) and #438 (boot loop on --edge-tier 1/2 against
pre-v0.4.3.1 firmware) as new sections 9-11 of docs/TROUBLESHOOTING.md.
Supersedes the docs-only PR #413.
Closes#374, #386
Refs #188, #438, #301
* firmware/esp32-csi-node: fix IDF 6 build (PSA SHA-256, explicit REQUIRES)
- rvf_parser: use psa_hash_* / psa_hash_compute; mbedTLS 4 has no public
mbedtls/sha256.h on the IDF include path.
- main/CMakeLists: declare REQUIRES for WiFi, netif, HTTP, OTA, drivers, lwip,
mbedtls per ESP-IDF v6 component dependency checks; optional wasm3 when
CONFIG_WASM_ENABLE.
Signed-off-by: Chaitanya Tata <chaitanya@dotstarconsulting.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
* firmware/esp32-csi-node: fix CSI config for Wi-Fi 6 (ESP32-C6)
When CONFIG_SOC_WIFI_HE_SUPPORT is set, wifi_csi_config_t is the
wifi_csi_acquire_config_t bitfield layout. The legacy bool fields
(lltf_en, htltf_en, ...) only apply to ESP32-S3-class targets.
Initialize acquire fields for HE targets; add MAC v3-only members when
CONFIG_SOC_WIFI_MAC_VERSION_NUM >= 3.
Verified: idf.py build for esp32c6 and esp32s3 (ESP-IDF v6.1).
Signed-off-by: Chaitanya Tata <chaitanya@dotstarconsulting.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
* firmware/esp32-csi-node: pin edge DSP task for unicore (ESP32-C6)
edge_processing_init used xTaskCreatePinnedToCore(..., core 1). ESP32-C6
runs FreeRTOS unicore (portNUM_PROCESSORS == 1), so core 1 trips the
xTaskCreatePinnedToCore range assert right after CSI init.
Use core 1 only when SMP is available; otherwise pin to core 0.
Signed-off-by: Chaitanya Tata <chaitanya@dotstarconsulting.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
* firmware/esp32-csi-node: provision NVS with chip auto-detect
provision.py always passed --chip esp32s3 to esptool, so flashing NVS on
ESP32-C6 failed. Default --chip to auto (esptool v5) and add an explicit
--chip override. Use write-flash instead of deprecated write_flash.
Signed-off-by: Chaitanya Tata <chaitanya@dotstarconsulting.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
---------
Signed-off-by: Chaitanya Tata <chaitanya@dotstarconsulting.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
* v2: pin Rust 1.89 for sensing-server dependency chain
ruvector-core 2.0.5, hnsw_rs 0.3.4, and mmap-rs 0.7 require newer Cargo/rustc
than 1.82 (edition2024 manifest, is_multiple_of, stable avx512f target_feature
on x86_64). Add v2/rust-toolchain.toml so cargo build -p
wifi-densepose-sensing-server picks a compatible toolchain.
Signed-off-by: Chaitanya Tata <chaitanya@dotstarconsulting.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
* sensing-server: default UI path for cwd v2/ and coalesce fallbacks
The previous default ../../ui resolves to a non-existent directory when
the binary is run from v2/ (common), so /ui/* returned 404 and the
dashboard appeared broken. Default to ../ui and try ../ui, ./ui,
../../ui when the configured path is missing.
Signed-off-by: Chaitanya Tata <chaitanya@dotstarconsulting.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
---------
Signed-off-by: Chaitanya Tata <chaitanya@dotstarconsulting.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
`vendor/midstream` is a git submodule of RuView but no `v2/crates/*` depends
on a `midstreamer-*` crate and no Rust source uses one — i.e. it is vendored
but not consumed, the same state `vendor/rvcsi` was in before ADR-097.
ADR-098 evaluates whether to change that. The candidate seams (from the
prompt) were:
1. Streaming / pub-sub for the WS fan-out (today: `tokio::sync::broadcast`
at `wifi-densepose-sensing-server/src/main.rs:4769`).
2. CSI → DSP → event pipeline (today: rvcsi-events::EventPipeline, just
adopted by ADR-097).
3. Multi-source merging / TDM for the ESP32 mesh (ADR-029, ADR-073).
4. Backpressure / flow control between the UDP receiver and downstream
consumers (firmware `stream_sender` ENOMEM; host-side bounded
broadcast channel).
Reading all six midstream workspace crates end-to-end
(`vendor/midstream/crates/{temporal-compare,nanosecond-scheduler,
temporal-attractor-studio,temporal-neural-solver,strange-loop,
quic-multistream}/src/*.rs` — ~3,455 LOC) shows midstream's identity
unambiguously: `Cargo.toml:16` calls itself "Real-time LLM streaming with
inflight analysis", the README frames it as analyzing *LLM token streams*
in real time, and zero hits across the workspace for `csi|wifi|sensing|
sensor`. midstream's abstractions are LLM-token / dashboard-telemetry
shaped; RuView's pipeline is RF-frame / event-detector shaped.
Decisions:
D1 — WS fan-out: keep `tokio::sync::broadcast::channel::<String>(256)`.
midstream offers no equivalent in-process broadcast primitive.
D2 — CSI pipeline: keep `rvcsi-events::EventPipeline` (deterministic,
single-frame-at-a-time, replayable per ADR-095 D9). midstream's
attractor / LTL crates operate on multi-dimensional trajectories,
not validated single CSI frames.
D3 — TDM / aggregator: keep `wifi-densepose-hardware::aggregator` +
firmware-side TDM. midstream has no UDP merger and no cross-device
wall-clock scheduler.
D4 — Backpressure: the firmware ENOMEM rate-limit and the bounded host
`broadcast` channel are correct at each end; midstream's QUIC
primitives don't help the actual UDP+WS topology.
D5 — Carve-out: `midstreamer-temporal-compare` (DTW / LCS / Levenshtein)
is a plausible future-evaluation option if a *second* DTW use case
appears in RuView. RuvSense already has one (`gesture.rs`).
D6 — Carve-out: `midstreamer-scheduler` (deadline-aware, EDF / LLF /
RM) is a plausible future option if the cluster-Pi aggregator ever
takes over real-time scheduling. Today that lives in firmware.
D7 — Submodule: keep `vendor/midstream` pinned at `30fe5eb` as reference
material; do not advance the pin per-release (unlike vendor/rvcsi
under ADR-097 D7) because there is no in-build consumer.
D8 — Docs: cross-reference, don't import. ADR-098 added to
`docs/adr/README.md`.
Status: Rejected (with named re-evaluation triggers in §6 — second DTW use
case, host-side real-time scheduler, midstream gains a CSI adapter, or a
QUIC-to-external-client requirement that WS can't service).
* docs(tutorials): add Pi 5 + Hailo cluster rvcsi tutorial
Field-tested walkthrough for building a 4-node Raspberry Pi 5 + 2×
Hailo-8 multistatic Wi-Fi CSI cognitive RF observer using rvcsi. Built
against the v0-appliance v0.5.0-cognitive-rf-observer milestone — 446k+
observed fingerprints, 16 stable RF states, 2nd-order Markov running at
39% top-1 ceiling (1.06× over 1st-order, 16× chance baseline).
Covers:
- Pi 5 + Hailo hardware bring-up (BOM ~$580 + workstation)
- nexmon_csi native ARM build recipe (cross-compile is a dead end)
- Per-node services + per-host topology (15 expected services across 4 hosts)
- Workstation pipeline: 3 daemons + 7 timers, brain HTTP + SQLite
- 12 brain categories from spatial-vitals through rfmem-fleet
- cog-query CLI: 34 subcommands, 4 JSON modes, --post for 2
- Calibration recipe: walk → cluster → warm-start IDs → Markov chain
- 13-axis anomaly detector w/ composite info score (1.0–8.0)
- Fleet-health triad: check-drift + replica-status + fleet-status
- Troubleshooting table for the painful lessons (clock skew, cp -r footgun,
self-loop dominance in Markov argmax, etc.)
Pairs with a detailed cookbook gist (linked from intro + steps 3, 4,
and the Reference section):
https://gist.github.com/ruvnet/88e7b053c41cb4f4af7a7ec4af873017
Co-Authored-By: claude-flow <ruv@ruv.net>
* docs(tutorials): clarify rvcsi naming + add ADR-207 cutover note
Two amendments per ADR-207's "naming defect — fix immediately regardless"
action item:
1. Intro callout: when the tutorial was first written, "rvcsi" was a
naming convention only (no upstream library dep). As of 2026-05-13
the v0-appliance accepted ADR-207 Option D and shipped a Rust
binary built on the real rvcsi-runtime. Both stacks can coexist on
a mixed cluster during cutover.
2. Per-node services section: explicit note that cog-csi-emitter +
cog-csi-adapter + cog-rvcsi-stream are being consolidated into one
cog-rvcsi-pi Rust binary, with deploy + rollback commands and
scope (per-Pi cutover, mixed clusters OK).
The tutorial's overall instructions remain correct for both pre- and
post-cutover deployments — fleet-status, the operator surface, and
the architectural model are unchanged.
Co-Authored-By: claude-flow <ruv@ruv.net>
The verify.py "platform-independent for IEEE 754 compliant systems"
docstring at archive/v1/data/proof/verify.py:172 is incorrect — scipy's
pocketfft uses SIMD vector kernels (AVX2/AVX-512 on x86_64, NEON on
Apple Silicon) that reorder FP operations differently across builds, so
the SHA-256 of the production pipeline diverges at ULP precision per
platform. That divergence is what bug report #560 caught on macOS arm64.
This script reproduces verify.py's hash-relevant scipy.fft.fft + Hamming-
window calls in isolation on a deterministic synthetic input, without
dragging in src.app / pydantic Settings. Run on each platform and diff
the JSON output:
python3 scripts/probe-fft-platform.py
- If two machines print the same first8_doppler_bytes_hex and the same
first4_psd_floats but different sha256, the divergence is in later FFT
bins (SIMD reordering).
- If even the first values differ, it's true ULP-level divergence at
every bin (NEON vs x86_64, or different scipy pocketfft builds).
Captured empirical evidence across Windows (Intel AVX-512), Linux x86_64
(ruvultra), and Apple Silicon (ruv-mac-mini) — Win + Linux agree on first
PSD values but produce different SHA-256s; Mac arm64 differs at the first
bins at ~1 ULP precision (~2e-14 on a value of ~94).
This commit ships only the diagnostic. The architectural fix for #560
(quantize-before-hash in features_to_bytes(), then regenerate
expected_features.sha256 on a canonical CI platform) is left as a
separate maintainer decision because it changes a published trust-anchor
artifact and merits a deliberate call.
Supersedes the probe portion of PR #577 (the verify path fix from #577
already shipped via PR #590).
@xiaofuchen's code audit in #568 was correct: the firmware's
`pkt.n_persons` is `s_top_k_count / 2` (clamped) — a subcarrier-slot
partition, not a learned classifier. The README's old wording
('Multi-person estimation', 'Presence sensing') reads stronger than
`edge_processing.c:481-548` actually supports. Same-direction fix as
commit bd4f81749 (which retracted the 92.9% PCK@20 claim because
ADR-079's eval phases are still Pending) and ADR-099 §D8 (which
honestly amended the 10× latency target because it's unreachable on
1-D scalar features).
Three things this commit changes:
1. **Headline-table 'Presence sensing' -> 'Presence indicator (heuristic)'.**
Adds an explicit caveat that strong RF interference can false-positive
without re-calibration, with a link to the detailed Tier-2 section.
The marketing word 'sensing' implied a classifier; the code is a
variance threshold.
2. **Tier-2 bullet 'Multi-person estimation' -> 'Multi-person slot count'.**
Now reads:
'partitions the top-K subcarriers into top_k / 2 groups (clamped to
[1, EDGE_MAX_PERSONS]), computes per-group filtered breathing/heart-
rate estimates, and reports the slot count as pkt.n_persons. This
is a slot-capacity heuristic, not a learned counter — the reported
count tracks subcarrier diversity, not actual occupancy.'
Links directly to `main/edge_processing.c:481-548` so the user can
verify the claim against the code.
3. **New 'What this firmware does NOT do (Tier 2 caveats)' subsection.**
Three explicit non-claims:
- No trained neural model on the ESP32 — the person count is
arithmetic, not inference.
- No pose estimation on the ESP32; pose comes from the host's Rust
server, and only runs learned inference when --model <rvf-file> is
passed. Without a trained model, the host runs signal-based
heuristics, not keypoint inference. Same point as #509 / #506.
- Presence indicator false-positives under fans/microwaves/AP TX
swings without re-running the 60 s ambient calibration. Notes the
concrete remedy (power-cycle in an empty room).
Closes#568.
The sensing-server binds to 127.0.0.1 by default with no `Host` header
validation on either router. A foreign page can lower its DNS TTL,
re-resolve to 127.0.0.1 after the browser has accepted the origin, and
then read live pose + vital signs from /api/v1/* + /ws/sensing as
same-origin against the attacker's hostname. When `RUVIEW_API_TOKEN` is
unset (the documented LAN-mode default from #443/#547) the attacker
can also drive state-mutating POSTs (recording/start, models/load,
adaptive/train, calibration/start, sona/activate).
Defense: a small `host_validation` axum middleware that pins the `Host`
header to a configurable allowlist. The loopback names (`localhost`,
`127.0.0.1`, `[::1]`, each with or without a port) are always in the
set, so default 127.0.0.1 deployments keep working from the local
browser without any configuration change. Operators who bind to a
routable address extend the set with one or more `--allowed-host`
flags or a comma-separated `SENSING_ALLOWED_HOSTS` env var.
Reverse-proxy deployments that already canonicalise `Host` opt out
with `--disable-host-validation`.
The layer is wired into both the dedicated WebSocket router on
`--ws-port` (8765) and the main HTTP router on `--http-port` (8080),
so /ws/sensing on either listener is covered. Rejection responses are
`421 Misdirected Request` (the correct status for a request that
arrived at a server that does not consider the supplied `Host`
authoritative); missing `Host` is `400 Bad Request`.
CWE-346 (Origin Validation Error), CWE-350 (Reliance on Reverse DNS).
Severity: high.
Tests: 13 new unit tests on the middleware (loopback defaults,
case-insensitivity, IPv6 bracketing, port stripping, env-var/CLI
merge, foreign-host rejection on /health + /ws/*, disabled-allowlist
escape hatch). Full suite: 220/220 pass under
`cargo test -p wifi-densepose-sensing-server --no-default-features`.
Co-authored-by: Aeon <aeon@aaronjmars.com>
rUv
Mathew005
Grzegorz Malopolski
OrbisAI Security
dependabot[bot]
Chaitanya Tata
Timothy Schwarz
DavidKrame
Rahul
@aaronjmars
NgoQuocViet2001