• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Bluetooth-dev Digest, Vol 13, Issue 75
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bluetooth-dev Digest, Vol 13, Issue 75

  • Subject: Re: Bluetooth-dev Digest, Vol 13, Issue 75
  • From: Ramin Firoozye <email@hidden>
  • Date: Fri, 22 Jul 2016 16:13:41 -0700
Hmm. That DBL_MAX value is a little strange. The value should be something small when in background. Not sure what’s going on there.

The issue with foreground vs. background scan is that when in background mode the CBCentralManagerScanOptionAllowDuplicatesKey is ignored. So if you continue scanning as before AND the device was seen before, it’s possible it won’t be signalled again once you’re in the background. 

More details here:

https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html#//apple_ref/doc/uid/TP40013257-CH7-SW1

Of special note is this section:

Although you can perform many Bluetooth-related tasks while your app is in the background, keep in mind that scanning for peripherals while your app is in the background operates differently than when your app is in the foreground. In particular, when your app is scanning for device while in the background:

  • The CBCentralManagerScanOptionAllowDuplicatesKey scan option key is ignored, and multiple discoveries of an advertising peripheral are coalesced into a single discovery event.

  • If all apps that are scanning for peripherals are in the background, the interval at which your central device scans for advertising packets increases. As a result, it may take longer to discover an advertising peripheral

My suggestion was to stop/restart scanning to allow the system to flush its cache and see the device a second time. But it’s entirely possible that CoreBluetooth is caching all that internally so it may not do any good. It’s an easy experiment. FWIW, in most situations the scanning is done in foreground and the connection is kept open in background mode. That works fine.

Changing your advertising packet is likely in one of the data sections (perhaps, manufacturing data). If the device advertising address isn’t changing then it’ll likely be bunched with previous packets from the same device and get ignored the same way.

One suggestion: might consider broadcasting the data you need as an iBeacon packet and putting the custom data into the major/minor fields. That way you can use iOS location services and set up a beacon scan in the background. It comes with some other restrictions but it might be your only choice if you absolutely need background support.


On July 13, 2016 at 3:31:35 PM, Michael Kurtz (email@hidden) wrote:

Ramin,

Thanks for the quick response.  The DBL_MAX value is returned in the background.  Here’s a snippet of the log created on my phone showing the transition to background and a connection that occurs after the transition.

7/13/16 13:56 Start Scan Normal
7/13/16 13:57 Resign Active Normal AppDelegate.applicationWillResignActive
7/13/16 13:57 Entered background Normal AppDelegate.applicationDidEnterBackground
7/13/16 13:57 Background time Normal centralManager:didDiscoverPeripheral:advertisementData:RSSI: - 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000 secs.
7/13/16 13:57 Background time Normal centralManager:didConnectPeripheral: - 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000 secs.
7/13/16 13:57 Background time Normal peripheral:didDiscoverServices:error: - 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000 secs.
7/13/16 13:57 Background time Normal peripheral:didDiscoverCharacteristicsForService:error: - 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000 secs.
7/13/16 13:57 Background time Normal peripheral:didUpdateNotificationStateForCharacteristic:error: - 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000 secs.
7/13/16 13:57 Background time Normal peripheral:didUpdateNotificationStateForCharacteristic:error: - 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000 secs.
7/13/16 13:57 Background time Normal peripheral:didUpdateNotificationStateForCharacteristic:error: - 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000 secs.
7/13/16 13:57 Background time Normal peripheral:didUpdateNotificationStateForCharacteristic:error: - 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000 secs.
7/13/16 13:57 Device Connected Normal 6050C100059D: 1
7/13/16 13:57 Background time Normal peripheral:didWriteValueForCharacteristic:error: - 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000 secs.
7/13/16 13:57 Device Disconnected Normal 6050C100059D: 1.6667
7/13/16 13:57 Start Scan Normal

I used to stop scanning after I detected a device and called connectPeripheral.  I then restarted scanning inside of the peripheral:didDisconnect method.  I no longer do that and just re-establish the scan in the peripheral:didDisconnect method.  This problem has remained through both scenarios.  There are multiple peripherals that I may need to connect to so not stopping the scan is the preferred procedure.

One area that is confusing is the matter of aggregated/ignored advertisement packets.  If I respond to an advertisement and connect, talk, and then disconnect will I get advertisements from the peripheral the next time it advertises?

Also, in my current peripheral implementation, I am modifying the advertisement payload slightly (swapping 1 byte in the CBAdvertisementDataLocalNameKey data) each time the device starts advertising.  My thought was that each time the peripheral wishes to connect to the central, the advertisement will look different and therefore, hopefully not be ignored.  Doesn’t seem to help this particular situation though.

Thanks again for the thoughts and ideas.

-Mike

On Jul 13, 2016, at 2:54 PM, Ramin Firoozye <email@hidden> wrote:

Replies inline.

On July 13, 2016 at 2:06:27 PM, Michael Kurtz (email@hidden) wrote:
Ramin, 

One more quick note. The backgroundTimeRemaining value is DBL_MAX when my Core Bluetooth delegate handlers are called. 


That looks like the number you get if you check the value when app is in foreground. Once it’s in the background it should be a much smaller value (around 10,000 milliseconds) or maybe a bit longer if you’ve created a separate background task. You may want to check that you’re logging that value only when in background.


Thanks, 

-Mike 

> 
> Message: 1 
> Date: Tue, 12 Jul 2016 21:07:44 -0700 
> From: Michael Kurtz <email@hidden> 
> To: email@hidden 
> Subject: Re: Not your normal BLE background issue 
> Message-ID: <email@hidden" class="">email@hidden> 
> 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. 
> 

Unless you need to continue scanning for multiple devices, you may want to stop scanning after you’ve made a connection and then restart the scan after disconnect. It’ll help conserve battery on your phone. Issuing multiple scans for the same services… not sure it’ll do anything. At best it’ll get coalesced into one scan. At worst you’ll get multiple notifications when a device is seen.


> 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]; 

My suggestion is to stop scanning and restart it when enterBackground is called AND you’re not connected. If you’re already connected, then you don’t have to do anything. It’s just a guess, but if you don’t do anything the advertising packets may be ignored when in background since allow-duplicates is ignored. This is a quick and dirty test to see if it helps CoreBluetooth notify when it sees the advertising packets in background.


> 
> 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? 
> 

Yes. You should be able to replace it with the background queue. 


> 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? 
> 

Not knowing what your app is doing I was just speculating about why it might not be responding. In background mode scanning just takes longer. You may want to log the timestamps for when you start scanning and when you actually get a scan result. That should give you some insight as to why the app isn’t responding when it goes into background.


> 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? 
> 

The range sounds fine. But if it’s an easy test, try dropping it and then check in your logs to see if the devices show up more regularly. You can then adjust it back up until it stops working again. The more you advertise obviously the more juice the peripheral will use.


> 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. 
> 

Good, that knocks off one of your potential issues. Althought you’d do better if you could get your hands on a phone that consistently failed.


> 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. 
> 

It’s always good to have a decent sniffer around. Sometimes it’s best to try that first just to eliminate low-level issues as a cause. Another suggestion is to contact Apple DTS and have them provide you with a Bluetooth debugging profile. That will help you see a lot of low-level events on the iOS side.

Best of luck,

Ramin


 _______________________________________________
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
  • Follow-Ups:
    • Re: Not your normal BLE background issue
      • From: Michael Kurtz <email@hidden>
References: 
 >Re: Bluetooth-dev Digest, Vol 13, Issue 75 (From: Michael Kurtz <email@hidden>)
 >Re: Bluetooth-dev Digest, Vol 13, Issue 75 (From: Ramin Firoozye <email@hidden>)
 >Re: Bluetooth-dev Digest, Vol 13, Issue 75 (From: Michael Kurtz <email@hidden>)

  • Prev by Date: Re: Not your normal BLE background issue
  • Next by Date: Re: Not your normal BLE background issue
  • Previous by thread: Re: Bluetooth-dev Digest, Vol 13, Issue 75
  • Next by thread: Re: Not your normal BLE background issue
  • Index(es):
    • Date
    • Thread