BLE Architecture for Low-Power Remote Control?

[AgreeaBLE]

Howdy DevZone! I'm brand new to BLE, and have some beginner questions on the best way to architect a project for ultra-low power consumption.

Here's what I want to make:

Two battery-powered nRF52840s, one with a button and one with an LED. Both are idle until the button is pressed, waking up the Sender. The Sender tells the Receiver to light up the LED for a second, and then everything shuts off. Pretty simple stuff.

What I'm wondering is, what is the best BLE setup to minimize the idle power usage on both sides? Which device should be Central, which should be Peripheral? Should I use a Broadcast model instead? How does Connection Interval play into all of this? What sort of sleep modes can I use with the nRF52840 to conserve energy while still remaining BLE responsive?

Here are some more details that might affect the architecture:

• The button will only be pressed a few times per day. Otherwise the two devices do nothing. There's no need to maintain a persistent connection or share status between them except after a button press.
• It's acceptable to add up to a second of latency between button press and LED light-up, if it reduces overall power consumption.
• The communication needs to be reliable; if the Sender and Receiver are within BLE range of each other, the LED needs to light up (as opposed to a "best effort, 50% success" setup).
• Peak power consumption (after button press) isn't a concern, just overall idle-state consumption / battery drain.
• I'm open to using ANT or Thread if they're better suited for this specific application.

Thank you so, so much!

[Susheel Nuguru]

Hi,

I think that it is not a matter of which protocol you use in this use case, The most difficult thing to solve in your case is to sync up advertising and scan the window so that when there is a button press, then the receiver is on at that time.

1) Transmitter side seems to be able to use deep sleep (System Off) since it has nothing to do unless the button is pressed. So you can wake the system from deep sleep on the button press which will reset the chip and you can initialize the protocol and trasmit the packet within a second without any problem. If you do not think that the latencies involved in initializing the protocol stack every button press is not acceptable then you need to live with idle sleep (__WFE)

2) On the receiver end, which is the scanning side, it is very difficult to achieve good power optimizations and make sure that the receiver radio is on at the time of the button press. There is no straight answer for this as the power optimization vs making sure the scanner is on at the time of button press are conflicting interests. So you need to find a balance by choosing the proper scan interval and the scan window. Probably do some benchmark with different values. You might not be able to do a deep sleep (System off sleep) on the receiver side, but idle sleep between the scan windows is easily achievable. 

If the button is pressed for a longer duration (like more than a second) then probably you can increase the scan interval to one second on the receiver side and get much better power consumption results.