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.tur...@gmail.com> wrote: > > > > > On 30 Jun 2015, at 05:29, Rick Walsh <rickmwa...@gmail.com> wrote: > > Hi Claudiu, > > On 30 June 2015 at 04:37, Claudiu Olteanu < > olteanu.vasilica.clau...@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@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > >
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface