This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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.

Parents
  • 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 

  • 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.

  • That's OK. Thank you very much!

    Best regards,

    June6

  • June6 said:
    That's OK. Thank you very much!

    No problem at all, June6. I am happy to help!

    Please do not hesitate to open a new ticket if you should encounter any issues or questions in the future.

    Good luck with your development!

    Best regards,
    Karl

  • Hi, Karl

    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?

    Looking forward to your reply,

    June6

  • 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

Reply
  • 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

Children
No Data
Related