Are there benefits of using the BLE's GATT API call of onCharacteristicChanged() versus getValue() of a characteristic?

Question

I noticed that when looking at the best practices for Bluetooth Low Energy(BLE), Apple mentions that using the API comparable the Android GATT's onNotificationChanged() is more efficient than calling calling getValue() on a characteristic that updates regularly.

"Though reading the value of a characteristic using the readValueForCharacteristic: method can be effective for some use cases, it is not the most efficient way to retrieve a value that changes. For most characteristic values that change—for instance, your heart rate at any given time—you should retrieve them by subscribing to them."

Link for reference

I am working on a device where we have multiple sensors (similar to the Text Insturment's CC2541). What is going on behind the scenes (i.e. Bluetooth antenna power, sensor activity) that makes the notifications more efficient?

I am seeing if it is beneficial to pace the transmission through setting the update period on the device, by pinging the device (the queries will be to get the reading 1-2 times a second for each sensor).

Answer 1

The difference is that generally event-driven behaviours are more efficient than polling behaviours. This is particularly important on a battery-powered device, such as a phone or an embedded sensor. Making a connection and reading a value requires transmission from both devices - consuming battery power.

Using notifications allows the device to transmit only when it has new data.

Consider a couple of different scenarios -

First, a temperature sensor. In many environments (rooms, even outdoors) temperatures are relatively stable - changing by a few degrees over minutes. If you poll the sensor every second then 99.99% of the time you are going to get the same answer as last time. If the sensor notifies when the temperature changes you will only transmit for 0.01% of the time - a huge saving in power.

Second, a heart-rate sensor which reports a "table" of rates and durations for that rate. The data here can change much more frequently and less predictably - you don't know when the wearer is going to start or stop exercising - but outside of these "edges" the heart rate may be quite stable - such as when resting, watching TV etc. In this case you could poll, but you are going to waste power during the stable periods. With notification the sensor can periodically notify that a new collection of heart rate information is available and the notification period will vary depending on how variable the heart rate is. The device could also notify immediately if it detected a serious but rare event (such as a heart-attack).

You can, of course, include a maximum time before a notification is forced on your sensor, such as 30 seconds, to ensure that the app receives regular updates even when "nothing" is happening - this still represents an 83% reduction in transmissions compared to polling twice a second.