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

It is up to the device sending the notifications (the GATT server) to decide when to send them, and the Bluetooth specification doesn't define any way for the client to control this. 

You could define a custom characteristic that allows the client to tell the server how often it should send notifications, but if you want to implement a standard GATT profile then this will not be compliant. 

It sounds a bit odd that you wouldn't get notifications when the value is the same, I thought this should be implemented out of the box. Do you have more information about this 'Enable notification' function that you are using?

Is this a part of the standard examples?

Best regards
Torbjørn

[Vipul2988]

Thank you for quick Response.

I am talking about ble_rscs_c_rsc_notif_enable()

I am trying to implement it on Standard Example first than I will implement on other custom application.

Do we have any Example on this " custom characteristic that allows the client to tell the server how often it should send notifications" ?

[ovrebekk]

Hi

Vipul2988 said:

Then how we can separate Notification case out of hrs_c_evt_handler? 

Not sure what you mean by this. Why do you need to separate the notification case out of the handler?

If you want to run some code on the client side at a fixed timer interval, whether or not you get a notification from the peripheral, there is nothing stopping you from doing this. 

Just run the repeated_timer_handler at the rate you wish, and use the old data value if no new data has been sent. 

Every time the BLE_HRS_C_EVT_HRM_NOTIFICATION event occurs you simply update the local variable, and then the next time the repeated_timer_handler runs it will use the new value. 

Best regards
Torbjørn

[Vipul2988]

Hello,

I have concern about battery life of the central device, peripheral is sending a notification let say 1 second interval. but I want to be notified in the interval of 5 minutes. And I can not modify the code of peripheral what should we have to do in this case.

[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