Jaguar2 8822BU TX does not air at level for ~4 s after its first submitted frame

[josephnef]

What was seen

A Jaguar2 RTL8822BU (TP-Link Archer T3U, 2357:012d) driven by txdemo at max duty (DEVOURER_TX_RATE=MCS1 DEVOURER_TX_GAP_US=0, ch165) does not air at level for ~4 s after its first submitted frame. Found while re-validating #437 on this bench: the Jaguar3 sensor's first armed busy window read a valid 0% on a channel that was 64% busy a second later.

Sensor first, flooder second (RTL8812CU sensor, 120 × 50 ms ArmChannelBusy windows, tests/busy_window_probe.cpp):

cycle	flooder's first bulk_send	sensor first non-zero window	gap
1	window #37	window #99 (11%, then 61-65%)	~62 windows ≈ 4.0 s
2	window #38	window #100 (56%, then 61-65%)	~62 windows ≈ 4.0 s

The complementary arm, flooder first: 5/5 sensor bring-ups launched 4 s after the flooder saw seven 50 ms windows at 0% before the load appeared; 5/5 with the flooder running >10 s were at 61-65% from the first window. 15 s of sensor idle before bring-up changes nothing. So it is the transmitter's onset, not the receiver's.

txdemo reports submitted frames from its first bulk_send, and the bulk-OUT calls return OK, so from the host's side the flooder is transmitting the whole time.

Why it matters

• Any harness that starts a Jaguar2 flooder and measures within ~5 s measures an idle channel and cannot tell. tests/busy_window_probe.sh now waits for it (measured value + margin, FLOOD_SETTLE_S), and the sensing doc carries the caveat; other loaded-channel harnesses that use a Jaguar2 flooder should be checked.
• On the link itself: the first ~4 s of a Jaguar2 TX session are, as far as a co-channel receiver is concerned, not at the level the rest of the session runs at. For a quick-connect FPV downlink that is the part of the session that matters most.

What is not known

• Whether it is power (weak), a wrong channel, or no radiation at all during the window — the sensor's CLM cannot tell those apart. An SDR read of the first 5 s would.
• What ends it at ~4 s. Candidates in the Jaguar2 bring-up: the thermal/pwr-track first tick, the DIG/EDCCA operating point settling, or something in the USB smart-switch sequence on this unit (the T3U boots USB2 and re-enumerates USB3).
• Whether the 8821CU and the CF-924AC (0bda:b812, external antennas) do the same — only the T3U was the flooder here.
• Whether the vendor rtl88x2bu driver shows the same onset. That A/B is the first thing to run before attributing it to the port.

Reproduce

Bench with a Jaguar3 sensor and the T3U on ch165, branch of #437:

sudo tests/busy_window_probe.sh   # with FLOOD_SETTLE_S=0 the first arm reads 0%

Or the sensor-first form: start BusyWindowProbe --vid 0x0bda --pid 0xc812 --channel 165 --mode window --window-ms 50 --reps 120, then txdemo on the T3U ~3 s later, and count windows between its first bulk_send and the sensor's first non-zero reading.

🤖 Generated with Claude Code