LAUNCHCC3220MODASF: Issues with WiFi reliability

Hi Charles,

UDP broadcast have generally bigger percentage of packet lost at WiFi networks in case worse signal strength. For a test you can try this and check if you will see any difference:

• try to use UDP unicast
• set power policy to always on

Jan

Hey Jan,

I tried changing the policy to always on and it does seem to help! It does miss every now and then still, but it's a lot less frequent. I haven't had time today to test out using unicast, but I should have more time tomorrow I think.

I am a little concerned that if we have to policy as always on it will use a lot more battery power, though. I'll have to look into that as well. Do you know if there are more energy efficient ways to prevent dropped packets?

Thanks again for the help,

Charles

Hey Jan,

Unfortunately we won't be able to use unicast for this application.

I did some experiments with normal and always on power policies, and I'm still pretty concerned that something is wrong. I ran 15 test and in normal mode I only received the signal 4 times and in always on i only received it 11 times. I figured at least with always on mode we would receive all of them, and 4/15 is incredibly bad for normal mode. We have a similar program running on a raspberry pie and it never misses any of the signals, so I feel like this should be working a lot better.

Thanks again!

Charles

Hi Charles,

Because you are using LaunchPad we cannot expect issue with hardware design. If you are sure that signal is a good at both test cases, issue may to be due to interference with other Wifi networks or other 2.4GHz radios (Bluetooth, etc.).

Designing real (commercial) device with IEEE 802.11 radio which rely on UDP broadcast/multicast only is really bad idea. Because you will facing many interoperability issues at the end (customer) side. Many APs have different strategy how deal with broadcast and multicast. For example many APs drops multicast/broadcast packets in case higher load of WLAN. For example my AP from Ubiquiti have as default enabled dropping broadcast/multicast according WLAN load. Yes this feature may to be disabled, but it need to be done manually. This is a nice article which is describing IEEE 802.11 issues with multicast. With UDP broadcast is may to be situation very similar.

What I want to say at paragraph above. Even when you run test at different client devices with same AP, and one will be reliable and another not, you can't be sure that packet drop issues is related to client or AP. Due to internal management of AP with each connected client (e.g. packets at AP side may to be dropped lodging WLAN load, PHY rate, RSSI/SNR, etc.).

If you want to determine real reason of your issues, you will need to use WLAN sniffer and controlled environment (low interferences at 2.4GHz). And is also better to use AP which is full under your control - e.g. APs with OpenWRT. But even if you will be able figure out what is going on and solve your issue, after moving to another AP you can have similar problem again. From my point of view to have IEEE 802.11 device which rely on UDP broadcast may to be pretty nightmare from end - customer support side.

Jan

Hi Charles, 

Is there a lot of wireless network traffic in your environment? Fundamentally UDP is not reliable and when combined with heavy network traffic reliability decays further. To be sure you can always run this test in an isolated environment with just AP and our device to rule out any doubts.

Jan, thank again for the support.

Jesu

Hey guys,

I finally had a chance to run my test again in a lower traffic environment, but we still are missing about 1/4 of the UDP packets in always on, while the raspberry pi never seems to miss any. I also see all of the UDP packets while running wire shark, so we are still concerned about our reliability. We are aware that UDP does drop messages, but it's odd that we are dropping so many more than the raspberry pi, even in always on mode. We were hoping to be at least 90% reliable in always on, is that just an unrealistic hope?

Thanks again!

Charles

Hi Charles,

I have done my own test, but I don't seen such big packet lost as you. I use UDP broadcast for discovering CC3220 devises. My device is in always on mode. I used very simple python script which sends small UDP broadcast in interval 100ms. RX/TX packets was counted at Python and CC3220 side. I tested with environment with low RF noise together AP from Ubiquiti (UniFi AC Lite).

Results of my tests:

• CC3220SF LP with disconnected antenna (RSSI ~ -62dBm): TX packets 7367, RX packets 7285 = 1.1% UDP broadcast packet loss
• CC3220SF LP with uFL antenna (RSSI ~ -35dBm): TX packets 7755, RX packets 7644 = 1.4% UDP broadcast packet loss

Difference between both test cases (0.3%) is only statistical deviation.

For tests I used CC3220SF LaunchPad Rev-A with code based on SDK version 3_20_00_06 and ServicePack version 3.12.0.1.

For test was used this simple Python code:

import socket, time

PORT = 30719
HOST = "192.168.236.8"

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
msg = chr(0)+chr(0)+chr(0)+chr(0xf6)
cntr = 0;

while True:
    s.sendto(bytes(msg,"iso-8859-1"), ("255.255.255.255", PORT))
    cntr = cntr + 1
    print(cntr)
    time.sleep(0.1)

Jan

Hey Jan,

What code are you using for the CC3220? I'm thinking that we may have messed something up while initializing the NWP and I'm having trouble finding the correct example code in the examples for the launchpad.

Thanks again!

Charles

Hi Charles,

For a test I used own application which have a pretty complex code. Unfortunately I can't share my code. First set of tests was done at my office. We have in office very good RF conditions (building from reinforced concrete with RF shielding windows).

I have done another set of tests at my apartment where RF conditions are much harder.

Test setup:

• I used CC3220SF LaunchPad Rev-B (pre-production device) with on board SMD antenna. Software was used same as at 1st case.
• As AP was used historic AP TP-Link TL-WR741N/ND v4 with OpenWRT 18.06.4
• Very hard RF environment including many other Wifi networks. I have used my Sennheiser wireless headphones. This headphones use proprietary 2.4GHz radio and  interfere with Wifi.
• RSSI was about -60dBm

Results: TX packets 7310, RX packets 6474 = 11.4% UDP broadcast packet loss

I am not able to determine what have bigger effect to packet lost at this test case. Whether its a poor AP or the bad RF environment with many interferences.

Jan

Hi Charles,

What SDK version are you using? I would like to make sure you're not using a very outdated SDK with old service pack. 

Also, for software you can try running network terminal. Through CLI you can connect to your AP and sends UDP packets. You shouldn't have to make any software modifications here. Just build, flash and open terminal to send it commands. 

If you still get the same behavior in lower RF environment try a different AP.

Jesu

Hey Jesu,

I updated my sdk a few months ago, so I don't think it should be too old. It looks like its simplelink_cc32xx_sdk_2_40_02_00.

I'll look into using the network terminal example. I believe that is where we started when we were writing our UDP code.

Thanks again!

Charles

Hey guys,

I haven't had time to try out the network terminal example again, but I'm hoping to spend some more time this week investigating why we are so unreliable. I realized that we are using FreeRTOS, is it possible that is causing some issues? Also, if posting my code would help, I can certainly try and post whatever is relevant.

Thanks again,

Charles

Hi Charles,

As long as you're not mixing RTOS (i.e. FreeRTOS with TI-RTOS) it should be okay). It should not be difficult to bring up the network terminal test. We also have a FreeRTOS version of the example. You just need to connect to an AP using wlanconnect then use the send command with relevant parameters. More details in actual CLI when running the example.

Jesu