wifi-densepose/firmware
ruv e69572ff99 fix(csi): ADR-018 byte 19 bit 4 now signals ESP-NOW sync too (not just broken 15.4)
WITNESS-LOG-110 prior state had byte 19 bit 4 (cross-node sync valid)
only being set from c6_timesync_is_valid() — but c6_timesync is the
802.15.4 path that D1 documented as unfixable in IDF v5.4 (rx=0 across
every soak we've run). The working transport is c6_sync_espnow (§A0.7,
§A0.10: 99.43-99.56% RX cross-board, 104 µs smoothed-offset stdev),
yet frames from sync'd nodes had bit 4 cleared because the ESP-NOW
path didn't OR into the flag.

Fix: also set bit 4 when c6_sync_espnow_is_valid() — the OR semantic
means a node signals sync from whichever transport is healthy. Host
sees bit 4 set, knows to pair the frame against the most recent sync
packet (§A0.12) from this node_id.

Side effect: this also enables S3 boards to set bit 4 (c6_sync_espnow
works on both targets, c6_timesync is C6-only). So a multi-target
mesh of S3+C6 boards now correctly signals cross-node alignment
regardless of which chips are in the fleet.

Build evidence: C6 image 1019 KB (+16 bytes for the new check),
45% slack unchanged.

Co-Authored-By: claude-flow <ruv@ruv.net>
2026-05-23 12:47:06 -04:00
..
esp32-csi-node fix(csi): ADR-018 byte 19 bit 4 now signals ESP-NOW sync too (not just broken 15.4) 2026-05-23 12:47:06 -04:00
esp32-hello-world firmware/esp32-hello-world: ESP32-C6 target and ESP-IDF v6 build fixes (#524) 2026-05-17 18:00:45 -04:00