LAUNCHCC3220MODASF: LAUNCHCC3220MODASF: Packet Drops in WiFi-UDP mode and in Raw mode.

Hi,

A few points and questions:
- did you use latest SDK and Service Pack?
- how do you have set power policy? Can you retest with SL_WLAN_ALWAYS_ON_POLICY?

I am not sure if this is related to 2nd generation, but at CC3200 was mandatory to have small delay at TX side in transceiver mode. I am not sure what was minimal length of this delay.

Jan

Hello Jan,

1. SDK is "simplelink_cc32xx_sdk_1_50_00_06"
2. Service pack is "CC3100_CC3200_ServicePack_1.0.1.11-2.9.0.0"

3.
From "swru368a.pdf" Section 4.6.2 I see the usage of SL_WLAN_ALWAYS_ON_POLICY.
But, the description text there also mentions that the user may provide the target latency figure.

The description text is as follows:
"• Always on – The Wi-Fi subsystem is kept fully active at all times, providing the best WLAN traffic
performance. This policy is user-directed; the user may provide the target latency figure. For setting
always-on power-management policy use:
sl_WlanPolicySet(SL_POLICY_PM, SL_ALWAYS_ON_POLICY, NULL,0)"

Q.1 Which API has to be used to "provide this target latency"? Can I have a pointer to the relevant documentation?
Q.2 What is the default value in case the user does not provide the target latency when configuring the Policy as WLAN_ALWAYS_ON_POLICY?

--Regards,
Neeraj Sallh

Hi,

I am really confused what device do you use? it is CC3200 or CC3220?

- simplelink_cc32xx_sdk_1_50_00_06 - SDK for CC3220

- CC3100_CC3200_ServicePack_1.0.1.11-2.9.0.0 - ServicePack for CC3200

- swru368a.pdf - document for CC3200

I am not sure about meaning of statement in SWRU368 for CC3200. But I think that when you set always-on-policy, NWP not goes into sleep and you can get best possible performance (=target latency). In case of that you set other policies,  latency in increased by NWP itself (due to sleep).

Can you retest with latest SDK (simplelink_cc32xx_sdk_2_10_00_04) + ServicePack (3.7.0.1_2.0.0.0_2.2.0.6) with always-on-policy?

Jan

Hello Jan,

Since I am working on both the CC3200 and CC3220 boards, figuring out the SDK version, Service Pack, and the documentation etc. was confusing for me too.

Actually the project I am talking about in my query is a modification of the project "network_terminal_CC3220SF_LAUNCHXL_tirtos_ccs".

And the SDK 1.50.06 that it is using has been inherited from the project "tirtos_builds_CC3220_LAUNCHXL_release_ccs".

My installation directory also shows SDK 1.50.06.

But I cannot find any hint about the Service Pack that has been applied.

Can you please give a document reference for applying a Service Pack onto the SDK?

Meanwhile I will try the always-on-poilcy also.

--

Regards,

Neeraj Sallh

Hi Neeraj,

Yes, I also use CC3200 and CC3220. From my point of view is all crystal clear, but this is not important.

ServicePack at CC3220 works at same principles as at CC3200. ServicePack for CC3200 and CC3220 is not same, because in network processor is different firmware. ServicePack is applied into device itself (respectively uploaded into sFlash) not into SDK. ServicePack can be uploaded using Uniflash software. ServicePack you find at SDK subdirectory \tools\cc32xx_tools\servicepack-cc3x20\. Description how to use Uniflash you find here www.ti.com/lit/ug/swru469b/swru469b.pdf

Please retest with latest SDK and ServicePack with NORMAL and ALWAYS_ON power policy. I expect that issue will be still there, but we need to know this for next progression.

Jan

Hello Jan Dospel,

Just sharing one more development/observation.  This one is positive and may be you can help gain insight into this behavior.

Before changing the SDK and the Service Pack I tried one more thing.

I introduced delay between two consecutive send calls.  At the delay of 600 us, the PER came out to be 0, even for 1 million packets.

1. Therefore, does this behavior have something to do with the queues inside the sender?
2. What explains this improvement of PER?

--

Regards,

Neeraj Sallh

Hi Neeraj,

I am not sure. What is difference between you first post and this test?

But if we talk about transceiver mode, some small delay is probably expected between sends, as I said at my first post.

Jan

Hi Jan,

In my first post the delay was introduced only in the transceiver mode sends, i.e. in the implementation of the "radiotool" command.

And the reduction in the PER for the transceiver case on introduction of a delay between send calls is in line with your observation that in transceiver mode, it was required (at least in the 1st generation) that there be some delay between two send calls.

And in the last post I tell the results of trying a similar thing even in the WiFi mode, with UDP data being pumped from one CC3220 to another CC3220.

I may have not been able to correctly put across what I wanted to share.  I will try again in a better way this time.

The purpose was to share my findings that:

1. Even in WiFi mode a finite delay between two send calls improved the PER.
2. The improvement was even better that seen in the case of transceiver mode.  In transceiver mode we got PER of the order of 10E-4, i.e. 100 out of a million packets.  Whereas, when using UDP over WiFi, the PER was 0, i.e. 0 out of a million packets.
3. Lastly, I wanted to share that the improvement was achieved without the power policy being set as ALWAYS ON. 
4. And a question, if using a delay between two send calls is a good/reliable way of ensuring low PER?

--

Regards,

Neeraj Sallh

Hi Neeraj,

OK, it is all clear now. I am not sure why you seen this behaviour. ALWAYS_ON policy probably make sense to use only in STA mode.

Jan