Hi Peter and Bob,
Currently, the switching instance (for moving to the new connection parameters) can be optimized by moving it closer in time. We are looking into addressing this in a future release.
Also, caching of services and characteristics is also being investigated for a future release.
Thanks, Joakim
On Mar 12, 2012, at 12:24 PM, Peter Skinner wrote: Hi Bob,
Thanks. It's helpful to hear you've worked through the same issues.
I was able to implement a minimal level of power saving without hurting the user experience by changing only the slave latency to 4 when backgrounding. Even though it doesn't return to the usual 0 until a few seconds after the app becomes active, it's not something the user would notice. When backgrounding, a lower connection interval would have saved much more power, but I think it's better to waste a user's battery than make them wait a few seconds.
I did end up trying to disconnect and reconnect when backgrounding/foregrounding, but found the same result of needing to rediscover everything, and this isn't fast.
From the bt design guidelines:
"The Bluetooth accessory should implement the Service Changed characteristic only if the accessory has the ability to change its services during its lifetime. The Apple product may use the Service Changed characteristic to determine if it can rely on previously read (cached) information from the device. See the Bluetooth 4.0 specification, Volume 3, Part G, Section 7.1."
After removing the Service Changed characteristic from my peripheral, I was hopeful that the peripheral's services would be cached after disconnecting. However, after disconnect, my call to [peripheral services] returned only null, so they are still being dropped. It would be nice to have these live on a little longer, or maybe have the manager discover them from a cache instead of over the air on reconnect.
Thanks,
Peter Skinner
Ten One Design 201-965-0200
On Mar 10, 2012, at 6:14 PM, Bob Frankel wrote:
hi peter
i've had similar experiences, with the "instant" the switch to
the new rate actually takes places being about 5 seconds in the
future from the time the peripheral makes the connection
parameter update request....
as for connecting/disconnecting, that might help a little --
though not much, in our experience.... by default, ios seems to
use a connection interval of around 104ms when initially
connecting; and even when it immediately receives an parameter
update request (say, to a faster interval like 20ms), we don't
see the change take effect for another 5 seconds.... as it
turns out, there is *lots* of packet activity involved in simply
(re-)discovering services/characteristics that don't seem to be
cached -- about 4 seconds worth at the 104ms rate!!!! bottom
line -- it's takes about 4-5 seconds to connect (which is
admittedly better than 10 seconds in your case, though still
ideal for a user-experience IMHO).... were the rate switch to
occur sooner, however, connection would take about 1 second....
bob.
On 3/9/2012 10:42 PM, Peter Skinner wrote:
Hello,
Our BLE accessory is only used when an app is active. It
makes a lot of sense to put it in a lower power state when the
app moves to the background
Our app sends a message to the accessory when it is time to
switch connection parameters. The accessory then makes a
standardL2CAP Connection Parameter Update Request for a longer
connection interval.
I can see using a sniffer that iOS 5.1 immediately accepts
the connection parameter update request, and sends the
LL_Connect_Update_Req with the new interval, but the 'Instant'
it chooses to make the switch (the connEventCount) can be fairly
far in the future.
As a result, when switching back to the app, I will typically
see a delay of about 10 seconds before the accessory has
switched back to a faster connection and becomes usable. That's
too long for a user to wait, so I'm working on
disconnecting/reconnecting the accessory instead to see if
that's faster.
Does this sound about right? Are there any guidelines that
will allow these connection update transactions to happen
faster?
Thanks,
Peter Skinner
Ten One Design
201-965-0200
_______________________________________________
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
|