Re: Not your normal BLE background issue

Subject: Re: Not your normal BLE background issue
From: Ramin Firoozye <email@hidden>
Date: Tue, 12 Jul 2016 15:56:51 -0700

A few ideas:

- You don’t mention what triggers the background scanning. Whether it’s always on or it it’s based on a timer or some other trigger. One thing to keep in mind is that in background mode scanning for devices is much slower than foreground. Also, duplicate advertising packets are filtered out. One implication is that if you already received an advertising packet while in foreground and then the app was pushed into background then you may not get the advertising again when in background. You may want to reinitialize your scanning if transitioning between background and foreground states.

- Could try assigning a background queue to the Central manager.

@property (nonatomic, strong) dispatch_queue_t centralQueue;

…

self.centralQueue = dispatch_get_global_queue(QOS_CLASS_BACKGROUND, 0);

self.centralManager = [[CBCentralManager alloc] initWithDelegate:self queue:self.centralQueue options:nil];

- When in background, apps are generally supposed to complete their task in approximately 10 seconds. If your app is taking too long it may get throttled or killed by the OS. Might want to log your application states as well as the value of UIApplication’s backgroundTimeRemaining property to see if that’s an issue. One workaround that used to work (haven’t checked if it changed in iOS 9) was to set up a background task to get around the time limit.

- If you have control over the device firmware you may want to see if tweaking the advertising interval on the peripheral side helps.

- As to why it works on some devices and not others? It might have to do in subtle variations in testing, for example starting a scan while in foreground in one case and not in another, or multiple nearby devices broadcasting at the same time.

- You don’t mention if this is a battery operated or mains-powered peripheral. If battery-operated another possible culprit is how the peripheral BLE module behaves at different voltage levels. Try connecting your peripheral to a variable power supply instead of a battery then try your tests with the voltage gradually lowered and see if the behavior changes. Verify that packets are being broadcast properly (and at the right interval) with a BLE sniffer. Sometimes it comes down to tiny, subtle issues like that.

Of course, it could always be a deep, dark issue with iOS :-)

On July 12, 2016 at 12:57:24 PM, Michael Kurtz (email@hidden) wrote:

I have an iOS application that communicates as a BLE central with proprietary BLE peripheral devices. The communication mechanism is such that a connection is created, data is sent, and the connection is broken for each discrete request. Connections are not persisted with the peripheral devices which is a requirement.

The application's plist file has bluetooth-central value in the UIBackgroundModes array. The app only scans for the peripheral's specific services. Communication in the background works perfectly on most devices. However, we have a few customers whose phones do not send BLE activity to my app in the background. I say "BLE activity" because none of my delegate methods are being called -- centralManager:didDiscoverPeripheral:advertisementData:RSSI: for instance -- so I can't say that the phone isn't seeing advertisements or other activity. Unfortunately, none of the devices I have to test with in my office experience the background communication issue.

Below are two snippets of logs from a non-working (iPhone 6+ iOS 9.3.2) and a working (iPhone 6 iOS 9.3.2) device that may help demonstrate what I am seeing.

Non-working device. Note that there is communication in the beginning (foreground) and then ~50 minutes with the phone in the background with no activity. Once the device is back in the foreground, there is activity again. The notes for the “Device Disconnected” action is the peripheral mac & total time of the connection (advertisement received to peripheral disconnection).

Timestamp Action State Mac Address & Action Notes

------------------------------------------------------------------------------------

7/10/16 13:13 Start Scan Normal

7/10/16 13:16 Device Connected Normal 6050C1002622: 1

7/10/16 13:16 Device Disconnected Normal 6050C1002622: 1.2907

7/10/16 13:17 Device Connected Normal 6050C1002622: 2

7/10/16 13:17 Device Disconnected Normal 6050C1002622: 1.2894

7/10/16 13:20 Entered background Normal

7/10/16 14:09 Entered foreground Normal

7/10/16 14:09 Device Connected Normal 6050C1002618: 0

7/10/16 14:09 Device Disconnected Normal 6050C1002618: 2.6698

7/10/16 14:09 Device Connected Normal 6050C1002618: 0

7/10/16 14:09 Device Disconnected Normal 6050C1002618: 2.5114

Working block is data from a customer who keeps the phone in the background most of the time while using the devices. Notice that there is consistent activity after the device has logged that it is entering the background.

Timestamp Action State Mac Address & Action Notes

------------------------------------------------------------------------------------

7/8/16 14:05 Device Connected Normal 6050C100067C: 2

7/8/16 14:05 Device Disconnected Normal 6050C100067C: 1.1910

7/8/16 14:05 Entered background Normal

7/8/16 14:06 Device Connected Normal 6050C100067C: 1

7/8/16 14:06 Device Disconnected Normal 6050C100067C: 1.5235

7/8/16 14:06 Device Connected Normal 6050C100067C: 2

7/8/16 14:06 Device Disconnected Normal 6050C100067C: 1.1698

7/8/16 14:07 Device Connected Normal 6050C100067C: 1

7/8/16 14:07 Device Disconnected Normal 6050C100067C: 1.4137

7/8/16 14:07 Device Connected Normal 6050C100067C: 2

7/8/16 14:07 Device Disconnected Normal 6050C100067C: 1.1710

7/8/16 14:07 Device Connected Normal 6050C100067C: 1

7/8/16 14:07 Device Disconnected Normal 6050C100067C: 1.4856

7/8/16 14:07 Device Connected Normal 6050C100067C: 0

7/8/16 14:07 Device Disconnected Normal 6050C100067C: 2.9013

7/8/16 14:08 Device Connected Normal 6050C100067C: 2

7/8/16 14:08 Device Disconnected Normal 6050C100067C: 1.2361

7/8/16 14:09 Entered foreground Normal

iOS 9.3.2, iPhone 5s, 6, 6s, 6+ have shown the problem, Xcode 7.3.1, ST Micro BlueNRG Stack 6.4 Peripheral

Can anyone provide some insights on why this intermittent activity may be occurring and/or some things I can do to help troubleshoot what might be happening? I do have some limited access to one such device from one of our customers. If there is some additional debugging I can enable on his phone, I'm sure I could get it setup.

Thanks so much,

-Mike
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:

>Not your normal BLE background issue (From: Michael Kurtz <email@hidden>)

Prev by Date: Re: Not your normal BLE background issue

Next by Date: Not your normal BLE background issue

Previous by thread: Re: Not your normal BLE background issue

Next by thread: Not your normal BLE background issue

Index(es):

Date

Thread