Hi Luiz, On 27 May 2014 14:49, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi, > > On Tue, May 27, 2014 at 10:52 AM, Andrzej Kaczmarek > <andrzej.kaczmarek@xxxxxxxxx> wrote: >> From: Lukasz Rymanowski <lukasz.rymanowski@xxxxxxxxx> >> >> This patch introduces API to monitor connection parameters. >> >> New device properties are introduced: ConnectionRSSI, ConnectionTXPower >> and ConnectionTXPowerMax. >> >> Client can request to poll for updates of RSSI and TX power via Start- >> and StopConnectionMonitor methods. >> --- >> doc/device-api.txt | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 56 insertions(+) >> >> diff --git a/doc/device-api.txt b/doc/device-api.txt >> index 577ee60..67f573c 100644 >> --- a/doc/device-api.txt >> +++ b/doc/device-api.txt >> @@ -100,6 +100,35 @@ Methods void Connect() >> Possible errors: org.bluez.Error.DoesNotExist >> org.bluez.Error.Failed >> >> + >> + void StartConnectionMonitor() >> + >> + This method starts connection monitor session. This >> + includes link RSSI and TX power. >> + Use StopConnectionMonitor to release the sessions >> + acquired. >> + >> + This process will start updating connection-related >> + properties, e.g. ConnectionRSSI and ConnectionTXPower. >> + >> + Note that all sessions for device are released when >> + device is disconnected and it's required to start >> + sessiong again once reconnected. >> + >> + Possible errors: org.bluez.Error.Busy >> + org.bluez.Error.NotConnected >> + >> + void StopConnectionMonitor() >> + >> + This method stops previous StartConnectionMonitor >> + session. >> + >> + Note that connection monitor is shared between all >> + monitor sessions thus calling StopConnectionMonitor >> + releases a single session. >> + >> + Possible errors: org.bluez.Error.Failed >> + >> Properties string Address [readonly] >> >> The Bluetooth device address of the remote device. >> @@ -193,3 +222,30 @@ Properties string Address [readonly] >> >> Received Signal Strength Indicator of the remote >> device (inquiry or advertising). >> + >> + int16 ConnectionRSSI [readonly, optional] >> + >> + Received Signal Strength Indicator of connected remote >> + device. >> + >> + This property is present only if device is connected >> + and will be updated if at least one monitoring session >> + is active. >> + >> + Note that RSSI has different units for BR/EDR (dB) >> + and LE (dBm) as specified in BT Core ver. 4.1, Vol. 2, >> + Part E, Chapter 7.5.4 >> + >> + int16 ConnectionTXPower [readonly, optional] >> + >> + Transmit power level to connected remote device. >> + >> + This property is present only if device is connected >> + and will be updated if at least one monitoring session >> + is active. >> + >> + int16 ConnectionTXPowerMax [readonly, optional] >> + >> + Maximum transmit power level to connected remote device. >> + >> + This property is present only if device is connected. >> -- >> 1.9.3 > > IMO this API is too low level, if there is a reliable way to calculate > the link quality we should do it and probably expose as a single > property in percentage like we see in WiFi and other technologies, > trying to push this to the application to figure out is probably bad > idea since different applications may come up with different results. > > I would follow connman API design: > > uint8 Strength [readonly] > > Indicates the signal strength of the service. This > is a normalized value between 0 and 100... There's nothing to calculate here since RSSI and TX power are measured in different "directions". Actually you can calculate pathloss once you have RSSI from *local* side and TX power from *remote*. This is what PXP does using TPS, (but it only works over LE). By having these values exposed to application you can make proper PXP application and even do this on BR/EDR. BR, Andrzej -- 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
