dealing with unused tanks

[Jef Driesen]

On 28-12-12 15:14, Dirk Hohndel wrote:
> Jef Driesen <jefdriesen at telenet.be> writes:
>> On 28-12-12 09:20, Jacco van Koll wrote:
>>> I would like you to remember that there are 1st stages, who 'leak'  air/gas
>>> on purpose. The longer the dive is, the more air/gas leaked away. So, in
>>> certain circumstances, this could lead to measurable differences in
>>> pressure, letting software think that the tank is used.
>>
>> The gas mixes and tank pressures are two different things. At the
>> libdivecomputer level we treat them as completely independent because we usually
>> don't have enough information to match gas mixes with the correct tank. For
>> example if you have an air integrated model, you usually get tank pressures for
>> just one tank (because there is only one pressure sensor). But the device can
>> still support multiple gas mixes, and report gas switches.
>
> This is an area that Linus and I discussed yesterday while driving to
> our class... right now our code muddles that distinctions a tiny bit
> (and that's mostly my fault as I made some assumptions based on the way
> the Uemis SDA handles gas switched). But what Jef says is correct and is
> the way to think about it:
> a) you have an active gas. and you switch between active gasses. And all
> the gas mixtures that are active at some point are the set of "used
> gases" (for some reasonably definition of "gas used on a dive").
> b) you have tank pressure information. On most dive computers you have
> none (not air integrated or no pressure sensor connected) or data for
> one tank only, even if the dive computer supports more tanks. That's the
> case with the air integrated Suuntos for example. Or the Atomics
> Cobalt. So you only ever have tank pressure information for one gas,
> even if you switch away from that tank to a different tank (or, even if
> you never switch to that tank in case you have the pressure sensor
> connected to one of your stage tanks). The Uemis SDA is one of the
> exceptions as it can indeed reed from three wireless transmitters and
> can track pressures for the three different gases that it supports -
> assuming you have three transmitters. I am still waiting to get at least
> a second one so I get a better idea of what data it actually stores in
> that case...

I believe some Oceanics even have a feature to monitor tank pressure from your 
buddy. In that case the tank pressure has no relation with your gas mixes at 
all. I don't think I have ever seen data from such a device.

For the multiple pressure sensors, I think most devices only record a single 
tank pressure value in the samples. Thus you only get data for the active tank. 
If you switch tanks, you no longer get any pressure data from the previous tank. 
Of course there might be devices that store pressure data from all sensors 
simultaneously, but I don't think I have ever seen that so far.

It makes sense to record the tank pressure this way. In practice there are very 
few cases where you are actually using multiple tanks at the same time (e.g. 
buddy breathing).

>> If you dig into the details, there are some devices that have a number of gas
>> mixes defined, together with a flag to mark a gas active/inactive (e.g. can be
>> switched to during the dive). Currently libdivecomputer doesn't take into
>> account such flags. This is in fact one reason why libdivecomputer returns bogus
>> percentages, because some devices uses an invalid percentage (for example a 0xFF
>> byte) to mark a mix as inactive.
>
> And some of them don't record this in the downloaded data at all. The
> current firmware of the OSTC is an example for that (but based on
> discussions with Jef and me, H&W may fix that in a future firmware
> version).

If the info isn't there, then we can't take it into account either. That sucks, 
but there isn't much we can do about it :-(

Luckily some manufacturers like HW (and they are not the only ones) do take into 
account feedback!

>> But even if a gas mix is marked active, it's not necessary used (as in switched
>> to that gas) during the dive. That can be because the device always stores the
>> full set of gas mixes, regardless of whether they are actually used or not (this
>> is very common and almost all devices work like this), or it might be that the
>> diver carried a tank with that gas, but never switched to it. The problem is
>> that we can't tell the difference between those two cases. If we decide to only
>> report mixes that are really used during the dive (because there are gas
>> switches for it), then that works well for the first case, but not the second
>> case. In the second case the unused gas mix would get dropped. The question is
>> now whether this is acceptable or not? If I'm not mistaken, this is exactly the
>> issue Dirk wanted to raise too (@Dirk: correct me if I'm wrong on this).
>
> Absolutely correct.
>
> My logic here is that this will be correct for the vast majority of
> cases; I would bet that there are a thousand times more recreational
> divers that have a computer that reports gases that they may have
> configured when playing around with their computer, or that may even be
> configured by default, but who will never ever dive with more tank, than
> there are tec divers who carry an extra stage tank that for some reason
> they never switch to. This of course doesn't take CCR divers into
> account (who bring bail out tanks to every dive and hope never to have
> to switch to those except for training purposes). But again, the ratio
> of recreational divers to CCR divers is quite huge...
>
>> I believe this isn't a major problem, because I assume the gas mixes that are
>> actually used during the dive are the most important ones.
>
> I completely agree. So this is the direction I think I want to go with
> that...
>
> The question is: should I simply rely on libdivecomputer doing this, or
> should Subsurface do that itself?

Well, I think the active/inactive flag (if available) should definitely be taken 
care of at the libdivecomputer level. I'm pretty sure everyone will agree on that.

The used/unused part is another story. Jan already pointed out a legitimate 
use-case where dropping unused gases would be undesirable. If we move the 
used/unused logic into libdivecomputer, then unused gases are permanently 
dropped, and there is no way to get them back. If it's done at the application 
level, then the user or applications still has a choice here.

So I'm not sure what's going to best way. Maybe we can treat CC dives different 
here? I guess OC tec divers are less likely to carry "spare" mixes, only extra 
gas volume for emergency situations. But I could be wrong on that.

Jef