What does sd_ble_tx_buffer_count_get return?

[Marius Heil]

Hello,

the documentation states: "Get the total number of available application transmission buffers per link in the BLE stack." What does "link" mean in that context? I just ran a test where i connected to two other devices as a master and alternately sent them data. I filled the buffer with many packets for both connections. But I was only able to fill it with 3 packets, 2 for the first node and one for the second. This means that I have a total amount of only three packets that I can schedule for all of my links, right? And if I have 4 links, I have to skip a connection event because I can not fill 4 packets in the buffer, is that right as well?

Thanks

[Stefan Birnir Sverrisson]

Hi Marius

Very late response, I know. Sorry for that.

The sd_ble_tx_buffer_count_get returns available user buffers per link Here is the buffer information for the nRF51 BLE softdevices:

User buffers: Used to send Write Commands and Notifications, they generate BLE_EVT_TX_COMPLETE events once the packet has been sent to the peer

System buffers: Used to send anything else (Write Request, HVI, Read Request, SMP packets, L2CAP Connection Parameter Update, etc.)

S130:
User buffers: 3x per link (up to 4 links, whatever the role)
System buffers: 6x per link (up to 4 links, whatever the role)

S120:
User buffers: 1x per link (up to 8 links, always central)
System buffers: 1x per link (up to 8 links, always central)

S110:
User buffers: 7x per link (but it's single-link)
System buffers: 8x per link (but it's single-link)

[Marius Heil]

Mhhm, that's weird as it doesn't stack up with my own findings. When I run sd_ble_tx_buffer_count_get, I receive a total of 3 buffers for the S130 1.0 prod. I call this function right in my bootup code as the documentation states that this will not change during runtime. These 3 buffers are not per link and filling them with more than three packets, no matter the link, will produce an error. On the other hand, I only had 1 buffer available to send reliable packets per link. Writing more did produce an error as well. I will recheck this tomorrow.... You say that I have 8 buffers to send write commands if i have 4 connected links? And there are even more reliable buffers,.. well, would be great if that's right^^

[Carles]

the documentation states: "Get the total number of available application transmission buffers per link in the BLE stack." What does "link" mean in that context?

It means a BLE connection. So per connection. If you are connected to 2 peripherals, each connection to each of the peripherals gets 3 user TX buffers.

I just ran a test where i connected to two other devices as a master and alternately sent them data. I filled the buffer with many packets for both connections. But I was only able to fill it with 3 packets, 2 for the first node and one for the second.

That doesn't make sense. What kind of packets were you sending? Remember that user TX buffers only apply to non-acked transactions, which means:

• Handle Value Notification (HVN)
• Write Commnad (Write Without Request)

The rest of operations are acked by the peer and hence you cannot buffer multiple of them (you need to wait for the response to the first one) and so they do not take up user TX buffers. Instead they are allocated in internal system buffers.

This means that I have a total amount of only three packets that I can schedule for all of my links, right? And if I have 4 links, I have to skip a connection event because I can not fill 4 packets in the buffer, is that right as well?

No, you have 3 packets per BLE connection. But only for the packet types I listed above.

[Stefan Birnir Sverrisson]

I made a mistake in my post. It should have been 3x user buffers per link for S130. I have corrected it accordingly.

[Marius Heil]

I've finally updated my code an included this knowledge. I do not quite know how the system buffers help me (@Carles says that I need to wait for an ack, so I cannot buffer multiple packets), but I got the user buffers filled nicely now.