WL1835MOD: WL1835MOD — SRRC Certification & MIIT 2021 No. 129 Adaptive Interference Avoidance Support

Hi Michael,

Thanks for reaching out. 

Michael Magny said:

1. SRRC certification status: We are aware from a prior E2E thread (WL1837MOD, thread #1278121) that TI "cannot confirm whether or not WL1837MOD is compliant with SRRC certification because TI has not done the certification process". Is this still actual? Is there any new development or planned timeline?

We do not have plans to certify WL18xxMOD with SRRC certification

Michael Magny said:

2. Firmware-level DAA/LBT capability: Does the WL1835 firmware (wl18xx-fw-4.bin) implement any Listen Before Talk (LBT) or Detect And Avoid (DAA) mechanism autonomously, or is interference avoidance entirely delegated to the host stack (mac80211 / wpa_supplicant)?

Our device does implement CCA threshold mechanism in the FW so it is not dependent 100% on host stack.

A few more questions on my side:

- are you using the latest FW and latest INI file (WL1835MOD_INI_C2PC)?

- What are your results? By what margin are you failing? 

- What is the power level of the interferer? Can you continue to raise the power until our CCA threshold is triggered? Perhaps there is an issue with trace loss which isn't compensated correctly. Make sure you have defined the path loss based on the custom board in the INI correctly (PerSubBandTxTraceLoss and PerSubBandRxTraceLoss).

Best,

Josh

Hi Josh,

Thank you for answer. Here is our current status on each point.

1. Firmware and .ini

We confirmed we are not running the latest firmware. Our units are currently on 8.9.0.0.85 and we are working to update to 8.9.0.0.90. We also identified that our current build does not have a regulatory database enabled. As soon as the update is validated and database enabled, we will retest at the lab and report back.

We’ll also validate that we are using latest .ini. However, I can confirm that we are using default PerSubBandTxTraceLoss and PerSubBandRxTraceLoss. Is TI provided guidance on how to calculate / measure this parameter?

 2. Trace loss / interferer power level

We followed up with the lab on the interferer power level. They clarified that the interferer power will depend on the equivalent total radiated power measured by our device own measured TX power. It means that before doing this test, the lab would do the TX power test using another device sample and get the power level parameter, then would set this parameter into the interfere device.

They also confirmed they can raise the interferer power further if the current level is not sufficient to trigger our device to stop transmitting, so that avenue remains open after the firmware update.

 3. Link instability

The lab also flagged that our device shows unstable upstream and downstream throughput even during the basic stream test, before the interference avoidance test is run (confirmed on two devices). They suggest fix this before anything else…

We do not yet have a clear explanation for this instability. We are hoping the 8.9.0.0.90 update & regulatory database resolves or improves this. Are there known link stability issues in 8.9.0.0.85 that are addressed later?

As soon as we have new results with the updated devices, I'll keep you posted. Meanwhile, if those new informations are helpfull and bring you new ideas, let me know.

Hi Michael,

It is always good to use the latest FW to ensure the historical bug fixes are implemented. This could be a cause for your Link Instability.

To measure your trace loss, the exact way would be to use a VNA and measure from the RF pin of WL18xxMOD to your antenna port. That way you can know roughly the exact loss across the trace from RF pad to antenna.

I will look forward to updated results with latest FW.

Josh