Re: iOS 11, BLE and battery troubles
Re: iOS 11, BLE and battery troubles
- Subject: Re: iOS 11, BLE and battery troubles
- From: email@hidden
- Date: Thu, 03 May 2018 23:18:59 -0700
Hi Rogers,
We’ll order some of your devices to try out locally; and contact you offline to
help.
Thanks!
Duy
> On May 3, 2018, at 12:23 PM, Rogers George <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