This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3235MODASF: Radiated electromagnetic field immunity test (RS) EN61000-4-3 FAIL

Part Number: CC3235MODASF
Other Parts Discussed in Thread: WL1835MOD, WL1831, LAUNCHXL-CC3235SF, UNIFLASH

Dear Sir/Madame,

I am hardware design engineer from China and I am involved in certification phase of our new device, which is using CC3235MODASF as the 2.4GHz&5GHz WiFi module works in STA mode.

Past week we have been performing Radiated electromagnetic filed immunity test (RS) according to test standard EN61000-4-3, criterion A in a certified facility. During the test the DUT is exposed to electromagnetic field of 3V/m from 80MHz until 6000MHz. We are monitoring CC3235 WiFi by pinging it once per second from PC(the PC connected to the access point through wired and PC located out of EMC chamber, the CC3235 connected to the AP wirelessly). The CC3235 operates as expected from 80MHz until 3000MHz. From 3.0GHz until 6.0GHz the ping messages always or frequently lost. When the Radiated disturbance is turned off, WiFi start to operate normally immediatly or after few seconds. However, this ping lost is only observed during 3.0GHz to 6.0GHz in 2.4G WiFi mode, for 5G WiFi mode, it works normally.

After searching on the TI E2E community, I find a very interesting topic in the Link: WL1831MOD: Radiated electromagnetic field immunity test (RS) EN61000-4-3 FAIL - Wi-Fi forum - Wi-Fi - TI E2E support forums

The problem they faced was quite similar with me. The main reason they worked out is: WiFi module stops replying ping messages because of too high noise floor level on WiFi frequencies. At the lab which they are performing test, the lab use one amplifier in 1GHz-3GHz region and another one from 3GHz and 6GHz. It turns out that noise floor level at 2.4GHz is 10dBm higher when second amplifier operates, compared to when first amplifier operates. Thus WL1831 does not work in the 3GHz to 6GHz region. After they lower BG2 RX loss in PerSubBandRxTraceLoss (the loss of the rx path) for 3dB, WL1831 started to transmit between 3GHz and 6GHz. Finally they identified that the WL1835MOD_C2PC.INI file they used in the test was not correct, which lead to this issue.

Could you please help to check whether there is same parameter in CC3235MODASF can be configured? Maybe we can modify this parameter to check whether Radiated Immunity performance can be improved.

On the other hand, please direct us how to check whether this parameter is correct in our design? So we can avoid failure with the same reason as them.

We have struggled on this problem for several months, hope you can provide fully support. Many thanks.

  • Hi Wenhai,

    Are you using the Radio Tool GUI to perform this test? If so, which version are you using? The latest is v1.0.3.19.

    Are you programming the device with the SLI image that is found in the Radio Tool CC3235MODASF directory?

    Did you request a design review here and get your board design reviewed by us?

    BR,

    Seong

  • Hi Seong,

    No, we are using CC3235 running our own application. We have tried to use the Radio Tool GUI to perform the test also, but it seems there is no information on how to setup the access point or get the CC3235 connected into a wireless environment in the application notes of Radio Tool GUI. Could you please provide a more detailed guide on how to have the certification RS test as CC3235MODASF module have done? So we can perform it in our side to identify the issue.

    The service pack we used is sp_4.13.0.2_3.7.0.1_3.1.0.26.

    For the board design, it was reviewed by TI already before we manufacture the board.

    BR.

  • Hi Wenhai,

    Let me look into this and get back to you by next week. 

    BR,

    Seong

  • Hi Seong,

    Thank you. Is there any update on this topic to help me move forward? So I can follow the guide to have the certification test which have been performed on CC3235MODASF. I have the evaluation board LAUNCHXL-CC3235SF RevA.

    On the other hand, whether there is a similar parameter in CC3235MODASF which equivalent to PerSubBandRxTraceLoss in WL1831?

    BR,

    Wenhai.

  • Hi Wenhai Liao,

    Test procedures for the CC3235MODASF's certification testing can be found in the test reports here, but I am currently checking to see if there is something more useful. I will share this as soon as I can.

    As for your second inquiry, see Section 6.8 in the Uniflash User's Guide, but I do not recommend changing anything in the Regulatory Domain tables in Uniflash's Advanced Settings.

    BR,

    Seong

  • Hi Seong,

    I have checked the test reports, but it don't have the detailed information about how to configure the evaluation board. In the test report, it describes that an WLAN AP ASUS, Notebook DELL and evaluation board were used, but we need to know how to configure the evaluation board to connect to the AP and Notebook, e.g. how to set the SSID and password to the board, how to set the IP address of the board... Without those information, we can not configure the wireless environment successfully, the evaluation board can not communication with Notebook wirelessly through AP, by using ping command. The document Radio Tool User Guide also not provide those information.

    For the Section 6.8 in the Uniflash User's Guide, I find the Back-Off Offset (BO) parameter to modify the RF trace loss, does this parameter both modify the RxTraceLoss and TxTraceLoss at the same time?

    BR,

    Wenhai.

  • Hi Seong,

    I'm wondering whether there have FAE who located in Shenzhen, China that can help us to investigate this issue in the field? It will be more efficiency.

    Thank you.

    BR,

    Wenhai.

  • Hi Wenhai,

    Please see here. This zip contains an SLI image that will program the SimpleLink device with the "network terminal" application. The instructions will guide you on how to use "network terminal" to connect to an AP and transmit infinite UDP packets. 

    Hope this helps,

    Seong

  • Hi Seong,

    It is clear to have the test according to your file. Yesterday, we have performed the test based on evaluation board LAUNCHXL-CC3235SF and on our own hardware platform, with the same SLI image. During the immunity test from 2.7GHz to 6.0GHz with 3V/m strength, the UDP communication works noramlly on evaluation board, however, when applied on our own board with CC3235MODASF, ping messages always or frequently lost from 3.0GHz to 6.0GHz.

    Thank you for your help.

    Wenhai.

  • Wenhai,

    Thanks for the update. I will look into this and get back to you as soon as I can. 

    BR,

    Seong

  • Hi Seong,

    We have re-test the evaluation board LAUNCHXL-CC3235SF RevA for Radiated immunity in 2.7GHz to 6.0GHz. We find that the evaluation board will be ping communication loss during 3.0G to 6.0GHz, especially in the position 90°(with short edge facing to the RF Antenna of the lab), it will be always communication loss. In position 0° (with long edge facing to the RF Antenna of the lab) it will be better, but the ping communication loss is also frequently observed.

    The software and test procedure are according to the zip file you provided. Please help to identify why this issue happens.

    The USB cable we used during the test is a shield USB cable with length 1.5m. We connect the LAUNCHXL-CC3235SF to the Notebook through the USB cable, the Notebook is powered by its internal battery.

  • We also use the USB cable which delivered with the evaluation board LAUNCHXL-CC3235SF to perform the Radiated immunity test, ping communication loss also can be observed frequently. Our Access point is Netgear nighthawk AX4. Please help to analysis it.

    Thank you very much.

    BR,

    Wenhai.

  • Wenhai,

    That is not good news. Okay, give me some time to work on this one.

    BR,

    Seong

  • Hi Seong,

    To help understand more clearly, I add more information here. Notebook trade - Lenovo,  Access point-Netgear nighthawk AX4, USB cable-delivered with the evaluation board LAUNCHXL-CC3235SF, setup-same as RS Setup Photograph present in the test report "EW832725_R01_EN301489_Texas_LAUNCHXL-CC3235SSF". Only 2.4G WiFi mode tested, due to we don't see issues during RS test of 5G WiFi mode in our product. RF Antenna in the lab polarity Horizon (with position 0°,90°,180°) and Vertical (with position 180°) are tested, always ping communication loss or frequently ping communication loss can be observed during 3.0GHz to 6.0GHz.

    The background is our product designed with CC3235MODASF is not works stable during the Radiated Immunity test 3.0GHz to 6.0GHz in 2.4G WiFi mode. Ping communication loss can be frequently observed. Sometimes it maybe stable without ping communication loss, but if re-test it again, this issue can be observed.

    Now we are blocked in this test, please help us on this. If you need more information from my side, please let me know. Thanks a lot.

    BR,

    Wenhai.

  • Wenhai,

    I would like to try generating a new network_terminal application specifically for the CC3235MODASF. We'll make adjustments to the power levels of each channel via UniFlash based on our CZ of the CC3235MODASF module. See section 6.8.1.1.1.1.1 in the SimpleLink UniFlash User's Guide here. I will need a couple of days to work with our SW apps team to generate this.

    BR,

    Seong

  • Wenhai,

    Please try the attached SLI image.

    nw-term-infinite-send_Programming.sli

    BR,

    Seong

  • Hi Seong,

    Thanks for the new SLI image. Actually, in the passed days, we have already adjust this parameter to +3db and -3db through Uniflash tool as you suggest, but it seems no significant improvement by this way. What modification have you made in this new SLI image? We will test it in these couple days and feedback to you the result.

    For the evaluation board LAUNCHXL-CC3235SF, do you have any idea about why this issue happened?

    BR,

    Wenhai.

  • Hi Seong,

    We have test the new SLI image you provided 2 days ago. We use 2*AA size battery to provide the power supply for WiFi chip CC3235MODASF (the WiFi chip is mounted on our board), but we get the same result as before: it is continuous or frequently communication loss during 3.0GHz to 6.0GHz in 2.4G WiFi mode. We test in Horizon with 3V/m strength.

    If you have any other suggestion, please let me know.

    BR,

    Wenhai.

  • Wenhai,

    Have you tried measuring the return loss of the antenna on your board? This may be worth trying after I reviewed your design the other day. 

    BR,

    Seong

  • Hi Seong,

    How to measure the return loss of the antenna? Should I cut off the Antenna on the module CC3235MODASF, and solder a pigtail to the antenna (not connect to the module), then using a network analyzer to do the return loss measurement? What acceptance criteria should be expected for this test? If you have any application notes for this test, it will be more easier to follow up. Thank you.

    BR,

    Wenhai

  • Hi Wenhai,

    Yes, if you can spare one or two modules, you can cut the RF trace right before the PCB antenna and solder a pigtail cable to measure S11 with a network analyzer. See Section 6.2.1 in the Antenna Selection appnote. Ensure that the network analyzer is calibrated and it is calibrated even further with the extension of the pigtail cable BEFORE soldering it on your module. 

    The following table shows the return loss measurements we made using this reference design.

    Anything higher than -6dB is considered bad return loss. Anything equal or lower than -10dB is considered optimal. 

    BR,

    Seong

  • Hi Seong,

    Thank you for the details of measurement. I will share the S11 return loss measurement result to you after we finished it.

    For this issue also happened on evaluation board LAUNCHXL-CC3235SF, do you have any suggestion?

    BR,

    Wenhai

  • Wenhai,

    I will respond to you via email.

    BR,

    Seong