iOS 11, BLE and battery troubles
iOS 11, BLE and battery troubles
- Subject: iOS 11, BLE and battery troubles
- From: Rogers George <email@hidden>
- Date: Thu, 03 May 2018 14:23:08 -0500
Hi,
We have a fitness product on the market and selling well. It connects to our
mobile* apps via BLE. It is powered with a lithium coin cell, which is supposed
to last about six months under normal use, and usually has.
Over the last 6-8 months, though, something nasty has cropped up: a significant
number of our iOS-using customers are reporting short battery life, ranging
from just a month or so, to as short as a few days. It usually recurs over
multiple sets of batteries from different vendors, and multiple replacement
units from us. (but not always!)
As best as we can tease out from customer reports:
Signs point strongly to this cropping up alongside the iOS 11 release.
There is a faint hint that this may also be correlated with simultaneous use of
other BLE devices (Apple Watches, Fitbits, etc).
Of course, we haven't been able to reproduce this on the bench. Everything
continues to function just fine; the peripheral is just eating battery under
some mystery customer circumstance.
Is anyone here able to speak to, or point to a technote on, the detailed iOS 11
changes to Core Bluetooth and BLE?
In particular, our product does a couple of strange things that draw my
suspicion:
It does not encrypt. (no Pairing.) This used to mean we got no
Service+Characteristic cacheing - now it seems like we do?
It initially connects using a very fast connection interval, sufficient to
drain the battery in a day. Six seconds after connecting it requests
renegotiation down to a properly slow connection. Bench tests indicate this
renegotiation is happening just fine... under bench conditions.
It must, in a couple of cases, drop the connection and reconnect with a
different set of Services.
In one rare case, it has to remove a Service without telling the central about
it, and any activity on that Service's Characteristics will error out. (The app
is coded to allow for this.)
My strategy for most other BLE errors, on the app side, is to drop the
connection and let things start over.
Our app uses State Restoration support to try to get background BLE connections
to stay live even when our process is evicted.
Again, did anything change in iOS 11 that belies our assumptions here? E.g.:
Is the iPhone central now likely to deny a connection interval renegotiation,
if there is a chatty peripheral like a Watch also present?
Or are there other new-in-iOS11 errors likely to crop up, that I might not see
while developing, but might be more frequent for customers?
Is there a way to opt out of any of the new iOS11 behavior, e.g. discovery
cacheing for unencrypted peripherals?
Is there a (private-api, non-appstore, debugging only) way to monitor the
low-level parameters of a BLE connection, so we can test over a longer term of
normal use that the connection is doing what we expect?
any further info I could provide that might help?
(Am double-checking
https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf
<https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf> with
our EE already.)
-- R.
_______________________________________________
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