What has been shared so far is not sufficient evidence that BE19 fixes the problems people observed with BE14. A screenshot showing only RSSI does not validate range, stability, or RF quality.
-
RSSI without SNR/noise is meaningless High RSSI at short distance can still happen with a poor link (high retries, errors, MCS drops). The BE14 “range” reports look more like a noise / isolation / EMI issue than a simple “TX power” issue. Without SNR / noise floor (or at least serious proxies like retries/failed under load), no conclusion can be drawn.
-
Publish the minimum reproducible metrics (required) If you want the community to validate “BE19 fixes BE14”, you must provide at least:
Exact distance + obstacles (LOS / 1 wall / 2 walls; wall material: brick/concrete/drywall, etc.) Channel + bandwidth + TX power + regulatory domain/country (especially for 6 GHz) RSSI and SNR (or noise floor + RSSI) Actual PHY: Tx/Rx rates, MCS, NSS, EHT/HE mode, GI, retries, failed, packet error / loss Real throughput (iperf3 TCP and UDP) at 1 m / 5 m / 10 m / 1 wall / 2 walls Stability over time (30–60 min sustained load), temperature, and whether shielding/heatsink is installed Without these, results are anecdotal and not comparable.
- If you claim “6 GHz / 320 MHz”, why does it show AX instead of BE/EHT? That is a red flag. 6 GHz + 320 MHz is Wi‑Fi 7 (802.11be / EHT) territory. If the UI reports AX:
the client may not support EHT 320, EHT may not be enabled in driver/firmware/hostapd, the UI may be reporting incorrectly, or the test is not actually running at 320. Please clarify precisely:
whether EHT is enabled on the AP (driver + hostapd configuration), which client is used and whether it supports EHT 320 on 6 GHz, exact driver/firmware versions and the build tree used. 4) No “marketing screenshots”: we need repeatable results If there is no distance-based measurement table + the exact settings/logs/commands needed to reproduce it, then it is not evidence.
