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 <hemantgupta.ste@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
