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

[Jef Driesen]

On 2014-08-22 16:21, Dirk Hohndel wrote:
> On Fri, Aug 22, 2014 at 03:53:05PM +0200, Jef Driesen wrote:
>> 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.

My criteria for including new features has always been that it has to be 
reasonable generic AND supported by at least a few dive computers. And 
that last criteria does not apply here. If we ignore the Uemis, which is 
rather special because it has a complete built-in logbook of its own, 
the Cobalt is basically the only dive computer which gives us the tank 
size.

You can argue that we need this anyway, because future dive computer 
will provide this information too, but I'm not really convinced that 
will happen. The reason behind that statement is very simple. A dive 
computer doesn't need this kind of information to do its job. For gas 
consumption estimations (e.g. How long before I'll run out of gas?), 
your dive computer doesn't need to know the tank size. The existing air 
integrated dive computer are the perfect proof of that. So why would a 
manufacturer bother adding this? It's a bit like adding a knob that 
isn't hooked up to anything.

About the only use-case that's left for the tank volume is the gas 
consumption calculation in the logbook application (e.g. How much gas 
did I consume on my dive). If the dive computer supplies the tank size, 
then you no longer have to enter this manually, but that's about it. 
However, unless you are always diving with the same size of tank, I 
think it's far more convenient to enter this information in the logbook 
application than the dive computer UI. I have a Cobalt and use it in 
combination with different tanks (6L 300bar, 10L 300bar, 12L 200bar, 15L 
200bar), but I no longer bother adjusting the tank size in the Cobalt. 
It's too annoying to change it every time, and usually I just forget to 
do that anyway. I think it's far more user friendly to setup the tanks 
in the application, and assign them to your dives there. If you always 
dive with the same tank, then you can easily setup a default tank that 
automatically gets assigned to new dives, and then the user experience 
is exactly the same. Even better, because it also works for devices 
which don't provide the tank size!

And then I haven't even talked about the different systems to specify 
the tank volume (e.g. air vs wet volume). There is a reason why 
libdivecomputer always uses metric units. Mixing different units is only 
confusing and asking for trouble. I wouldn't mind if I can leave that 
mess to the applications :-) Luckily there are only a few small 
countries that hold on to their crazy imperial units :-) (me runs away 
now)

Jef