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

[Dirk Hohndel]

On Tue, Sep 09, 2014 at 01:04:29PM +0200, Jef Driesen wrote:
> >>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.
> >
> >Won't it be confusing if all three values are allowed to contain valid
> >data? How do you know if it's a metric or imperial tank? I assume most
> >applications already have logic to deal with this difference anyway. Are
> >there any devices that give us the wet volume for imperial tanks? As far
> >as I know the cobalt doesn't. As you already mention, this conversion
> >may need to take into account the compressibility factor (e.g. ideal vs
> >vanderwaals gas law). I think that's something libdivecomputer should
> >leave to the application.

Yes, definitely.

I have not seen a device that would give all three data points.

> >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;
> >};

How is that simpler than having all three values and figuring it out based
on that?

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

I would LOVE if you would switch these new fields to be integers.
And I think it would be perfectly fine to have wet_volume, air_volume and
working pressure and simply test against 0 to see which one is set. And if
for some odd device both are set, have the app figure out what it wants to
do.

/D