BLE sleep mode and advertizing with anormal power consumption


We have noticed an increase of power consumption with the BLE sleep mode enabled.
After the last advertizing peek, an increase of current occur after 2,5 seconds going from 20nA to 200nA.
With an advertizing period lower than 2,5 seconds, everything is fine. When the advertizing period is higher than 2,5 seconds, we observe the current increase for the remaining time until the next advertizing message. If i configure an advertizing period of 3 seconds, the excess of current consumption last for 500ms.

My objective is to reduce power consumption by disabling advertizing period for some time, but i don’t gain anything with this behaviour. If the advertizing is disabled for 30 seconds, i ll have a low current of 20nA only the first 2,5 seconds then 200nA during 27,5 seconds!

The RSL10 is in BLE sleep mode during that time, has OnSemi any explanations related to this behaviour
in regard of the BLE stack?

It could be related to the light stack overconsumption described by Peripheral_server_sleep overconsumption

Our fimrware is built with the full stack from sdk 3.5, not the light stack version. The difference about consumption with the post you mentionned:

  • the overconsumption we observe is permanent, not from time to time, as long the advertizing period is configured > 2,5secs, or the RSL10 remain in BLE sleep mode >2,5secs.
  • the consumption when the RSL10 enter BLE sleep mode is 20nA as expected only for 2,5 secs, then rises to 200nA until next wakeup.

I ll investigate with an eval board and the peripheral_server_sleep code sample if i reproduce this behaviour

Hi @rvs ,
I have conducted some tests on the RSL10 evaluation board configured for the lowest consumption possible as described by Peripheral_server_sleep overconsumption

I have flashed the RSL10 with the test binary you provided ( 1Mbps version of peripheral_server_sleep with an advertising of 5s and a RF amplifier set to 0dBm):
peripheral_server_sleep_1mbps_5s_0dbm.hex (419,8 Ko)

The board is powered with a battery at 3.6V.
We observe the same beaviour as described previsously, except that the excess current consumption appears 3,5 seconds after the last advertizing message.
We can see it does occur every time and not from time to time compared to the post you mentionned.

We can oberseve series of periodic current pikes every 20ms for about 2,5 seconds until the next wakeup for the advertizing message.

Does the .hex you provided was compiled with the light stack? From the graph, it seems the MCU supply is LDO.

I have some doubt about the observations from the post you mentionned. It seems to me the overconsumption occuring from time to time are more MCU reboots with POR reset. I would be interesting to drive a DIO during the boot process until the first adv message.
It looks like the problem is present with any BLE (full or light) stack, even with supply voltages above 2,2V (in my test 3.6V) and is permanent.

I resume our firmware config:
clk 48MHz, BLE Non light stack, 2mbps, mcu supply DCDC buck, powered battery @3.6V
Results: increased concumption 2.5 seconds after last adv message from 20nA to 200nA. It occurs with adv period longer than 2.5 seconds and permanent until next wakeup.

  • I ll run more tests the peripheral_server_sleep with Non-light stack and changing settings as mcu system clock @48Mhz.

-I had a try to compile our fw with the 1Mbps version but it does not boot, i have to inverstigate this point. ( I have removed the define APP_SLEEP_2MBPS_SUPPORT from sleep.h and set gap_rate params with tx/rx pref_rates to GAP_RATE_ANY and GAP_RATE_LE_1MBPS

Hi @sylvain.mariteau & @rvs,

This is the expected behavior when using sleep mode on the RSL10.

The reason this happens is due to the capacitors that are present within the VCC line. Given the extremely low current consumption in sleep mode, the device can run off the residual power in these capacitors for a limited amount of time (ie. with more Memory Retention this cap will drain faster, and with less Memory Retention this cap will drain slower).

After these capacitors are drained, you will see a higher current consumption as the device will be required to pull the current from the source instead of the capacitor. ~200nA is the expected steady state current with our default ‘peripheral_server_sleep’ sample application after ~2.5s of sleep.