Claudiu, On 1 July 2015 at 08:55, Claudiu Olteanu <[email protected] > wrote:
> I attached a patch which should resolve the issues regarding > the connection. > Thank, I'll try it out this evening. > > 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 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. > > > Assuming it's similar to setting up a connection on the command line with rfcomm, I think most devices use channel 0, not 1. I can't test this because mine uses channel 5. Can you try both 0 and 1 with the OSTC, and see if one works and the other doesn't? Cheers, Rick
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
