How to force the notification to turn on from the server not the client?

[June6]

uint16_t buffer[4];
	
buffer[0] = p_nus->handles1.cccd_handle;                  // cccd handle
buffer[1] = 2;                                            // cccd attribute size = 2
buffer[2] = 1;                                            // 1 = enable notifications
buffer[3] = crc16_compute((uint8_t *)buffer, 6, NULL);     // CRC-CCITT (0xFFFF)
err_code = sd_ble_gatts_sys_attr_set(p_ble_evt->evt.gap_evt.conn_handle, (uint8_t*)(buffer), 8, BLE_GATTS_SYS_ATTR_FLAG_SYS_SRVCS); 

if(err_code == NRF_SUCCESS)
{
    p_client->is_notification_enabled1 = true;  // Enable notification
}

I add this code in 'static void on_connect(ble_nus_t * p_nus, ble_evt_t const * p_ble_evt) '  on the sever. But I still got an err_code NRF_ERROR_INVALID_DATA. Softdevice is s132nrf52611. Any suggestions to force the notification? I use the SDK version 15.3.0.

[Karl Ylvisaker]

Hello,

Any suggestions to force the notification?

I am not sure I understand exactly what you mean here.

A server / peripheral may not force the client / central to accept notifications. The notification has to be enabled by the central / client itself, before the peripheral / server can start sending notifications.
The only time that the peripheral may send notifications "unprompted" to the central, is if the two devices are bonded, and the central has enabled the notification in a previous connection.
Perhaps if you could detail your problem or use-case some more, I would be able to advise you better.

If this is not what you were asking about, please elaborate on what you would like to achieve.

Best regards,
Karl 

[June6]

My customer has a product that uses ti's Bluetooth chip, which can automatically enable notification and send data once Bluetooth is connected, without clicking the enable notification button on the app. The customer wants to achieve the same effect.

[Karl Ylvisaker]

Thank you for elaborating, now I understand what you meant originally!

If you would like nRF Connect ( for desktop? ) to automatically reconnect and receive notifications, you need to use the autoConnect feature, and bonding. Bonding will ensure that the notification-enabled information is kept between connections, and autoConnect will automatically connect to your peripheral.
You should then configure your GATT client ( in the nRF Connect application ) to enable notifications for the custom service you have created.

June6 said:

My customer has a product that uses ti's Bluetooth chip, which can automatically enable notification and send data once Bluetooth is connected,

This does not have anything to do with the particular manufacturer, since it is a feature of the BLE specification.
You can see an example of how this is implemented in an example in the unmodified ble_app_uart_c example from the SDK.

Best regards,
Karl

[June6]

Thank you for your reply. But It's not automatic reconnection, it's automatic notify

[Karl Ylvisaker]

June6 said:

Thank you for your reply.

No problem at all, I am happy to help!

June6 said:

But It's not automatic reconnection, it's automatic notify

My apologies, I should have been more explicit in my previous reply.
There is no way for a peripheral to force the central to enable notifications. The only possibility here is to have the central enable notifications for specific services / characteristics.

The nRF Connect for Desktop application with its accompanying connectivity firmware does not support automatic enabling of notification following service discovery.
The desktop application provides a GUI button for doing this.

However, if you are creating your own desktop application, you can easily have your central device automatically enable notifications.
This is demonstrated in the Heart Rate Collector example in the pc-ble-driver github repository. For your application, it sounds like you should take a look at what happens following a CONNECTED event, particularly in the function hrm_cccd_set.

Please let me know if anything still should be unclear, or if you have any other questions!

Best regards,
Karl

[June6]

Hi Karl

Thank you for your detailed explanation again. This time I know it clearly. 

This means that notification can only be enabled on peripheral devices by a central device or mobile phone, right?

[June6]

But I did add the above code in the sample program, which has the effect of forcing the peripheral device to turn on the notification and upload data after the mobile phone is connected with it. And the mobile app (NRF connect) did not click the enable notification.

[Karl Ylvisaker]

Hello June6,

June6 said:

But I did add the above code in the sample program, which has the effect of forcing the peripheral device to turn on the notification and upload data after the mobile phone is connected with it. And the mobile app (NRF connect) did not click the enable notification.

What you did in the initial tickets code, is to tell the SoftDevice on your peripheral device that CCCD is set, and notifications should be sent. However, you central device will not know about this, and as such it will not accept the incoming notifications, since it has not asked for them.

The reason why your nRF Connect central might still accept the notifications could be that the CCCD information for this device is still cached from a previous connection.
I.e if you previously bonded with the peripheral device, set up CCCD properly, then disconnected - flashing the peripheral device with the modified firmware - and reconnecting to the same peripheral device, the central might remember this peripheral device by its address, and see that it has indeed enabled notifications for this service. Thus, it will accept incoming notifications immediately.
Could this be what you are observing?

June6 said:

I thought of another way. Can peripheral devices enable notification when they are connected, just like setting channel characteristics, to write CCCD values by themselves?

The peripheral may never "enable notifications", it can only provide a service which uses notifications. When the central does service discovery, it will discover the service and see that it uses notifications - the central may then choose to enable notifications from this service. What you are doing in your previously shared code is telling your peripheral device that the central has already enabled notifications - but nothing changes on the central's side. The central still does not have notifications enabled, but the peripheral will think that it does.

Please do not hesitate to let me know if anything still should be unclear, or if you have any other issues or questions! 

Best regards,
Karl