802.15.4 time-sync after #2161: offset not applied, CSI cost, last-heard leader election #2162

PR #2161 (ESP32-C5 target, ADR-383) makes the 802.15.4 time-sync path (CONFIG_C6_TIMESYNC_ENABLE, firmware/esp32-csi-node/main/c6_timesync.c) receive beacons for the first time. This issue tracks what's still missing or broken once #2161 is merged. Time-sync stays off by default, so none of this affects default builds.

Context: what #2161 fixes

Until #2161, a node never received a peer beacon. That's the "only 1 RX event ever fires" note from ADR-110 / #762. #2161 fixes four bugs in c6_timesync.c:

• RX armed only once, with rx_when_idle never set;
• ESP_LOGI in the ISR RX callback, which aborted;
• the beacon built in a stack buffer that the asynchronous transmit read after it had been reused;
• Wi-Fi + 802.15.4 coexistence never enabled.

MEASURED on two ESP32-C5 boards (IDF 5.5.2) after #2161, with time-sync enabled:

• the follower received 708 of 708 beacons intact;
• the Wi-Fi STA got an IP in about 6 s;
• no aborts.

The full write-up is in ADR-383 §3.3 and docs/validation/2026-10-04-esp32-c5-rate-aware-sensing.md.

Still open after #2161

1. The offset isn't used. c6_timesync.h says each CSI frame is stamped with c6_timesync_get_epoch_us(). In practice csi_collector.c only sets a "15.4 sync valid" flag bit (flags |= 1 << 4), and the frame timestamp stays local. So even with beacons arriving, nothing downstream gets a shared clock. CODE-DERIVED.

2. Offset accuracy is unknown. The follower computes offset = leader_epoch_us - local_now at receive time, with no correction for TX queueing, air time or ISR latency, and no smoothing. I haven't measured how close two nodes' corrected clocks are. NOT MEASURED.

3. Leader election is "last heard wins". The comment says lowest-EUI-wins is "deferred". Both nodes start as leader, and the first one heard wins.

   • When the leader's beacons pause for 3 s, the follower promotes itself. On the bench that happened once at 109 s, during a burst of coex-refused transmits.
   • With more than two nodes this can churn. MEASURED (two nodes); CODE-DERIVED beyond that.

4. CSI cost. With time-sync on, 802.15.4 shares the radio. On the C5 the CSI callback yield dropped from about 40 pps to about 27 pps, and about a third of beacon transmits were refused by the coex arbiter. MEASURED. To make this usable it probably needs duty-cycling, for example a short RX window around each beacon instead of continuous RX.

5. RX after TX. feat(firmware): ESP32-C5 dual-band CSI node (ADR-383) #2161 sets rx_when_idle and also re-arms RX from task context after every TX.

   • In one run of a minimal two-board reproducer, RX didn't resume after the node's own TX despite rx_when_idle.
   • Three reruns of that same case without the re-arm didn't reproduce it: two on IDF 5.5.2 and one on 5.5.4, receiving 835-851 of 851 frames.
   • So the re-arm is defensive, and the driver isn't the cause here. Reproducer: https://gist.github.com/aepod/5a097c4b167ba7ebb9869443e6e79f03

6. C6 hardware. The fixes build for the ESP32-C6 on IDF 5.4 with time-sync on and off, but I haven't run them on C6 hardware.

ESP-NOW time-sync is unaffected and remains the default. It matched about 98 % of beacons on the same boards.