RTL8812CU (rtl8822c) RX marginal on 2.4 GHz channel 6

[josephnef]

Summary

The RTL8812CU (rtl8822c, 0bda:c812) receives poorly on 2.4 GHz channel 6 — RX frame delivery is intermittent-to-none — while 5 GHz reception is solid. This is pre-existing (present on master), not caused by any recent refactor.

Observed

Ambient RX capture via tests/bench_init.py (init → first RX frame), 2 reps per build:

build	c812 RX ch6	c812 RX ch36
master (f542b06)	0/2	—
refactor branch (#125)	1/2	400 frames captured

• On ch36 (5 GHz, rtl8822c's validated band) the same binary pulls hundreds of frames per run.
• On ch6 the chip initializes cleanly (monitor RX config applied, IQK completes) but delivers few or no frames, even with a strong local beacon injected on the same channel.
• Its Jaguar3 sibling rtl8822e (0bda:a81a), which shares the same FrameParserJaguar3 read/parse path, does capture on ch6 — so the gap is specific to the rtl8822c PHY/RF path on 2.4 GHz, not the shared RX plumbing.

Expected

Comparable RX sensitivity on 2.4 GHz to the other supported chips (8812AU / 8821AU capture ch6 ambient reliably in the same rig).

Repro

cmake -S . -B build && cmake --build build -j
sudo python3 tests/bench_init.py --pids c812 --channel 6 --skip-tx --reps 2
sudo python3 tests/bench_init.py --pids c812 --channel 36 --skip-tx --reps 2   # contrast

Suspected areas

• 2.4 GHz RF front-end / RFE pin config or LNA path for rtl8822c (the 5 GHz path is the one that was primarily brought up and validated).
• 2.4 GHz AGC / initial-gain or CCK RX config on rtl8822c.

Notes

Not a regression — surfaced while A/B-testing the src/jaguar1 split (#125), where master showed the same (worse) ch6 behavior. Filing so the 2.4 GHz rtl8822c RX path gets a proper look.

[josephnef]

Decisive: it's a devourer bring-up gap, not hardware

Put the same CU module into kernel (rtw88_8822cu) monitor mode on ch6 and flooded frames from an 8812AU:

CU monitor iface=wlp4s0u2u4 ch=6
kernel CU monitor frames captured : 200
  6.0 Mb/s 2437 MHz 11g  -24dBm signal  antenna 0 -24dBm  antenna 1 -36dBm

The kernel driver receives 200 frames on ch6 at −24 dBm on this exact hardware, so the 2.4 GHz antenna/front-end is fine. devourer's 8822c is near-deaf on ch6 (0 hits to the same strong local beacon that a81a heard 58× and that c812 hears 68× on ch36). → devourer's rtl8822c 2.4 GHz RX bring-up is missing/mis-setting something.

Note the antenna asymmetry on 2.4: antenna 0 = −24 dBm, antenna 1 = −36 dBm — path A is the strong 2.4 path on this module.

Next: usbmon A/B of the kernel vs devourer ch6 register-write sequence to pin the missing 2.4 GHz RX writes.

[josephnef]

Root cause is a multi-area 2.4 GHz RX bring-up gap (not a single block)

Did the full usbmon A/B — kernel rtw88_8822cu vs devourer, both taken to ch6, comparing the final value of every register. Key results below.

Method note (endianness)

usbmon's data= field is the little-endian byte serialization, so the true register value is the byte-reverse of the printed string. Verified against 0x810 (devourer writes field [13:4]=0x19b → value 0x11b019b0 → wire b019b011, identical to the kernel). Any capture-based comparison must byte-reverse first — I initially didn't, which sent me down a wrong path.

The gap

Of the registers the kernel touches bringing the CU to ch6, 83 end at a different value than devourer, and 22 the kernel writes devourer never touches at all. They cluster into several areas, all RX-relevant:

• RX-AGC gain tables — 0x18b0/0x18cc (kernel ea11fb89 vs 0a11fb89), 0x18bc/0x18d8, 0x18c0/0x18dc.
• IQK RX-CFIR engine — 0x1b04,0x1b08,0x1b10,0x1b1c,0x1b20,0x1b24,0x1b2c,0x1b44,0x1b5c,0x1b60,0x1b64,0x1bb8–0x1bf0 (e.g. kernel 0x1be4=77472f17 / 0x1be8=efbfa78f vs devourer 09050301 / 000009c4). devourer's 8822c IQK leaves the RX filter path in a different state.
• CCK RX — 0x1a04 (kernel 81000008 vs c1000008), plus the 0x1a14/0x1a20–0x1ab0 block devourer's channel-set omits.
• RX-path / band selects — 0x180c[31] (devourer sets it, kernel clears), 0x1c80, 0x1a80, 0x0454, 0x1e2c, 0x0820.
• MAC / RX-filter never written by devourer — 0x06c0/0x06c4/0x06c8, 0x0668, 0x0524, 0x1040, 0x0304, 0x042c, 0x01d0/0x01d4, 0x0030/0x0034 …

Status

I prototyped the missing BB channel-switch block (config_channel_8822c, C-variant-gated, with byte-corrected kernel values for 0x1830/0x4130 AFE, the 0x1a.. CCK block, 0x1d70 IGI, 0x18ac/0x41ac, 0x0454/0x1a80/0x1c80), but on its own it does not restore RX — the RX-AGC + IQK-CFIR differences remain. So this needs a vendor-source-guided port of the 8822c RX-AGC gain table + IQK RX path, not a one-off register block. Reverted the partial change (unvalidated, doesn't fix the symptom).

Full per-register diff (byte-corrected) saved for whoever picks this up next. Reproduce with the two captures: kernel unbind→bind + iw monitor ch6 under usbmon vs devourer WiFiDriverDemo on ch6 under usbmon, byte-reverse data=, diff final-value-per-address.