AN92584
Designing for Low Power and Estimating Battery Life for BLE Applications
Authors: Uday Agarwal, Kunal Patel, Vikram, Prathap Reddy, Santosh S
Associated Project: Yes
Associated Part Family: CY8C4xx7-BL, CY8C4xx8-BL, CYBL10X6X, CYBL10X7X
®
Software Version: PSoC Creator™ 3.2
Related Application Notes: AN91267, AN94020
To get the latest version of this application note, or the associated project file, please
visit http://www.cypress.com/go/AN92584
AN92584 teaches you how to design low-power applications with PSoC 4/PRoC™ BLE devices. It also guides you on
how to compute the current consumption and battery life for a BLE application and provides tips and tricks to minimize
the current consumption to increase battery life.
Contents
1
2
Introduction ...............................................................1
Design and Implementation for Low-Power BLE ......2
2.1
System Clocks .................................................2
2.2
System Power Modes ......................................3
2.3
BLE Subsystem Power Modes ........................4
2.4
Recommendations for Low Power ...................5
2.5
Low-Power Implementation .............................6
3
Example Projects.................................................... 15
3.1
Example Project 1: Low-Power Modes in
Advertisement ................................................ 15
3.2
Example Project 2: Low-Power Modes in
Connection..................................................... 15
3.3
Average Current Measurement ...................... 16
3.4
Power Calculator ........................................... 21
1
4
BLE Applications .................................................... 22
4.1
BLE System Power ........................................ 22
4.2
Battery Life .................................................... 23
4.3
Techniques for Increasing Battery Life .......... 25
4.4
Example Application: Heart-Rate Monitor ...... 27
4.5
Example Application: Remote Control ........... 28
4.6
Implementing System Design
Recommendations ......................................... 31
5
Summary ................................................................ 33
6
Appendix A: Advertising State Current Profile ........ 34
7
Appendix B: Connection State Current Profile........ 38
Document History............................................................ 41
Worldwide Sales and Design Support ............................. 42
Introduction
Bluetooth Low Energy (BLE) devices such as heart-rate monitors are typically battery operated. A long battery life is a
key requirement for such devices. This application note shows how to implement a low-power solution and estimate
the battery life for the device using Cypress’s BLE solutions.
Before you read this document, you should have a basic knowledge of BLE and have read the Getting Started with
PSoC 4 BLE or Getting Started with PRoC BLE application notes.
This application note is divided into two sections. The first section guides you in implementing low-power BLE
solutions using PSoC 4/PRoC BLE devices. It first provides an overview of the clocks and low-power modes available
in these devices. It then explains how to manage the clocks and the power modes in your application to reduce
current consumption. The implementation is illustrated in the example projects provided with this application note. A
procedure to measure the average current in the CY8CKIT-042-BLE Bluetooth Low Energy (BLE) Pioneer Kit is also
discussed. A power calculator tool provided with this application note makes it easy for you to estimate the current
consumption for a given configuration of the device.
www.cypress.com
Document No. 001-92584 Rev. *A
1
Designing for Low Power and Estimating Battery Life for BLE Applications
The second section provides a system-level view of a BLE device and shows how to estimate its battery life. Tips and
tricks to reduce the average current consumption and improve the battery life are discussed and illustrated with the
help of two example use-cases: a heart-rate monitor and a remote control. The current consumption in the non-BLE
parts of the system and the idle time between BLE operations adds significantly to the average current consumption.
2
Design and Implementation for Low-Power BLE
It is important that you first understand the different clocks and power modes available in PSoC 4/PRoC BLE devices
that should be managed to conserve power.
2.1
System Clocks
The PSoC 4/PRoC BLE clock system includes the following clock sources:
Two internal clock sources:
3-MHz to 48-MHz internal main oscillator (IMO) ±2 percent across all frequencies with trim
32-kHz internal low-speed oscillator (ILO) ±60 percent with trim
Three external clock sources:
External clock (EXTCLK) generated using a signal from an I/O pin
24-MHz external crystal oscillator (ECO)
32-kHz watch crystal oscillator (WCO)
The five clock sources and the clocks derived from these sources are shown in Figure 1.
Figure 1. PSoC 4/PRoC BLE System Clocks
WCO
ILO
ECO
Low-Frequency Clock to WDT, BLE LowPower Logic, LCD, CPU Timer and UDB
LFCLK
To BLE Link Layer
LLCLK
To Flash and Peripherals that
Need Specific Divided Clock
HFCLK
Prescaler
/2n (n=0..2)
Divider
/2n (n=0..3)
To CPU & Bus Interface
of Peripherals
Prescaler
/2n (n=0..7)
SYSCLK
IMO
EXTCLK
Divider 0
/2n (n=0..16)
Clock Enables to SCB, CSD, TCPWM,
LCD, PASS & UDB to Divide HFCLK
0-9
Divider 9
/2n (n=0..16)
Fractional Divider0
/( 2m+(2n-1)/2n )
(m=0..16, n=0..5)
PER0_CLK
Fractional Divider1
/( 2m+(2n-1)/2n )
(m=0..16, n=0..5)
PER15_CLK
Table 1 summarizes the clock sources, their use in the system, and specific system constraints on them. The table
also lists the APIs that are used to turn ON or OFF the clock sources.
www.cypress.com
Document No. 001-92584 Rev. *A
2
Designing for Low Power and Estimating Battery Life for BLE Applications
Table 1. System Clocks
Clock
Source
Frequency
IMO
3 MHz -48 MHz
System Requirements
Used to run the CPU and all other
peripherals
System Constraints
Either the IMO or ECO is required ON – CySysClkImoStart()
to run the CPU.
The CPU must use the IMO while
performing flash write operations.
ECO
24 MHz
Used by BLE subsystem (BLESS) for
packet transmissions and reception.
32 kHz
ILO
32 kHz
OFF – CySysClkImoStop()
Either the IMO or ECO is required ON – CySysClkEcoStart()
to run the CPU.
Can also be used to run the CPU
WCO
APIs
OFF – CySysClkEcoStop()
Used by BLESS to maintain link
timing. Can also be used to run the
watchdog timer
Either the WCO or ILO is required ON – CySysClkWcoStart()
to run the watchdog timer.
Can be used to run the watchdog
timer if WCO is not available
The ILO cannot be used for
BLESS link timing.
OFF – CySysClkWcoStop()
ON – CySysClkIloStart()
OFF – CySysClkIloStop()
2.2
System Power Modes
PSoC 4/PRoC BLE devices support five system power modes. Table 2 summarizes these modes, their currents,
active components, wakeup sources, and the APIs available to put the system into one of the low-power modes.
Table 2. System Power Modes
System
Current
Code
RAM
Digital
Analog
Clock
Power Consumption Execution Available Peripherals Peripherals Sources
Mode
Available
Available Available
Wakeup
Sources
Wakeup Wakeup
Time
State
API
Yes
ON
All
All
All
–
–
–
–
No
Retention All
All
All
Any
interrupt
source
0
Active
CySysPmSleep()
1.3 µA
No
Retention WDT1,
LCD2,
SCB(I2C/SPI
only),
BLESS3
LP
WCO6,
Comparator, ILO7
CTBm11,
POR4,
BOD5
LP
25 µs
Comparator,
GPIO8,
CTBm,
BLESS3,
WDT, SCB9
Active
CySysPmDeepSleep()
Hibernate 150 nA
No
Retention No
LP
None
Comparator,
POR, BOD
LP
2 ms
Comparator,
GPIO
Chip
Reset
CySysPmHibernate()
Stop
No
OFF
No
WAKEUP, 2 ms
XRES10 pins
Chip
Reset
CySysPmStop()
Active
850 µA +
260 µA per
MHz
Sleep
850 µA +
60 µA per
MHz
DeepSleep
1
2
3
60 nA
No
Watchdog timer
4
Liquid crystal display
5
BLE subsystem
10
External reset
www.cypress.com
None
7
32-kHz internal low-speed oscillator
Brownout detect
8
General-purpose input/output
6
32-kHz watch crystal oscillator
9
11
Continuous time block mini
Power-on reset
Document No. 001-92584 Rev. *A
Serial communication block
3
Designing for Low Power and Estimating Battery Life for BLE Applications
2.3
BLE Subsystem Power Modes
In addition to the system power modes, PSoC 4/PRoC BLE devices support three BLESS power modes. Table 3
summarizes them, their active components, and their mapping to the internal states of the BLESS while being in
these power modes.
The BLESS power modes directly map to the input parameters of the CyBle_EnterLPM() API that is used to put
the BLESS into the specific power mode.
The BLESS internal states directly map to the states returned from the Get_Blessstate()API.
The BLESS DEEPSLEEP and SLEEP modes are entered under application control. The exit may be initiated in
one of two ways:
o
The application calls the CyBle_EnterLPM() function with the input parameter as ACTIVE.
o
The BLESS internally triggers the exit at a time determined by the BLE stack within the BLE Component.
Upon exit from the DEEPSLEEP or SLEEP mode, the BLESS enters the ACTIVE mode.
The CYBLE_BLESS_STATE_ECO_ON and CYBLE_BLESS_STATE_ECO_STABLE states are entered for a
short duration (up to a 1-ms period) while the BLESS is transitioning from the DEEPSLEEP mode to the ACTIVE
mode.
Table 3. BLESS Power Modes
BLESS
Power Mode
BLESS Internal States
BLESS Operation
DEEPSLEEP CYBLE_BLESS_STATE_DEEPSLEEP
Idle. Maintain link.
BLESS
Radio Clock
OFF
BLESS
Link
Timing
Clock
Source
WCO
ECO
OFF
Internal
State
Entry
Control
CPU
Allowed
System
Power
Modes
Deep-Sleep
Sleep
Active
CYBLE_BLESS_STATE_ECO_ON
ECO startup and
amplitude
stabilization
CYBLE_BLESS_STATE_ECO_STABLE
SLEEP
CYBLE_BLESS_STATE_SLEEP
OFF
WCO
ON
BLESS
Deep-Sleep
Sleep
Active
ECO frequency
OFF
stabilization and BLE
timing
synchronization
WCO
Idle. Maintain link.
ECO
OFF
ON
BLESS
Sleep
Active
ON
CPU
Sleep
Active
ACTIVE
CYBLE_BLESS_STATE_ACTIVE
Idle. Maintain link.
OFF
ECO
ON
CPU
Sleep
Active
CYBLE_BLESS_STATE_ACTIVE
Transmit
ON
ECO
ON
BLESS
(Transmitter)
CYBLE_BLESS_STATE_ACTIVE
Receive
ON
Active
ECO
ON
BLESS
(Receiver)
CYBLE_BLESS_STATE_EVENT_CLOSE Enter Deep-Sleep
mode.
www.cypress.com
OFF
Document No. 001-92584 Rev. *A
Sleep
Sleep
Active
ECO
ON
BLESS
Active
4
Designing for Low Power and Estimating Battery Life for BLE Applications
The WCO clock source must be ON to use the DEEPSLEEP mode to maintain the BLE link timing during the
DEEPSLEEP mode. The WCO may be turned OFF if BLE is not used or the BLESS DEEPSLEEP power mode is not
used.
The system can be in the Sleep or Active power modes during the BLESS SLEEP and ACTIVE power modes. It can
be put into the Deep-Sleep mode only when the BLESS is in the DEEPSLEEP mode and the BLESS link layer and
modem logic are not using the ECO clock. To ensure that invalid combinations of the system and BLESS modes are
not entered, the application should check the BLESS internal state first and then put the system into the appropriate
low-power mode.
2.4
Recommendations for Low Power
The user application should manage the system clocks, system power modes, and BLESS power modes to
implement a low-power design in PSoC 4/PRoC BLE devices.
The recommendations for implementing low-power designs (see Figure 2) are as follows:
The BLESS should be put into the DEEPSLEEP mode between BLE events. The system should be put into the
Deep-Sleep mode during this time if there is no pending application processing.
The system should be put into the Sleep mode when the BLESS is in the ACTIVE or SLEEP modes if no
application processing is required. The system can also be put into the Sleep mode when the BLESS is in the
CYBLE_BLESS_STATE_ECO_STABLE state.
If the system is in the Sleep mode while the BLESS is in the ACTIVE or SLEEP modes, the ECO clock source
should be used for the CPU clock. This allows the IMO to be turned OFF to reduce current consumption.
If the ECO is used in the system Sleep mode, the ECO clock should be divided down from 24 MHz to 3 MHz.
The 3-MHz frequency is enough to keep the system in the Sleep mode and switch back to the IMO clock when
the system exits the Sleep mode.
The WCO must be selected with a low ppm variation. You should further tune it to reduce the ppm variation. A
lower ppm reduces the listening window time in the BLE Peripheral role, thus reducing the current consumed.
Refer to AN95089 – PSoC 4/PRoC BLE Crystal Oscillator Selection and Tuning Techniques for details on WCO
crystal tuning.
If your application does not use the ILO, the ILO should be stopped to reduce current consumption.
Figure 2. Low-Power Implementation Recommendations
Interval between BLE events
ECO Stable
Active
BLE
Event
ECO ON
BLE
Event
Event Close
Deep-Sleep
Deep-Sleep
BLE Activity
Active or Sleep
Sleep
Active or Deep-Sleep
Deep-Sleep
A
B
Active or Sleep
A
Application pre-processing
B
Application post-processing
Deep-Sleep
System Activity
ECO
WCO
www.cypress.com
Document No. 001-92584 Rev. *A
5
Designing for Low Power and Estimating Battery Life for BLE Applications
2.5
Low-Power Implementation
This section discusses how to implement the low-power-mode recommendations in your BLE project. It involves two
steps:
2.5.1
1.
Configure your project in PSoC Creator™.
2.
Implement the recommendations in your application code.
PSoC Creator Configuration
The following configurations should be implemented in your project to ensure a low-power operation.
Low-Frequency Clock (LFCLK) Selection
The LFCLK in the system must be set to use the WCO to operate the BLESS in the DEEPSLEEP mode.
1.
Access this setting in the Clocks tab of the .cydwr file in your project.
2.
Click Edit Clock to open the Configure System Clocks window, as shown in Figure 3.
3.
Go to the Low Frequency Clocks tab.
4.
Confirm that the WCO tab is selected and the WCO is selected as LFCLK.
5.
Close the window.
Figure 3. LFCLK Setting
WCO Power Mode
The WCO supports two modes of operation: low power and high power. The high-power mode is required for a fast
start up of the oscillator block upon power up of the chip. After the oscillation has stabilized, the WCO must be set to
operate in the low-power mode to reduce current consumption.
1.
Access this setting under the Clocks tab of the .cydwr file.
2.
Click Edit Clock to open the Configure System Clocks window, as shown in Figure 4.
3.
Go to the Low Frequency Clocks tab.
www.cypress.com
Document No. 001-92584 Rev. *A
6
Designing for Low Power and Estimating Battery Life for BLE Applications
4.
Select the Low Power option.
5.
Close the window.
Figure 4. WCO Low-Power Mode Settings
BLE Component Deep-Sleep Mode
The Use BLE low power mode button in the BLE Component customization window must be selected to use the
BLESS DEEPSLEEP mode. This setting is available in the General tab of the BLE Component configuration, as
shown in Figure 5. If this setting is selected, the WCO must be configured as the LFCLK source in the Design-Wide
Resources (DWR) Clock Editor, as shown in Figure 3. If the WCO is not configured for LFCLK and this button is
selected, then an error is reported when you build the project.
www.cypress.com
Document No. 001-92584 Rev. *A
7
Designing for Low Power and Estimating Battery Life for BLE Applications
Figure 5. Deep Sleep Setting for BLE Component
Stop Mode
If you are using the Stop mode in your application, make sure that the WAKEUP pin is configured correctly to exit the
Stop mode successfully:
1.
Configure P2.2 as the WAKEUP pin.
2.
Set the WAKEUP pin active HIGH or active LOW as required by your application.
Setting the WAKEUP pin to the configured level will cause the device to wake up from the Stop mode. The WAKEUP
pin is active LOW by default.
SWD Pin Configuration
SWD pins are used for runtime firmware debug during development stages. Configuring the SWD pins for debug
increases the current consumption. Therefore, in the production release, SWD pins should be switched to the GPIO
mode. They will still be available for programming the device upon chip reset.
1.
Go to the System tab in the .cydwr file.
2.
Click Debug Select under Programming\Debugging, as shown in Figure 6.
3.
Change the value to GPIO.
www.cypress.com
Document No. 001-92584 Rev. *A
8
Designing for Low Power and Estimating Battery Life for BLE Applications
Figure 6. Debug Pin Setting
2.5.2
I m p l e m e n t i n g L o w - P o w e r O p e r a t i o n s i n Ap p l i c a t i o n C o d e
The implementation is divided into three functional blocks in your application:
System initialization and main loop
BLE stack event handler
Power management functions
System Initialization and Main Loop
After a power on or reset, the system initializes various components by calling the respective start functions. The
following steps are performed at initialization for a low-power operation. Refer to the code snippet with comments
(comments are labeled with “C<number>”) for the reference implementation.
[C1] Stop the ILO to reduce current consumption.
[C2] Configure the divider values for the ECO so that a 3-MHz ECO divided clock can be provided to the CPU in
the Sleep mode. The clock to the CPU is switched from the IMO to the ECO before entering the Sleep mode.
The ECO-derived clock is available when the CPU wakes up from the Sleep mode.
[C3] In the main while loop, call the function CyBle_EnterLPM()() to put the BLESS into the DEEPSLEEP
mode soon after the BLE event processing is completed. Note that this function will internally check the BLESS
conditions if it can enter the DEEPSLEEP mode. Therefore, no check is required before calling this function.
[C4, C5] If the system is active, run your application as illustrated by calling the run_application()function
[C4].
Once the application completes all its tasks, check if it is ready to enter a low-power mode. The
application can enter a low-power mode if all the non-BLE components used in the application are idle. The
application should enter the Sleep mode if some of the components need the high-frequency clock (ECO or IMO)
to wake up the system. The application should enter the Deep-Sleep mode if the clock to all the components can
be shut down. This is done by setting a flag (called applicationPower in the code) to SLEEP or
DEEPSLEEP. The flag is used by the ManageApplicationPower() function to put the components into the
Sleep or Deep-Sleep modes. Note that the definition of the Sleep and Deep-Sleep modes are applicationspecific. Refer to the function definition of run_application()for a reference implementation [C5].
www.cypress.com
Document No. 001-92584 Rev. *A
9
Designing for Low Power and Estimating Battery Life for BLE Applications
[C6] Call the ManageApplicationPower()
application-specific, non-BLE components.
[C7] Call the ManageSystemPower()function. The function checks both the application power mode and the
BLESS power mode to put the entire system into the Sleep or Deep-Sleep mode.
function to manage the power mode transitions for the
int main()
{
/* Variable declarations */
CYBLE_LP_MODE_T lpMode;
CYBLE_BLESS_STATE_T blessState;
uint8 interruptStatus;
/* Enable global interrupts */
CyGlobalIntEnable;
/* C1. Stop the ILO to reduce current consumption */
CySysClkIloStop();
/* C2. Configure the divider values for the ECO, so that a 3-MHz ECO divided
clock can be provided to the CPU in Sleep mode */
CySysClkWriteEcoDiv(CY_SYS_CLK_ECO_DIV8);
/* Start the BLE Component and register the generic event handler */
apiResult = CyBle_Start(AppCallBack);
/* Wait for BLE Component to initialize */
while (CyBle_GetState() == CYBLE_STATE_INITIALIZING)
{
CyBle_ProcessEvents();
}
/*Application-specific Component and other initialization code below */
applicationPower = ACTIVE;
/* main while loop of the application */
while(1)
{
/* Process all pending BLE events in the stack */
CyBle_ProcessEvents();
/* C3. Call the function that manages the BLESS power modes */
CyBle_EnterLPM(CYBLE_BLESS_DEEPSLEEP);
/*C4. Run your application specific code here */
if(applicationPower == ACTIVE)
{
RunApplication();
}
/*C6. Manage Application power mode */
ManageApplicationPower();
/*C7. Manage System power mode */
ManageSystemPower();
}
}
/****************************************************************************
* C5. Function Name: RunApplication()
*****************************************************************************
*
* Summary:
*
This function is a template to run Application-specific code.
www.cypress.com
Document No. 001-92584 Rev. *A
10
Designing for Low Power and Estimating Battery Life for BLE Applications
*
* Parameters:
* none
*
****************************************************************************/
inline void RunApplication()
{
/***********************************************************************
* Place your application code here
************************************************************************/
/* if you are done with everything and ready to go to sleep,
then set it up to go to sleep. Update the code inside if() specific
to your application*/
if(0)
{
applicationPower = SLEEP;
}
/* if you are done with everything and ready to go to deepsleep,
then set it up to go to deepsleep. Update the code inside if() specific
to your application*/
if (1)
{
applicationPower = DEEPSLEEP;
}
}
BLE Stack Event Handler
The BLE stack event handler function handles the events generated by the BLE stack. Employ the following lowpower techniques in the event-handling section soon after the BLE stack is initialized (an EVT_STACK_ON event is
received):
[C8] Set the device sleep-clock accuracy (SCA) based on the tuned ppm of the WCO. The SCA is defined by the
Bluetooth specifications in seven subranges in the total range of 0 ppm to 500 ppm.
The code snippet for these is shown below:
void AppCallBack(uint32 event, void* eventParam)
{
CYBLE_BLESS_CLK_CFG_PARAMS_T clockConfig;
switch(event)
{
/* Handle stack events */
case CYBLE_EVT_STACK_ON:
/* C8. Get the configured clock parameters for BLE subsystem */
CyBle_GetBleClockCfgParam(&clockConfig);
/* C8. Set the device sleep-clock accuracy (SCA) based on the tuned ppm
of the WCO */
clockConfig.bleLlSca = CYBLE_LL_SCA_000_TO_020_PPM;
/* C8. Set the clock parameter of BLESS with updated values */
CyBle_SetBleClockCfgParam(&clockConfig);
/* Put the device into discoverable mode so that a Central device can
www.cypress.com
Document No. 001-92584 Rev. *A
11
Designing for Low Power and Estimating Battery Life for BLE Applications
connect to it. */
apiResult = CyBle_GappStartAdvertisement(CYBLE_ADVERTISING_FAST);
/* Application-specific event handling here */
break;
/* Other application-specific event handling here */
case CYBLE_EVT_GAP_DEVICE_CONNECTED:
}
}
Power Management Functions
The power management functions control the application and system power mode transitions.
Application Power Management
The function ManageApplicationPower() manages the power state transitions for all the components used by
the application, except the BLE Component. Five application power states are defined. You should customize this
function for your application.
The ACTIVE power state indicates that the application is active. There is no specific action required when the
application is active.
The WAKEUP_SLEEP and WAKEUP_DEEPSLEEP states indicate that the system is waking up from the Sleep or
Deep-sleep mode, respectively. The application should also wake up the components from their Sleep or DeepSleep modes.
The SLEEP and DEEP SLEEP states are entered when the application has completed all application processing and
is requested at the end of it to enter the Sleep or Deep-Sleep modes. The non-BLE components used by the
application are put into their respective Sleep or Deep-Sleep modes. Note that the definition of the Sleep and DeepSleep are application-specific.
void ManageApplicationPower()
{
switch(applicationPower)
{
case ACTIVE: // don’t need to do anything
break;
case WAKEUP_SLEEP: // do whatever wakeup needs to be done
applicationPower = ACTIVE;
break;
case WAKEUP_DEEPSLEEP: // do whatever wakeup needs to be done.
applicationPower = ACTIVE;
break;
case SLEEP:
/***********************************************************************
* Place code to place the application components to sleep here
************************************************************************/
break;
case DEEPSLEEP:
/***********************************************************************
www.cypress.com
Document No. 001-92584 Rev. *A
12
Designing for Low Power and Estimating Battery Life for BLE Applications
* Place code to place the application components to deepsleep here
************************************************************************/
break;
}
}
System Power Management
The application should call the ManageSystemPower() function to put the system into low-power modes. The
function puts the system into the allowed low-power modes as follows:
[C9] Get the current internal state of the BLESS by calling the CyBle_GetBleSsState()function.
[C10, C11] If the BLESS is in the DEEPSLEEP mode and the non-BLE application components are also in the
Deep-Sleep mode [C10], then put the system into the Deep-Sleep mode [C11]. The code execution halts here
until the system wakes up from the Deep-Sleep mode due to an interrupt.
[C12] If the BLESS does not enter the DEEPSLEEP mode, it is either because it is at the beginning or in the
middle of an event. The system can be put into the Sleep mode in this period except in the
CYBLE_BLESS_STATE_EVENT_CLOSE state.
[C13, C14, C15, C16] There are two possibilities about the application power mode under the above condition. If
the application is in the Deep-Sleep mode [C13], the system can use the ECO instead of the IMO as the clock
source in the Sleep mode. First, the HFCLK source is switched to the ECO and the IMO is stopped [C14]. The
system is then put into the Sleep mode [C15]. The code execution halts here until the system wakes up from the
Sleep mode due to an interrupt. The IMO is restarted upon wakeup and the clock source for HFCLK is reverted
to the IMO [C16].
[C17, C18] If the application is in the Sleep mode and requires the IMO [C17], then the system is put into the
Sleep mode [C18], without switching OFF the IMO.
Note 1: It is important that the code to handle the low-power transitions is protected in a critical section and that
interrupts are not allowed to change the thread of operation. In the code snippet, this critical section is bound by
the CyEnterCriticalSection() function at the beginning and the CyExitCriticalSection() function at
the end. If you do not put the code in this critical section, it may result in race conditions between the system and
the BLESS in entering the BLESS low-power modes, causing the device to enter an unknown state from which it
cannot recover.
Note 2: When you put the BLESS into the DEEPSLEEP mode in the application using the
CyBle_EnterLPM()function call, the ECO is configured to be OFF within the function. Therefore, the
application need not do an explicit ECO OFF. However, if you are not using the BLESS, then you need to
explicitly stop the ECO in the system if it is not required. This is because the system API call,
CySysPmDeepSleep(), will not turn OFF the ECO. This can be done by calling the
CySysClkEcoStop()API, described previously, just before putting the system into the Deep-Sleep mode.
The code snippet follows.
void ManageSystemPower()
{
/* Variable declarations */
CYBLE_BLESS_STATE_T blePower;
uint8 interruptStatus ;
/* Disable global interrupts to avoid any other tasks from interrupting this
section of
code*/
interruptStatus = CyEnterCriticalSection();
/* C9. Get current state of BLE sub system to check if it has successfully
www.cypress.com
Document No. 001-92584 Rev. *A
13
Designing for Low Power and Estimating Battery Life for BLE Applications
entered deep
sleep state */
blePower = CyBle_GetBleSsState();
/* C10. System can enter Deep-Sleep only when BLESS and rest of the application
are in
DeepSleep or equivalent power modes */
if((blePower == CYBLE_BLESS_STATE_DEEPSLEEP || blePower ==
CYBLE_BLESS_STATE_ECO_ON) &&
applicationPower == DEEPSLEEP)
{
applicationPower = WAKEUP_DEEPSLEEP;
/* C11. Put system into Deep-Sleep mode*/
CySysPmDeepSleep();
}
/* C12. BLESS is not in Deep Sleep mode. Check if it can enter Sleep mode */
else if((blePower != CYBLE_BLESS_STATE_EVENT_CLOSE))
{
/* C13. Application is in Deep Sleep. IMO is not required */
if(applicationPower == DEEPSLEEP)
{
applicationPower = WAKEUP_DEEPSLEEP;
/* C14. change HF clock source from IMO to ECO*/
CySysClkWriteHfclkDirect(CY_SYS_CLK_HFCLK_ECO);
/* C14. stop IMO for reducing power consumption */
CySysClkImoStop();
/*C15. put the CPU to sleep */
CySysPmSleep();
/* C16. starts execution after waking up, start IMO */
CySysClkImoStart();
/* C16. change HF clock source back to IMO */
CySysClkWriteHfclkDirect(CY_SYS_CLK_HFCLK_IMO);
}
/*C17. Application components need IMO clock */
else if(applicationPower == SLEEP )
{
/* C18. Put the system into Sleep mode*/
applicationPower = WAKEUP_SLEEP;
CySysPmSleep();
}
}
/* Enable interrupts */
CyExitCriticalSection(interruptStatus );
}
www.cypress.com
Document No. 001-92584 Rev. *A
14
Designing for Low Power and Estimating Battery Life for BLE Applications
3
Example Projects
Two example projects are included with this application note to show the implementation of low-power mode
techniques. These example projects require the BLE Pioneer Kit and the following software to build and test:
3.1
PSoC Creator 3.2 or later with PSoC Programmer 3.23.0 or later
CySmart™ PC application
Example Project 1: Low-Power Modes in Advertisement
This project shows how to implement low-power modes in a PSoC 4/PRoC BLE device during the advertising state.
You can also use this project to configure and measure the device’s current consumption for different advertising
intervals. Refer to Appendix A: Advertising State Current Profile for details on how the low-power mode transitions
occur when the device is in the advertising state.
The project configures the device in the Peripheral role with the default settings shown in Table 4. The advertising
interval can be set per your requirement. The Central device sleep-clock accuracy is assumed to be 0 ppm to 20
ppm. The IMO clock is 16 MHz in the example, but it can be lower in real applications.
Table 4. Advertisement Settings
GAP role
Peripheral
Advertising type
Nonconnectable advertising
IMO clock
16 MHz
Transmit power
0 dBm
WCO clock accuracy
0–20 ppm
ADV packet length
14 bytes
The default clock settings used for the project are listed in Table 5.
Table 5. Clock Settings
IMO
Enabled
ECO
Enabled
Direct_Sel
DBL_Sel
IMO (16 MHz)
PLL_Sel
SYSCLK Divider
1
WCO
Enabled
WCO Power Mode
Low Power
LFCLK
WCO (32 kHz)
After you build and program the project into the kit, measure the current and capture the current profile for analysis.
You can modify these configuration parameters and choose the optimum parameters according to your application.
3.2
Example Project 2: Low-Power Modes in Connection
This example project shows you how to implement low-power modes in a PSoC 4/PRoC BLE device in a Peripheral
role. The project can also be used to measure the current consumption of the device for various connection intervals.
Refer to Appendix B: Connection State Current Profile for details on how the low-power mode transitions occur in the
connection state.
The project uses the default connection settings listed in Table 6. The Central-side sleep-clock accuracy is assumed
to be 0 ppm to 20 ppm.
www.cypress.com
Document No. 001-92584 Rev. *A
15
Designing for Low Power and Estimating Battery Life for BLE Applications
Table 6. Connection Settings
GAP role
Peripheral
Connection interval
100 ms
Slave latency
0
IMO clock
16 MHz
WCO clock accuracy
0-20 ppm
Remote device sleep clock
accuracy
0-20 ppm
Transmit power
0 dBm
The default clock settings used in the project are shown in Table 7.
Table 7. Clock Settings
IMO
Enabled
ECO
Enabled
Direct_Sel
DBL_Sel
IMO (16 MHz)
PLL_Sel
SYSCLK Divider
1
WCO
Enabled
WCO Power Mode
Low Power
LFCLK
WCO (32 kHz)
After you build and program the project into the kit, you can measure the current and capture the current profile for
analysis. You can also modify these configuration parameters and choose the optimum parameters for your design.
3.3
Average Current Measurement
The example projects can be used to measure the average current consumption and observe the current profile.
The instantaneous current consumed by the device is not a steady value but varies depending on the state of the
chip that dynamically changes with the power-mode transitions. Therefore, it is practically impossible to measure
each individual instantaneous current with a handheld multimeter because the duration of these current bursts is very
small. Therefore, you should use a multimeter that provides the option to set the “aperture” of the measurement. The
aperture is the period “T” during which the multimeter measures the instantaneous currents, integrates them, and
then displays the average current for the period “T”. For accurate measurements, the aperture of the multimeter must
be set to be the same as the advertising or the connection interval.
To measure the current, follow this procedure:
1.
Build the chosen example project provided with this application note and program the binary into the BLE
Pioneer Kit.
2.
Connect a multimeter across jumper J15 of the BLE Pioneer Kit. A multimeter such as the Keysight 34410A
digital multimeter should be used.
3.
Set the aperture for the measurement based on the advertising interval or connection interval. If the exact
aperture is not available, then set it to an integral multiple of the advertising or connection interval.
4.
Measure the current. The current measured is the average current over one interval.
www.cypress.com
Document No. 001-92584 Rev. *A
16
Designing for Low Power and Estimating Battery Life for BLE Applications
Note For advertising/connection intervals where the aperture is more than that supported by the instrument, a
different method is required to measure the average current. For example, the Keysight 34410A multimeter has a
maximum one-second aperture. Measuring the average current for intervals greater than one second requires a
different approach. For these cases, set the integration method on the instrument to Number of Power Line Cycles
(NPLC) and set the NPLC number to 100. Enable the “stats” option in the “math” menu. This will run an averaging
filter on the current samples measured. After allowing a few samples (approximately 100x interval time), the value
settles to a stable value, which is the average current.
3.3.1
Average Current in Advertising and Connection States
Table 8 and Table 9 list the average currents measured for different values of advertising and connection intervals
using the example projects. The remote device used is another BLE Pioneer Kit. You can also use the kit USB dongle
with the CySmart PC tool for connection-related measurements. The currents measured will be higher, however, due
to the higher WCO clock inaccuracy of the dongle WCO crystal.
Table 8. Advertising Interval Versus Average current
Advertising Interval (ms)
Current (µA)
100
261.8
120
219.5
150
175.6
180
147.0
200
132.3
250
106.4
300
88.8
400
66.5
500
53.3
1000
26.6
4000
7.5
Table 9. Connection Interval Versus Average Current
Connection Interval (ms)
www.cypress.com
Average Current (µA)
10
1501.3
20
783.6
30
522.7
40
389.0
50
313.4
60
264.2
70
224.9
80
197.3
90
175.4
100
157.2
200
80.3
300
53.9
400
41.0
500
33.2
Document No. 001-92584 Rev. *A
17
Designing for Low Power and Estimating Battery Life for BLE Applications
Connection Interval (ms)
Average Current (µA)
600
27.9
700
24.3
800
21.4
900
19.3
1000
17.6
4000
5.8
Figure 7 and Figure 8 show graphs of the measured current values for different advertising and connection intervals,
respectively. The graphs can be used to get a quick estimate of the average current for any interval in the range.
Figure 7. Average Current Versus Advertising Interval
180
160
Average current (uA)
140
120
100
80
60
40
20
0
100
www.cypress.com
200
300
400
500
600
700
Advertisement interval (ms)
Document No. 001-92584 Rev. *A
800
900
1000
18
Designing for Low Power and Estimating Battery Life for BLE Applications
Figure 8. Average Current Versus Connection Interval
180
160
Average current (uA)
140
120
100
80
60
40
20
0
100
3.3.2
200
300
400
500
600
700
Connection interval (ms)
800
900
1000
Current Profile for Advertising and Connection States
To observe the current profile described previously for the advertising and connection events, follow this procedure.
1.
Connect a current probe such as Tektronix TCP0030 across the jumper wire on the J15 connector.
2.
Connect the probe to a high-performance oscilloscope such as Tektronix DPO 4054.
3.
Set the range of resolution for the current axis between 2 mA and 5 mA and the range of resolution for the time
axis between 500 µs and 800 µs.
4.
Trigger the oscilloscope to capture the waveform.
Figure 9 and Figure 10 show the current profile oscilloscope captures for the advertising interval and connection
interval of 100 ms each, respectively. The letters marked in the capture map to the different power stages the device
goes through during the advertising and connection states, as described in Appendix A: Advertising State Current
Profile and Appendix B: Connection State Current Profile.
www.cypress.com
Document No. 001-92584 Rev. *A
19
Designing for Low Power and Estimating Battery Life for BLE Applications
Figure 9. Current Profile Scope Capture for Advertising Interval
Figure 10. Current Profile Scope Capture for Connection Interval
www.cypress.com
Document No. 001-92584 Rev. *A
20
Designing for Low Power and Estimating Battery Life for BLE Applications
3.4
Power Calculator
To make it easy to estimate the current consumption for your design, a power calculator based on an Excel
worksheet is provided with this application note. This tool allows you to calculate the average current consumption for
PSoC 4/PRoC BLE devices for the advertising and connection states of different system settings and BLESS
parameters. You can use this tool during the system design stage to derive the optimum set of parameters to achieve
the required low current consumption. Note that the calculator provides only an estimation of the current
consumption. The actual current measured in your system may be different depending on your system design and
how you use the various low-power modes.
The workbook has two calculators: the advertisement calculator and the connection calculator. In each calculator
sheet, the user input parameters are entered in the yellow cells provided in the Input Parameters table. The
calculated values are shown in the blue cells. The grey cells are for information purposes only. You are required to
edit only the yellow cells and not modify the other cells. The allowed range of values for each input parameter is
highlighted when you click on any input cell.
The advertisement calculator allows you to calculate the average current for different advertisement settings. The
advertisement calculator input parameters are shown in Table 10. Select the advertising type, interval, and size of the
data based on the configuration done in the BLE Component of your project. The CPU clock frequency can be 6,
12, or 16 MHz. You should also select the transmit power level configured in the BLE Component configuration.
Table 10. Advertisement Calculator Input Parameters
Table A - Input Parameters
Advertisement Settings (From BLE Component Configuration)
Value
Advertisement Type
Unconnectable Advertising
Advertisement Interval
1000
Advertisement payload
14
System Settings
CPU clock (IMO) frequency
16
Transmit Power
0
Estimate Average Current Consumption
27.67
Units
ms
bytes
MHz
dbm
uA
Based on the inputs, the sheet automatically updates the average current in the blue cell.
To estimate the battery life for an application such as iBeacon, where the device is in the Broadcaster role, select the
battery capacity and the number of hours in a day the device is active. It is assumed that for the rest of the time, the
device is in the OFF state and does not consume any power. Based on these inputs, the battery life is estimated, as
given in Table 11.
Table 11. Advertisement – Battery Life Calculation
Table B - Battery Life Estimator
hours of usage per day
Battery Capacity
Estimate Battery Life
24
2200
3313
hours
mAh
days
The connection calculator allows you to estimate the current consumption of a PSoC 4/PRoC BLE device in the
connection state in a Peripheral role. The connection calculator input parameters are shown in Table 12. Select the
connection interval and the slave latency based on the configuration done in the BLE Component of your project. The
CPU clock frequency can be 6, 12, or 16 MHz. You should also select the crystal clock accuracy of the WCO crystal
used in your design. The clock accuracy of the Central device, typically 031_TO_050_PPM, must also be entered.
The transmit power level configured in the BLE Component is also selected.
www.cypress.com
Document No. 001-92584 Rev. *A
21
Designing for Low Power and Estimating Battery Life for BLE Applications
Table 12. Connection Calculator Input Parameters
Table A - Input Parameters
Connection Settings (From BLE Component Configuration)
GAP Role
Connection Interval
Slave Latency
Number of bytes to be sent
System Settings
CPU clock (IMO) frequency
WCO clock accuracy
Remote Device clock accuracy
Transmit Power
Estimate Average Current Consumption
Value
Peripheral
1000
0
0
Units
16
000_TO_020_PPM
000_TO_020_PPM
0
17.49
MHz
ppm
ppm
dbm
uA
ms
Based on the inputs, the sheet updates the average current in the blue cell.
4
BLE Applications
4.1
BLE System Power
A typical BLE application involves sending the sensor data from a BLE Peripheral device (such as a heart-rate
monitor) to a BLE Central device (such as a smartphone). The system-level architecture of a Peripheral device for
such applications has three major functional blocks, as shown in Figure 11: sensing, data and event processing, and
BLE connectivity. Each block contributes to the average current of the overall system.
4.1.1
Sensing Block
The sensing block comprises a sensor and transducer hardware that converts the sensor information into an analog
electrical signal, followed by a signal-conditioning circuit that is used for filtering and amplification of the analog
signal. The conditioned analog signal is converted into digital data for processing by an analog-to-digital converter
(ADC). The key factors that determine the current consumption in the sensing operation are the following:
Signal conditioning and analog-to-digital conversion: The signal-conditioning circuit and the ADC consume
significant current during the sensing operation.
Sampling rate: The sampling rate is the minimum rate at which the sensor data must be captured by the ADC to
have enough samples for accurate processing of the sensor data.
Scan rate: The scan rate is the rate at which a sensor must be polled to detect an activity. This allows the system
to be in low-power states if there is no activity.
Figure 11. System Block Diagram
Flash for
Data logging
+ processing
Sensing
Sensor &
Transducer
www.cypress.com
Signal
Conditioning
ADC
Document No. 001-92584 Rev. *A
CPU
BLE
Connectivity
22
Designing for Low Power and Estimating Battery Life for BLE Applications
4.1.2
D a t a a n d E ve n t P r o c e s s i n g B l o c k
The sensor data requires processing to derive meaningful and actionable information. You may also need to
compress the data to reduce the over-the-air bandwidth required to transfer the data to the peer device.
Sometimes, a BLE device may use more than one sensor. For example, a heart-rate monitor device may measure
the battery level in the device to detect a low-battery condition, in addition to heart-rate sensing. A BLE touch mouse
may have an optical sensor, a touch sensor, a scroll key, a trackpad, and multiple buttons to detect key presses. In
such systems, you need to detect activities in multiple sensors, process the data from multiple sensors, and send the
data from multiple sensors over the BLE link. Each sensor’s scan rate can be asynchronous to the others and the
BLE link. Efficient management of these multiple asynchronous activities is an important factor that contributes to the
current consumption.
4.1.3
B L E C o n n e c t i vi t y B l o c k
The sensor data is sent to a Central device through BLE notifications or through Read requests from the Central
device. The time taken to process the notifications and send the sensor data to the peer device efficiently will
determine the current consumption.
4.2
Battery Life
Most BLE devices are battery operated. A long battery life is typically the most important requirement for a batteryoperated device. A long battery life helps reduce the maintenance cost of replacing the batteries often. It ensures
high availability of the devices in the deployed environment. It also allows using a lower-capacity battery for a given
lifetime of device usage, reducing the battery cost and allowing the devices to be smaller (See Table 13).
Table 13. CR Battery Comparison
Type
Capacity (mAh)
Size (d x h, mm)
CR1025
30
10 × 2.5
CR1220
35–40
12.5 × 2.0
CR1616
50–55
16 × 1.6
CR1620
75–78
16 × 2.0
CR1632
140
16 × 3.2
CR2032
225
20 × 3.2
CR2450
610–620
24.5 × 5.0
The battery life is a function of the time that the device is used over the lifetime of the battery and the average current
consumption of the system during its use. A device usage profile is the time pattern of a typical user using the BLE
device through a normal day or a week—how long the device is used for the intended function, how long the device is
idle, how long the device is switched OFF, and so on.
Based on the usage profile, the device can be put through different low-power states to reduce current consumption.
The duration that the device is put in a specific state is determined by the usage profile and the application
requirements. The current consumed in each state is determined by the system architecture, low-power modes used,
and the current consumed by the different parts of the system in that state. Therefore, it is important to determine the
usage profile and a current profile in various system states to estimate the battery life.
An illustration of the usage and current profile for an activity-monitoring (sleep and activity levels) device is shown in
Figure 12. A user uses this device through the day; the user may switch it OFF intermittently. The current consumed
varies accordingly.
www.cypress.com
Document No. 001-92584 Rev. *A
23
Designing for Low Power and Estimating Battery Life for BLE Applications
Figure 12. Usage and Current Profile
Evening
Jog
00:00
21:00
Device Sleep
OFF Monitor
19:00
Device
OFF
12:00
12:30
Time in a day
07:00
Device
OFF
06:00
00:00
Current
Sleep
Monitor
Noon
Cycling
18:00
Morning
Jog
The battery life can be measured by a simple formula that combines the usage profile and the current profile, as
shown in Equation 1:
Equation 1. Battery Life
Where,
The current in any state is a function of the current consumed in the different blocks in that state. Broadly speaking,
this is the sum of the current consumed in the three major blocks, shown as:
Equation 2. Average current in a state
Where,
www.cypress.com
Document No. 001-92584 Rev. *A
24
Designing for Low Power and Estimating Battery Life for BLE Applications
4.3
Techniques for Increasing Battery Life
From these equations, it is evident that battery life can be increased by using the following approaches to reduce the
average current consumed:
Reduce the Active mode current: The sensing and processing functions contribute equally, if not more, to the
overall system current consumption. Therefore, you should take a system view and reduce the current
consumption in all active operations such as sensing, data processing, and BLE transactions.
Reduce the active time: Reduce the time spent in CPU or RF operations so that the system can be in the idle or
OFF states more often. The current consumed in these idle or OFF states is as important as the current
consumed during active operations. The current consumption in these states should be reduced by using the
available low-power modes.
The following is a list of suggestions to reduce the average current in PSoC 4/PRoC BLE devices and effectively
increase the battery life.
4.3.1
R e d u c i n g t h e A c t i ve C u r r e n t
Operate at Lower CPU Clock Frequency
The application should be designed to allow the CPU to operate at lower clock frequencies to reduce the current. For
example, power-optimal algorithms and implementations tuned to the CPU architecture should be used to reduce the
processing power required for sensor data processing.
Shut Down Unused Resources
The application can put the unused peripherals and clocks into the available low-power modes permanently. In
addition, peripherals and clocks that are not required often or that are required only in specific usage modes should
be put into their lowest power modes, wherever possible.
For example, you can turn the ILO OFF for most BLE applications. The WCO can be used for all LFCLK
requirements such as the watchdog timer or BLESS.
Utilize Chip-Level Integration
Integration of the sensing circuit and other external interfaces in a single chip reduces the overall system current
consumption due to improved performance, reduced I/O switching, and communication overheads. PSoC 4 BLE is a
®
highly integrated device that includes Cypress CapSense , programmable analog with 12-bit ADC, four opamps with
comparator mode, two low-power comparators that can operate in the Deep-Sleep mode, a programmable digital
2
block, and up to 32 GPIOs multiplexed with different communication interfaces such as I C, SPI, and UART. This
system integration must be utilized to reduce the external components that need to be present on a PCB for the
application and improve the overall system-level current consumption.
Reduce Transmit Power
Most applications require 0-dBm RF transmit power. However, the transmit power can be lowered if the device is
designed to work for ranges of less than 5 m. This reduces the RF current consumption. For example, by operating
the device at –6 dBm, the transmit current can be reduced by 3 mA.
4.3.2
R e d u c i n g t h e A c t i ve T i m e
Schedule Activities Around the Connection Event
The application should align the sensing and data processing operations to the beginning or end of BLE connection
events. The application can then complete all the processing and put the system into the Deep-Sleep mode along
with the BLESS until the next BLE connection event. This is more power efficient than processing asynchronous to
the BLE events, because it allows the system to be in the Deep-Sleep mode for longer times (refer to Figure 1).
However, note that the application activity should be avoided during the BLE events when the BLESS is transmitting
or receiving packets. This reduces the peak current consumption that adversely impacts the battery life of some types
of batteries such as coin-cell batteries.
Lower Sensor Scan Rates
www.cypress.com
Document No. 001-92584 Rev. *A
25
Designing for Low Power and Estimating Battery Life for BLE Applications
If no sensor use or activity is detected for some time, the device can reduce the rate at which it scans for the activity.
In addition, it can increase the connection interval of the BLE link and enter low-power modes to reduce the system
current. While this may introduce latency in reacting when an activity occurs, the overall system power can be
significantly reduced. For example, in trackpad designs, scanning alternate sensors instead of all the sensors to
detect a movement can save power. The sampling rate for data can also be minimized where and when possible.
Lower Data Sampling Rates
The sampling rate of the SAR ADC in the device should be reduced to the minimum frequency required to effectively
reproduce the analog signal being sampled. Based on the sampling frequency, the SAR ADC configurations (such as
the ICONT_LV register fields) that allow low-power operation should be used. In addition, the channel resolution can
also be reduced to decrease the conversion time and thus save power.
Use Asynchronous Wakeup
PSoC 4 BLE provides a low-power comparator that continues to operate while the system is in the Deep-Sleep mode.
If any sensor activity is detected through the comparator, it can wake the entire system from the Deep-Sleep mode.
This avoids keeping the CPU active for periodic scanning for sensor activity. In addition, the GPIOs are available as
asynchronous wakeup sources, which can be used to wake up the system from the Deep-Sleep mode based on the
detection of an external activity.
Reduce WCO Crystal ppm
The WCO crystal accuracy (measured in ppm) affects the listening window at the connection events in a Peripheral
device. Due to the drift in timing caused by an inaccurate crystal, the Peripheral will have to listen for a larger window
to “locate” the packet from the Central device. The higher the inaccuracy, the larger is the listening window and the
higher is the current consumption. Refer to AN95089 – PSoC 4/PRoC BLE Crystal Oscillator Selection and Tuning
Techniques for details on WCO crystal selection and tuning.
Figure 13 shows the improvement in average current for a one-second connection interval in PSoC 4 BLE as the ppm
is reduced. A 500-ppm crystal is considered for the chart.
Figure 13. ppm Versus Current Reduction
By using a more accurate crystal, the active time for which the radio is listening can be reduced. For example, in the
PSoC 4/ PRoC BLE device, reducing the WCO inaccuracy by 50 ppm reduces the average current by approximately
2 µA, thus increasing the battery life.
Increase Connection Interval
The connection interval for a BLE link is set by the Central device when a connection is created with the Peripheral
device. It is preferable that the Peripheral have a connection interval that matches the rate at which the sensor data
from the Peripheral is sent to the Central device. If the initial connection interval set by the Central is lower than
necessary, then the Peripheral should request the Central to increase the connection interval to reduce current
consumption.
www.cypress.com
Document No. 001-92584 Rev. *A
26
Designing for Low Power and Estimating Battery Life for BLE Applications
Use Slave Latency
Slave latency is a BLE feature that allows a Peripheral to listen to the Central device on connection events at a
reduced rate. This is useful if the Peripheral device is inactive for some time and has to wait for some activity to occur
to send data to the Central device. If no activity is detected for some time, the Peripheral can enter slave latency by
sending a connection update request to the Central. The Peripheral can extend the interval between the connection
events at which it listens to the Central. This allows the BLESS and the system to be put into the Deep-Sleep mode
for longer time. The key advantage of using slave latency is that when the Peripheral application detects an activity, it
can switch the BLESS back ON to listen to the Central at the original connection interval until the data transfer is
completed. This avoids the latency in sending the data upon the first activity.
For example, maintaining an idle connection with a 100-ms interval consumes 148 µA. If the same connection is
updated with a slave latency value of 9, the current consumption drops to 17 µA.
These points are illustrated with two example BLE use cases: a fitness application and an HID application.
4.4
Example Application: Heart-Rate Monitor
A common usage segment of BLE connectivity is the fitness and wearable segment. Many BLE devices track
distance cycled, number of steps climbed, heart rate, number of hours slept, and so on. A heart-rate monitor (HRM) is
one of the most common fitness applications that use BLE today to monitor fitness levels.
4.4.1
S ys t e m A r c h i t e c t u r e
An HRM performs the following high-level activities (see Figure 14):
Sensing: The HRM has an analog front end to capture signals from the human body. In general, it consists of
one or more of the following activities:
o
Sensor: The sensor captures the input signal. Optical sensors (LED-photodiode pairs) and electrodes are
commonly used.
o
Filtering and amplification: The input signal is filtered and amplified for accurate detection. Usually,
operational amplifiers and hardware filters are used for this purpose.
o
Analog-to-digital conversion: This stage converts the analog signal to a digital signal, which is sent to the
application firmware for further processing.
o
Firmware processing: The application implements further filtering and amplification, followed by an algorithm
to convert the signal into a heart-rate value by using a timing procedure.
BLE connectivity: The HRM maintains a BLE connection when in use and transmits the converted heart-rate
value to a heart-rate collector device, usually with a refresh rate of once per second.
Figure 14. HRM System Block Diagram
Heart Rate Monitor
Sensing
Input Signal
Sensor and
Transducer
Signal
Conditioning
CPU- Firmware
Processing
4.4.2
ADC
BLE Connectivity
HRM Usage Profile
An HRM is typically used in one of these ways.
1.
Using the HRM during a training or exercise routine, generally for 1-2 hours per day.
2.
Wearing the HRM all day in an ultra-low-power mode and turning it active multiple times during the day for short
durations. The average active time is approximately one hour per day.
www.cypress.com
Document No. 001-92584 Rev. *A
27
Designing for Low Power and Estimating Battery Life for BLE Applications
4.4.3
A p p l i c a t i o n D e s i g n f o r L o w P ow e r
For the typical usage profile, the application design is shown in Figure 15. When the device is in use, it scans the
heart-rate sensor at a constant rate and processes the sensor output to get a heart-rate value. For an HRM, the
sensor scan rate is usually about 20 milliseconds. During the sensor scan, the system is put in the Sleep mode.
The BLE connection events are asynchronous to this operation, and the connection interval is much larger than the
sensor scan rate. The typical connection interval is one second for HRM applications. At every connection event, the
device sends the sensor data to the heart-rate collector device through notifications. The system then goes to the
Deep-Sleep mode when all the BLE and system processing is completed.
When the user no longer needs the heart-rate information, the device disconnects from the peer device and enters an
idle state with a very low current consumption (such as the Hibernate or Stop mode) where all the system
functionality is turned OFF and a low-power wakeup source (such as a GPIO or the WAKEUP pin) is set up to
resume functionality. For example, an external piezo can be used as a wakeup source by driving a GPIO. The piezo
is activated and triggers an interrupt when the user wears the HRM. For this application, the SAR ADC and three
CTBms available on the chip (PSoC 4 BLE only) are used to interface to the external sensor.
Figure 15. HRM Firmware Design
Application Flow
Scan sensor and get raw data
Process raw data to get Heart
Rate value
Ultra-low-power mode
BLE Connectivity
1 second
elapsed since last
check?
Disconnection
All functionality
turned off; wait for
user assertion
Yes
GPIO Wakeup
Timer Interrupt to
maintain sensor
scan rate
No
Connection Event
Push a notification packet to
BLE link layer
BLE connection
event (Rx/Tx)
handled
asynchronous to
the main
application
Process BLE events
Enter Lowest Power Mode
possible (Sleep or Deep Sleep)
depending on BLE activity
4.5
Example Application: Remote Control
An emerging application of BLE connectivity is in the HID market with products such as the smart remote control for
smart TVs and set-top boxes. These applications differ from the wearable device applications mainly in the BLE data
rate and the usage profile that involves start-idle-stop cycles. This example discusses a simple BLE remote control
with a trackpad. It demonstrates an additional level of complexity in the system compared with the HRM and shows
how a low-power design should be done in such a case.
4.5.1
S ys t e m A r c h i t e c t u r e
A BLE remote control with a trackpad as a BLE Peripheral device performs the following functions:
Trackpad sensing: The touchpad of the remote device will have an array of sensor rows and columns. The
number of rows and columns will vary depending on the size and resolution of the touchpad required. The
www.cypress.com
Document No. 001-92584 Rev. *A
28
Designing for Low Power and Estimating Battery Life for BLE Applications
trackpad sensor array implements capacitive sensing (CapSense). The CapSense block converts the
capacitance of the sensor to a digital quantity, which can be processed by the firmware.
Firmware processing: The sensor array data from the CapSense block is processed by the application firmware
to detect mouse pointer movements and recognize gestures such as zoom, scroll, rotate, click, double-click, and
so on. This data is sent as an HID report over BLE to the BLE Central device.
BLE connectivity: The remote control device sends the HID reports to its host typically at a 10-ms connection
interval whenever there is a user activity. However, in the absence of a user activity, this interval should be
increased using slave latency to save power and maintain a BLE connection.
The overall system can be represented as shown in Figure 16.
Figure 16. Remote Control System Architecture
HID Trackpad Remote Control
User Input
Track pad Sensor
Array
BLE Connectivity
Capacitive Sigma
Delta (CSD)
Sensing
CPU- Gesture
Recognition
System on Chip
4.5.2
Remote Control Usage Profile
A typical usage model for the remote control follows:
4.5.3
If the remote is used for 25 minutes a day, it will be in a low-power state for the rest of the day.
Out of the total usage of 25 minutes, it is estimated that the user will actively use the remote with intermittent
breaks when the remote is idle. The remote is assumed to be in active use for 80 percent of the time and idle for
the remaining 20 percent of the time.
A p p l i c a t i o n D e s i g n f o r L o w P ow e r
The activities that are carried out by the application are as follows:
Scanning the trackpad
Processing the trackpad data
Sending the trackpad report over BLE
Staying in a low-power mode for the rest of the time
A watchdog timer is used to interrupt the PSoC BLE/ PRoC BLE device periodically to scan the trackpad to detect
user activity. A low current consumption can be achieved by keeping the system in a low-power mode between
interrupts. If an activity is detected on the trackpad, the trackpad is scanned to process the finger movements and to
send the data over BLE to the host device. Thus, the firmware of the remote implements a simple algorithm, as
shown in Figure 17.
www.cypress.com
Document No. 001-92584 Rev. *A
29
Designing for Low Power and Estimating Battery Life for BLE Applications
Figure 17. Remote Control Firmware Flowchart
Scan Trackpad
Wakeup
Touch
Detected?
Yes
Timer
Interrupt
Process Gestures
Prepare HID report
No
Exchange BLE
Packets
System in DeepSleep Mode
The trackpad scan is aligned with the BLE connection events so the system can be in the Deep-Sleep mode for the
maximum possible time. Scanning of sensors and processing of gestures take a finite amount of time every scan
cycle. When these activities are completed at the connection event, the system is put into the Deep-Sleep mode to
save power. The connection interval must be chosen appropriately. If the connection interval is higher, the HID report
rate for the device may be lower than required, which will degrade the user experience due to latency in transmitting
the data. If the connection interval is lower, then the current consumption increases. To satisfy the conflicting needs
of a good user experience and a power-efficient system, the application needs to switch adaptively between the
required connection intervals.
A similar challenge is faced with respect to the trackpad scan rate. The trackpad must be scanned at a higher rate to
recognize gestures, but it should be scanned at a lower rate when there is no movement for a long time. The lower
rate must be just enough to detect user activity. To meet these requirements, the application implements a state
machine, as shown in Figure 18.
Figure 18. Remote Control State Machine
Device Init State
Initialization Complete
User Activity
Active State
No user activity for short duration
Idle State
No user activity for long duration
Low-Power State
Low Battery Voltage
Shutdown State
www.cypress.com
Document No. 001-92584 Rev. *A
30
Designing for Low Power and Estimating Battery Life for BLE Applications
Active state: The Active state denotes that all the scanning and processing activities are carried out at the
highest required rate. Typically, the trackpad scan is done every 10 ms in the Active state. Therefore, most of the
current consumption of the system originates in the Active state. The firmware will remain in the Active state as
long as user activities are happening.
Idle state: When using the trackpad, users may keep the trackpad idle for several seconds between touch
activities. The Idle state saves power when the trackpad in not being used for an idle period. This state is entered
if no touch activity is detected for a specified timeout in the Active state. In this state, the trackpad is scanned at
a rate lower than needed for a smooth mouse movement, but sufficient to detect the start of a touch activity
without an observable delay. The BLE connection uses slave latency to reduce the use of the radio, while
maintaining readiness to send the data without latency when a user activity is detected. The system and BLESS
are in the Deep-Sleep mode for most of the time.
Low-Power state: The system is expected to stay in the low-power state for most of the time. The application
enters this state from the Idle state if a user activity is not detected during the Idle state for additional time. In this
state, a BLE connection is sustained with no application data exchange. The application may also increase the
slave latency to reduce the use of the radio while sustaining the connection. The trackpad still needs to be
scanned to detect user activity. To detect a touch activity, a high resolution of the touch is not needed. Therefore,
only the alternate rows of the trackpad are scanned. The system is in the Deep-Sleep mode for most of the time.
Shutdown state: When the battery voltage drops below the operable voltage, the system stops all the activities
and shuts down. This is done by putting the system in the Hibernate or Stop mode.
It should be noted that in each of these states, the system undergoes power mode transitions among the DeepSleep, Sleep, and Active modes for optimizing power, based on the device activity. Only the durations for which the
device remains in the Active or Deep-Sleep mode are different in different states.
4.6
Implementing System Design Recommendations
4.6.1
RF Transmit Power
RF transmit power can be reduced to conserve power. To configure the RF transmit power in your project, open the
Configure BLE window from the BLE Component instance, as shown in Figure 19.
1.
Go to the GAP Settings tab.
2.
Configure the TX power level (dBm) to the desired setting from the list.
www.cypress.com
Document No. 001-92584 Rev. *A
31
Designing for Low Power and Estimating Battery Life for BLE Applications
Figure 19. Changing the RF Transmit Power Level
4.6.2
Connection Parameter Update
The PSoC 4/PRoC BLE device supports the connection parameter update feature of the BLE specification. The
feature allows a Peripheral to negotiate the connection parameters, connection interval, and slave latency with the
Central device as required by the application.
To update either the connection interval or the slave latency parameters, the application on the Peripheral device
must call the CyBle_L2capLeConnectionParamUpdateRequest() function with the new connection interval and
slave latency parameters. The function is called when the CYBLE_EVT_GAP_DEVICE_CONNECTED event is received
upon device connection.
void AppCallBack(uint32 event, void* eventParam)
{
static CYBLE_GAP_CONN_UPDATE_PARAM_T hrmConnectionParam =
{
1000,
/* Minimum connection interval required */
1000,
/* Maximum connection interval required */
0,
/* Slave latency */
500
/* Supervision timeout */
};
switch(event)
{
/* Handle Stack events */
case CYBLE_EVT_GAP_DEVICE_CONNECTED:
/* Send Connection Parameter Update request to the Central */
CyBle_L2capLeConnectionParamUpdateRequest \
(cyBle_connHandle.bdHandle, &hrmConnectionParam);
}
}
www.cypress.com
Document No. 001-92584 Rev. *A
32
Designing for Low Power and Estimating Battery Life for BLE Applications
5
Summary
PSoC 4/PRoC BLE devices support multiple systems and BLESS low-power modes that enable you to design a
highly power-efficient solution. The advertising and connection current profiles indicate that the Deep-Sleep mode
current is equally important to the RF transmit/receive currents when considering a reduction in the overall average
current. The advertising and connection power calculator can help you choose the right set of parameters.
The battery life of a BLE application depends on the system-level current consumption. In most applications, sensing
and processing can consume more power than the BLE operations, so attention must be paid to reduce the overall
system current. The system-level low-power techniques suggested should help you in designing a low-power BLE
solution by including some suggestions, where possible, at the system design stage. You can also use the power
calculator tool to help you make decisions on the system parameters to improve the battery life.
www.cypress.com
Document No. 001-92584 Rev. *A
33
Designing for Low Power and Estimating Battery Life for BLE Applications
6
Appendix A: Advertising State Current Profile
The PSoC 4/PRoC BLE device in the advertising state transmits packets containing the advertising data in periodic
events. Three advertising packets may be sent in an advertising event (one on each of the three enabled advertising
channels). The device may optionally listen for and respond to a peer BLE device that receives the advertising
packets and requests for additional data.
The time between the start of the two consecutive advertising events (T_adv_event) is specified as follows:
T_adv_event = advInterval + advDelay
The advInterval is an integer multiple of 0.625 ms and has different ranges for different advertising packet types. It is
typically chosen in the range 100 ms to 10.24 s. The advDelay is a pseudo-random value with a range of 0 ms to 10
ms. Advertising events are illustrated in Figure 20, with one advertising event as an example.
Advertising State Entered
ADV_IND
Channel 37
ADV_IND
SCAN_REQ
SCAN_RSP
Channel 38
Channel 38
Channel 38
T_IFS*
T_IFS
Advertising
Event
Advertising
Event
T_advEvent
T_advEvent
advInterval
advInterval
advDelay
ADV_IND
Channel 39
Advertising
Event Close
Advertising
Event Start
Figure 20. Advertising Event and Interval
Advertising
Event
advDelay
* T_IFS is Inter Frame Space, which is defined to be 150 µs. This is to allow the radio to switch between transmit and receive states.
6.1.1
Current Profile
The advertising state current profile for a PSoC 4/PRoC BLE Peripheral device implementing the recommendations
for low power is shown in Figure 21. It illustrates the power mode transitions, along with the BLE state transitions and
relative current levels across the states.
www.cypress.com
Document No. 001-92584 Rev. *A
34
Designing for Low Power and Estimating Battery Life for BLE Applications
Current
A
B
C
D IH
D
I H I D
E
D IH F
J G
Advertising event = ~8 ms
Time
Adv Event Avg. Current
System Deep-Sleep Current
T_adv_event = ~100 ms
The stages of the current profile curve, labeled with the letters A to H, are listed in Table 14 along with the BLESS
internal states and the system and BLESS power modes used. Note that in some of these states, the system is
shown to be in more than one power mode. This is because an interrupt at the beginning of the state transitions the
system into the Active mode. After the interrupt is processed, the system is put back into a low-power mode.
www.cypress.com
Document No. 001-92584 Rev. *A
Deep-Sleep
Enter Deep-Sleep
Post Processing
Inter Frame Space
Wait for Scan Req
No Packet Received
ADV Packet Transmit
ADV_IND (Channel 39)
Inter Channel delay
Scan Resp Transmit
SCAN_RESP (Channel 38)
Inter Frame Space
Scan Req
SCAN_REQ (Channel 38)
ADV_IND (Channel 38)
E
Inter Frame Space
ADV Packet Transmit
Inter Channel delay
Inter Frame Space
Wait for Scan Req
No Packet Received
ADV Packet Transmit
ADV_IND (Channel 37)
BLE Deep-Sleep Exit
Wait for Oscillator
Stability
Wait in Deep-Sleep
Wake Up &
Turn Oscillator ON
Figure 21. Advertising Current Profile
35
Designing for Low Power and Estimating Battery Life for BLE Applications
Table 14. Advertising Current Profile Stages
Power Modes
Stage
BLESS Internal State
BLESS Operation
BLESS
A
CYBLE_BLESS_STATE_ECO_ON
Oscillator Startup
DEEPSLEEP
System
Active
Deep-Sleep
Active
B
CYBLE_BLESS_STATE_ECO_STABLE
Oscillator Stabilization
DEEPSLEEP
Sleep
Active
C
CYBLE_BLESS_STATE_ACTIVE
Event Start Delay
ACTIVE
D
CYBLE_BLESS_STATE_ACTIVE
ADV Transmit
ACTIVE
Sleep
I
CYBLE_BLESS_STATE_ACTIVE
Inter-Frame Space
ACTIVE
Sleep
H
CYBLE_BLESS_STATE_ACTIVE
Receive
ACTIVE
Sleep
E
CYBLE_BLESS_STATE_ACTIVE
Inter-Channel Delay
ACTIVE
Sleep
F
CYBLE_BLESS_STATE_EVENT
CLOSE
Post-Processing
ACTIVE
Active
J
CYBLE_BLESS_STATE_DEEPSLEEP
Enter Deep-Sleep
two LFCLK cycles)
DEEPSLEEP
Sleep
G
CYBLE_BLESS_STATE_DEEPSLEEP
Deep-Sleep
DEEPSLEEP
Deep-Sleep
Sleep
(takes
The BLESS is in the DEEPSLEEP mode (stage G) between advertising events. The system may also be in the DeepSleep mode if no processing is required. The BLESS maintains the link timing by using the WCO clock because the
ECO is OFF. The BLESS automatically wakes up at the programmed instant before the start of the advertising event
and generates an interrupt.
A – The BLESS interrupt wakes up the system from the Deep-Sleep mode. The BLE Component turns ON the ECO
at the beginning of the stage. The ECO ramps up by the end of stage A with a stable clock amplitude. The ramp up
takes approximately 400 µs. The application can put the system back into the Deep-Sleep mode until the ECO is
ready. The ECO interrupts the CPU once the amplitude is stable.
B – The ECO requires more time to stabilize the frequency. The application puts the system into the Sleep mode
during this period. This stabilization takes approximately 400 µs. At the end of stage B, the BLESS wakes up from the
DEEPSLEEP mode. It switches from the WCO clock to the stable ECO clock and generates an interrupt.
C – The BLESS interrupt wakes up the CPU. The BLESS enters the ACTIVE mode. If no processing is required, the
application puts the system again into the Sleep mode. The system may remain in the Sleep mode until all BLE
transactions are completed in stage F. The system remains in this stage until the start of the advertising event.
D – In the advertising event, the Peripheral transmits the advertising packets. The entire BLESS including the RF is
active during this period. The advertising packets are transmitted on the three advertising channels.
I – After transmitting the advertising packet, the Peripheral waits for an Inter-Frame Space time interval (T_IFS) of
150 µs (per the BLE specification) to listen to the peer device. This stage is optional and depends on the advertising
type settings.
H – After an Inter-Frame Space time interval, the Peripheral listens on the same channel for a packet from the peer
device. The BLESS times out and stops listening if no packet is received within a specific time. If a packet is received,
it continues to receive until the end of the packet. This state is optional and depends on the advertising type settings.
E – The three packets are spaced at an interval of 1.25 ms. The BLESS is idle during this interval between the
transmissions.
www.cypress.com
Document No. 001-92584 Rev. *A
36
Designing for Low Power and Estimating Battery Life for BLE Applications
F – After transmitting the three advertising packets, the BLESS generates an “end-of-event” interrupt that wakes up
the CPU. The BLE stack and application complete any event-specific or other application-specific activities in this
period. The application then programs the BLESS to enter the DEEPSLEEP mode by calling the
CyBle_EnterLPM()function in the BLE Component. The BLESS takes two LFCLK cycles (approximately 120 µs)
to switch to the WCO and enter the DEEPSLEEP mode internally. The BLE Component therefore puts the system
into the Sleep mode until the DEEPSLEEP mode entry is complete.
J – The system is in the Sleep mode in this state, waiting for the BLESS to enter the DEEPSLEEP mode. Once the
transition is complete, the BLESS generates an interrupt to indicate successful entry into the DEEPSLEEP mode,
which wakes up the CPU.
G – When the application receives the interrupt at the end of stage J, the application puts the system also into the
Deep-Sleep mode no processing is required.
Note: In the profile described, it is assumed that the application is only managing the BLE advertising events and not
handling any system-level tasks and interrupts. Additional system-level processing will change the current profile
depending on the implementation.
www.cypress.com
Document No. 001-92584 Rev. *A
37
Designing for Low Power and Estimating Battery Life for BLE Applications
7
Appendix B: Connection State Current Profile
A connection is set up between two BLE devices: one acting as a Central (referred to as the Master at the Link Layer)
and the other as a Peripheral (referred to as a Slave at the Link Layer) for exchanging application data. The Central
and Peripheral devices exchange data by transmitting and receiving packets at connection events. The Central
device starts the connection event by transmitting first. The devices then alternate transmitting and receiving data
until they stop the exchange and close the connection event. The starts of connection events are spaced with a
periodic interval of connInterval. The connInterval is a multiple of 1.25 ms in the range of 7.5 ms to 4 s, per the BLE
specification.
In addition to the connection interval (connInterval), the connSlaveLatency parameter defines the number of
consecutive connection events that the Peripheral device is not required to listen to the Central device. These
parameters together determine the timing for connections. A BLE connection event with zero slave latency is
illustrated in Figure 22.
7.1.1
Connection
Event
S to M
T_IFS
connInterval
M to S
T_IFS
Connection
Event
S to M
T_IFS
Connection
Event Close
Connection
Event Start
M to S
Connection
Established
Figure 22. Connection Event and Interval
Connection
Event
Legend
M:
Master
S:
Slave
connInterval
Current Profile
A connection state current profile for a PSoC 4/PRoC BLE Peripheral device considering this approach is shown in
Figure 23. The figure illustrates the power modes used, along with the BLESS internal state transitions and relative
current levels.
www.cypress.com
Document No. 001-92584 Rev. *A
38
Designing for Low Power and Estimating Battery Life for BLE Applications
Time
Deep-Sleep
F
J
G
Transmit Packet to Central
Enter Deep-Sleep
C
Post Processing
Current
Transmit Packet
Inter Frame Space
Receive Packet
from Central
B
Receive Packet from Central
Wait for Oscillator
Stability
A
LL Deep-Sleep Exit
Wait in Deep-Sleep
Wake Up &
Turn Oscillator ON
Figure 23. Peripheral Connection Current Profile
H
I
D
Connection Event = ~3 ms
Conn Event Avg. Current
System Deep-Sleep Current
connInterval = 1000 ms
The stages of the current profile, labeled using the letters A to I, along with the BLESS internal states, BLESS power
modes, and the system power modes are tabulated in Table 15.
www.cypress.com
Document No. 001-92584 Rev. *A
39
Designing for Low Power and Estimating Battery Life for BLE Applications
Table 15. Connection Current Profile States
Power Modes
Stage
BLESS Internal State
Connection Profile State
BLESS
System
Active
A
CYBLE_BLESS_STATE_ECO_ON
Oscillator Startup
DEEPSLEEP
Deep-Sleep
Active
B
CYBLE_BLESS_STATE_ECO_STABLE
Oscillator Stabilization
DEEPSLEEP
Sleep
Active
C
CYBLE_BLESS_STATE_ACTIVE
Event Start Delay
ACTIVE
Sleep
H
CYBLE_BLESS_STATE_ACTIVE
Receive
ACTIVE
Sleep
I
CYBLE_BLESS_STATE_ACTIVE
Inter-Frame Space
ACTIVE
Sleep
D
CYBLE_BLESS_STATE_ACTIVE
Transmit
ACTIVE
Sleep
F
CYBLE_BLESS_STATE_EVENT CLOSE
Post-Processing
ACTIVE
Active
J
CYBLE_BLESS_STATE_DEEPSLEEP
Enter Deep-Sleep (takes
two LFCLK cycles)
DEEPSLEEP
Sleep
G
CYBLE_BLESS_STATE_DEEPSLEEP
Deep-Sleep
DEEPSLEEP
Deep-Sleep
The BLESS is in the DEEPSLEEP mode (stage G) between the connection events. The system may also be in the
Deep-Sleep mode if no processing is required. The BLESS maintains the link timing by using the low-frequency WCO
because the ECO is OFF. The BLESS automatically wakes up at the programmed instant before the start of the
connection event and generates an interrupt to wake up the system from the Deep-Sleep mode.
Stages A, B, and C in the connection current profile remain the same as that for the advertising current profile.
H – The device first listens to a packet from the Central device. The duration of this first listening window depends on
the drift caused by clock inaccuracies (measured in ppm) of the crystal oscillator (WCO in this case) used by the
Central and Peripheral devices between the events.
I – After receiving a packet, the Peripheral waits for an Inter-Frame Space time interval (T_IFS) of 150 µs (per the
BLE specification).
D – After waiting for T_IFS, the Peripheral transmits a response packet. The entire BLESS including the RF is active
during this period.
F – After transmitting the three advertising packets, the BLESS generates an “end-of-event” interrupt that wakes up
the CPU. The BLE stack and application complete any event-specific or other application-specific activities in this
period. The application then programs the BLESS to enter the DEEPSLEEP mode by calling the
CyBle_EnterLPM()function in the BLE Component. The BLESS takes two LFCLK cycles (~120 µs) to switch to
the WCO and enter the DEEPSLEEP mode internally. The BLE Component therefore puts the system into the Sleep
mode until the DEEPSLEEP mode entry is complete.
J – The system is in the Sleep mode in this state, waiting for the BLESS to enter the DEEPSLEEP mode. Once the
transition is complete, the BLESS generates an interrupt to indicate successful entry into the DEEPSLEEP mode,
which wakes up the CPU.
G – When the application receives the interrupt at the end of stage J, the application puts the system also into the
Deep-Sleep mode, if no processing is required.
Note: In the profile described, it is assumed that the application is only managing a BLE connection event and not
handling any system-level tasks and interrupts. Additional system-level processing will change the current profile
depending on the implementation.
www.cypress.com
Document No. 001-92584 Rev. *A
40
Designing for Low Power and Estimating Battery Life for BLE Applications
Document History
Document Title: AN92584 – Designing for Low Power and Estimating Battery Life for BLE Applications
Document Number: 001-92584
Revision
ECN
Orig. of
Change
Submission
Date
Description of Change
**
4701892
KMVP
03/26/2015
New Application Note
*A
4765378
KMVP
05/14/2015
Updated Associated Part Family
www.cypress.com
Document No. 001-92584 Rev. *A
41
Designing for Low Power and Estimating Battery Life for BLE Applications
Worldwide Sales and Design Support
Cypress maintains a worldwide network of offices, solution centers, manufacturer’s representatives, and distributors. To find
the office closest to you, visit us at Cypress Locations.
PSoC® Solutions
Products
Automotive
cypress.com/go/automotive
psoc.cypress.com/solutions
Clocks & Buffers
cypress.com/go/clocks
PSoC 1 | PSoC 3 | PSoC 4 | PSoC 5LP
Interface
cypress.com/go/interface
Lighting & Power Control
cypress.com/go/powerpsoc
Memory
cypress.com/go/memory
PSoC
cypress.com/go/psoc
Touch Sensing
cypress.com/go/touch
USB Controllers
cypress.com/go/usb
Wireless/RF
cypress.com/go/wireless
Cypress Developer Community
Community | Forums | Blogs | Video | Training
Technical Support
cypress.com/go/support
PSoC is a registered trademark and PSoC Creator is a trademark of Cypress Semiconductor Corp. All other trademarks or registered trademarks
referenced herein are the property of their respective owners.
Cypress Semiconductor
198 Champion Court
San Jose, CA 95134-1709
Phone
Fax
Website
: 408-943-2600
: 408-943-4730
: www.cypress.com
© Cypress Semiconductor Corporation, 2015. The information contained herein is subject to change without notice. Cypress Semiconductor
Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any
license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or
safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as
critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The
inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies
Cypress against all charges.
This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide
patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a
personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative
works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress
integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source
Code except as specified above is prohibited without the express written permission of Cypress.
Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the
right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or
use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a
malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’ product in a life-support systems
application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges.
Use may be limited by and subject to the applicable Cypress software license agreement.
www.cypress.com
Document No. 001-92584 Rev. *A
42