Hi,
A quick follow-up to give my observations on the following point from Roland King:
After running some tests and inspecting the on-air packets via the sniffer, I see the following behaviour:
Case 1:
Connect only, cache connected device (in UserDefaults), re-connect later using device in cache (retrievePeripheral)
In this case, iOS stack will again pull services and characteristics (all of them) over the air
Case 2:
Pair only (no bonding), cache connected device, re-connect later using device in cache (retrievePeripheral)
Note: pairing only was achieved by setting GAP parameters MITM=FALSE, Bonding=FALSE on the peripheral
In this case, iOS stack will again pull services and characteristics (all of them) over the air
Case 3:
Bond the peripheral, cache connected device, re-connect later using device in cache (retrievePeripheral)
Note: bonding was achieved by setting GAP parameters MITM=TRUE, Bonding=TRUE on the peripheral
In this case, iOS stack does not pull services and characteristics over the air. It must use cached parameters
However, in all cases, connecting to the peripheral is painfully slow (10-15 secs in some cases). So, neither pairing or bonding is helpful in speeding up the initial connection
Regards,
Andrew Coad
Subject: Re: Reconnecting a peripheral
From: email@hidden
Date: Sat, 11 Jul 2015 14:52:37 +0800
CC: email@hidden
To: email@hidden
Searching through this forum and stackoverflow is seems clear that, after disconnecting from a peripheral, you must go through the service(s) & characteristic(s) discovery process again after reconnection before you can interact with a characteristic.
The project that I am working on is a central (iOS device) and controlled peripheral (TI CC2541 device). Communication is predominantly control sequences from the iOS device to the peripheral. Following Apple's guidelines, I should be connecting, transferring data, disconnecting in order to "minimise radio usage."
To avoid the need to re-discover services and characteristics, I could leave the connection open for as long as the iOS application is running. What is the impact of doing so? Will the iOS device's radio be on for the duration and, presumably, draining the battery more quickly? What about the peripheral? Will maintaining an open connection have any adverse impact on battery life of the peripheral?
If you leave the connection open you will drain the iOS battery, the peripheral battery (assuming your advertising power consumption is less than your connection power consumption which is a factor of advertising interval and payload vs connection interval and slave latency).
However iOS caches services and characteristics on devices it’s connected to so just reconnecting to the device by UUID should mean that yes you still do the service discovery and characteristic discovery again but the results come from the cache and aren’t re-transferred from the peripheral.
Now where I get confused is whether a peripheral needs to be bonded in order to get this behaviour or not. I thought not, it was based on the address of the device as long as BTLE hasn’t been turned off etc etc. but I’m quite prepared to be wrong on that point.
Note that during development I usually use a randomly generated address each time I start up in order to avoid any of the iOS caching behaviour because I’ve found it doing odd things before.