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.

CC3235MODSF: period excess packet delays - scanning?

Part Number: CC3235MODSF

In our application we send ~1000-1200bytes every ~290ms.

On device side we plot the sl_Send is called exactly every 288-290ms.

On our server side we also plot the frequency of the incoming packets and we see that there is a jitter every 10seconds when the SCANNING INTERVAL is set to 10s.
When SCANNING INTERVAL is set to 30s the jitter happens every 30s.

The jitter means that sometimes packets are incoming with 600ms delay. Sometimes they arrive with 5000ms delay (5seconds).

Having a delay of +320ms to 280ms is not something we would bother.
But the higher delays above 1000ms bothers us and we would like to understand why they happen and what causes them.

Note that this is not internet/routing caused delay, measurements was reproduced over the internet and on LAN with a notebook acting as client (without any delay) and the CC3235 acting as a client.
we always saw that using any other client we have no jitter at all, using the cc3235 as the client we start to experience packet delays.

Questions:
 - what other feature can cause a delay?
 - how long scanning takes when enabled on all channels (2.4G / 5G?)
 - can we disable scanning and only enable it when the RSSI of the connected SSID is low?
  - we plan to use the roaming feature (there is an issue for that - it doesnt work at the moment): what triggers the roaming? The scanning result or a certain type of packet's RSSI? OR will the roaming trigger a scan?

Scan interval set to 10s and 30s (X axis does not reflect time)

random jitters of 1600-1800ms

random jitter of 5000ms:

  • Hi,

    To answer your questions:

    1. What other feature can cause a delay?

    Interoperability issues with an AP, heavy network traffic on the WLAN, application code delaying the sl_send, as well as potentially NWP functionality such as the scan might cause delays.


    2. How long scanning takes when enabled on all channels (2.4G / 5G?)

    This is info I'm still looking into, but it varies based on how busy each Wi-Fi channel is in your environment. During each scan, it will linger on each channel for a minimum amount of time, but keep listening if it detects beacons from different SSIDs. So if there are many APs, then it could take potentially a relatively long time to complete. The exact numbers for how long it lingers I don't have at the moment.


    3. Can we disable scanning and only enable it when the RSSI of the connected SSID is low?

    Yes, this is possible. You can freely disable scanning, or increase the scan interval, and check the average RSSI of received packets through the sl_DeviceStatsGet() API to re-enable it when needed.


    4. We plan to use the roaming feature (there is an issue for that - it doesnt work at the moment): what triggers the roaming? The scanning result or a certain type of packet's RSSI? OR will the roaming trigger a scan?

    There are a few different types of roaming you can enable on the CC3235 - soft roaming, agile multiband, and triggered roaming. Please take a look at the NWP programmer's guide (http://www.ti.com/lit/swru455) for a description of each type of roaming. For soft roaming, you can configure what it checks - by default it is the beacon packet of the AP, not from the scan result. The soft roaming trigger should result in a scan when the RSSI condition is met.

    From the data you've collected, it does appear that the delay is related to the scanning interval. Some debug info that would be interesting for me to check is the NWP logs. If you can collect them and provide them to me for analysis that would be helpful. Please see section 20.1 of the NWP programmer's guide for instructions.


    Regards,

    Michael

  • Thanks all I wished to know if there are any features (API features) that might interact sending and cause unexpected with latencies.

    For now I disabled the scanning and it solved the problem. Should we experience any unexplainable delays in the future I will make the NWP log.