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

Improving power consumption on the SensorTag 2

Anup Rajput
Expert 1920 points

Other Parts Discussed in Thread: CC2650STK, CC2650

While we wait for the XDS110 debugger to have current measurement superpowers, I am trying to improve the power consumption on the CC2650STK SensorTag. I don't see the main SensorTag.c task ever going to sleep! Nor does it implement any kind of Semaphore_Pend, which I expected it to once the GAPROLE becomes "WAITING"/"WAITING_AFTER_TIMEOUT". Is there some purpose behind this?

Once the BLE advertisement switches itself off, what's a good point in the code to put the device into sleep such that the button press will wake it, but nothing else?

  • 0
    TI__Guru** 105180 points

    Hello Anup,

    There are no plans to add current measurement capabilities to the XDS110 (or any debugger) for the CC26xx. If you are trying to measure current, I suggest following the guidelines in the power measurement app note, available on the TI BLE Wiki page. Note that due to the PCB size and layout, the SensorTag is not ideal for taking power measurements of just the CC2650, for that the CC2650DK is recommended. The SensorTag is an IoT demonstration platform, thus it is full of sensors which will themselves consume some power.

    Regarding MCU power management, you can refer to the ICall section of the SW Developer's Guide (SWRU393). Specifically, ICall_wait is implemented as a blocking function, thus the system will transition to sleep (standby) when no other events are pending.  Also note that GAP Role states are not necessarily correlated to RTOS PM states.

    Can you describe in more detail as to what you are trying to accomplish? Optimize CC2650 power or board/component power? What is your end product application?

    Best wishes

  • 0 in reply to JXS
    Expert 1920 points

    Hi JXS,

    I got my hopes up seeing this post:

    We are not looking at extreme power optimization right (yet). We have been commissioned to build a couple of BLE enabled wearables, one of which is a fitness tracking device. Right now, we are focussing on getting the software architecture right to get the maximum juice out of our batteries. We are optimizing at the board level only right now.

    We are looking at the main SensorTag task for further optimization. For example, right now while it is advertising, it does NOT stop at ICall_wait. I could make some kind of timer handle the LED blink while advertising if I could make the main SensorTag task halt at ICall_wait till there is a timeout of some kind and it moves to the WAITING state, or there is a new BLE connection to handle.

    We would like to understand why does it NOT stop at ICall_wait during the advertising phase. Then, we will also move to the same kind of analysis of the WAITING state.

  • 0 in reply to JXS
    Expert 1920 points
    We observe that under no circumstances is the periodicClock inside the SensorTag.c stopped. Is my understanding correct that even after the device has stopped advertising, the interrupt for this clock will keep getting serviced?

    I am experimenting by switching it off after the device enters the WAITING states but would like to understand if there is some issue expected with such an action?
  • 0 in reply to Anup Rajput
    TI__Guru** 105180 points

    Hi Anup,

    In your  case, I would start with simpleBLEPeripheral and not enable the periodic clock. You can then cherry-pick in the driver changes needed to support your product's external sensors.

    Best wishes

  • 0 in reply to JXS
    Expert 1920 points
    Thanks JXS,

    We will try to do it in your suggested manner once we have complete confidence of the SensorTag project code.
  • 0 in reply to Anup Rajput
    Intellectual 780 points

    Hello,

    I saw this post and am struggling with the same thing. I realize the HW is for development/demo purposes, but I'm pretty sure there is further optimization to be had in the current setup.

    Here is a scope capture of what I'm seeing. 

    The green circles are the advertisements, as scheduled at 2 second intervals.

    The red circles are blips I'm getting every 200ms or so. Not sure what it is as I've repurposed or deactivated all the timers. Any idea on what they could be in the SensorTag code?

    Also, the baseline current is running at about 3mA. Still seems higher than it should be an inactive MCU and idling sensors.

    Would be great to get some input!

    Thanks,

    Nishant