[RSL10 - Knowledge Base]
Table of Contents
- Power Profiler
- Measurement Equipment Setup
- Hardware Setup
- Software Setup
- Evaluating Current Measurements
- ‘peripheral_server_sleep’ HEX files for Power Measurements
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 |
P9 | VBAT |
P7 | Removed |
P10 | VBAT |
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)