Maximum BLE throughput for reliable data transfer

[Anonymous]

Per this thread here: Re: Maximum BLE throughput for reliable data transfer

Is there some other way to configure the number of transmit buffers?  I'd be perfectly happy to configure it at build time, if that's possible.

If I print the result of blecm_getAvailableTxBuffers() from my app create function, I get 15.  Sometimes the app sends a burst of notifications, and even though I always check that blecm_getAvailableTxBuffers() returns non-zero before I send a notification, I sometimes get log messages that "lel2cap Fail to allocate buffer".  I'm guessing that this is due to a buffer not being available for something else the stack is trying to do, but I don't really know.

I'd like to be able to queue up 17 notifications for transmission, as I have a block of data of about that size to send. This obviously isn't going to work when there are only 15 transmit buffers, hence my desire to increase the number of transmit buffers.

Aside from that, perhaps I should only queue up notifications when blecm_getAvailableTxBuffers() is greater than 1, so that one buffer is left over for other things?

[MichaelF_56]

Have you take a look at the speed_test application within the SDK?  During testing, we were able to see roughly an 80Kb/s transmission rate using this application.

[Anonymous]

Yes, I have. I'm using the same approach, but I'm still running into the occasional "lel2cap Fail to allocate buffer"  log message that something wasn't able to get a tx buffer, and I'd still like to increase the number of tx buffers if that's possible.

[MichaelF_56]

We will speak with the developers this week to see if we can recommend a means by which you can increase the Tx buffers.

[Anonymous]

Hello Eric,

"when blecm_getAvailableTxBuffers() is greater than 1"

Make greater than 5 and see if this helps?

Thanks

KT

[Anonymous]

Thanks for suggestion, KT. The speed test example tests for the tx buffer count being non-zero, which does mean that it can (temporarily) tie up the last buffer. Yesterday I added a #define to my code to set a threshold, currently with a value of 2, and if I don't send notifications unless the available buffer count is >= 2, I don't see any of the lel2cap error messages in the trace output. I think this confirms that something else in the stack needed a buffer and I was starving it.  Perhaps in a future SDK release Broadcom might wish to make this change to the speed_test application to avoid other developers encountering the same issue.

It still would be helpful to be able to increase the total number of tx buffers from the normal 15 to perhaps 20, to better accommodate my application wanting to send 17 notifies at a time.  I appreciate mwf_mmfae checking with the developers on whether it is feasible to do so.

[MichaelF_56 · Accepted solution]

I spoke with the developers and in theory, its possible to increase the size as there is a config item that can be added, but none exists today. Or we could add an API.

They said that they will try to add to the next SDK release.

[LeCa_2156671]

boont​

we meet this problem too.

We send notify/write_cmd when blecm_getAvailableTxBuffers()>=2,we add a count in sender(20736) and receiver(20736) to count the packets.

After a lot of packets transmitted,we find the count in receiver is less than the count in sender.

We are wondering why few packets are lost.

SDK is 2.2.1.

Is there any solution about this problem?

[BoonT_56]

The best bet is still the speed_test sample app and it also featured the use of blecm_getAvailableTxBuffers(). This API is used to check the availability of transmit buffers and so I'm not too sure about the validity of your above described strategy.