site_archiver@lists.apple.com Delivered-To: bluetooth-dev@lists.apple.com Great work on root-causing this problem Rogers. We appreciate the feedback. Thanks, Duy
On Dec 21, 2018, at 9:23 AM, Rogers George <rgeorge@hidrate.me> 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 <rgeorge@hidrate.me <mailto: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