Notifications: How to know who is consuming tx buffers, most efficient way of sending a sequence, what error conditions are received?

[brianreinhold]

I am going to send a sequence of notifications and the documentation provides this information

The API functions that may consume an application packet depending on the parameters supplied to them can be found below:

• sd_ble_gattc_write (write without response only)
• sd_ble_gatts_hvx (notifications only)
• sd_ble_l2cap_tx (all packets)

I am not using the SDK but just SoftDevice (s130 at the moment). What is not clear from the docs is if some of the SoftDevice calls I make, in turn, make calls to sd_ble_l2cap_tx() that I don't know about. It appears to me unlikely that any of the SoftDevice APIs would themselves call sd_ble_gatts_hvx(); that is something only my application is likely to do. So are there 'hidden' sd_ble_l2cap_tx() calls being made or can I safely assume that if my application does not call the method, that the method is never called?

I am trying to figure out the most efficient way to send a sequence of notifications. The documentation suggests two approaches - keeping track of the guaranteed available buffers (fairly involved) or just sending, and if one gets a BLE_ERROR_NO_TX_PACKETS error wait for the BLE_EVT_TX_COMPLETE event.

Related to this question is the error NRF_ERROR_BUSY response. For notifications will that error message ever happen or will I just get a BLE_ERROR_NO_TX_PACKETS error? If I can get both, what is the difference, and how should I behave in the two different cases? With indications the NRF_ERROR_BUSY means call again, or that packet will not get indicated! If notifications can cause that error, then I assume the behavior is the same?

If I chose to notify and always wait for the BLE_EVT_TX_COMPLETE event before the next notification, will this be less efficient? (It is programmatically simpler.)

[Kenneth]

The softdevice will try to send packets as fast possible, depending on the connection parameters, peer capabilities, other procedures, and packet loss. The simplest may be to have an app_timer that run slightly faster than the connection interval, and just write sd_ble_gatts_hvx() until you receive an error code from the timeout handler. It is also possible to wait for BLE_EVT_TX_COMPLETE before calling sd_ble_gatts_hvx(), however that presumes you have called sd_ble_gatts_hvx() previously, else the BLE_EVT_TX_COMPLETE is not triggered. But both can work.

The NRF_ERROR_BUSY may happen if you are sending indications (not notifications).

[brianreinhold]

I did an experiment where I changed indications to notifications and in all cases the data transfer was slower with notifications. I am trying to understand why.

In my case I have a long characteristic of 90 or so bytes that are either indicated one after the other or notified one after the other. When using indications I indicated one hunk (MTU = min size 23) waited for the Indication done event, BLE_GATTS_EVT_HVC, and indicated the next hunk and so on. In the notification case the procedure was the same except I waited for the BLE_EVT_TX_COMPLETE event before sending the next notification.

The wait procedure was the same in both cases, sd_app_evt_wait() and then on wake up do the sd_ble_evt_get() loop. All this was done in the main thread.

Its not the greatest test given the size of data indicated or notified was not that big, but in all cases the indication case was faster; completely unexpected. Is that some fluke about the handling of the TX buffers that makes it slower?

[Kenneth]

Typically an on-air sniffer log, such as nRF sniffer, may be helpful to find what may be the limiting the throughput.

Kenneth

[brianreinhold]

In this case I don't think it would have helped. I was basing my code on what I understood the behavior of the API to be. On the air I tend to look at the packets, not the packets in a time sequence with respect to the connection intervals. (Im sure the front line sniffer can do this but that is not where I would be looking.) My problem was from the description of the method I assumed a one to one relation between call and event.

At the moment I still don't know what happens when I make the call and get a BLE_ERROR_NO_TX_PACKETS response ... do I have to send the same packet again AFTER the BLE_EVT_TX_COMPLETE event or is it sufficient just to wait for the event and THEN send the next packet? At the moment I have not run into the problem as I have not had a sufficiently long sequence to run out of buffers.

[Kenneth]

brianreinhold said:

do I have to send the same packet again AFTER the BLE_EVT_TX_COMPLETE event

On any error you need to call sd_ble_gatts_hvx() with the same packet again later yes.

Kenneth

[brianreinhold]

Will I ever get an NRF_ERROR_BUSY event using notifications or will that only happen on indications?

[Kenneth]

Only indications.

Kenneth

[brianreinhold]

One more question, if I send 5 packets by notifications in a loop how many  BLE_EVT_TX_COMPLETE events will I get? It appears I will get 5. I was expecting to get 1 with a count of 5 in that event. How does this work? But I am never seeing a count greater than 1.

I have the feeling one has to do something like this

1. For every notification, increment a count by one

2. For every BLE_EVT_TX_COMPLETE event, decrement the count by the count returned in the event.

3. When 0, all indications have been sent.