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

[Jef Driesen]

On 05-09-14 18:46, Linus Torvalds wrote:
> On Sep 5, 2014 9:27 AM, "Jef Driesen" <jef at libdivecomputer.org> wrote:
>>
>> But what about header data, like begin/end pressure, temperature, maxdepth,
>> divetime, etc? There are several devices where such information isn't available
>> from the header, but where it's (indirectly) in the sample data. In that case
>> libdivecomputer can calculate the missing info from the sample data. I already
>> do that in a few places for divetime and maxdepth.
>
> I can mind of see the point of doing max depth and time, just to always have
> those fields in the header data for a dive.
>
> But cylinder pressures etc? Bad idea. They aren't always there anyway, claiming
> them just because you also have sample data is just wrong, stupid, and print to
> error (ie the cylinder connected to the pressure sensor may not be the first
> one, you don't know, stop gues

How can you not have begin/end tank pressure, when the samples contain tank 
pressure values? You are right that not every tank may have a pressure sensor 
connected, but why should that be a problem? You'll only get pressure 
information from tanks with a pressure sensor. Usually your dive computer isn't 
even aware of those other tanks. In that case you typically configure the gas 
mix, and the dive computer doesn't even care about the tanks at all. That's 
actually the reason why libdivecomputer will not try to associate gas mixes to 
tanks, because in most cases it doesn't have enough information. But here we are 
only talking about pressure sensors, not gas mixes.

In your example, where the pressure sensor is not connected to the first tank, 
then indeed libdivecomputer won't have that info. As far as libdivecomputer is 
concerned there would only be a single tank. Or more, if there are multiple 
sensors. But in that case libdivecomputer will know which pressure value belongs 
to which sensor. Because if that's not true, then the data format would be 
really broken. So the concept of the first (or second, etc) tank doesn't really 
apply here.

Assuming (just theoretically) that libdivecomputer would calculate begin/end 
pressures for devices which don't store those values in the dive header, then we 
would just go through the samples. For each tank sensor find the first and last 
sample with pressure data for that sensor and return those as the begin/end 
pressures. How can that go wrong? Am I missing something here?

> So don't add implied data. Even max depth and time is debatable (max time based
> on samples should take surface time into account, do you? Probably not),
> anything else is just really wrong.

Most dive computers store the dive time in the header, so this isn't really an 
issue. But for those that don't, the way libdivecomputer calculates it, depends 
on the dive computer. Some exclude surface time, others don't. I try to match 
with the manufacturers application, because that's usually also what is shown by 
the dive computer. Most of the time they can easily omit the divetime (to save a 
few bytes of storage I assume) because they just show number of samples 
multiplied with the sample interval. So in a sense the divetime is there, just 
not stored directly as a number of seconds.

Anyway, if you want the dive time to be consistent, independent of the dive 
computer, then you should ignore the value and always calculate the time 
yourself. Because in most cases, we simply don't know the exact details of how 
the dive computer calculates the dive time (e.g. does it exclude shallow 
samples, what's the threshold, etc). If you ask me, there isn't really a correct 
answer either.

I think most people expect to see the same value as reported by their dive 
computer, so that's what libdivecomputer tries to provide.

> If you can do it from sample data, then the real application that probably can
> do better and more (like correlate "multiple* she computers etc). Your
> calculated value at best might be just wrong, at worst they mess up a better
> calculation.
>
> Give what the dive computer gives. Nothing more. Nothing less.

Given my explanation above, I think what libdivecomputer does today is pretty 
much the way you want it.

Jef