DEVLOG #23

The issue encountered during initial startup was a design error: the LD2450 had been mounted rotated by 180°. The UART routing itself was correct.
After rotating the sensor and reflashing the ESP32-C3, everything worked again, though the physical setup doesn’t look very tidy.
I designed PCB-03 based on PCB-02. The LD2450 connector and its wiring have been rotated by 180°.
Everything else remains unchanged. I also added ground planes.
Until the PCB arrives, the breadboard setup will continue to serve as a temporary mmWave configuration.

Next steps: order PCB-03, mount the LD2450 in the marked orientation, and repeat the live radar verification. Continue using the breadboard setup until delivery.

DEVLOG #22

I fixed the last browser security gap found in the local security review: a page on one local port can no longer reach an unauthenticated service on another local port by default.

The review contained 13 entries. Entries 8 and 11, and entries 12 and 13, were duplicates, leaving 11 unique findings.

The old check trusted the hostname alone, so every localhost port was accepted. I separated browser Origin validation from the existing Host/DNS-rebinding protection. WebSockets and state-changing /api/v1/* requests now require an exact scheme, host, and port.

By default, only http://localhost:<http_port>, http://127.0.0.1:<http_port>, and http://[::1]:<http_port> are allowed. Repeatable --allowed-origin values or the comma-separated SENSING_ALLOWED_ORIGINS variable explicitly replace these defaults. Host-only values, wildcards, null, paths, userinfo, and invalid ports are rejected.

The protection covers /ws/* and /api/v1/stream/pose on both the HTTP and dedicated WebSocket ports. CLI clients without an Origin header remain compatible.

The regression test now returns 403 for an unlisted cross-port UI, while an explicitly allowlisted cross-port UI still works. All 24/24 Origin/Host tests, 471 sensing-server tests (1 ignored), HomeCore server/API/auth/WebSocket tests (18 + 18 + 6 + 5), and 7 Python/firmware security-boundary tests passed. Binary checks, targeted rustfmt, and git diff --check also passed. No flash or OTA action was performed.

The ESP-IDF v5.4 build matrix is still inconclusive: the native ARM64 image is missing a containerd layer, while the AMD64 fallback crashes in the emulated Xtensa compiler inside MbedTLS. I therefore do not count the three firmware builds as passed.

Next: Solder PCB-02 first, then mount the mmWave sensor in the corner.

DEVLOG #21

The 65-second empty-room calibration failed before it could collect a usable
baseline. The UI showed Samples 0 when I returned, so no calibration ID or
context hash was created.

The failure exposed a design problem in the run itself. A recoverable
outside-room radar target could stop the entire measurement. I’m changing the
workflow so the run always reaches its configured end and evaluates the
evidence afterwards. The final report will mark it valid or invalid with
concrete reasons instead of hiding the failure behind an early stop.

This behavior change is planned, but not yet implemented or validated. No
successful calibration, restored baseline, 10/10 acceptance, position index,
guided room walk, or blind-test result is claimed.

Next: implement and test the non-interrupting run plus the post-run validity
report

DEVLOG #20

Today I finally found why the four RX streams kept disagreeing: the server was
fusing packets from different transmitter moments. The old path had already
reached 98,126 engine errors with a timestamp spread of about 710 ms.

The first timing fix exposed the deeper problem. The server was simply taking
the latest packet from each receiver, even when those packets did not belong to
the same event. I replaced that with bounded per-RX queues and approximate-time
matching. The existing 60 ms guard stays fail-closed, so an incoherent quartet
is discarded instead of becoming a fake D6 input.

The new tests cover packet loss, reboots, sequence wrap, clock jumps, queue
matching, and host-time fallback. 484/485 tests passed in the sandbox,.

Next: restart the server and verify a stable, error-free 25-second preflight. But for now, time to sleep.

DEVLOG #19

I activated the new mmWave firmware and got the live 25-second preflight to
pass once, but the first empty-room recording did not complete.

The main work was hardening the transport: the firmware now sends redundant
radar packets, while the server handles reordering, duplicates, short CSI gaps,
and recent diagnostics instead of relying on cumulative counters. The UI also
gained a controlled empty-room countdown.

The remaining failure is intermittent: the sensor stays online and reports no
local UDP send errors, but the server still recorded packets_lost=10 and
packets_rejected=324. The empty-room capture lasted only 4.8 s for radar
and 5.1 s for CSI, so it is not a valid calibration reference.

No calibration, training, or blind position result is claimed yet.

Next: expose the exact reject reason and sequence-gap timing, fix the remaining
transport problem, and repeat the complete empty-room measurement.

DEVLOG #18

Since the LD2450 first worked, I connected TX, RX1–RX4, and Wi-Fi, positioned
the sensor, sealed setup-v2, and added a calibration preparation phase with a
countdown and a minimum duration of 60 seconds.

The real hardware UI is running on port 8080; port 3002 still shows the
simulation. I started the workflow, but it currently stops at step 4, the
empty-room Wi-Fi baseline, because radar packets are being lost.

I improved server-side packet sorting and built a new 10 Hz firmware. The OTA
update started, but the device still boots the old firmware from ota_0 at
about 20.6 Hz.

The sensor is online, but calibration is not ready. 63 UI tests pass; one
Rust test mismatch remains. No real D6 calibration or blind validation has
been completed yet.

Next: activate the 10 Hz firmware, resolve the packet-loss blocker, and rerun
the preflight and empty-room baseline.

DEVLOG #17

I finally verified the complete breadboard mmWave data path with the
HLK-LD2450.

After flashing the known firmware to a new ESP32-C3, it joined csi-test,
received 192.168.4.2, and exposed /ota/status on port 8032. The status
confirmed the expected UART mapping: GPIO20 RX, GPIO21 TX, and 256000 baud in
calibration mode.

The important test was a read-only UDP capture: 224 valid LD2450 datagrams in
20 seconds, followed by 222 more while the setup was powered only from the
normal power supply. Every packet matched ruview.mmwave.ld2450.v1 and
contained a recognized target. This proves that the breadboard wiring, UART
parser, ESP Wi-Fi connection, and UDP transport work together. The reported
coordinates are still sensor-frame data, not a validated room position.

The permanent PCB-02 is still pending. Next I will validate the radar
transform with known room marks, connect the CSI receivers, and continue with
D6 calibration, training, blind tests, and the quality gates.

DEVLOG #02

The monitoring loop now takes exactly one Guider 2S camera snapshot per minute and can switch on the printer light when the image is too dark.

I connected the app to Home Assistant’s Core API and configured light.cab_guider_ii_series_light as the automatic camera light. The app measures the configured ROI, and when its 75th-percentile luminance falls below 45/255, it turns the light on for the next scheduled snapshot. It does not immediately retry the dark frame, so the one-image-per-minute limit remains true.

The most important decision was keeping the one-image limit even when the first frame is dark. The tricky part was that changing the app’s default interval did not change the existing Home Assistant option, so I updated the stored option from 5 to 60 seconds, restarted the app, and verified that version 0.1.3 is running with poll_interval_seconds: 60.

This milestone proves that the new lighting and cadence configuration is released on main, and all 16 automated tests pass. The printer is currently off, so the camera/light behavior is not yet live-validated. Shadow mode, phone notifications, and printer decisions remain disabled.

Next: turn the printer on, verify the app-container camera connection and dark-frame light response, then complete two full shadow-mode prints before testing the phone notification and controlled pause/continue flow.

DEVLOG #16

The ESP was not the problem

After the original PCB failed during WLAN authentication, I redesigned the mmWave carrier as PCB-02 and isolated the ESP to find the real cause.

PCB-02 replaces the too-small ESP contact pads with proper through-hole header rows, keeps the case-compatible outline, protects the antenna area, and retains the SMD capacitors. The routing and electrical checks passed, and the Gerbers are ready to order.

The important experiment came next. I unsoldered the suspect ESP from the old PCB and powered it by itself. It joined csi-test, answered every ping, and returned HTTP 200 from /ota/status. A second ESP did exactly the same without any PCB attached.

This was the key finding: both ESPs work outside the PCB. The earlier auth → init failure is therefore very unlikely to be a dead ESP. The likely cause is the old PCB assembly, its soldered fly-wires, power delivery, or the antenna/contact area.

The LD2450 UART and radar path are still unverified.

Next: as an interim solution, continue on a breadboard with one known-good ESP and the LD2450 before moving to manufactured PCB-02.

DEVLOG #15

D4/D5/D6 evidence package

I consolidated every archived D4/D5/D6 recording into one reproducible technical report and a 25-run CSV inventory. I kept historical A/G captures separate because their sample rate and guard settings do not support a direct percentage comparison.

The result is clear: pooled D4 retained 88.4% still recall but produced 75.2% empty-room false presence. Historical D5 replay looked strong at 0.0% false presence and 89.3% recall, but the real D5 live run and D5-abs still-person run both collapsed to 0% recall. D5-abs therefore reduced false presence only by making still presence unusable.

I also audited all five D6 raw CSI files against their sidecars. Every file is complete, has zero recorder drops, includes RX1–RX4, and uses one 2.437 GHz / 1-antenna / 64-subcarrier grid. The current empty-neutral-02 capture is a valid same-setup baseline candidate; the older setup and discovery capture remain separate.

This is technical evidence, not an accuracy claim. No phase yet has independent mmWave ground truth, blind position validation, or a proven live localization path.

Next I will install the heat-set thread inserts in the mmWave case and then check whether everything works as intended before deciding how to proceed.

DEVLOG #14

Since the last devlog, I published a new Observatory Control Center and a
guided calibration workflow for the D6 experiment.

The setup now includes a CAD-style room editor for the TX and RX1–RX4
positions. It validates room boundaries, duplicate receiver positions, and the
canonical node IDs. The continuous mmWave calibration route is now the primary
workflow; the manual P01–P09 grid remains only as a legacy fallback.

Experiment profiles, run phases, setup hashes, and prediction/truth artifact
hashes are persisted in SQLite. The UI also makes READY, RUNNING, PASS,
OFFLINE, and SOFTWARE-ONLY / UNVALIDATED states explicit, so a simulated
workflow cannot be mistaken for a real sensor result.

I ran 41 UI/Observatory tests and 4 targeted Rust workflow tests; all
passed. This validates the software workflow, but not the real CSI stream,
LD2450 UART/UDP path, calibration data, or position accuracy.

Next: connect the LD2450 to the working ESP on the breadboard, verify UART
bytes and valid radar frames, and then continue with the sealed hardware
workflow and real blind tests.

DEVLOG #13

I narrowed the Wi-Fi authentication problem down to the original ESP32-C3.
A second ESP running the same firmware connected to csi-test, received an IP
address, and started its HTTP server successfully. This shows that the TX,
credentials, and firmware work in principle—and that the LD2450 is not causing
the current Wi-Fi failure.

The original ESP (ac:a7:04:c2:71:f4) is now the main suspect, possibly because
of its Wi-Fi hardware, power stability, flash state, or an access-point client
entry.

I also planned a breadboard-compatible power setup for testing without the SMD
capacitors: a through-hole 100 nF ceramic capacitor and 10 µF electrolytic
capacitor across 5 V and GND, placed close to the ESP and radar connections.

The radar itself has not passed a UART test yet. Next, I will connect the
unpowered LD2450 to the working ESP and check whether UART bytes and valid radar
frames increase.

DEVLOG #12

I built a new Observatory Control Center that guides the experiment through
all ten phases—from creating and sealing the setup to calibration, blind tests,
evaluation, and the final report.

Run metadata, setup profiles, phase history, and artifact hashes are now stored
persistently in SQLite, while the raw recordings remain separate files. The UI
shows clear READY, RUNNING, PASS, OFFLINE, and UNVALIDATED states and
keeps software-only demonstrations separate from real measurements.

I also made continuous mmWave-guided calibration the main workflow. The manual
P01–P09 capture grid remains available only as a legacy fallback.

All 29 UI tests and all 4 targeted SQLite/workflow tests pass. This verifies
the software workflow, but does not yet validate the real sensors or position
accuracy.

Next: connect the finished hardware and run the guided workflow with real data.

DEVLOG #11

I started assembling the reference-sensor PCB and soldered the available
parts. The SMD capacitors have not arrived yet, and the ESP pads turned out to
be too small for reliable soldering, so I have started connecting the ESP with
wires instead.
On the software side, I added diagnostics for UART bytes, valid radar frames,
UDP transmissions, and errors. The server and UI now display these values and
detect connection or network problems.
I also tested the complete software path synthetically—from radar input through
calibration, position indexing, blind-test gates, and the UI. All relevant tests
passed, including 10/10 UI tests. This confirms the software path, but not the
final live hardware setup.
A read-only CSI check currently receives no RX packets. The last discovery did
find TX and RX1–RX4 with a stable 64-subcarrier grid, although sequence gaps
were around 5–6%.
Next: finish the wiring, add the capacitors, and restore live CSI reception.

DEVLOG #01

The Spaghetti AI detector is now running as a Home Assistant app and watching the Guider 2S camera in safe shadow mode.

I first created and verified a protected Home Assistant backup. Then I installed the CPU-only ONNX detector, connected its status to MQTT, and checked the live service: it currently reports normal, a score of 0.0, and no error.

The most important decision was keeping detection separate from printer control. Shadow-mode detections can be recorded for evaluation, but the software cannot pause or abort the active print. Phone notifications and the Home Assistant decision automations also remain disabled.

The difficult part was fitting the model into a lightweight Home Assistant app. I limited ONNX Runtime to one CPU thread and disabled its CPU memory arena instead of deploying the much larger full Obico server.

This milestone proves that the monitoring pipeline is installed and running. It does not yet prove that spaghetti detection is accurate enough for real printer decisions.

Next: complete two full shadow-mode prints, review every detection, and only then test the phone notification and a controlled pause/continue decision.

DEVLOG #10

I completed the calibration and evaluation pipeline for WiFi positioning
with an HLK-LD2450 reference sensor.
The new system includes:

• ESP32-C3 firmware with UART parsing, room coordinates, operating modes,
  Wi-Fi transmission, and protected configuration;
• persistent coordinate transformation with origin, rotation, and optional
  mirroring;
• synchronization of mmWave and RX1–RX4 CSI data within 150 ms;
• a 65-second empty-room reference;
• automatic room coverage with nine reachable zones (P01–P09) and six
  training blocks per zone;
• a position index that uses only CSI after calibration;
• blind evaluation with separated WiFi predictions and mmWave reference data;
• fixed quality thresholds with automatic acceptance or rejection; and
• a guided German calibration assistant in the UI.
  The PCB has also arrived. I am checking it carefully before soldering and
  starting the first complete hardware tests.
  Next: verify the PCB, solder the components, and test the full system.

DEVLOG #09

I 3D-printed the case and a PCB mockup to test the fit. The IKEA Skådis mount
and the retaining posts were slightly too large, possibly because supports
were placed in the wrong areas.
I have already updated the 3D model and will print the revised version
tomorrow.

DEVLOG #08

I finished the firmware and flashed it onto the ESP32-C3 SuperMini for the
mmWave reference sensor.

It uses the correct UART pins (GPIO20 RX, GPIO21 TX, 256000 baud), parses
all three LD2450 targets using the
official protocol,
and sends timestamped UDP JSON data. It also separates calibration and
reference recordings, supports protected A/B OTA, detects ambiguous
multi-person measurements, and allows configurable radar placement.

The firmware is ready, but the final PCB still needs to arrive. I then need to
solder it before any complete hardware testing can begin. I will also finish
the IKEA-board mount, print the case, and check the PCB fit—especially the
retaining posts.

Next: receive and solder the PCB, print the case, and test everything together.

DEVLOG #07

I added small retaining posts to hold the PCB securely inside the mmWave
sensor case.
I also designed a holder for mounting the enclosure to an IKEA board. These
details should keep both the electronics and the finished case in place, but
they still need to be printed and tested for fit.
Next: print the parts and check the tolerances.

DEVLOG #06

I continued redesigning the mmWave reference sensor case and replaced the
honeycomb pattern with cleaner parallel openings.
I also refined the inside of the enclosure by adding two posts and a
rectangular internal feature. The case now has a much cleaner shape, but it is
still a CAD design and has not been printed or tested yet.
Next: check the component fit and prepare the case for printing.