Covers the Proximity Reporter for Link Loss, Tx Power and Immediate
Alert services. This first proposal considers that the connections
will be managed by the bluetoothd core based on the registered
connection callbacks.
Only one instance of Immediate Alert service is allowed, "Alert Level"
characteristic of this service is used by Find Me and Path Loss. Note
that "Alert Level" for Path Loss is a LOCAL property written in the
Immediate Alert service when the threshold is reached. For Find Me
the user/application needs to actively enable the alert in the Immediate
Alert service. Link Loss has it's own instance of Alert Level
characteristic.
---
doc/proximity-api.txt | 75 +++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 75 insertions(+), 0 deletions(-)
create mode 100644 doc/proximity-api.txt
diff --git a/doc/proximity-api.txt b/doc/proximity-api.txt
new file mode 100644
index 0000000..d9ed71d
--- /dev/null
+++ b/doc/proximity-api.txt
@@ -0,0 +1,75 @@
+BlueZ D-Bus Proximity API description
+***********************************
+
+Copyright (C) 2011 Claudio Takahasi <[email protected]>
+
+
+Proximity hierarchy
+=================
+
+Service org.bluez
+Interface org.bluez.ProximityMonitor
+Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
+
+Methods dict GetProperties()
+
+ Returns all properties for the interface. See the
+ properties section for available properties.
+
+ void SetProperty(string name, variant value)
+
+ Changes the value of the specified property. Only
+ properties that are listed a read-write are changeable.
+ On success this will emit a PropertyChanged signal.
+
+ Possible Errors: org.bluez.Error.InvalidArguments
+
+Signals PropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+Properties
+ uint8 PathLoss[readonly]
+
+ If Tx Power Service is available, this property value
+ will be reported on regular intervals when the peer is
+ connected. Range: 0 - 100. The number is a relative
+ value to represent inaccurately the signal strength,
+ where 0 represents out of range and 100 close to the
+ reporter.
+
+ string Threshold [readwrite]
+
+ Persistent property. Trigger for immediate alert.
+ Values: "low", "medium", "high". Enabled only if Tx
+ Power and Immediate Alert services are available in
+ the reporter. Controls when the immediate alert is
+ triggered in the reporter.
+
+ boolean ThresholdAlert[readonly]
+
+ Alert indicating that threshold has been reached or the
+ path loss returned to a value below the threshold. It is
+ up to the implementation catch this property value and
+ emit a sound in the proximity monitor.
+
+ string LinkLossAlertLevel [readwrite]
+
+ Persistent property. Sets the alert level in the
+ proximity reporter for link loss scenario. Values:
+ "none", "mild", "high".
+
+ string PathLossAlertLevel [readwrite]
+
+ Persistent property. Alert level for path loss scenario.
+ It's a local property value written in the Alert Level of
+ the Immediate Alert service when the threshold alert is
+ triggered. Values: "none", "mild", "high".
+
+ string FindMeAlertLevel [readwrite]
+
+ Alert level to be written in the Find Me target.
+ Values: "none", "mild", "high". Default value is
+ "none". Applications should disable the alert setting
+ the value to "none".
--
1.7.6
Hi,
On Thu, Jun 30, 2011 at 4:16 PM, Bastien Nocera <[email protected]> wrote:
> On Thu, 2011-06-30 at 15:24 -0300, Claudio Takahasi wrote:
>> Covers the Proximity Reporter for Link Loss, Tx Power and Immediate
>> Alert services. This first proposal considers that the connections
>> will be managed by the bluetoothd core based on the registered
>> connection callbacks.
>
> Any examples of possible uses, or hardware implementing those?
It is a LE-only GATT profile. So any Bluetooth 4.0 certified hardware
should be able to run the Proximity and Find Me profiles. But I'm not
aware of any Bluetooth 4.0 hardware selling for general consumers (I
heard of a notebook with it sometime ago on this list).
For use cases, you should really take a look at the Bluetooth Low
Energy concept as a whole. See bluetooth.org for details.
> Is this
> good enough to implement both sides of the profile, or just one side of
> it?
The API is for the Proximity Monitor role. The Proximity Reporter role
will usually run on LE single mode (very low power, coin cell battery)
devices, but we will have a basic Proximity Reporter for testing
purposes as well, which could be later expanded to a full featured
Reporter.
> Is this something that could require UI being written?
For sure. This is just the D-Bus API, some graphical/console
application must be written to use it. We will provide test scripts
under the test/ directory.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
On Thu, 2011-06-30 at 15:24 -0300, Claudio Takahasi wrote:
> Covers the Proximity Reporter for Link Loss, Tx Power and Immediate
> Alert services. This first proposal considers that the connections
> will be managed by the bluetoothd core based on the registered
> connection callbacks.
Any examples of possible uses, or hardware implementing those? Is this
good enough to implement both sides of the profile, or just one side of
it?
Is this something that could require UI being written?
> Only one instance of Immediate Alert service is allowed, "Alert Level"
> characteristic of this service is used by Find Me and Path Loss. Note
> that "Alert Level" for Path Loss is a LOCAL property written in the
> Immediate Alert service when the threshold is reached. For Find Me
> the user/application needs to actively enable the alert in the Immediate
> Alert service. Link Loss has it's own instance of Alert Level
its.
> characteristic.
Cheers
Hi,
On Thu, Jun 30, 2011 at 2:24 PM, Claudio Takahasi
<[email protected]> wrote:
> Covers the Proximity Reporter for Link Loss, Tx Power and Immediate
> Alert services. This first proposal considers that the connections
> will be managed by the bluetoothd core based on the registered
> connection callbacks.
BTW, the Proximity & Find Me profiles and related services have just
been made available on:
https://www.bluetooth.org/Technical/Specifications/adopted.htm \o/
This RFC covers both Proximity and Find Me (find me share the same
immediate alert service from Proximity).
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hi Claudio,
On Wed, Jul 06, 2011, Claudio Takahasi wrote:
> Covers the Proximity Monitor for Link Loss, Tx Power and Immediate
> Alert services. This first proposal considers that the connections
> will be managed by the bluetoothd core based on the registered
> connection callbacks.
>
> Only one instance of Immediate Alert service is allowed, "Alert Level"
> characteristic of this service is used by Find Me and Path Loss. Note
> that "Alert Level" for Path Loss is a LOCAL property written in the
> Immediate Alert service when the threshold is reached. For Find Me
> the user/application needs to actively enable the alert in the Immediate
> Alert service. Link Loss has it's own instance of Alert Level
> characteristic.
> ---
> doc/proximity-api.txt | 78 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 78 insertions(+), 0 deletions(-)
> create mode 100644 doc/proximity-api.txt
Pushed upstream. Thanks.
Johan
Covers the Proximity Monitor for Link Loss, Tx Power and Immediate
Alert services. This first proposal considers that the connections
will be managed by the bluetoothd core based on the registered
connection callbacks.
Only one instance of Immediate Alert service is allowed, "Alert Level"
characteristic of this service is used by Find Me and Path Loss. Note
that "Alert Level" for Path Loss is a LOCAL property written in the
Immediate Alert service when the threshold is reached. For Find Me
the user/application needs to actively enable the alert in the Immediate
Alert service. Link Loss has it's own instance of Alert Level
characteristic.
---
doc/proximity-api.txt | 78 +++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 78 insertions(+), 0 deletions(-)
create mode 100644 doc/proximity-api.txt
diff --git a/doc/proximity-api.txt b/doc/proximity-api.txt
new file mode 100644
index 0000000..ed78fb5
--- /dev/null
+++ b/doc/proximity-api.txt
@@ -0,0 +1,78 @@
+BlueZ D-Bus Proximity API description
+***********************************
+
+Copyright (C) 2011 Claudio Takahasi <[email protected]>
+
+
+Proximity hierarchy
+=================
+
+Service org.bluez
+Interface org.bluez.ProximityMonitor
+Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
+
+Methods dict GetProperties()
+
+ Returns all properties for the interface. See the
+ properties section for available properties.
+
+ void SetProperty(string name, variant value)
+
+ Changes the value of the specified property. Only
+ properties that are listed a read-write are changeable.
+ On success this will emit a PropertyChanged signal.
+
+ Possible Errors: org.bluez.Error.InvalidArguments
+
+Signals PropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of a given
+ property.
+
+Properties
+ uint8 PathLoss[readonly]
+
+ If Tx Power Service is available, this property value
+ will be reported on regular intervals when the peer is
+ connected. Range: 0 - 100. The number is a relative
+ value to represent inaccurately the signal strength,
+ where 0 represents out of range and 100 close to the
+ reporter.
+
+ string Threshold [readwrite]
+
+ Persistent property. Trigger for immediate alert.
+ Values: "low", "medium", "high". Enabled only if Tx
+ Power and Immediate Alert services are available in
+ the reporter. Controls when the immediate alert is
+ triggered in the reporter.
+
+ boolean ThresholdAlert[readonly]
+
+ Alert indicating that threshold has been reached or the
+ path loss returned to a value below the threshold. It is
+ up to the implementation catch this property value and
+ emit a sound in the proximity monitor.
+
+ string LinkLossAlertLevel [readwrite]
+
+ Persistent property. Sets the alert level in the
+ proximity reporter for link loss scenario. Values:
+ "none", "mild", "high".
+
+ string PathLossAlertLevel [readwrite]
+
+ Persistent property. Alert level for path loss scenario.
+ It's a LOCAL property value written in the Alert Level of
+ the Immediate Alert service when the threshold alert is
+ triggered. Values: "none", "mild", "high".
+
+ string FindMeAlertLevel [readwrite]
+
+ Alert level to be written in the Find Me Target.
+ Values: "none", "mild", "high". Default value is
+ "none". Applications can disable the alert setting
+ the value to "none". If the "Target" is not found,
+ "none" will be emitted after the configured timeout.
+ When changing the level, signal is the confirmation
+ that the value was written in the remote.
--
1.7.6
Hi Arun,
<snip>
>
> Also how about setting profile specific LSTO? Proximity specs recommends this value to be 6X connection interval but I guess we may give the user/application some flexibility to play around on this? Same may be the case for connection interval, scan interval, latency values etc...I believe these values can be pretty much user/platform specific and user should have control over these ...
We will investigate it later. The first step is to push the ATT
connection management and Proximity patches upstream.
Briefly: the idea is to create "profiles" related to connection speed
and power consumption.
Regards,
Claudio.
>
> Thanks,
> Arun
>
SGkgQ2xhdWRpbywgQW5kZXJzb24sDQoNCj4+IFNvcnJ5LCBhY3R1YWxseSBpdCB3YXMgYSBtaXN0
YWtlIGZyb20gQ2xhdWRpbyAod2hpY2ggSSBoYWRuJ3Qgbm90aWNlZA0KPj4gd2hlbiBJIG1hZGUg
bXkgY29tbWVudHMpIDopIFRoaXMgaXMgYSAqTW9uaXRvciogQVBJIGFzIEkgbWVudGlvbmVkLg0K
Pj4gVGhlIGRvYyBpdHNlbGYgbWVudGlvbnM6DQo+Pg0KPj4gK0ludGVyZmFjZSDCoCDCoCDCoG9y
Zy5ibHVlei5Qcm94aW1pdHlNb25pdG9yDQo+Pg0KPj4gQW5kIHlvdSBhcmUgY29ycmVjdCwgb3Vy
IGN1cnJlbnQgZm9jdXMgaXMgb24gUHJveGltaXR5IE1vbml0b3IgJiBGaW5kDQo+PiBNZSBMb2Nh
dG9yIChBS0EgImNsaWVudCIpIHJvbGVzLiBUaGUgInNlcnZlciIgcm9sZXMgd2lsbCBiZSBpbml0
aWFsbHkNCj4+IGltcGxlbWVudGVkIGZvciB0ZXN0aW5nIHB1cnBvc2VzLg0KPj4NCj4NCj5JdCB3
aWxsIGJlIGZpeGVkLiBTb3JyeSENClRoYW5rcyBmb3IgY2xhcmlmeWluZy4NCg0KPlllc3RlcmRh
eSBkaXNjdXNzaW5nIGludGVybmFsbHkgaGVyZSB3ZSBmb3VuZCBzb21lIGlzc3VlczoNCj4xLiBT
ZXRQcm9wZXJ0eSgiRmluZE1lQWxlcnRMZXZlbCIsIGxldmVsKTogbmVlZHMgYSB0aW1lb3V0LiBM
RSBDcmVhdGUNCj5Db25uZWN0aW9uIENvbW1hbmQgZG9lc24ndCBoYXZlIGEgdGltZW91dCwgYnV0
IHRoZSBMMkNBUCBzb2NrZXQofjQwcykNCj5hbmQgRC1CdXMgbWVzc2FnZSh+MjBzKSBoYXZlLg0K
PjIuIFNldFByb3BlcnR5KCJGaW5kTWVBbGVydExldmVsIiwgbGV2ZWwpOiBuZWVkcyBhIGNhbmNl
bCBtZWNoYW5pc20/DQo+TWF5YmUgc2V0dGluZyBpdCB0byAibm9uZSIgaXMgZW5vdWdoLg0KPg0K
PkxpbmtMb3NzQWxlcnRMZXZlbCBhbmQgUGF0aExvc3NBbGVydExldmVsIGFyZSBvazogdGltZW91
dCBub3QNCj5uZWNlc3NhcnkuIFRoZSBsYXN0IG9uZSBpcyBMT0NBTCBhbmQgdXNlZCBvbmx5IHdo
ZW4gdGhlIHRocmVzaG9sZCBpcw0KPnJlYWNoZWQuIA0KDQpIb3cgYWJvdXQgaWYgdGhlcmUgaXMg
YSBjb25uZWN0aW9uIGxvc3MgYmVmb3JlIE1vbml0b3IgY291bGQgd3JpdGUgdGhlIEFsZXJ0IExl
dmVsIGludG8gUmVwb3J0ZXI/IEluIHRoaXMgY2FzZSBNb25pdG9yIHdvdWxkIHRyeSB0byByZWNv
bm5lY3QgYmFzZWQgb24gQXV0byBjb25uZWN0aW9uIHByb2NlZHVyZXMgYnV0IHdvbid0IFBhdGhM
b3NzQWxlcnRMZXZlbCBuZWVkIGEgdGltZW91dCBoZXJlIC4uLiBbd2lsZCBzcGVjdWxhdGlvbnMg
Oi0pXQ0KDQoNCkFsc28gaG93IGFib3V0IHNldHRpbmcgcHJvZmlsZSBzcGVjaWZpYyBMU1RPPyBQ
cm94aW1pdHkgc3BlY3MgcmVjb21tZW5kcyB0aGlzIHZhbHVlIHRvIGJlIDZYIGNvbm5lY3Rpb24g
aW50ZXJ2YWwgYnV0IEkgZ3Vlc3Mgd2UgbWF5IGdpdmUgdGhlIHVzZXIvYXBwbGljYXRpb24gc29t
ZSBmbGV4aWJpbGl0eSB0byBwbGF5IGFyb3VuZCBvbiB0aGlzPyBTYW1lIG1heSBiZSB0aGUgY2Fz
ZSBmb3IgY29ubmVjdGlvbiBpbnRlcnZhbCwgc2NhbiBpbnRlcnZhbCwgbGF0ZW5jeSB2YWx1ZXMg
ZXRjLi4uSSBiZWxpZXZlIHRoZXNlIHZhbHVlcyBjYW4gYmUgcHJldHR5IG11Y2ggdXNlci9wbGF0
Zm9ybSBzcGVjaWZpYyBhbmQgdXNlciBzaG91bGQgaGF2ZSBjb250cm9sIG92ZXIgdGhlc2UgLi4u
DQoNClRoYW5rcywNCkFydW4NCg==
Hi Mike,
On Fri, Jul 1, 2011 at 1:00 PM, mike tsai <[email protected]> wrote:
> I am a bit curious about the definition of PathLoss and Threshold
> property definition. The PathLoss has a range of 0 - 100, while the
> Threshold has low, medium and high setting. How do you plan to map
> PathLoss reading with Threshold setting?
The idea is to "low" "medium" and "high" in Threshold map to some
(hard-coded or calculated) percentage between 0% and 100%. E.g.:
low: 10%
medium: 60%
high: 90%
But of course we are open to suggestions :). It is very possible the
these values will not be hard-coded, because they will very much
depend on the quality of the radio hardware (I suppose). We will
probably need to perform some "calibration" during bonding.
The PathLoss is 0-100 range is just a linear normalization from actual
Path Loss calculation values, where 100 is mapped to the maximum
(nearest) theoretical value and 0 is the minimum (most far) value.
This can help applications which want to show the value as a
measurement of "link quality" of some sort.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hi,
On Fri, Jul 1, 2011 at 7:23 AM, Claudio Takahasi
<[email protected]> wrote:
> Hi Anderson, Arun,
>
> On Fri, Jul 1, 2011 at 7:50 AM, Anderson Lizardo
> <[email protected]> wrote:
>> Hi Arun,
>>
>> On Fri, Jul 1, 2011 at 3:22 AM, Arun Kumar SINGH
>> <[email protected]> wrote:
>>> Hello Anderson,
>>>
>>>>>> Covers the Proximity Reporter for Link Loss, Tx Power and Immediate
>>>
>>> [clip ...]
>>>
>>>>> Is this
>>>>> good enough to implement both sides of the profile, or just one side of
>>>>> it?
>>>>
>>>>The API is for the Proximity Monitor role.
>>>
>>> Sounds bit confusing.. Ain't these API's being proposed for Proximity Reporter Role which is what Claudio mentioned in the original RFC? Which bring me to the next question- since a GATT client makes more sense for a dual mode stack such as Bluez, shouldn't we focus first on Monitor kind of roles for LE profiles and later consider Reporter type roles for testing only?
>>
>> Sorry, actually it was a mistake from Claudio (which I hadn't noticed
>> when I made my comments) :) This is a *Monitor* API as I mentioned.
>> The doc itself mentions:
>>
>> +Interface ? ? ?org.bluez.ProximityMonitor
>>
>> And you are correct, our current focus is on Proximity Monitor & Find
>> Me Locator (AKA "client") roles. The "server" roles will be initially
>> implemented for testing purposes.
>>
>
> It will be fixed. Sorry!
>
> Yesterday discussing internally here we found some issues:
> 1. SetProperty("FindMeAlertLevel", level): needs a timeout. LE Create
> Connection Command doesn't have a timeout, but the L2CAP socket(~40s)
> and D-Bus message(~20s) have.
> 2. SetProperty("FindMeAlertLevel", level): needs a cancel mechanism?
> Maybe setting it to "none" is enough.
>
> LinkLossAlertLevel and PathLossAlertLevel are ok: timeout not
> necessary. The last one is LOCAL and used only when the threshold is
> reached. LinkLossAlertLevel can be persistent and written when the
> connection is established.
>
I am a bit curious about the definition of PathLoss and Threshold
property definition. The PathLoss has a range of 0 - 100, while the
Threshold has low, medium and high setting. How do you plan to map
PathLoss reading with Threshold setting?
Regards,
Mike
> Regards,
> Claudio
> --
> 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 Anderson, Arun,
On Fri, Jul 1, 2011 at 7:50 AM, Anderson Lizardo
<[email protected]> wrote:
> Hi Arun,
>
> On Fri, Jul 1, 2011 at 3:22 AM, Arun Kumar SINGH
> <[email protected]> wrote:
>> Hello Anderson,
>>
>>>>> Covers the Proximity Reporter for Link Loss, Tx Power and Immediate
>>
>> [clip ...]
>>
>>>> Is this
>>>> good enough to implement both sides of the profile, or just one side of
>>>> it?
>>>
>>>The API is for the Proximity Monitor role.
>>
>> Sounds bit confusing.. Ain't these API's being proposed for Proximity Reporter Role which is what Claudio mentioned in the original RFC? Which bring me to the next question- since a GATT client makes more sense for a dual mode stack such as Bluez, shouldn't we focus first on Monitor kind of roles for LE profiles and later consider Reporter type roles for testing only?
>
> Sorry, actually it was a mistake from Claudio (which I hadn't noticed
> when I made my comments) :) This is a *Monitor* API as I mentioned.
> The doc itself mentions:
>
> +Interface org.bluez.ProximityMonitor
>
> And you are correct, our current focus is on Proximity Monitor & Find
> Me Locator (AKA "client") roles. The "server" roles will be initially
> implemented for testing purposes.
>
It will be fixed. Sorry!
Yesterday discussing internally here we found some issues:
1. SetProperty("FindMeAlertLevel", level): needs a timeout. LE Create
Connection Command doesn't have a timeout, but the L2CAP socket(~40s)
and D-Bus message(~20s) have.
2. SetProperty("FindMeAlertLevel", level): needs a cancel mechanism?
Maybe setting it to "none" is enough.
LinkLossAlertLevel and PathLossAlertLevel are ok: timeout not
necessary. The last one is LOCAL and used only when the threshold is
reached. LinkLossAlertLevel can be persistent and written when the
connection is established.
Regards,
Claudio
Hi Arun,
On Fri, Jul 1, 2011 at 3:22 AM, Arun Kumar SINGH
<[email protected]> wrote:
> Hello Anderson,
>
>>>> Covers the Proximity Reporter for Link Loss, Tx Power and Immediate
>
> [clip ...]
>
>>> Is this
>>> good enough to implement both sides of the profile, or just one side of
>>> it?
>>
>>The API is for the Proximity Monitor role.
>
> Sounds bit confusing.. Ain't these API's being proposed for Proximity Reporter Role which is what Claudio mentioned in the original RFC? Which bring me to the next question- since a GATT client makes more sense for a dual mode stack such as Bluez, shouldn't we focus first on Monitor kind of roles for LE profiles and later consider Reporter type roles for testing only?
Sorry, actually it was a mistake from Claudio (which I hadn't noticed
when I made my comments) :) This is a *Monitor* API as I mentioned.
The doc itself mentions:
+Interface org.bluez.ProximityMonitor
And you are correct, our current focus is on Proximity Monitor & Find
Me Locator (AKA "client") roles. The "server" roles will be initially
implemented for testing purposes.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
Hello Anderson,
>>> Covers the Proximity Reporter for Link Loss, Tx Power and Immediate
[clip ...]
>> Is this
>> good enough to implement both sides of the profile, or just one side of
>> it?
>
>The API is for the Proximity Monitor role.
Sounds bit confusing.. Ain't these API's being proposed for Proximity Reporter Role which is what Claudio mentioned in the original RFC? Which bring me to the next question- since a GATT client makes more sense for a dual mode stack such as Bluez, shouldn't we focus first on Monitor kind of roles for LE profiles and later consider Reporter type roles for testing only?
>The Proximity Reporter role
>will usually run on LE single mode (very low power, coin cell battery)
>devices, but we will have a basic Proximity Reporter for testing
>purposes as well, which could be later expanded to a full featured
>Reporter.
>
>> Is this something that could require UI being written?
>
>For sure. This is just the D-Bus API, some graphical/console
>application must be written to use it. We will provide test scripts
>under the test/ directory.
Thanks,
Arun