Maximum BLE throughput for reliable data transfer

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hello.

We are developing a BLE demo application using WICED SDK 1.0.1 and BCM20732 tag. In such demo, BLE tag is used as peripheral device, while an Android 4.3 smartphone is used as central device. The goal consists in transferring a binary file from the tag to the smartphone in a reliable way. The file contains encoded data from emulated sensors and peripherals.

My questions are:

- which is the best design for BLE profile, in order to transmit a reliable stream of data?

- which is the maximum net throughput I can obtain?

In our current implementation, we are using two characteristics:

- one notification characteristic: it is used to transmit 20 bytes from peripheral to central

- one control characteristic: it is used by central device to request next data

Using such a simple protocol, we reach very low throughput, just 1.3kbps. Please notice my transmission interval is already 12ms.

What I noticed can really drop the throughput is the fact that on central device - the Android smartphone - reception of notification is asynchronous and enqueued: in case peripheral device sends two notifications too closely, Android's callback is called twice, but the value of the last characteristic is read twice. That's why I had to use the control characteristic to slow down the transfer.

I noticed that one simple way to achieve higher throughput is to use 4 characteristics for notification instead of one, but this solution does not scale well.

Please advice.

1 Solution

The minimum connection interval is 7.5mS (per the spec), lower connection intervals are not possible.

conn_idle parameter is used to disconnect the link when there is no data in either direction for this long (in seconds). This does not affect throughput in any way when you have data flowing (because the timer will keep getting restarted).

> characteristic used for notification is also writable no response: why? does it help to improve throughput?

> such characteristic is not readable: why?

Which one? Besides, permissions have no effect on throughput.

> encryption and security are off: do they speed up transmission?

Not really.

> spped_test application implements simple ACK mechanism: is it necessary? Isn't BLE already proving acknowledgment of notifications in lower layers (like L2CAP)

These are application layer acks, more like flow control.

View solution in original post

8 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

Per this post: List of the Profile/Application Support within SDK 2.0


You may want to leverage the speed_test application for your testing.


I believe this demo is pretty consistent at 80kbps

0 Likes
Anonymous
Not applicable

Hi. Thank you. I gave a look at speed_test sample, and I noticed the following things:

- transmission interval min and max values are set to 6 (7.5ms), while I was setting it to 1 (1.25ms). By fixing it, I reached much 2KBps throughput! So, can you confirm that 6 is the minimum value?

- .con_idle_timeout property is set to 9, while in hello_sensor its value is 3: why?

- characteristic used for notification is also writable no response: why? does it help to improve throughput?

- such characteristic is not readable: why?

- encryption and security are off: do they speed up transmission?

- spped_test application implements simple ACK mechanism: is it necessary? Isn't BLE already proving acknowledgment of notifications in lower layers (like L2CAP)?

Thank you for your valuable help!

0 Likes

The minimum connection interval is 7.5mS (per the spec), lower connection intervals are not possible.

conn_idle parameter is used to disconnect the link when there is no data in either direction for this long (in seconds). This does not affect throughput in any way when you have data flowing (because the timer will keep getting restarted).

> characteristic used for notification is also writable no response: why? does it help to improve throughput?

> such characteristic is not readable: why?

Which one? Besides, permissions have no effect on throughput.

> encryption and security are off: do they speed up transmission?

Not really.

> spped_test application implements simple ACK mechanism: is it necessary? Isn't BLE already proving acknowledgment of notifications in lower layers (like L2CAP)

These are application layer acks, more like flow control.

Hi,


Is this the maximum theoretical throughput in BLE protocol?

Or how is this being calculated? bit or byte per sec?

"I believe this demo is pretty consistent at 80kbps"


And is this parameter configurable for controller?

' blecm_setAvailableTxBuffers(INT32 val);' Any maximum and default value for reference?

0 Likes

The theoretical data rate is 1 Mbps, but this assumes that you are continuously transmitting, which is not how the protocol works. Data is packetized and transmitted/received in at most 27 byte packets every connection event. However, there is is some overhead at the application (GATT) layer and what you get is only 20 bytes. The minimum connection interval is 7.5ms (so when there is no data, the two devices have to exchange 0 byte payload data every 7.5mS). As long as either side has data, the two devices can exchange these 27 byte (or less) packets multiple times in a connection interval. But there are some timing requirements that both sides have to honor. In short, you can get anywhere from 1 to 6 packets (depends on resource availability, interference and a number of other factors) to the other side in this 7.5mS.

So at the app layer, if you send 20 bytes/packet, assume an average of 4 connection events/connection interval and 133 intervals (7.5mS)/second, you will get ~85Kbps.

Just one new question hitting to my mind.

And is this parameter configurable for controller?

' blecm_setAvailableTxBuffers(INT32 val);' Any maximum and default value for reference?


Here is the packets flow from sniffer:

4 Notification PDUs in one connection event

still having 5xxx us period before next connection event.

sniffer_snapshot_speed_test.jpg

0 Likes

Does anyone help on my question about blecm_setAvailableTxBuffers(INT32 val)?

0 Likes

blecm_setAvailableTxBuffers() is not for use by the application. The stack uses it to keep track of packet credits from the controller.