RTL8814AU: 5 GHz TX power drastically under-driven (~1.5 Mbps vs kernel ~58 Mbps)

[josephnef]

Summary

devourer drives the RTL8814AU's 5 GHz TX at far too low power. On-air throughput is ~1.5 Mbps where the in-tree rtw88_8814au kernel driver gets ~58 Mbps from the same dongle on the same channel. The chip's PA is healthy — devourer computes the 8814's per-rate 5 GHz TXAGC power index far too low.

This is distinct from the USB Vbus-sag / power-delivery effect seen on the 8812/8821 under load — this one reproduces on a fresh rail and is a TX-power calculation bug.

Evidence

Measured with a USRP B210 (tests/sdr_duty.py, channel-occupancy → on-air Mbps), ch36 / 5180 MHz, HT MCS7 / 20 MHz, 1500 B payload, identical conditions:

Driver / mode	duty	on-air
devourer (normal power calc)	1.9–2.2 %	1.2–1.5 Mbps
kernel rtw88_8814au (inject)	89.8 %	58.4 Mbps
devourer + DEVOURER_TX_PWR_START=63 (force max TXAGC index)	70.9 %	46.1 Mbps

Forcing the TXAGC index to max rescues devourer to ~46 Mbps (≈ the kernel's 58). So:

• The PA / RF hardware is fine (kernel drives it to 58 Mbps; forced-max devourer hits 46).
• devourer's normal per-rate 5 GHz TX-power index for the 8814 is drastically too low.

A monitor sniffer decodes devourer's frames fine (sensitive receiver), which is why a frame-count metric hides this — the energy/throughput metric is what exposes it.

Likely location

PHY_SetTxPowerIndex_8814A / PHY_SetTxPowerLevel8814 in src/RadioManagementModule.cpp (~L1836–2011) — the 8814 5 GHz EFUSE power-by-rate / per-Ntx diff computation. Relevant prior commits: f3b8c8c (5G EFUSE PG diff-block layout), b3929ef (per-Ntx TX-power diffs cumulative over rate ranges), c9394a4 (drop 8812 TX-power-training for 8814).

Also check

• 2.4 GHz: the 8814 is also weak there (~20 Mbps vs 8812's ~52). May be the same under-drive on both bands.
• Compare the actual TXAGC index devourer programs per rate against the kernel's PHY_GetTxPowerIndex_8814A for a 5 GHz channel — the diff should pinpoint the bad term (base power vs per-Ntx diff vs PG-block layout).

Reproduce

# devourer (weak):
sudo env DEVOURER_PID=0x8813 DEVOURER_CHANNEL=36 DEVOURER_TX_HT_MCS=1 \
  DEVOURER_TX_MCS=7 DEVOURER_TX_GAP_US=0 ./build/WiFiDriverTxDemo
sudo python3 tests/sdr_duty.py --freq 5180e6 --secs 3 --mcs 7 --bw 20 --noise-db -62
#   -> ~2% duty, ~1.5 Mbps

# force max TXAGC index (rescues it):
sudo env DEVOURER_PID=0x8813 DEVOURER_CHANNEL=36 DEVOURER_TX_HT_MCS=1 \
  DEVOURER_TX_MCS=7 DEVOURER_TX_GAP_US=0 DEVOURER_TX_PWR_START=63 ./build/WiFiDriverTxDemo
#   -> ~71% duty, ~46 Mbps

# kernel control (reg US so 5 GHz TX isn't regulatory-blocked):
sudo iw reg set US
# rtw88_8814au monitor on ch36, inject_beacon --max-rate --mcs 7 --size 1500
#   -> ~90% duty, ~58 Mbps

Hardware: RTL8814AU 0bda:8813 (COMFAST CF-938AC), USRP B210 2500:0020, host kernel 6.18.

[josephnef]

Smoking gun — the computed TXAGC index is the problem. Instrumented PHY_SetTxPowerIndexByRateArray to print the per-rate index devourer programs (via EepromManager::GetTxPowerIndexBase), ch36 / MCS7 / 20 MHz / path 0:

Adapter	computed TXAGC index @ ch36 MCS7	on-air
RTL8814AU (0bda:8813)	14	~1.5 Mbps
RTL8821AU (2357:0120)	26	~32 Mbps
8814 forced DEVOURER_TX_PWR_START=63	63	~46 Mbps
kernel rtw88_8814au	(n/a)	~58 Mbps

So devourer derives index 14 for the 8814 at 5 GHz where it needs ~40+. loaded=1 (EFUSE TX-power info loaded), override=-1 (no override) — so this is the genuine EFUSE-derived value, not a fallback.

Localized to: EepromManager::GetTxPowerIndexBase → Index5G_BW40_Base[path][ch_idx] (+ OFDM_5G_Diff / BW20_5G_Diff). The 5 GHz base array for the 8814 is the prime suspect (read too low), or a 5 GHz diff term. Next step: dump devourer's Index5G_BW40_Base[0][ch36_idx] vs the kernel's PHY_GetTxPowerIndexBase/EFUSE PG value for the same channel — the delta pinpoints whether it's the base, the per-Ntx diff, or the PG-block offset (cf. f3b8c8c).

[josephnef]

Root cause found: blank EFUSE + missing default-PG-map fallback

Dumped the raw PG TX-power EFUSE region on the 8814 (0bda:8813, COMFAST CF-938AC), pg_txpwr_saddr = 0x10:

0x08: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x18: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x28: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
... (all 0xFF through 0x60)

The 8814's entire PG TX-power block is unprogrammed (all 0xFF). This dongle ships with no per-rate TX-power calibration burned in.

The kernel handles this; devourer doesn't:

• Kernel (hal_com_phycfg.c): IS_PG_TXPWR_BASE_INVALID(base) = (base > 63). It pre-fills the power table from a per-chip default map (rtl8814a_pg_txpwr_def_info, at offset 0x10) and only overwrites entries where the EFUSE byte is valid (≤63). With an all-0xFF EFUSE, every entry stays at the sane default.
• The 8814 default-map base values are 0x2D (45) for 2.4 GHz and 0x2A (42) for 5 GHz.
• devourer's EepromManager::LoadTxPowerInfo reads the raw EFUSE with no default-map fallback, so blank 0xFF bytes yield a garbage/under-driven base. Net result: computed index 14 instead of ~42 → ~1.5 Mbps instead of ~46–58.

This also explains the 8814's weakness on 2.4 GHz (~20 Mbps): the whole PG block is blank, so the 2.4 GHz base is wrong too (should default to 0x2D=45).

The 8812 and 8821 are unaffected because their EFUSEs are programmed with valid bases (e.g. 8821 reads index 26 directly).

Fix

Port the kernel's default-PG-map fallback into LoadTxPowerInfo: when a PG base/diff byte is invalid (0xFF / > 63), substitute the corresponding byte from the per-chip default map (rtl8814a_pg_txpwr_def_info / rtl8812a_pg_txpwr_def_info / rtl8821a_pg_txpwr_def_info). Simplest faithful approach: pre-fill a 168-byte PG buffer from the chip's default map, then overlay valid EFUSE bytes, then parse — exactly as upstream does.

Quick validation that the value is right: DEVOURER_TX_PWR_START=42 (≈ the default base) on the 8814 at ch36 should reproduce ~kernel-level on-air throughput; index 63 already gives ~46 Mbps.

[josephnef]

Fix implemented + hardware-validated

Ported the kernel's default-PG-map fallback into EepromManager::LoadTxPowerInfo (gated to the 8814): embed rtl8814a_pg_txpwr_def_info (168 bytes), and when an EFUSE PG byte reads 0xFF (unprogrammed) substitute the default-map byte. The 8812/8821 paths are byte-for-byte unchanged.

SDR-measured on-air throughput (USRP B210, MCS7/20 MHz, GAP=400µs), before vs after:

	before	after
8814 2.4 GHz (ch6)	~20 Mbps	65 Mbps (saturated)
8814 5 GHz (ch36)	1.2 Mbps	32 Mbps
8821 5 GHz (regression check)	32 Mbps	32 Mbps (unchanged)

The 8814's computed 5 GHz TXAGC index goes from 14 → 42 (= the default-map base 0x2A), matching the ~46–58 Mbps the chip is capable of. Fixes the 8814 on both bands and confirms the blank EFUSE was the sole cause. Patch is local (not yet a PR).

[josephnef]

Correction — retracting the "blank EFUSE / default-map fix"

My earlier "EFUSE all 0xFF → default-map fix → 32 Mbps" was wrong, and I'm retracting it. Root cause of my error: LoadTxPowerInfo runs twice per session and the two reads disagree — dumping efuse_eeprom_data[0x10..0x40] on each:

read A (real):  1f 1f 1f 1f 1f 1f 23 23 23 23 23 00 ee ee ee ee ee ee  0c 0b 0a 0d 1b 1d 1f 22 25 24 23 23 23 23 ...
read B (spurious): ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ...

So the EFUSE is programmed, not blank. My default-map fallback only fired on the spurious all-0xFF read B, which is the only reason I once saw idx=42/32 Mbps. The genuine value (read A) gives idx=14 consistently → ~1.5 Mbps. The default-map patch is reverted.

Two real issues remain:

1. 5 GHz base parse looks misaligned for the 8814. Read A's 2.4G section parses cleanly (1f×6 CCK, 23×5 BW40, then Ntx diffs), but devourer then reads the 5 GHz BW40 base as 0c 0b 0a 0d 1b 1d 1f 22 25 24 23 23 23 23. The leading 0c 0b 0a 0d (10–13) look out of place; the sane smooth 5 GHz curve (1b 1d 1f 22 25 24 23… = 27–37) starts ~4 bytes later. Strongly suggests the 8814's per-path 2.4G PG block is ~4 bytes longer than the 8812 layout devourer assumes (18 B), shifting the 5 GHz base read early → ch36 picks up 0x0c=12 → idx 14. Needs the 8814 kernel hal_load_pg_txpwr_info_path_{2,5}g byte layout to confirm the correct section size.
2. The second LoadTxPowerInfo read returns all 0xFF — separate bug worth understanding (why does the EFUSE re-read fail/zero on the 2nd call?).

Net: the 8814 5 GHz under-drive is real, but the fix is not a default-map fallback — it's most likely correcting the 8814 5 GHz-base PG offset. Reopening for that.

[josephnef]

Likely misdiagnosis — the "under-drive" is the Vbus-sag wedge, not EFUSE

Measured the 8814 per-channel with the stock binary (no patch, genuine EFUSE idx=14 for ch36):

ch	duty	on-air
36 (UNII-1)	48.8 %	31.7 Mbps
149 (UNII-3)	0.0 %	0.0
100 (UNII-2)	0.0 %	0.0

ch36 hit 31.7 Mbps at idx=14 — same as the 8821 — yet minutes earlier the same ch36/idx=14 read 1.5 Mbps, and ch149/ch100 (which earlier decoded ~900 frames) now read 0. The readings are not reproducible: they track the intermittent USB Vbus-sag wedge on the 8814's deep bus-powered hub branch (the same bench issue that hits the 8821/8812 — all three go dark at once when the rail sags).

Conclusion: idx=14 is adequate (48.8 % duty = frames well above the noise floor). The "~1.5 Mbps under-drive" earlier was the wedge throttling PA output, not the EFUSE index being wrong. The kernel-58 vs devourer-1.5 and forced-idx63→46 comparisons were taken while devourer happened to be in the wedged state, so they don't isolate an EFUSE problem.

Retracting the EFUSE-bug framing (and the earlier default-map / parse-misalignment hypotheses). The EFUSE parse appears correct (MAX_CHNL_GROUP_5G=14, pg_txgi_diff_factor=1, per-path 18+24=42 B all match the aircrack-ng/rtl8814au reference; the 5G base curve maps low→high by channel as expected, with low UNII-1 plausibly per regulatory).

This issue should be re-validated on a powered USB hub / direct root port (stable rail) before treating it as a code bug. On a stable rail I'd expect the 8814 5 GHz to behave like the 8821 (~32 Mbps) at the stock index. I cannot fully exclude a minor residual power-index effect from this sagging bench, but the dominant variable is clearly the USB power.