RSSI property is inquiry RSSI and this should be stated here especially
that we plan to add connection RSSI property soon.
---
doc/device-api.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/device-api.txt b/doc/device-api.txt
index 2d9fa3c..7a301d3 100644
--- a/doc/device-api.txt
+++ b/doc/device-api.txt
@@ -191,5 +191,5 @@ Properties string Address [readonly]
int16 RSSI [readonly, optional]
- Received Signal Strength Indicator of the remote
+ Received Signal Strength Indicator (inquiry) of the remote
device.
--
1.8.4
Hi Scott,
On Wed, May 7, 2014 at 8:15 PM, Scott James Remnant <[email protected]> wrote:
> On Wed, May 7, 2014 at 7:17 AM, Lukasz Rymanowski
> <[email protected]> wrote:
>> This patch introduce device method to start and stop connection monitor
>> and two new device properties ConnectionRSSI and ConnectionTXPower which
>> are tracked when monitor is active
>
> Does a polling API like this make more sense than just an "Update
> Connection Properties" method call?
>
IMHO DBus is to heavy for polling methods.
I planned to have interval value for this Monitor in config file so
user can adjust it depends on needs.
> Why make new properties? The existing RSSI property could be re-used
> without confusion, likewise the TXPower property could be called just
> that - which would then give a place to fill in the TX Power if
> present in AD as well.
>
TXPower for AD is different than TXPower on the connection. Same thing
with RSSI - so I would keep separate properties for that.
> Scott
> --
> Scott James Remnant | Chrome OS Systems | [email protected] | Google
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
BR
Lukasz
Hi Scott,
On Wed, May 7, 2014 at 10:30 PM, Marcel Holtmann <[email protected]> wrote:
> 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.
>
There is fancy table of supported states in BT core ver 4.1, Vol 2
Part E, Chapter 7.8.27. You can indeed find there a combination where
device is connected and still can advertise.
>> 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
>
BR
Lukasz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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
On Wed, May 7, 2014 at 12:06 PM, Marcel Holtmann <[email protected]> wrot=
e:
>>> 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. On=
e is essentially tight to the Inquiry TX power and the other to the TX powe=
r of the connection. Results will be different. This has always been the pr=
oblem with Bluetooth=E2=80=99s RSSI. Mapping the RSSI you got Extended Inqu=
iry Result to Read RSSI is not possible.
>
LE Devices aren't ever in a situation where they are Advertising
during a Connection though, right?
So either the RSSI + TX Power are relevant to Inquiry (when Connected
=3D false) or relevant to Connection (when Connected =3D true)
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.
Scott
--=20
Scott James Remnant | Chrome OS Systems | [email protected] | Google
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.
Regards
Marcel
On Wed, May 7, 2014 at 7:17 AM, Lukasz Rymanowski
<[email protected]> wrote:
> This patch introduce device method to start and stop connection monitor
> and two new device properties ConnectionRSSI and ConnectionTXPower which
> are tracked when monitor is active
Does a polling API like this make more sense than just an "Update
Connection Properties" method call?
Why make new properties? The existing RSSI property could be re-used
without confusion, likewise the TXPower property could be called just
that - which would then give a place to fill in the TX Power if
present in AD as well.
Scott
--
Scott James Remnant | Chrome OS Systems | [email protected] | Google
On Wed, May 7, 2014 at 7:17 AM, Lukasz Rymanowski
<[email protected]> wrote:
> 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.
Scott
--
Scott James Remnant | Chrome OS Systems | [email protected] | Google
This patch introduce device method to start and stop connection monitor
and two new device properties ConnectionRSSI and ConnectionTXPower which
are tracked when monitor is active
---
doc/device-api.txt | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/doc/device-api.txt b/doc/device-api.txt
index 7a301d3..9e7296e 100644
--- a/doc/device-api.txt
+++ b/doc/device-api.txt
@@ -100,6 +100,34 @@ Methods void Connect()
Possible errors: org.bluez.Error.DoesNotExist
org.bluez.Error.Failed
+
+ void StartConnectionMonitor()
+
+ This method starts connection monitor session.
+
+ This method enables connection information tracking.
+ E.g. ConnectionRSSI, ConnectionTXPower.
+
+ Use StopConnectionMonitor to release session.
+
+ Possible errors: org.bluez.Error.NotReady
+ org.bluez.Error.Failed
+ org.bluez.Error.NotConnected
+ org.bluez.Error.NotSupported
+
+ 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
+ org.bluez.Error.NotReady
+ org.bluez.Error.NotAuthorized
+
Properties string Address [readonly]
The Bluetooth device address of the remote device.
@@ -193,3 +221,23 @@ Properties string Address [readonly]
Received Signal Strength Indicator (inquiry) of the remote
device.
+
+ int16 ConnectionRSSI [readonly, optional]
+
+ Received Signal Strength Indicator of connected remote
+ device.
+
+ This property is present only if at least one connection
+ monitor 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 the remote device on the existing
+ connection
+
+ This property is present only if at least one connection
+ monitor session is active.
--
1.8.4