BLE Central Role, libraries and power saving schemes

[Carl]

Hi 

I am very new to BLE...

We are looking into a new industrial product design that will be battery powered, and be capable of communicating with BLE sensors (Mesh not required), my initial investigation has highlighted that the Central Role is very power hungry, and there are no true out of the box solutions (coding would seem to be required on the BLE module/SoC to implement the Central Role.

I have had a quick look at your development environments, and your 'Bluetooth low energy central tutorial' (pdf only). Are there any additional libraries available? or is it just the API and sample code?

Also what if any power saving scheme/s can be employed on the BLE Central? (and a brief pointer to the implications would be handy)

We do not really need the additional features that Bluetooth V5 introduced (Mesh, long range, and higher data rate), power consumption is key. We are keen to avoid obsolesce, but do not want to incur the increased power requirement s of Bluetooth V5.0, can we have the best of both worlds? (Can your SoCs operate in mode that gives the power advantages of Bluetooth 4.2?)

Any help would be greatly appreciated.

Kind Regards

Carl

[Carl]

Hi Hung Bui

Thanks for the information. The information about increated current demand in a central role was from multiple sources, It is my understanding that a peripheral BLE device can spend much of its time asleep, while a central device will need to be constantanly awake in order to scan for advertising from the peripherals, thus its average current consumtion will be very much larger than the average peripheral . As I said I am new to this, is this not the case? Is it possible for a device in a central role to sleep? 

I assumed that in order to scan for advertising the RX circuitry would need to be on, So I looked at the average and peak RX currents, these were higher on Bluetooth 5.0 BLE modules and SoCs thus I assumed that in order to cater for the increased range and speed of V5.0 a price in increased current needed to be paid. I did not think about the potential for power saving by using 2Mbps option, as the amount of data that we will need to send is quite small, however if the dominate current demand is not the RX circuitry but the TX then this is worth considering:). (I had assumed that the increased data rate was achieved buy broadcasting on multiple channels, is this not the case?)

I have a limited understanding of BLE, but if we limit the amount of time that the central listens to advertising, will we not miss advertising packets, forcing the periperals to re-broadcast, more often? (power saving on central = power increase on peripheral) is this not the case?

I have had a quick look at your tutorials/examples they seem very helpful.

Many thanks for your continued support.

Carl

[Hung Bui]

Hi Carl, 

I would suggest to have a look at our video on getting started with BLE here: https://youtu.be/BZwOrQ6zkzE?t=731

I also have a blog series here: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/bluetooth-smart-and-the-nordics-softdevices-part-1 . Part 2 would be more relevant. 

What you were thinking of when the central have to scan all the time for advertising packet is only applied before the connection is established. After the connection is established, you don't need to keep the central in scanning mode. And the central can sleep between each connection event. 

My understanding is that you want to create a battery powered device that can act as a central and you will have other peripheral devices (also not main powered) that report data to the central ?

If it's the case, you can create a period when the central can scan continuously for 5-10 seconds (then sleep for a minute for example) until it established the connection to all the peripherals. It then will stop scanning and only keep the connection with the peripherals. If the connections are maintained, it will keep running like that. If a connection is dropped or if the user want to add a new connection, it will switch to the scan mode again and wait for a connection. Of course it will consume more power than a normal peripheral, but you still can achieve a quite good battery life with this approach.