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

[Dirk Hohndel]

On Sep 10, 2014, at 6:31 AM, Jef Driesen <jef at libdivecomputer.org> wrote:

> 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.

You are a prolific author :-)
And yes, I understand the difference. I just think that we could help get more people involved.

>> 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.

True.

>> 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).

Yeah, I’ve been through that with the Uemis :-)

>>>> 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/

Fun.

> 
>>> 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.

That’s also good to know. Nick, Sven, do you have more users with that device?

/D