site_archiver(a)lists.apple.com
Delivered-To: bluetooth-dev(a)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(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/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:message-id:date:to; bh=v2GDxBZkNXu8LTT0/95EUvkvl7EiPwnIcRHX+FWBxKY=; b=kTAnHip8avuBg8gcnVa2DJqSiUDcQCHFEb780YdqbzgWi4eEXMnn3pifxfBwFfHiaB /RDB1XVuOF0om91bVPDEM+rPqM4IJKMXF0+/usZdx5ZPHYX7KOjYwRsmTPFEvFB5camH gOQ8sPggOQheoSxxBWyW4YdMSoKO/EyS1xYQ/s4k04r/KHjdH97s9+19CZRXndXeNSjy VyuTZ9k0aaAB/G4i4g1yC2oLjX+I/Hncawe5GmnuqF12ZFANR9JQ2OW3hV3O2GpIl5Kp hl3LOdCipj+nE4j5jWQZH8+bbWPhc5bklFzXJinm7fuCjVaV2CBLYtBDIviMZrF3+MsH d2zg==
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