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