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

Jef Driesen jef at libdivecomputer.org
Tue Sep 9 04:04:29 PDT 2014


On 03-09-14 17:04, Jef Driesen wrote:
> On 2014-09-02 22:53, Dirk Hohndel 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.
>
> 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


More information about the devel mailing list