• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 40 subscribers
  • Views 1903 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 power policy

ron jacoby
Intellectual 750 points
Other Parts Discussed in Thread: CC3100

im trying to use the SL_LONG_SLEEP_INTERVAL_POLICY power policy in sdk 1.0, firmware version 4.5

changing the values appears to change the interval between wakeup, but not giving the correct intervals.

setting 200 msec gives a 150 msec interval, but setting 300 msec gives 89 msec interval. see the attached power measurements with resolution of 120 usec. also, the current level is sometimes much higher than the spec

this is the code:

_u16 PolicyBuff[4] = {0,0,200,0}; // PolicyBuff[2] is max sleep time in mSec

sl_WlanPolicySet(SL_POLICY_PM , SL_LONG_SLEEP_INTERVAL_POLICY, (_u8*)PolicyBuff,sizeof(PolicyBuff));

200 msec setting:

300 msec setting:

  • 0
    TI__Mastermind 26155 points

    Hi Ron,

    Can you please share the average current values in both cases?

    Regards,

    Ankur

  • 0 in reply to Ankur Baranwal
    Intellectual 750 points

    in the first case, average current is 2.53 mA, for the second case 3.04 mA

  • 0 in reply to ron jacoby
    TI__Intellectual 1630 points

    Ron,

    Can you please share the following:

    1. Beacon interval - what is the time between beacons that the AP is configured to?

    2. DTIM - what is the DTIM configurtation in the AP

    3. Capture with NORMAL policy - same capture as you did just without any configuration of long sleep interval

    4. AP model

    Regards

    Ben

  • 0 in reply to Ben Gilboa
    Intellectual 750 points

    seems there was a mistake in previous measurements I posted.

    now we've tested in NORMAL mode, 100 msec beacon DTIM=1 and the wakeup interval looks ok - every 100 msec.

    however, every third beacon it is waking up for 30 msec instead of 1 msec, which increases average power significantly.

    do you have some explanation for this ?

  • 0 in reply to ron jacoby
    TI__Intellectual 1630 points

    Ron

    From the capture it is can be seen that every third wake up is longer but it looks less than 30ms please check.

    We know that some APs send beacons not very accurately, SimpleLink internal algorithms cope with this behavior but wakeup may be a little bit longer.

    1. What is the model of the AP

    2. Can you check with different AP?

    3. Can you share sniffer capture showing the beacons?

    Ben

  • 0 in reply to Ben Gilboa
    Intellectual 750 points

    we measured again on a different AP in a different location and better sampling, and got the attached results.

    the AP is edimax br6574n running dd-wrt.

    it looks like there are two separate issues here:

    - the cc3100 wakes up every 100 msec as required, but for a period of ~5 msec instead of 1 msec.

    - in a "busy" environment, perhaps because of lots of network devices sending multicast/broadcast, almost every wakeup involves transmission.

    400 usec sample rate:

    100 usec sample rate:

  • 0 in reply to ron jacoby
    TI__Intellectual 1630 points

    Ron,

    In busy environment, AP may delay the beacon which result longer wakeup.

    To refer the 5ms or the other long wakeup that you saw before, can you share a sniffer capture of the beacons?

    Ben

  • 0 in reply to Ben Gilboa
    Intellectual 750 points

    attached captures and measurements for 102.4 msec beacon and 204.8 msec beacon times.

    it appears that with the double beacon time the wakeup time also doubles.

    0160.cap.zip

    100 msec beacon

    200 msec beacon

  • 0 in reply to ron jacoby
    TI__Intellectual 1630 points

    Ron,

    SimpleLink internal algorithms are designed to optimize the always connected use case. Apart from air congestion and link quality, one of the items that impact the most on average current consumoption is if AP transmission of beacons is not accurate. Our algorithm is trying to wakeup before the beacon arrives in order to receive it correctly. If the beacon is delayed or not accurate than the wakeup can take longer time that result in higher average current consumption.

    From the sniffer capture you shared, I learn the following:

    100ms interval: there is some non accuracy that can explain higher current than the benchmark but I expect it to be less han 2mA

    200ms interval: beacons transmission non accuracy is significant. There is also inconsistency between the timestamp and the actual time that beacon is sent. From the first 10 beacons in the capture you can see the following delta time between 2 consecutive beacons: (203.776ms, 206.337ms, 203.263ms, 205.888ms, 203.777ms, 206.335ms, 204.801ms, 203.775ms, 204.864ms). This explains the longer wakeups in 200ms interval vs 100ms interval.

    Ben

     

  • 0 in reply to Ben Gilboa
    Intellectual 750 points

    hi

    I did another sniffer capture, this time with Microsoft netmon, as opposed to previous capture done using airodump on a virtual machine.

    the results for the same AP as before show that almost always the beacon interval is between 204.6 and 204.8 msec.7510.netmon.zip

  • 0 in reply to ron jacoby
    TI__Intellectual 1630 points

    Ron,

    In order to make sure there is no other problematic factor in your setup I suggest that you check with Cisco 1250 AP (Air-AP 1252) if you can.

    Ben