RE: Implementing 'Wake on BLE' on nrf52832

Susheel Nuguru — Mon, 23 Nov 2020 09:39:01 GMT

Your understanding is correct Terry.

Just to add, that the time between the device advertising (plus some post processing) the device sleeps most of the time. Larger advertising interval would directly be equal to larger sleep times and hence larger power saving on your device.

RE: Implementing 'Wake on BLE' on nrf52832

Terry V — Thu, 19 Nov 2020 15:04:56 GMT

Thanks Susheel Nuguru, I looked at the blinker example.

Do I understand this correctly:

- after everything it setup and run, it enters into idle state via idle_state_handle()

- during this idle time, BLE is still advertising - so if a device connects, I'll get an event occurring in ble_evt_handler() and I just continue processing from there

Is this correct?

RE: Implementing 'Wake on BLE' on nrf52832

Susheel Nuguru — Thu, 19 Nov 2020 07:34:43 GMT

Hi Terry,

Very interesting question.

[quote user=""] But I've also seen things like 'wake from system OFF' when triggered by GPIO, LPCOMP, NFC. Is it possible to have the radio somehow trigger a wake from System OFF? [/quote]

You are on the right track in terms of understanding. As you can see the System OFF mode, only four wakeup sources are available to wake the system from OFF mode. This is the deepest sleep mode that saves most of the power switching of most of the regulators and keeping the power only to the wakeup sense mechanism.

Unfortunately, RADIO is not one of the wakeup sources for System OFF, so we cannot use this type of sleep in your case.

I think your concerns are what is Nordic is all about. And like what you said below

[quote user=""]From my reading it seems the way to go is to put the device into sleep mode, then wake occasionally to advertise and then stay awake if the app happens to be there and connects.[/quote]

This is where Nordic's solution and BLE are so special. When you make the chip to go to system idle (__WFE sleep) then you can architect your software to disable all of the peripherals and the BLE stack (softdevice) will wake the application automatically if there are any advertising (or any other radio events) that needs application processing. So in short what you need is already in place and all you need to do is handle those specific advertising events in such a way to keep the application alive until you need and make it go to sleep.

How often you want the system to wake up to advertising/scan events depends on the intervals you choose to configure the radio. I would recommend you to try out a simple nRF5_SDK_17.0.0_9d13099\examples\ble_peripheral\ble_app_blinky example and measure the power it consumes. Play with different advertising intervals and measure again to see if the power consumption matches your usecase.