Airtime field notes from a 9-node ESP32-C6 fleet

[clonea1]

We run 9 ESP32-C6 nodes on one 2.4 GHz AP and channel, all sending CSI to one host. Most of our "the fleet gets slower over time" problems turned out to be about airtime, not code. These notes are generic so they should carry over to other setups. Fix PR: #2081.

1. Check the AP's per-client rate first. When a node's fps decays with uptime, look at the rate the AP receives that node at. Ours fell back to 802.11b, 1-2 Mbps (MEASURED, UniFi per-client rx_rate). One node at 1 Mbps takes roughly 11% of the channel (MODEL fitted to the AP's numbers). Blocking 11b on the STA cut channel busy from 80-85% (daily median, 8 days before) to about 44% the first day after, and fleet fps rose 26% (MEASURED). Over the following week the night-time median stayed at 42-46% on five of seven nights; the two bad nights (58-62%) were nodes stuck at a low rate after a slide, which a separate fix (the node re-associates when its uplink stays slow) has since removed (MEASURED, nightly reports).

2. A minimum rate on the AP is not enough. On UniFi, minrate_ng_enabled at 12 Mbps still leaves the 11b rates advertised unless minrate_ng_advertising_rates is also on (MEASURED via rest/wlanconf). A hidden or legacy BSS on the same radio can also keep 11b protection on.

3. Firmware cannot remove 11b entirely on the C6. esp_wifi_set_protocol(WIFI_IF_STA, 11G|11N|11AX) returns ESP_ERR_INVALID_ARG: the 2.4 GHz validator only accepts protocol sets that include 11B (MEASURED on IDF 5.4.0, 5.4.4 and 5.5.5, by disassembly and on hardware). esp_wifi_config_11b_rate(WIFI_IF_STA, true) does work, but only partly: we still saw RTS at 2 Mbps and retries at 5.5 Mbps in AP-side captures (MEASURED).

4. Heap dips behind a slow link are not a leak. With CONFIG_ESP_WIFI_DYNAMIC_TX_BUFFER_NUM=128, up to 128 TX buffers queue behind a 1 Mbps link. Free heap returns to its baseline; only the dips get deeper, and the min-heap watermark makes that look like a leak (MEASURED, on-node log).

5. Illuminator pings have a cost. A 50 Hz ping per node is about 1.8% of the channel per node (MODEL). Halving the rate cut how well the other nodes hear that node by about half or more, with no measurable benefit in return, so we went back to 50 Hz (MEASURED, one node, two nights; the airtime saving itself was too small to separate from night-to-night channel changes).

6. RTS is a trade, not a win. Turning RTS on helped some links and hurt others in our A/B; it did not improve the fleet overall (MEASURED).

7. Placement beats configuration. A weak node got far better when we moved it toward the AP, on both axes. Its rate problems were placement, not settings (MEASURED; numbers are house-specific, so not given here).

8. IDF version is not a fix by itself. One-node trials of IDF 5.4.4 and 5.5.5 against 5.4.0, and neither did better: on 5.4.4 the node stayed at 2 Mbps for hours after a slide that 5.4.0 nodes recover from in under an hour; on 5.5.5 the node wedged after about 37 h (still associated at the AP, but every send failing and the IP stack unresponsive, and no watchdog reset it). We stay on 5.4.0 (MEASURED, n = 1 node each, so treat these as anecdotes, not verdicts on those IDF versions).

Happy to share the scripts (per-client AP rate poller, nightly comparison report) if they are useful to anyone.