Atomic Cobalt

[Jef Driesen]

On 2011-12-26 21:36, Kurt wrote:
> I figured as much. I have the complete C# source for the Atomic log
> software as well as access to the folks in Washington that developed
> the Cobalt. I was just reporting the default change because it
> changed. I have not had time (nor will I) to read and assimilate the
> inner workings of your library. Though I have the basic gist from the
> sparse design docs, working through the execution path takes a bit of
> time. Suffice to say that I was hoping that you weren't actually 
> using
> the Device name.  Looking from the outside I have no way of knowing
> what you are doing with it or what hidden dependencies you might 
> have,
> so I was simply reporting for completeness sake, and because that is
> what the instructions say to do. For all I know, you may have 
> centered
> on a Serial-like interface in your state machine that transforms to
> whatever protocol is necessary on the way down and pack. 
> Message/reply
> protocols can be written anyway the author likes and I've seen 
> weirder
> things on source forge.
>
> A little documentation would go along way.

I'm biased of course, but I think the libdivecomputer internals should 
be easy to understand for a developer, even without any documentation. 
Basically every backend lives in a single file, and most of the function 
names are straightforward. The libdivecomputer project is targeted at 
developers (and where that's not the case, we do have detailed 
instructions available). End-users have little use for such 
documentation, unless you are referring to subsurface now (cf. Dirk's 
reply).

I don't want to be rude, so don't take this comment as such, but you 
want me to provide better documentation, while you don't even want to 
spend any time to look at the code? Remember this is an open source 
project ... I spend my time on what I believe is the most important. 
Right now, better documentation is low priority for me. Not because I 
think documentation is unimportant, but because I think other things are 
more important. If you (or anyone else) disagree with my priorities, you 
are free to contribute better docs.

>> Have you also switched from the "libusb0" driver to the "WinUSB" 
>> driver using the "zadig" installer? This is explained here:
>
> Absolutely not. This is most unfortunate, since it renders subsurface
> a non-starter. I read the docs but did not make those changes, 
> playing
> a strictly defined role: Interested user looking for an acceptable
> dive log for Cobalt.
>
> I assume from your prior comments that you have no intention of
> undertaking firmware flashing on the Cobalt. Changing to a driver 
> that
> makes that impossible (WinUSB) is an unacceptable cost for my 
> purposes
> or any other likely user.  Switching drivers and remembering which 
> one
> is installed is just not acceptable. That is really too bad.

I'm aware the situation with the different drivers is not ideal.

There are currently two versions of the libusb library. First there is 
the legacy 0.1 version, which supports the libusb0 driver (from the 
libusb-win32 project), but which is also not actively maintained 
anymore. The future is the newer 1.0 version, and thus that's the 
version I used. Unfortunately this version is targeted at the winusb 
driver (from Microsoft). Support for the libusb0 driver is on the libusb 
roadmap, but last time I checked it wasn't available yet.

The libusbk project is the next generation libusb-win32 driver.

Updating firmware isn't something you have to do very often, so I think 
the inconvenience is actually quite small. With the zadig installer, 
it's just one click to switch drivers. You are actually the first user 
to complain about the driver switching.

I never said anything about supporting firmware flashing, so I have no 
idea why you think that couldn't be supported by the libdivecomputer 
project.

>>> Universal -b cobalt com3 reports Error 660 "Error opening device"
>>
>> That is expected, because the test applications are build without 
>> USB support. If I would build with usb support, everyone would have to 
>> download the libusb dll too, and that's making everything even more 
>> complicated for non-technical people.
>
> You have a different idea of what non-technical means than I do. The
> average diver out there can barely turn on an iMac and most can't
> figure out where a USB cable plugs in. non-technical people are not
> going to be running universal.exe.

I don't think our definition of non-technical people is different. I 
agree that running a command-line application is indeed a challenge for 
many of those people, but it's currently the only option I have 
available to have end-users collect the diagnostics information I need. 
If I would have to create a nice easy to use GUI application, that would 
take quite some time (especially to support all three major OS'es), 
which I unfortunately don't have at the moment. These command-line 
applications are very easy to build for me, and with some assistance 
most people manage to run them too. So it's far from perfect, but it 
gets the job done.

If you look at the mailinglist archives, you'll see there are plans to 
enhance the logging and have it integrated into the application directly 
(look for the "Logging support" and "Roadmap" threads). That will make 
it a lot more user-friendly.

> That said, I copied the libusb dll
> from subsurface install in its[universal.exe] directory figuring it
> would need to find it.

It's statically linked (and without libusb support), to make sure it 
doesn't have any external dependencies. That's one less possibility for 
mistakes by end-users.

> Oh well, I guess I'll never have a useful dive log for the Atomic on
> the Win platform, MacDive here we come….

Macdive is a very nice application, I'm sure you'll like it. But in 
case you didn't know, it's also using the libdivecomputer library, 
except that it uses the native Mac USB api directly, rather than through 
the cross-platform libusb api. And it doesn't support your Uwatec Smart, 
due to the lack of IrDA support on Mac OS X :-(

Jef