Hi Claudio, Gustavo,
>>> 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.
>
>We need to keep both
>"interfaces" working, the
>same way that we are
>trying to do for discovery.
>When hciops will be removed?
[Arun] Since many LE profiles require SMP procedures, it would be imprudent to keep "rssi" support on both interfaces? Unless of course we are looking at profiles that would never need any LE security implementation which would lead half of the profile implementors using hciops and remaining mgmt, making phasing out of hciops all the more difficult.
LE and profile support should finally culiminate to mgmt i/f else we would clutter profile support all over the user space. hciops should eventually slip to oblivion someday-
>>> 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.
>>
[Arun] Since the onus of calculating path-loss is entirely on the proximity monitor aka application, it should be relied as sane enough to know how to use this command. Moreover, if we implement (1) then we may have to give an option to user/profile monitor to also confifure the rssi monitoring intervals which would make this stuff overly complicated. (2) sounds safe.
Thanks,
Arun
ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±ý¶ â^n‡r¡öë¨è&£ûz¹Þúzf£¢·hšˆ§~††Ûÿÿïÿ‘ê_èæ+v‰¨þ)ßø
