BLE Low Power States

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
AnWa_1259496
Level 4
Level 4
Welcome! 50 replies posted 25 replies posted

I am trying to work out the power saving methodology for a HID device.

   

The power saving application note states that its possible to enter a low power mode while still maintaining the connection. It does not explain how to do this.

   

Ideally, the device would want to have an active mode, slow poll mode, idle mode and stop mode.

   

The HID Mouse RDK example does have these states so seems to be an ideal model. The first problem with this example is there are no comments at all in the main code body, so its quite difficult to work out whats going on.

   

In all states except stop, the CPU sleep is the same ie:

   

                if(CyBle_GetBleSsState() == CYBLE_BLESS_STATE_ECO_ON || 
                                CyBle_GetBleSsState() == CYBLE_BLESS_STATE_DEEPSLEEP)
                {
                    CySysPmDeepSleep();                

   

But this is (I think) waking the CPU every 10ms connection interval so there does not appear to be much difference between all the 3 states.

   

The questions I have are:

   

Is there another BLE mode which can be used which maintains the connection but consumes less power (a longer connection interval)?

   

Does the CPU have to be woken periodically when the connection is maintained (assuming no user task pending)?

   

In the code before CySysPmDeepSleep(); there is a CyGlobalIntDisable. How is the CPU even waking at all if interrupts are disabled. It definitely does though. Does this mean the BLE is waking it at the connection interval even if interrupts are disabled? 

   

I am getting approx 4 mA of current in all modes but that might be because I am only using a standard multimeter, maybe this is reading peaks only.

   

Thanks

0 Likes
1 Solution
Anonymous
Not applicable

Andy,

   

BLE specification, as you may know, defines a connection interval which both the master and slave accepts during the connection setup. This interval is (always) first set by master and may be requested to be updated by slave after the initial connection has been made.

   

So as part of the accepted interval and because both master and slave use high accuracy clock, know the time at which both of them should initiate a data transfer (or empty packet) to maintain the connection. All other times, both master and slave shutdown their radio and put CPU to low power mode. This way they achieve the low power consumption.

   

 

   

The wakeup source for system to maintain BLE connection is a internal LL timer running in the BLE block. It runs on WCO and counts the time that is set by the BLE stack. This time is the connection interval - time required to setup the radio before active transmission. Once the time is reached, the LL timer initiates an interrupt to the system causing the system to wakeup and BLE to be set for the upcoming connection event. So when your system wakes up after every 10 ms, it is due to this LL timer running the ~10 ms count.

   

Yes, CPU has to be woken to maintain the connection by starting up the BLE radio and Link Layer (LL). But as soon as the connection event is finished, the CPU can be put to deep sleep again and power can be conserved. That is why there is check for CyBle_GetBleSsState() before putting system to sleep or deep sleep.

View solution in original post

0 Likes
16 Replies
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

When you want to have a better look at the power consumption, I suggest using an oscilloscope. Add a shunt resistor (maybe 10 Ohms so you get 40mV for 4mA) to your power supply line, and trace it with a scope. That way you can have a better look at whats happening.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

These might be of help (AN92584) -

   

 

   

http://www.cypress.com/documentation/application-notes/an86233-psoc-4-low-power-modes-and-power-redu...         AN86233 - PSoC® 4 Low-Power Modes and Power Reduction Techniques

   

http://www.cypress.com/documentation/application-notes/an90114-psoc-4000-family-low-power-system-des...                         AN90114 - PSoC® 4000 Family Low-Power System Design Techniques

   

http://www.cypress.com/documentation/application-notes/an92584-designing-low-power-and-estimating-ba...                          AN92584 - Designing for Low Power and Estimating Battery Life for BLE Applications

   

 

   

http://video.cypress.com/video-library/search/psoc+4+low+power/

   

 

   

Regards, Dana

0 Likes
AnWa_1259496
Level 4
Level 4
Welcome! 50 replies posted 25 replies posted

Thanks Dana, I have read all these before but re-read AN92584 again. It doesnt explicitly say so but implies that the CPU will always be woken by the BLESS at the connection interval even when the BLESS is in DEEPSLEEP mode. So maybe no saving possible there.

   

There is a project referenced in this app note which is supposed to demonstrate low power modes, but there are no instructions on the project or in the code on how you actually run it and change modes. So not much help there. Seems like some data needs to be sent to it from the host but it doesnt say.

   

I will go back to the Mouse RDK and try to unravel what its doing and get a proper current measurement method set up. 

0 Likes
Anonymous
Not applicable

Andy,

   

BLE specification, as you may know, defines a connection interval which both the master and slave accepts during the connection setup. This interval is (always) first set by master and may be requested to be updated by slave after the initial connection has been made.

   

So as part of the accepted interval and because both master and slave use high accuracy clock, know the time at which both of them should initiate a data transfer (or empty packet) to maintain the connection. All other times, both master and slave shutdown their radio and put CPU to low power mode. This way they achieve the low power consumption.

   

 

   

The wakeup source for system to maintain BLE connection is a internal LL timer running in the BLE block. It runs on WCO and counts the time that is set by the BLE stack. This time is the connection interval - time required to setup the radio before active transmission. Once the time is reached, the LL timer initiates an interrupt to the system causing the system to wakeup and BLE to be set for the upcoming connection event. So when your system wakes up after every 10 ms, it is due to this LL timer running the ~10 ms count.

   

Yes, CPU has to be woken to maintain the connection by starting up the BLE radio and Link Layer (LL). But as soon as the connection event is finished, the CPU can be put to deep sleep again and power can be conserved. That is why there is check for CyBle_GetBleSsState() before putting system to sleep or deep sleep.

0 Likes
SanthoshV_71
Employee
Employee
First like received First like given Welcome!

Hi Andy,

   

>> Is there another BLE mode which can be used which maintains the connection but consumes less power (a longer connection interval)?

   

Response: For mouse RDK BLE connection interval is set to 7.5 ms and slave latency is set to 80.

   

                  It means BLE activity occurs every 600 ms (7.5 * 80) if there is no activity. Connection interval of 7.5 ms is mandatory as HID
                   Mouse should meet atleast 125 Hz report rate, slave latency can be varied to save power. 

   

>> Does the CPU have to be woken periodically when the connection is maintained (assuming no user task pending)?

   

Response: CPU can be in deep sleep state till next BLE event (in this case 600 ms away), BLE will trigger an interrupt before next anchor
                  point.

   

I am getting approx 4 mA of current in all modes but that might be because I am only using a standard multimeter, maybe this is reading peaks only.

   

Response: You should use 6 1/2 Digit multimeter

   

                  Refer section   "3.3 Average Current Measurement" of  " http://www.cypress.com/file/140991/download" regarding Average                       current measurement setup for BLE applications.

   

 

   

Thanks,
Santhosh.

ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

This might be useful -

   

 

   

https://www.youtube.com/watch?v=ynObUvO8HZc

   

 

   

Regards, Dana.

0 Likes
AnWa_1259496
Level 4
Level 4
Welcome! 50 replies posted 25 replies posted

Something very strange is going on with these low power states.

   

In the end I bought an Agilent 34401A meter. I tried measuring using two methods, firstly setting the resolution to 6 digit, slow, which gives an integration time of approx 3 seconds, and also by using math mode and setting the resolution to 4 digit fast, which gives about 10 readings per second, and taking an average of 5000 readings.

   

I used the actual Touch Mouse RDK and connected the meter to the current-measuring jumper which powers only the BLE, not the optical sensor etc.

   

If I start out from scratch with the mouse not paired to the Windows host and not present in device manager, then pair the device, everything seems fine. I am getting reasonable current readings which are:

   

active: 4.5 mA

   

idle: 0.7 mA

   

sleep: 0.08 mA

   

But if the mouse is powered off and on, and it re-pairs with the host (bonding is enabled), the current readings thereafter are:

   

active: 5.7 mA

   

idle: 2.2 mA

   

sleep: 1.7 mA

   

So the measuring method is working. I am getting the same high readings in my own application which is not a surprise as its based on the same power-state logic as the RDK.

   

I will raise a case for this.

0 Likes
AnWa_1259496
Level 4
Level 4
Welcome! 50 replies posted 25 replies posted

I found out what was going wrong with the power states. I am using as a test host the very popular CSR-based USB dongle and the CSR Harmony Windows stack.

   

The mouse RDK updates the connection parameters on change of power state, but in all states the connection interval is set to 6 which equates to 7.5ms.

   

The host is returning a status of "Invalid Parameter" on this request. After it does this, the host appears to use an arbitrary set of parameters which result in high power consumption.

   

The only connection interval which works is 10 (12.5 mS). This returns a good result. The slave latency can be varied without any problem.

   

The issue here is that other hosts might have other connection interval requirements, and I assume its not possible to change the slave latency only, without sending the whole structure which includes the connection interval. I dont think its possible to read the current connection interval. In fact what connection interval is being used when the device first connects, before a parameter update is sent?  

0 Likes
Anonymous
Not applicable

"...In fact what connection interval is being used when the device first connects, before a parameter update is sent?  "

   

->The connection interval used when the connection is first set is decided by the central device. This could be iOS, Android, CySmart PC Tool or any other dongle. So the actual connection interval set varies from device to device.

   

For iOS, connection interval set is 30 ms

   

For Android, connection interval set is 50 ms (except there is another wrapper over the Android core that modifies the value)

   

For CySmart PC Tool, it is about 8.5 ms.

   

You need to check the device information to find out that connection interval it would set. Also, as you noted, some of these Central devices have their own restriction of the connection interval/slave latency and may not accept all the connection parameter update request from the connected slave device.

   

One discussion is here: 

   

http://stackoverflow.com/questions/22514333/bluetooth-low-energy-connection-parameters-for-android-i... 

0 Likes
AnWa_1259496
Level 4
Level 4
Welcome! 50 replies posted 25 replies posted

Thanks for this. I have been experimenting and the CSR stack can accept a range of values of 12.5 mS and above, and Android seems very flexible on values. But I cant get any values to work at all with IOS. I have tried exactly the values Apple specify, plus other variants and all values result in the event CYBLE_EVT_L2CAP_CONN_PARAM_UPDATE_RSP returning "Invalid Parameter".

   

So, either Apples BLE stack is not working as per spec, or the Cypress stack has a bug in CyBle_L2capLeConnectionParamUpdateRequest. 

   

I have a hunch its the latter and its sending the same values for min and max, which is acceptable on Android but Apple wants them to be separated by 20mS.

   

Creating a case now.

0 Likes
Anonymous
Not applicable

Andy,

   

In case you have not, can you give the requirements for iOS BLE connection interval a look here (section 3.6)?

   

https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf

   

I have tried with few values myself and those seem to work. The CY8CKIT-042-BLE Kit peripheral example projects also use a common connection parameter update value that works along all iOS, Android and CySmart PC Tool.

0 Likes
AnWa_1259496
Level 4
Level 4
Welcome! 50 replies posted 25 replies posted

Thats the document I am using. So this is strange. Can you give me an example of some working values on iOS?

   

With your working values does the event CYBLE_EVT_L2CAP_CONN_PARAM_UPDATE_RSP return a zero? Thats the only way to tell if the update worked as the connection is still maintained with non-working values.

0 Likes
Anonymous
Not applicable

Following are the values from the CY8CKIT-042-BLE Pioneer kit example project on CapSense Proximity:

   

 

   

/* Minimum connection interval = CONN_PARAM_UPDATE_MIN_CONN_INTERVAL * 1.25 ms*/
#define CONN_PARAM_UPDATE_MIN_CONN_INTERVAL    40      

   

     
/* Maximum connection interval = CONN_PARAM_UPDATE_MAX_CONN_INTERVAL * 1.25 ms */
#define CONN_PARAM_UPDATE_MAX_CONN_INTERVAL    42    

   

       
/* Slave latency = Number of connection events */
#define CONN_PARAM_UPDATE_SLAVE_LATENCY        4          

   


/* Supervision timeout = CONN_PARAM_UPDATE_SUPRV_TIMEOUT * 10*/
#define CONN_PARAM_UPDATE_SUPRV_TIMEOUT        200      

0 Likes
AnWa_1259496
Level 4
Level 4
Welcome! 50 replies posted 25 replies posted

Those values dont work either unfortunately. 

0 Likes
AnWa_1259496
Level 4
Level 4
Welcome! 50 replies posted 25 replies posted

Ok I found what the problem is. There is an error in the RDK source as follows:

   

#define BLE_ACTIVE_SUPERVISION_TIMEOUT                  (3000u)   /* 3 sec */

   

This is incorrect because this figure is in tens of milliseconds so the correct value for the 3 sec value in the comment is actually 300u. 

   

3000u does not work presumably because its too long.

   

However the min/max values in the capsense proximity example definitely wont work because they are outside the Apple spec which requires 20 ms difference.

0 Likes
AnWa_1259496
Level 4
Level 4
Welcome! 50 replies posted 25 replies posted

Experimenting some more, what is annoying is iOS has different limitations from other hosts, in particular a max slave latency of 4. It allows very long connection intervals though. 

   

Conversely Windows hosts allow a much higher slave latency value but a relatively low limit on connection interval.

   

So to maximise power saving two sets of parameters need to be used depending on which host its connected to.

0 Likes