How can I identify the transmission completion of a packet when using NCS?

[lammobile]

Hi Nordic team,

I'm using the bt_gatt_notify_cb function to send notifications about data.

In the SDK, I can ascertain that the data has been successfully sent through the "BLE_GATTS_EVT_HVN_TX_COMPLETE" event. However, in NCS, which event or function can provide me with this information?

I want to find out how many packets are waiting in the queue.

Thank you.

[Kenneth]

Hello,

I am not aware of any way to find how many packets are waiting in the queue no, but if you are using the notify with callback function, isn't the callback being called to indicate that the packet is sent? Ref for instance from nus.c service where on_sent() is called:

int bt_nus_send(struct bt_conn *conn, const uint8_t *data, uint16_t len)
{
	struct bt_gatt_notify_params params = {0};
	const struct bt_gatt_attr *attr = &nus_svc.attrs[2];

	params.attr = attr;
	params.data = data;
	params.len = len;
	params.func = on_sent;

	if (!conn) {
		LOG_DBG("Notification send to all connected peers");
		return bt_gatt_notify_cb(NULL, &params);
	} else if (bt_gatt_is_subscribed(conn, attr, BT_GATT_CCC_NOTIFY)) {
		return bt_gatt_notify_cb(conn, &params);
	} else {
		return -EINVAL;
	}
}

Kenneth

[lammobile]

Thank you, it has been working for me.

[lammobile]

Hi Kenneth 
One more question, according to my connection parameters, the Windowsize is 6.25ms, which means it can transmit a maximum of 3 packets per interval. However, in my image, it doesn't meet the expectation. It doesn't flush all the data in the queue as quickly as expected, like the last packet, it only succeeds after some time of notification, under good connection conditions.

[Kenneth]

Hello,

Normally data should be sent every connection interval yes, but if either peer is doing something different (e.g. scanning, advertising, possible flash write operation), then this may skip one of a few intervals. Can that be the problem here? Alternatively it can be noise of course (e.g. wifi) that cause packet to be lost, or you may also look into trying to increase the tolerance (e.g. in ppm) of the lfclk in case it's somethow related to either lfclk sources are a bit on the edge of configured setting, but if that was the problem you should see it much more frequently than like you do in this plot.

Kenneth

[lammobile]

Hi Kenneth ,

Thanks for quick reply.

That's not really a problem, I just want to find an explanation for this phenomenon because I always see one packet left in the queue after notifying. It would make more sense if it was sent out and there were no packets left in the queue.

Lam

[Kenneth]

It may be that the packet is actually sent, but the acknowledge that the packet is received is likely not received until next event (because then the sequence number is incremented). In case of packet loss, it will wait for "acknowledge" before stating that packet was sent.

Kenneth