sample BLE beacon app for measuring energy consumption

[bios-bob]

i'm looking for an extremely simple BLE beacon app, which advertises (say) at 1HZ and then enters a "low-power" sleep mode....

there are numerous samples included in the SDK -- where should i start????

i've tried the (eddystone) beacon sample....  works fine -- though it's not obvious how to change the advertising interval....

more important, however, the target is consuming ~300 uA between advertising events....

is there a sample app that enters some ON_IDLE state with current consumption in the 1-2 uA range???

[bios-bob]

i switched over to the `multiple_adv_set` example, where i only am enabling the non-connectible advertising; i also adjusted the advertising rate per my use-case....

power consumption between advertising events was still ~300 uA....

my use-case will also require transmission at 5dB....  how can i change the TX POWER used by the BLE stack ???   also, can i restrict the stack to use just *one* of the three advertising channels....

is there some reference documentation on the BLE stack which defines what i can/cannot do in my `main.c` ???

[Vidar Berg]

Hello,

For most examples, it is sufficient to disable the UART(s) to reduce the idle current to a few micro amps. This can be achieved by setting CONFIG_SERIAL=n in your project configuration file (prj.conf).

Attached below is a modified version I made of the multiple advertising sets sample you mentioned configured with an advertising interval of 1 second and a transmit power of 5 dBm.

Test sample (tested with SDK v2.9.1)

beacon_advertiser.zip

PPK2 Measurements

Advertisement event

Average current @ 3.3v

Advertisement channels can be disabled by setting the BT_LE_ADV_OPT_DISABLE_CHAN_3x flags in your advertisement parameters.

E.g.

Best regards,

Vidar

[bios-bob]

this is helpful....

if i want to use the UART while active, i assume that clearing UART.ENABLE will do the trick....

and what about the GPIOs???  except for those whose state i wish to retain, should i put them into their reset configuration???

and what about the clock....  do we switch to the 32.768 kHz source, or does the system do that automatically??? 

if not obvious, i'm benchmarking the nRF54L against other comparable wireless MCUs -- and each MCU takes a very different approach entering low-power mode...

i just want to put nordic in the best possible light ;-)

[Vidar Berg]

bios-bob said:

if i want to use the UART while active, i assume that clearing UART.ENABLE will do the trick....

Regarding this, sometimes you need to wait for TX or RX to stop before writing to the ENABLE register as mentioned in the UARTE chapter of the datasheet here: link. But I'm already doing this in the sample I posted via the suspend task here:

	/* Disable UART to reduce System ON idle current */
	err = pm_device_action_run(uart_dev, PM_DEVICE_ACTION_SUSPEND);
	if (err) {
		printk("UART suspend failed. (err %d)\n", err);
		return 1;
	}

bios-bob said:

and what about the clock....  do we switch to the 32.768 kHz source, or does the system do that automatically??? 

The 32K clock is enabled on startup and is used as the system timer for the kernel. It is always active. Our development boards use the 32KHz crystal oscillator by default, but you can opt to use the internal RC oscillator with calibration  by setting CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y in your prj.conf file.

Average current will be slightly higher with the RC oscillator as you can see from our  Online Power Profiler for Bluetooth LE  .

The HF clock (used as CPU clock, etc) is power on and off automatically:

https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/pmu.html 

bios-bob said:

i just want to put nordic in the best possible light ;-)

Good to hear :) Are you considering the nRF54L15 or nRF54L05? The latter will have slightly lower sleep currents since it has less memory. If testing on the nrf54L15 you may emulate this by powering off unused RAM sections.

[bios-bob]

that's certainly much better....  where was the TX power configured for 5dB....  it certainly measured higher when advertising....