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?