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

[Janice McLaughlin]

On Sep 9, 2014, at 4:04 AM, Jef Driesen <jef at libdivecomputer.org> wrote:
>> 
>> Wouldn't it be simpler to have either a metric size (wet volume, and
>> optionally working pressure) or imperial size (air volume and working
>> pressure), but never both at the same time. And then a third field
>> containing the type? Something like this:
>> 
>> struct dc_tank_t {
>>     unsigned int type; /* metric or imperial */
>>     double volume; /* either wet or air volume depending on the type, but
>> always in liter */
>>     double workpressure; /* in bar */
>>     double beginpressure;
>>     double endpressure;
>> };
> 
> I would love to get some feedback on this!
> 
> Although the discussion on whether libdivecomputer should calculate missing header fields from the samples or not, is an interesting one, it's not a priority at the moment. Initially libdivecomputer will only implement the new tank and temperature fields for devices where such info is available in the header, especially those that do not even have sample data. But I really would like to have this included in the next v0.5 release!
> 
> Jef

I've been reluctant to venture into this discussion because I don't have a strong opinion about this aspect directly. But this is because I've already implemented my own strategy because it was missing from libdivecomputer. There would have to be a compelling reason to switch from what I have now, that is working and shipping, to something new and untested. Getting the same information in a different way is not that compelling. Perhaps other application developers are in the same boat. However a later discussion about a different subject is related to this and I think tied in.

First, my dc_tankinfo_t looks like this:
typedef struct dc_tankinfo_t {
    float helium;
    float oxygen;
    float nitrogen;
    float startpressure;
    float endpressure;
    float tanksize;
    float workingpressure;
    float minPPO2;
    float maxPPO2;
    int type;
    int sensor;
} dc_tankinfo_t;

This is simply a direct result of what the UWatec Trimix firmware delivers for each of 10 tanks. So I grab this information from the DC and fill out the structure. Right now I'm only using this for UWatec Trimix firmware and no other manufacturers though as it hasn't been needed. But that may change soon.
(BTW - UWatec does NOT give tank size or working pressure however so I don't use those elements and I don't use the type or sensor yet either; the UWatec also has an additional field per tank that is still TBD for me though)
(BTW - I could skip Imperial tanksize units altogether too as calling it "braindead" is being too kind)

My point here though is that it also includes the gas mix for each of the tanks. So my only comment is that if you're going to add a new API for tanks, I would make it as expansive as possible and just have a way to indicate "no value" for the fields that are not applicable. That would accommodate the largest range of dive computers.

On Sep 9, 2014, at 12:00 PM, Jef Driesen <jef at libdivecomputer.org> wrote:
> [To give a bit more context on why I picked the gas mixes as an example. It has been discussed several times already that the current libdivecomputer api for gas switches is far from ideal. A much better design would be to provide the id of the current gas instead of the O2/He percentages directly. That would for example solve the problem that right now you don't really know which mix you switched to, if you happen to have configured two identical gas mixes. But that means libdivecomputer has to collect all gas mixes up front, to be able to assign an id!]

So this is why I think that what you do for tanks now might have a greater impact in the future. Right now libdivecomputer will report gas switches but not tank switches. Based on your explanation of how this came about, this make sense.  However, I would like to see the addition of tank switches to accommodate the dive computers that use this concept. And - you can model gas switches AS tank switches if you want to but you can't model tank switches as gas switches.

So, you mention that ostc and nitekq use the gas switch model. And so does Shearwater, although you can get the list of gases up front. But Atomic, Liquivision, Pelagic, and UWatec all have a tank switch model. I'm not sure about Suunto as I don't have good switching data, but it *seems* like it's tank based but could be gas based. Same for the newer Mares. But right now, if a diver switches from one tank to another with the same mix in it, it may not get recorded. In any case, I think there is a good argument for also having tank switch capability in libdivecomputer for more accurate information from the DC.

Anyway, I suggest that libdivecomputer could keep the existing DC_FIELD_GASMIX_COUNT and DC_FIELD_GASMIX API, and could also add a DC_FIELD_TANK_COUNT and DC_FIELD_TANKINFO interface, and then that would nicely give id's and a way to get SAMPLE_EVENT_TANKCHANGE events in the sample stream for those DC's that support it.

On Sep 10, 2014, at 6:31 AM, Jef Driesen <jef at libdivecomputer.org> wrote:
>>>> 
>>>> 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.

I have a USB analyzer that I needed for my driver work. If someone can deliver one of these units into my hands, I'd be happy to take a look and take some traces. And we could go from there.

Janice






Jan McLaughlin
Director, MPRF
http://www.mantapacific.org/