Hi,
I have a question about behaviour establishing connections that seems
to have changed between different versions of BlueZ, and I'm hoping
someone will be good enough to help explain what's going on for me!
I have a test program that opens an L2CAP connection to a device,
reads the RSSI, closes it again, waits a few seconds and repeats the
process. Optionally, it will do clock caching - i.e. read the clock
offset when a connection is established and pass this in when making
the next connection. Using version 3.18 the BlueZ libraries, this
behaves more or less as I would expect: if clock caching is not
turned on, the connection times are distributed fairly evenly and if
it is they are much quicker and fairly constant (e.g. 1300 ms, plus or
minus a hundred or so for a particular device). Using various
subsequent versions however (in particular 3.29 and 4.22) we see
different behaviour: whether clock caching is turned on or not, the
connection times follow a sawtooth pattern, starting very low (about
100 ms), then going up steadily in increments of a couple of hundred
ms until they reach a peak (1000-2000) and then fall back to a very
low value and the process repeats. I'm somewhat confused as to why
this is happening - I've tried to read through the code changes but
without much success. Can anyone shed any light on this for me?
Thanks very much in advance for your help!
Simon
Hi Simon,
> > I don't see any issue here, but the whole concept of connecting to a
> > remote device to read its RSSI is broken by design. The RSSI value
> > of an
> > already connection is basically useless. What you want is the link
> > quality, but even that doesn't really help you since it is vendor
> > specific and every company defines it differently.
>
>
> Thanks for the reply. I appreciate your point about RSSI vs link
> quality, and understand the issue there, but actually that's
> incidental to the point I'm really trying to understand - reading the
> RSSI is just something to do with the connection before I throw it
> away again. I'm trying to get to the bottom of what's changed to
> cause the different behaviour in the connection times - why passing in
> a clock offset doesn't seem to make a difference any more, and why we
> see this regular pattern of times going up and up then jumping back
> down again. Is there anything that was deliberately changed in this
> regard, or is it a side effect of something else?
you can't pass in the clock offset except you use the low-level HCI
Create Connection command. And that is not guaranteed to work as
expected at all. The kernel has full control over these information and
you should not mess with it. However when reading the clock offset of a
remote connection the kernel will store that clock offset and reuse
during the next connection attempt. You have to create proper L2CAP
connections and not just fake them via HCI Create Connection.
Regards
Marcel
Hi Marcel,
On 19 Dec 2008, at 18:49, Marcel Holtmann wrote:
>
> I don't see any issue here, but the whole concept of connecting to a
> remote device to read its RSSI is broken by design. The RSSI value
> of an
> already connection is basically useless. What you want is the link
> quality, but even that doesn't really help you since it is vendor
> specific and every company defines it differently.
Thanks for the reply. I appreciate your point about RSSI vs link
quality, and understand the issue there, but actually that's
incidental to the point I'm really trying to understand - reading the
RSSI is just something to do with the connection before I throw it
away again. I'm trying to get to the bottom of what's changed to
cause the different behaviour in the connection times - why passing in
a clock offset doesn't seem to make a difference any more, and why we
see this regular pattern of times going up and up then jumping back
down again. Is there anything that was deliberately changed in this
regard, or is it a side effect of something else?
I really appreciate all your help and patience on this!
Simon
Hi Simon,
> I have a question about behaviour establishing connections that seems
> to have changed between different versions of BlueZ, and I'm hoping
> someone will be good enough to help explain what's going on for me!
>
> I have a test program that opens an L2CAP connection to a device,
> reads the RSSI, closes it again, waits a few seconds and repeats the
> process. Optionally, it will do clock caching - i.e. read the clock
> offset when a connection is established and pass this in when making
> the next connection. Using version 3.18 the BlueZ libraries, this
> behaves more or less as I would expect: if clock caching is not
> turned on, the connection times are distributed fairly evenly and if
> it is they are much quicker and fairly constant (e.g. 1300 ms, plus or
> minus a hundred or so for a particular device). Using various
> subsequent versions however (in particular 3.29 and 4.22) we see
> different behaviour: whether clock caching is turned on or not, the
> connection times follow a sawtooth pattern, starting very low (about
> 100 ms), then going up steadily in increments of a couple of hundred
> ms until they reach a peak (1000-2000) and then fall back to a very
> low value and the process repeats. I'm somewhat confused as to why
> this is happening - I've tried to read through the code changes but
> without much success. Can anyone shed any light on this for me?
I don't see any issue here, but the whole concept of connecting to a
remote device to read its RSSI is broken by design. The RSSI value of an
already connection is basically useless. What you want is the link
quality, but even that doesn't really help you since it is vendor
specific and every company defines it differently.
Regards
Marcel