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 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
