How to enable notification on the peripheral side?

[evan]

Hi , I am using nRF51822 as a ble_peripheral to send the sensor data to the phone. I already add a characteristic with the property of notify , and it could work when using MCP to test. But now I want to send the data autonomously without the enabled notification from phone. I find a function called 'sd_ble_gatts_value_set' to enable the cccd value but it do not work as I expect. I researched some questions about cccd , as said it could be retained by both sides when bounding. I am not exactly aware of what that means.So I wonder if I could enable notification on the peripheral side without enabling from phone and how to do this? Thanks. Forget to mention that I got the err_code of NRF_ERROR_FORBIDDEN when calling the function of 'sd_ble_gatts_value_set' to set the cccd value with cccd handle.

[Tony Wu]

Hi Evan,

To be clear, by "peripheral side" I assume you mean "server side"? Your phone is the GATT client in this case, and your nRF51822 + sensor is the GATT server which has data that your phone wants to receive. Just wanted to make the technicality clear since there's nothing stopping a GAP peripheral from being both a GATT server and a GATT client.

Under that assumption, it is not possible to autonomously send notifications of a characteristic value from your nRF51 (server) to your phone (client) without the client enabling notifications by writing a "1" to the CCCD for that characteristic. The reason for that is nicely written in the Client Characteristic Configuration Descriptor section of the Getting Started With Bluetooth Low Energy if you want detailed information. But long story short, the server cannot autonomously send notifications to the client because the server has no idea if the client knows about that characteristic yet (it may not have performed a full service or characteristic discovery), so the client won't be able to identify the characteristic handle that comes in the notification from the server anyway if the client has not discovered that characteristic.

And to answer your question about retaining the CCCD while bonding: if the client bonds with the server and enables the notification for a characteristic, then on every subsequent connection while they are bonded the CCCD for that particular characteristic will automatically be set enable notifications since the server now remembers that the client wanted notifications for that characteristic.

So in your case, the closest thing to autonomous notifications to your phone is to bond with the nRF51 on the first connection, and then enable notifications to the characteristics that you want. This way your nRF51 will remember that your phone wants notifications and automatically start sending them on subsequent connections.

Hope this helps.

[evan]

Thanks a lot for your help, Tony. The link is quite useful for me to understand the mechanism of CCCD. After reading the link of Bluetooth Low Energy Pairing Guide,I understand the mechanism for storing and restoring the bonding information and system attributes ,which is important to freely reconnect without do the bonding procedure again and mainly include CCCD,but the document is too old so I can't find the functions related to System Attributes in the latest SDK . Then I tried several methods with respect to modifying the System Attributes which includes CCCD configuration. Finally I saw this question about 'automatically start notification', the link is righthere.By following the steps using two main functions sd_ble_gatts_sys_attr_set and sd_ble_gatts_sys_attr_get , I finally enable the notification successfully on the GATT server side.Now we could notify the value as long as building the connection without waiting the enabled notification from GATT client. However ,if we want to let the GATT client side(I use Android mobile phone as the GATT client) receive the value notified we should firstly set the notification enable on the GATT client side ,notice that just setting the notification enable and don't need enable the CCCD on the GATT client. As tony said , doing the work like this dose not make any meaningful sense because we don't know the client's state whether it is ready to receive the value notified from server, it is kind of wasting power. I use this just to test when doing the specific connection of two known peers,actually we put the control right to the server not the client with the prerequisite of client all the time running to wait the notification from server.Anyway, thanks tony again.