RSL10 current consumption with peripheral server UART sample code


I’m now evaluating current consumption of RSL10 (EVB) based on peripheral server UART sample code. I’ve encountered some issues and would like to seek advice in this matter -

  1. As compared to peripheral server sleep sample code, a relatively large transient current during setup segment (valid for both connectable advertising and connected profile) is no longer visible from my measurement.

Could please check if it’s normal and what is the reason behind it if it’s normal?

  1. From current consumption measurement, I noticed that TX current increases when DC supply voltage increases. It seemed to contradict to peripheral server sleep sample code of which I noticed TX current decreases when DC supply voltage increases.

Does this relationship (TX current is linearly proportional to DC supply voltage) valid for peripheral server UART sample code? If it’s valid, what is the reason that it behave differently?

  1. I noticed that advertising interval is inconsistent based on my measurement. Refer to attached, advertising interval is changing (43.3ms between 1st and 2nd, 46.0ms between 2nd and 3rd, 48.8ms between 3rd and 4th) instead of stay at constant 40ms which is pre-set by FW.

/* Advertising minimum interval - 40ms (64*0.625ms) */
#define APP_ADV_INT_MIN 64

/* Advertising maximum interval - 40ms (64*0.625ms) */
#define APP_ADV_INT_MAX 64

Could please advise if it’s normal and what to cause this variation if it’s normal?

  1. Refer to attached, there is approximately 10mA measured during idle segment (or any proper name for this region when there is no TX/RX activities). Is there any method (other than set it to sleep/standby mode) to further reduce this current?

  2. Refer to attached, there are some small spikes during idle segment (when there is no TX/RX activities). Is it normal or is it due to measurement error?


Hi @OS_com,

Please see my answers below:

This is because the ‘peripheral_server_UART’ sample code does not make use of the Deep Sleep mode between the advertising and connection intervals. The large current spike you were seeing at wakeup were caused by the RSL10 needing to recharge the system capacitors after they had drained during the sleep time. If your device never sleeps, you will never see the large capacitor drain and won’t need to charge them as abruptly.

I have confirmed these both on my end, and you are correct that these behaviors do not seem consistent or correct.

I will reach out to our internal firmware team to figure out why this is occurring.

This is the normal active current consumption range and is to be expected. Using Sleep/Standby modes are the best options to reduce the current consumption between intervals. You can also disable other unnecessary components (ie. UART or ADC interfaces) but this will not result in a substantial current drop like sleep mode would.

This is the expected behavior when in active mode. This could be caused by a variety of active running mode functionalities, from current leaking through Digital Interface (UART, ADC, etc.) to the need to recharge the DC-DC Converter or LDO.

Hi Brandon,

Thank to verify those reported issues. Kindly update me once you got more input from your internal FW team.

  1. TX duration is about 180usec as shown in attached connected profile. Based on spreadsheet as provided for peripheral server sleep sample code (please correct me if this spreadsheet is solely valid for peripheral server sleep sample code only), I estimate that this TX duration is equivalent to about 8 bytes TX payload. Could please advise which file (and location) I should refer in order to validate my assumption of TX payload in this case?

    Just curious, could I modify default TX payload for peripheral server UART sample code? If it’s possible, where and how I could modify the TX payload for connected profile?

  2. I understood from spreadsheet (as provided for peripheral server sleep sample code) that max TX payload is 248bytes for connected profile.

    Does max TX payload of 248bytes applicable to connected profile of peripheral server UART sample code too?

    Could I further modify max TX payload for connected profile? If it’s possible, please advise what is max permitted TX payload and the file that I should refer in order to modify max TX payload for connected profile?


Hello @OS_com,

Please see my follow-up below:

In this default configuration when no UART data is being received through the terminal, the only TX exchange that should occur is the Connection Supervision packet.

This sample application will send Custom Service Notification packets only when there is data that has been received over the terminal. The sample code will create a packet with variable size depending on ow much UART data has been prepared since the last Connection Interval had occurred.

Therefore, when using this sample in its default configuration, the only way to send a Custom Service Notification with a data payload is to pass in information over the UART terminal. There is no direct way to select the size of this information, as the firmware in the background will parse the UART terminal input into as many 244 byte notification packets as needed.

Yes, the Data Length Extension feature is negotiated in this sample application, so the limit of 248 byte notification payload can be used.

It should be noted, that this limit is actually 244 bytes when you strictly consider the Notifications user customizable data length, as other flags and information is required in the payload.

By default, the Custom Service Notifications are already configured to support the 244byte limit in this sample code, so you would simply need to call the ‘CustomService_SendNotification()’ with the length variable set to 244.

In the UART sample code, this is done following UART data being received to the terminal on lines 73, 77 and 84 of the ‘app.c’ project file.

As for a quick follow-up on our internal investigation into the strange current consumption you were seeing originally, the initial suggestion is to try and configure the firmware to run off of the Buck Converter (preferred for 1.8V - 3.3V), instead of the default LDO that is used (preferred for 1.25V - 1.8V).

This can be done by using the ‘peripheral_server_sleep’ sample firmware as a guide, as it offers a simple ‘#define’ and the matching logic that can be used to easily configure either the Buck Converter or LDO.

Hi @OS_com,

Apologies for the delay in getting back to you with the finer details from our design team.

Please see our feedback on the remaining two open items below:

This was found to be caused by both the DIO configurations used to support the UART interface and the use of LDO instead of the BUCK mode at 1.8V - 3.3V. It is the expected behavior, as when the VBAT voltage level drops, more current draw is needed to keep the DIO driver strength consistent. By removing the UART interface and configuring the firmware for BUCK mode, you should see the expected TX/RX current consumption levels as you sweep from 1.8V to 3.3V.

Our design team has confirmed that this is the expected functionality given the requirements of the Bluetooth Specifications. When an Advertising Interval of 40ms is used there will be a random, changing amount of extra time added to the interval (0-10ms) to make it easier to discover for Central devices.