sd_ble_gatts_hvx() usage

[Daniel Bayeh]

I have a characteristic that is 80bytes long which is sometimes read by the client using long read. I also want to send the complete attribute value when its state changes using gatts_hvx. This is where it got fuzzy and the documentation wasn't of much help.

Is it possible to use gatts_hvx function specifying the length to the attribute size (80 in this case) and have the hvx function send it out 20bytes at a time? I have tried but couldn't make it work.

Or is it limited to 20bytes and the app has to call it multiple times with 20bytes at a time? I did this - calling hvx with the p_data member pointing to the consecutive 20byte values and this does work - but to a point. The problem is if I do a value read after the four hvx calls, it always reads the last 20bytes as if some internal pointer is stuck pointing to the last 20bytes. The only way I could get it to read starting from the first byte is by calling hvx again with p_value set to the first byte. Is there a way to reset this so I don't have the extra hvx call?

Here is the code with the last hvx call commented out. Uncommenting it kind of works, but I shouldn't need to do this. Is there any documentation that sheds some light as to what the hvx does to the attribute table? What am I doing wrong?

if((p_tag->conn_handle != BLE_CONN_HANDLE_INVALID) && p_tag-is_notification_supported) { ble_gatts_hvx_params_t hvx_params; memset(&hvx_params, 0, sizeof(hvx_params));

len = 20;	    // not necessary since offset is 0
hvx_params.handle		= p_tag->tag_char_handles.value_handle;
hvx_params.type		= BLE_GATT_HVX_NOTIFICATION;
hvx_params.offset		= 0;
hvx_params.p_len		= &len;
hvx_params.p_data		= (uint8_t*)(&state->data[0]);
err_code = sd_ble_gatts_hvx(p_tag->conn_handle, &hvx_params);
			
hvx_params.p_data		= (uint8_t*)(&state->data[10]);
err_code = sd_ble_gatts_hvx(p_tag->conn_handle, &hvx_params);
			
hvx_params.p_data		= (uint8_t*)(&state->data[20]);
err_code = sd_ble_gatts_hvx(p_tag->conn_handle, &hvx_params);
	
hvx_params.p_data		= (uint8_t*)(&state->data[30]);
err_code = sd_ble_gatts_hvx(p_tag->conn_handle, &hvx_params);

// hvx_params.p_data = (uint8_t*)(&state->data[0]); // err_code = sd_ble_gatts_hvx(p_tag->conn_handle, &hvx_params); }

Note: state->data[] is of uint16_t type.

Also, in order to send all the attribute values, I had to use p_data which will update the attribute value in the stack which is where the value is stored in my application. Is there a way to do multiple hvx calls with p_data set to NULL? In other words, without gatts_hvx() updating the attribute value?

Thanks.

[Ole Morten]

There is no way to send a notification of more than 20 bytes (it's limited to ATT_MTU-3 by the Core Specification, and the MTU with current S110 is 23 bytes). A notification on-air has no offset field, so it is assumed that the notification contains either the complete value, or the first 20 bytes. If you define a characteristic with a length > 20 bytes, and then send a notification of 20 bytes, the behavior will depend on whether the characteristic is of variable length:

• If the characteristic has vlen set, the softdevice will assume that you want to set the value of the characteristic to just 20 bytes.
• If the characteristic does not have vlen set, the softdevice will change the lower 20 bytes to whatever value you notified and leave the rest unchanged.

There isn't any very easy way to work around this, but I can see two options:

1. Send the notifications you want and afterwards set the value back to the 80 byte value by using sd_ble_gatts_value_set(). In this case, a device that reads at the same time that it receives notifications will see strange (i.e. partial) values.
2. Use two characteristics, one that's readable and have max_len 80 bytes, and another that is only notifiable with max_len 20 bytes.

In my personal opinion, the latter seems to be a cleaner way to achieve what you want.

[Daniel Bayeh]

Thank you, Ole. It seems the gatts_hvx call only overwrites the first 20bytes. Just for curiousity, i just updated the first 20bytes using gatts_value_set() and that fixed the problem. I understand partial values can be read if notification and read operations coincide.