RTL8733B: SDR RF characterization + on-air throughput benchmark (blocked on BL-M8733BU2 arrival)

[josephnef]

The RTL8733B backend merged in #388 has no RF-domain measurement at all — the DUT bench had no SDR. Every RF claim in docs/rtl8733b.md is therefore a delivery/readback claim, and the README bandwidth cells for RTL8731BU are —. This issue closes that gap once a second module (BL-M8733BU2) is on the bench.

Everything here is hardware-gated: it cannot start before the board arrives.

Why it matters beyond bookkeeping

• AdapterCaps::narrowband_ok is false purely for want of an SDR (#TBD-narrowband depends on this issue). The 5/10 MHz register sequence already reads back on hardware; occupied-bandwidth proof is the missing evidence.
• The README table is the first thing an integrator reads. A — row next to benchmarked 8812EU/8852BU rows reads as "untested silicon" when what is actually missing is one instrument.
• A one-unit result is not a population (docs/rtl8733b.md, "Known gaps"). The second module makes every number below a two-sample claim.

Work items

1. Absolute output power, per band and per rate. 1/2/5.5/11 Mbps CCK and 6 Mbps OFDM on 2.4 GHz; 6 Mbps OFDM and HT MCS0/4/7 on both bands. The backend has no TX-power API surface beyond its safe TSSI target (kSafeTssiTargetQdbm8733b) — establish what that target actually radiates before anyone proposes raising it.
2. Occupied bandwidth + spectral mask at 20 and 40 MHz, both bands. This is the gate for the narrowband work and the sanity check on the 40 MHz centre-channel table.
3. EVM at the top of the ladder (MCS7/20, MCS7/40). Per docs/bench-testing-near-field.md, EVM — not SNR — is the saturation tell; take the near-field precautions.
4. On-air TX throughput via tests/bench_onair.py: Mbps = SDR duty × PHY rate, never monitor-sniffer frame counts (a sensitive receiver decodes weak frames and masks a real drop). Fill the README RTL8731BU row's 2.4 GHz / 5 GHz / 40 MHz cells.
5. TSSI target validation. Confirm the closed-loop target is met and stable across a bounded run, and that the safe cap is neither leaving margin on the table nor overdriving the PA.

Traps this specific chip has already demonstrated

• TSSI needs settling time, and a fast rate-switching run lies about power. Measured on the f72b DUT during rtl8733b: add RTL8731BU/RTL8733BU USB RX and TX #388: alternating CCK and OFDM at ~9 ms/frame leaves CCK airing ~5 dB above its settled level; the same stream paced to 86 ms/frame lands on the settled value. Any power or mask measurement taken during a mixed-rate stream is measuring the tracking loop, not the transmitter. Pace single-rate, let it settle, then measure.
• The CCK↔OFDM TSSI table switch costs 84 ms (rtl8733b: CCK<->OFDM TSSI table switch costs 84 ms (136 USB register ops) inside send_packet #389). Do not build a per-rate sweep that flips the table between every sample and then wonder why the numbers drift.
• One clean SDR read per session — a second back-to-back sdr_duty read can fail to reacquire and report ~0. Pin the B210 serial (the bench has two).
• Re-check a known-good control adapter each session before believing any absolute number.

Acceptance criteria

• README RTL8731BU (and RTL8733BU if the arriving board is that die) bandwidth cells populated from bench_onair.py, with the DUT model named as the other rows do.
• docs/rtl8733b.md "Known gaps" loses the "No SDR was available" bullet and gains the measured OBW / mask / EVM / power table — each favourable number paired with its adversarial counterpart (worst band, worst rate, near-field caveat), per the repo's docs convention.
• Every number reproducible from a script committed under tests/, not from a shell transcript.

Follow-up to #388. Related: #233.

[snokvist]

One extra deliverable worth folding into the heat-soak part of this, because it decides whether a knob lives or dies.

#396 makes the TSSI thermal table a once-per-channel-set choice (vendor behaviour) and leaves per-frame re-selection behind DEVOURER_TSSI_RATE_TABLE=1. The default is validated at room temperature — 1 Mbps CCK, 300/300 delivered on the OFDM table vs 299/300 on the CCK table, which is not a difference. That is expected from the table contents: the CCK and OFDM curves are identical in words 0-3 and 12-15 and differ only in words 4-11, the swing ramp away from the baseline. At a thermal delta near zero they agree by construction.

What is unmeasured is whether they diverge enough to matter when the part is actually hot — nobody has run this silicon at elevated thermal delta. That is precisely a heat-soak-plus-SDR question, so it belongs here rather than in its own issue.

The measurement that would settle it: hold a single CCK rate, soak until the RF 0x42 delta stops climbing, and compare absolute output power with the CCK table loaded versus the OFDM table loaded. If the gap is inside SDR noise, the honest outcome is to delete tssi_rate_table and keep the vendor behaviour unconditionally — the knob only earns its place if the hot case diverges. The declaration in src/DeviceConfig.h states that disposal condition explicitly so it does not quietly become permanent.

Two traps for the power runs in this issue, both measured rather than assumed:

• Pace single-rate, as you noted — a mixed-rate stream at ~9 ms/frame reads ~5 dB high on CCK and lands on the settled value at ~86 ms/frame. That is the loop converging, not the transmitter.
• Qualify the receiver before quoting delivery. Sweeping the RTL8812AU witness across the HT ladder gives MCS1/3/5 at 300/300 and MCS6 at 296/300, so it has margin to spare in this range — but the same session read MCS0 at 270/300 and MCS7 at 277/300 with 5-7 units less RSSI, which is per-run link variation and would be easy to misread as a transmitter effect.

[snokvist]

Update to my earlier comment: I ran the room-side half of the heat-soak question on the validation unit, and it produces a specific number for this issue to test against.

The two thermal-compensation curves are bit-identical until thermal delta +18. Reconstructing the plan against the vendor 64-entry layout, the swing ramp starts at index 18 and every word either side of the baseline is zero in both tables. Below +18 the CCK and OFDM tables are the same bits, so the table choice cannot affect output power at all.

The validation unit plateaus at +8. Five-minute max-duty MCS7 soak, DEVOURER_TX_GAP_US=0, thermal polled every 2 s:

raw 33 -> 40   delta +1 -> +8
33/1, 37/5, 38/6, 39/7, 39/7, 39/7, 40/8, 40/8, 40/8, 40/8, 40/8

Asymptotic — it stopped climbing after ~2 minutes and held +8 for the remaining three, rather than still rising when I stopped.

On that evidence the tssi_rate_table knob is deleted in #396: on this unit there is no reachable temperature at which it does anything.

What this issue can still settle, and why it is worth a line in the heat-soak plan:

• +8 is a property of this unit, not the silicon. Bare module, open air, room ambient, and submission-rate duty rather than measured radiated duty. A sealed BL-M8733BU2 at higher ambient is exactly the case that might reach +18 — that is the interesting measurement, and it is cheap to take while the board is already soaking for the RF work. If it stays under +18 there too, the question is closed for good and the vendor behaviour is simply correct.
• If it does reach +18, the per-rate table switch becomes real, and the implementation to revisit is the in-place rewrite validated in rtl8733b: CCK<->OFDM TSSI table switch costs 84 ms (136 USB register ops) inside send_packet #389 (13.8 ms / 20 ops, tracking left enabled) rather than the 84 ms teardown/rebuild that was just deleted.

The threshold is the durable half of this — it comes from the vendor table contents, so it applies to any RTL8733B. Only the reachable delta varies by board.