Apple

Le 22 avr. 2014 à 15:56, Effie Arditi <email@hidden> a écrit :

According to my tests, yes.
When a disconnection occurs due of device out of range, then you get back to range, eventually, iOS will connect again (emphasising the 'eventually' term).

I've made some tests for this particular scenario - I created a disconnection (by walking away from the device until I've got the disconnection event), then came back to range.
the results are:

out of around 50 test, the device was re-connected to the iPhone at 100% of the times. The issue here was how long did it take it to reconnect.
Worst case: 125 seconds.
Best case: 9 seconds.

Average: 43 seconds.
(I tested it in a few disconnection modes, sometimes for a minute, sometime for a few hours.. but it was always re-connected eventually).

Another thing I tested and looks interesting is connect to device without scanning.
It's not as weird as it sounds:
- After your initial scan, you find your peripheral and hold reference to it.

From now on, you can actually connect to it even without scanning, just by using the 'connectPeriphral' function of the central.
So maybe If your app is in the background, you can start a background task (you have 10 minutes for that) using 'beginBackgroundTaskWithExpirationHandler'

and there you can run a timer that tries to connect to your peripheral every interval (5 seconds lets say).

But it's kind of a long shot, I've never tested it throughly.

Good luck,
Please update with the results.

On Tue, Apr 22, 2014 at 10:49 AM, Mark <email@hidden> wrote:

Hi Effie,

Thanks a lot for your response, i’m glad i’m not alone with this problem…. (at least i’m not crazy !)
Disconnecting from the peripheral is interesting, i never thought about that, however i’m not able to do that, when a disconnection occurred on my side, it’s because the device is out of reach…. If the device is in range i want to stay connected to it.

Do you think a timeout disconnection behave the same way as a peripheral disconnection ?

Thanks
Mark

Le 18 avr. 2014 à 17:14, Effie Arditi <email@hidden> a écrit :

Hi Mark,
I have found something really interesting.
I was struggling in this exact issue for days until I've found a reasonable "almost 100%" solution.

I have a central (the app) that scans for a specific device with a specific service all the time, 24/7 (my device is a pedometer)

whenever my device has interesting data to send (let's say it has aggregated a few steps) it advertises and pass the data whenever a connection is established.

As you mentioned, when the app is in the foreground, everything is perfect.

When the app is in the background there are 3 scenarios:
App in the background, phone is unlocked - Works perfect
App in background, phone is locked, screen is lighted - Works perfect

App in background, phone locked, screen is off - Doesn't work!
Now, Let's focus on the 3rd scenario:
If my app is running in a background and the phone is locked and the screen is off when my device is advertising - the central will not find it nor connect it.

whenever I cause the screen to light up (by clicking the home button or the lock button at the iPhone top) - Voilla! - within 1 to 5 seconds I get the central to connect to the device.

Now the plot thickens:

By working on the app and running it for several days, I found that this behaviour is not consistent.
Sometimes my phone was away from my device for a few hours, then, whenever I got close to the device, my app discovered it (without me touching anything, my phone was locked, and screen is off).

then I figured out that Apple has a timeout for re-discovering a device when the app in the background and phone is locked (with screen off).

But this made me try something totally different:

After passing the data from the device to the phone, I killed the connection completely, then after a minute of disconnection, I started advertising again.
In this case, the phone, in almost 100% of the times manages to find and connect to the device even if it's locked with screen off.

2 things to know about this solution:
It takes the phone between 10 seconds to 5 minutes to make the connection.
The connection HAS to be killed by the device itself (because the disconnection function of the iOS BLE stack is not a real low level disconnection)

Depending on what your peripheral does and the nature of the connection,
this solution may suit you.

Please let me know what do you think.

On Fri, Apr 18, 2014 at 1:12 PM, Mark <email@hidden> wrote:

Hi,

I got a problem with the BLE detection when the device locked.

Basically i have an app, the central, which scan for peripherals with a specific service.
Everything works great in the foreground AND the background (i’m able to detect the device multiple time with the option CBCentralManagerScanOptionAllowDuplicatesKey even if i’m in background, which is not what the documentation said…)

My real problem is that as soon as i lock my phone, my app is unable to detect any peripherals (old and new one), unless i set a really short advertisement interval (30 ms) on my peripheral, which is not possible. I asked the question to the Apple tech support but they affirm to me that there is no difference between an app one background with the device locked and unlocked, but my console logs show me the opposite.

In my console logs, when i lock my device i can see this:

Apr 18 10:35:10 iPhone-de-Mark SpringBoard[33] <Notice>: (Note ) MC: Locking device.

Apr 18 10:35:10 iPhone-de-Mark wirelessproxd[67] <Notice>: (Note ) stopDeviceScan: DBDeviceTypeATVSetup (4)

Could it be related ? (it seems to be a private API and i have no clue of what it really does)

Is there a way to discover peripherals with a reasonable advertisement interval in background with the phone locked ?

Here is my config:
iPhone 5 iOS 7.1

And my code for launching a scan

dispatch_queue_t backgroundQueue = dispatch_queue_create("fr.mark.testBLE", DISPATCH_QUEUE_SERIAL);

self.manager = [[CBCentralManager alloc] initWithDelegate:self queue:backgroundQueue options:@{CBCentralManagerOptionRestoreIdentifierKey:@"test.demo"}];

NSDictionary *options = [NSDictionary dictionaryWithObjectsAndKeys:[NSNumber numberWithBool:YES], CBCentralManagerScanOptionAllowDuplicatesKey, nil];

[self.manager scanForPeripheralsWithServices:@[KITI_SERVICE] options:options];

Thanks
Mark

_______________________________________________
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

References:
	>BLE and device locked (From: Mark <email@hidden>)
	>Re: BLE and device locked (From: Effie Arditi <email@hidden>)
	>Re: BLE and device locked (From: Mark <email@hidden>)
	>Re: BLE and device locked (From: Effie Arditi <email@hidden>)