Hi Scott, >>>> RSSI property is inquiry RSSI and this should be stated here especially >>>> that we plan to add connection RSSI property soon. >>> >>> Does connection RSSI really need to be a separate property? Why can't >>> the same property be used for both? It's the same device after all. >> >> the problem is that they are different. They get measured differently. One is essentially tight to the Inquiry TX power and the other to the TX power of the connection. Results will be different. This has always been the problem with Bluetooth’s RSSI. Mapping the RSSI you got Extended Inquiry Result to Read RSSI is not possible. >> > > LE Devices aren't ever in a situation where they are Advertising > during a Connection though, right? they can be. Bluetooth 4.1 introduces link layer topology. As long as your controller supports this state, you can advertise again. > So either the RSSI + TX Power are relevant to Inquiry (when Connected > = false) or relevant to Connection (when Connected = true) We can do that, but it is also semantic wise a bit of a nasty thing to do. The meaning of a property changes depending on if another property is true or false. Sounds like a hack to me. > Since the Connection RSSI on a Classic device is always just deviation > from the golden range, the RSSI field isn't even that interesting in > those cases. For BR/EDR this is mostly irrelevant. However in combination with TX power you can calculate the path loss and that makes it interesting again. 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
