Hi Claudio, On Wed, Aug 3, 2011 at 4:52 PM, Claudio Takahasi <claudio.takahasi@xxxxxxxxxxxxx> wrote: > Hi Gustavo, > > On Wed, Aug 3, 2011 at 5:25 PM, Gustavo Padovan <padovan@xxxxxxxxxxxxxx> wrote: >> * Claudio Takahasi <claudio.takahasi@xxxxxxxxxxxxx> [2011-08-03 16:36:43 -0300]: >> >>> Hi Briglia/Marcel/Padovan: >>> >>> On Tue, Aug 2, 2011 at 3:35 PM, Anderson Briglia >>> <anderson.briglia@xxxxxxxxxxxxx> wrote: >>> > This RFC is about RSSI monitoring since controllers do not have a specific >>> > command for this and we need it for Proximity Profile, at least. >>> > >>> > The RFC implements a mechanism to set threshold levels in order to send >>> > alerts to userspace when a RSSI value reaches one of the configured thresholds. >>> > >>> > Management Interface contains a list of RSSI Monitors. Elements are inserted >>> > or deleted from this list using two new Management commands: Enable and Disable >>> > RSSI Monitor. >>> > >>> > A timer was added to do HCI Read RSSI requests to the controller and get RSSI >>> > values updated. If there is monitored connection (eg.: RSSI Monitor list size > >>> > 0), the timer is reseted after two seconds and the RSSI for each monitored conn >>> > is updated. Using the RSSI value, a Management Event is sent if one of the >>> > thresholds were reached and the alert is different from the last one sent. >>> > >>> > Userspace is responsible to add and remove RSSI Monitors. Each monitor must >>> > have low and high thresholds values for RSSI. A RSSI Monitor is disabled when >>> > the connection is no longer available or the userspace sends a command to >>> > remove it. If there is no RSSI Monitor remaining in the list, the RSSI Read >>> > polling timer is removed. >>> >>> Should be the entries persistent across connections? In the suggested >>> approach the RSSI threshold monitor for a given address is >>> automatically removed when the connection is lost. >>> By other hand, persistence introduces another problem: trust that the >>> userspace will disable the monitor. >> >> Is it really worth? There are some reconnections to justify the persistent >> entry? The wast of memory worth the savings in interactions between >> kernel-userpace through the mgmt? >> >> Gustavo >> > > It saves logic in the userspace. Memory is not critical, how many > keyfobs a "normal" user will have? > Removing automatically means the kernel and userspace will be out of > sync, there isn't an event notifying that an entry was removed. > > For Proximity, the RSSI threshold needs to be calculated, remote's Tx > power(read using ATT) is an input. In theory, Tx Power will not change > in the next connection, meaning that an additional logic can be added > in the Proximity Monitor to avoid enable/disable the RSSI threshold > monitor if the new calculated RSSI threshold doesn't change. Please, correct me if I'm wrong, but this persistency will be used to save one command from userspace to kernel? I mean, Proximity application still needs to tell to the kernel that it needs to start a RSSI monitoring even if the thresholds had not changed. For example, if a connection with the same remote address is established but we do not want to use Proximity, userspace needs to tell to Management that no RSSI monitoring should be started for that connection. In this case, Management will not be able to enable/disable RSSI monitors automatically. IMHO, the userspace should be responsible to enable/disable RSSI monitors. > > Regards, > Claudio > -- INdT - Instituto Nokia de tecnologia +55 92 2126 1122 +55 92 8423 3183 -- 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
