KB: RSL10 Power Consumption Evaluation Guide

[RSL10 - Knowledge Base]

Table of Contents

Power Profiler

The spreadsheet tool included in the topic link below was designed to allow people using the RSL10 for its Ultra-Low Power BLE capabilities to generate an estimated average current/power consumption and battery life, given the user’s specific operating conditions and our models, created using samples captured from a functional RSL10 firmware implementation.

This tool will allow users to specify the Operating Mode, Advertising/Connection Interval, VBAT Voltage, Tx Payload, and Tx Power, which will then be input into our Peripheral Power Model to generate an estimate of the average current and power consumption that will be observed during firmware execution.

The topic also includes a collection of the RSL10 firmware files that were used to generate the samples and models used in the spreadsheet tool, so that users can validate the output estimates with their own RSL10 evaluation boards.

RSL10 Power Consumption & Battery Estimator

Measurement Equipment Setup

It is important to ensure that the Source Meter you are using has the required specifications to accurately capture and profile the advertising/connection events and sleep current.

The RSL10 can reach a minimum current of ~50nA while in sleep mode, and a maximum current of ~12mA while performing Transmit operations. This means that the Source Meter should be able to seamlessly auto-range its measurements to ensure properly captured data points, as well as capture current fluctuations as low as 50nA.

It is also important that the sampling rate of the Source Meter should capture an appropriate resolution to ensure that the advertising/connection events are characterized in their entirety.

Once execution of the firmware is started, the Source Meter can be configured to the expected VBAT voltage, and used to capture the current consumption waveform over at least one advertising/connection interval. This waveform can then be analyzed and dissected to determine the relationship between the various model inputs.

Hardware Setup

To achieve the optimal current consumption, the following jumper configurations and hardware setup can be used on an RSL10 SiP or QFN Evaluation Board:

Jumper Connection
P8 Removed
P7 Removed
SWD TMS Removed
SWD TCK Removed
SWD RST Removed
Power Options VBAT
External Power Source Meter

Software Setup

All of these software configurations are intended to be applied within the ‘peripheral_server_sleep’ sample application included within our RSL10 Software CMSIS Package. This sample project was used to generate all of the firmware files that were measured to create the models used in this tool.

Connectable/Non-Connectable Advertising

The ‘peripheral_server_sleep’ sample application offers an easy to use symbol definition within the ‘ble_std.h’ project file. This symbol definition sets all of the appropriate Bluetooth Low Energy Stack settings to achieve the desired Advertising type.

By setting the ‘#define APP_ADV_CONNECTABILITY_MODE’ variable to a value of ‘ADV_CONNECTABLE_MODE’ or ‘ADV_NON_CONNECTABLE_MODE’ , you will configure the Stack to operate using the respective advertising packet type.

Advertising Interval

To set the desired desired Advertising Interval within the ‘peripheral_server_sleep’ sample application, you can set the ‘# define ADV_INT_CONNECTABLE_MODE’ or ‘# define ADV_INT_NON_CONNECTABLE_MODE’ variables within the ‘ble_std.h’ project file to the expected interval value.

Please note that the resolution of these settings is in 625uS steps. For example, setting the Connectable Interval variable to ‘# define ADV_INT_CONNECTABLE_MODE 160’ would result in a 100ms Advertising Interval if Connectable Advertising packets are configured (160 * 0.625 = 100).

Connection Interval

In general, the default Connection Interval is determined by the Central peer device of the Bluetooth Low Energy connection, but a Peripheral device can provide preferred values during the Connection process if the Central firmware is designed to consider these values.

These preferred values can be set in the ‘peripheral_server_sleep’ sample application by setting the ‘#define PREF_SLV_MIN_CON_INTERVAL’ and ‘#define PREF_SLV_MAX_CON_INTERVAL’ variables within the ‘ble_std.h’ project file.

Please note that the resolution of these settings is in 1.25mS steps. For example, setting the Preferred Connection Interval variable to ‘# define PREF_SLV_MAX_CON_INTERVAL 32’ would result in a 40ms Preferred Connection Interval (32 * 1.25 = 40).

It is also possible to send a ‘GAPC_PARAM_UPDATE_CMD’ to the Peripheral Bluetooth Low Energy Stack, which will result in the RSL10 attempting to broker a new Connection Interval value with the Central device. In this use-case, the ‘#define PREF_SLV_MIN_CON_INTERVAL’ and ‘#define PREF_SLV_MAX_CON_INTERVAL’ variables should be copied into the appropriate payload variables within the ‘GAPC_PARAM_UPDATE_CMD’ message.

Tx Payload

The Tx Payload of an Advertising Event can be configured within the ‘peripheral_server_sleep’ sample application by changing the Advertising Data variable in the ‘GAPM_START_ADVERTISE_CMD’ Stack message. This Advertising Data is constructed in the ‘ble_std.h’ project file.

More information about the layout and contents of the Advertising Data can be found in the Bluetooth Core Spec.

The Tx Payload of a Connection Event can be configured within the ‘peripheral_server_sleep’ sample application by changing the variable and sized of the information being passed into the ‘CustomService_SendNotification()’ within the ‘app.c’ project file. This will automatically configure the ‘GATTC_SEND_EVT_CMD’ Stack message to send a notification of the specified size to a specific GATT characteristic.

When trying to send a notification with >27byte bytes of data payload, it is important to negotiate the Data Length Extension feature with the Central device to add support for a single notification packet payload of 244 bytes of data. This can be done using the ‘GATTC_EXC_MTU_CMD’ and ‘GAPC_SET_LE_PKT_SIZE_CMD’ Stack messages.

Tx Power

The ‘peripheral_server_sleep’ sample application offers an easy to use symbol definition within the ‘calibration.h’ project file that will configure the RSL10 Tx Power and the necessary Power Supply settings to achieve the set Tx Power goal.

By setting the ‘#define RF_TX_POWER_LEVEL_DBM’ variable to the desired Tx Power level, this configuration will be done automatically.

Please note, the ‘calibration.h’ project file only supports the automatic configuration of 0, 3 and 6 dBm by default, so if another Tx Power is required, please refer to Table 5 in Section 5.3.3 of the RSL10 Hardware Reference for the VCC voltage that must be used to achieve a given Tx Power. In this situation, the ‘Sys_RFFE_SetTXPower()’ call in the ‘app_init.c’ project file should also be updated to the desired Tx Power.

Evaluating Current Measurements

Each of the model input parameters has a direct and linear impact on the current consumption and duration of certain parts of the advertising/connection events. To generate each of the model components, these events were dissected and a linear equation was generated for each of its dependent inputs. The estimates provided by each part of the model will then be combined to create an overall average current/power estimate for the specific operating conditions.

A graphical representation of each of the events (Connectable/Non-Connectable Advertising & Connect) and their given dependencies is available below, as well as in the respective sheet of the spreadsheet.

‘peripheral_server_sleep’ HEX files for Power Measurements

Connectable_Hex.zip (1.9 MB)

Non_Connectable_Hex.zip (1.9 MB)

Connected_Hex.zip (1.9 MB)


Thank to prepare such useful power evaluation guide. I have several questions which need further clarification -

  1. After quick comparison between excel sheet and RSL10-D product datasheet, I noticed that TX peak current consumption (VBAT = 3V, Tx power = 6dBm) is 8.4mA (excel) vs 12mA (datasheet, page 7) whereas RX peak current consumption (VBAT = 3V, 2Mbps) is 3.4mA (excel) vs 2.73mA (datasheet, page 6).

    Could please kindly advise why there is large difference in term of TX peak current consumption? Also, which figure (8.4mA or 12mA) is more practical?

  2. In Introduction Worksheet (section Methodology), you mentioned that standalone flash loader (available in RSL10 utilities package) can be used to download each of model FW files onto RSL evaluation board for measurement.

    How to locate this standalone flash loader? Is it under RSL10 software package or RSL10 software utility apps? Any user guide or procedures in order to use standalone flash loader for downloading FW onto RSL evaluation board or any PCB built-in with RSL10 chipset ?

  3. In Introduction worksheet (Assumptions), there is an assumption to use 2Mbps & Data Length Extension in Connected model. Is it possible to adjust this data rate (2Mbps)? If yes, how could I do it?

  4. How possible to modify software in order to measure current consumption with LDO regulator? If yes, how could I do it?

  5. I refer to above section “Tx Power” and there is a statement “Please note, the ‘ calibration.h ’ project file only supports the automatic configuration of 0, 3 and 6 dBm by default”. However I noticed that Tx power = +6dBm, 0dBm, -4dBm from drop-down list in excel sheet. Is it correct?

Thank for advice.

Hi @OS_com,

Please see my answers to your feedback and questions below:

I think you might have the Excel and Datasheet values flipped in this situation. If you are using either of the Advertising Sheets, they make use of 1Mbps data rate. This brings the 2.73mA in Excel much closer to the 3.0mA reported in the Datasheet for 3V @ 1Mbps.

If you are using the Advertising Sheets as reference for this Excel value, it is also likely caused by the discrepancy between 1Mbps in the Excel Sheet versus 2Mbps in the Datasheet. 12mA is likely more accurate if you would like to do 2Mbps data rate for Advertising.

The Standalone Flash Loader is available in the “RSL10 Software Utility Apps”. It comes with a PDF document intended to outline the basic functionality and use. It is essentially an abstracted J-Link tool that uses JTAG functionality to place the firmware into the RSL10’s Flash using a simplified UI.

For Advertising this can be done by setting the ‘tx_pref_rates’ & ‘rx_pref_rates’ variables within the ‘GAPM_SET_DEV_CONNFIG_CMD’ data structure to 2Mbps.

For Connected mode, this is by default negotiated with the Central device. If the Central supports negotiation on Connection, the ‘GAPM_SET_DEV_CONNFIG_CMD’ data structure values can be used, but if the Central requires negotiation after Connection you can use the ‘GAPC_SET_PHY_CMD’ stack command.

Unfortunately, the first revolution of this spreadsheet only supports DC-DC mode. There are plans to include LDO mode in future Spreadsheet releases, so we will take this feedback into consideration when we plan what new features the next release will include.

If you are referring to how this can be done within our ‘peripheral_server_sleep’ sample application, there is a ‘#define’ within ‘app.h’ called ‘VCC_BUCK_LDO_CTRL’ that can be set to a value of ‘VCC_LDO_BITBAND’.

This is correct. We made changes to our ‘calibration.h’ file to apply the necessary RSL10 power settings to best support -4dBm TX Power. This was done to expand the range of TX Power selections available in the Spreadsheet to lower values than 0dBm. If you do not wish to further optimize the RSL10 power settings, the values for 0dBm will also support any lower TX Power needs.

Hi Brandon,

 Thank for prompt reply.

Q1. Yes, it was my mistake to mess up measurement data for RX peak current consumption. Thank to correct it.

Q4. Refer to your reply “For Advertising this can be done by setting the ‘ tx_pref_rates ’ & ‘ rx_pref_rates ’ variables within the ‘ GAPM_SET_DEV_CONNFIG_CMD ’ data structure to 2Mbps.”, I’m able to locate ‘GAPM_SET_DEV_CONNFIG_CMD’ in “ble_std.c” project file.

Below is what I found -

gapmConfigCmd->tx_pref_rates = GAP_RATE_ANY;
gapmConfigCmd->rx_pref_rates = GAP_RATE_ANY;

Does it mean that I can define GAP_RATE_ANY to 2Mbps or any value? OR how should it be done correctly as I’m not familiar with coding?

Q6. So far I’m able to locate all variables (connectable/non-connectable advertising, advertising interval, connection interval, Tx power) as mentioned in your introduction except Tx payload.

I can find “GAPM_START_ADVERTISE_CMD” in the “ble_std.c” file instead of “ble_std.h” project file. Is it correct? Anyway, I can’t find any variable in order to configure Tx payload of an advertising event. Could you please kindly advise?


Hi @OS_com,

No problem at all, please see my follow-up suggestions and answers below:

Our implementation of Bluetooth Low Energy supports only 1Mbp & 2Mbps. To change this as you require, you can make use of the enumerated values in the ‘gap.h’ file. In our Eclipse IDE, you can use the F3 key while you have highlighted a enumerated value to open the definition. That is to say, by highlighting ‘GAP_RATE_ANY’ and pressing F3, Eclipse will automatically open the enumerated definition and you can easily find the other option available.

In the case of advertising, the TX Payload refers to the advertising data that is packed into every advertisement that is sent out.

The advertising data can be set within the ‘GAPM_START_ADVERTISE_CMD’ data structure, specifically the ‘info.host.adv_data’ structure value.

You will need to format this advertising data with the proper flags and length variables (so that central devices can parse it effectively) as defined in the Bluetooth Low Energy spec, so it might make sense to look into this layout before you start filling your advertising data.

Hi Brandon,

Thank for replies.


So far I can’t find “gap.h” file as quoted but I can find “app.h, ble_bass.h, ble_custom.h, ble_std.h, calibration.h” files from project “peripheral_server_sleep”. Does it hidden somewhere and could please kindly share procedures in order to retrieve the file “gap.h”?


I can find “info.host.adv.data” as suggested in your earlier message. However I’m still bit confuse after go through the codes.

For simplicity, could please advise what is default TX payload when I tested with “peripheral_server_ sleep” sample application?

My objective is to get TX payload in order to estimate average total current (as shown in your excel spreadsheet).

Q7. How could I confirm which data rate (2Mbps or 1Mbps) is applied when I tested with “peripheral_server_ sleep” sample application as provided by ON Semi?

I found below code from “ble_std.h” file -

#if defined(CFG_LIGHT_STACK)
#define CFG_ADV_INTERVAL_MS 5000

So does “#define APP_SLEEP_2MBPS_SUPPORT” mean that applied data rate is 2Mbps in this case? Please kindly correct me if I made wrong assumption.

Thank for advise.

1 Like

Dear Brandon,

I have another question, other than above-mentioned enquiries, which need your advice again.

Based on information provided, so far I was able to perform current consumption measurement for connectable advertising and non-connectable advertising. However, I’m not yet able to test connected profile.

My initial idea is to pair RSL10 device with another BLE device such as laptop or handphone and to establish connection. From there, I should be able to perform current measurement on connected profile. However this idea is not working as I always lock to either connectable advertising or non-connectable advertising even there is pairing done successfully.

Is there anything wrong with such approach? Could please kindly advise if there is anything else that I need to do in order to lock to connected profile?


Hi @OS_com,

Please see my advice below,

This is one of the core BLE CMSIS components that is included in the CMSIS Pack instillation and is automatically added to the Include list in projects using BLE. All specific BLE include files can be found in ‘{CMSIS_Pack_Directory}/PACK/ONSemiconductor/RSL10/{Pack_Version}/include/ble’.

As a note, if you are using our Eclipse based IDE, you can highlight an enumerated variable, right click and select the ‘Declarations’ option to automatically open the file where the enumeration is defined.

By default our ‘peripheral_server_sleep’ sample application will advertise using the Device Local Name and the Company Specific ID. By default, the Local Name is left empty to save power, so the advertising payload will be:

3 (advertising flags) + 1 (Company Specific ID Flag) + 1 (Company Specific ID Length) + 2 (Company Specific ID Value) = 7 Bytes

If you have updated the ‘ble_std.h’ file to have a name stored in the ‘APP_DFLT_DEVICE_NAME’ variable, this byte count will be increased by ‘2 + Length of Name’ bytes.

The code you have found above will allow support for 2Mbps to be achieved, but in order to make use of the 2Mbps you must: configure this within the GAPM Set Device Configure Command structure (for advertising @ 2Mbps), or negotiate the PHY rate with the Central device during Connection (the peripheral will share its preferred rate at connection time, but the Central will not always consider this) or by using the PHY Negotiation ‘GAPC_SET_PHY_CMD’ stack command (this will force the Central to consider the rate and allow it if both devices support it).

Both the laptop and smartphone approaches that you have outlined should allow you to capture the current consumption after the connection is established (ensuring you are using Connectable Advertising). During our development of this model, we made use of our RSL10 BLE USB Dongle and the associated BLE Explorer software to easily debug the BLE Central connectivity.

Can you please provide more detail on what is occurring that is preventing you from capturing the current consumption while connected? One thing to note is that you must have the device configured and connected to your source meter before connecting to the device, as powering down to attach the source meter will cause the connection to drop.

Hi Brandon,

Thank for replies.

I would like to clarify with an example and kindly correct me if I have wrong understanding.

Assume now I set ‘APP_DFLT_DEVICE_NAME’ variable = “BLETESTING”, so total TX payload = 7 + 2 + 10 = 19 byte right?

In this case, are there any measurements that I can perform in order to verify if central device is supporting 2Mbps or simply 1Mbps only (since central device will have final say about data rate during connection)?

Also, just wonder if you have ever compared current consumption between “forced” 2Mbps and “forced” 1Mbps? If yes, what is approximately difference of current consumption between “forced” 2Mbps and “forced” 1Mbps?

Today I repeated current measurement with connectable advertising profile. I noticed that connected profile can be captured only during short moment when laptop is trying to establish connection (pairing) with RSL10 EVB. Once pair up (between laptop and RSL10 EVB) is done successfully, then I noticed that RSL10 will enter connectable advertising profile again. Is it normal?

Hi @OS_com,

This is correct. In this configuration you will see 19 bytes of the advertising packet utilized.

This can be done at the Software level by using the ‘GAPC_SET_PHY_CMD’ & ‘GAPC_SET_PHY_IND’ Stack messages to keep track of any PHY negotiations occurring. If a PHY negotiation is triggered, both devices will receive a ‘GAPC_SET_PHY_IND’ message with the new rates stored inside of the structure.

There is no straight forward way to figure out if the Central supports 2Mbps, and the simplest options are to: read the BLE support specifications for the Central device, or to attempt to use a ‘GAPC_SET_PHY_CMD’ to set 2Mbps and see if the ‘GAPC_SET_PHY_IND’ returns 1Mbps (Not supported by Central) or 2Mbps (it is supported by Central).

This has not been explicitly compared, but a good estimate can be found by comparing the TX Current for the Connected model (measured at 2Mbps) in the RSL10 Power Consumption & Battery Estimator with the TX Current for the Advertising model (measured at 1Mbps).

It is also worth noting that the 2Mbps rate used will result in a TX Current consumption that lasts ~1/2 of the time length due to the faster rate being ~2x faster for the same data payload.

It is possible that the laptop is not maintaining a constant connection. By default, our ‘peripheral_server_sleep’ sample applicaiton will only support 1 concurrent BLE connection, so it should not continue advertising while a connection is active.

It has been noticed that some Central devices will not maintain a Connection if there is no specific BLE role that is being fulfilled. To ensure the BLE Connection is maintained properly, we recommend using our BLE USB Dongle and BLE Explorer software to test on Windows devices, or using a smartphone BLE debugging application (nRF Connect for example).

Hi Brandon,

Thank for your suggestion. Now I’m able to capture connected profile consistently after I downloaded BLE Explorer software and used it to connect to RSL10 device.

I noticed that connection interval = 60ms from my measurement. Just wonder if this interval is set by central device or it’s configurable in FW such as advertising interval? Could please point out the location if it’s configurable in FW?


Hi @OS_com,

It is good to hear you have the Connected mode setup and measured! For your follow up question, please see my response below:

This can be done from either the Central side or the Peripheral side.

On the Peripheral side, you can setup the firmware to send a ‘GAPC_PARAM_UPDATE_CMD’ after a Connection is established, loaded with the desired Connection Interval.

On the Central side (assuming you are still using the RSL10 BLE USB Dongle & BLE Explorer software) this can be done easily using the BLE Explorer UI. By opening the “Setup > Connection...” tab you can set the default Connection Interval that the Central device will apply when Connected, or after you have Connected with a device you will have the option to “Update Params” within the Device control window.