[QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families

[Rick Walsh]

Hi Claudiu,

On 30 June 2015 at 04:37, Claudiu Olteanu <
olteanu.vasilica.claudiu at gmail.com> wrote:

> 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.
>
>
It looks to me like you are 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.
>>
>
> 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.
>

I'm definitely not a UI designer.  Don't lose sleep over what this, because
what you have works, which is the main thing.  The issue with the the
context menu is that it doesn't prompt you if you don't know it's there.  I
expected there would be a 'pair' button, that is greyed out (or becomes
'unpair') when a paired device is selected.  Even better, could you keep
the context menu, but  allow the user to select a device and exit the
dialog with save, whether it's paired on not.  If it isn't already paired,
then pair at that point.  The user doesn't need to understand what pairing
is.


>
>
>> 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.
>
>

It doesn't appear to be a timeout issue.  Upon selecting download, there's
no pause - I immediately get the dialog "Unable to connect to
xx:xx:xx:xx:xx:xx Shearwater (Petrel)".  It's exactly the same with or
without the 20s timeout patch.  In both cases, the display on the Petrel
continues its "Wait PC 2:10" timer (it counts down from 3:00), which
suggests it isn't responding to a failed connection, but is waiting for
another attempt (no error message).  When a connection is made to channel
5, (either with your previous patch, or with rfcomm), the display changes
to "Wait CMD", then "Sending" when downloading starts.

I have no idea how qtbluetooth works, and haven't even tried to understand
the code, but it appears that on initial failure, we are getting "unable to
connect", and giving up, rather than trying the next channel.  Could you
force it to try again with the next channel?

Alternatively, create a new dive computer type, Petrel 2, and if that is
selected, go straight to channel 5.  The problem with this is that it
relies on the user knowing their computer is a Petrel 2 - they look the
same as the Petrel 1, and are almost the same dive computer - only
differences I'm aware of is the new version has a digital compass, and a
new Bluetooth chip.

Cheers,

Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150630/de9cf12f/attachment-0001.html>
-------------- next part --------------
HCI sniffer - Bluetooth packet analyzer ver 5.29
btsnoop version: 1 datalink type: 1002
> HCI Event: Command Status (0x0f) plen 4
    Create Connection (0x01|0x0005) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 11 bdaddr 00:12:34:56:78:9A type ACL encrypt 0x00
> HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
    status 0x00 handle 11
    Features: 0xbf 0x02 0x24 0x78 0x58 0x1e 0x1a 0x81
> HCI Event: Command Status (0x0f) plen 4
    Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
> HCI Event: Read Remote Extended Features (0x23) plen 13
    status 0x00 handle 11 page 1 max 1
    Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Remote Name Req Complete (0x07) plen 255
    status 0x00 bdaddr 00:12:34:56:78:9A name 'Petrel'
> HCI Event: Command Status (0x0f) plen 4
    Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
> HCI Event: Command Complete (0x0e) plen 10
    Link Key Request Reply (0x01|0x000b) ncmd 1
    status 0x00 bdaddr 00:12:34:56:78:9A
> HCI Event: Auth Complete (0x06) plen 3
    status 0x00 handle 11
> HCI Event: Command Status (0x0f) plen 4
    Set Connection Encryption (0x01|0x0013) status 0x00 ncmd 1
> HCI Event: Encrypt Change (0x08) plen 4
    status 0x00 handle 11 encrypt 0x01
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 11 reason 0x13
    Reason: Remote User Terminated Connection