Re: iOS 11, BLE and battery troubles
Re: iOS 11, BLE and battery troubles
Great work on root-causing this problem Rogers. We appreciate the feedback.
Thanks,
Duy
> On Dec 21, 2018, at 9:23 AM, Rogers George <email@hidden> wrote:
>
> Hi again,
>
> I thought other bluetooth developers might like to know how this shook out. A
> number of dead ends and false leads were explored, but in the end, this is
> what worked.
>
> We deployed a special version of our device's firmware that would collect,
> and transmit back to us, various statistics regarding bluetooth connection
> parameters. How much time spent at each connection interval, whether speed
> negotiations were denied, etc.
>
> From the customers with battery problems, we were able to determine that the
> device was frequently getting "stuck" in a high-speed connection mode. The
> initial fast connection interval was never negotiated down to a reasonable
> one, and of course this chews up battery in a big hurry.
>
> What was most interesting about this - and why we had discounted this
> possibility earlier - is that the connection interval re-negotiation was
> **not failing**! No negotiation failure was reported back to our firmware.
> It's as if the connection interval negotiation was simply disregarded. (this
> matches the Sysdiagnoses we sent to Apple [Thanks guys!] that didn't indicate
> any negotiation failures.)
>
> We had not thought this was possible.
>
> Once we realized that this was a thing that could happen, a fix was simple
> enough - add a safety timer that checks if the connection has been in
> high-speed for longer than expected and, if so, drop the connection. The
> "stuck" state, while frequent on certain phones, doesn't happen most of the
> time, so this was sufficient.
>
> takeaways:
>
> Developers: an old but evergreen lesson - there's no such thing as "can't
> happen". Handle all the cases you can think of, and then think of some more.
>
> Apple: the more visibility you can give us devs into the deep details of
> Bluetooth connections, the better. We had to explore this from the firmware
> side, because Core Bluetooth offers so little debug information beyond "it's
> working/it didn't work". But thanks for looking over those sysdiagnoses.
>
> -- R.
>
>
>> On May 3, 2018, at 2:23 PM, Rogers George <email@hidden
>> <mailto:email@hidden>> wrote:
>>
>> 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
_______________________________________________
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