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

[Janice McLaughlin]

On Sep 12, 2014, at 5:37 AM, Jef Driesen <jef at libdivecomputer.org> wrote:

> One of the main problems here, is that most dive computers don't have any knowledge about the tanks, only the gas mixes. That's why libdivecomputer does not even try to match gas mixes with tanks. In most cases, there is simply not enough information to do this correctly. And we're not talking about some odd corner cases, but very common scenarios!
> 
> Currently, libdivecomputer can report the list of available gas mixes, and also the gas switch events in the sample data. This is a very simple model that can easily be supported by all dive computers. (I'm aware that the current api for the gas switches has a serious design flaw. It doesn't deal well with multiple identical gas mixes. But that's another story, so let's ignore that for a moment.)
> 
> For the air integrated models, libdivecomputer provides the tank pressure in the sample data. Multiple tank pressure sensors are fully supported, because each pressure is tagged with the tank id (which is just a zero based index). Because the tank pressure is fully decoupled from the gas mixes, this model also works well for all dive computers. Non-air integrated models just don't report any tank pressure.
> 
> If you want to integrate the gas mixes into the tank info, then you'll run into problems with devices that do not track tank info, but only the gas mixes. And those are still the majority of the devices. Even air integrated models typically only track those tanks for which they have a pressure sensor. The only case where you can do this correctly, are those devices that model gas switches as tank switches. Because there you have a direct association between the tank and its gas mix.

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.

> In theory it's possible that a device records tank pressure from multiple sensors at once. The libdivecomputer api supports this, and some data formats are in theory also capable of doing this, but I've never seen this in practice.
> 
> Data from a dive computer with multiple pressure sensors is difficult to find. If anyone has such a setup, I would love to get some real data from it!

FYI The Liquivision Lynx allows you to monitor the air supply of up to 10 other divers (in addition to your own) and give's pressure samples for each throughout the dive. Now, why you would want to "log" someone else's pressure samples is a good question :-) But I'm assuming that you can use some of this capacity to get pressure data from more than one of your own tanks.
> 
> The problem of not being able to detect a switch to another tank with the same gasmix is due to the fact that the gas change events carry the O2/He percentages instead of a gasmix index. This is a design flaw that I intent to fix after v0.5. It's not directly related to not having tank switches.

Seems like a good idea to instead put the gas mix id in the event.
> 
> When I read your email for the first time, I thought introducing tank change events would indeed be a good idea. But the more I think about it, the more I doubt whether that's the right solution.
> 
> For devices with a tank based switch model, and those are the ones where this info would be useful, the tank switches and gas switches will always coincide. So you kind of get this information already. You just don't know whether you have such device or not, because libdivecomputer doesn't tell you that. So maybe what we really need here is a way to tell the application that there is a one to one mapping between the tanks and the gas mixes? One property of these devices with a tank based switch model, is that the number of tanks will always be equal to the number of gas mixes. Maybe that's something the application can use for that purpose?
> 
> Also, assuming we introduce tank switch events in the samples, then the application still has to work out which gas mix is associated with a particular tank. But even while this association is fixed for the entire dive, you'll have to this by manually processing the tank and gas switches in the samples. That's a bit odd if you ask me. It also means you'll only be able to do this for those tanks and gas mixes that have been used on the dive. Maybe it's a better idea to include the id of the gas mix in our tank structure?
> 
> struct dc_tank_t {
>   unsigned int gasmix;
>   ...
> };

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.

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

This would mean that none of the applications would need to change much. I think that each application that is using libdivecomputer will also have their own model for how they communicate this information to the end user. I think if libdivecomputer gives more "hints" about the DC itself and how it works, then it gives the application more flexibility on how to give the information to the end user and map it to their own data model.

>> I have a USB analyzer that I needed for my driver work. If someone can
>> deliver one of these units into my hands, I'd be happy to take a look
>> and take some traces. And we could go from there.
> 
> For capturing USB communication there are also software solutions. That's basically what I have been doing all those years for serial communication. It's certainly a bit more practical than having to send an (expensive) dive computer. But if the owner doesn't mind doing that, that's certainly also an option.

You've done this enough that perhaps you could write a new backend for a new device simply based on some USB traces. I just meant that *I* could not do this :-) There was talk of trying to get more people to contribute to the project and so if I were to contribute a new backend to libdivecomputer, I could reverse engineer it but I would also  need one in my hands to test with.

Janice