On Thu, Jul 02, 2015 at 11:51:39PM +0300, Claudiu Olteanu wrote: > > I tried your patch, and it works. But it works by falling back (after a > > delay) to channel 5. To confirm, I commented out the fallback conditions, > > so it only tried the uuid method, and that fails. > > Thanks again! It is quite strange why the QBluetoothServiceDiscoveryAgent > doesn't find the SPP service. On my HW OSTC2 device there are moments > when the SDP search ends with no results and moments when it finds the SPP > service. All happens randomly and I couldn't find a pattern. > > > There might be someone on this list with more Qt and/or bluetooth knowledge > > that could help. Otherwise, I'm sure there'll be a Qtconnectivity mailing > > list or forum you could try. > > I have sent an e-mail on the qt-interest mailing list about this issue > and to the > maintainer of the Qt Bluetooth API. I will let you know if I will > receive an answer. > > > I suspect the 5s delay could be reduced, but I don't know what to. > > I didn't know how small to make the delay. I know that it is > frustrating to wait more > than 10 seconds to connect to the Petrel 2 device. I hope that the issue with > the SDP search will be fixed soon and the delay will not be a problem anymore.
So it seems that all Petrel 2 use channel 5. At which stage do we need to know the correct channel? Do we have the name of the device at that stage already? /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
