January 2013 - Bluetooth-dev

Re: Data throughput issues, CoreBluetooth[ERROR] XPC connection interrupted
by Dave Camp 18 Jan '13

18 Jan '13

On Jan 18, 2013, at 2:54 AM, Etan Kissling <kissling(a)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(a)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(a)lists.apple.com

1 0

Quality questions about A2DP & AVRCP
by Gordon Rankin 18 Jan '13

18 Jan '13

Gang, So I am designing a A2DP sink with an AVRCP source. ~~~ Or is there some other way of handling this? Thanks, Gordon -- J. Gordon Rankin Owner and Chief Scientist ====== Wavelength Audio, ltd ====== _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com I am looking to get information on the best quality of audio output I can get from Bluetooth. I know the codec has a lot to do with it, but I am looking even further than that. Volume control? In general all digital volume controls will reduce the resolution of each sample so I am wondering... do I signal the A2DP source with AVRCP to make the volume = 100% will that result in the best data available at my A2DP sink? Digital volume controls in the source will basically multiply the float32 sample with the digital volume percent to create the new sample. But since we get fixed point samples at the endpoint this basically means we loose resolution if the volume control is set to something other than 100%. I can control the actual volume in the analog domain which will result in the best support of the digital samples.

1 0

Re: Central and Peripheral at the same time?
by Etan Kissling 18 Jan '13

18 Jan '13

(resending as plain text to reduce message size) On 18.01.2013, at 14:33, Etan Kissling <kissling(a)oberon.ch> wrote: > Allan, > > extra data can only be put in the CBAdvertisementDataOverflowServiceUUIDsKey. > > /*! > * @constant CBAdvertisementDataOverflowServiceUUIDsKey > * > * @discussion A list of one or more <code>CBUUID</code> objects, representing <code>CBService</code> UUIDs that were > * found in the "overflow" area of the advertising data. Due to the nature of the data stored in this area, > * UUIDs listed here are "best effort" and may not always be accurate. > * > * @see startAdvertising: > * > */ > CB_EXTERN NSString * const CBAdvertisementDataOverflowServiceUUIDsKey NS_AVAILABLE(NA, 6_0); > > Regarding long names, the standard scheme is to put a truncated version into the advertisement data. > In your case, the first 28 bytes of the name. > > As soon as you connect to the peripheral, iOS will read the Device Name characteristic to get the full name of your peripheral. > This name is then cached - as long as your peripheral is using the same Bluetooth address, the name from the characteristic > is displayed, even when not connected. > > Note that you cannot control this behavior using CoreBluetooth. In fact, you cannot even read the name characteristic yourself, > and need to trust that the peripheral.name property is accurate. > > To know when the peripheral name has been fully loaded, you can use the peripheralDidUpdateName: delegate method. > Have not used it, so no comment about whether it works. > > /*! > * @method peripheralDidUpdateName: > * > * @param peripheral The peripheral providing this update. > * > * @discussion This method is invoked when the @link name @/link of <i>peripheral</i> changes. > */ > - (void)peripheralDidUpdateName:(CBPeripheral *)peripheral NS_AVAILABLE(NA, 6_0); > > > Etan > > > > On 18.01.2013, at 14:27, Allan Young <allany(a)adobe.com> > wrote: > >> Hi Etan, >> >> On iOS, I observed that if I put a 32-byte value into CBAdvertisementDataLocalNameKey, the Central was only able to see about 28 or 29 bytes of it. Is there a way in iOS to retrieve all of it? >> >> -Allan >> >> From: Etan Kissling <kissling(a)oberon.ch> >> Date: Fri, 18 Jan 2013 05:20:48 -0800 >> To: Allan Morgan Young <allany(a)adobe.com> >> Cc: "bluetooth-dev(a)lists.apple.com" <bluetooth-dev(a)lists.apple.com> >> Subject: Re: Central and Peripheral at the same time? >> >> Allan, >> >> You could first scan and list the peripherals without the additional user interface. >> After scanning for 5 seconds or so, connect to each one to retrieve additional info, and update the user interface. >> This way, the user interface does not feel empty and one can see that something is happening (like a web browser - >> it doesn't wait until all images are loaded to display a web page). >> >> Because I don't know the exact use case, I cannot recommend a specific behavior here. >> It all depends on the user experience that you want to deliver. >> >> Advertising data is limited. A 32-byte object cannot be put there currently. Note that when using the CBPeripheralManager, >> you can actually put more data in an advertising packet than is actually defined in the Bluetooth Core Spec. >> However, this data can only be read by other iOS devices. >> >> Etan >> >> On 16.01.2013, at 18:57, Allan Young <allany(a)adobe.com> wrote: >> >>> Hi Etan, >>> >>> > A solution for your problem would be to first build a list of devices to connect, then stop scanning and then connecting to all peripherals. >>> >>> So, for a Central that might want to connect to multiple Peripherals, would you advise scanning for some period of time, stop scanning, and then update the user interface with the list of discovered Peripherals? >>> >>> Currently, I'm connecting as I'm scanning. Indeed, I'm scanning/connecting while this particular user interface is showing, so that I can dynamically add newly discovered Peripherals to my UI…and I need to connect to them when found, so that I can query them for some information to show in the UI. >>> >>> The advertising data itself does not allow enough room for meaningful data for my UI…this is why I was connecting whenever I found a new peripheral…that is, in order to be able to read a characteristic so that my UI can show something meaningful about the peripheral. >>> >>> But perhaps this isn't a good approach. >>> >>> Maybe, then, I should scan for 5 seconds or so, building a list of CBPeripherals, then connect to each one to query for additional info, and to allow the user to interact with each one (via a writeable characteristic and notifications/indications). >>> >>> Thoughts? >>> >>> Also, is the custom data in the advertising packet really limited to something like 28 bytes or so? I have a 32-byte object that I would love to expose in the advertising packet. >>> >>> -Allan >>> >>> From: Etan Kissling <kissling(a)oberon.ch> >>> Date: Wed, 16 Jan 2013 09:26:35 -0800 >>> To: Allan Morgan Young <allany(a)adobe.com> >>> Cc: "bluetooth-dev(a)lists.apple.com" <bluetooth-dev(a)lists.apple.com>, Darren Jones <djonesuk(a)me.com>, Joakim Linde <joakim(a)apple.com> >>> Subject: Re: Central and Peripheral at the same time? >>> >>> Allan, >>> >>> Advertising does normally stop when a connection request is received. Not sure about iOS, but there is no way to stop advertising with the API currently. Have to check that with a sniffer. >>> >>> When you program the central side, connecting becomes very slow while scanning. A solution for your problem would be to first build a list of devices to connect, then stop scanning and then connecting to all peripherals. >>> >>> Etan >>> >>> On 16.01.2013, at 17:46, "Allan Young" <allany(a)adobe.com> wrote: >>> >>>> Etan, >>>> >>>> Regarding your comment: >>>> >>>> > Also don't forget to stop scanning and advertising as soon as you establish a connection. >>>> >>>> …is it really necessary to stop scanning and advertising when the connection is established? >>>> >>>> From the peripheral side, what if multiple centrals want access to my data? >>>> >>>> And from the central side, what if I want to get data from a number of peripherals advertising the same service/characteristics? To use a medical/sports example, should I be able to monitor the heart rates reported by a number of different peripherals? >>>> >>>> Is this not possible? >>>> >>>> Thanks. >>>> >>>> -Allan >>>> >>>> From: Darren Jones <djonesuk(a)me.com> >>>> Date: Tue, 15 Jan 2013 23:53:09 -0800 >>>> To: Joakim Linde <joakim(a)apple.com> >>>> Cc: "bluetooth-dev(a)lists.apple.com" <bluetooth-dev(a)lists.apple.com> >>>> Subject: Re: Central and Peripheral at the same time? >>>> >>>> Hi Joakim, >>>> >>>> Bug number: 12963322 >>>> >>>> >>>> Sent from my iPhone 5 >>>> >>>> On 16 Jan 2013, at 03:06, Joakim Linde <joakim(a)apple.com> wrote: >>>> >>>>> >>>>> Hi Darren, >>>>> >>>>> What's the bug report number for this? >>>>> >>>>> Thanks, >>>>> Joakim >>>>> >>>>> On Jan 11, 2013, at 8:23 AM, Darren Jones <djonesuk(a)me.com> wrote: >>>>> >>>>>> Thanks Etan, >>>>>> >>>>>> I have actually filed a bug report for the backgrounding of bluetooth-central stopping. >>>>>> I hope they fix it soon as there's so much more potential for apps when continuous background scanning is available. >>>>>> >>>>>> On 11 Jan 2013, at 16:21, Etan Kissling <kissling(a)oberon.ch> wrote: >>>>>> >>>>>>> Darren, >>>>>>> >>>>>>> OK. If you want to enable background scanning and advertising, just add the bluetooth-central and bluetooth-peripheral keys >>>>>>> to the UIBackgroundModes array in your Info.plist. >>>>>>> >>>>>>> http://developer.apple.com/library/ios/#documentation/General/Reference/Inf… >>>>>>> >>>>>>> bluetooth-central >>>>>>> The app uses the CoreBluetooth framework to communicate with a Bluetooth accessory while in the background. >>>>>>> This value is supported in iOS 5.0 and later. >>>>>>> bluetooth-peripheral >>>>>>> The app uses the CoreBluetooth framework to communicate in peripheral mode with a Bluetooth accessory. >>>>>>> This value is supported in iOS 6.0 and later. >>>>>>> You will then receive the callbacks for around 45-60 minutes of background mode. After this, a bug >>>>>>> prevents to receive more callbacks, as the connection is terminated as soon as your app is purged >>>>>>> from the memory. After relaunching the app, scanning should resume to function properly. >>>>>>> >>>>>>> Etan >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11.01.2013, at 17:14, Darren Jones <djonesuk(a)me.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Thank you. I want to use non pairing so CoreBluetooth is the way. >>>>>>>> I'm glad it's possible. I wasn't sure if background scanning and advertising would be allowed. >>>>>>>> >>>>>>>> >>>>>>>> On 11 Jan 2013, at 16:02, Etan Kissling <kissling(a)oberon.ch> wrote: >>>>>>>> >>>>>>>>> Darren, >>>>>>>>> >>>>>>>>> If you want to perform iPhone to iPhone communication only, I suggest using GameKit for it. >>>>>>>>> You will have an increased throughput, as classic Bluetooth is used as a transport, and don't have >>>>>>>>> to worry about specifying who is master and who is slave. >>>>>>>>> >>>>>>>>> If you want to stay with CoreBluetooth: at least from the Bluetooth Core Specification, a device is >>>>>>>>> allowed to scan and advertise at the same time. I have not yet tried it under iOS, but can tell for your >>>>>>>>> background requirement that scanning times are pretty slow while backgrounded (around 55x >>>>>>>>> advertisement interval). Also don't forget to stop scanning and advertising as soon as you establish >>>>>>>>> a connection. >>>>>>>>> >>>>>>>>> Etan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10.01.2013, at 23:59, Darren Jones <djonesuk(a)me.com> wrote: >>>>>>>>> >>>>>>>>>> Is it possible to use CBCentral scanning and CBPeripheral advertising at the same time? (Also in the background) >>>>>>>>>> >>>>>>>>>> If I wanted 2 random iPhones to communicate and both where set to Central or both to Peripheral they wouldn't see each other. I'd like to remove that they would both have to know which method to activate. >>>>>>>>>> >>>>>>>>>> Is that possible? >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Sent from my iPhone 5 >>>>>>>>>> >> > _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Central and Peripheral at the same time?
by Allan Young 18 Jan '13

18 Jan '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Central and Peripheral at the same time?
by Etan Kissling 18 Jan '13

18 Jan '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Data throughput issues, CoreBluetooth[ERROR] XPC connection interrupted
by Etan Kissling 18 Jan '13

18 Jan '13

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(a)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(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/bluetooth-dev/kissling%40oberon.ch > > This email sent to kissling(a)oberon.ch _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: A Few iOS Peripheral Advertising Rate Questions
by Etan Kissling 18 Jan '13

18 Jan '13

Steve, what you observe is a concept called "Limited Discoverable Mode". (see Bluetooth Core Spec V4.0 Vol 3 Part C 9.2.3). What happens is that a different flag is set in the advertising packets, telling that the peripheral has been recently switched on, or that a user action happened (like pressing a connect button). Normally, you may scan only for packets with that flag set, or at least examine the flags to put such peripherals on the top of a peripheral picker view because it is likely that a user wants to connect to a device with which he/she has recently interacted. This is not possible using CoreBluetooth, though. Another aspect of "limited discoverable mode" is that advertisements are sent with a high frequency. Note that connections can only be established in response to an advertisement. Therefore, this helps in reducing the latency required to connect to the peripheral. This mode comes with the downside that the advertising channels are flooded, and that power consumption is increased. Therefore, one common practice is to limit such high-frequency advertisements to a certain time span - typically around 30 seconds. After this time, the advertising frequency is slowed down. This matches your observations about the advertising rate ramping down over time. On iOS, you cannot modify the advertising interval with the available public APIs. I have not tested it but it may be worth a try to call the startAdvertising method an additional time if you want to switch back to the "Limited Discoverable Mode". While in background, you notice that the advertising rate is inconsistent. On iOS devices, the radio that is used by BLE is also shared with classic BT and WiFi. Also, since the app is backgrounded, it's considered to be less important. The Bluetooth Spec defines that the advertising rate can be varied depending on other connections that have to be maintained - so it's no bug here either :-) Regarding your third question: can't tell, but feel free to share your results. Etan On 17.01.2013, at 20:58, Steve Jabs <stevejabs(a)gmail.com> wrote: > Hi All, > > I'm currently developing an application where the iOS device is in a peripheral mode. So far everything has been pretty straight forward. I have it running fine in the foreground and background. However, I've noticed a few issues that I wanted to bring up and see if there was anyone who may be able to shed some light on them: > > 1.) In the foreground, my app acting as the peripheral advertises extremely fast on startup. This is great, but it seems that after a little bit those advertisements tend to slow down (even while still in the foreground). Should I make the assumption that iOS ramps the advertisement rate up and down? If so, is there a set amount of time that an app will advertise at it's max rate before ramping down? Can I set this without being connected to a central? > > 2.) In the background the app immediately goes to a slower advertising rate. However, it's extremely inconsistent. While the majority of advertisements are sent out at what seems to be a second or less there are a few that can take up to 3 or 4 seconds to advertise. Can I assume, like the first question that the advertising rate varies as it's controlled by iOS? > > 3.) How long can I expect my device to advertise in the background under normal usage? Right now, we've exceeded 3 hours advertising in the background with nothing else running. I'm curious if anyone has done tests that have exceded 24 hours in the background with normal usage. Our use case will likely be 12 or less hours in the background. > > (In all situations this was performed on a latest generation iPod Touch running iOS 6 and not connected to a central) > > Thanks everyone, > > Steve Jablonski > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/bluetooth-dev/kissling%40oberon.ch > > This email sent to kissling(a)oberon.ch _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Data throughput issues, CoreBluetooth[ERROR] XPC connection interrupted
by Dave Camp 18 Jan '13

18 Jan '13

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(a)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(a)lists.apple.com

1 0

A Few iOS Peripheral Advertising Rate Questions
by Steve Jabs 17 Jan '13

17 Jan '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

AAC audio Stream packets for A2DP: LATM Audio Mux Element.
by Shawn Steenhagen 17 Jan '13

17 Jan '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0