• State TI Thinks Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 3 answers
  • Subscribers 41 subscribers
  • Views 388 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

CC3120MOD: Station mode is unstable means ping response time varies too much

CC3120MOD: Station mode or access point mode is unstable means ping response time varies too much on latest service pack

Mahendra Rana
Expert 1010 points
Part Number: CC3120MOD
Other Parts Discussed in Thread: CC3120

Hi,

Can anyone help why I am getting this kind of response time variation or sometime timeout on ping command as I am using latest service pack and host driver,

This behavior observed in both AP and station mode but sometimes it work fine why?

==============================================

CHIP: 0x31000000
MAC: 2.0.0.0
PHY: 2.2.0.7
NWP: 3.15.0.1
ROM: 0
HOST: 3.0.1.41
MAC address: c8:df:84:4f:ba:f9

==============================================

Pinging 192.168.43.237 with 32 bytes of data:

Reply from 192.168.43.237: bytes=32 time=9ms TTL=128
Reply from 192.168.43.237: bytes=32 time=102ms TTL=128
Reply from 192.168.43.237: bytes=32 time=37ms TTL=128
Reply from 192.168.43.237: bytes=32 time=32ms TTL=128
Reply from 192.168.43.237: bytes=32 time=138ms TTL=128
Reply from 192.168.43.237: bytes=32 time=144ms TTL=128
Reply from 192.168.43.237: bytes=32 time=162ms TTL=128
Reply from 192.168.43.237: bytes=32 time=7ms TTL=128
Reply from 192.168.43.237: bytes=32 time=3ms TTL=128
Reply from 192.168.43.237: bytes=32 time=30ms TTL=128
Reply from 192.168.43.237: bytes=32 time=4ms TTL=128
Reply from 192.168.43.237: bytes=32 time=7ms TTL=128
Reply from 192.168.43.237: bytes=32 time=152ms TTL=128
Reply from 192.168.43.237: bytes=32 time=8ms TTL=128
Reply from 192.168.43.237: bytes=32 time=3ms TTL=128
Reply from 192.168.43.237: bytes=32 time=35ms TTL=128
Reply from 192.168.43.237: bytes=32 time=9ms TTL=128
Reply from 192.168.43.237: bytes=32 time=7ms TTL=128
Reply from 192.168.43.237: bytes=32 time=113ms TTL=128
Reply from 192.168.43.237: bytes=32 time=130ms TTL=128
Reply from 192.168.43.237: bytes=32 time=8ms TTL=128
Reply from 192.168.43.237: bytes=32 time=32ms TTL=128
Reply from 192.168.43.237: bytes=32 time=76ms TTL=128
Reply from 192.168.43.237: bytes=32 time=6ms TTL=128
Reply from 192.168.43.237: bytes=32 time=108ms TTL=128
Reply from 192.168.43.237: bytes=32 time=9ms TTL=128
Reply from 192.168.43.237: bytes=32 time=31ms TTL=128
Reply from 192.168.43.237: bytes=32 time=31ms TTL=128
Reply from 192.168.43.237: bytes=32 time=54ms TTL=128
Reply from 192.168.43.237: bytes=32 time=89ms TTL=128
Reply from 192.168.43.237: bytes=32 time=3ms TTL=128
Reply from 192.168.43.237: bytes=32 time=116ms TTL=128
Reply from 192.168.43.237: bytes=32 time=34ms TTL=128
Reply from 192.168.43.237: bytes=32 time=31ms TTL=128
Reply from 192.168.43.237: bytes=32 time=159ms TTL=128
Reply from 192.168.43.237: bytes=32 time=7ms TTL=128
Reply from 192.168.43.237: bytes=32 time=7ms TTL=128
Reply from 192.168.43.237: bytes=32 time=103ms TTL=128
Reply from 192.168.43.237: bytes=32 time=115ms TTL=128
Reply from 192.168.43.237: bytes=32 time=125ms TTL=128
Reply from 192.168.43.237: bytes=32 time=132ms TTL=128
Reply from 192.168.43.237: bytes=32 time=7ms TTL=128
Reply from 192.168.43.237: bytes=32 time=30ms TTL=128
Reply from 192.168.43.237: bytes=32 time=38ms TTL=128
Reply from 192.168.43.237: bytes=32 time=3ms TTL=128
Request timed out.
Reply from 192.168.43.237: bytes=32 time=4ms TTL=128
Reply from 192.168.43.237: bytes=32 time=6ms TTL=128
Reply from 192.168.43.237: bytes=32 time=2ms TTL=128
Reply from 192.168.43.237: bytes=32 time=63ms TTL=128
Reply from 192.168.43.237: bytes=32 time=72ms TTL=128
Reply from 192.168.43.237: bytes=32 time=88ms TTL=128
Reply from 192.168.43.237: bytes=32 time=15ms TTL=128
Reply from 192.168.43.237: bytes=32 time=4ms TTL=128
Reply from 192.168.43.237: bytes=32 time=125ms TTL=128
Reply from 192.168.43.237: bytes=32 time=135ms TTL=128
Reply from 192.168.43.237: bytes=32 time=7ms TTL=128
Reply from 192.168.43.237: bytes=32 time=159ms TTL=128
Reply from 192.168.43.237: bytes=32 time=33ms TTL=128
Reply from 192.168.43.237: bytes=32 time=32ms TTL=128
Reply from 192.168.43.237: bytes=32 time=92ms TTL=128
Reply from 192.168.43.237: bytes=32 time=103ms TTL=128

Ping statistics for 192.168.43.237:
Packets: Sent = 62, Received = 61, Lost = 1 (1% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 162ms, Average = 56ms

Regards,

Mahendra Rana

  • 0
    TI__Guru 61436 points

    It can be due to the load on the channel: distance from the AP or congested air (i.e. if there are other devices on the same channel and specifically on the same network) can cause re-transmissions and delays.

    A temporary disconnection from the AP can introduce long delay.

    Also this can depend on other activities on your devices, i.e. in case of other threads using the wi-fi in parallel to the ping.

    All this assumes that the delays are caused within the local network.

    Br,

    Kobi

  • 0 in reply to Kobi Leibovitch
    Expert 1010 points

    Hi Kobi,

    1) No, other device on same channel communicating. And device are kept just nearer means less than 1 meter. But still observed high response time / time out or unstable response time in ping command why?

    Some more observations: -

    2) In station mode I observed when device starts communicate with modbus tcp/ip socket then response time is good but when i again close socket then ping response time get unstable and long.

    For this I have already made device in always power ON mode.

    Status = Set_STAtxPower(STA_POWER_MAXM); // Maximum Tx power set
    Status = Set_STAPowerPolicies(); // Always power ON, not goes to lower power mode.
    Status = Set_STAConnectionPolicies(); // Auto

    But still seems goes in low power mode why?

    3) In AP mode sometimes its response time is good / stable and sometimes in starting it misbehaves and after 30-40 seconds of connection it response properly why?

    Reply from 192.168.43.237: bytes=32 time=1822ms TTL=128
    Request timed out.
    Request timed out.
    Request timed out.
    Reply from 192.168.43.237: bytes=32 time=4ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=2ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=5ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=2ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=2ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=2ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=5ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=3ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=5ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=5ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=5ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=5ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=5ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=5ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=5ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=5ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=5ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=5ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=5ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128.


    Reply from 192.168.43.237: bytes=32 time=11ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=5ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=14ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=35ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=52ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=261ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=5ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=3ms TTL=128
    Request timed out.
    Request timed out.
    Reply from 192.168.43.237: bytes=32 time=288ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Request timed out.
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128
    Reply from 192.168.43.237: bytes=32 time=1ms TTL=128

    Regards,

    Mahendra Rana

  • 0 in reply to Kobi Leibovitch
    Expert 1010 points

    Hi Kobi,

    Sorry forget to mention in last reply that we are using non rtos environment on non TI host controller. So in latest host driver we have done changes according to below link: -

    Implemented OS Adaptation Layer for non rtos environment :-
    (referred from https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/690115)  

    Regards,

    Mahendra Rana

  • 0 in reply to Mahendra Rana
    Expert 1010 points

    Hi Kobi,

    Waiting for your comment on my issue. Please reply...

    Regards,

    Mahendra Rana

  • 0 in reply to Mahendra Rana
    TI__Guru 61436 points

    Is the station in low power mode?

    This can explain the latency variance, as the station only wakes up every for the AP beacons (typically once every 100ms).

    What is your concern about this variance?

    Br,

    Kobi

  • 0 in reply to Kobi Leibovitch
    Expert 1010 points

    Hi Kobi,

    Our concern is that why CC3120MOD is that much unstable response time in AP and Station mode both?

    1) As No, other device on same channel communicating. And device are kept just nearer means less than 1 meter. But still observed high response time / time out or unstable response time in ping command why?

    2) In station mode I observed when device starts communicate with modbus tcp/ip socket then response time is good but when i again close socket then ping response time get unstable and long.

    For this I have already made device in always power ON mode.

    Status = Set_STAtxPower(STA_POWER_MAXM); // Maximum Tx power set
    Status = Set_STAPowerPolicies(); // Always power ON, not goes to lower power mode.
    Status = Set_STAConnectionPolicies(); // Auto

    But still seems goes in low power mode why?

    3) In AP mode sometimes its response time is good / stable and sometimes in starting it misbehaves and after 30-40 seconds of connection it response properly why?

    4) we are using non rtos environment on STM32 host controller. So in latest host driver we have done changes according to below link: -

    Implemented OS Adaptation Layer for non rtos environment :-
    referred from  https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/690115 

    Waiting for solution on our issue.

    Regards,

    Mahendra Rana

  • 0 in reply to Mahendra Rana
    Guru 73255 points

    Hi,

    Just a quick comment. to point 2). I am pretty sure that you not have properly set away-on power policy. Long latency to ping which you see is pretty expected at normal power policy. After changing power policy may to re restart (sl_Stop/sl_Start) required.

    Jan

  • 0 in reply to Jan D
    Expert 1010 points

    Hi Jan,

    No I have already stop/start device after complete configuration and checked in debug mode on power policy API (to always power ON) so that API not returns any error while configuring it. My code is like this: -

    Status = Set_STAPowerPolicies(); // Always power ON, not goes to lower power mode.
    Status = Set_STAConnectionPolicies(); // Auto

    Status = STA_SetDHCPIpAddr(); // Configured IPv4 value from DHCP Server

    // Configure country code as EU which supports channels 1-13 (JP country code

    // also supports channels 1-13, but US country code supports only channels 1-11).
    Status = Set_Channel(STA_CHANNEL, (uint8_t *)COUNTRY_CODE);

    Status = connect_ToAP((int8_t *)temp_user_char1, wireless.flags.bit.wifi_encryption, (int8_t *)temp_user_char2);

    Status = sl_Stop(0); // Reset the device
    ASSERT_ON_ERROR(Status);

    HAL_Delay(50);

    Role = sl_Start(NULL,NULL,NULL); // start the device
    ASSERT_ON_ERROR(Role);

    1) Is it I have to stop/start device just after configure power policy?

    2) Why in AP mode also I am getting unstable in ping command?

    waiting for your reply!

    Regards,

    Mahendra Rana

  • 0 in reply to Mahendra Rana
    Guru 73255 points

    Hi,

    Answers to your questions:

    1. It should be enough do restart after configuring all parameters. You don't need restart at next step after changing power policy. But I am not able to say if function Set_STAPowerPolicies() is properly implemented.

    2. I don't see any reason for such behaviour at AP mode. Because at AP mode are not used power save modes. But few thing may to cause similar behaviour:

    • improper RF design. Was your RF design properly implemented (that means calculated proper impedance of your antenna path) and optimised e.g. using VNA? How looks RSSI from CC3120 and infrastructure AP side?
    • maybe issue can be related to your client device (e.g. cell phone) at AP mode of CC3120. Can you test with another device?
    • can you test with some older ServicePack?

    Jan

  • 0 in reply to Jan D
    Expert 1010 points

    Hi Jan,

    1) in Set_STAPowerPolicies() function I have implemented below and I think it is correct.

    Status = sl_WlanPolicySet(SL_WLAN_POLICY_PM , SL_WLAN_ALWAYS_ON_POLICY, NULL,0); 

    2) RF design is proper (as even checked long distance range up to approx 80 meter) and this issue I have already checked on old service pack "3.9.0.6-2.0.0.0-2.2.0.6" and also checked on multiple laptop in AP mode and in station mode by connecting with office network but same behavior.

    3) Any suggestion to resolve issue as in station mode getting stable ping response when communicate with modbus tcp/ip?

    4) Also don't know why in AP mode some times unstable but sometimes stable response getting?

    5) As we are having non rtos environment so how often we have to call sl_task(NULL) API as right now called on approx every 2ms. Is it fine?

    6) Is it while reset device means stop/start needs to add timeout. I have not added any time out right now sl_stop(0).

    waiting for your reply!

    Regards,

    Mahendra Rana

  • 0 in reply to Mahendra Rana
    Guru 73255 points

    Hi,

    1. It looks OK.

    2. Even you are able to connect from long distance, you can still have RF design issue, even it is less likely. Maybe you can read RSSI to be sure.

    3. I am not sure what is going on at your case. But this behaviour at STA mode is exactly what is expected when normal power policy is set.

    4. Sorry, I am not able answer your question. Maybe you can test at different location (with less RF interferences).

    5. Sorry, I am not able answer your question. Please wait for answer from TI. But for me it looks too often.

    6. Calling sl_Stop() without timout after calling API which save configuration is pretty bad idea. It may to happen that configuration is not properly saved info sFlash. Please use timeout 200.

    Jan

  • 0 in reply to Jan D
    TI__Guru 61436 points

    Hi,

    Just adding regarding question 5, that the interval is completely dependent on the application (latency, power consumption and bandwidth requirements).

    The driver should be able to work with this but you should consider the costs (comparing to longer/shorter intervals).

    Br,

    Kobi

  • 0 in reply to Jan D
    Expert 1010 points

    Hi Jan,

    One more issue I am facing in AP mode

    Is it in AP mode we need to set gateway ip same as device ip and How to not lease default gateway to connected client/mobile so that I can access internet as well in mobile if connected with CC3120MOD in AP mode

    "and on that you /TI suggested to use own DHCP server so: -

    1) Whats changes we need to do for disabling internal DHCP server.

        Is it by just calling this API will stop internal DHCP server and then will start our own while configure CC3120MOD in AP mode?

        Status = sl_NetAppStop(SL_NETAPP_DHCP_SERVER_ID);  // Stop DHCP server before settings

    2) In our application we have provision of to connect maximum one client at a time with AP so can you suggest any example code code of own DHCP server in which we will modify just to not lease default gateway.

    Thanks,

    Mahendra Rana

  • 0 in reply to Mahendra Rana
    Guru 73255 points

    Hi,

    1) Yes, this should be enough. But I am not sure is NWP reboot is not mandatory as well. This you can easily test. If you will not able able start UDP server at port 67, internal DHCP server is still running.

    2) Sorry I am not able to provide you code for DHCP server. But implementation of own DHCP server is a pretty simple job. For example you can search around IwIP stack and their DHCP server implementations.

    Jan

  • 0 in reply to Jan D
    Expert 1010 points

    Hi Jan,

    Thanks for your reply!

    Any document or guide on How to implement own DHCP server? Which will help me.

    Regards,

    Mahendra Rana

  • 0 in reply to Mahendra Rana
    Guru 73255 points

    Hi,

    I don't know about some step-by-step description how to implement DHCP server. This you need to find by yourself.

    Specification of DHCP protocol you find at RFC. There is many books which describes DHCP protocol (e.g. TCP/IP from Heather Osterloh)

    Jan