device autoprobing and changig bluetooth handling

[Dirk Hohndel]

On Mar 2, 2013, at 3:24 PM, Jan Schubert wrote:

> Hey guys, I see a strong need for a more userfriendly handling of
> downloading dives from dive computers and would like to start a
> discussion about this.
> 
> Mainly I'm adressing the need to know the device name which is no issue
> for us in here but for "normal" divers this is something as explaining
> rebreathers to Linus :-).

Careful - we just ordered the Rebreather course manuals :-)

> In the long run I'd like to see the device name filed dropped completely
> or moved to an expert/advanced submenu as there is just no need and it
> is not common to use them in other dive log software. In fact,
> specifying such technical stuff is for sure an indication that the UI is
> driven by developers.

I think that's a bit of an overgeneralization. And I can show you lots
of ways in which things can go horribly wrong if you just assume
that any serial device that you see is a dive computer. Really not a 
solid plan.

> Here are some of my thoughts:
> 
> Knowing which connection type to use - USB or Bluetooth, do we also have
> IR? - should be defined by the selected divecomputer and easily known to us.

Yes, in theory libdivecomputer supports at least one IR attached dive
computer, but I don't think anyone ever tried that with Subsurface

> Autoprobing USB ports and devices should be not that tricky!? I guess
> there is some way of recognizing active USB ports and autoprobing all of
> them, one by one or also in parallel. In rare cases where someone has
> connected several dive computers at once we should add a disclaimer
> saying he should not do so or have an expert menu for specifying the
> port manually (might also be needed in other cases?).

Oh this is all very easy. And that CNC machine behind that USB/serial
cable certainly won't mind when you send it random bytes over its control
port, nor will the GPS, the sensor network or any other of a number of
devices that frequently sit on the other end of these cables.

The problem is that the cables are easy to identify, but what's on the
other end is NOT. And I absolutely despise software that goes around
and randomly sends data to devices that it finds.

> Things gets more complicated when we talk about bluetooth. Autoprobing
> of typical Bluetooth ports should also be possible, but as of now there
> is a need to do some nasty manual work before the box is setup to use
> such a port. Not sure if you have read the corresponding section 4.3 in
> the user manual, but IMHO setting up bluetooth is a PITA in Linux. And
> also using Windows it is much more complicated to download from
> Shearwater Predator to Subsurface than using the Shearwater Desktop
> where the user has to specify just nothing at all and also do not have
> to pair the unit before. Same is true when using JDiveLog, they seem to
> use some Java Bluecove bluetooth stack doing all the work. I've not been
> able to get it running so far but it is said, that it is just working
> without the need for pairing before. And things go worse in Windows: In
> my (only) experience using Subsurface on Windows it turned out that
> pairing the Predator with Windows prevents downloading in Shearwater
> desktop, so this might fall back to Subsurface as users will for sure
> use both application on Windows at least for some time.

That last part puzzles me - but overall Bluetooth is actually much easier
than USB/serial. The Bluetooth devices tell us their name. The problem
is that there are so many Bluetooth stacks to get this right with. There are
seemingly half a dozen under Windows and two (at least) under Linux.
And it's not entirely obvious how to get the name of all Bluetooth devices
that the computer can see.

But I'm sure that someone with a bit of free time on their hands could make
this all "just work".

Things are even easier for the "disk drive" connected devices (so far I
think that's only the Uemis SDA and the h&w DR5/DRx). They have a
specific name that we can easily look up.

Again, just code that needs to be written.

> So you see, lots of reasons to have to think about this and question is:
> Is there some C library or something else which we could use to ease up
> using bluetooth devices in Subsurface? In fact I'm not sure if the way I
> do it (pairing before...) and also specified as such in the user manual
> is the correct one. It works but there has to be an easier way to do so.
> So is there are more experienced people around please come up with your
> suggestions, I'm more than willing to try other ways.
> 
> That said: I also have the feeling that the Shearwater Predator itself
> might be at little bit itchy when it comes to bluetooth. There is also
> indication from users running Windows that there is a reason for
> Shearwater to deliver their own Bluetooth dongle together with their
> dive computers.

The current firmware issue with the Predator prevents me from having
a more educated opinion on this one.

Overall answer:

yes, I want this to be easier.
no, I will not allow Subsurface to send random commands to random
ports in the hopes that maybe there's a dive computer on the other end.

One thing I could be talked into is something like this
- tell the user to connect the DC and put it in download mode
- check if there is exactly ONE usb-serial device we can see
- use that device

But if there is more than one cable attached this has to be a choice that
the user is able to make.

/D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4130 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130302/e7b9e6be/attachment.bin>