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.

CC3100MOD: High Channel Utilization with Multiple CC3100MOD Connected to AP

Part Number: CC3100MOD
Other Parts Discussed in Thread: CC3100,

Hi team,

 A customer is using CC3100MOD with the tcp_socket example, connecting multiple CC3100MOD to an H3C AP. As the number of station(CC3100MOD) increased, they found that the channel utilization of the AP increased significantly, leads to throughput decrease/dataloss eventually.

Below is the channel utilization diagram of the AP with 30 CC3100MODs connected. You can see ctlbusy is the total utilization and it's above 80%.

The customer also tested another wifi module(not TI product) and found the channel utilization is lower than CC3100MOD. Could you give some suggestions regarding to the use case of large network for CC3100MOD? What test could be implemented to find the cause of this? Any suggestion to decrease the channel utilization?

Thanks!

Best regards,

Shuyang

  • Please find the AP's airtime percentage which represents the channel utilization, with comparison of CC3100MOD and the other Wi-Fi module:

    CtlBusy% CtlBusy% CtlBusy% CtlBusy%
    No connection 2 x Liderda module 2 x CC3100MOD 3 x CC3100MOD
    33 36 60 72
    32 29 59 70
    33 28 56 69
    33 30 55 72
    28 31 57 74
    33 31 55 76
    30 29 50 71
    33 38 60 82
    38 33 54 71
    40 34 59 72
    32 38 45 71
    34 45 53 76
    34 30 38 72
    30 29 41 64
    32 28 43 61
    32 28 31 62
    30 30 36 52
    Average 32.76 32.18 50.12 69.82

    And the customer also want to check the spectral mask value of CC3100MOD, because they suspect this is the cause of the high channel utilization. Would you please kindly provide the data?

    Thanks.

    BR, 

    Shuyang

  • Hi Shuyang,

    I'm not sure what is the purpose of the test.

    The tcp socket example tries to send/receive as much data as possible so it will increase the channel utilization.

    Does the other device also sends high throughput data?

    If you just want to connect many stations to the AP with minimum inference to the channel check for example the idle profile example.

    Br,

    Kobi

  • Hi Kobi,

    The customer is not using the original tcp_socket example, sorry for making you confused. They modified the example to transfer data received from host MCU through SPI interface, and the throughput is about 9K Byte/second. The channel utilization data was measured under this throughput, and the modules for comparison also use the same condition.

    Please let me know if you need more details, thanks!

    BR,

    Shuyang

  • We need to check air sniffer logs to understand what is going on. It can be that the other device supports higher data rates or that the distance from the AP causes retransmissions.

    There is no known issue that can explain this.

    Br,

    Kobi

  • Hi Kobi,

    Please find the air sniffer log as attached. The test used 4 CC3100MODs with IP addresses as below:

    192.168.100.90

    192.168.100.94

    192.168.100.169

    192.168.100.221

    And 192.168.100.53 is the PC.

    The CC3100MODs started to transmit data to the PC at the beginning, the data rate was around 10KB/s. The host MCU of CC3100MOD was reset after 5 minutes later, and was shut down again after the 6th minute, then reboot after the 7th minute.

    Would you please help review the log and give some advice about the possible cause of the high channel utilization?

    Thanks!

    BR,

    Shuyang

    8686.log.zip

  • Hi Shuyang,

    Kobi who has been looking into this issue for you is out of the office. Please give him until he is back in the office next week to follow-up.

    Best Regards,

    Ben M

  • Hi Ben,

    Thanks for the note, I will wait for Kobi's reply.

    BR,

    Shuyang

  • Hi Shuyang,

    We need to see the air sniffer log to see the difference in the wi-fi behavior.

    In the log you've provided, i can't find anything problematic.

    It seems that at least these 4 devices complete the 10B transfer within 100-150 msec - so seems like it should be much less than the utilization numbers that were provided. We need to check what happens over the air in order to understand the difference between the CC3100 and the competition performance. 

    Br,

    Kobi

  • Hi Kobi,

    Do you have a guide for how to capture the air sniffing log? Does the customer need to purchase extra tools (like Omnipeek) for air sniffing?

    Thanks.

    BR,

    Shuyang

  • No, we don't have a guide.

    Omnipeek is a good option, but there are few alternatives (e.g. using the free Wireshark sniffer with a supported Wi-Fi dongle and sometimes just using the laptop's onboard Wi-Fi).

  • Hi Kobi,

    The customer has provided a sniffer log with 20 CC3100MODs connected to AP, with the channel utilization rate about 70%. The customer has observed lost of connections under this setup. Would you please help review the log and analyze the cause of the high channel utilization? Thanks.

    https://tidrive.itg.ti.com/a/f94X4OLeF_5t3hf4/3b7e5886-5836-4f25-9a9f-11591e0d9339?l

    BR,

    Shuyang

  • Thanks.

    Please provide as much as possible details on the use case (e.g. MAC addresses of participating devices). i'll check the log early next week.

    BTW what is the difference in utilization rate from the reference (i.e. when using 20 non-ti devices)?

    Some of the disconnections may be related to use of PS-POLL which has some IOP issues with some APs (which AP was used by the customer)? Maybe it is worth to try to disable the PS-POLL (see command below):

    SlWlanNoPSPollMode_t NoPsPollMode;
    NoPsPollMode.Enable = 1; // enable no PS-Poll mode (work without PS-Poll frames)
    sl_WlanSet(SL_WLAN_CFG_GENERAL_PARAM_ID, SL_WLAN_GENERAL_PARAM_OPT_NO_PS_POLL_MODE, sizeof(SlWlanNoPSPollMode_t),(_u8 *)& NoPsPollMode);
    
    

    Br,

    Kobi 

  • Hi Kobi,

    Please find the mac addresses of the AP and the nodes as below:

    Node MAC Address
    Huawei:BF:85:C0(AP) DC:21:E2:BF:85:C0
    Dell:03:93:D7(server) D8:D0:90:03:93:D7
    TexasInst:42:66:12 64:69:4E:42:66:12
    TexasInst:42:41:FA 64:69:4E:42:41:FA
    TexasInst:EE:16:A3 00:35:FF:EE:16:A3
    TexasInst:42:47:88 64:69:4E:42:47:88
    TexasInst:42:40:9A 64:69:4E:42:40:9A
    TexasInst:EE:15:27 00:35:FF:EE:15:27
    TexasInst:EE:16:F4 00:35:FF:EE:16:F4
    TexasInst:42:40:D3 64:69:4E:42:40:D3
    TexasInst:EE:16:AD 00:35:FF:EE:16:AD
    TexasInst:42:68:6F 64:69:4E:42:68:6F
    TexasInst:EE:16:8A 00:35:FF:EE:16:8A
    TexasInst:42:44:67 64:69:4E:42:44:67
    TexasInst:42:3C:B6 64:69:4E:42:3C:B6
    TexasInst:42:3B:6E 64:69:4E:42:3B:6E
    TexasInst:11:1E:83 2C:AB:33:11:1E:83
    TexasInst:42:44:2E 64:69:4E:42:44:2E
    TexasInst:42:68:01 64:69:4E:42:68:01
    TexasInst:EE:18:A2 00:35:FF:EE:18:A2
    TexasInst:42:47:87 64:69:4E:42:47:87
    TexasInst:42:44:06 64:69:4E:42:44:06

    The nodes collects sensor data and send to server. The data rate from each node is about 9kB/s.

    The customer doesn't have 20 non-TI devices to test, but they test the case with 2 non-TI devices against 2 CC3100s. The result is listed in my re-post.

    Thanks for the advice of disabling PS-POLL, I will let the customer try.

    BR,

    Shuyang

  • And the AP is Huawei AP8150DN

  • Hi Kobi,

    I checked the release note, it seems this option was added in the servicepack 2.12. However, the customer cannot use the servicepack 2.12 or 2.13 because CC3100 can't connect to their AP with these servicepack versions. I have submitted another post for this: 

    https://e2e.ti.com/support/wireless-connectivity/wifi/f/wi-fi-forum/986872/cc3100mod-can-t-connect-to-ap-with-nwp-version-2-12-and-2-13

    The customer is now using servicepack 2.11, so could you please review the log to see if there is other causes? Thanks.

    BR,

    Shuyang

  • That's true. I missed that they issue relates to CC3100.

    Anyway, i don't see too many disconnections and i don't see the devices are going to PS mode at all - so PS-POLL is not the issue.

    I see that there are many retransmissions (especially when transmitting to the stations. What is the distance between the AP and the stations?

    I assume this is a custom design. If so, did it pass our design review?

    From the numbers you sent it seems that the issue is more critical in the low numbers of devices (as the utilization is around 70% with 3 devices and the same with 20 devices).

    Can you send a 2 logs: one having 2/3 TI stations and another having the 2/3 non-TI stations, so I can compare the behavior?

    br,

    Kobi

  • Hi Kobi,

    The customer is using CC3100MOD, not a custom design.

    The test setup is as below, the distance between AP and CC3100 is around 25-30m:

    And I double checked with the customer, the data before(70%) is captured under a noisy environment, rather than the relatively clean one used for the test with 20 CC3100MODs. So I'm afraid the data can't be used for comparison.

    From the sniffer log, can you identify the reason of the frequent retransmission? Thanks.

    BR,

    Shuyang

  • no, we can't find the reason from the log.

    The modules are used within the boosterpack (CC3100MODBOOST), right?

    we need to compare the TI devices to the non-TI ones (same environment, same number of stations) to try to identify the differences.

    Br,

    Kobi

  • Hi Kobi,

    The modules are soldered onto customer's PCB, not within the boosterpack. Is there anything need to take care from the hardware side?

    I will try to ask the customer to capture the log of TI devices vs. non-TI ones, but the modules are already deployed, I'm not sure they can reproduce the environment for the test as the previous log used. Do you have any general advice that they can try without the sniffer log?

    Thanks!

    BR,

    Shuyang

  • I'll need to check with our hw team to see if there is anything that can explain the low rx sensitivity. Did they performed any RF tests using the new board?

    I need to see a comparison between the TI and the non-TI devices (when the TI devices cause the high utilization). In the old log, there were some issues (in the RX side) but the utilization was not as bad as before so i'm not sure we are seeing the real issue.

    Br,

    Kobi

  • Hi Kobi,

    What's the progress on this issue?

    Thanks!

    Best regards,

    Wuxiang

  • Again, i'm waiting for logs from the customer that will allow us to compare the behavior of TI devices to non-TI devices.

    With the previous one we didn't see the bad utilization numbers that were reported originally.