Receiving BLE_L2CAP_EVT_RX events on Peripheral

[Milton]

I am working with nRF52832 and SD 132 and SDK 11 (nRF5_SDK_11.0.0-2.alpha_bc3f6a0). One of my BLE services has a characteristic with an attribute larger than 22 bytes. It is a variable length attribute that could range from 26 to 48 octets. Also, the attribute values (data set) change dynamically and the values (data set) get stored in a FIFO when there is no BT connection with the central.

So, for properly updating and sending the next data set, whenever the central requests for it (using Read Long), I use BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST and sd_ble_gatts_rw_authorize_reply(). Here, I update the attribute value, if ((p_ble_evt->evt.gatts_evt.params.authorize_request.request.read.offset == 0).

This works well for properly sending FIFO data sets out and sending attribute values when dynamically updated.

However, I need to be able to know for sure that the complete characteristic data set was successfully received by the central, so that I can remove the previously sent data set from the FIFO.

For this, I wanted to capture the l2cap event, BLE_L2CAP_EVT_RX, in my ble_event handling code. But, I do not seem to be getting this event.

Is there any specific registering or initializing that is required to be able to receive this event?

Thanks.

Milton

[RK]

The BLE_L2CAP_EVT_RX has nothing to do with standard communications on the ATT channel, it's used for other, non-ATT channels where you set up a numbered channel and send and receive data down it. You'll never receive that event when just using normal GATT commands.

You do know that the complete data will be sent because the channel will continue to try to send it until it is sent or the link breaks (eg out of range). You don't know however when the last packet is completed, you can't know that.

However you don't really have a problem here. Presuming the central is coded to read the whole characteristic, as soon as you see a 0 offset you update the data and you can throw the first FIFO data away at that point, it's cached in the attribute and it will get read.

If you really care about knowing when the central finishes the read, the closest you can get is to look at the offsets of the read requests. When you reply to any rw_auth with an offset such that less than a full MTU will be sent (including zero bytes) you know the central will stop reading after that packet, and you know the data you send to the rw_auth_reply call will be cached in the softdevice until the packet is sent, so as soon as you've seen that request and crafted the reply, you know that last packet will get delivered and you can throw your FIFO data away.