Claidiu, On 1 Jul 2015 8:55 am, "Claudiu Olteanu" <[email protected]> wrote: > > I attached a patch which should resolve the issues regarding > the connection. > > I know that this is not the ideal solution but I wanted to cover all cases. > First I try to make a connection using the UUID of a service. > If the timer expires and the device is in the ServiceLookupState, then > I extend the waiting time. > If the connection ends with a ServiceNotFoundError then I try to force > the connection on channel 1. If this doesn't work, I try again on channel > number 5.
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. > > I took this decision because the QBluetoothServiceDiscoveryAgent > cannot find the SPP service from my HW OSTCs device. I don't know > why. I captured the HCI events during the Qt service discovery proces > and they are identical with the ones raised by sdptool. > The interesting thing is that when I use my HW OSTC 2 device, the SPP > service is discovered. > > If you want I can remove the part where it tries to initiate a connection > using SPP's uuid. I can try to make a connection on channel 1 and if > it fails I try again on channel number 5. This would work if the SPP > service is always listening on channel 1 or on channel 5. > > Cheers, > Claudiu I don't know enough to say what method is best, so long as it's something that works. Using the SPP's uuid looks like a neat solution, but for some reason it isn't working all the time. 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 suspect the 5s delay could be reduced, but I don't know what to. Cheers, Rick
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
