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

[Janice McLaughlin]

On Sep 16, 2014, at 11:26 AM, Jef Driesen <jef at libdivecomputer.org> wrote:

> On 2014-09-14 04:03, Janice McLaughlin wrote:
>> My thought was not to replace the existing Gas Switch model at all,
>> but just to add the tank model for those dive computers that it makes
>> sense for. So perhaps a ostc and Shearwater return 1 or 4(8) for
>> DC_FIELD_GASMIX_COUNT and return 0 for DC_FIELD_TANK_COUNT. And they
>> would continue to put gas switch events, (with id's probably to fix
>> the problem you reference) in the sample stream. But an eg: Atomic
>> would return 0 for DC_FIELD_GASMIX_COUNT and would return 3 for
>> DC_FIELD_TANK_COUNT. And the corresponding dc_tank_t would have the
>> tank capacity (where this all started) and starting and ending
>> pressure in it, just like the DC itself does. All of the DC's that
>> support a tank model seem to have all of that information available
>> about each tank, including gas mix.
> 
> That's not entirely correct. There are also air-integrated dive computers, that support gas switches, and also record tank pressure, but which do not follow the tank switch model.
> 
> Take for example the Suunto Cobra 2 (just to name one). It's an air integrated model (hose), which supplies tank data in the sense that it records tank pressure, but without any info about the tank size. Being a hose based model, it can of course only support a single tank sensor. It also support multiple gas mixes, and the gas switches are recorded using the gas switch model.
> 
> So in this case, you can't really replace DC_FIELD_GASMIX with DC_FIELD_TANK, because there are more gas mixes than tanks. Of course those extra gas mixes are also stored in a tank, but we just don't have any info about that. We don't even know which gas mix is in the tank connected to the tank sensor. Most likely it will be the main tank, and the other gas mixes will be some deco mixes in stages. But we can't guarantee that. So the DC_FIELD_TANK is still needed for the tank pressure, but there should be no gasmix inside.
> 
> That's the main reason why I proposed to keep the DC_FIELD_GASMIX as the main (and only) interface for the gas mixes. The DC_FIELD_TANK would be an optional interface for devices which also provide some info about the tank (tank pressure, tank size, etc). And if the exact gas mix is known (e.g. for tank switch based devices, or if the device provides this info in some other way), you would also get its id there. Thus there is no need to also include the actual O2/He percentages in the dc_tank_t structure.
> 
> With my proposal, the cobalt parser would return the same value for both DC_FIELD_GASMIX_COUNT and DC_FIELD_TANK_COUNT (note that the newer cobalt 2 supports more than 3 gas mixes). The gasmix field in the dc_tank_t struct would contain the id of the corresponding dc_gasmix_t structure.
> 
> 
>> 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?

>>> When we don't have enough information to provide this info, we set the field to some predefined value to indicate "unknown". Unfortunately we can't use zero here. The gasmix index is zero based, so zero would be a valid value. But something like 0xFFFFFFFF should do:
>>> #define DC_GASMIX_UNKNOWN 0xFFFFFFFF
>>> The key point here is that we keep the gas mixes outside the tank structure. We need that in order to support devices that don't track tanks. But for devices where there is a known one to one mapping between tanks and gas mixes, we can also provide this info to the application.
>>> (I'm just thinking aloud here, feel free to join!)
>> 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.

Janice