What is the difference between a BLE central reading from a peripheral versus a peripheral notifying the central in term of resources drained?

[helpme]

Suppose a BLE central needs to get sensor data from 10 peripheral sensors. Given that there is a limit to the number of connections a BLE central can have, is it better for the central to read from peripheral because it uses lesser resources compared to notify?

[Hung Bui]

@helpme: Could you give me more information on why you think read command would use less resource compare to notify ?

As far as I know, sending notify is more efficient than read command when thinking of the number of packet needed to send data (1 packets vs 2 packet).

The only advantage of read command I can think of is that the client (central) doesn't have to wait for notification but has control of when to get it.

[EDITED] Another advantage of using notify is to avoid the delay by slave latency. The peripheral can wake up in the middle of the latency sleeping period to send notification, when with read, the central have to wait until the next wake up of the latency sleeping period to get the data which only comes on next connection event after the read command.

[helpme]

I was assuming that for read, the central can turn off the connection after reading. For notify, the connection needs to remain on all the time because there is a publish-subscribe relationship to maintain. So, for 10 peripheral sensors, the central can take turns to read. However, for notify, 10 connections need to be always on. Is this understanding incorrect?

[Hung Bui]

Well, you don't really need to keep the connection to be always on to receive notification. You can simply connect, wait for notification and disconnect right after that.

If you have bonded with the device, you don't have to enable CCCD on every connection. So you can configure the peripheral to send the notification right after it get connected then can immediately disconnect. I think it's the most efficient way of transmitting small data when remaining in low power.

[Bill Siever]

To be available the peripheral will need to be advertising, so there will still be periodic radio traffic.

My guess is that it really depends on the particular parameters of Advertising Interval vs. connection timing (Connection Interval, Slave Latency, and Connection Supervision Timeout). When notifying the peripheral can skip several connection events (slave latency) if there isn't an update. If this total skip time is long enough it may consume less power than advertising would.

[Hung Bui]

@Bill: You are correct, to be able to be discovered the peripheral must advertise. And actually advertising usually consume more power than stay in connection with the same interval because by default we advertise in 3 channels, when a connection packet is sent on one channel.

And I also forgot about slave latency, notification has an advantage that it can wake up in the middle of the latency sleeping period to transmit data, when with read, the central have to wait until the next wake up of the latency sleeping period.

[Hung Bui]

However, it doesn't need to periodically advertising though. How long it would take the peripheral to wake up and start advertise before it can be connected is depend on how the central be configured to do scaning. If the current consumption on the central is not the concern, it can stay in scan mode with big scan window and can have higher chance to catch the advertising packet. I guess in this case helpme hits the constrain on the maximum peripheral can be connected to the central at the same. Currently on S120 we only support 8 connections and on S130 it is 3 for now.