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

Should we decide if a notification should be sent or is it the role of the SoftDevice ?

A characteristic can be read/write/notify.

I have seen cases in Nordic's examples where there is an internal boolean "is_notify", and when the user sets it from the central device, you record that, and depending on this you send, or not, a notification when needed. (see the uart example in ble_nus.c and variable is_notification_enabled)

In other examples, it seems that the SoftDevice does this for us. (see ble_hrs.c for instance, no such variable)

What is the correct use case? Thanks P.S Im using sdk 8.1

Parents
  • Hi

    I don't think there is right or wrong way to do this. I think the thought process in the examples is that the Heart Rate Service is a Bluetooth SIG defined service, which defines the heart rate measurements notifications as mandatory (the peer has no read permission). So it makes sense to simply start a timer and start calling the notify function right away. No need to explicitly check if the peer has enabled notifications since we know that the peer expects them because of the service definition.

    Regarding the nus example on the other hand, which is a Nordic proprietary service, notification is not mandatory and the peer has both read and write permissions. So then it might make sense to explicitly store the notification status somewhere for use around the application.

    I believe the way it's done in the SDK is intended to make the examples flexible. Although I guess one could argue that this also make them harder to understand.

Reply
  • Hi

    I don't think there is right or wrong way to do this. I think the thought process in the examples is that the Heart Rate Service is a Bluetooth SIG defined service, which defines the heart rate measurements notifications as mandatory (the peer has no read permission). So it makes sense to simply start a timer and start calling the notify function right away. No need to explicitly check if the peer has enabled notifications since we know that the peer expects them because of the service definition.

    Regarding the nus example on the other hand, which is a Nordic proprietary service, notification is not mandatory and the peer has both read and write permissions. So then it might make sense to explicitly store the notification status somewhere for use around the application.

    I believe the way it's done in the SDK is intended to make the examples flexible. Although I guess one could argue that this also make them harder to understand.

Children
Related