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. 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 :-) 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). 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. One final optimization would be an increase of the payload size. This way you can disconnect more quickly, reducing strain on CoreBluetooth. 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 :-) Etan On 18.01.2013, at 02:58, Dave Camp <dave@thinbits.com> wrote:

We are working on an iOS app to capture data from some BTLE sensors. The goal is to deploy up to 40 of these sensors, allow them to collect data for a couple of hours, retrieve the sensors and then download all of the collected data. Over the course of two hours, the sensors will collect approximately 420KB of data each.

Data is read by writing to a command characteristic on the sensor, indicating what block of data I want (0-n). My code then receives 256 notifications for the response characteristic, each notification carrying a 16 byte data payload. This process is repeated until I've read all the blocks I need.

What we are having problems with is maximizing the throughput of the overall download process. We are testing on an iPad 3 and iPad Mini with iOS 6.0.1.

For any single sensor, we receive data at about 4000 bytes/sec. We believe this is a limitation of the sensor itself. All of the sensors seem to hover around that data rate.

To improve throughput, we've been initiating connections with small numbers of sensors and running downloads in parallel. With two downloads, we get ~8000 bytes/sec. Once we scale this up to 3 sensors at the same time (or more), things get weird. Some or all of the following happens:

- Console log shows "CoreBluetooth[ERROR] XPC connection interrupted". The central then changes states to resetting, off, then on, and all of our devices are re-discovered. I'm assuming the bluetooth daemon is crashing…

- Connections and downloads slow to a crawl. After a number of parallel downloads, connecting to a single sensor will take several seconds and download proceed at a glacial pace. After some period of time, this may or may not resolve itself.

- Some new connections will not work.

Is there anything wrong with the approach we are taking? While I don't expect parallelizing our downloads to scale infinitely, it seems odd that Core Bluetooth seems to fall apart so quickly.

Suggestions?

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/kissling%40oberon.ch

This email sent to kissling@oberon.ch

_______________________________________________ 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