site_archiver@lists.apple.com Delivered-To: bluetooth-dev@lists.apple.com 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 <rgeorge@hidrate.me> 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 (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/duy_phan%40apple.com

This email sent to duy_phan@apple.com

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com