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.

Excess Power Consumption during advertising mode

Other Parts Discussed in Thread: CC2541, ASH

Hi All,

We are developing a project based on TI's CC2541 Keyfob reference design, that communicates with the App on iOS/Android devices.

We are facing with excess power consumption problem during advertising state.

We referred some of the links available on the TI forum regarding the same issue and made necessary changes to our code, but still its consuming more power.

We have compared the current consumption of our device in connected state with the one mentioned in the TI's Keyfob Application Note and the average current consumption was almost equal but in advertising state its consuming more power.

I am attaching the power consumption comparison chart for Keyfob and our device in connected state.

              Image 1:  power consumption comparison chart for Keyfob and our device in connected state

I am also attaching the waveforms obtained  while testing  for our device along with the  TI's reference waveform.

Connected State

              Image 2: Wave forms obtained in Connected State for our Device 'vs' Keyfob reference design

The obtained wave form looks similar to the TI's reference wave form if it was in connected state with our App.

Advertising State

In advertising State, its different from the Reference design, it consumes nearly 8mAh power while advertising and consumes even more during connection event. 

            Image 3: Wave forms obtained in Advertising State for our Device 'vs' Keyfob reference design

                 Image 4: Wave form  showing default power consumption in Advertising State for our Device 

This image clearly shows that by default it consumes 8mAh during advertising and consumes even more power during connection intervals. Hence, our device consumes more power in advertising mode that reduces the battery life.

Kindly, check the above details and suggest us the required solution to reduce the power consumption during Advertising state.

Additional details for your reference

We are using CR1632 (3V, 140mAmp) coin cell for our device

Connection Parameters for our device are as follows

Min connection interval:           100 mSec
Max connection interval:          1 Sec
Slave Latency:                             0
Time out:                                       5 Sec
 
We think that the device was not going to sleep with in the advertising events causing excess power consumption
 
/**********Connection parameters and advertising intervals section of our code for your reference***********/

// Use limited discoverable mode to advertise for 30.72s, and then stop, or
// use general discoverable mode to advertise indefinitely
//#define DEFAULT_DISCOVERABLE_MODE GAP_ADTYPE_FLAGS_LIMITED
#define DEFAULT_DISCOVERABLE_MODE GAP_ADTYPE_FLAGS_GENERAL

// Minimum connection interval (units of 1.25ms, 80=100ms) if automatic parameter update request is enabled
#define DEFAULT_DESIRED_MIN_CONN_INTERVAL 80

// Maximum connection interval (units of 1.25ms, 800=1000ms) if automatic parameter update request is enabled
#define DEFAULT_DESIRED_MAX_CONN_INTERVAL 800

// Slave latency to use if automatic parameter update request is enabled
#define DEFAULT_DESIRED_SLAVE_LATENCY 0

// Supervision timeout value (units of 10ms, 1000=10s) if automatic parameter update request is enabled
#define DEFAULT_DESIRED_CONN_TIMEOUT 500

// Whether to enable automatic parameter update request when a connection is formed
#define DEFAULT_ENABLE_UPDATE_REQUEST TRUE

// By setting this to zero, the device will go into the waiting state after
// being discoverable for 30.72 second, and will not being advertising again
// until the enabler is set back to TRUE
uint16 gapRole_AdvertOffTime = 0;

uint8 enable_update_request = DEFAULT_ENABLE_UPDATE_REQUEST;
uint16 desired_min_interval = DEFAULT_DESIRED_MIN_CONN_INTERVAL;
uint16 desired_max_interval = DEFAULT_DESIRED_MAX_CONN_INTERVAL;
uint16 desired_slave_latency = DEFAULT_DESIRED_SLAVE_LATENCY;
uint16 desired_conn_timeout = DEFAULT_DESIRED_CONN_TIMEOUT;

// Set the GAP Role Parameters
GAPRole_SetParameter( GAPROLE_ADVERT_ENABLED, sizeof( uint8 ), &initial_advertising_enable );
GAPRole_SetParameter( GAPROLE_ADVERT_OFF_TIME, sizeof( uint16 ), &gapRole_AdvertOffTime );

GAPRole_SetParameter( GAPROLE_SCAN_RSP_DATA, sizeof ( deviceName ), deviceName );
GAPRole_SetParameter( GAPROLE_ADVERT_DATA, sizeof( advertData ), advertData );

GAPRole_SetParameter( GAPROLE_PARAM_UPDATE_ENABLE, sizeof( uint8 ), &enable_update_request );
GAPRole_SetParameter( GAPROLE_MIN_CONN_INTERVAL, sizeof( uint16 ), &desired_min_interval );
GAPRole_SetParameter( GAPROLE_MAX_CONN_INTERVAL, sizeof( uint16 ), &desired_max_interval );
GAPRole_SetParameter( GAPROLE_SLAVE_LATENCY, sizeof( uint16 ), &desired_slave_latency );
GAPRole_SetParameter( GAPROLE_TIMEOUT_MULTIPLIER, sizeof( uint16 ), &desired_conn_timeout );

GAP_SetParamValue(TGAP_GEN_DISC_ADV_INT_MIN , 1600);

GAP_SetParamValue(TGAP_GEN_DISC_ADV_INT_MAX , 1600);

/****************************************************************************************************************/

 
Please reply us if in case anymore details required in this regard.
Update: 
We are sure that its not an issue with our hardware as we tried with the default keyfob code and it was consuming power as per the TI guidelines  in both connected as well as in advertising state.
Its definitely an issue with the coding part.
  • Hello,

    The 8mA is most likely a result of you not going to sleep PM2, I would check that you have POWER_SAVING and are entering osal_pwrmgr_powerconserve. Note, that having debugger hooked up will keep CPU awake, so you will get higher current readings, but it will still go through sleep code states.

    BR,

    -Greg

  • Hi Greg,

    One of Krishna's colleague here. We have confirmed that Power saving feature is enabled- we are able to enter PM2 mode once connected to the iOS app -- that is why we are able to match TI's average current calculations. Just not able to enter sleep while advertising for some reason. We do not have any pending events that might prevent the processor from sleeping between advertising events. Also, I can confirm that the DUT is not connected to the debugger.

    Any specific advice would be helpful!! Many thanks!

    Abhishek

  • Hi Greg,

    The problem is resolved.

    Thanks for your support.

    Regards,

    Krishna

  • Can you share how you solved the issue?

  • Hi Kai,

    We had a timer and another event running-- which was preventing the processor from going into sleep. The processor will sleep only if no events and timers are pending!

    Hope that helps!

  • I am also running a timer with a value of 60s or 160s or 320s. The device goes to sleep. However I observed that sometimes the timer came in with half speed, e.g. 120s when it should be 60s. I fixed this behaviour by breaking up the timer in multiple <20s portions. The timer needs to be longer than the minimum sleep time defined in HAL_SLEEP.c in order to get the device to sleep.

    I still encounter loosing advertising... but thats on another thread.

    -Kai

  • Dear Kal Scheffer,
    I am a newbie for this and I am also facing the same problem, I guesss regarding timer calshing. may be because of this its not getting into sleep mode. But I am not sure about that. Could you please explain me how and where did you check this timer clashing and how did you modify the code to resolve it ?
    Hope to have a well explained reply from you~Thanks in advance,/Ash