DEVLOG #46

RX1’s reconnect firmware passed its 15-minute hardware qualification, and I collected around 21 minutes of UART logs. The original failure didn’t reappear, so I still can’t call the Wi-Fi issue fixed. I restored and verified the original firmware afterward.

I also finished the new firmware builds for RX2, RX3 and RX4. All three include the reconnect fix and diagnostics. RX2 and RX3 also include the packet-age fix, while RX2 gets proper UDP socket locking. These builds are tested offline, but aren’t installed yet.

On the host side, I fixed a race in the logger handoff and tightened the time checks so an installation can’t start without enough time for qualification and a possible safe rollback. The complete installation-to-measurement workflow passes offline, but the real baseline and two-way peer measurements are still missing.

Next: install and qualify RX2–RX4 one at a time, then run the short capture and full baseline/peer comparison.

DEVLOG #45

The setup recorded 5,165 raw frames in a short test, but the run still failed because its rejection log overflowed. I expanded that bounded log and moved slow startup hashing out of the packet-processing locks.

I also installed RX1’s new memory-diagnostic firmware and checked it for about 15 minutes. The old heap dip didn’t reappear, although that doesn’t prove its cause is fixed.

Wi-Fi is now the main headache. TX1’s access point restarted internally, and the receivers didn’t reliably reconnect. Restarting them helped temporarily, but the problem returned. I found a firmware path where an immediately failed reconnect schedules no further attempt. The corrected candidate is built and tested offline, with extra UART diagnostics to capture what happens during a real failure. The actual outage cause is still unproven.

Next: check the reconnect candidate on hardware, capture the failure, then retry the short recording and full baseline/peer comparison.

DEVLOG #44

The offline evaluation finally fits within its three-minute limit. About 155 seconds on the maximum-rate test data, with the same results as before.

A real recording had stopped when RX1 packets arrived out of order. I added a small 10 ms reordering buffer, while stale or invalid data is still rejected. That makes the host more tolerant, but doesn’t explain what caused the original reordering.

I also fixed a recording-start issue where an old packet received before the start could abort the new capture. Rejection details and file closing are more reliable now, too, so failed runs leave better evidence.

Next: verify a clean 30-second recording start, then run the full baseline and two-way peer comparison.

DEVLOG #43

I built a first offline position pipeline that predicts x/z coordinates instead of just fixed zones. It can save and reload a model, but I’ve only tested it with synthetic data so far. Real tracking accuracy is still unproven.

I also traced more of the CSI data path. A diagnostic capture contained 5,005 valid CSI frames from all four receivers, and a fresh offline replay accepted all of them. The running host still wasn’t accepting several receivers correctly, though, so the live issue isn’t fixed yet.

On the measurement side, I tightened capture timing and replaced the oversized blanket storage reserve with a budget based on the actual recording limits. The real storage medium still needs checking.

The main blocker now is processing speed: the maximum-rate synthetic run still exceeds the three-minute evaluation deadline. Recording and the return to the default state work, but that doesn’t make the complete run a pass.

Next: speed up evaluation using the saved test data, then recheck the complete measurement workflow before another live run.

DEVLOG #42

RX3 and RX4 have passed their individual checks on the latest firmware. A complete OTA update, the LED pattern test and ten minutes of stability monitoring each, with no errors recorded.

The false SOS warning on RX1 is also fixed and verified on the board now. I corrected concurrent access in the shared UDP sender and transport statistics, too. Those are real software fixes, but I still can’t claim they explain the original RX3 heap corruption or watchdog resets.

I also improved CAD profile handling. Profiles can use a separate store, the UI shows which revision is loaded, and refreshing no longer overwrites unsaved edits or brings back an older saved version.

The rollout isn’t finished, though. The next RX1 update stopped because its device identity couldn’t be confirmed, so RX2’s update to this latest version hasn’t started either.

Next: resolve that binding, finish updating RX1 and RX2, then move on to the actual two-way peer comparison. Tracking acceptance is still open.

DEVLOG #41

RX1 finally passed a full three-minute TX1→RX1 test. 6,407 qualified CSI frames, around 35.6 per second, and all 173 measurement windows passed. The firmware had been rejecting our setup because TX1 is also the Wi-Fi access point. That’s corrected and installed now.

SOS is the warning for missing or stale usable CSI from TX1. It doesn’t automatically mean the board is broken. Ironically, the warning itself had a bug, RX1 reported stale data even though a matching frame had arrived just 8.7 milliseconds earlier. A timing race between the LED task and CSI reception caused the false alarm. The fix is built and tested offline, but isn’t installed yet.

Host startup and recording also work now. RX2 is still a problem, though: its upload timed out while CSI kept arriving, and the cause isn’t confirmed.

Next: install and verify the LED fix on RX1 before continuing with the other receivers. The actual two-way peer comparison and tracking acceptance are still open.

DEVLOG #40

I cut the recording footprint from 4.54 to 2.67 GB in the full synthetic test, about 41% less. The saving comes mainly from removing duplicate exports, not throwing away raw data or evidence.

I also corrected timing and CSI rate-limit bugs offline, plus a cleanup issue that could prevent the recorder from stopping its own processes when disk space got tight.

The frustrating part is that the peer comparison still hasn’t recorded anything. One attempt stopped on the timing bug, after that was fixed, the next hit a missing signing key during host startup. No peer firmware was uploaded and no capture started in either attempt.

Next: fix host startup and prepare a separate 35-minute pilot. The actual peer comparison and tracking acceptance are still open.

DEVLOG #39

All four receivers finally made it through a full 30-minute CSI run together. RX1, RX3 and RX4 are now on C1, while RX2 stays on C. Each delivered around 17–20 matching frames per second, and 99.61% of the shared measurement windows passed the CSI checks.

The RX1↔RX4 peer firmware and recording workflow are also implemented and tested offline now. The actual radio comparison hasn’t happened yet, so I still don’t know whether those extra links will improve positioning.

One annoying bug kept rejecting good data after a 128→64→128 format change. That’s fixed in the offline analysis, along with separate format rules for TX1 and peer links and a recorder completion check.

I also added RX and radar exports that keep raw data, timing and recording boundaries together. That path works in offline tests; it isn’t a new live hardware result.

Next: check both mmWave sensors individually and then together at known points. The shared CSI run is a milestone, but tracking and full-system acceptance are still open.

DEVLOG #38

RX2 is finally delivering a lot more matching CSI data. After installing the new firmware, the rate went from about 1.9 to 31.9 frames per second. A longer, half-hour capture averaged around 30. The firmware now fixes Wi-Fi bandwidth at 20 MHz and guards against invalid CSI callbacks.

One annoying catch: the long capture only recorded RX2 because some device endpoints were outdated or mixed up. I’ve prepared a stricter preflight so an incomplete group can’t silently become a four-receiver test again.

I also corrected the offline window analysis. A valid frame with a different format no longer ruins an entire otherwise usable window. The UI code now separates format exclusions from unexplained sequence gaps instead of calling everything “loss”. The host fixes are tested locally, but aren’t active on the running server yet.

Next: complete a proper simultaneous four-RX capture, then implement the RX1 <-> RX4 peer profile for testing. Tracking and full-system acceptance are still open.

DEVLOG #37

I narrowed down the RX2 and mmWave2 issues from the failed run. Still no hardware fix, but the picture is getting clearer.

The surprising part is that RX2 was still sending valid CSI packets during its apparent dropout. They just weren’t the 128-subcarrier frames the current evaluation needs. mmWave2, on the other hand, really did have gaps in packets reaching the host. I’m looking into its send-and-acknowledgement path, but haven’t proven the cause yet.

I also found a parser mistake. A supposedly damaged RX packet was actually a valid warning message. That’s corrected in the isolated diagnostic tools, which now also distinguish device timeouts from requests the collector skipped or cancelled.

New diagnostic firmware candidates for TX1, RX2 and mmWave2 are built locally to help trace where things stop moving. They aren’t installed yet, and the TX send errors are still unresolved.

The UI is less misleading now, too: an ESP being reachable doesn’t mean radar data is arriving, and old readings no longer keep disconnected devices looking active.

Next: review the diagnostic candidates, then use a short, controlled hardware run to investigate the remaining errors. The last full acceptance is still a FAIL.

DEVLOG #36

The first full TX1 acceptance run is done now and it failed, but at least I finally have a much clearer picture of what is still going wrong…

The common setup passed: all seven expected participants were visible, and 22 complete snapshots kept the shared basis valid for more than 20 seconds. Then Scope A ran its three 120-second windows. All three failed. There were 14 new TX send errors, and the diagnostic counters placed them in the wifi_handoff ENOMEM stage. That tells me where the error was recorded, but not yet why it happens or whether it is fixed. MMWAVE2 also became stale in parts of the run, and several RX requests were missing, so none of the historical comparisons could count as a valid PASS.

Scope B stopped itself at the safety gate when the source binding became inconsistent and RX2 was already 5.044 seconds old. This is frustrating, but the guard did exactly what it was supposed to do, it refused to turn an incomplete 120-second window into a result.

Next: decide how to continue the ENOMEM and source-binding issues before starting another acceptance run.

DEVLOG #35

I fixed two concrete TX1 firmware bugs. An authentication check that ran too late and an HTTP task with too little stack space.

The status endpoint could lose the request headers before checking authorization. I moved that check ahead of the response. I also increased the HTTP task’s stack from 4 KB to 8 KB after confirming that some call paths could exceed the old limit.

Two independent builds matched byte for byte. After taking fresh backups, I installed the candidate and verified the complete 16 MiB flash against the expected image. That part passed.

The UDP/ENOMEM errors are not yet proven fixed.

Next: investigate the reset path, complete a clean controlled boot, then check the matching server setup, authentication, all participants, and the measurement windows.

DEVLOG #34

The TX1 migration is now 100% verified, but the project is still only around ≈ 70% complete. The third and final boot attempt did not give me the clean result I was hoping for.

Recovery happened within the allowed time, but UART0 showed two app starts. After the first start, an RTC_SW_CPU_RST appeared and the app started again. It eventually reached BOOT_OK, but because of the duplicate start I still cannot accept the boot trace or move on to server activation and measurements. I am currently documenting the exact restart sequence and trying to figure out what caused it.

I also put together a source collection about Wi-Fi sensing and RF-based person detection. GitHub

The separate mmWave freshness test did not reproduce the old MMWAVE2 delay problem, but that does not prove it is fixed.

Next: get one clean TX1 boot, then activate the server and start collecting real measurements.

DEVLOG #33

The TX1 finally made it all the way to BOOT_OK. After the CHECK_COUNTRY problem from the last update, the new candidate passed the Country20/Power44 and Wi-Fi checks, booted into test mode, and passed the local TX/RX4 checks. I also confirmed the amber LED and both mmWave transport paths.

The previous candidate had stopped because one sampling gap grew to 10.2 seconds. I traced that back to the timing bookkeeping and changed the sampler to schedule from the last real sample completion. The corrected run stayed within the sampling limits. That is a real improvement, but it is not the final acceptance yet. The full coverage result is still blocked by the clock-binding requirement, and the radar window only showed no_target, not a position result.

I also switched to the new diagnostic server in a controlled run. It stayed ready and a separate 61-second capture passed the coverage gate, but the active CSI position setup is still missing, so this does not count as a complete TX-7B or system pass.

The CAD UI got a pretty big upgrade too. MMWAVE1 and MMWAVE2 can now be edited as separate sensors with their own colors, 6 m fields of view, direction arrows, and yaw handles. I added a button to aim them at each other, plus a wall-angle tool that draws the real beam/wall intersection and lets me set the angle directly. Marker labels also move out of the way automatically, and the snap setting survives a refresh.

Next: fix the remaining coverage and clock evidence, activate the sealed CAD/CSI setup, and complete the full TX-7B validation.

DEVLOG #32

I still do not really have a final result to show, but it has been another ten hours, so I did not want to skip the devlog.

The latest TX1 boot attempt did at least narrow things down. The new firmware now passes the Wi-Fi channel checks: channel 6, HT40 with the secondary channel below, AP-only mode, and the other radio checks all matched the expected profile. It then stops at CHECK_COUNTRY, before reaching BOOT_OK. The TX1 migration is therefore still not accepted, but the failure is much more specific now.

The confusing part is that the Wi-Fi power values do not line up cleanly. The country structure reports a different power field than expected, while the separate power API returns the expected value. This may be an SDK representation or comparison issue rather than a real transmit-power problem, but there is not enough evidence to call it fixed yet. I also corrected related checks for the country bytes, SSID representation, and status getters, and prepared another reproducible candidate offline.

With the move to Python 3.15, I also added the new lazy-import implementation. The official Python documentation describes the new syntax. Eligible imports now use explicit lazy import and lazy from syntax, with a local verifier to keep the behavior consistent.

After the failed candidate boot, I restored the original 16 MiB image and verified the return path. The historical firmware is running again, and RX4 plus both mmWave sensors are sending data.

Next: resolve the country/power comparison, then attempt the candidate boot again under the existing safety gates.

DEVLOG #31

The mmWave2 connection problem is finally understood. It was caused by a reproducible dependency on the WLAN transmit power: at around 19.5 dBm, the ESP kept running and received probe requests, but its test AP could not be found and connections failed.

At 10 dBm, the AP worked immediately, csi-test connected again, and 360/360 pings succeeded without a disconnect. Raising the limit reproduced the issue, confirming the dependency. Both mmWave sensors now work reliably.

The TX1 migration is also complete. I verified the candidate firmware and baseline, created two identical 16 MiB backups.

The new app was written to app1 together with the NVS merge and OTA selection. A complete readback of all 16,777,216 bytes matched the expected flash image exactly.

Next: Boot the candidate under the existing safety gates, check that TX1 comes up properly, and run the full comparison.

DEVLOG #30

The replacement ESP for mmWave2 is now soldered and mounted on the previously working breadboard setup. The connection problem has not disappeared, however WiFi still fails, so I uploaded a minimal WiFi test script to isolate the radio and network path before testing the radar or UDP transport.

The mmWave firmware now distinguishes MMWAVE1 and MMWAVE2 with separate build and upload paths, uses 55010 as the default UDP port, and logs the WiFi disconnect reason. These changes are prepared locally; the test image is not yet a confirmed fix, and the complete mmWave2 path is still unvalidated.

In parallel, the TX1 replacement reached a stronger local checkpoint. Reproducible builds from fresh and isolated source copies are byte-identical, and the local test suite passed. The 7A TX1/RX4 baseline still produced no usable measurement data, so the migration remains blocked and 7B is NO-GO.

Next: resolve the WiFi connection on the replacement ESP, verify mmWave2 communication, and continue with two-sensor validation and RX3 calibration.

DEVLOG #29

The local RX work has expanded, but the two-sensor setup is currently blocked by a connection problem with mmWave2. RX-04 to RX-12 add bounded capture and queue handling, stale-frame rejection, corrected CSI parsing, clearer UDP/server counters, and timing and synchronization metadata. The firmware host tests, standard and raw ESP32-S3 builds, and targeted server checks pass. These are still software and build results. No live RX measurement has yet proven lower frame loss or data age. :(

The 3D-printed part now fits. While investigating the mmWave2 connection, I tried to desolder its ESP, but it could not be removed cleanly. Since the connection problem is not resolved, I ordered a replacement ESP, a new mmWave sensor, and an FH/Fenghua 1206X106K160NT SMD component. The exact cause is still open, and the replacement parts have not been installed or tested yet. The existing TX1 replacement also remains locally tested but unflashed.

Next: rebuild mmWave2 with the replacement parts, identify the connection fault, validate both sensor paths, and continue with RX3 calibration.

DEVLOG #28

I prepared and locally verified an ESP-IDF replacement candidate for TX1. The firmware builds successfully, and the host-side checks for packet handling, scheduling, boot/OTA variants, and negative compile guards pass. This is still a software-only result. Nothing has been flashed, and TX1 has not been validated on hardware. Before replacing the existing TX1, the old TX1/RX4 baseline and network pre-check must still be completed.

I also tightened the RX data path. Incoming frames are now checked for valid input and correct TX binding before passing through one jitter-tolerant 20 ms admission gate. Invalid or foreign frames no longer consume the timing budget. Callback, queue, UDP, and server-side counters are tracked separately, making it possible to see where loss or delay occurs. The deterministic fixtures and local ESP32-S3 build pass, but no live RX measurement has yet shown an actual reduction in frame loss or data age.

The new 3D print exposed a mechanical error: it is approximately 1 mm too small and does not fit. It needs to be adjusted and printed again.

Next: complete the read-only TX1/RX4 baseline, adjust and reprint the part, then continue with RX3 calibration and validation of both mmWave sensor paths.

DEVLOG #27

I soldered a second PCB from revision 3, making the hardware for two mmWave sensors available. The software now keeps MMWAVE1 and MMWAVE2 separate through stable node identities and independent sequence, transform, and calibration state.

The mmWave transport also crossed an important milestone. Because best-effort UDP was not enough, firmware 0.1.6 now uses ACK-based retransmission. In a controlled 60-second comparison, sequence loss reached 0.00% and the radar_sequence_loss_free gate passed, compared with 0.70% loss and 84 full ACK timeouts on firmware 0.1.5.

The Tauri desktop shell has been replaced in the active build by a loopback control helper for discovery, provisioning, flashing, OTA, and WASM. I also created a new 3D-print file, which is currently being printed; the mechanical result is not finished yet.

Next: validate both sensor paths together, resolve the RX3 Phase 1 offset, and repeat the full radar preflight.