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

[Dirk Hohndel]

On Fri, Aug 22, 2014 at 03:53:05PM +0200, Jef Driesen wrote:
> On 2014-08-22 13:29, Calle Gunnarsson wrote:
> >And implemented this for Cressi Leonardo, see the attached patches.
> 
> Calle's patch uses a double for the temperature, which I think is fine. I
> remember that a while ago there was some discussion about defining the exact
> meaning of such temperature field. Keep in mind that not all dive computer
> store the same kind of temperature value(s). Some may record the minimum or
> maximum temperature, the temperature at maximum depth, etc. Others may even
> record several values. I think trying to support all these variants will
> quickly end up in a mess, so I'm fine to provide just a single value without
> attaching any particular meaning. Of course the interpretation will always
> be fixed within a particular backend, but temperature values from different
> backends may have a slightly different interpretation.

I will repeat my earlier comment that that's disappointing.
There is no way an application can now how these temperatures are defined.
Isn't that what libdivecomputer tries to do, to take away the need for the
application to worry about which dive computer was used?

I'd love if we could add a flag with at least three value:

- TEMP_IS_LOWEST_TEMP
- TEMP_IS_AT_DEEPEST_POINT
- TEMP_IS_OTHER

I know from diving with multiple dive computers that at least some single
temperature Suunto dive computers use the "at deepest point" logic, while
some my old Mares appears to log the lowest temperature.

> For the tank pressure, we certainly need support for multiple tanks, so my
> proposal is to add DC_FIELD_TANKPRESSURE along with a
> DC_FIELD_TANKPRESSURE_COUNT. That's consistent with what we already have for
> the gasmixes. For the corresponding data structure, I propose this:
> 
> typedef struct dc_tankpressure_t {
>     double begin;
>     double end;
> } dc_tankpressure_t;
> 
> That would be consistent with the data that is delivered in the samples
> (e.g. a pressure value with a tank id). The begin/end fields would simply
> correspond to the value of the first/last sample. So no attempt to add tank
> size (which not many dive computers support) or anything else.

Why not? You support at least one DC that does provide the data (Cobalt)
and it would be easy enough to include the three values that dive
computers may record:

typedef struct dc_tankdata_t {
	double begin;
	double end;
	double air_volume; // this is usually cuft
	double wet_volume; // this is in liter
	double working_pressure; // in bar like behin and end
};

Even having just one backend that today fills these values makes things
more useful for applications - and as more dive computers provide this you
have no need for yet another API.

Today Subsurface extracts this information from raw data - we can of
course continue to do so but I'd much prefer if this was in the official
API.

/D