• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 41 subscribers
  • Views 590 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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:

CC3120: DTIM and LSI influence on power consumption

CC3220SF: Understanding LSI current consumption. Seeing extra NWP beacon wakeups.

Ben Schoeler
Intellectual 770 points
Part Number: CC3220SF


Hi support,

We are trying to understand the impact of LSI on current consumption.

See the attached screenshots.  Our AP is set to DTIM 1.  We set the LSI to 520ms, and let the CC32 enter lpds.  At this point, we have a connected idle environment, with one socket open.

Usually, we see around ~510ms between each NWP wakeup (as expected, to service a beacon).  

Zoomed in of the above screen shot.  

However, sometimes we see extra beacon wakeups.  See the below screenshot.

These appear to be at the beacon interval ~100ms.  Why is the NWP waking up more often than expected?  Sometimes we can see up to 4 extra beacon wakeups in every 500ms period.  The impact of these extra wakeups is causing our current consumption to be ~30% higher than expected.

Thanks!

  • 0
    TI__Mastermind 28285 points
    Ben,

    What I would assume is happening here is that the device is missing the beacon at the ~ 500 ms interval, and because of this it wakes up on the next beacon (~100 ms later).

    If you let the device run for a little bit, our network algorithm should improve the probability of missed beacon events from occurring, and thus you should see this issue reduce. Is that the case?

    Best Regards,
    Vince
  • 0 in reply to Vincent Rodriguez
    Intellectual 770 points

    How long would you expect the network algorithm to stabilize?  Unfortunately, letting it run longer does not seem to have much impact.  Here are more unexpected wakeups 83 minutes in:

    I turned on RX filtering such that we will drop traffic that isn't TCP, but it seems to make no impact on these NWP events.

    Ben

  • 0 in reply to Ben Schoeler
    TI__Mastermind 30840 points
    Hi Ben,

    It is still possible to miss beacons even after the device has stabilized depending on the jitter in the timing from the AP and environmental conditions. No, the algorithm would stabilize much earlier than 83 minutes in. The algorithm is designed to provide a balance between adjusting wake-ups to ensure the connection to the AP is maintained under bad conditions and maintaining the low-power operation.

    RX filtering of TCP packets wouldn't necessarily impact this behavior. That could prevent triggering of the traffic monitor, which will also adjust the wake-up timing briefly, but it will not eliminate the events that you are seeing.

    Best Regards,
    Ben M
  • 0 in reply to Benjamin Moore
    Intellectual 770 points
    Hi Ben M

    Thanks for your response.

    I think I am beginning to understand this further. After reading up on 802.11 power save a bit more, I've begun to understand that the AP may not necessarily send the DTIM beacon at exactly the Target Beacon Transmission Time (which is why it's called a target). They can sometimes be delayed by the AP due to the way CSMA/CA works. I think what is happening here is that the beacon is delayed, and the CC32 wakes up to listen and does not hear it in some reasonable amount of time, decides to go back to sleep, and try again for the next one. Does this sound right?

    Thanks

    Ben
  • 0 in reply to Ben Schoeler
    TI__Mastermind 30840 points
    Hi Ben,

    Yes, your understanding is spot on.

    Best Regards,
    Ben M