• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 326 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.

CC2541: Low Power Mode operation in Central Mode

Rob Weekly
Intellectual 910 points
Part Number: CC2541


Hi there,

I've been struggling trying to get the CC2541 working as a CENTRAL DEVICE to utilise the POWER DOWN modes during operation.

Currently the application take 8ma and then about 17mA once it is connected. Looks to save some power as running from a coin cell,
can a central harness any of the power down features.

Typically other than the radio, I have two very short events that occur. One every 10ms and one every 100ms. The device is only
transmitting to a connected peripheral if there is some user action, so normally not much radio activity other than connection events.

Just need some clarification power save is useable in Central mode and any other suggestions welcome.

Best Regards

Rob

  • 0
    Guru 735685 points

    Basically, you cannot do much power saving for BLE central. BLE central usually consumes lots power.

  • 0 in reply to YiKai Chen
    TI__Mastermind 40380 points

    Hey Rob, 

    What makes you think that the power is not expected? Have you analyzed the power consumption using a power analyzer of some sort? 

    I can say that while maintaining a connection interval of 10ms and another of 100ms, this will consume a decent amount of power to do this. Is there something that makes you believe that the device is not going into a lower power mode state inbetween connection events?

    Are you still scanning when connected? 

    As YiKai mentioned, the central BLE role can be more power hungry because as a BLE central device, you have to scan as well to find devices that you want to initiate a connection with. This will inherently consume more power because your radio is in the receive state consistently. If you continue scanning while connected as well, this will mean that you are not only scanning, but adding other tasks the radio has to complete (tx/rx for connections for example) as well. 

  • 0 in reply to Evan W
    Intellectual 910 points

    Hi Evan,

    You couldbe right 8mA is typical, but this is power when actually the Central is not scanning and has no connections, so I'm thinking maybe it could be lower to help gain a few more battery hours.

    I am very sure the device is not entering low power mode, as there is no change between having POWER_SAVING active and not. Still trying to trap those events and evaluate if it does ever
    enter saving mode. I not that when I shutdown my application to sleep in PM3 ( which is off mode waiting for IO event to wake up) - the power is then 1.5uA - and when trying to debug POWER_SAVING
    with an inline resistor on the power return and oscilloscope attached to evaluate current I never see any dips below the 8mA threshold at the moment.

    One interesting thing with the BTLE Stack I am not sure on, is the use of this function...

    osal_pwrmgr_task_state( SYS_TaskID, PWRMGR_HOLD ); 

    osal_pwrmgr_task_state( SYS_TaskID, PWRMGR_CONSERVE );

    should I call PWRMGR hold att he start of a TASK and then CONSERVE at the end - or as I expect a task is always executed to completion, power down can only occur during the OSAL main task
    when no other events have been triggered.

    Regards

    Rob

  • 0 in reply to Rob Weekly
    TI__Genius 17265 points

    Hi Rob,

    By default, all tasks should start in PWRMGR_CONSERVE, so there should not be a need to call osal_pwrmgr_task_state. You can also try intentionally leaving a task in PWRMGR_HOLD in order to see if that makes your current consumption any worse. Have you ensured that you are not hanging somewhere in one of your events? Lastly, how are you managing the timing for your two events?

    Best Regards,
    Alec M