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

What does ble_gatts_char_md_t.char_props.read do?

It suggests that it holds the permission regarding whether a chara. can be read, but isn't that kinda redundant since there are tons of other similar properties out there detailing the same thing?

Also I noticed that, when communication with the MCU using my android app, if I enable it, no matter I set CCCD handle or not, it won't trigger the

sd_ble_evt_handler(), and once I turn it off, the sd_ble_evt_handler() can correctly be triggered.

And by not triggering I mean nothing at all, this is what being triggered look like: I press a button on my app, it enters the handler, if I enable char_props.read, nothing happens, the ble evet handler appears not to be called at all.

Why is that?

Parents
  • Everything in the ble_gatts_char_md_t struct are hints for the peer device. When the remote GATT client discovers the entries in the local GATT server, it can ascertain which methods that are likely to be usable for that characteristic or descriptor. Of course, if the local device is implementing a known service, you do not need this information, as it is known. For a generic device, however, these hints makes it possible to present something valuable to the user, without trying to read and write to every characteristic just to see if it will work or not.

    On the GAP level, you have the actual access permissions, which tells the SoftDevice at what GAP security modes the value should be readable or writable. You could argue that these permissions should be synced up with the hints we return, but there are cases where you could want to not set all the flags irrelevant to the characteristic. (On the GATT level, you can add authorization as an additional layer if desired, but this is never communicated to the peer).

    For your second issue, please see Hung Bui's response. I just wanted to clarify the first question a bit for future searchers.

Reply
  • Everything in the ble_gatts_char_md_t struct are hints for the peer device. When the remote GATT client discovers the entries in the local GATT server, it can ascertain which methods that are likely to be usable for that characteristic or descriptor. Of course, if the local device is implementing a known service, you do not need this information, as it is known. For a generic device, however, these hints makes it possible to present something valuable to the user, without trying to read and write to every characteristic just to see if it will work or not.

    On the GAP level, you have the actual access permissions, which tells the SoftDevice at what GAP security modes the value should be readable or writable. You could argue that these permissions should be synced up with the hints we return, but there are cases where you could want to not set all the flags irrelevant to the characteristic. (On the GATT level, you can add authorization as an additional layer if desired, but this is never communicated to the peer).

    For your second issue, please see Hung Bui's response. I just wanted to clarify the first question a bit for future searchers.

Children
No Data
Related