Sorry for top response... I believe I built the Windows binaries with libusb and a very recent version of libdc. /D -- Sent from my phone. Please excuse the brevity and text prediction errors Jef Driesen <jefdriesen@telenet.be> wrote: On 12/23/2011 07:22 PM, Kurt wrote:

I have been looking at Subsurface dive log 1.2 which offers to download Atomic Cobalt.

I can't make it work. I suppose that it may not be implemented, or that my bonafide software installation which includes libusb may interfering or incompatible. My installation and connection works fine with the Atomic software.

I can't see any Atomic support in the latest snapshot, so I suppose it is the former. If this is a work in progress I may be of some [not insignificant] help to the implementor(s). If they are interested, get in touch with me.

Perhaps there is Fog in the cockpit and I am doing something wrong?

My platform is Win7/32 and I am entering COM3 as the device. "COM3" works fine with Uwatec. The Cobalt is attached and "Connected" (enumerated and recognized by PC) I have tried three different firmwares, currently 1.13/1

Is there a special device name or sequence.

Are you compiling subsurface and the libdivecomputer library from source, or are you using the precompiled packages? I think the precompiled packages are build without usb support, and thus have no cobalt support. If you build yourself, make sure to use the latest code from the git repository. The snapshot on the libdivecomputer website is quite old, and also doesn't have usb support. The next thing you have to be aware of is that the libdivecomputer library requires a different driver than the atomcics application (they are both using libusb under the hood, but we are using the more recent 1.0 version instead of the legacy 0.1 version). Instructions for switching between the drivers are available on the Diving Log website: http://www.divinglog.de/english/tutorials/cobalt.php Jef _____________________________________________ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _____________________________________________ libdivecomputer-devel mailing list libdivecomputer-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel

Will fix once I have access to a computer again... /D -- Sent from my phone. Please excuse the brevity and text prediction errors Jef Driesen <jefdriesen@telenet.be> wrote: On 12/23/2011 09:53 PM, Dirk Hohndel wrote:

Sorry for top response...

I believe I built the Windows binaries with libusb and a very recent version of libdc.

I just checked, and the 1.2 installer doesn't include the libusb dll, and the libdivecomputer dll has no dependency on it either. If it did, subsurface wouldn't even run without a libusb dll present. That's why my test applications are not build with usb support :-)

On 12/24/2011 06:43 AM, Dirk Hohndel wrote:

On Fri, 23 Dec 2011 21:59:47 +0100, Jef Driesen<jefdriesen@telenet.be> wrote:

...

On 12/23/2011 09:53 PM, Dirk Hohndel wrote:

...

Sorry for top response...

I believe I built the Windows binaries with libusb and a very recent version of libdc.

I just checked, and the 1.2 installer doesn't include the libusb dll, and the libdivecomputer dll has no dependency on it either. If it did, subsurface wouldn't even run without a libusb dll present. That's why my test applications are not build with usb support :-)

Ok, back at a computer. My fault. I could have sworn I enabled libusb but apparently I didn't. Unfortunately I'm on vacation and don't have access to a Windows system to do any testing on whatsoever. So while I can easily build a new version, I'm unable to test if I packaged things correctly. So please give this a try and let me know if I missed anything else:

http://subsurface.hohndel.org/wp-content/uploads/2011/12/subsurface-1.2-libu...

I did add the libusb-1.0.dll - so I /think/ it should work...

I tested this version, and downloading a cobalt works fine. Jef

On Dec 24, 2011, at 10:35 AM, Dirk Hohndel wrote:

...

...

Ok, back at a computer. My fault. I could have sworn I enabled libusb but apparently I didn't. Unfortunately I'm on vacation and don't have access to a Windows system to do any testing on whatsoever. So while I can easily build a new version, I'm unable to test if I packaged things correctly. So please give this a try and let me know if I missed anything else:

http://subsurface.hohndel.org/wp-content/uploads/2011/12/subsurface-1.2-libu...

I did add the libusb-1.0.dll - so I /think/ it should work…

I retrieved this version and it does (of course) have libusb-1.0.dll. It is advertised in the install details and I verified it in "Program Files/Subsurface". Additionally, this version kindly defaults to "COM3" for the Device. Unfortunately, it is not able to download either of my Atomic Aquatics Cobalts on my system : Win7/x86. I'll try it later on my win7/64 when I get some time. I nuked the prior installation and also rebooted. The firmware version on the Cobalt is 1.13/1 and it continues to be accessible to the Atomic software. Importing from my Aladin Smarts thru USB IrDA using "com3" continues to work well. Universal -b cobalt com3 reports Error 660 "Error opening device" regards kurt

On Dec 26, 2011, at 2:20 PM, Jef Driesen wrote:

...

Additionally, this version kindly defaults to "COM3" for the Device.

The serial port (e.g. COM3) isn't used for the cobalt because it downloads over USB directly. You can set this parameter to whatever you want, because it's simply ignored.

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.

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.

...

Importing from my Aladin Smarts thru USB IrDA using "com3" continues to work well.

Uwatec Smarts also don't use the serial port.

I used MSFT's IrDA Tcp stack as I recall…I haven't touched that code in several years. Again, haven't looked at your code for the actual implementation. Just trying it out to see if subSurface is worth looking into. The docs say to use COM3, so I use COM3.

...

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. That said, I copied the libusb dll from subsurface install in its[universal.exe] directory figuring it would need to find it.

I have access to a cobalt myself (including excellent support directly from Atomics Aquatics!), so I can perform all testing locally, and the lack of support in the test app isn't an issue.

Understood. Not having any more documentation than you supply, I offered that information in case 1) it worked, and 2) subsurface implementation was suspect. I'm not sure what's going on with winusb/libusb0/libusbk and don't really want to know. Atomic is probably using libusb0 because thats what libusbdotnet uses and that's that. Oh well, I guess I'll never have a useful dive log for the Atomic on the Win platform, MacDive here we come….

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