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

[Jef Driesen]

On 2014-09-22 04:04, Janice McLaughlin wrote:
> On Sep 16, 2014, at 11:26 AM, Jef Driesen <jef at libdivecomputer.org> 
> wrote:
>> On 2014-09-14 04:03, Janice McLaughlin wrote:
>>> But to address your point of decoupling the gas mix from the tank
>>> information .... this would not be *my* preference. That would mean
>>> that the sample stream would return both a gas change AND a tank
>>> change event every each time there was a tank change. And, as you
>>> suggest, you'd have to put the gas mix id inside the tank information
>>> ..... and that just seems confusing. I'd rather see the gas mix 
>>> inside
>>> the tank info and only 1 event in the stream. Which may or may not
>>> mean a gas change as well depending on what's in the tank.
>> 
>> No, I think you misunderstood me. The idea is that in the samples, 
>> there will be no tank changes, only gas changes. For a device using 
>> the tank switch model, the gasmix field provides a fixed one to one 
>> relationship between the dc_tank_t structure and the corresponding 
>> dc_gamix_t structure. So you don't really need a tank switch.
>> 
>> For devices using a true tank switch model like the cobalt one, the 
>> number of dc_tank_t and dc_gasmix_t structures will always be 
>> identical. Thus if the id's is a simple zero based index, then the id 
>> in the gas change event can be directly mapped to the tank structure.
> 
> I see. And the pressure samples will also use the same id (tank) in
> the future then too?

Yes, that's the idea.

>>> Again, I would not change anything for devices that "don't track
>>> tanks" and continue to do what you are doing. And for DC's that have 
>>> a
>>> one to one mapping, then put the gas mix inside the dc_tank_t.
>> 
>> How do you deal with the "hybrid" case that I explained above (e.g. 
>> Suunto Cobra 2)?
> 
> I don't think the Suunto Cobra 2 is a hybrid - it seems like the base
> configuration of the majority of dive computers. One supply of
> breathing gas that the user and the DC have to agree upon in advance.
> In this way, it's no different from an Atomic. And while diving, the
> Cobra2 will put information about gases in the sample data and the
> Atomic will put information about tanks in it's sample data. But in
> this simplest case which is the majority of what everything out there
> is, it just becomes semantics as to whether it's a gas switch or a
> tank switch at the beginning and there is no point in getting into
> semantics. But for the more advanced DC's, then I think we should have
> a scheme that expands to support them. Keeping the gas and tank info
> separate is "fine", not my preference, but I can live with it as long
> as all the id's match up.

Hybrid was maybe a bad term to refer to the Cobra2. I just wanted to 
point out that it supports multiple gas mixes and tank info, but no 
information to link the two together.

Anyway, let me illustrate what kind of info you would get for the three 
main type of devices, by means of a few examples:

1. Non-air integrated model (OSTC)

Gas mixes:
0: Air
1: Nx32
2: Nx36
3: ...
4: ...

Tanks: None

In the samples, a gaschange event will reference the gas mix using the 
corresponding id. (Right now the event contains the O2/He percentages 
directly, but let's assume we have fixed that already.) Since this is a 
non-air integrated model, there are no tanks reported, and also no 
pressure samples.

2. Air integrated model, gas switch model (Cobra2)

Gas mixes:
0: Air
1: Nx32
2: Nx36

Tanks:
0: gasmix=UNKNOWN, volume=xxx, pressure=yyy, ...

For the gas mixes and gas change events in the samples nothing changed 
at all. Because we now have an air integrated model, there will be one 
or more tanks available. The tank pressure samples do not only contain 
the tank pressure, but also the tank id. That's already the case today 
in order to support multiple tank sensors per sample, so again nothing 
really changes here.

However, due to the gas switch model, we don't have any info about which 
gas mix is associated with the tanks, so we simply leave the gasmix 
field blank (UNKNOWN). It's up to the application (or the end-user) to 
fill in the missing info. Libdivecomputer won't try to guess it.

2. Air integrated model, tank switch model (Cobalt)

Gas mixes:
0: Air
1: Nx32
2: Nx36

Tanks:
0: gasmix=0, volume=xxx, pressure=yyy, ...
1; gasmix=1, volume=xxx, pressure=yyy, ...
2: gasmix=2, volume=xxx, pressure=yyy, ...

This is a very similar case to previous one, except that due to the tank 
switch model, there is now a clear one-to-one correspondence between 
tanks and their gas mixes. So we can now link each tank with its gas 
mix. The gasmix and tank id's are in fact identical because the number 
of gas mixes and tanks are by definition identical. Thus, although a gas 
change event doesn't directly carry any info about the tank switch, you 
can easily figure that out by looking at the gas mix id in the tank 
structures.


I believe this results in a consistent api, that can be implemented for 
all types of devices, no matter how they store their tank or gas mix 
info internally.

My proposal is now as follows:

typedef enum dc_field_type_t {
     ...
     DC_FIELD_TANK_COUNT,
     DC_FIELD_TANK,
} dc_field_type_t;

#define DC_GASMIX_UNKNOWN 0xFFFFFFFF

typedef enum dc_tankvolume_t {
     DC_TANKVOLUME_NONE,
     DC_TANKVOLUME_METRIC,
     DC_TANKVOLUME_IMPERIAL,
} dc_tankvolume_t;

typedef struct dc_tank_t {
     unsigned int gasmix; /* Index of the gas mix, or DC_GASMIX_UNKNOWN 
*/
     dc_tankvolume_t type;
     double volume; /* Either wet or air volume depending on the type, 
but always in liter */
     double workpressure; /* Pressure in bar. */
     double beginpressure;
     double endpressure;
} dc_tank_t;


PS: To fix the gaschange event issue right now, we can consider adding a 
new SAMPLE_EVENT_GASCHANGE3 variant that does not contain the O2 and He 
percentages, but the gasmix index. Adding the new event doesn't break 
backwards compatibility, and thus we can slowly start porting the 
backends to this new model. Of course the downside is that applications 
that are not updated to recognize this new event will no longer get 
gaschange events from backends that already moved to the new event.

Jef