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