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

[Dirk Hohndel]

On Tue, Sep 02, 2014 at 10:04:01AM +0200, Jef Driesen wrote:
> [Sorry for the slow response, but I've been busy with non libdivecomputer
> related things.]

How dare you have a real life! :-) :-)

I actually took the last few days off myself and did a computer free trip
into the mountains.

> Remember that adding features ad-hoc, based on what a certain manufacturer
> (e.g. suunto, which happens to be the first supported devices) provides is
> pretty much how the current libdivecomputer "design" evolved into what we
> have now. Linus and you already complained several times about the current
> libdivecomputer api. Don't get me wrong, I absolutely agree that many of
> those concerns are indeed valid and should be addressed. But for the time
> being, I just don't want to repeat those mistakes again. So yes, I'm a lot
> more careful when it comes to adding new features now.

Which I think is a wise choice. Don't get me wrong, I am not advocating to
add any random thing. I'd like at least a couple of dive computers from
different vendors to provide the information. Which makes this a tricky
one as the Uemis with its ass-backwards download approach isn't supported
by libdivecomputer at all. And I'd like at least a vague "OK, this could
be useful" check. The Uemis includes rather illdefined values for
"cold_fact", "work_fact", and "bubble_fact" in every sample. I wouldn't
suggest supporting something like that in libdivecomputer because even if
the Uemis was supported... what the heck would you do with these?

> Also from an application point of view, I think it's more interesting to
> have a rather limited set of features that is very well supported by the
> majority of the backends, then having a large number of features that are
> only supported by a few backends. That's basically why I have been spending
> most of my time and energy on improving the existing features, and not
> adding anything new.

I think we get at least as many "the vendor application supports this, why
don't you" email as you do. And then we often go back and look and notice
that the vendor application is actually making data up that isn't included
in the download (I think you just helped us in one case where the vendor
application shows a pressure graph but looking into the sample data it is
clear that there isn't even enough space there to hide the pressure
data...) - so it's just interpolated data. Same goes for deco information.
Sadly very few vendors actually include that in the downloadable data -
yet their applications show it by simply "re-doing the math".

But on the flip side - if a computer (or better, a couple of computers) do
provide something that I can imagine being really useful (heart rate comes
to mind, compass heading, ndl / deco status), then I'll argue to include
it even if only a few DCs support it.

> But okay, maybe I went into the defensive corner too fast. So let's start
> all over again, and assume we want to include the tank size too. Can you
> explain me how you would use the dc_tankdata_t structure in the following
> scenarios:
> 
>  * No tank size available (e.g. just begin/end pressure): How do we indicate
> that the tank size isn't available?

I see where you are going. The libdivecomputer design pattern would be to
return an error when that piece of information isn't availble, yet here we
have some data available and others not available.

We could fall back to saying "all values 0" means no data available. If we
have neither compressed nor wet volume, we obviously don't know how big
the tank is (i.e., while 0°C is a valid temperature, a volume of 0ml is
NOT a valid tank volume).

>  * Metric vs imperial tanks (e.g. water vs air capacity): How do we indicate
> the difference? For imperial tanks, we'll certainly need the working
> pressure. Metric tank also have a working pressure, and although it's not
> needed for calculating the amount of gas, it may be available too. Do we
> convert imperial units to metric units to be consistent with the rest of the
> libdivecomputer api, or do we make an exception here?

With all due respect to my host country, the American way of defining
cylinder capacity is beyond braindead. Yes, it seems to make intuitive
sense when you tell someone "this is an 80cuft cylinder" (assuming you
have wrapped your mind around the non-metric measurements), but of course
this only makes sense if you actually know the correct working pressure -
and as I frequently find out on dive boats it is not clear at all to a lot
of divers that an HP119 and LP95 contain the same amount of gas at the
same pressure...

So I would suggest that we have a member for the wet volume in mL.
And a different member for the volume at working pressure - also in mL.
And a third member for the working pressure - in mbar.
(oops, I am assuming the Subsurface style "we prefer integers" approach -
you can obviously use doubles and liter and bar - I like integer math
better, but I'm fine either way).

Technically one of the three values should of course be redundant - but we
have also learned the hard way that it actually isn't. Because the
"marketing size" of many cylinders is incorrect. And apparently almost no
one takes the compressibility factor into account (at 300bar a tank
contains only about 270 times as much air as its wet volume).
So if you have all three, give them. If you have only wet volume (or only
gas volume and working pressure) set the others to 0.

> And then we can work out something from there.

Thanks Jef. Much appreciated.

Sven, Nick - any input on what would be useful for your apps?

/D