[PATCH] Added support for parsing temperature in the dive, header

[Jef Driesen]

On 2014-09-09 21:24, Dirk Hohndel wrote:
> On Tue, Sep 09, 2014 at 12:50:19PM +0200, Jef Driesen wrote:
>>> I think we really need to try to get more people to contribute...
>>> I'm sure we can find some people who will help if they can get access 
>>> to
>>> the necessary data.
>> 
>> Usually, people that request support for a new devices are not 
>> software
>> developers. And those that are, either have a device that is already
>> supported, or are not interested in working on a device they don't 
>> own. At
>> least that's my impression from the past years.
> 
> So Subsurface has about half a dozen contributors who don't even dive.
> And there are several diver/programmers out there who have shown
> tremendous energy and patience to help with topics that don't affect
> themselves directly.

I could be wrong, but I think that one of the reasons is that 
libdivecomputer as a low-level library has much less visibility than the 
applications using it. It get for example plenty of support emails from 
end users who think I wrote divinglog, macdive or subsurface. They just 
don't know the difference, and you can't really blame them for that.

> I certainly am more than happy to dig into adding support for dive
> computers that I don't own. I believe I added to the Atomics Cobalt -
> which I don't own :-)

I do get some occasional patches, but nobody has ever contributed a 
completely new backend from scratch. That obviously takes a lot more 
effort. Especially if you don't own a test device yourself, because then 
you also heavily depend on the availability of the test person. Timezone 
differences can be really annoying here.

Fixing parsing bugs is a lot easier, because once you have the data, you 
can easily reproduce everything locally.

> Is there a public list of which dive computers are missing but we have
> data?

At the moment, I have data for these two devices:

  * Divesystem Orca 2: I have some good capture files. Based on my 
initial investigation, the protocol appears to be a fairly standard 
request/response type of protocol. I suspect Divesystem uses the same 
protocol for their newer iDive range of dive computers too.

  * Citizen Hyperaqualand: I don't have a capture file yet, but there is 
some reverse engineered documentation [1], and an open source 
implementation [2] too.

[1] 
http://sourceforge.net/p/aquapalm/feature-requests/_discuss/thread/a5ec1ccf/b72c/attachment/aqualand.txt
[2] 
http://gdivelog.cvs.sourceforge.net/viewvc/gdivelog/gdivelog/plugins/hyperaqualand/src/hyperaqualand.c?revision=1.4&view=markup

> And a quick "how to get started"?

I don't have any documentation at all. I have couple of scripts to 
post-process the portmon capture files, to reduce them to the bare 
minimum (e.g. only the data packets) and remove all other distracting 
info.

 From there on, trying to figure out how the protocol works is mostly 
manual work. Experience from reverse engineering previous protocols 
certainly helps. Very often (but not always) the communication protocols 
have roughly the same structure (e.g. command, parameters, length, 
payload, checksum).

>>> What's missing? What do we have?
>> 
>> According to the usb device descriptors it's a USB HID device. That's
>> basically everything I know. Once I discovered libusb doesn't seem to
>> support USB HID very well, I didn't investigate much further due to a 
>> lack
>> of time.
> 
> OK, I think there are a few more "real" USB devices coming in the near
> future. So let's figure out what it takes to support that family of
> devices.
> 
> So this is the "what do we have" part.
> What's the "what's missing" part - i.e., where is the starting point to
> add support? Or is this entirely new to libdivecomputer and needs to be
> designed from scratch?

The cobalt is currently the only device which uses "real" usb 
communication. As you probably know, we're using libusb for that. But 
according to the libusb documentation [3], it's not suitable for HID. 
There is an open source hidapi library [4], but I don't have any 
experience with it. I also don't have much experience capturing usb 
communication in general (there wasn't really any need so far). USB is a 
lot more verbose and complex than serial communication. So yes, HID is 
pretty much starting from scratch.

[3] http://www.libusb.org/wiki/APIs
[4] http://www.signal11.us/oss/hidapi/

>> I wouldn't be surprised if the high level communication protocol is 
>> still
>> the same as the other Uwatec devices. For the Meridian Scubapro/Uwatec 
>> also
>> switched only the low-level layer from IrDA to usb-serial, and kept
>> everything else the same. But of course that's just an educated guess, 
>> and I
>> could be complete wrong.
> 
> So I assume you have contact to a few people who have such computers?

So far, Vincent is the only one who requested support for the Uwatec 
Square.

Jef