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.