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

[Jef Driesen]

On 22-08-14 16:21, Dirk Hohndel wrote:
> On Fri, Aug 22, 2014 at 03:53:05PM +0200, Jef Driesen wrote:
>> On 2014-08-22 13:29, Calle Gunnarsson wrote:
>>> And implemented this for Cressi Leonardo, see the attached patches.
>>
>> Calle's patch uses a double for the temperature, which I think is fine. I
>> remember that a while ago there was some discussion about defining the exact
>> meaning of such temperature field. Keep in mind that not all dive computer
>> store the same kind of temperature value(s). Some may record the minimum or
>> maximum temperature, the temperature at maximum depth, etc. Others may even
>> record several values. I think trying to support all these variants will
>> quickly end up in a mess, so I'm fine to provide just a single value without
>> attaching any particular meaning. Of course the interpretation will always
>> be fixed within a particular backend, but temperature values from different
>> backends may have a slightly different interpretation.
>
> I will repeat my earlier comment that that's disappointing.
> There is no way an application can now how these temperatures are defined.
> Isn't that what libdivecomputer tries to do, to take away the need for the
> application to worry about which dive computer was used?
>
> I'd love if we could add a flag with at least three value:
>
> - TEMP_IS_LOWEST_TEMP
> - TEMP_IS_AT_DEEPEST_POINT
> - TEMP_IS_OTHER
>
> I know from diving with multiple dive computers that at least some single
> temperature Suunto dive computers use the "at deepest point" logic, while
> some my old Mares appears to log the lowest temperature.

I certainly don't mind a solution where the exact interpretation is better 
defined then in my simple proposal. That's exactly why I brought up this 
discussion again. I would like to get some feedback from the application 
developers on what they need for their application. And then we can work out 
something from there.

One of the main reasons I'm not really in love with the flags you propose, is 
that it doesn't really solve the problem that some dive computers store multiple 
temperature values. Which one should libdivecomputer pick then? What if your 
application really wants the minimum temperature, but libdivecomputer decided to 
pick the maximum temperature? If you would just ignore the flag, then why do you 
need it in the first place? If you discard the temperature if it doesn't have 
the right flag, then your users will likely complain about the missing 
temperature. So yes, the flags does give you some extra info, but I doubt it 
will be very useful in practice.


Anyway, let's approach the problem from a different side. I spend the evening 
collecting some info about which type of temperature(s) dive computers record by 
looking at the data displayed by the manufacturers application. Not everything 
has been reverse engineered, but this should provide a good insight of what is 
likely stored in the data. This is what I found:

Suunto DM3: maxdepth, begin, end
Suunto DM4: maxdepth

For the vyper family, I can confirm the temperature at maxdepth, begin and end 
of the dive is stored in the data. For the newer vyper2 and d9 I don't know. But 
these models store a full temperature profile, so the header value is less 
interesting. Suunto DM4 just shows less information than the older DM3.

Mares DiveOrganizer: min, max
Mares Iris/Drak: min

The DiveOrganizer app supports the iconhd family devices, while the Iris and 
Drak app supports the older nemo and puck family. For the iconhad family, both 
the min and max values are stored in the data. And if my info is right, the 
older models only store the min temp.

Cressi PCLogbook: unknown
Zeagle DiveLogbook: unknown

These Seiko based applications just show a temperature value, and don't give any 
indication of the type. I also don't know how and where it's stored in the data. 
Most likely somewhere in somewhere in the header, because there is no full 
temperature profile.

Cressi Pc Interface: min

This is the application for the leonardo family. And also the one for which 
Calle provided a patch.

Scubapro Logtrak: min, max
Uwatec Smartrak: min, max
Uwatec Datatrak: min, air?

For the smart and meridian family the applications show min and max temperature. 
This matches with the reverse engineered documentation. These models also have a 
full temperature profile. For the older aladin/memomouse family, the application 
shows min and air temperature, but after downloading dives, the air temperature 
isn't filled in, so it might be just a field for manual entry by the user. The 
docs indicate there is a temperature at the start of the dive if the dive has 
profile data (which is not always the case).

Oceanic Oceanlog: min

Application shows min temperature. No idea whether it's stored in the data or 
not. I suspect it is, but with oceanic you never know. With the exception of a 
few models, they also have a full temperature profile.

Shearwater: none
Atomics Cobalt: begin
OSTC2/3: min

These are the ones for which we have official documentation. What I indicate 
above are the values stored in the header, but they all have a full temperature 
profile too (note that for the ostc the sample temperature can be disabled by 
the user).

Wlog: min, air
Diving Log: air, water
Subsurface: air, water
Diveboard: surface, bottom
Jdivelog: surface, water

These are some of the existing general purpose applications. They all seem to 
support a surface and water temperature. (Air and bottom are essentially the 
same thing, just a different name.) I assume this is a good indication of what 
most user expect to see in a logbook application independent of the dive 
computer manufacturer.

To summarize, we have 5 different variants:

  * minimum
  * maximum
  * at begin
  * at end
  * at maxdepth

The first two need very little further explanation. The minimum temperature is 
definitely the most common variant. I assume one of these values is also what 
most people will record as the water temperature in the general purpose logbook 
applications? Although I haven't come across a general purpose application that 
supports both minimum and maximum water temperature, I can see the value in 
supporting these two subtypes.

The temperature at begin and end of the dive are a lot less common (Suunto, 
Cobalt and maybe the old Uwatec Aladins). I think they are also among the least 
useful variants. The temperature sensors in most dive computers are very slow 
and need a significant amount of time (in the order of several minutes) to adapt 
to changing temperatures. So the temperature at the start of the dive will not 
be the water temperature, but the air temperature. I guess the reason why people 
want to log this, is because it gives an indication of the weather conditions 
and maybe also the difference with the real water temperature? But what's the 
purpose of the end temperature?

The temperature at maximum depth is a Suunto only thing. In practice this will 
be roughly equivalent to the minimum temperature, because due to physics laws, 
the coldest temperature is usually found at the greatest depth. I know there are 
exceptions, but for 99% of the dive sites this is probably correct. So either 
not supporting this one, or mapping it to the lowest temperature, is not 
unreasonable I think.

That brings us down to 3 different temperatures worth supporting: surface 
temperature, minimum and maximum water temperature.

This corresponds nicely with the values that the existing general purpose 
applications are using. Except that we distinguish between minimum and maximum 
water temperature (if available). In case only one water temperature is 
available, we could even return the same value for min and max. For devices with 
a full temperature profile, min and max can easily be calculated from there if 
absent in the header (note that I don't intend to implement that part for now, 
because the header value is most useful for devices which don't have a full 
temperature profile, so this is lower priority.)


For the api, maybe we can stick to the DC_FIELD_TEMPERATURE with a single double 
value, but use the flag parameter of the dc_parser_get_field function to specify 
the subtype:

typedef enum dc_temperature_t {
    DC_TEMPERATURE_SURFACE,
    DC_TEMPERATURE_MINIMUM,
    DC_TEMPERATURE_MAXIMUM,
} dc_temperature_t;

In the application you would call like this:

dc_parser_get_field (parser, DC_FIELD_TEMPERATURE, DC_TEMPERATURE_XXX, &value);

What do you think?

>> 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.

I'll leave this part for another time, because I'm running out of time now.

Jef