Dwell-1 A/B injection: a two-context per-slot data plane (exp 4/5)

[josephnef]

Closes #272.

Fourth in the standard-driver FHSS series. #272 was premised on the MCC/FCS scheduler from #271, which #271 rejected — so this reframes onto the vehicle the series already validated (the ordinary channel switch) and answers #272's actual question: can firmware-grade channel time-slicing carry a real per-slot data plane with deterministic queue ownership? It can.

What it is

A new examples/dwelltx demo runs a two-context A/B schedule — one wall-clock slot per channel — and admits exactly one data-frame opportunity per slot ("dwell-1") inside a bounded window that guarantees the frame finishes airing before the slot flips. Past the deadline the frame is dropped with a structured reason, so a frame built for context A can never air on B. This bounded admission is pure caller policy; the library is unchanged.

Each per-slot frame carries a HopSyncMarker (src/HopSchedule.h) whose slot maps, through the shared schedule, to the channel that slot belongs to — so a fixed-channel oracle that decodes an out-of-context frame is a self-evident wrong-channel event, and attribution needs no cross-clock alignment. tests/dwell1_ab.py drives two oracles (A/B) with per-slot accounting, fault injection, and the switch-primitive comparison.

On-air results (RTL8822BU DUT, 8821AU + 8812CU oracles)

run	slots	delivered correct channel	wrong-channel	dup	late-drop
primary	5 020	97.2 %	0	0	0
reliability	100 013	96.2 %	0	0	7 (0.007 %)

• Zero wrong-channel and zero duplicates over 100 k slots; admit jitter p99−p1 = 132 µs. The ~4 % shortfall is first-decode/settle loss, not mis-delivery.
• Fault (late enqueue, 18 ms into a 20 ms slot): 511/516 dropped-late, zero mis-aired — overload is deterministic.
• Lockstep RX: a single receiver acquires the schedule from the markers (889 tracked decodes/12 s) and re-acquires from a cold restart (861), no persistent phase inversion.

Key finding — the two switch primitives have opposite sweet spots

Running the identical loop over the firmware switch (DEVOURER_FASTRETUNE_FW) inverts the dwell-1 schedule at 20 ms slots: in the sparse one-retune-per-slot pattern its fire-and-confirm-later RF completes far later than the ~1 ms it shows under continuous hopping (settle sweep: 3 % → 82 % delivery as settle goes 2 → 12 ms). The synchronous FastRetune — RF programmed by the time the call returns — places the frame deterministically with a ~2 ms settle and is the correct dwell-1 primitive. This composes with experiments 2–3 rather than contradicting them: firmware switch for throughput hopping, synchronous switch for deterministic slot placement.

Go/no-go: go — advance to experiment 5, using the synchronous switch for the slot data plane. Full note: docs/dwell1-ab-injection.md.

🤖 Generated with Claude Code