We are an engineering company developing a commercial Wi-Fi HaLow product on the MM8108, now
in pre-production / design-validation. Before we lock the design we want to resolve a power
and link-performance gap — and do it the supported way (within FCC/ETSI and your
BCF/regulatory framework). We’d rather invest in the correct calibration path with you than
work around anything.
Setup
Quectel FGH200M (MM8108), USB, on SigmaStar SSC338Q / OpenIPC, Linux 4.9.
Conducted output sits ~3–4 dB below both the reported value and the ~24.75 dBm BCF ceiling,
widening with bandwidth. We confirmed tx_max_power_mbm is not the limiter on 1.17 (driver sets
the cap to the chip’s queried max; 2200 vs 2600 makes no difference) — so a second limiter
(regulatory back-off, per-MCS EVM back-off, or PA/FEM headroom) is binding.
Why this matters — comparison at equal TX power
On the same bench/attenuator we benchmarked against another HaLow SoC (Taixin TXW8301). At an
identical 21 dBm conducted, it delivered ~2× the usable range and visibly smoother video. TX
power was equalized, so the difference lies elsewhere. We want to close this gap on the MM8108
before committing to production volumes.
Questions
Reported vs radiated: Is 24 dBm a reported ceiling, with real conducted reduced by
per-MCS/EVM back-off? Expected conducted at 2 MHz (and per MCS)? What accounts for the ~3–4 dB
below BCF?
PA/FEM supply (3.3 V vs 4.3 V): Our module runs at 3.3 V; several of your reference BCFs
ship as VFEM = 4.3 V variants. Is our shortfall related to PA/FEM supply voltage — would a
higher VFEM / 4.3 V-calibrated BCF raise output? Recommended supply for rated power?
Official power-calibration path: Supported process to reach rated output — board/BCF
calibration via your tools, a different BCF, or DVT firmware? Happy to engage via support /
under NDA — we just want the in-spec route.
Range at equal power: What would drive a ~2× range gap vs another SoC at identical 21 dBm —
RX sensitivity, ERP, EVM, link adaptation? Recommended measurements?
Video smoothness (jitter), not throughput: Priority is low-latency, low-jitter video, which
we suspect depends on rate control and TWT more than bitrate. Recommended rate-control / TWT
/ power-save / A-MPDU / TX-lifetime settings? Can the rate controller be biased toward
latency/consistency over peak throughput?
We can provide analyzer screenshots, full hostapd_s1g.conf, morse_cli channel -a / stats
dumps, and methodology. As we’re finalizing a production design on your silicon, timely
guidance directly affects our platform decision.
As you’ve mentioned, 24 dBm is the maximum the module can transmit. Your suspicion is correct in that this power must be backed off to meet EVM and SEM limits laid out by the 802.11ah standard. It is backed off for rate (BPSK/MCS0 allowing the maximum, 256-QAM/MCS9 backed off the furthest), and bandwidth, with higher bandwidth configurations backed off further than lower bandwidth. Unfortunately there is no mechanism for us to report the power for a (potentially) dynamically changing MCS back to iw, so you are seeing the maximum available power for the configured bandwidth.
Also don’t forget insertion losses.
Taixin is no different in this respect, in that their power is also reduced for different MCS.
These are for our MM6108 modules. There is no VFEM for the MM8108 modules currently available on the market as the PA is built into the chip.
We have recently announced our MM8108-M20 module reference design, which is being picked up by module vendors. It will take some time before these high power reference designs are available for customers.
It is best to work with your module vendor on improving your performance. But noting the above, make sure you are measuring at MCS0 - if the link has changed rate you will see back offs to meet the EVM and SEM limits laid out by 802.11ah + manufacturing yields.
What rate? What bandwidth? It’s hard to say exactly without having all the measurements for every rate and bandwidth configuration.
It’s possible there is some rate control dynamics distinguishing the two as well, have you performed any rate vs range measurements for the two modules?
If the device is static, the selected rate is not going to change unless there is an active interferer. TWT is also off by default and unlikely to improve your latency.
You’re more likely to be suffering from latency issues due to Linux network stack configuration parameters. We default to pfifo for the queuing discipline in our evaluation kits, though this may not be the best choice for low latency applications. If you’re using fq_codel you will want to look at increasing the target and interval parameters to accommodate the propagation delays of our sub 30Mbps links. Alternatively, you could look at SQM scripts to tune things. See https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel/ for example.
