• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 41 subscribers
  • Views 257 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.

CC3235MODASF: Always connected + MQTT power consumption optimization

Cedric Gerber
Expert 2240 points
Part Number: CC3235MODASF

Hi,

I'm considering switching one of our product which use the cc3235 from "Hibernate with HTTP" to "always connected with MQTT". And this brings a few questions regarding consumption.

1: Beacon skipping (LSI)

I see in swra594 the sentence "TI strongly recommends setting the LSI parameter to less than half a second to ensure reliable service while lowering current consumption".

My understanding is that higher LSI value cause beacon time synchronization issues, is it correct? Is there other issues?

I would like to set the LSI at max (=2sec) by default, and lower it if too many beacons are missed. 

Is there any way to know from the cc3235 if there are missed beacons?  Or if the high LSI is causing any other issue?

2: LPDS exit/enter

I would expect LPDS to be entered once, then exited each time an mqtt message is received. 

However if I track LPDS status with enterLPDSHookFxn hook, I can see a lot more LPDS enter, and none that I can link to mqtt activity. Some of them are very close in time.  

Typically it wakes 6 times within 300ms every 30sec. 

What could be the source of those wake up? How can I know the source of a LPDS exit?

2020-10-28 13:06:52,464 INFO COM10: b'Waiting on next message\r\n'
2020-10-28 13:06:52,466 INFO COM10: b'Entering LPDS\r\n'
2020-10-28 13:07:21,457 INFO COM10: b'Entering LPDS\r\n'
2020-10-28 13:07:21,473 INFO COM10: b'Entering LPDS\r\n'
2020-10-28 13:07:21,698 INFO COM10: b'Entering LPDS\r\n'
2020-10-28 13:07:21,699 INFO COM10: b'Entering LPDS\r\n'
2020-10-28 13:07:21,714 INFO COM10: b'Entering LPDS\r\n'
2020-10-28 13:07:21,714 INFO COM10: b'Entering LPDS\r\n'
2020-10-28 13:07:51,717 INFO COM10: b'Entering LPDS\r\n'
2020-10-28 13:07:51,732 INFO COM10: b'Entering LPDS\r\n'
2020-10-28 13:07:51,844 INFO COM10: b'Entering LPDS\r\n'
2020-10-28 13:07:51,845 INFO COM10: b'Entering LPDS\r\n'
2020-10-28 13:07:51,860 INFO COM10: b'Entering LPDS\r\n'
2020-10-28 13:07:51,861 INFO COM10: b'Entering LPDS\r\n'
2020-10-28 13:08:21,863 INFO COM10: b'Entering LPDS\r\n'

3: SL_WLAN_IOT_LOW_POWER_POLICY

I suppose WFA IoT Low Power is what is called "Target Wait Time" in 802.11ax. Can you confirm? 

In swru455 it is written "In case the AP does not support BSS Max Idle, the device will remain in normal power save mode".

How can we know if the AP supports it? And up to what LSI duration? 

Does it fall back to normal mode or LSI mode?

I've tried it with an LSI of 4sec, it looks good, with only a wake up every 4sec and consumption of ~340uA in between. But I was actually expecting my AP not to handle it.

I hope my questions are clear enough, do not hesitate to ask for clarifications ; )

Cédric

  • 0
    TI__Mastermind 38980 points

    Hi Cédric,

    1. Yes, the higher LSI can cause the NWP to miss beacons and your application may see more frequent disconnections. There's a little more info on LSI and Packet Loss in the Power Management Section of the NWP guide. We recommend 500 ms for the best stability, and if you go beyond that, you should monitor the frequency of unexpected disconnects. I also suggest always using the latest servicepack (they are backwards compatible with older host driver versions).
    2. What else is happening in your application? Do you have a software timer or a periodic blocking timeout? The power policy will wake the MCU for any scheduled RTOS event.
    3. No, this setting is a combination of the low power features we list in the NWP guide Power Management section. The WFA IoT Low Power setting will default to the normal power mode. The CC3235 will negotiate the maximum allowed sleep interval during the connection. I will have to check if the application is able to detect that the AP supports this feature.

    Best regards,

    Sarah

  • 0 in reply to Sarah P
    Expert 2240 points

    Hi Sarah,

    Thanks for your feedbacks and the pointer on the nwp guide!

    1:

    We do update the service packs regularly. And we can monitor disconnection. However, is it possible to know if the consumption is sub-optimal? For example if beacons are always missed and result in the NWP being often awake but without disconnection. (I don't have much experience on this, not sure if it is realistic)

    2: 

    We only have main_task, along with sl_task and idle task, no timer.

    I tried to check which task is waking up using  switchFxn hook, but I did not find how to rename the pthreads to see which is which.  I'll keep looking into it next week.

    3:

    Thanks for checking!

    In my opinion it is a must for the application to be able to know whether this setting is used. Especially if the transparent fallback is not the second lowest power consumption. 

    Best regards,

    Cédric

  • 0 in reply to Cedric Gerber
    TI__Mastermind 38980 points

    Hi Cédric,

    1. The application is setting the LSI length at the expense of missed traffic. You can use the sl_DeviceStat* APIs to track the NWP wake time and disconnects, but your application will have to determine what to do with that data.
    2. Try using PRCMLPDSWakeupCauseGet() to determine if you're waking up from network activity or the LPDS timer (which is set by the RTOS based on scheduled events).
    3. Unfortunately, there doesn't seem to be a way to do this now. The normal power mode does use the network learning algorithm to sleep as often as possible without affecting performance. I understand why you would want the flexibility though.

    Best regards,

    Sarah

  • 0 in reply to Sarah P
    Expert 2240 points

    Hi Sarah,

    Thank you for your reply.

    1: I will start using sl_DeviceStat. 

    2: Will do.

    3: Can you request this feature to the dev team? I don't think I would be the only one interested.

    According to swra594, normal mode would result in 2 to 3 times the average current consumption.

    image

    It does not much matter how it could be checked (An event when it switches mode, a way to read back the currently used mode, a way to know if the AP is compatible, ...)

    Best regards,

    Cédric

  • 0 in reply to Cedric Gerber
    TI__Mastermind 38980 points

    Hi Cédric,

    Yes, I will request this internally. A feature like that would require a change to the servicepack and host driver, so it would have to be considered for a future release. In the meantime, if you would like to try the WFA IoT policy, you may be able to use the same device statistics to monitor the NWP wake time and make some assumptions on when to change the power policy.

    Best regards,

    Sarah

  • 0 in reply to Sarah P
    Expert 2240 points

    Hi Sarah,

    Excellent, thank you!

    Yes I will check what I can get from the statistics.

    Best regards,

    Cédric