Adding characteristic (for purpose of long read) fails

RE: Adding characteristic (for purpose of long read) fails

Aurabindo — Thu, 14 Dec 2017 17:31:42 GMT

@hungbui by "send a long sequence of bytes", I did not specifically mean about setting characteristic's data or not setting it. Either way it would work fine for me, unless one method has considerable performance penalty in terms of data throughput. Thanks for the suggestion

RE: Adding characteristic (for purpose of long read) fails

Hung Bui — Thu, 14 Dec 2017 11:51:55 GMT

Hi Aurabindo,

What do you mean by "send a long sequence of bytes" ? Do you mean that you can send different data instead of the value of the characteristic ? If it's the case, you may need read with authorization, where you can actually set the data you want to set to the characteristic and send it via read response.

sd_ble_gattc_read() can be used on the client side to do a read. Offset parameter can be used to do a read blob /read long. Meaning you need to do several sd_ble_gattc_read() and move the offset to read the whole characteristic.

Note that if you use authorization, you can think of updating the characteristic value to send different trunk of data based on the number of read instead of using offset, This is useful when you don't want to use a large buffer or if the size of your data is bigger than the max size for characteristic (512).

RE: Adding characteristic (for purpose of long read) fails

Aurabindo — Wed, 13 Dec 2017 18:09:23 GMT

@hungbui Let me try to clear the misunderstanding. I did look into the message sequence chart. I would like to clarify that my requirement is not to read long characteristic from a peer device. Rather, when a peer device does a read, my device should be able to send a long sequence of bytes. So from your response, I infer that sd_ble_gattc_read() is used to do a long read on a peer's characteristic. Am I right ?

RE: Adding characteristic (for purpose of long read) fails

Hung Bui — Wed, 13 Dec 2017 16:38:19 GMT

No. Why you talk about GATT client here? we are talking about gatt server.
It should as it's defined in BLE_GATTS_VAR_ATTR_LEN_MAX isn't it.
"The Client Characteristic Configuration declaration shall be readable and writable." It's defined in the spec (section 3.3.3.3 Vol 3 Part G Spec v4.0)
I don't understand you. Authorization has nothing to do with long read. Have you looked at the sequence chart I mentioned in the answer ??
Check the message sequence chart.
You mean sd_ble_gatts_value_set? This function tells nothing to the peer device, it only update the value of the characteristic. You need to send a notification if you want to tell the peer device you have new data (using sd_ble_gatts_hvx() function). This function take a pointer and length and then update it to the buffer you declare when you initialize the characteristic. The buffer can be inside the stack if you use BLE_GATTS_VLOC_STACK. If you use BLE_GATTS_VLOC_USER, the it will be the buffer you provided as the initialize value of the characteristic.

RE: Adding characteristic (for purpose of long read) fails

Aurabindo — Wed, 13 Dec 2017 13:46:29 GMT

@hungbui knock knock

RE: Adding characteristic (for purpose of long read) fails

Aurabindo — Tue, 12 Dec 2017 18:03:00 GMT

Inorder to tell the stack that I have fresh data to be sent from the peripheral next time when a read is performed by a peer, the function to be used to set the fresh data is sd_ble_gatts_set_data() ? If so, this function takes a pointer to data with its length and offset. What significance does it have wrt the data pointer that was initially setup for this characteristic when it was created/added ? Can i point to this same buffer ?

RE: Adding characteristic (for purpose of long read) fails

Aurabindo — Tue, 12 Dec 2017 17:51:55 GMT

Even though both read blob and read with authorization are not related, is this not the only way to send to the peer a long read sequence when the peer does a normal read ? My assumption was that I will have to enable read with authorization for this characteristic, and just before I reply, I will have to call the corresponding api that does long read (which turns out to be sd_ble_gattc_read instead of sd_ble_gatts_value_get from your answer). Is this the right way to make a long read happen ?
Is my understanding correct that the peer has only one kind of read; and its the peripheral that decides to do a long/normal read ?

RE: Adding characteristic (for purpose of long read) fails

Aurabindo — Tue, 12 Dec 2017 17:21:50 GMT

Thank you for the response @Hung Bui, I have some questions:

Are there any other setup necessary to do related to GATT Client during initialization?
Is the value 512 valid for the max length of the characteristic?
I'm unable to understand the reason why cccd needs the write permission, when there is no need for a peer to write to it, since it doesnt support enabling notification. Are there other reasons cccd needs to be written ?

RE: Adding characteristic (for purpose of long read) fails

Hung Bui — Tue, 12 Dec 2017 16:14:48 GMT

Hi Aura,

There is no relation between read blob and read with authorization . Have a look here.

The reason you have error #7 is that you don't set a write permission for CCCD which is required. Try adding this:

BLE_GAP_CONN_SEC_MODE_SET_OPEN(&cccd_md.write_perm);