• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 40 subscribers
  • Views 134 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.

CC3100: cts-to-self

Steven Baker
Intellectual 255 points
Part Number: CC3100

I am trying to improve battery life of an embedded product that uses a CC3100 module.  From what I can tell, the module is using CTS-to-self. There are not other devices on this network, so we prefer to not have CTS enabled.

In the sniffer trace, we see that the CTS is sent by the TI STA (packet 11111) that in the very next packet (11112) is a data transmission from the same TI STA.   On inspection, the NAV for the CTS is 262 microseconds. Interestingly, packet 11112 is received 369 microseconds after 11111, so it seems the NAV has already expired before packet 11112 has been transmitted.    There was no RTS before packet 11111.

We are using a power setting of 7 (7 dB below max power).  Note that the received CTS signal is indicated as about 8 dB higher than the data signal, implying it was transmitted with a power setting of 0, where the external PA is enabled.

Can you please confirm if the CC3100 implements CTS-to-self? 

IF so:

  1.  is there a way to disable it?
  2. is there a way to ensure the CTS only uses the same Tx power as the data?
  3. why a delay of 369 microseconds after the CTS before the data packet is transmitted?  I would expect something like an SIFS (10 microseconds).  With the data frame transmitted after the NAV expires, could you explain the purpose of the CTS?

IF the CC3100 is not implementing CTS-to-self, then could you help me understand the purpose of the CTS (packet 11111)?

Thank you,

Steve

  • 0
    TI__Mastermind 38980 points

    Hi Steve,

    I need some more information. Can you attach the sniffer trace?

    1. What servicepack version is flashed?
    2. What power policy is configured?
    3. Is the device acting as a AP or station? Is it connected?

    Best regards,

    Sarah

  • 0 in reply to Sarah P
    Intellectual 255 points

    HI Sarah,

    Tx for the response and additional questions.  

    1.   I'm checking w/ the FW engineer and will update when I have the information.  

    2.  Normal power mode, power level 7

    3.  The device is acting as a STA in a P2P (Legacy Wi-Fi direct mode).  It is connected.  In packet 11112, the device with the TI radio is transmitting a 1580 B packet the other 802.11 device.  The other 802.11 device is configured for Wi-Fi direct and the TI radio associates with it. The other device has mac address: fa:e4:e3:c7:22:61

    I reduced it to 550 kB, but the web server seems to not be happy with it as a file upload..  The trace is (hopefully) available at this link.  The original packet # 11111 is now #1111.  

    Note that starting at #1111, we see pairs of CTS and data, without an RTS. (which is why I think this is a CTS-to-self).  A similar sequence happens elsewhere, for example, starting at #1161.  

    • 1111 CTS (destination TI_ff:f9:de)
    • 1112 Data (from TI_ff:f9:de)
    • 1113 CTS (destination TI_ff:f9:de)
    • 1114 Data (from TI_ff:f9:de)
    • 1115 CTS (destination TI_ff:f9:de)
    • 1116 Data (from TI_ff:f9:de)

    In contrast, at packet #1255, we see a standard RTS/CTS/Data sequence

    • 1255 RTS to the TI radio from fa:e4:e3:c7:22:61
    • 1256 CTS w/ destination fa:e4:e3:c7:22:61
    • 1257 Data from fa:e4:e3:c7:22:61 to the TI radio.

    Another odd things re: CTS.

    packets 1072 & 1073, both CTS packets from the TI radio are about 340 microseconds apart.  Since CTS doesn't require an ACK, why would the TI radio.  This occurs multiple time in the trace, including at 1153 & 1155, two CTS packets are about 400 microseconds apart.

  • 0 in reply to Steven Baker
    TI__Mastermind 38980 points

    Hi Steve,

    Thanks for the sniffer trace. It will take a day or two to review it.

    Please let me know when you determine the servicepack version. If it is not the latest version v1.0.1.15-2.14.0.0, that will be the first thing I ask you to test. Note that servicepacks are backwards-compatible, so you can test it without updating the host driver version or changing your host application.

    Best regards,

    Sarah

  • 0 in reply to Sarah P
    Intellectual 255 points

    HI Sara,

    Thank you for the update. I understand it may take a while to sift through the trace.

    BTW, the options indicated in the user guide do not include "service pack" version that we see. 

     printf("Build Version %d.%d.%d.%d.31.%d.%d.%d.%d.%d.%d.%d.%d\n",
    _ver.NwpVersion[0], _ver.NwpVersion[1], _ver.NwpVersion[2], _ver.NwpVersion[3],
    _ver.ChipFwAndPhyVersion.FwVersion[0], _ver.ChipFwAndPhyVersion.FwVersion[1],
    _ver.ChipFwAndPhyVersion.FwVersion[2], _ver.ChipFwAndPhyVersion.FwVersion[3],
    _ver.ChipFwAndPhyVersion.PhyVersion[0], _ver.ChipFwAndPhyVersion.PhyVersion[1],
    _ver.ChipFwAndPhyVersion.PhyVersion[2], _ver.ChipFwAndPhyVersion.PhyVersion[3]);
    On an EVK (not our production code), we received this from the prior printf.  
    Is this what you are requesting?
    Best,
    Steve
  • 0 in reply to Steven Baker
    TI__Mastermind 38980 points

    Hi Steve,

    The first four numbers of the servicepack version correspond to the tested host driver version. The next four numbers are the NWP version. See the servicepack release notes for more details.

    Servicepacks are backwards-compatible with an older host driver, but the opposite it not true: an old servicepack (i.e. old NWP firmware version) can not be used with a newer host driver. So if you are using host driver 1.0.1.6, you should have at least the 1.0.1.6-2.7.0.0 servicepack loaded to the serial flash.

    I recommend you update to the latest servicepack (1.0.1.15-2.14.0.0) and test again.

    Best regards,

    Sarah