Power optimizing NRF beacon

[pbn4]

Hello,

I have read the questions on power optimizations in nrf chips:

devzone.nordicsemi.com/.../ devzone.nordicsemi.com/.../

I wanted to use SDK11 example -> BLE -> Peripheral -> Beacon Transmitter as a reference for my code, yet there is a note saying that this example is not power optimized. (I want to code simple advertising, same as in the example) The main loop uses power_manage to enter "System Sleep on idle" power mode.

How is that not optimized? How can we improve?

Another questions:

• Will entering a "system off" power state (loosing state if not retained) will be more power efficient than a "system on" optimization?
• Does coming back from "system off" on gpio level sensing require running the initialization code like the device was turned off and on? If so - is "system off" basically an ability to run our code from reset on a GPIO trigger?

EDIT:

I also wanted to know if I enable advertising in the BLE controller, does going to "system off" disable advertising? (I don't fully understand "system" term in this case, is BLE RF controller a peripheral of the system and turns down with "system off"?

[endnode]

Hi pbn4,

Yes, nRF5x chips have basically just "sleep during system on" and "system off". In normal app design chip (through SD or app code if it runs without stack) spends most of the time (for broadcaster only such as "beacon" it can be even >99%) in "wait for event" aka "sleep". However whole system continues in the code execution after very next "wake on event" with all state variables preserved. If you want to go better (basically if you want to go to <1uA range) you need to use "system off" but then wake-up (even you can do it by timer/GPIO/NFC sense/similar event) works as system reset so you need to perform whole start-up procedure including all HW peripherals' init, BLE stack (Soft Device) if used etc. So yes, going to "system off" will interrupt advertisement and you can use it only if you implement your own timer to wake-up and start advertising again (also note that standard BT Smart compliant advertisement - e.g. as implemented by Nordic SD - has little variations around adv. interval to prevent collisions in case some broadcasters get accidentally synchronized periods/phases, but that might be a detail which you can neglect at the first design).

Cheers Jan