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

[Jef Driesen]

On 06-09-14 20:46, Linus Torvalds wrote:
> On Fri, Sep 5, 2014 at 2:58 PM, Jef Driesen <jefdriesen at telenet.be> wrote:
>>>
>>> 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 may not *have* sample pressures, because maybe you don't have a transmitter.

Well, if there is no sample pressure, then of course libdivecomputer will never 
make up such data. That's just stupid.

For the tank pressure (and other fields) there are 4 different cases:

1. No header, no samples: This is probably a non-air integrated model. We won't 
try to provide any pressure data whatsoever.

2. Header, but no samples: This is typically an older or lower-end 
air-integrated model, which doesn't have enough memory to store a full pressure 
profile. We provide just the begin/end pressure from the header. We won't try to 
interpolate sample data.

3. Samples and header: This is a device that gives us everything. Nice and easy.

4. Samples, but no header: This is basically a special case of the previous one, 
except that the device tries to save some memory by not storing redundant 
information. The begin/end pressure can easily be obtained from the sample data. 
This is the category where this discussion is all about.

> The point I'm making is that the user of libdivecomputer cannot
> possibly _depend_ on having beginning/ending cylinder pressure data.
>
> So there is no point in trying to make such data up. It doesn't buy
> the library user anything, and you almost certainly make things
> *worse*, not better.
>
> In other words: you add no actual information, you add nothing that is
> valuable, but you *do* add confusion.
>
> If the pressure data is in the samples, then subsurface (or any other
> user) can - and will - look at the sample data. If you start reporting
> beginning and ending pressures separately that you just take from the
> sample data anyway, the *only* thing you do is to make for a more
> complex download with more room for errors.
>
> Why the f*ck would you want to do that? It's stupid. It's wrong. It
> doesn't _help_. It only hurts.
>
> Now, if the dive computer *separately* reports data like that, in
> addition to the data in the samples, then by all means, pass that kind
> of information through.  But don't make it up based on other data.
>
> An example of that is "maxdepth", where many dive computers (all?)
> report maxdepth as a separate thing from the depth data in the
> profiles. And it doesn't always match - the dive computer may save
> sample data at some particular frequency that is almost certainly
> separate from the actual internal sampling frequency. So in this case,
> maxdepth may actually have a *separate* value from the maximum depth
> found in the samples. THEN it is real data.
>
> But if it's just something you figured out from the samples, you
> SHOULD NOT LIE to the application and tell it that the dive computer
> reported it.
>
> Get it? You'd be *lying* about the dive computer. You'd be making shit
> up. And you'd almost certainly be *worse* at it, than we are. You only
> look at one dive computer at a time, subsurface will not. You don't
> have any way to match pressure sensors to particular cylinders, but
> subsurface might (ok, we don't, but at least we track it and there's a
> chance we might allow user editing etc). The moment you say "let me
> make things up based on other things", you're basically just making it
> harder to use the library sanely, because at that point we can no
> longer trust the data you give us to be what the dive computer
> reports. See?
>
> I'd much rather *not* get begin/end pressure data, and know that that
> means "the dice computer does not save that separately" than get
> made-up pressure data that I then don't know if it's the dive computer
> that has such things, or just Jef that is making shit up again. See
> the difference between the two cases?
>
> (And this is not just about pressure data. This is about temperature,
> about depth, about anything. Give us what the dive computer reports,
> not some "sanitized view" that means that we don't know what is dive
> computer and what is some random library version.

I think the main reason why we have a different opinion here, is because we see 
the role of libdivecomputer a bit different. You prefer a "minimal" library that 
just provides access to the data that is explicitly stored by the dive computer. 
So libdivecomputer only abstracts away where (byte offset) and how (little/big 
endian, metric/imperial, etc) the data is stored and that's it. That used to be 
my opinion too, but nowadays I think that ideally (and we're talking about the 
long term goal here) it should go one step further: libdivecomputer gives you an 
abstract representation of a dive, and the application can just get the info, no 
matter where or how it is stored (explicitly in the header or implicitly in the 
samples).

 From my point of view, the main benefit is that the application side becomes 
more simple. Instead of requiring all applications to implement their own 
fallback code, it would all be centralized in libdivecomputer. Then 
libdivecomputer could guarantee things like if the device has a pressure sensor, 
then you can just get the begin/end pressure. If there is a full pressure 
profile, then great, you can get that too, but that's optional. (Again, this is 
for the long term goals.)

You consider this as making things up or lying, I don't. For things like 
begin/end pressure, maximum depth there is no real calculation involved. It's 
basically collecting some trivial "statistics" on the sample data. How would an 
application be able to calculate this different or better? The input data is 
exactly the same! Yes, you are right that if a user has multiple dive computers, 
then the application may have a bit more info. But in that case, you'll have to 
merge the data somehow anyway. The maxdepth (or other header data) from two 
devices will rarely be exactly the same, and that's true regardless of whether 
you take maxdepth from the samples or dive header.


I'll try to illustrate my point with a complete different piece of date: the gas 
mixes. Most dive computers store the available gas mixes in the header. But 
there are several exceptions to this rule. The ostc has an extra manual gas that 
can be changed during the dive. The nitekq has no gas mixes in the header at 
all, only gas switches in the sample data. What should libdivecomputer return 
when subsurface (or another application) calls dc_parser_get_field with the 
DC_FIELD_GASMIX? Just the gasmixes in the header? For the ostc or nitekq that 
means you would miss some or all the gas mixes. Or should we parse the sample 
data and also pick up the manual gas (ostc) or process the gas switches 
(nitekq)? Do you also consider this making things up or lying?

If you ask me, libdivecomputer should do the latter, because this is just some 
internal detail of how the device records the gas mix data. The end user or the 
application shouldn't need to be aware of such things. I just don't understand 
why this would be any different than collecting begin/end pressure or maxdepth 
from the sample data. Where do you draw the line?

[To give a bit more context on why I picked the gas mixes as an example. It has 
been discussed several times already that the current libdivecomputer api for 
gas switches is far from ideal. A much better design would be to provide the id 
of the current gas instead of the O2/He percentages directly. That would for 
example solve the problem that right now you don't really know which mix you 
switched to, if you happen to have configured two identical gas mixes. But that 
means libdivecomputer has to collect all gas mixes up front, to be able to 
assign an id!]


I'm also not convinced that the application can always calculate missing data 
better than libdivecomputer can, as you claim. Libdivecomputer can easily apply 
device specific knowledge, which is much harder (or at least annoying) to do on 
the application side. Take for example the sensusultra. It records no divetime 
(or maxdepth, etc) in the header, only depth and temperature samples. But it 
also has a user configurable depth threshold and endcount setting to determine 
when a dive is considered over. (I assume all dive computers use a similar 
logic, but with the settings hardcoded.) The consequence is that the tail of the 
dive always consists of endcount samples with a depth shallower than the 
threshold. Most users will likely prefer this tail to be excluded from the 
divetime. Libdivecomputer can easily take these settings into account (although 
today it doesn't do that yet). Do you really want such device specific knowledge 
on the application side?


Note that I agree that for certain fields, like divetime, there are indeed 
multiple ways to calculate it. But as I already explained in my previous email, 
there is not really a correct answer, and if the goal is to have a consistent 
value across different devices then you should probably always ignore the value 
from the header and calculate it from the samples.

Jef