Understanding BLE_EVT_TX_COMPLETE events

RE: Understanding BLE_EVT_TX_COMPLETE events

Einar Thorsrud — Thu, 25 Feb 2021 12:39:18 GMT

Hi,

[quote user="brianreinhold"]I did not realize that notifications were acknowledged at any layer, but I guess they have to be in some sense just to keep the 'heartbeat' alive.[/quote]

Not just that. BLE provide data integrity so all data packets are acknowledged (or retransmitted if necessary) on the link layer.

[quote user="brianreinhold"]You say above that I will get another BLE_ERROR_NO_TX_PACKETS if I send an indication before all my notifications have been evented (I realize that one BLE_EVT_TX_COMPLETE event may encompass more than one notification and I take that into account).[/quote]

I didn't mean to say that. But if the buffer is full, then one packet has to be successfully transmitted (meaning also acknowledged by the peer) before it can be freed so that another packet can be queued. The Tx buffer does not need to be emptied completely.

[quote user="brianreinhold"]However, I am confused about getting a BLE_ERROR_NO_TX_PACKETS if I send an indication before all my notifications have been evented. My understanding from the documentation is that I can only get a BLE_ERROR_NO_TX_PACKETS from notifications. Indications will generate an NRF_ERROR_BUSY error only. Is that not true?[/quote]

No, you are right. I should have refreshed my memory there. That makes sense, as an indications needs to be acked by the peer's app layer before another can be queued.

[quote user="brianreinhold"]Another thing I want to understand - if I get more than one notification evented in the BLE_EVT_TX_COMPLETE event does that means more than one notification went out in a single connection interval?[/quote]

Yes. But it is not necessarily the other way around. You could get more BLE_EVT_TX_COMPLETE events for the same connection event.

[quote user="brianreinhold"]Yet another thing: If I send notifications with 1 byte per notification versus 10 bytes per notification as fast as I can, in which case will I exhaust the buffers the fastest?[/quote]

The buffer has a fixed number of elements (for old SoftDevices that is 1, 3 or 6 depending on bandwidth configuration), and those are scaled for the maximum size packets. But you cannot fit more than the specified number of packets, so 6 packets is max with high bandwidth configuration, even if the payload is only 1 byte.

RE: Understanding BLE_EVT_TX_COMPLETE events

brianreinhold — Thu, 25 Feb 2021 10:38:56 GMT

I did not realize that notifications were acknowledged at any layer, but I guess they have to be in some sense just to keep the 'heartbeat' alive.

You say above that I will get another BLE_ERROR_NO_TX_PACKETS if I send an indication before all my notifications have been evented (I realize that one BLE_EVT_TX_COMPLETE event may encompass more than one notification and I take that into account).

However, I am confused about getting a BLE_ERROR_NO_TX_PACKETS if I send an indication before all my notifications have been evented. My understanding from the documentation is that I can only get a BLE_ERROR_NO_TX_PACKETS from notifications. Indications will generate an NRF_ERROR_BUSY error only. Is that not true?

Another thing I want to understand - if I get more than one notification evented in the BLE_EVT_TX_COMPLETE event does that means more than one notification went out in a single connection interval? I note that 90% of my notifications generate a BLE_EVT_TX_COMPLETE with only a single notification. That's a little disappointing. I'm pushing only 20 bytes per notification in the characteristic value.

Yet another thing: If I send notifications with 1 byte per notification versus 10 bytes per notification as fast as I can, in which case will I exhaust the buffers the fastest? IN which case will I have sent more bytes by the time the buffers are exhausted? Which is the fastest way to deliver data to the peer?

RE: Understanding BLE_EVT_TX_COMPLETE events

Einar Thorsrud — Thu, 25 Feb 2021 10:28:03 GMT

Hi,

The BLE_EVT_TX_COMPLETE is typically raised every time a packet has been transmitted. However, sometimes when more packets are sent in the same connection event you may not get this event for each. Therefor you must also check the count field in the ble_evt_tx_complete_t struct you get with the event.

[quote user=""]The question is when can I start doing the indication? I finish doing all the notifications before all the BLE_EVT_TX_COMPLETE events have been received; a good tenth of a second before all BLE_EVT_TX_COMPLETE events have been received. Can I start sending indications BEFORE all the BLE_EVT_TX_COMPLETE events have been received or will I just get an NRF_ERROR_BUSY error?[/quote]

You need to wait for the BLE_EVT_TX_COMPLETE event to be sure that a buffer has been freed. There is no way to know before this. You could of course try and just live with another BLE_ERROR_NO_TX_PACKETS error if spending a bit of extra CPU time is not problem.

[quote user=""]In other words, if I send a notification and receive no error, is that packet out the door?[/quote]

No. The packet will remain buffered by the SoftDevice until it is acknowledged by the peer (or the link is disconnected due to supervision timeout).

[quote user=""]Additionally, if that happens to be the last notification I need to send for that data packet, can I immediately start sending an indication?[/quote]

No. The same buffer is used for both notifications and indications.

[quote user=""]Please explain the relation between sending a notification, having the notification successfully on its way to the peer, and the BLE_EVT_TX_COMPLETE events.[/quote]

When you send a notification, you really just queue it. Then it is sent and potentially retransmitted several times before it is acknowledged by the peer. Once acknowledged the buffer is freed and you get a BLE_EVT_TX_COMPLETE event. If it was a indication instead of a notification it would have to be acknowledged by the application layer as well, which takes more time (see this old post).