How to change Frequency of Notification(Subscription) of read value in BLE Central Example Code?

[Vipul2988]

In BLE Central Example like HRS and RSCS,

Central has Enabled the notification  when event handler find Case : BLE_RSCS/HRS_C_EVT_DISCOVERY_COMPLETE.

But what if we want to read the value in fixed timed interval. Which function we need to use?

Also I found that Enable notification function reads value only if that value changes.

What changes will be require if we want to read/notify that value also if it is not changing ?

I am using nRF5_SDK_17.0.2 with nRF52840-DK Board 

[ovrebekk]

Hi

What kind of battery are you using?

The BLE protocol is optimized for very low power consumption, and even if you are receiving notifications every second this should not make a big impact on average system current. 

Since you are controlling the central you can decide the connection parameters, and by using a long connection interval you should be able to ensure that the Bluetooth connection itself doesn't add a lot to the power consumption. 

To estimate the average current draw with different connection parameters you can use the Online Power Profiler (OPP). 
With the OPP you can also add TX or RX data to each connection event, and see how much this affects the average current. 

That being said, if you only want to get an update on the data every 5 minutes, why can't you just unsubscribe to the notifications, and subscribe again 5 minutes later?

Essentially follow this flow:

1) Unsubscribe to notifications
2) Wait 5 minutes (using app_timer)
3) Subscribe
4) Wait until a notification is reported 
5) Repeat from 1)

Best regards
Torbjørn

[Vipul2988]

Hello,

This will really helps. Thank you..!

We are using Lithium-thionyl chloride battery for central about 4500mAh.

One more question here, if we subscribe notification and Unsubscribe notification uses the TX I believe, is that correct? from central to peripheral .

So how that will be different from reading the value from peripheral instead of enabling the notification. 

I have read in so many tickets that Nordics Experts are advising to Notification function than Reading.
what will be the best thing in this case? in terms of power and performance.  

[ovrebekk]

Hi

Vipul2988 said:

We are using Lithium-thionyl chloride battery for central about 4500mAh.

That is a pretty big battery compared to the coin cells used in many Bluetooth applications (a CR2032 coin cell has a capacity of around 230mAh for comparison). You might want to have very long battery life with such a big battery, but I don't expect a couple of extra writes and reads over the Bluetooth connection to make a measurable impact. 

Vipul2988 said:

One more question here, if we subscribe notification and Unsubscribe notification uses the TX I believe, is that correct? from central to peripheral .

That is correct. The central is already sending empty packets to keep the connection alive, so the only difference is that you are adding a small TX packet to write to the CCCD characteristic, adding 5 bytes to the payload (3 bytes for the ATT header, and 2 bytes for the CCCD value). 

Vipul2988 said:

So how that will be different from reading the value from peripheral instead of enabling the notification. 

Good point. If the characteristic supports read then it will be more efficient to send a read request rather than to enable and disable notifications.  

Vipul2988 said:

I have read in so many tickets that Nordics Experts are advising to Notification function than Reading.
what will be the best thing in this case? in terms of power and performance.  

Notifications are the most efficient way to send data from the server to the client. Having the client issue reads is quite slow, since you are only able to get one packet through per connection event (the host is not able to respond to the read request immediately, and you will have to wait for the next connection event before the data is sent). 

In most applications it is more important for the client to be informed every time the data changes on the server side, which is what notifications are designed for, rather than keep the communication to an absolute minimum in order to save power. 

In your case it should work OK to only issue reads once in a while if you don't care about receiving all the data updates, but please do some checking in order to verify that the data changes also when notifications are disabled. 

Some peripheral devices might assume that you don't care about data updates at all if you disable notifications, and might not update the value in the stack at all. 

Best regards
Torbjørn