From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 13 Dec 2012 09:48:50 +0200 From: Johan Hedberg To: Ting Chou Cc: Anderson Lizardo , "linux-bluetooth@vger.kernel.org" Subject: Re: [BLE] org.bluez.Device1.Connect() returns org.bluez.Error.NotAvailable Message-ID: <20121213074850.GA1348@x220> References: <20121212075201.GA14256@x220> <20121212092537.GA5371@x220> <20121212100737.GA6620@x220> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Ting, On Thu, Dec 13, 2012, Ting Chou wrote: > > > I'm not sure if I understand correctly. But do you mean the GCEP you > > > mentioned above is applied while "reconnecting" to a supported device? > > > > Yes, all GAP connection procedures are applicable for re-connection. > > There is no "reconnection" procedure as per GAP (as far as I know). > > But note that each GATT profile can specify reconnection procedures in > > case of disconnection due to link loss (most of those that I read have > > this). For instance, in HTP: > > > > "5.2.4 Link Loss Reconnection Procedure > > When a connection is terminated due to link loss, a Collector should > > attempt to reconnect to the Thermometer using any of the GAP connection > > procedures with the parameters in Table 5.2." > > > > This is what BlueZ is doing for profiles implemented internally, except > > that the parameters we use are not the ones recommended on the profile > > specs (that could be implemented in future, but for now GCEP uses fixed > > connection parameters). > > > > So I should exercise the D-Bus API like following for LE device: > > Adapter1.StartDiscovery > Device1.Pair > ... > ... > // link loss > ... > // auto reconnect > ... > Adapter1.RemoveDevice > > Is my understanding correct? Yes, except that you should call Adapter1.StopDiscovery before calling Device1.Pair. Johan