[QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families

Claudiu Olteanu olteanu.vasilica.claudiu at gmail.com
Mon Jun 29 11:37:48 PDT 2015


>
> I've tested your patches, and your work looks great!
>

Hi Rick,

First of all, thanks a lot for your help! It helps me a lot to know that
it worked for a device that I didn't have the chance to test personally.
It gives me hope that I am on the right track.

To test a bit more, I unpaired my dive computer through the KDE Bluetooth
> system tray thing, and tried to pair it again through the Bluetooth dialog
> in Subsurface.  I have to admit that right-clicking and choosing pair
> seemed less than intuitive, but it worked flawlessly.  I did not need to
> use bluetoothctl.  Downloading dives again 'worked', except there were no
> new dives after downloading everything previously, so nothing was
> downloaded.
>

To be honest I don't have too much experience with the UI/UX. I though
that usually when an user wants to execute an action on a specific item,
he just uses the right button click and he selects the action from a
context menu. If you have other suggestions, please let me know.


> Can you do a similar query through qtbluetooth?  Or perhaps try channel
> zero first (should work for OSTC computers, Shearwater Predator and Petrel
> v1), if that fails, try channel 5.  I'm only aware of dive computers using
> those two channels, but you could try brute force after that.
>

I suspect that this is caused by the timer which after 5 seconds
without a feedback will stop the connecting process. This is just a
speculation but I believe that the device starts to interrogate each
channel (incrementally) and searches for the UUID of the required
service. It is possible that if the Serial Port Profile is available on
channel 5, the connection needs more time to succeeds.
Therefore, do you think that you can apply the attached patch and
try again? First remove the patch number 5 and then apply this one.
This patch increases the timeout from 5 seconds to 20. If the timeout
signal is raised and the device is in lookup service state, then it waits
another 30 seconds. I just want to eliminate this possibility.


> As further testing, I also tried using the Bluetooth dongle that came with
> the Petrel 2.  The dialog in Subsurface only recognized the onboard
> Bluetooth device, i.e. hci0, even when I used hciconfig to turn hci0 off
> and hci1 on.  I'm guessing you know this.
>

Yes, I am aware of this. The thing is that your onboard Bluetooth
device is set as default. If you set the Bluetooth dongle as default,
then it will be used in the Subsurface dialog. I will make a drop-down
list where the user can select which local Bluetooth device he
wants to use.

Best wishes,
Claudiu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150629/dcc26fb4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Increase-the-waiting-time-for-Bluetooth-LookUpSevice.patch
Type: text/x-patch
Size: 2110 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150629/dcc26fb4/attachment-0001.bin>


More information about the subsurface mailing list