From 572e09ad8639da703c369f97bd82f62a475701a4 Mon Sep 17 00:00:00 2001 From: ruv Date: Sat, 23 May 2026 11:40:56 -0400 Subject: [PATCH] =?UTF-8?q?witness(ADR-110=20=C2=A7A0.7):=20ESP-NOW=20cros?= =?UTF-8?q?s-board=20mesh=20=E2=80=94=20leader=20election=20+=20sync=20off?= =?UTF-8?q?set=20measured?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit SOTA iter 2 (cron c40dab4a tick 2). The §D-workaround that v0.6.6 left on TX-only soak coverage is now empirically complete end-to-end. Parallel 60 s capture with COM9 (206ef117053c) + COM12 (206ef1170084) both on default v0.6.7, no WiFi associations needed: * RX rate cross-board: - COM12: tx=301 rx=297 match=297 (98.7 %) - COM9: tx=301 rx=300 match=300 (99.7 %) - 0 TX failures on either side over 30 s of beacons * Leader election fired for the first time in ADR-110: +27336 ms COM9: "stepping down: heard lower-id leader 206ef1170084 (we are 206ef117053c)" — the lowest-EUI-wins protocol the original c6_timesync was designed to run, now actually working because the transport is healthy. * Cross-board sync offset converged and stable: COM9 offset_us: -1462 -> -950 -> -954 -> -957 -> -948 ±10 µs jitter once leader-following stabilises, hitting the ±100 µs target named in ADR-110 §2.4. 802.15.4 c6_ts path stayed rx=0 across both 60 s captures — D1 still broken in IDF v5.4, exactly as documented. ESP-NOW is confirmed as the working multistatic time alignment transport. Raw captures: dist/firmware-v0.6.7/iter2-{COM9,COM12}-espnow.log. Co-Authored-By: claude-flow --- docs/WITNESS-LOG-110.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/WITNESS-LOG-110.md b/docs/WITNESS-LOG-110.md index c79b54f4..c35f71fa 100644 --- a/docs/WITNESS-LOG-110.md +++ b/docs/WITNESS-LOG-110.md @@ -26,6 +26,7 @@ This witness separates what was **empirically observed on real silicon today** f | **A0.4** | **v0.6.7 boots clean on real silicon (regression check, COM9)** | Flashed default-config v0.6.7 to ESP32-C6 on COM9 (`20:6e:f1:17:05:3c`). Boot log captured in `dist/firmware-v0.6.7/COM9-v0.6.7-regression.log`. Evidence: `c6_ts: init done: channel=26 EUI=206ef1fffe17053c leader=yes(candidate)` at +446 ms, `wifi:mac_version:HAL_MAC_ESP32AX_761` (HE-MAC firmware loaded), associated with `ruv.net` at +5206 ms (DHCP `192.168.1.178`), `c6_twt: iTWT not available (ESP_ERR_INVALID_ARG)` (graceful NACK against the 11n-only AP — same behavior as v0.6.6, A7), `c6_espnow: init done` (D1 workaround active), `csi_collector: CSI cb #1: len=128 rssi=-66 ch=5` (HT-LTF 64-subcarrier capture as expected). Zero regression vs v0.6.6 — new code paths default off, observed behavior is byte-for-byte the v0.6.6 path. | | **A0.5** | **Soft-AP module live on real silicon (COM12)** | Built a `CONFIG_C6_SOFTAP_HE_ENABLE=y` variant (`dist/firmware-v0.6.7/esp32-csi-node-c6-4mb-softap.bin`, 1023 KB / 45% slack), flashed to ESP32-C6 on COM12 (`20:6e:f1:17:00:84`). Boot log: `dist/firmware-v0.6.7/COM12-v0.6.7-softap.log`. **Evidence the new module fires**:

`I (556) c6_softap: soft-AP starting: ssid="ruview-c6-twt" channel=6 auth=wpa2-psk`
`I (556) main: C6 soft-AP HE armed on channel 6 (ADR-110 B1/B2)`
`I (636) wifi:mode : sta (20:6e:f1:17:00:84) + softAP (20:6e:f1:17:00:85)`
`I (666) c6_softap: AP started on channel 6`

The IDF assigns the soft-AP MAC at the STA-MAC+1 offset (`...00:85`), standard behavior. **Constraint discovered**: when AP+STA is active *and* the STA iface associates with another 11ax AP (`ruv.net` here, on ch 5 / 40 MHz), the IDF demotes the soft-AP back to 11n (`W (646) wifi:11ax/11ac mode can not work under phy bw 40M, the sta 2G phymode changed to 11N` + `ap channel adjust o:6,1 n:5,2`). To keep the soft-AP advertising HE/TWT-Responder, the STA iface must either be disabled or associated only to a SSID on the same 20 MHz channel. Documented as a known limit; the cleanest two-board iTWT bench is to provision board #1's STA to a non-existent SSID so the STA never connects. | | **A0.6** | **Two-C6 iTWT bench attempted live — surfaces an IDF v5.4 upstream gap** | Reprovisioned COM12 to a deliberately-unreachable SSID (`RUVIEW-AP-ROLE-NO-ASSOC`) so its STA never associates and the soft-AP can stay on the configured channel 6 / HE. Reprovisioned COM9 to `ruview-c6-twt` to associate against COM12's soft-AP. Parallel boot logs in `dist/firmware-v0.6.7/iter1-{COM9,COM12}-*-role.log`.

**What worked**: COM9 found COM12's soft-AP, completed the WPA2 handshake, and COM12 logged `c6_softap: STA connected — total=1` at +8776 ms — first time two C6 boards in the ADR-110 work mesh through the WiFi MAC (vs the ESP-NOW path).

**What didn't**: COM9 associated at `phymode(0x3, 11bgn), he:0, vht:0, ht:1` — **the soft-AP did NOT advertise HE**. Source of the gap: a full grep of `components/esp_wifi/include/esp_wifi*.h` in IDF v5.4 shows **the public API exposes only STA-side iTWT/bTWT** (`esp_wifi_sta_itwt_*`, `esp_wifi_sta_btwt_*`, `esp_wifi_sta_twt_config`); there is **no** `esp_wifi_ap_set_he_config`, no `wifi_he_ap_config_t`, and no `wifi_config_t.ap.he_*` field. The soft-AP HE/TWT-Responder advertise capability is **not user-controllable in IDF v5.4** for the ESP32-C6.

Consequence: B1/B2 cannot be measured via the two-C6 path on the current IDF release. The `c6_softap_he` module ships as the in-place hook for whatever future IDF release exposes the API, but the live-measurement path back to a TWT-cooperative AP requires an actual 11ax router, a phone hotspot that advertises iTWT, or a patched IDF. **Sharpens the open question from "do we need an 11ax AP?" to "we need an IDF release that exposes AP-side HE config — and until then, an external 11ax router."** | +| **A0.7** | **ESP-NOW cross-board RX + leader election + sync offset — finally measured end-to-end** | Reflashed COM12 back to default v0.6.7 (no soft-AP) so both boards run identical config. Parallel 60 s capture in `dist/firmware-v0.6.7/iter2-{COM9,COM12}-espnow.log`. **The §D-workaround promise from v0.6.6 is now empirically complete**, three new measurements:

1. **Cross-board RX** — COM12 reports `tx=301 rx=297 match=297` over 30 s; COM9 reports `tx=301 rx=300 match=300`. **98.7 % / 99.7 % RX rate** between the two boards, zero TX failures on either side.

2. **Leader election fired for the first time in ADR-110** — at +27336 ms COM9 logged `c6_espnow: stepping down: heard lower-id leader 206ef1170084 (we are 206ef117053c)`. Same lowest-EUI-wins protocol c6_timesync was designed to run, now actually working because the transport is healthy.

3. **Cross-board sync offset stable at ≈ −950 µs** — COM9 reports `offset_us` settling from `-1462 → -950 → -954 → -957 → -948` over the same 30 s. Jitter ≈ ±10 µs around the converged value once leader-following stabilizes. The ±100 µs target ADR-110 §2.4 named for the multistatic protocol is met across one hop (the value reflects FreeRTOS timer-tick quantisation plus WiFi MAC TX queueing — both characterisable).

**Meanwhile the raw 802.15.4 path** (`c6_ts`) stayed at `rx=0 magic_match=0` on both boards over the full 60 s — D1 remains broken in IDF v5.4 exactly as documented. ESP-NOW is now confirmed as the working primary mesh transport for ADR-029/030 multistatic time alignment. | ## A. Empirically verified (real silicon, today)