After 3 systematic hypotheses tested + rejected (radio coex, OpenThread
shadowing, manual RX re-arm), the 802.15.4 leader-election bug is
narrowed to: TX path works perfectly (~10/s clean, 0 fail), but the RX
path stops after exactly 1 frame. Manual esp_ieee802154_receive() from
either callback bootloops the driver (verified across all 3 boards).
The IDF reference example uses the same handle_done-only pattern as
this code, implying the driver should auto-restart RX — but empirically
doesn't here. Either a half-duplex radio state issue or an IDF v5.4
bug. Tracked as known issue D1 in WITNESS-LOG-110.
Changes shipped:
- c6_twt.c: ESP_ERR_INVALID_ARG added to graceful-fallback list
(empirically: ruv.net AP advertises TWT Responder=0, IDF driver
validates against AP HE capability and rejects with INVALID_ARG)
- c6_timesync.c: diagnostic counters (s_tx_count, s_tx_fail, s_rx_count,
s_rx_magic_match) + per-10-beacon log line preserved so future
investigation has the diagnostic harness ready
- sdkconfig.defaults.esp32c6: 15.4 channel default 15 → 26 (non-overlap
with WiFi 2.4 GHz channels), OpenThread disabled (we use raw 15.4)
- promiscuous=true on the radio (broadcast frames addressed to 0xFFFF)
- WITNESS-LOG-110 §D1 expanded with the full diagnostic trace +
3-hypothesis investigation record
Cross-node sync claim (B3) BLOCKED until either an IDF maintainer
trace or a working multi-board reference is available. The other
three SOTA dimensions (HE-LTF, TWT cadence, 5 µA hibernation) are
also still unverified and need different hardware (11ax AP, INA meter)
— honestly recorded in §B.
Tracking: ruvnet/RuView#762, task #30 closed as known-issue.
Co-Authored-By: claude-flow <ruv@ruv.net>
66523843e6