[QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families

[Benjamin]

Just some random handwaving here...

The idea of a "new" dive computer called a Petrel 2 might be the simple
option right now, but what happens if in a future firmware update the
channel number gets changed? Is the idea of doing something similar to the
sdptool query over qtbluetooth not doable?

Benjamin

On 30 June 2015 at 01:38, Miika Turkia <miika.turkia at gmail.com> wrote:

>
>
>
>
> On 30 Jun 2015, at 05:29, Rick Walsh <rickmwalsh at gmail.com> wrote:
>
> 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.
>
>
> We have similar need to know ui designs in other places as well. At least
> the selection of columns on dive list. But I haven't seen this dialog, so
> don't know how confusing it is. A button might really make sense. Anyway,
> the UI can be improved once the real functionality is in place.
>
>
>
>>
>>
>>> 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.
>
>
> This selection would not be a big issue as current serial dl requires that
> as well. But of course it would be better if user was not bothered with
> these details.
>
> miika
>
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150630/b7086bf9/attachment.html>