site_archiver@lists.apple.com Delivered-To: bluetooth-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hidrate-me.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=2sKykaPIIY0kjL1lSvutkPFGgQen188UBzW7szA2c48=; b=xwu/j0vQn+mGCspRQo6PO1Ryl/Z5zOBde/DahcpDv00auit91a15/XZEqDlkBgB+vn I4uhNhIaKhFYYFLZMUdAuz5/E3wUR0x7AGXh+Aozq8r6CgeUY4PC7DqlLbfmN5pFPyZj 6A6fzW7F0YEtyU338HdyWpDn1y72FyMe5T2yzA806Iv5TCRvBttB5v9fnyZJWSN+FqrA YmLbAq+j/pjv54jUupWSDDHi/Yydf0bXTWJfrMmscylRAOJ+auoBn9JQSJ5yfB3nlEJO 9s8ZwTzPwPr8fihYyrfMH5tazgaCKMA1o8aHbVt9dlA6Vyuv8Ehl7hJRkWUY9abTcZCZ HD+A== 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 (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