[QtBluetooth] Help for testing HW_OSTC3 and SHEARWATER families

[Miika Turkia]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150630/41046a53/attachment.html>