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?

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:


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


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.


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


What you are seeing when packets are dropped are due to buffer overflow either on the iPhone side (most likely I think) or on the host side. Starting with iOS 11.2, apple provides a mechanism allowing you to check if the buffer is ready before writing the next packet; canSendWriteWithoutResponse:

If you wait until canSendWriteWithoutResponse is true before writing a packet, the delivery is guarantied to have been placed in the receiving buffer, but not guarantied that it has been processed (unacknowledged). The other thing that could help is by negotiating a MTU size greater than 20. Apple supports MTU at 185B, and up to 251 (extended data length aka EDL). By chunking your data packets in MTU-3 sizes, your packet==(MTU-3) x 1 per connection interval. @185B MTU, 24 ms connection interval I have throughput around 48kbps with no dropped packets. When sending data to the iPhone from the device, the SDK on that end will need the equivalent to 'canSendWriteWithoutResponse', which in my case using SiLabs hardware/SDK does have e.g


 do {
     result = gecko_cmd_gatt_server_send_characteristic_notification(
     [chunk bytes])->result;
 } while(result == bg_err_out_of_memory); 
  //retry until buffer is empty and ready for more 
 //then update the offset
 offset += thisChunkSize;


Here is a video and .pdf from apple explaining the different BLE techniques and expected speeds. MTU + Connection Interval is what you use to determine max throughput. 48kps should be easily achievable, 96kbps and maybe a little higher are possible.

What's New in Core Bluetooth

video: https://devstreaming-cdn.apple.com/videos/wwdc/2017/712jqzhsxoww3zn/712/712_hd_whats_new_in_core_bluetooth.mp4?dl=1
pdf: https://devstreaming-cdn.apple.com/videos/wwdc/2017/712jqzhsxoww3zn/712/712_whats_new_in_core_bluetooth.pdf 

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.