Peripheral in .connecting state refuses to connect
Peripheral in .connecting state refuses to connect
- Subject: Peripheral in .connecting state refuses to connect
- From: Rogers George <email@hidden>
- Date: Mon, 18 Feb 2019 10:32:31 -0600
Greetings. Once again there is a behavior we're seeing with our BLE devices
that's got me stumped.
We try to stay connected to our peripheral as long as it's in range. The
Apple-endorsed strategy here is to call central.connect(peripheral) immediately
on disconnection, and wait; and allow Core Bluetooth to reconnect and let us
know on the appropriate delegate method. Turning on scanning is purportedly not
necessary.
Now, what we are actually seeing, is that occasionally we will have a
CBPeripheral in the .connecting state, that refuses to connect even though our
device is right next to the phone for multiple minutes.
Our device has a fairly slow advertising interval, so our first thought was,
oh, the phone just isn't seeing the ads, it'll get there eventually.
But!
I tried turning on scanning (we use
[CBCentralManagerScanOptionAllowDuplicatesKey: true].) And lo and behold, the
advertisements were coming through!
We have clear cases where we have a CBPeripheral, in the .connecting state, and
we are seeing advertisements from the device (via
centralManager(central:didDiscover:...) that peripheral ), so it's clearly in
range... but the connection just never opens.
So I added a mitigation strategy: when trying to reconnect a peripheral, turn
on scanning; then if n advertisements for that peripheral are seen within an x
second window, call central.cancelPeripheralConnection(peripheral) (and then
call central.connect(peripheral) on the next advertisement.) This might be a
little battery-demanding, but seems to work; so we left it at that for about a
year. (current values for n and x are 6 and 60.)
More recently, I started logging this occurrence to os_log and to Crashlytics,
to see how widespread a problem this is, and in hopes that it was fixed in ios
11 or 12.
Over 20% of our customers are running into this!
Ideas? How could this state be reachable? Could my mitigation strategy be
making things worse somehow?
Worse, we've recently been getting some customer reports that our peripheral is
not always connecting, and occasionally see this ourselves (not when running
attached to Xcode, of course.) When it happens in-house, briefly turning on
Airplane Mode to power down the bluetooth radio always fixes the problem. I
don't know enough yet to say that this is related but I have a bad feeling.
(Apple engineers, if you want to peek at this I think you have some of our
device in hand ( hidratespark.com <http://hidratespark.com/> ), but let me know
if you would like some more.)
-- R.
_______________________________________________
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