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]

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.

 

[Kenneth]

You should be able to get more than count=1 for each complete event, however it may be that you have not configured the BLE event to have time for more than 1 packet. You can find this thread useful on how to increase the event length:

https://devzone.nordicsemi.com/f/nordic-q-a/22698/setting-gap-connection-event-length---ble-hrs-c-demo 

[brianreinhold]

Okay, that is interesting. I automatically assumed that the entire connection interval would be used. In this case I am using the minimum MTU (developing a new standard and want to assure it works under minimal conditions) and letting the peer set the connection parameters (because as I understand it the central can do what it wants and ignore the peripheral's requests).

So what you are saying is that maybe the default configuration is not making full use of the connection interval. (occasionally I do get a 2 in the count). ... and I have the power to change this. Well, I'll certainly need to look into that!

Never mind! I am using SoftDevice s130 and according to the documentation the method sd_ble_cfg_set does not exist. There might be another way to do it, but I note that the ble_cfg structure does not exist either. Is there another way to do this in s130?

[Kenneth]

For the old S130 this was done differently, please check out:
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v3.0.0/structble__conn__bw__counts__t.html

https://devzone.nordicsemi.com/f/nordic-q-a/21483/6-notifications-in-one-connection-interval-related-issue/84287#84287