site_archiver(a)lists.apple.com
Delivered-To: bluetooth-dev(a)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(a)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(a)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(a)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(a)apple.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com
site_archiver(a)lists.apple.com
Delivered-To: bluetooth-dev(a)lists.apple.com
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hidrate-me.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=7T/YHZGiQZ5tpjkNQg4UYA/WnBmFtMARI+w8NmhStVA=; b=xFZZyZBKXteQ7ZiWTDH7aLgfHMi2SRLx4ihmBe/94M4cfFvsNx/fq9BnHIDrTKCn2v +TdAlb8DAbptvHrF6T+YEEvJQRMfOTWUHraIetuPuxHkNWVNiB/VRfBvhKYoIGJx/4U4 2FN5q/GrSoGwP33flOxdKGwn1Xn+0SnCdfWv6LTK/tb7bQGE+qBK2oraRlR1afdBYN5T 2jOss8GJz8JrNJjjhb6Q5bYvLu9FOtXbWNHeKn/RX4YSmuxTZCWFdU1OhcepKexIGmrN A79G+gHxb2MHMkINLs/lGVBOpRujZguIwAcCdv43+8ZqeBH32KL8yJlQdk95DGJWhox0 5FLA==
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(a)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(a)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(a)lists.apple.com