[QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families

Rick Walsh rickmwalsh at gmail.com
Wed Jul 1 14:32:56 PDT 2015


On 1 Jul 2015 8:55 am, "Claudiu Olteanu" <olteanu.vasilica.claudiu at gmail.com>
> 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
> 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150702/e05a5489/attachment-0001.html>

More information about the subsurface mailing list