Hi Claudio, Anderson,
> Please sync with Anderson Briglia, he already sent a RFC to the ML
> some months ago.
> In the Bluetooth Summit(Prague), we decided to not proceed with RSSI
> monitor emulation in the kernel until we have a clear idea or spec
> defining how the controllers will implement RSSI monitoring.
Could you please provide some details about what was discussed in the summit.
> The ideia was to provide transparency, the userspace doesn't need to
> know if RSSI monitoring is emulated or not.
As per my understanding the BT spec (4.0, Volume 2, Part E, Section
7.5.4) the HCI_Read_RSSI command can be used to retrieve the RSSI from
the controller. In our case, I have tested it against ST-Ericsson BT
controller and it works in our case. Are you suggesting that until we
know how the RSSI is determined in controller, we should not implement
this functionality in kernel ? I ask this because in Proximity Spec,
it is mentioned that the monitor should use appropriate calculations
to prevent false alerts on reporter, so if we leave this to layer
above BlueZ to do this part, then we are pretty independent with the
approach of implementation of Path Loss RSSI Monitoring in BlueZ and
Kernel.
If I misunderstood anything please clarify.
> The timer is there to trigger overwriting the value if it is already
> "none" or to disable the alert. The behavior in the remote side can be
> implementation specific, the user can also interfere disabling the
> alert(eg: pressing a button).
> My point is: think in the UI elements behavior to implement the Find
> Me Locator APP. It is easy to implement a event driven action than add
> timers in the APP to control/block the user to press the
> button(control states).
>
> Does it help if we add a new property? eg: ImmediateAlertTimeout, zero
> means disabled.
>
> When both are enabled it not possible to determine which service
> triggered the IAS alert. If my previous suggestion doesn't help, I
> don't see another way to keep both services qualifiable unless we
> remove the timer and move the logic to the upper layer(I'd like to
> avoid if possible).
After doing some more study and analysis at my end, I have come to
following points in case
both Proximity and FindMe services are supported by remote device
- There is no need of timer for immediate alert service if this is
initiated by Path Loss.
- Timer to be used only if this is triggered for FindMe. Once timer is
fired, the immediate alert is set to none and ATT connection is
maintained as Proximity Profile is still connected.
In case only FindMe Profile is supported on remote device.
- Timer is triggered, and on expiration, ATT connection is
disconnected in accordance with FindMe Specification
- Before timer is fired, if user of Monitor sets alert level to None,
same is sent to remote side for stopping the alert.
In short we need the following things to support the above use cases -
1) An extra parameter in Immediate alert SetProperty to determine if
this alert is for Proximity or FindMe Profile.
2) Mechanism to disconnect the ATT connection if only FindMe is
supported on remote device (Currently there is no provision to
disconnect the ATT connection in monitor.c, except explicit call to
monitor_destroy, which I think is not intended for that)
Please let me know you views on this.
--
Best Regards
Hemant Gupta
ST-Ericsson India
Hi Arun,
On Wed, Dec 28, 2011 at 4:27 PM, Arun K. Singh <[email protected]> wrote:
> Hi Claudio,
>
>> If the remote supports both services, there is no way in the
>> client(Proximity plugin) to figure out which scenario is happening.
>> The upper layer(app external to BlueZ) implements the logic to control
>> the ImmediateAlertLevel. My suggestion are:
>> 1) add a new property ImmediateAlertTimeout
>
> The problem that I see with this new Timeout is that both Proximity
> and Findme app - above Bluez have to have the intelligence of knowing
> what services are supported on the remote side and then setting this
> level accordingly. This can further complicate such apps as these may
> not be standard profile applications and may be different from LE
> stacks where both the proximity and FindMe profiles are implemented
> pretty independently.
>
>> 2) or split ImmediateAlertLevel into: FindMeLevel and PathLossLevel
>> mapping into the same remote characteristic.
>
> This would need immediate Immediate alert to propogate to both such
> levels(FindMe/PAthLoss) from a remote side. May not be that bad except
> pushing extra logic into higher level apps. But still may be more
> appealing than the timeout complexities of approach (a).
>
>> Opinions?
> Would suggest (b) except that what happens to existing
> ImediateAlertLevel timeout. Who shall now decide to disconnect the ATT
> connection for FindMeLevel and retaining it for PathLoss. May be we
> need to export ATT disconnect too as a property in this case?
At the moment, there isn't a mechanism in the Proximity API to control
connections.
If the remote supports Link Loss or TX power, the link will NOT be
disconnected. If the remote supports Immediate Alert Service only, the
link can be disconnected after some seconds(after writing the level).
For Proximity, it seems enough. I don't think we need to expose ATT
disconnect property or method.
BR,
Claudio
Hi Claudio,
> If the remote supports both services, there is no way in the
> client(Proximity plugin) to figure out which scenario is happening.
> The upper layer(app external to BlueZ) implements the logic to control
> the ImmediateAlertLevel. My suggestion are:
> 1) add a new property ImmediateAlertTimeout
The problem that I see with this new Timeout is that both Proximity
and Findme app - above Bluez have to have the intelligence of knowing
what services are supported on the remote side and then setting this
level accordingly. This can further complicate such apps as these may
not be standard profile applications and may be different from LE
stacks where both the proximity and FindMe profiles are implemented
pretty independently.
> 2) or split ImmediateAlertLevel into: FindMeLevel and PathLossLevel
> mapping into the same remote characteristic.
This would need immediate Immediate alert to propogate to both such
levels(FindMe/PAthLoss) from a remote side. May not be that bad except
pushing extra logic into higher level apps. But still may be more
appealing than the timeout complexities of approach (a).
> Opinions?
Would suggest (b) except that what happens to existing
ImediateAlertLevel timeout. Who shall now decide to disconnect the ATT
connection for FindMeLevel and retaining it for PathLoss. May be we
need to export ATT disconnect too as a property in this case?
Thanks,
Arun
Hi Claudio/Hemant,
Some time back I initiated a thread
"[RFC] FindMe: Proposal to have separate dbus interface"
Because BlueZ is not aware of whether ImmediateAlert is written for
PathLoss or for FindMe, in this RFC I proposed to have seperate
interfaces for proximity and FindMe profiles. Having seperate
interfaces for these profiles will also solve the problem. Doing
things this way will make things more clear. Also there will be scope
for future enhancements in both the profiles.
Same approach can be used while sending back the
signal(PropertyChanged signal). if ImmediateAlert is written for
Proximity interface then signal will be sent on that interface
otherwise on the FindMe interface.
any views, opinions on this?
Thanks
Vishal
On 12/22/11, Claudio Takahasi <[email protected]> wrote:
> Hi Hemant,
>
>>> The timer is there to trigger overwriting the value if it is already
>>> "none" or to disable the alert. The behavior in the remote side can be
>>> implementation specific, the user can also interfere disabling the
>>> alert(eg: pressing a button).
>>> My point is: think in the UI elements behavior to implement the Find
>>> Me Locator APP. It is easy to implement a event driven action than add
>>> timers in the APP to control/block the user to press the
>>> button(control states).
>>>
>>> Does it help if we add a new property? eg: ImmediateAlertTimeout, zero
>>> means disabled.
>>>
>>> When both are enabled it not possible to determine which service
>>> triggered the IAS alert. If my previous suggestion doesn't help, I
>>> don't see another way to keep both services qualifiable unless we
>>> remove the timer and move the logic to the upper layer(I'd like to
>>> avoid if possible).
>>
>> After doing some more study and analysis at my end, I have come to
>> following points in case
>> both Proximity and FindMe services are supported by remote device
>> - There is no need of timer for immediate alert service if this is
>> initiated by Path Loss.
>> - Timer to be used only if this is triggered for FindMe. Once timer is
>> fired, the immediate alert is set to none and ATT connection is
>> maintained as Proximity Profile is still connected.
>>
>> In case only FindMe Profile is supported on remote device.
>> - Timer is triggered, and on expiration, ATT connection is
>> disconnected in accordance with FindMe Specification
>> - Before timer is fired, if user of Monitor sets alert level to None,
>> same is sent to remote side for stopping the alert.
>>
>> In short we need the following things to support the above use cases -
>> 1) An extra parameter in Immediate alert SetProperty to determine if
>> this alert is for Proximity or FindMe Profile.
>> 2) Mechanism to disconnect the ATT connection if only FindMe is
>> supported on remote device (Currently there is no provision to
>> disconnect the ATT connection in monitor.c, except explicit call to
>> monitor_destroy, which I think is not intended for that)
>>
>> Please let me know you views on this.
>
> If the remote supports both services, there is no way in the
> client(Proximity plugin) to figure out which scenario is happening.
> The upper layer(app external to BlueZ) implements the logic to control
> the ImmediateAlertLevel. My suggestion are:
> 1) add a new property ImmediateAlertTimeout
> 2) or split ImmediateAlertLevel into: FindMeLevel and PathLossLevel
> mapping into the same remote characteristic.
>
> Opinions?
>
> BR,
> 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 Hemant,
>> The timer is there to trigger overwriting the value if it is already
>> "none" or to disable the alert. The behavior in the remote side can be
>> implementation specific, the user can also interfere disabling the
>> alert(eg: pressing a button).
>> My point is: think in the UI elements behavior to implement the Find
>> Me Locator APP. It is easy to implement a event driven action than add
>> timers in the APP to control/block the user to press the
>> button(control states).
>>
>> Does it help if we add a new property? eg: ImmediateAlertTimeout, zero
>> means disabled.
>>
>> When both are enabled it not possible to determine which service
>> triggered the IAS alert. If my previous suggestion doesn't help, I
>> don't see another way to keep both services qualifiable unless we
>> remove the timer and move the logic to the upper layer(I'd like to
>> avoid if possible).
>
> After doing some more study and analysis at my end, I have come to
> following points in case
> both Proximity and FindMe services are supported by remote device
> - There is no need of timer for immediate alert service if this is
> initiated by Path Loss.
> - Timer to be used only if this is triggered for FindMe. Once timer is
> fired, the immediate alert is set to none and ATT connection is
> maintained as Proximity Profile is still connected.
>
> In case only FindMe Profile is supported on remote device.
> - Timer is triggered, and on expiration, ATT connection is
> disconnected in accordance with FindMe Specification
> - Before timer is fired, if user of Monitor sets alert level to None,
> same is sent to remote side for stopping the alert.
>
> In short we need the following things to support the above use cases -
> 1) An extra parameter in Immediate alert SetProperty to determine if
> this alert is for Proximity or FindMe Profile.
> 2) Mechanism to disconnect the ATT connection if only FindMe is
> supported on remote device (Currently there is no provision to
> disconnect the ATT connection in monitor.c, except explicit call to
> monitor_destroy, which I think is not intended for that)
>
> Please let me know you views on this.
If the remote supports both services, there is no way in the
client(Proximity plugin) to figure out which scenario is happening.
The upper layer(app external to BlueZ) implements the logic to control
the ImmediateAlertLevel. My suggestion are:
1) add a new property ImmediateAlertTimeout
2) or split ImmediateAlertLevel into: FindMeLevel and PathLossLevel
mapping into the same remote characteristic.
Opinions?
BR,
Claudio
Hi Claudio,
Do you have any comments on the below section of email about Proximity
and Find Me .
Thanks.
On Tue, Dec 20, 2011 at 9:35 AM, Hemant Gupta <[email protected]> wrote:
> Hi Claudio, Anderson,
>
>> Please sync with Anderson Briglia, he already sent a RFC to the ML
>> some months ago.
>> In the Bluetooth Summit(Prague), we decided to not proceed with RSSI
>> monitor emulation in the kernel until we have a clear idea or spec
>> defining how the controllers will implement RSSI monitoring.
> Could you please provide some details about what was discussed in the summit.
>
>> The ideia was to provide transparency, the userspace doesn't need to
>> know if RSSI monitoring is emulated or not.
>
> As per my understanding the BT spec (4.0, Volume 2, Part E, Section
> 7.5.4) the HCI_Read_RSSI command can be used to retrieve the RSSI from
> the controller. In our case, I have tested it against ST-Ericsson BT
> controller ?and it works in our case. Are you suggesting that until we
> know how the RSSI is determined in controller, we should not implement
> this functionality in kernel ? I ask this because in Proximity Spec,
> it is mentioned that the monitor should use appropriate calculations
> to prevent false alerts on reporter, so if we leave this to layer
> above BlueZ to do this part, then we are pretty independent with the
> approach of implementation of Path Loss RSSI Monitoring in BlueZ and
> Kernel.
>
> If I misunderstood anything please clarify.
>
>
>> The timer is there to trigger overwriting the value if it is already
>> "none" or to disable the alert. The behavior in the remote side can be
>> implementation specific, the user can also interfere disabling the
>> alert(eg: pressing a button).
>> My point is: think in the UI elements behavior to implement the Find
>> Me Locator APP. It is easy to implement a event driven action than add
>> timers in the APP to control/block the user to press the
>> button(control states).
>>
>> Does it help if we add a new property? eg: ImmediateAlertTimeout, zero
>> means disabled.
>>
>> When both are enabled it not possible to determine which service
>> triggered the IAS alert. If my previous suggestion doesn't help, I
>> don't see another way to keep both services qualifiable unless we
>> remove the timer and move the logic to the upper layer(I'd like to
>> avoid if possible).
>
> After doing some more study and analysis at my end, I have come to
> following points in case
> both Proximity and FindMe services are supported by remote device
> - There is no need of timer for immediate alert service if this is
> initiated by Path Loss.
> - Timer to be used only if this is triggered for FindMe. Once timer is
> fired, the immediate alert is set to none and ATT connection is
> maintained as Proximity Profile is still connected.
>
> In case only FindMe Profile is supported on remote device.
> - Timer is triggered, and on expiration, ATT connection is
> disconnected in accordance with FindMe Specification
> - Before timer is fired, if user of Monitor sets alert level to None,
> same is sent to remote side for stopping the alert.
>
> In short we need the following things to support the above use cases -
> 1) An extra parameter in Immediate alert SetProperty to determine if
> this alert is for Proximity or FindMe Profile.
> 2) Mechanism to disconnect the ATT connection if only FindMe is
> supported on remote device (Currently there is no provision to
> disconnect the ATT connection in monitor.c, except explicit call to
> monitor_destroy, which I think is not intended for that)
>
> Please let me know you views on this.
>
> --
> Best Regards
> Hemant Gupta
> ST-Ericsson India
--
Best Regards
Hemant Gupta
ST-Ericsson India
Thanks Marcel for the clarifications.
On Wed, Dec 21, 2011 at 3:10 AM, Marcel Holtmann <[email protected]> wrote:
> Hi Hemant,
>
>> > Please sync with Anderson Briglia, he already sent a RFC to the ML
>> > some months ago.
>> > In the Bluetooth Summit(Prague), we decided to not proceed with RSSI
>> > monitor emulation in the kernel until we have a clear idea or spec
>> > defining how the controllers will implement RSSI monitoring.
>> Could you please provide some details about what was discussed in the summit.
>>
>> > The ideia was to provide transparency, the userspace doesn't need to
>> > know if RSSI monitoring is emulated or not.
>>
>> As per my understanding the BT spec (4.0, Volume 2, Part E, Section
>> 7.5.4) the HCI_Read_RSSI command can be used to retrieve the RSSI from
>> the controller. In our case, I have tested it against ST-Ericsson BT
>> controller ?and it works in our case. Are you suggesting that until we
>> know how the RSSI is determined in controller, we should not implement
>> this functionality in kernel ? I ask this because in Proximity Spec,
>> it is mentioned that the monitor should use appropriate calculations
>> to prevent false alerts on reporter, so if we leave this to layer
>> above BlueZ to do this part, then we are pretty independent with the
>> approach of implementation of Path Loss RSSI Monitoring in BlueZ and
>> Kernel.
>>
>> If I misunderstood anything please clarify.
>
> we need proper notifications about RSSI changes triggered by the
> Bluetooth controller and not having the host polling the controller all
> the time. So just the existence of HCI_Read_RSSI is not enough to make
> this part efficient. And we can only emulate the RSSI notification via
> polling once we know how the new HCI commands will look like. We are
> kinda stuck here.
>
> Regards
>
> Marcel
>
>
--
Best Regards
Hemant Gupta
ST-Ericsson India
Hi Hemant,
> > Please sync with Anderson Briglia, he already sent a RFC to the ML
> > some months ago.
> > In the Bluetooth Summit(Prague), we decided to not proceed with RSSI
> > monitor emulation in the kernel until we have a clear idea or spec
> > defining how the controllers will implement RSSI monitoring.
> Could you please provide some details about what was discussed in the summit.
>
> > The ideia was to provide transparency, the userspace doesn't need to
> > know if RSSI monitoring is emulated or not.
>
> As per my understanding the BT spec (4.0, Volume 2, Part E, Section
> 7.5.4) the HCI_Read_RSSI command can be used to retrieve the RSSI from
> the controller. In our case, I have tested it against ST-Ericsson BT
> controller and it works in our case. Are you suggesting that until we
> know how the RSSI is determined in controller, we should not implement
> this functionality in kernel ? I ask this because in Proximity Spec,
> it is mentioned that the monitor should use appropriate calculations
> to prevent false alerts on reporter, so if we leave this to layer
> above BlueZ to do this part, then we are pretty independent with the
> approach of implementation of Path Loss RSSI Monitoring in BlueZ and
> Kernel.
>
> If I misunderstood anything please clarify.
we need proper notifications about RSSI changes triggered by the
Bluetooth controller and not having the host polling the controller all
the time. So just the existence of HCI_Read_RSSI is not enough to make
this part efficient. And we can only emulate the RSSI notification via
polling once we know how the new HCI commands will look like. We are
kinda stuck here.
Regards
Marcel