Training does not start – /ws/train/progress returns 404 and no model is generated

[PiotrBejza]

Hi,

I'm testing the latest main branch of RuView with 4× ESP32-C6 nodes and I cannot get model training to work.

Environment
Latest main branch (fresh clone)
Ubuntu 24.04
Python 3.12
Docker image: ruvnet/wifi-densepose:latest
4× ESP32-C6
Full CSI frames are being received correctly (--edge-tier 0)
What works
ESP32 nodes connect successfully.
UDP packets are received.
Live visualization works.
Recording works correctly.

Example:

Recording stopped: rec_1782994280 (629s)
Recording rec_1782994280: stop signal received (57367 frames)
Recording rec_1782994280 finished: 57367 frames written

The recording file (rec_1782994280.jsonl) is created correctly.

Problem

When I start training from the web dashboard, the frontend reports:

Connecting progress stream
ws://localhost:3000/ws/train/progress

Immediately afterwards:

GET ws://localhost:3000/ws/train/progress
HTTP/1.1 404 Not Found

Browser console:

Firefox can't establish a connection to ws://localhost:3000/ws/train/progress

[TRAIN-ERROR]
Progress stream error

Progress stream disconnected

The backend logs only show:

Training started with config:
{
"dataset_ids":["rec_1782994280"],
"config":{
"batch_size":32,
"epochs":100,
"learning_rate":0.0003,
"patience":15
}
}

After that:

CPU usage stays near idle.
No additional training logs appear.
No trained .rvf model is generated.
Additional information

Initially I had an installation issue caused by:

allowed_hosts

in .env, which expected a JSON array. After changing it to:

ALLOWED_HOSTS=["*"]

installation completed successfully, but the training issue remains.

Questions
Is model training currently supported in the latest main branch?
Is /ws/train/progress expected to exist?
Is there a CLI command or REST API that should be used instead of the dashboard?
Is there any additional service or feature flag that needs to be enabled for training?
Could someone provide the current workflow for training a custom .rvf model from recorded CSI data?

Thanks!

[ruvnet]

Thanks for the detailed report. The /ws/train/progress WebSocket endpoint is not yet exposed in the stable server — the training pipeline (room-calibration specialists, MAE pretraining) runs via the CLI (wifi-densepose train-room) rather than through the HTTP/WebSocket API, which is why the Docker image returns 404 for that path.

For now:

• Use wifi-densepose train-room from the CLI inside the container, or build the wifi-densepose-train crate directly (cargo run -p wifi-densepose-cli -- train-room).
• The Known Issues guide at Known Issues & Setup Troubleshooting Guide #301 has the current list of confirmed gaps including training UI status.

The REST training endpoint is on the roadmap (tracked in #749) but not in the current release.

---

Generated by Claude Code

[SANJAYSIVAN]

Thanks for clarifying! Since this is a point of confusion, would you like me to submit a quick PR to update the README/Docs to explicitly state that training must be run via the CLI right now, so other users don't hit this 404?

[PiotrBejza]

Thanks for the clarification.

I continued investigating and found what appears to be another issue.

I followed the recommended CLI workflow:

cargo run -p wifi-densepose-cli -- calibrate
cargo run -p wifi-densepose-cli -- enroll
cargo run -p wifi-densepose-cli -- train-room

However, calibration never succeeds because every CSI frame is rejected.

With the current firmware running on ESP32, I consistently get:

[calibrate] WARN frame skipped: subcarrier count mismatch: expected 52, got 192

Trying different PHY tiers produces similar results:

--tier ht20  -> expected 52, got 192
--tier ht40  -> expected 114, got 192
--tier he20  -> expected 256, got 192

I inspected the calibration code (crates/wifi-densepose-signal/src/ruvsense/calibration.rs) and found that the supported layouts are currently hardcoded as:

• HT20 → 52 active subcarriers
• HT40 → 114 active subcarriers
• HE20 → 256 active subcarriers
• HE40 → 484 active subcarriers

The firmware included in the repository consistently transmits CSI frames containing 192 subcarriers, which does not match any of the supported calibration profiles.

Because of this:

• baseline.bin is never generated,
• enroll fails because baseline.bin does not exist,
• train-room fails because enrollment.json is never created.

Is the current firmware expected to output 192 subcarriers?

If so, should the calibration CLI support this layout, or is there another firmware configuration/build that produces the expected CSI format for the current training pipeline?

At the moment it seems that the latest firmware and the current CLI calibration pipeline are not compatible, making room calibration and training impossible to complete.