Improving throughput of a Bluetooth Low Energy Connection

Question

Follow-Up question from Stackoverflow

I am trying to write a characteristic value repeatedly over a short amount of time. Different sources tell that rates between 200 and 305 kbit / s should be possible. However, I reach only ~36 kbit/s.

I am using an iPhone 4S to write the characteristic repeatedly. A development board with a CSR1000 BLE chip serves as the peripheral that accepts the writes. I am using writes without response to avoid acknowledgments on the attribute layer. See my question on Stackoverflow for further details.

A write to the 20 byte long characteristic value happens after every millisecond. Therefore, I am sending 160 kbit / s. Only ~36 kbit/s are actually received. The strange thing about it is, that, at the start of the session, everything works fine for a fraction of a second. Then, packets start to drop. However, most often, packs of four continuous write requests work fine before a varying number of packets is getting dropped again.

I have found a significant correlation between the throughput and the value of Conn_Interval. However, the iPhone 4S won't accept any lower Conn_Interval values than 0x0f. This is already lower than what Apple proposes within their hardware guidelines. When I comply to their values and use an interval minimum of 20ms, and an interval maximum of 40ms, the throughput decreases to ~15 kbit/s.

Conn_Interval = 0x000f = 18.75 ms
Conn_Latency  = 0x0000
Supervision_Timeout = 0x00fc

The "Modeling the Maximum Throughput of Bluetooth Low Energy in an Error-Prone Link" paper by Gomez et al. describes the influence of *Conn_Interval* and bit errors on the throughput. However, according to their analysis, there would be a relatively high amount of bit errors, if this would be the limiting problem source. The development board lies in close proximity to the iPhone 4S. Therefore, I guess that there exist other limiting factors.

• What other parameters could have an influence on the throughput in Bluetooth Low Energy?
• Why is the Conn_Interval such a big deal? If the interval is higher, shouldn't the individual connection events be filled with more packets, leading to a similar throughput?
• Could a Bluetooth Sniffer / Analyzer help in detecting whether there are really so many bit errors? If yes, what analyzers would you recommend?

Answer 1

Are you sure all those packets are actually leaving the iPhone? Maybe Apple imposes bandwidth restrictions on apps, as I told you on stackoverflow you should really ask this question in the Apple Bluetooth mailing list, where there are several helpful Apple engineers that could potentially help you.

Otherwise you really need to specify what chipsets you are using if you want to get something out of these questions.

EDIT: ok, you are using the CSR chipset, then I suggest contacting CSR directly and posting your question here:

https://lists.apple.com/mailman/listinfo/bluetooth-dev

EDIT2: a sniffer could certainly help you see whether those packets are actually being sent by the iphone and not being received by the CSR chipset, or else it is just that the iPhone is never actually sending them over the air

Answer 2

What development board you are using? There have been some problems with Bluegiga and the BLE-112A. The original specs they listed weren't quite correct with regards to memory capacity and available firmware profile options. It is my understanding that they are supposed to be updating their software specs based on feedback they have received.

Depending on what your trying to do another option may be present in the tod Smart Beacon for more info see todhq.com

Answer 3

Could get a reply from Apple by burning a TSI and waiting for a month.

Basically, they tell that the behavior is intended in iOS 5.1. It somehow makes sense, because they don't want that your app's performance depends on whether another app uses Bluetooth or WiFi.

Per the engineers comments - Under iOS 5.1 there should be 6 pairs of notifications during a connection interval, meaning 6*packetSize*1000/interval . This should translate to ~55kbps max (min interval is 20ms, packetsize is 23 bytes). We made the decision to limit the number of pairs per interval and have a minimum interval due to the fact that the iPhone and iPad both have shared antenna between BT classic, BT LE and WiFi.

iOS LE is designed to be a low power transport. For higher throughput BT classic is a better transport method.

Back to me - Based on the engineers comments above, if the desire is to achieve a 200 kbs throughput, Classic bluetooth is the answer. However, if the desire is to work with an application on the iPhone, I can understand that this is no simple change - Classic BT requires MFI licensing.