Hi guys,
we need to read the RSSI of LE and basic rate connections to implement
the Proximity profile. RSSI included in the advertising packets can't
be used for Proximity, it requires an "active" connection.
Here are some suggestions:
1. Add a new command to mgmt interface to add a given address into a
RSSI "monitoring list".
When the connection is established the kernel will automatically
track the RSSI of the connection on regular intervals sending
HCI_Read_RSSI. Read RSSI value can be reported through a new event in
the management interface
Forgetting SMP, we can keep the hciops compatibility implementing the
same logic inside the hciops plugin.
2. Add a new command to mgmt interface to actively read the RSSI of a
given connection/address
Approach (1) seems to be more feasible: address multiple address
asynchronously. In my opinion, approach(2) will not be transparent
enough to our use cases.
Any other idea?
Cheers,
Claudio.
Hi Claudio,
> >> we need to read the RSSI of LE and basic rate connections to implement
> >> the Proximity profile. RSSI included in the advertising packets can't
> >> be used for Proximity, it requires an "active" connection.
> >>
> >> Here are some suggestions:
> >>
> >> 1. Add a new command to mgmt interface to add a given address into a
> >> RSSI "monitoring list".
> >> When the connection is established the kernel will automatically
> >> track the RSSI of the connection on regular intervals sending
> >> HCI_Read_RSSI. Read RSSI value can be reported through a new event in
> >> the management interface
> >
> > the HCI_Read_RSSI on basic rate is a useless command since it depends
> > highly on the power control. Especially since all Bluetooth chips try to
> > keep this one optimized.
> >
> > The RSSI from an active connection does not really give us much. And in
> > addition we have a lot of legacy BR chips just plain failing this
> > command and returning static data. How do you plan to address this?
>
> I don't expect to have an accurate measurement of the RSSI for basic
> rate, we are only trying to have the profile operational on both
> transports. If it is not feasible enable it for basic rate we can keep
> only Link Loss service running.
>
> For LE, I hope we get better results. The fact is: we need a way to
> get the RSSI value of an active connection on regular intervals.
> Any other suggestion to implement this service keeping transport abstraction?
the problem with RSSI is really that for basic rate, it is different
from the HCI_Read_RSSI command and Inquiry_Result_with_RSSI event. The
value from inquiry is most likely useful while the connected value is
rather pointless.
The HCI_Read_Link_Quality is way better, but the problem is that its
implementation is vendor specific :(
Regards
Marcel
Hi Marcel,
On Thu, Apr 21, 2011 at 12:36 AM, Marcel Holtmann <[email protected]> wro=
te:
> Hi Claudio,
>
>> we need to read the RSSI of LE and basic rate connections to implement
>> the Proximity profile. RSSI included in the advertising packets can't
>> be used for Proximity, it requires an "active" connection.
>>
>> Here are some suggestions:
>>
>> 1. Add a new command to mgmt interface to add a given address into a
>> RSSI "monitoring list".
>> =C2=A0 =C2=A0When the connection is established the kernel will automati=
cally
>> track the RSSI of the connection on regular intervals sending
>> HCI_Read_RSSI. Read RSSI value can be reported through a new event in
>> the management interface
>
> the HCI_Read_RSSI on basic rate is a useless command since it depends
> highly on the power control. Especially since all Bluetooth chips try to
> keep this one optimized.
>
> The RSSI from an active connection does not really give us much. And in
> addition we have a lot of legacy BR chips just plain failing this
> command and returning static data. How do you plan to address this?
>
> Regards
>
> Marcel
I don't expect to have an accurate measurement of the RSSI for basic
rate, we are only trying to have the profile operational on both
transports. If it is not feasible enable it for basic rate we can keep
only Link Loss service running.
For LE, I hope we get better results. The fact is: we need a way to
get the RSSI value of an active connection on regular intervals.
Any other suggestion to implement this service keeping transport abstractio=
n?
Regards,
Claudio
Hi Gustavo,
On Wed, Apr 20, 2011 at 10:18 PM, Gustavo F. Padovan
<[email protected]> wrote:
> Hi Claudio,
>
> * Claudio Takahasi <[email protected]> [2011-04-20 19:20:57 =
-0300]:
>
>> Hi guys,
>>
>> we need to read the RSSI of LE and basic rate connections to implement
>> the Proximity profile. RSSI included in the advertising packets can't
>> be used for Proximity, it requires an "active" connection.
>>
>> Here are some suggestions:
>>
>> 1. Add a new command to mgmt interface to add a given address into a
>> RSSI "monitoring list".
>> =C2=A0 =C2=A0When the connection is established the kernel will automati=
cally
>> track the RSSI of the connection on regular intervals sending
>> HCI_Read_RSSI. Read RSSI value can be reported through a new event in
>> the management interface
>>
>> Forgetting SMP, we can keep the hciops compatibility implementing the
>> same logic inside the hciops plugin.
>
> I'm against this in hciops. Let's add the new features only to mgmtopts, =
so we
> force people to use it and deprecate hciops.
We need to keep both "interfaces" working, the same way that we are
trying to do for discovery.
When hciops will be removed?
Anyway, if someone wants to use LE Security Manager/Pairing it is
necessary to use the Management Interface. If security is not
essential for LE, hciops can be used. For basic rate, it will be
functional on both "interfaces".
Claudio.
>
>>
>> 2. Add a new command to mgmt interface to actively read the RSSI of a
>> given connection/address
>
> If the user use this in the wrong way it will waste power. Let's
> do (1) and not give him this option to actively read RSSI.
>
> --
> Gustavo F. Padovan
> http://profusion.mobi
>
Hi Claudio,
> we need to read the RSSI of LE and basic rate connections to implement
> the Proximity profile. RSSI included in the advertising packets can't
> be used for Proximity, it requires an "active" connection.
>
> Here are some suggestions:
>
> 1. Add a new command to mgmt interface to add a given address into a
> RSSI "monitoring list".
> When the connection is established the kernel will automatically
> track the RSSI of the connection on regular intervals sending
> HCI_Read_RSSI. Read RSSI value can be reported through a new event in
> the management interface
the HCI_Read_RSSI on basic rate is a useless command since it depends
highly on the power control. Especially since all Bluetooth chips try to
keep this one optimized.
The RSSI from an active connection does not really give us much. And in
addition we have a lot of legacy BR chips just plain failing this
command and returning static data. How do you plan to address this?
Regards
Marcel
Hi Claudio,
* Claudio Takahasi <[email protected]> [2011-04-20 19:20:57 -0300]:
> Hi guys,
>
> we need to read the RSSI of LE and basic rate connections to implement
> the Proximity profile. RSSI included in the advertising packets can't
> be used for Proximity, it requires an "active" connection.
>
> Here are some suggestions:
>
> 1. Add a new command to mgmt interface to add a given address into a
> RSSI "monitoring list".
> When the connection is established the kernel will automatically
> track the RSSI of the connection on regular intervals sending
> HCI_Read_RSSI. Read RSSI value can be reported through a new event in
> the management interface
>
> Forgetting SMP, we can keep the hciops compatibility implementing the
> same logic inside the hciops plugin.
I'm against this in hciops. Let's add the new features only to mgmtopts, so we
force people to use it and deprecate hciops.
>
> 2. Add a new command to mgmt interface to actively read the RSSI of a
> given connection/address
If the user use this in the wrong way it will waste power. Let's
do (1) and not give him this option to actively read RSSI.
--
Gustavo F. Padovan
http://profusion.mobi
SGkgQ2xhdWRpbywgR3VzdGF2bywNCg0KPj4+IDEuIEFkZCBhIG5ldyBjb21tYW5kIHRvDQo+bWdt
dCBpbnRlcmZhY2UgdG8gYWRkIGENCj5naXZlbiBhZGRyZXNzIGludG8gYQ0KPj4+IFJTU0kgIm1v
bml0b3JpbmcgbGlzdCIuDQo+Pj4gwqAgwqBXaGVuIHRoZSBjb25uZWN0aW9uIGlzDQo+ZXN0YWJs
aXNoZWQgdGhlIGtlcm5lbCB3aWxsDQo+YXV0b21hdGljYWxseQ0KPj4+IHRyYWNrIHRoZSBSU1NJ
IG9mIHRoZQ0KPmNvbm5lY3Rpb24gb24gcmVndWxhcg0KPmludGVydmFscyBzZW5kaW5nDQo+Pj4g
SENJX1JlYWRfUlNTSS4gUmVhZCBSU1NJDQo+dmFsdWUgY2FuIGJlIHJlcG9ydGVkDQo+dGhyb3Vn
aCBhIG5ldyBldmVudCBpbg0KPj4+IHRoZSBtYW5hZ2VtZW50IGludGVyZmFjZQ0KPj4+DQo+Pj4g
Rm9yZ2V0dGluZyBTTVAsIHdlIGNhbg0KPmtlZXAgdGhlIGhjaW9wcw0KPmNvbXBhdGliaWxpdHkg
aW1wbGVtZW50aW5nDQo+dGhlDQo+Pj4gc2FtZSBsb2dpYyBpbnNpZGUgdGhlDQo+aGNpb3BzIHBs
dWdpbi4NCj4+DQo+PiBJJ20gYWdhaW5zdCB0aGlzIGluDQo+aGNpb3BzLiBMZXQncyBhZGQgdGhl
IG5ldw0KPmZlYXR1cmVzIG9ubHkgdG8gbWdtdG9wdHMsDQo+c28gd2UNCj4+IGZvcmNlIHBlb3Bs
ZSB0byB1c2UgaXQgYW5kDQo+ZGVwcmVjYXRlIGhjaW9wcy4NCj4NCj5XZSBuZWVkIHRvIGtlZXAg
Ym90aA0KPiJpbnRlcmZhY2VzIiB3b3JraW5nLCB0aGUNCj5zYW1lIHdheSB0aGF0IHdlIGFyZQ0K
PnRyeWluZyB0byBkbyBmb3IgZGlzY292ZXJ5Lg0KPldoZW4gaGNpb3BzIHdpbGwgYmUgcmVtb3Zl
ZD8NCg0KW0FydW5dIFNpbmNlIG1hbnkgTEUgcHJvZmlsZXMgcmVxdWlyZSBTTVAgcHJvY2VkdXJl
cywgaXQgd291bGQgYmUgaW1wcnVkZW50IHRvIGtlZXAgInJzc2kiIHN1cHBvcnQgb24gYm90aCBp
bnRlcmZhY2VzPyBVbmxlc3Mgb2YgY291cnNlIHdlIGFyZSBsb29raW5nIGF0IHByb2ZpbGVzIHRo
YXQgd291bGQgbmV2ZXIgbmVlZCBhbnkgTEUgc2VjdXJpdHkgaW1wbGVtZW50YXRpb24gd2hpY2gg
d291bGQgbGVhZCBoYWxmIG9mIHRoZSBwcm9maWxlIGltcGxlbWVudG9ycyB1c2luZyBoY2lvcHMg
YW5kIHJlbWFpbmluZyBtZ210LCBtYWtpbmcgcGhhc2luZyBvdXQgb2YgaGNpb3BzIGFsbCB0aGUg
bW9yZSBkaWZmaWN1bHQuDQpMRSBhbmQgcHJvZmlsZSBzdXBwb3J0IHNob3VsZCBmaW5hbGx5IGN1
bGltaW5hdGUgdG8gbWdtdCBpL2YgZWxzZSB3ZSB3b3VsZCBjbHV0dGVyIHByb2ZpbGUgc3VwcG9y
dCBhbGwgb3ZlciB0aGUgdXNlciBzcGFjZS4gaGNpb3BzIHNob3VsZCBldmVudHVhbGx5IHNsaXAg
dG8gb2JsaXZpb24gc29tZWRheS0NCg0KPj4+IDIuIEFkZCBhIG5ldyBjb21tYW5kIHRvDQo+bWdt
dCBpbnRlcmZhY2UgdG8gYWN0aXZlbHkNCj5yZWFkIHRoZSBSU1NJIG9mIGENCj4+PiBnaXZlbiBj
b25uZWN0aW9uL2FkZHJlc3MNCj4+DQo+PiBJZiB0aGUgdXNlciB1c2UgdGhpcyBpbg0KPnRoZSB3
cm9uZyB3YXkgaXQgd2lsbCB3YXN0ZQ0KPnBvd2VyLiBMZXQncw0KPj4gZG8gKDEpIGFuZCBub3Qg
Z2l2ZSBoaW0NCj50aGlzIG9wdGlvbiB0byBhY3RpdmVseSByZWFkDQo+UlNTSS4NCj4+DQpbQXJ1
bl0gU2luY2UgdGhlIG9udXMgb2YgY2FsY3VsYXRpbmcgcGF0aC1sb3NzIGlzIGVudGlyZWx5IG9u
IHRoZSBwcm94aW1pdHkgbW9uaXRvciBha2EgYXBwbGljYXRpb24sIGl0IHNob3VsZCBiZSByZWxp
ZWQgYXMgc2FuZSBlbm91Z2ggdG8ga25vdyBob3cgdG8gdXNlIHRoaXMgY29tbWFuZC4gTW9yZW92
ZXIsIGlmIHdlIGltcGxlbWVudCAoMSkgdGhlbiB3ZSBtYXkgaGF2ZSB0byBnaXZlIGFuIG9wdGlv
biB0byB1c2VyL3Byb2ZpbGUgbW9uaXRvciB0byBhbHNvIGNvbmZpZnVyZSB0aGUgcnNzaSBtb25p
dG9yaW5nIGludGVydmFscyB3aGljaCB3b3VsZCBtYWtlIHRoaXMgc3R1ZmYgb3Zlcmx5IGNvbXBs
aWNhdGVkLiAoMikgc291bmRzIHNhZmUuDQoNCg0KVGhhbmtzLA0KQXJ1bg0K