Jaguar3 RX: parse jgr3 phy-status (#152) + fix 8822e 2.4 GHz RXBB

[josephnef]

Closes #152.

Two related Jaguar3 RX-correctness fixes, found together while validating per-frame signal metrics on hardware.

1. phy-status parse (#152)

The Jaguar3 RX path decoded rate/CRC but never parsed the PHY-status trailer, so RxAtrib.rssi/snr/evm stayed 0 on 8812CU/8822CU/8812EU/8822EU — while Jaguar1 and Jaguar2 already surface these. monitor_rx_cfg already enabled APP_PHYSTS + RX_DRVINFO_SZ=4, and parse_rx_8822c already skipped the 32-byte drvinfo; nothing decoded it.

8822C/8822E use the phydm jgr3 phy-status format (types 0-6 — matching the issue's "Type 0/1/2/3"). Verified against reference/rtl88x2{c,e}u/hal/phydm/phydm_phystatus.{h,c} that jgr3 type1's byte layout is identical to jgr2 type1 for the surfaced fields (per-path pwdb[4]@1-4, l/ht_rxsc@5, flags@7, s(8,1) rxevm[4]@16-19, rxsnr[4]@24-27), with vendor conversions pwdb-110 / snr>>1. Added parse_phy_sts_jgr3 (dispatches on page_num: CCK type0 vs OFDM type1), called in the RX loop gated on !C2H && drvinfo_size>=28 — mirroring the Jaguar2 call site. Stores raw phy-status bytes (Jaguar1/Jaguar2 convention).

Hardware-validated on 8822CU (ch6, 8812AU MCS1 beacon): 71 canonical-SA hits with plausible metrics — rate=13, rssi=73,57, snr=43,25, evm=-43,-128 (the -128 is the 1SS no-second-stream sentinel).

2. 8822e 2.4 GHz RXBB fix

Found while validating the EU: devourer's 8822e 20 MHz path set the RX baseband bandwidth via RF 0x3f=0x18 — an 8822c-only register — and left RF 0x1a unset (only written in the 40/80 branch). On the 8822e the RXBB/TXBB bandwidth lives in RF 0x1a[14:10] (config_phydm_switch_bandwidth_8822e: rf_reg1a &= ~0x7c00; 20M |= BIT11|BIT10). Kernel 2G ground truth (reference OpenHD rtl88x2eu driver via /proc .../read_reg): RF 0x1a=0xc00, RF 0x3f=0x2. Fixed to set RF 0x1a for every bandwidth and drop the bogus RF 0x3f. 5 GHz RX verified no-regression.

Also ported the EU's missing 2G config that the shared 8822c path skipped for the 8822e, register-verified against the kernel: 2G AGC-table selection (phydm_set_agc_table_8822e indices — 0x18ac now 0x8200, matching the kernel exactly), force-update-anapar (phydm_rstb_3wire_8822e, the #138 mechanism the BB-direct-window RF writes need), and CCK-RxIQ (identical across variants). The CU (8822c) path is byte-identical.

Caveat: on-air 2.4 GHz RX could not be demonstrated end-to-end — this specific 8822EU bench unit's 2.4 GHz receiver is hardware-dead (the reference OpenHD kernel driver is equally deaf on 2.4 GHz while both drivers work on 5 GHz). The 8822e changes are register-validated against the working kernel driver, not on-air.

Tests

• tests/validate_jaguar3_physts.sh — CU+EU phy-status on-air validation (8812AU beacon → Jaguar3 RX, asserts non-zero rssi/snr).
• tests/eu_kernel_2g_groundtruth.sh — loads the reference kernel driver to rule 2.4 GHz RX hardware in/out.

Build clean across the tree; ctest 100%.

🤖 Generated with Claude Code