Best communication scheme for a battery-powered Bluetooth LE display?

Question

I have a battery-powered design that I am working on using a Nordic NRF52832. The device is intended to connect to a smart phone and upon receiving a particular message from the phone, flash some LEDs in appropriate response to that message.

Intended runtime between charges is intended to be 3 months and there is space for a 200mAh LiPo Cell internally.

My question is - what is the most power-efficient communication scheme to use here? For a device that needs to simply send information periodically, waking up and advertising (possibly with a scan request / response after, possibly to initiate a connection and push data over than before disconnecting) followed by long periods of sleep seems to be the general way things work. The onus is then on the smart phone to periodically scan for advertisements, putting the higher battery drain on a more readily recharged device.

My best guess at the moment would be to have the device wake up periodically, advertise for a period of time with the hope that in that time the smart phone scans, detects that advertisement, connects, sends data to my device and then closes the connection. My device can then act on this data and / or go back to sleep.

Alternatively, it seems that the smart phone could periodically advertise if it had any data to share, and my device could periodically wake up, scan, and if it received an advertisement with appropriate data (assuming we can fit our payload into an advertisement) then react appropriately before returning to sleep. If a scan request / scan response was included in this we could effectively acknowledge receipt of the payload, avoiding the phone sending superfluous packets.

There is also the consideration of operating in an environment where several people in the same area have a phone and a device and interference where data from one phone was interpreted by an incorrect device would be unwanted. How do I go about targeting the data at a single device with the lowest possible power burden?

Additionally, if any advice could be given as to a suitable resource for me to read where I could get a better understanding of general best practice around queries like this I would be most appreciative.

Answer 1

You have several questions piled up here, coming short of simply asking "design this thing for me, so I can sell it to you better"...

Anyway, Re: power saving, the simple approach would be to synchronize clock on your device with the one in smartphone at the time of pairing. Then you would attempt to re-connect at set intervals and for brief time only, thus saving power. Re-synchronize clocks on successful connections.

Furthermore, if smartphone does not have any new data it can simply skip the session without establishing connection, which will save a bit more power too.

Re: interference, shouldn't SSP take care of this for you? And if that is not enough you can include some kind of GUID encrypted with time-varying cipher (good use for synchronized clocks) into handshake.

Re: Security, the security of the connection itself is pure software problem, coming on top of encryption (which is mandatory for 2.1 specification). Since you own the high-level protocol on both sides you have an option to make it as secure as possible.