Re: Bluetooth-dev Digest, Vol 13, Issue 75
Re: Bluetooth-dev Digest, Vol 13, Issue 75
- Subject: Re: Bluetooth-dev Digest, Vol 13, Issue 75
- From: Ramin Firoozye <email@hidden>
- Date: Wed, 13 Jul 2016 14:54:18 -0700
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> > 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