On 05-09-14 18:46, Linus Torvalds wrote:
On Sep 5, 2014 9:27 AM, "Jef Driesen" jef@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