Hello,
We are using the 88W9098 in a u-blox M2-JODY-W377 over SDIO running at SDR50. We have driver/firmware versions lf-6.18.20_2.0.0 from github. We are using it as an Access Point in 2.4ghz channel 6.
We are encountering an issue where enabling ed_mac (with "init_hostcmd_cfg=nxp/ed_mac.bin" in wifi_mod_para.conf, or using mlanutl with ed_mac_ctrl_V3_909x.conf) leads to much worse stability/latency of our in-house applicative tests :
I can't go too much into detail about the test here, but it is end-to-end latency measurement of specific in-house steps, using multiple machines with a 88W9098 Access Point in the middle. Not only are some curves 200-250ms higher in average with ed_mac than without, but overall they are also more spiky and tend to have random "bursts" of added latency.
We have tried tuning the offsets "ed_ctrl_2g.offset" and "ed_ctrl_5g.offset" to values different than the default 0x8, but no value that we tried had any effect on the test. The only way to have an impact is to set both enable (2g/5g) to 0, or to not load the file at boot.
Is there anything else we can try?
Dear @mjourdan ,
Thank you for the detailed description and test data. The behavior you are seeing is actually expected given how the ed_mac (Energy Detect MAC) feature is designed, but there are several things worth checking and clarifying.
Why ed_mac causes higher latency in AP mode
The ed_mac feature is designed specifically for the EU ETSI EN 300 328 adaptivity compliance test. Its core mechanism is to actively suppress transmissions when the firmware detects energy on the channel above a threshold. In an Access Point scenario, this directly delays buffered downlink packets whenever the radio detects ambient energy, resulting in the latency spikes and "bursts" you are measuring. Adjusting the offset parameter changes the threshold sensitivity (how easily the radio is triggered), but it does not remove the suppression behavior itself — which is why no offset value had any measurable effect on your end-to-end latency test.
Configuration file mismatch
I notice you are using ed_mac_ctrl_V3_909x.conf. According to our application note AN13756, the correct configuration file for 88W9098 is ed_mac_ctrl_V2_909x.conf (with default ed_ctrl_2g.offset = 0x08 and ed_ctrl_5g.offset = 0x08). The V3 variant uses a different ed_ctrl_txq_lock field value and is not the validated configuration for this device. Please try using ed_mac_ctrl_V2_909x.conf and test whether the latency impact improves.
Key question: Is EU adaptivity compliance required for your deployment?
The ETSI EN 300 328 adaptivity requirement only applies to devices operating in EU/EEA markets and with a declared maximum RF output power of 10 dBm EIRP or above. Could you confirm:
- Is this device deployed in the EU and subject to ETSI EN 300 328 certification?
- What is the declared RF output power of your module (u-blox M2-JODY-W377)?
If EU compliance is not required for your use case, the correct solution is simply to not load the ed_mac configuration — which you have already confirmed resolves the latency issue completely.
If compliance is required, we recommend switching to ed_mac_ctrl_V2_909x.conf first, and if the latency issue persists, we can explore whether there is a newer firmware version that may improve the AP-mode behavior.
Please let us know the answers to the above and we will follow up accordingly.
Best Regards,
Weidong
Thanks weidong. Yes the product definitely outputs more than 10dBm EIRP and needs to be EN 300 328 compliant.
I have tried with ed_mac_ctrl_V2_909x.conf (https://github.com/u-blox/u-blox-sho-host-based/blob/main/JODY-W3/txpower_config/ed_mac_ctrl_V2_909x...) but there was no change in behavior.
What we don't understand is that if we swap the module with one from DoodleLabs (QCA988X based) and perform the same test in the same environment, it also honors EN 300 328 but we have zero latency issues with it. So I am wondering why the 88W9098's implementation of ed_mac specifically would trigger such issues but not one from another chip maker.
Besides version lf-6.18.20_2.0.0, we have also tried hotfix/lf-6.12.49_2.2.0_hotfix but the issue is still present.
Some more information:
* There are 2 stations associated to the JODY's access point.
* The bandwidth used during the test between a station and the JODY is very low (~6KiB/s) but consists of many small packets, mostly in STA->AP direction.
Dear @mjourdan ,
I have escalated your issue to our internal team. Let's wait for the expert's response together — I will share any updates with you as soon as I have them.
Best regards,
Weidong
Dear @mjourdan ,
Internal team is analyzing the issue, could you please provide the following information? I got the following feedback from internal team.
======================================================
- Driver loading parameters, along with the complete driver load/unload command sequence used to reproduce the issue.
- ed_mac_ctrl_V2_909x.conf configuration file.
- Logs captured while reproducing the issue for further investigation.
- Host details, including:
- Host platform
- Kernel version
- Driver version
- Interface being used (PCIe/SDIO)
These details will help us correlate the customer's setup with our internal testing and expedite the analysis.
======================================================
Thanks,
Best Regards,
Weidong
Hi weidong, I am currently troubleshooting the issue with u-blox so in order to prevent a collision in case it also gets escalated to NXP, I will be seeing with them only for now. Thank you for your help.
Dear @mjourdan ,
Any update?
Thanks!
Regards,
Weidong
Dear @mjourdan ,
OK, got it.
Thanks for your update.
Best Regards,
Weidong
Dear @mjourdan ,
We verified the issue on the QA setup using release SD9098---17.92.1.p149.159-MM6X17552.p22 (FP92), and the issue was not reproducible.
The observed ping latency was around 1 to 2 seconds.
Test Steps:
- Loaded the build and enabled EDMAC using the default ed_mac_ctrl_V2_909x.conf available in the release config folder.
- Brought up APUT in CH6.
- Connected two Ex-STAs.
- Performed ping tests from the Ex-STAs to the APUT.
Scenarios Tested:
- auto_ds=1, ps_mode=1
- auto_ds=2, ps_mode=2
- APUT configured with HT20 and HT40
- Security modes: OPEN and WPA3
- Ex-STA power save: Enabled and Disabled
To help us analyze and reproduce the customer-observed issue, could you also please provide:
- Load file/build details used by the customer
- Complete configuration and test environment details
- Noise/interference level observed in the customer setup
- Relevant logs from the customer side
Once we have this information, we can perform a deeper analysis and attempt to reproduce the issue.
================================================
Thanks.
Best Regards,
Weidong