On Jan 18, 2013, at 2:54 AM, Etan Kissling <kissling@oberon.ch> wrote:

Dave,

You have for each sensor 4000 bytes / sec, your packet size is 16 bytes. Therefore, you are sending 4000 / 16 = 250 packets / sec in one direction.

iOS restricts the number of packets that can be sent in a single connection event to four. This is because the radio is shared with classic Bluetooth and WiFi and your app is not allowed to consume all resources, disturbing behavior of other apps that may potentially be using those other services. Therefore, you have at least 250 / 4 = 62.5 connection intervals / second. Your connection interval is therefore at most 1 / 62.5 = 16ms. This is close to the lowest connection interval that I managed to get accepted: http://www.scriptreactor.com/conn_interval-throughput.pdf Therefore, a connection interval of 18.75ms seems likely for your peripheral.

Your throughput is therefore not limited by the sensors, but by iOS.

Aha! That is good know.

In the Bluetooth Accessory Design Guidelines for Apple Products, the fastest possible connection parameters involve setting the interval min to 20ms, and the interval max to 40ms. When you choose those parameters, a connection interval of 38.75 is chosen under current iOS versions. (https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf)

This means that your first step should be to satisfy the rules given in the guidelines document. Your throughput will be halved to about 16 kbit/s = 2000 bytes / sec, but at least you can then tell that it's not your fault :-)

There are already a bazillion of these sensors in consumers hands and working with a couple of shipping iOS apps, so I don't have a luxury of altering the firmware right now, though that might be possible in the future. However, the existing apps only connect to two sensors and speed isn't a great concern. We're working on a new usage scenario for the sensors, so things that were acceptable before have suddenly become unacceptable. :-)

Regarding the XPC connection interrupted: I also observed this regularly on iOS 5 when I streamed data from a single peripheral at high speeds (even those covered by the guidelines). The error has become more rare, but still exists (nowadays mainly when using the CBPeripheralManager, but I've also seen it when using the iOS device only as a central). There is no fix yet, and the only thing that you can do there is to write a bug report (http://bugreport.apple.com).

I was afraid of that. I might use a DTS incident and offer to send in some hardware to see if any progress can be made...

Regarding the connections becoming slow: If you are not already doing it, try to stop scanning before creating any connections. Also, try reducing the advertisement interval of your sensors to allow for more time points where a connection can be established.

Yes, I only scan for a few seconds on launch in my prototype app and then stop scanning. I don't perform any of my download testing until after scanning has stopped.

One final optimization would be an increase of the payload size. This way you can disconnect more quickly, reducing strain on CoreBluetooth.

Again, I'm stuck with my current firmware for now.

Otherwise, nothing wrong with your approach. We are still in the early days with Bluetooth Low Energy, and while CoreBluetooth breaks apart fairly quick, it has heavily improved since it was first included in iOS 5 and is still more robust than what you get on Android devices. So, maybe 1-2 more years in which we have to endure the bugs :-)

So, sounds like there aren't any knobs on the iOS side I can turn to improve my situation. That's disappointing. :-( Thanks, Dave _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com