Content of the BLE_GATTC_EVT_WRITE_RSP event parameter structure

[puz_md]

Hello everybody,

sometimes, I find it pretty hard to work with the documentation provided by Nordic Semiconductor. For example, there is no straightforward documentation on the events that may be triggered by a specific Bluetooth operation, and which parameters provided by the event API have to be evaluated.

My current problem is that, when I invoke a GATTC write request, I do not know how to evaluate the data received within the BLE_GATTC_EVT_WRITE_RSP event (that should acknowledge the write operation on the GATT server):

typedef struct
{
  uint16_t            handle;           /**< Attribute Handle. */
  uint8_t             write_op;         /**< Type of write operation, see @ref BLE_GATT_WRITE_OPS. */
  uint16_t            offset;           /**< Data Offset. */
  uint16_t            len;              /**< Data length. */
  uint8_t             data[1];          /**< Data, variable length. */
} ble_gattc_evt_write_rsp_t;

I write 18 bytes to an attribute at offset 0. When I receive the BLE_GATTC_EVT_WRITE_RSP event, the handle seems to be the same as in the write request. But offset is set to 15 and len is set to 0. I do not know how to interpret this data. What does it tell me? Is there any place in the documentation giving a straightforward description on how to use the data within the ble_gattc_evt_write_rsp_t structure? Or which fields are valid under which conditions?

How can I find out if the write operation was successful or if there was an error (e.g. the data length exceeds the attribute length)?

What I also find suspicious is that the Bluetooth data for the ATT Write Response packet only contains a single byte with the opcode (0x13), no other data is transferred from the GATT server. How can there be any information about offsets and lengths in the software API? Why are these fields included in the parameter structure?

Update (Feb 27, 2015):

Here is a snapshot from the Bluetooth communication: write_req.png

[Stefan Birnir Sverrisson]

Hi

• The struct contains handle, which is the handle for the characteristic you are getting a response for.
• You should get back the data that you sent to the server, so you should be able to compare the received value here with the value that you sent, in order to ensure integrity.
• For the ble_gattc_evt_t structure, there you will get the gatt_status, which tells if the data was transferred successfully or not.

I am not sure of the offset either. But in the case when you send data, if "len" is 10 and "offset" is 5, then only the last 5 bytes of "data" is sent. So I suspect it could be similar here.

This is how I think it is, I have not tested this yet. Your feedback is appreciated on if I am right or wrong.

[puz_md]

Hi Stefan,

When sending a "Write Request", I think it is impossible to get the data that was transferred to the server back in order to ensure integrity. Please have a look at my sniffing snapshot (I will add it to my initial post): There is only one byte, which is used for the Opcode, transmitted from the GATT Server confirming the Write Request.

Not even the handle is transmitted, so if the handle in the struct is valid, it must have been cached somewhere within the SoftDevice. It would be great to have this kind of information somewhere within the official documentation. At the moment, it is just my assumption that the handle is valid and may be evaluated.

Unfortunatelly, I cannot confirm your assumptions on the offset and len fields: In my case, len is 0 and offset is 15. But on the GATT Client, all 18 bytes have been received successfully.