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:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=iRnFbQGGIkdtgAA5OkCXpQlgoVaPkYRBXBknqrQGYmg=; b=AjS3un2JvgXdVB363rYkF6rRwK0/y7jWW7DGOd9NLf8m0gOfh+7mwaog+KRwUMCD4v MFvEt/A9YfHuzKlPw/xmhPvisHX6DKe+AW1ZfwUPGYrwvv6X51O9Vy9fT2dKvabgH/vw GTZV8G0hCGkyOUOS+0p33ypIx7aomvgZxlOdcCM1UaE4KD5d1wcow3BwkdX+ZUORKgaM /fDg4fgYO0T7kQZUpMcyJRWmZ4KVhtxav6SoPeTBA+wRD5uCM0N0y785OpB6us2YITnD 3CE9wplr5BmCuHVkmr26fALK+3Q3i0Fx7ehyI4dHdbEUlA1Ji/TOnerqmP+J6xwyXKYc uiFA== I want to make sure this is normal, expected behavior, and I'm mitigating it properly. Our app connects to a Cypress PSoC-4 based peripheral. Normally, when our device advertises, we see: our CBCentralManager calls our delegate's centralManager(_ central:, didDiscover peripheral:, advertisementData, rssi RSSI:); we call connect(peripheral) if appropriate; and eventually our delegate gets a call to centralManager(_ central:,didConnect peripheral:). All as expected, well and good. But.

From time to time, our peripheral would be powered on, in range, the corresponding CBPeripheral would be in the .connecting state, app in foreground... and no connection would happen. Sometimes after waiting several minutes it would connect, sometimes not. Turning bluetooth off and on (using airplane mode, so bluetooth really did get turned all the way off) always resulted in immediate connection success.

Adding the CBCentralManagerScanOptionAllowDuplicatesKey to our scanning confirmed that the delegate was still getting repeated calls to the didDiscover method. Thus, our mitigation: when we see advertisements for a peripheral that we're trying to connect to, if we see more than six in 1 minute with the peripheral still in .connecting state, we cancel and retry the connection attempt. This seems to mostly work. We also log an event to Crashlytics, where we see that this is happening to 20% of our customers! Is this right? Is this how Core Bluetooth is expected to behave? Is there something I could be doing differently, or a better mitigation strategy? We've seen this on all iOS since 9. (I've asked about this before, am trying for less verbosity this time) -- 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