July 2013 - Bluetooth-dev - lists.apple.com

Re: Proper procedure to reconnect to a device in the background using CoreBluetooth
by John Earl 25 Jul '13

25 Jul '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: Proper procedure to reconnect to a device in the background using CoreBluetooth
by Raj Sathianarayanan 25 Jul '13

25 Jul '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

Pairing and bonding with iOS
by houdongfang＠jiuan.com 25 Jul '13

25 Jul '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: Proper procedure to reconnect to a device in the background using CoreBluetooth
by Raj Sathianarayanan 24 Jul '13

24 Jul '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: Proper procedure to reconnect to a device in the background using CoreBluetooth
by John Earl 24 Jul '13

24 Jul '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

Proper procedure to reconnect to a device in the background using CoreBluetooth
by Raj Sathianarayanan 24 Jul '13

24 Jul '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: CB is very unreliable
by Joakim Fernstad 24 Jul '13

24 Jul '13

Putting it on a separate thread is quite simple. All delegates will be called on this queue (and on some random thread GCD controls). self.bleManagerQueue = dispatch_queue_create("com.somedomain.queue", DISPATCH_QUEUE_SERIAL); m_centralManager = [[CBCentralManager alloc] initWithDelegate:self queue:self.bleManagerQueue]; The only thing to keep in mind is synchronizing state and member variables. Best of luck, Joakim -----Original Message----- From: Rick Mann [mailto:rmann@latencyzero.com] Sent: Tuesday, July 23, 2013 6:19 PM To: Joakim Fernstad Cc: bluetooth-dev(a)lists.apple.com Bluetooth Subject: Re: CB is very unreliable That's in interesting suggestions, Joakim. I'll see if I can work it into this re-work of my BLE code. I do have a block-based wrapper around CB, it may not be too hard to set it up on a different queue. -- Rick On Jul 23, 2013, at 18:12 , Joakim Fernstad <jfernstad(a)stratos.com> wrote: > The general advice I can give is to run the BLE code on a different thread (separate dispatch_queue_t queue). Some UI elements (scroll/table views etc) will starve out the BLE communication. That's probably not what's happening to you, looking at your output it seems the stack crashed and restarted, but since I put it on a separate queue I get less packet loss and the stack feels more robust in general. (I push quite a lot of data over the link. ) > > > Joakim > > -----Original Message----- > From: bluetooth-dev-bounces+jfernstad=stratos.com(a)lists.apple.com [mailto:bluetooth-dev-bounces+jfernstad=stratos.com@lists.apple.com] On Behalf Of Rick Mann > Sent: Tuesday, July 23, 2013 5:31 PM > To: bluetooth-dev(a)lists.apple.com Bluetooth > Subject: CB is very unreliable > > I've had to re-do some of the UI around our BLE interaction. Mostly, the code I'm using to call CoreBluetooth is the same, just when I call it has changed. > > But I'm seeing a lot of unreliable behavior. For example, I started scanning, then after that, this happened: > > 2013-07-23 17:26:36.761 [9458:907] CoreBluetooth[WARNING] <CBConcreteCentralManager: 0x1f07e340> is not powered on > 2013-07-23 17:26:36.896 [9458:907] <CameraBrowser.m:113>: centralManagerDidUpdateState: 5 > 2013-07-23 17:26:37.535 [9458:3c07] CoreBluetooth[ERROR] XPC connection interrupted, resetting > 2013-07-23 17:26:37.537 [9458:907] <CameraBrowser.m:113>: centralManagerDidUpdateState: 1 > 2013-07-23 17:26:37.654 [9458:907] <CameraBrowser.m:113>: centralManagerDidUpdateState: 4 > 2013-07-23 17:26:45.389 [9458:907] <CameraBrowser.m:113>: centralManagerDidUpdateState: 5 > > It seems like I have to keep all sorts of parallel state (in this case, I have to keep the state that I want to be scanning, so that if CB powers up, I can actually start scanning again). > > This is getting extremely frustrating. > > -- > Rick > > > > > _______________________________________________ > 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/jfernstad%40stratos.c… > > This email sent to jfernstad(a)stratos.com > > _______________________________________________ > 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/rmann%40latencyzero.c… > > This email sent to rmann(a)latencyzero.com -- Rick _______________________________________________ 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: CB is very unreliable
by Rick Mann 24 Jul '13

24 Jul '13

That's in interesting suggestions, Joakim. I'll see if I can work it into this re-work of my BLE code. I do have a block-based wrapper around CB, it may not be too hard to set it up on a different queue. -- Rick On Jul 23, 2013, at 18:12 , Joakim Fernstad <jfernstad(a)stratos.com> wrote: > The general advice I can give is to run the BLE code on a different thread (separate dispatch_queue_t queue). Some UI elements (scroll/table views etc) will starve out the BLE communication. That's probably not what's happening to you, looking at your output it seems the stack crashed and restarted, but since I put it on a separate queue I get less packet loss and the stack feels more robust in general. (I push quite a lot of data over the link. ) > > > Joakim > > -----Original Message----- > From: bluetooth-dev-bounces+jfernstad=stratos.com(a)lists.apple.com [mailto:bluetooth-dev-bounces+jfernstad=stratos.com@lists.apple.com] On Behalf Of Rick Mann > Sent: Tuesday, July 23, 2013 5:31 PM > To: bluetooth-dev(a)lists.apple.com Bluetooth > Subject: CB is very unreliable > > I've had to re-do some of the UI around our BLE interaction. Mostly, the code I'm using to call CoreBluetooth is the same, just when I call it has changed. > > But I'm seeing a lot of unreliable behavior. For example, I started scanning, then after that, this happened: > > 2013-07-23 17:26:36.761 [9458:907] CoreBluetooth[WARNING] <CBConcreteCentralManager: 0x1f07e340> is not powered on > 2013-07-23 17:26:36.896 [9458:907] <CameraBrowser.m:113>: centralManagerDidUpdateState: 5 > 2013-07-23 17:26:37.535 [9458:3c07] CoreBluetooth[ERROR] XPC connection interrupted, resetting > 2013-07-23 17:26:37.537 [9458:907] <CameraBrowser.m:113>: centralManagerDidUpdateState: 1 > 2013-07-23 17:26:37.654 [9458:907] <CameraBrowser.m:113>: centralManagerDidUpdateState: 4 > 2013-07-23 17:26:45.389 [9458:907] <CameraBrowser.m:113>: centralManagerDidUpdateState: 5 > > It seems like I have to keep all sorts of parallel state (in this case, I have to keep the state that I want to be scanning, so that if CB powers up, I can actually start scanning again). > > This is getting extremely frustrating. > > -- > Rick > > > > > _______________________________________________ > 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/jfernstad%40stratos.c… > > This email sent to jfernstad(a)stratos.com > > _______________________________________________ > 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/rmann%40latencyzero.c… > > This email sent to rmann(a)latencyzero.com -- Rick _______________________________________________ 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: CB is very unreliable
by Joakim Fernstad 24 Jul '13

24 Jul '13

The general advice I can give is to run the BLE code on a different thread (separate dispatch_queue_t queue). Some UI elements (scroll/table views etc) will starve out the BLE communication. That's probably not what's happening to you, looking at your output it seems the stack crashed and restarted, but since I put it on a separate queue I get less packet loss and the stack feels more robust in general. (I push quite a lot of data over the link. ) Joakim -----Original Message----- From: bluetooth-dev-bounces+jfernstad=stratos.com(a)lists.apple.com [mailto:bluetooth-dev-bounces+jfernstad=stratos.com@lists.apple.com] On Behalf Of Rick Mann Sent: Tuesday, July 23, 2013 5:31 PM To: bluetooth-dev(a)lists.apple.com Bluetooth Subject: CB is very unreliable I've had to re-do some of the UI around our BLE interaction. Mostly, the code I'm using to call CoreBluetooth is the same, just when I call it has changed. But I'm seeing a lot of unreliable behavior. For example, I started scanning, then after that, this happened: 2013-07-23 17:26:36.761 [9458:907] CoreBluetooth[WARNING] <CBConcreteCentralManager: 0x1f07e340> is not powered on 2013-07-23 17:26:36.896 [9458:907] <CameraBrowser.m:113>: centralManagerDidUpdateState: 5 2013-07-23 17:26:37.535 [9458:3c07] CoreBluetooth[ERROR] XPC connection interrupted, resetting 2013-07-23 17:26:37.537 [9458:907] <CameraBrowser.m:113>: centralManagerDidUpdateState: 1 2013-07-23 17:26:37.654 [9458:907] <CameraBrowser.m:113>: centralManagerDidUpdateState: 4 2013-07-23 17:26:45.389 [9458:907] <CameraBrowser.m:113>: centralManagerDidUpdateState: 5 It seems like I have to keep all sorts of parallel state (in this case, I have to keep the state that I want to be scanning, so that if CB powers up, I can actually start scanning again). This is getting extremely frustrating. -- Rick _______________________________________________ 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/jfernstad%40stratos.c… This email sent to jfernstad(a)stratos.com _______________________________________________ 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: CB is very unreliable
by Rick Mann 24 Jul '13

24 Jul '13

It's irrelevant if it's fixed in iOS 7. That won't be out for months, and I suspect it'll take longer for people to be willing to upgrade. We're shipping very soon, and this needs to work now. On Jul 23, 2013, at 18:01 , eklektek <steve(a)eklektek.com> wrote: > Is this running on iOS7 ? If not then give it ago. That bug is fixed in 7 > >> On 23 Jul 2013, at 17:31, Rick Mann <rmann(a)latencyzero.com> wrote: >> >> I've had to re-do some of the UI around our BLE interaction. Mostly, the code I'm using to call CoreBluetooth is the same, just when I call it has changed. >> >> But I'm seeing a lot of unreliable behavior. For example, I started scanning, then after that, this happened: >> >> 2013-07-23 17:26:36.761 [9458:907] CoreBluetooth[WARNING] <CBConcreteCentralManager: 0x1f07e340> is not powered on >> 2013-07-23 17:26:36.896 [9458:907] <CameraBrowser.m:113>: centralManagerDidUpdateState: 5 >> 2013-07-23 17:26:37.535 [9458:3c07] CoreBluetooth[ERROR] XPC connection interrupted, resetting >> 2013-07-23 17:26:37.537 [9458:907] <CameraBrowser.m:113>: centralManagerDidUpdateState: 1 >> 2013-07-23 17:26:37.654 [9458:907] <CameraBrowser.m:113>: centralManagerDidUpdateState: 4 >> 2013-07-23 17:26:45.389 [9458:907] <CameraBrowser.m:113>: centralManagerDidUpdateState: 5 >> >> It seems like I have to keep all sorts of parallel state (in this case, I have to keep the state that I want to be scanning, so that if CB powers up, I can actually start scanning again). >> >> This is getting extremely frustrating. >> >> -- >> Rick >> >> >> >> >> _______________________________________________ >> 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/steve%40eklektek.com >> >> This email sent to steve(a)eklektek.com >> ______________________________________________ >> This email has been scanned by Netintelligence >> http://www.netintelligence.com/email >> -- Rick _______________________________________________ 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