[GSoC] Week 6 (Native Bluetooth support)

Dirk Hohndel dirk at hohndel.org
Sun Jul 5 15:36:42 PDT 2015


On Sun, Jul 05, 2015 at 10:50:59PM +0300, Claudiu Olteanu wrote:
> Hi there,
> 
> I spent this week doing some tests to find out the possible reasons
> of some  issues:
> - first the QtSocketBluetooth::connectToService(address, uuid, mode)
> doesn't work as expected. On some devices, the SPP profile is never found.
> - second on some environments the connection takes too long when
> I use my second device (HW OSTC2) and the timeout event is raised
> 
> Besides my OpenSuse distribution (BlueZ 5.30 and Qt 5.4.1)
> I created two new environments:
> - Fedora 22 : Bluez 5.29 and Qt 5.4.2
> - ArchLinux 2015.07.01 : BlueZ 5.31 and Qt 5.4.2
> 
> Regarding the first issue I did some investigations and I started to
> talk with the maintainer of QtBluetooth API.  He said that it could be
> a bug in the library and I provided him some extra information. Now
> I am waiting for his feedback.

Might be worth following up, copying Thiago. If we are chasing a library
bug I'd prefer to know that early.
Out of curiosity, have you tried compiling Qt5.5 from source and trying
with that? That is high on my personal todo list.

> To be honest, I am a little stuck with the second problem.
> My HW OSTC Sport device works on all environments while the
> OSTC 2 model doesn't.

I have talked to Matthias Heinrichs about some issues I have with my OSTC
2 as well. Might also be worth pinging him in case he has newer firmware.

> On the OpenSuse environment there are moments when I successfully
> connect to the device and initiate the data transfer mode and moments
> when it gets stuck in the Connecting state. On the other two environments
> the device always gets stuck on the connecting state.

For my OSTC 2 I can load the directory but then get stuck loading dives.

> Now I don't know what to do next and how to tackle the problem.
> I did everything I had in mind (extended the timeout, verified that
> the date of the device is set correctly, looked over the HCI logs and
> see what could be wrong, tried to use directly the RFCOMM 1 channel).

I'm not much of a BT expert, obviously, so I'm not quite sure what else to
suggest.

On Sun, Jul 05, 2015 at 10:57:51PM +0300, Claudiu Olteanu wrote:
> I forgot to specify that the Fedora 22 and ArchLinux environments
> are two virtual machines. I don't know if this could cause the problem.
> If it does, I expect that it shouldn't work with the HW OSTCs device as
> well.

Depends on your VM. Forwarding BT to the VM tends to work fairly well. My
Arch Linux is running into a VM as well and rfcomm based BT interactions
work just fine.

I would like to start merging your patches into Subsurface master and into
the Subsurface-testing branch of libdivecomputer. Can you create git
branches that I can pull from that

a) are clean (coding style, commit messages, no redundant code added /
code deleted patterns)
b) don't mess with the user if they use rfcomm style communication (or
standard serial communication in case of the OSTC 3)
c) work at least in your openSUSE environment

That would make it easier for more people to test and help you figure out
what's going on.

/D


More information about the subsurface mailing list