Questions | Blogs | Tutorials | Resources | Tour | About GitHub/Nordic | nordicsemi.

com

all unanswered unresolved search in questions... ASK A QUESTION

User menu
How to minimize current consumption for BLE application
86
on nRF51822 [closed] Username or e-mail

current consumption Password

How to minimize current consumption for BLE application on Anonymous

or sign up
1061 4 7 4 Sign in
nRF51822
asked Feb 20 '14

Stefan Birnir Sverrisson

Nordic employee
15941 10 22 33
updated Sep 24 '14

edit retag flag offensive reopen report spam

Closed as "the question is answered, right answer was accepted" by

Petter Myhre at Sep 19 '14

Comments
add a comment

3 answers Sort by oldest newest most voted

Recent blog posts

nRF51 Low power modes and power Stefan Birnir Sverrisson
Nordic employee
200 15941 10 22 33 6 Things to Know about
profiles documentation answered Feb 20 '14 Bluetooth Beacons
Posted Sep 22 '17 by Rose Martin
The low power modes for the nRF51 series are System On and updated May 28 '16
System Off. You can read about them in the nRF51 Series Creating a Keil project
for a Bluetooth Mesh
Reference Manual v3.0 sections 12.1.5 and 12.1.7. Additional information are also given here. example
Posted Sep 19 '17 by Kristian
If you are using ANT or BLE softdevice for the nRF51, look at the "Power Profiles" chapter in Skordal
the Softdevice Specification document for the softdevice you are using, S110 SDS, S120 SDS,
Using millis() like in
S210 SDS and S310 SDS. The power profiles show what peripherals are drawing current during a Arduino.
radio event. Current consumption numbers for the different peripherals can be found in the Posted Sep 18 '17 by schef
nRF51822 PS v3.1. Look at table 32 for current consumption numbers for System On (I_ON) and Flashing nRF5x firmware
System Off (I_OFF). Table 36 shows current consumed by the radio peripheral for LDO mode. using any dumb terminal
For example, I_TX,0dBm is the current consumption used when radio TX is enabled with 0dBm program via standard
transmit power. I_RX,1M is the current consumption when radio RX is enabled for BLE or ANT. serial COM port
Posted Sep 18 '17 by Nguyen
Table 37 then shows the same numbers when DCDC mode is enabled. LDO mode and DCDC Hoan Hoang
modes are explained later in this post.
How to Debug the nRF52
Interrupts Useful Tips
Measure current consumption Posted Sep 13 '17 by Yaniv Nis
Look at the Measuring current section in the User guide for the nRF51-DK development kit Recent questions
(third revision nRF51), evaluation kit (second revision nRF51) or the "Current measurements"
section for the development kit (second revision nRF51) to find out how to set up the kit in Central receiving more
than 23 bytes as a
order to measure current. In addition to the text in the user guide, make sure you power-reset notification
the nRF51 after flashing your firmware to it. After flashing, the nRF51 stays in debugger-mode, Posted 7 hours ago by DavidC
which consumes excessive current (~1mA). When the nRF51 is power-reset, it will enter
In BLE Central code, is
normal-mode where actual current consumption can be measured. It is also possible to use there a way to get peer
nrfjprog.exe (part of nrf Tools) with the command "nrfjprog --pinreset" in order to enter address from storage?
normal mode. Posted 7 hours ago by nordicdev

In BLE Central code, is it

To test current consumption for the nRF51 low power modes without softdevice, try out the possible to delete bond
System Off mode example and the System On mode example.. Expected current consumption info after connection?
for the System Off mode example example is 0.6uA with no RAM retention and 2.6uA for the Posted 7 hours ago by nordicdev

System On mode example. To initially test current consumption with these examples, I want generating a
disconnect the all external circuits from GPIO pins as well as the debugger/programmer. To run 16MHz clock to output
those examples on evaluation kit (PCA10001 boards) look at these threads (1) (2) for extend ic,how to do
it?
Posted 8 hours ago by chenlmm
To test current consumption for a BLE application, use the Power profiling application in the
nRF51 SDK, or e.g. the heart rate application. In a BLE application, the radio is enabled hid keyboard params
Posted 8 hours ago by micele
periodically to transmit advertising packets or connection packets in so called BLE
advertising/connection events. Between BLE advertising/connection events, the nRF51 should
be in System On low power mode and should consume ~4uA. It is however hard to see the Question Tools
current consumption between those events on a multimeter if the advertising/connection
interval (the time between advertising/connection events) is small. If you modify the 18 followers
application to have long advertising interval, the reading on your multimeter should stabilize subscribe to rss feed
between advertising events, and you should be able to read the expected ~4uA. The
advertising interval can be adjusted from 20ms to 10.24s, and can be set to e.g. 4 seconds in Stats
the power profiling example by modifying the following define at the top of the main.c file:
Asked: Feb 20 '14
Seen: 49,465 times
#define APP_CFG_CONNECTION_INTERVAL 4000
Last updated: May 27 '16

To test the power profiling application, press Button 1 on the nRF51-DK (PCA10028) in order Related questions
start the advertising after you upload the code to the nRF51-DK board and power-reset it. Note
nRF51822 mKit Current
that when connection is established, the connection interval is determined by the central
consumption [closed]
device which is normally relatively short. Since the power profiling application does not send
connection parameter update request to the central, the connection interval stays short and Current consumption nRF8001
current consumption is therefore relatively high when connected.
how to recognize pin that caused
Troubleshooting GPIOTE PORT event (sense
nRF51 consumes excessive current after entering either System On low power mode or System interrupt)?
Off mode, the most likely reasons for that are:
Measuring Current Consumption -
Checking Debugger Mode and
The nRF51 is in debug mode. Solution: Power reset the chip in order to enter normal mode.
Normal Mode
The nRF51 remains in debug mode after power reset on custom board. Solution: connect an
external resistor to SWDCLK pin as described on this thread No current consumption benefits
running code from RAM
There is a leakage current on GPIO or SWD pins. Solution: Disconnect everything from debug
interface and GPIO pins. To disconnect the debug interface on PCA10001 boards set the SW4 High background current of BLE
switch on your PCA10001 board to OFF beacon [closed]
You have configured GPIO pin as input with no pull. For solution, see answer on this thread
Reducing power consumption for
You are using evaluation kit or development kit and LEDs are connected on your board. paired devices
Solution: Disconnect the LEDs or disable them in software. When using nRF51-DK or nRF51-
Dongle, LEDs are not included in the current measurement. Idling with low-speed timer

You have enabled a peripheral before entering System On low power mode. Solution: Disable Current consumption of if
the peripheral in question before entering System On mode. For System Off mode this is not condition in for(;;) loop
needed as all peripherals are powered off in System Off mode.
sd_app_evt_wait() doesn't give
You have explicitly enabled "Constant Latency mode". Solution: Enter low power mode
microamps consumption
before entering System On low power mode with NRF_POWER->TASKS_LOWPWR = 1;
You are using the nRF51822 Beacon kit. See solution on this thread.
You have enabled GPIOTE in event or task mode. For solution, see this thread.
Calcualate/Estimate current consumption
As for now, we do not have an online tool to calculate current consumption for the nRF51
series. However, there are some common scenarios given in this blog post, both when
advertising and when in a connection. If you need current consumption calculation for a
specific profile, please send your profile to us and we can calculate expected current
consumption for you. You can do that by registering a support case on www.nordicsemi.com.
Go to "My Page" and select "REGISTER NEW CASE". The profile parameters that are needed
are:

Accuracy of 32kHz crystal or if you are using internal 32kHz RC.

Supply voltage
TX power

For calculating current consumption during advertising:

Advertising interval
Amount of advertising payload data in bytes for each advertising packet
Continuously advertising or periodically advertising.
Application processing time for each advertising interval

For calculating current consumption during connection:

Connection interval
Slave latency
RX payload in each packet
TX payload in each packet
Number of RX packets to receive in each connection interval (max 6)
Number of TX packets to send in each connection interval (max 6)
32kHz master clock accuracy
Application processing time in each connection interval

For calculating current consumption from SPI, UART or TWI transmission: - What interface is
used, SPI, UART or TWI - Transmission speed - Data amount - Transmitting, receiving, or both

Also specify use of other peripherals, if any, e.g. TIMER, GPIOTE, etc.

Please provide as much as possible of these parameters above to enable us to measure the
current consumption for your profile.

Estimate battery life

Battery life can be calculated when you know the average current consumption of the device
and the energy capacity of your battery. Below are some calculation examples for battery
lifetime for batteries with different energy capacity:

Average current consumption of device: 20 uA

Energy capacity: 220 mAh (typical CR2032 coin cell battery)
Battery lifetime: 0,22 Ah / 0,00002 A = 11,000 hours = 458 days

Average current consumption of device: 100 uA

Energy capacity: 220 mAh (typical CR2032 coin cell battery)
Battery lifetime: 0,22 Ah / 0,0001 A = 2,200 hours = 91 days

Average current consumption of device: 100 uA

Energy capacity: 1000 mAh
Battery lifetime: 1 Ah / 0,0001 A = 10,000 hours = 417 days

Choice of 32 kHz clock source

Also, in your design you should consider what low frequency clock source to use. As the nRF51
reference manual states there is a choice of three low frequency clock sources, external
crystal, internal RC and the synthesized clock. Using the synthesized clock is of really no use in
terms of current consumption since it will require the 16 MHz clock to be constantly enabled.
Using a high accuracy external crystal is clearly the best choice in terms of current
consumption.

Another choice is to use the internal 32kHz RC oscillator and calibrate every 4 seconds to
maintain accuracy within 250 ppm. A motivation for using the internal 32kHz RC is either to
decrease BOM or to save space on PCB. Using internal low frequency 32kHz RC clock instead of
20ppm external crystal will add around 10 uA current consumption compared to 20ppm external
crystal. The internal 32kHz RC needs to be calibrated every 4 seconds and obtains frequency
tolerance of 250ppm.

When initialising the softdevice with ble_stack_init() function call in the main function, select
the NRF_CLOCK_LFCLKSRC_RC_250_PPM_TEMP_4000MS_CALIBRATION option when using the
internal RC clock. For further information on choice of 32kHz clock source with a softdevice,
look at this thread.

Choice of 16 MHz external crystal

To minimize current consumption, choose 16MHz external crystal with minimal startup
current consumption. For this purpose you should choose a crystal with low load capacitance,
i.e. around 9 pF instead of the specified maximum of 16 pF for the nRF51.

For a general guide on 16MHz clock sources for the nRF51, look at this thread.

Use of timers
If using BLE, use the application timers that are generally used in the BLE examples in the SDK.
Those use the RTC1 in the background which is very power efficient. Look at i.e. the
ble_app_hrs example which has several application timers implemented.

Low power mode with BLE softdevice

Most BLE examples in the SDK will include the power_manage call in the main function. This
call uses the sd_app_event_wait() softdevice call (or power_manage()) which enables the
System On low power mode, which keeps current consumption to a minimum.

To put a device into System Off mode when using the softdevice, call sd_power_system_off()
function.

The softdevice uses RTC0 to keep track of time and to know when to wake up for the next BLE
connection event. The RTC0 will eventually wake the chip up and the softdevice will carry out
the action needed for the BLE connection event, which includes receiving and sending
packages. When it is done, execution will continue where it left off in the application after
sd_app_event_wait() command. Normally in BLE examples in the SDK, the sd_app_event_wait()
command is inside the main loop, therefore code residing in the main loop will execute once
and then the sd_app_event_wait() is called again and the chip will sleep again in System On
low power mode until the next BLE connection event.

What sd_app_event_wait() actually does is to disable the CPU. All peripherals (e.g. SPI, UART,
TIMER, ...) that are enabled before calling sd_app_event_wait() will still be enabled. The CPU
will actually wake up on any interrupt, i.e. it will wake up for BLE connection/advertising
events, softdevice callbacks or peripheral interrupts (e.g. SPI, UART, TIMER, ... interrupts).

Tuning connection parameters

Control of current consupmtion during connection is mainly a question of tuning the Bluetooth
connection parameters. If your "connection interval" parameter is large, communication will be
slow and your device will consume little current during connection and packet delay will be
relatively large. Setting short connection interval will enable larger throughput and relatively
short packet delay but your device will consume more current. "Slave latency" is another
bluetooth parameter that allows the device to not respond to number of packets sent from the
host. This will decrease current consumption of the device while still allowing data bursts with
high thoroughput.

A typical scenario for transmitting data on a button press is to have BLE connection with
relatively low connection interval but with high slave latency. Low connection interval will
enable your device to send packets frequently, i.e. to have a good response on a button press.
High slave latency will allow your device to not send packets on every connection event,
thereby saving current.

Slave latency is a special BLE connection parameter. Information about the slave latency
parameter is found on the Bluetooth Developer site, A quote from this site about slave latency:

Slave Latency Slave latency allows a slave to use a reduced number of connection events.
The connSlaveLatency parameter defines the number of consecutive connection events that
the slave device is not required to listen for the master. As a result, slave device can skip a
number of connection events if it does not have additional data resulting in power savings.

For example, for an energy sensitive application, you choose relatively long connection
interval, e.g. 4 seconds, in order to save energy of the peripheral. This will make the
host/master send a packet every 4 seconds, also requesting the slave/peripheral to respond
with a packet transmission (to tell the master that the slave is alive, which prevents link loss)
which will also contain data if the slave/peripheral has some data to send. An alternative
would be to create a connection interval of 1 second and have a slave latency of 3. This would
make the master send packets to the slave every second but the slave would be obligated to
respond only to every fourth packet. This will therefore not create an increase in current
consumption for the slave compared to the 4 second connection interval, but instead will
decrease slave data delay and enable data bursts as well from the slave with higher
throughput.

If you are to connect with an iPhone there are however constraints from Apple on how
connection parameters can be tuned. This apple document states the following in the section
about Connection Parameters: The connection parameter request may be rejected if it does
not comply with all of these rules:

Interval Max * (Slave Latency + 1) 2 seconds

Interval Min 20 ms
Interval Min + 20 ms Interval Max
Slave Latency 4
connSupervisionTimeout 6 seconds
Interval Max * (Slave Latency + 1) * 3 < connSupervisionTimeout

To modify the connection interval in any BLE example in the nRF51 SDK, adjust the following
constants that are located at the top of the main file:

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(500, UNIT_1_25_MS) /**< Minimum acceptable connection interval (0.
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(1000, UNIT_1_25_MS) /**< Maximum acceptable connection interval (1

which means that the connection interval will be 0.5-1.0 seconds, but it is really up to the
central device to set the connection interval. More information on the connection parameter
update procedure is found on this thread. Similarly, the slave latency is adjusted by modifying
this constant:

#define SLAVE_LATENCY 0 /**< Slave latency. */

Tuning Advertising parameters

Current consumption during advertising mainly depends on the advertising interval, which is
adjusted by modifying the following constant:

#define APP_ADV_INTERVAL 40 /**< The advertising interval (in units of 0.62

The longer the advertising interval the less current will the device consume during advertising.
However, when connecting to a central device, increasing the advertising interval will
normally not decrease current consumption as it will take longer for the central device to
discover the peripheral device. The result is that current consumption will be lower for the
peripheral during advertising, but it will normally have to advertise for a longer time,
therefore, energy consumed before connecting to the central will generally be more or less the
same as when short advertising interval is chosen.

For some scenarios, it is convenient to advertise periodically, and that will save current
instead of having the device advertise continuously. The timeout for the advertising can be
adjusted by modifying the following parameter:

#define APP_ADV_TIMEOUT_IN_SECONDS 180 /**< The advertising timeout in units of second

Another parameter that effects the current consumption during advertising is how many
payload bytes are sent in each advertising packet. It is e.g. typically 20%-25% lower current
consumption during advertising if 10 payload bytes are sent in each advertising packet than the
maximum of 31 bytes. Therefore, it may be beneficial in terms of current consumption to only
place primary advertising data in the advertising packet and place all secondary data in the
scan response packet, as advertising packets are sent much more frequently than scan response
packets.

LDO mode vs Low Voltage mode vs DCDC mode

The three different modes are described in the nRF51 Series Reference Manual, Power
chapter. Schematics for the three different modes are shown in the nRF51822 Product
Specification (PS), Reference Circuitry chapter.

The specified current consumption is 0.6uA for System Off mode and no RAM retention but if
you operate it it low voltage mode it is 1.6uA, refering to note 1 in table 27 in the PS v2.0. So.
If you intend to use external switching regulator you could possibly save some current in low
voltage mode for the reason that it accepts supply power down to 1.75V, but then you have
1uA higher current consumption in both System On and System Off modes. Since you can run
the LDO mode almost as low, or down to 1.80V, I would assume that choosing the LDO option
provides lower current consumption for most applications.

The internal DCDC converter can potentially decrease power consumption of the device. For
explanation how a DCDC converter potentially lowers current consumpiton, look a this thread.

The DCDC is safe to use with the third revision nRF51 hardware and softdevices S110 8.0.0,
S120 2.0.0, S130 1.0.0, S210 5.0.0, S310 3.0.0 or more recent softdevices. The DCDC mode can
also be used safely with third revision nRF51 for proprietary protocols. For the second revision
of the nRF51 hardware, or softdevices older than mentioned above, we do not recommend
customers to use the DC/DC together with the BLE or ANT softdevices, as this has been
discovered to create radio disturbances. The DCDC can optionally be used with propriatery
protocol after carefully considering its operation limitations described in the nRF51 Series
Reference Manual version 2.1, Power chapter. Further recommendation for the DCDC mode is
given on this thread

Compiler optimization
Enable compiler optimization in order for you application to be executed in as few instructions
as possible. This will make the code execute faster and finish sooner and will therefore save
power. To enable compiler optimization in Keil, select Options for Target -> C/C++ tab and set
Optimization to Level 3 and check Optimize for Time. In order for you to efficiently debug
the application code in Keil, the setting should be however Optimization: Level 0 and
Optimize for Time should be unchecked.

Execute code from RAM

According to nRF51822/nRF51422 PS v3.1 table 34, current consumption can be decreased by
executing code from RAM instead of from flash. How to execute code from RAM is described
here.

Setup of SPI, UART, TWI interfaces

Since the SPI, UART and TWI more or less have the same current consumption for different
transmission speeds (see nRF51822 PS, Electrical Specifications chapter) it is most energy
efficient to choose maximum transmission speed. This will require the SPI/UART/TWI to be
enabled for a minimal time, therefore saving current. Disabling a peripheral is usually done by
writing a Disabled value to the peripheral's ENABLE register, and will ensure that they don't
keep the clock running when it isn't actually needed. More general information for
enabling/disabling peripherals is given on this thread.

Low Power UART When you enable the UART on the nRF51822, it will consume a lot of
current, ~1mA constantly. The strategy is to only enable the UART when data transmission is
needed. There are primarily two methods for achieving this, one is to manually configure two
GPIO's for controlling this, second method is to enable the UART in LOW_POWER mode, an
UART example with low power mode is available on Nordic's Github. The LOW_POWER mode is
implemented in nRF51 SDK 9.0.0 and older SDKs.

The LOW POWER example will have flow control enabled in a specific LOW POWER mode
where the nRF51822 is woken up and UART is enabled when CTS goes low. nRF51822 will set
RTS low when it is ready to receive data. So the peer UART device must set nRF51822 CTS low
when sending data to nRF51822 and set it high again when finished transmitting data. Further
information on the functionality is given in the Readme for the UART Low Power example.

To Enable the UART, both RX and TX, execute the following code:

NRF_UART0->ENABLE = 1;
NRF_UART0->TASKS_STARTTX = 1;
NRF_UART0->TASKS_STARTRX = 1;

If you only need to receive data, enable the UART and only start RX, it will consume less
current than starting both TX and RX. Similarly, if you only need to transmit data, enable the
UART and only start TX.

To disable the UART, execute the following code:

NRF_UART0->TASKS_STOPTX = 1;
NRF_UART0->TASKS_STOPRX = 1;
NRF_UART0->ENABLE = 0;

Low Power SPI master Similar to the UART, the SPI is high current when enabled. To enable
low current consumption, you should therefore only enable the SPI when there is data to be
transmitted.

To enable the SPI peripheral 0, execute the following code:

NRF_SPI0->ENABLE = 1;

To disable the SPI peripheral 0, execute the following code:

NRF_SPI0->ENABLE = 0;

Low Power SPI slave The SPI slave peripheral is low power by default, meaning it consumes
close to no current when the CSN line is high (chip select for the nRF51 is not set by the
connected SPI master device). When the CSN line is set low by the SPI master, the SPI slave is
enabled and consumes ~1mA. The SPI slave goes back into low power state when the SPI
master ends the SPI transaction by setting the CSN line high.

GPIOTE
For info on current consumption of the GPIOTE peripheral and how to set it up for low current
applications, take a look at this thread

edit flag offensive link

Comments
4 My goodness -- this may as well be a bible. Fantastic post!
syntroniks(Jun 21 '14) edit convert to answer

great post, thanks

hassan789(Sep 7 '14) edit convert to answer

Create an Application Note out of that...

azdem(Sep 16 '14) edit convert to answer

 azdem(Sep 16 '14) edit convert to answer

1 Superb post
Aashish Patel(Sep 23 '14) edit convert to answer

Just in time, Thanks!

YeLun(Feb 12 '15) edit convert to answer

Takk Stefn! Could you clarify: When advertising, does the arm wake up from __WFE every advertisement
interval?
Arnar Birgisson(Dec 8 '15) edit convert to answer

Sll Arnar! Yes, the nRF51 wakes up on every advertising interval. The way it works is that internally the
softdevice uses RTC0 low power timer to keep track of time and to generate an interrupt periodically
when it is time to advertise. When the softdevice is enabled, you should call sd_app_event_wait() instead
of __WFE in order to enter System On low power mode. The chip wakes up from
__WFE/sd_app_event_wait() on every interrupt, executes the interrupt handler (in the case of an
advertising event, there is a high priority interrupt handler exectuted internally in the softdevice) and
then execution continues in the main loop until __WFE/sd_app_event_wait() is called again.
Stefan Birnir Sverrisson(Dec 8 '15) edit convert to answer

Excellent documentation. But unfortately, I couldn't open some links. They might have been moved to
some other location. Eg: Link to "System Off mode example". Thanks
vineeshvs(Apr 14 '17) edit convert to answer

Hi, the links are still not opening. Do we have some other links for system off and on mode examples?
vineeshvs(Aug 5 '17) edit convert to answer

1 Hi, let me helps you. So you want any example for nRF51 or 52? Have you seen the Infocenter here? I' sure
you did. Now go to SDK section, find your SDK version, let's say the latest v14.0.0. And now go to
Examples and HW Peripherals (as you are interested into how particular HW feature works on the lowest
"HAL" level) and voila, it's there! Now the structure of Infocenter page copies how actual SDK archive is
organized so finding the project and code is simple.
endnode(Aug 5 '17) edit convert to answer

add a comment

This is a great answer. But remember to vote on the question as Petter Myhre
Nordic employee
well!
5 18476 3 14 23
answered Sep 19 '14

Artem
1 1 2 1
updated Sep 20 '14

edit flag offensive link

add a comment

Helpful,very good! Leo Fu

1 1
0 answered May 16 '14

edit flag offensive link

add a comment

faq | terms and conditions | give feedback Follow Nor dic on: