RE: CB is very unreliable
RE: CB is very unreliable
- Subject: RE: CB is very unreliable
- From: Joakim Fernstad <email@hidden>
- Date: Wed, 24 Jul 2013 01:22:38 +0000
- Thread-topic: CB is very unreliable
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:email@hidden]
Sent: Tuesday, July 23, 2013 6:19 PM
To: Joakim Fernstad
Cc: email@hidden 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 <email@hidden> 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=email@hidden [mailto:bluetooth-dev-bounces+jfernstad=email@hidden] On Behalf Of Rick Mann
> Sent: Tuesday, July 23, 2013 5:31 PM
> To: email@hidden 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 (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Bluetooth-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
--
Rick
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden