Return-Path: MIME-Version: 1.0 In-Reply-To: References: <1309458277-30407-1-git-send-email-claudio.takahasi@openbossa.org> <1309465011.5023.85.camel@novo.hadess.net> Date: Fri, 1 Jul 2011 10:00:50 -0700 Message-ID: Subject: Re: [RFC BlueZ] Add Proximity API From: mike tsai To: Claudio Takahasi Cc: Anderson Lizardo , Arun Kumar SINGH , Bastien Nocera , "linux-bluetooth@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi, On Fri, Jul 1, 2011 at 7:23 AM, Claudio Takahasi wrote: > Hi Anderson, Arun, > > On Fri, Jul 1, 2011 at 7:50 AM, Anderson Lizardo > wrote: >> Hi Arun, >> >> On Fri, Jul 1, 2011 at 3:22 AM, Arun Kumar SINGH >> wrote: >>> Hello Anderson, >>> >>>>>> Covers the Proximity Reporter for Link Loss, Tx Power and Immediate >>> >>> [clip ...] >>> >>>>> Is this >>>>> good enough to implement both sides of the profile, or just one side of >>>>> it? >>>> >>>>The API is for the Proximity Monitor role. >>> >>> Sounds bit confusing.. Ain't these API's being proposed for Proximity Reporter Role which is what Claudio mentioned in the original RFC? Which bring me to the next question- since a GATT client makes more sense for a dual mode stack such as Bluez, shouldn't we focus first on Monitor kind of roles for LE profiles and later consider Reporter type roles for testing only? >> >> Sorry, actually it was a mistake from Claudio (which I hadn't noticed >> when I made my comments) :) This is a *Monitor* API as I mentioned. >> The doc itself mentions: >> >> +Interface ? ? ?org.bluez.ProximityMonitor >> >> And you are correct, our current focus is on Proximity Monitor & Find >> Me Locator (AKA "client") roles. The "server" roles will be initially >> implemented for testing purposes. >> > > It will be fixed. Sorry! > > Yesterday discussing internally here we found some issues: > 1. SetProperty("FindMeAlertLevel", level): needs a timeout. LE Create > Connection Command doesn't have a timeout, but the L2CAP socket(~40s) > and D-Bus message(~20s) have. > 2. SetProperty("FindMeAlertLevel", level): needs a cancel mechanism? > Maybe setting it to "none" is enough. > > LinkLossAlertLevel and PathLossAlertLevel are ok: timeout not > necessary. The last one is LOCAL and used only when the threshold is > reached. LinkLossAlertLevel can be persistent and written when the > connection is established. > I am a bit curious about the definition of PathLoss and Threshold property definition. The PathLoss has a range of 0 - 100, while the Threshold has low, medium and high setting. How do you plan to map PathLoss reading with Threshold setting? Regards, Mike > Regards, > Claudio > -- > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at ?http://vger.kernel.org/majordomo-info.html >