July 2016 - Bluetooth-dev - lists.apple.com

Re: Bluetooth-dev Digest, Vol 13, Issue 75
by Michael Kurtz 13 Jul '16

13 Jul '16

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Bluetooth-dev Digest, Vol 13, Issue 75
by Ramin Firoozye 13 Jul '16

13 Jul '16

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Bluetooth-dev Digest, Vol 13, Issue 75
by Michael Kurtz 13 Jul '16

13 Jul '16

Ramin, One more quick note. The backgroundTimeRemaining value is DBL_MAX when my Core Bluetooth delegate handlers are called. Thanks, -Mike > > Message: 1 > Date: Tue, 12 Jul 2016 21:07:44 -0700 > From: Michael Kurtz <mkurtz(a)kineteksports.com> > To: bluetooth-dev(a)lists.apple.com > Subject: Re: Not your normal BLE background issue > Message-ID: <22711196-6F19-4647-AF73-D3CF1EBB030E(a)kineteksports.com> > Content-Type: text/plain; charset="utf-8" > > Ramin, > > Thanks for your response. Here are some additional details based on your questions. > > 1. Scanning is always on. I previously had scanning on until a connection was made. Once the connection was completed, data was passed, and the disconnect completed, I would restart scanning. However, the behavior was the same in that scenario. I have since removed the stopScan call so once the scan has started, it is never stopped. I do still call scanForPeripheralsWithServices:options: after each disconnect to ensure that the scan is still active. > > 2. When you say “reinitialize your scanning” are you saying to perform a stopScan followed by a scanForPeripheralsWithServices:options: within my background notification handler? I currently have a registration for background and foreground notifications which is where I am currently logging those entries. > > For example: > [[NSNotificationCenter defaultCenter] addObserver:self > selector:@selector(enterBackground:) > name:UIApplicationDidEnterBackgroundNotification object:nil]; > > 3. I am currently providing a queue to the CBCentralManager that is initialized like the following: > dispatch_queue_create("com.kineteksports.BLEEventQueue", DISPATCH_QUEUE_SERIAL) > Can I just replace this with the BACKGROUND_QUEUE you mention or should I swap queues when going to the background? > > 4. The app is not getting killed by iOS. The entire BLE connection, which is multiple callbacks, lasts less than 3 seconds typically and each specific notification processing lasts under 1 second. I will add the UIApplication’s backgroundTimeRemaining to my log, though, just to be sure. Should I log this within each notification handler? > > 5. I do have control over the peripheral. The advertising interval is currently setup with a minimum of 20ms. (0x0020) and a maximum of 100ms. (0x00A0). Do you see an issue with this range? > > 6. The peripheral is battery operated although I have done testing using a bench supply ranging the voltage from ~2.4 volts up to 3.0 volts. On the phones I have direct access to, the times are consistent in background (a bit slower) and foreground regardless of input voltage. > > 7. I haven’t looked at the packets using a sniffer in a long time since we haven’t had any problems until the app started getting broader usage by many more devices and in more environments. I will revisit that. > > Thanks again for the info and insights. > > -Mike > >> Date: Tue, 12 Jul 2016 15:56:51 -0700 >> From: Ramin Firoozye <raminf(a)gmail.com <mailto:raminf@gmail.com>> >> To: Michael Kurtz <mkurtz(a)kineteksports.com <mailto:mkurtz@kineteksports.com>>, >> bluetooth-dev(a)lists.apple.com <mailto:bluetooth-dev@lists.apple.com> >> Subject: Re: Not your normal BLE background issue >> Message-ID: <etPan.578575b8.333beb7a.2418(a)gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> 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 (mkurtz(a)kineteksports.com) 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 (Bluetooth-dev(a)lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/bluetooth-dev/raminf%40gmail.com >> >> This email sent to raminf(a)gmail.com >>

1 0

Re: Not your normal BLE background issue
by Michael Kurtz 13 Jul '16

13 Jul '16

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Not your normal BLE background issue
by Ramin Firoozye 12 Jul '16

12 Jul '16

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Not your normal BLE background issue
by Michael Kurtz 12 Jul '16

12 Jul '16

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Re: Not your normal BLE background issue
by Jason Conn 12 Jul '16

12 Jul '16

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Not your normal BLE background issue
by Michael Kurtz 12 Jul '16

12 Jul '16

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

Not your normal BLE background issue
by Michael Kurtz 11 Jul '16

11 Jul '16

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0

didWriteValueForCharacteristic being called after writing .WithoutResponse
by Rene Limberger 10 Jul '16

10 Jul '16

We are seeing a case where writing data using .WithoutResponse: peripheral.writeValue(data, forCharacteristic: characteristic, type: .WithoutResponse) Is still getting a callback to: func peripheral(peripheral: CBPeripheral, didWriteValueForCharacteristic characteristic: CBCharacteristic, error: NSError?) { The error is nil and the char is the one we just wrote to (.WithoutResponse). What could cause such behavior? iOS 9.3, iPhone 6s+, Xcode7.3.1, iOS Central, Ti CC2640 BLE Stack 2.1.0 Peripheral _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com

1 0