Log import of Trimix dive from Shearwater Teric

Jef Driesen jef at libdivecomputer.org
Mon Oct 11 05:43:45 PDT 2021 

On 8/10/2021 21:53, Linus Torvalds via subsurface wrote:
> But your data clearly has
> 
>    <cylinder size='22.2 l' workpressure='232.0 bar' description='D12
> 232 bar' o2='14.0%' he='49.0%' depth='65.378 m' />
>    <cylinder size='4.1 l' workpressure='206.843 bar' description='AL40'
> start='220.0 bar' end='140.0 bar' depth='103.075 m' />
>    <cylinder size='5.547 l' workpressure='206.843 bar'
> description='AL40' o2='51.0%' start='200.0 bar' end='140.0 bar'
> depth='21.021 m' />
>    <cylinder size='5.547 l' workpressure='206.843 bar'
> description='AL40' o2='79.0%' start='175.0 bar' end='90.0 bar'
> depth='10.016 m' />
> 
>    <event time='0:02 min' type='25' flags='1' name='gaschange'
> cylinder='0' o2='14.0%' he='49.0%' />
>    <event time='3:26 min' type='25' flags='2' name='gaschange' cylinder='1' />
>    <event time='30:32 min' type='25' flags='3' name='gaschange'
> cylinder='2' o2='51.0%' />
>    <event time='44:40 min' type='25' flags='4' name='gaschange'
> cylinder='3' o2='79.0%' />
> 
> which I agree is insane - you are going down to 82m and subsurface
> thinks you're breathing air at the deepest point (and breathing that
> hypoxic 49% He at the beginning shallow part).
> 
> That would be unhealthy and bad if real. I agree that clearly the two
> first gases are switched.
> 
> However, subsurface thinks that because those are the gas switch events we got.
> 
> And I have to say, when I tell subsurface to use the same 55/85
> Buehlmann settings that your dive computer reports it is using, the
> deco that subsurface calculates isn't actually that far off from what
> your Teric calculated. In fact, if anything, your Teric gave _more_
> deco at the end.
> 
> That said, that can't be real, and I suspect the issue is that I only
> see the one dive, and you presumably had some pre-existing deco
> loading, and then subsurface getting the gases wrong just happens to
> result in a fairly similar deco profile.
> 
> ANYWAY.
> 
> The gas confusion is clearly real, but I think it comes from some
> cylinder numbering confusion during the download.
> 
> I *suspect* it is because libdivecomputer has this horrendous model of
> "gases vs cylinders" being different. So libdivecomputer has a "gasmix
> index" and a "cylinder index", and the two can be different.
> 
> Which is INCREDIBLY broken by libdvicecomputer, because it means that
> if two cylinders have the same gas mix, the "gas switch" cannot tell
> them apart, because it uses the "gas index".
> 
> Subsurface gets rid of that libdivecomputer confusion, and just has a
> cylinder index, and each cylinder has a gas mix. Two cylinders having
> the same gas isn't a problem, and isn't a reason to have a separate
> "mix index" that only causes confusion.
> 
> But it's very possible that this impedance mismatch between subsurface
> and libdivecomputer then causes oddities if/when libdivecomputer does
> something strange.
> 
> IOW, maybe libdivecomputer called "air" gasmix 0, and your trimix is
> gasmix 1. But then it puts gasmix 1 in cylinder 0 and vice versa, and
> confuses subsurface that doesn't do that kind of crazy thing.
> 
> And with most people carrying just one gas, we don't see this mismatch
> very much (plus it quite possibly also depends on how you defined your
> gases on your teric)
> 
> I feel like a lot of the libdivecomputer interfaces are really quite
> broken, and go back to how old dive computers reported the data, not
> to anything that makes any real conceptual sense. So libdivecomputer
> treats "gasmix" as a primary thing, because if you don't have a
> pressure sensor and air integration, the only thing that matters for
> deco calculations is the mix, not which cylinder it came from.
> 
> And then libdivecomputer learnt about newer dive computers where you
> can set cylinder sizes, and where you can have air integration, and
> suddenly it matters which _cylinder_ you breathe from, but
> libdivecomputer had that insane notion of "gasmix is gasmix, not
> cylinder", and then you end up with two different concepts entirely.
> 
> And the libdivecomputer interfaces are bad in another way too: the way
> it reports gas changes is literally by giving that index into that
> "gasmix array" it has. But the Teric doesn't report gas switches that
> way: it reports them as the actual gas you switch to. So then
> libdivecomputer translates the real gas mix into an index, and that
> index may not be the same as the cylinder index it used elsewhere.
> 
> No wonder we get confused. But again - in most cases this won't ever
> even show up.
> 
> Some of the more modern backends (eg Suunto EON Steel) avoid this
> whole confusion entirely, and only have one notion of
> cylinder-vs-gasmix (ie every gasmix has exactly one cylinder
> associated with it, and the gasmix-vs-cylinder confusion just doesnt'
> exist).
> 
> But the shearwater parser is old and crufty and has grown organically over time.
> 
> Just to give an example of *how* odd liobdivecomputer is: the
> shearwater parser not only thinks that gasmixes and cylinders are
> different things, you can have up to 10 gas mixes, but you can only
> have up to 2 cylinders.
> 
> Just think about that kind of insanity. You can make excuses for it
> ("yeah, I only carried two cylinders, but I was breathing off eight
> buddies"), but in the end it really is just about libdivecomputer
> confusion, and often "random dive computer XYZ describes it this way,
> so we'll perpetuate the confusion".
> 
> I'll think about this a bit more to see if I can come up with
> something, but I hope I have explained why it can be hard due to
> libdivecomputer explicitly making it hard.


Why do you blame libdivecomputer for this, when it's actually (some of) the dive 
computers that are using this model with separate tanks and gas mixes? Because 
that's the only reason why libdivecomputer does report it that way.

Take for example the Shearwater. It supports up to 10 different gas mixes, but 
only 2 tank transmitters (or 3 with the latest firmware update). During the dive 
it reports the active gas mix, and pressure data from all transmitters. But 
there is no information to link the two together. Suppose you're diving with 3 
gas mixes, and 2 transmitters. How am I supposed to know how many tanks were 
used, and which gas mix was in each one of them? That information is simply not 
there. Most likely there are at least 3 tanks (e.g. one for each gas mix). But 
which ones have the transmitter attached? Again, that information isn't there. 
You can probably do an educated guess when analyzing the pressure graph. The 
transmitter showing a pressure drop is most likely the currently active tank. 
But such analysis is outside the scope for the libdivecomputer parser and also 
not entirely foolproof. Pressure can drop even when you're not breathing from it 
(temperature changes, inflating BCD), etc. There might as well be 4 tanks, with 
two tanks containing the same gas mix (e.g. sidemount). The truth is that only 
the diver has the correct answer here!


Let me illustrate with a real-world example. Attached is a dive downloaded from 
a Shearwater Perdix AI. This dive contains 2 gas mixes (Air and EAN48) and 2 
transmitters. At first sight, you would conclude this is dive with two tanks, 
one with air, and one with EAN48. That's indeed exactly how subsurface imports 
this dive. See the attached subsurface.xml file and the corresponding 
screenshot. But that's also completely wrong! If you take a closer look at the 
sample data, you'll see the dive starts with Air, and the pressure in tank 0 
starts dropping. This continues until about 08:20. At that point, the pressure 
in tank 0 remains constant (with some minor fluctuations), and the pressure in 
tank 1 starts to drop now. Note that there is no gas mix change here! The switch 
to the EAN48 mix only happens at 19:50, at which point the pressure in both tank 
0 and 1 remains constant until the next gas switch back to air at 34:30. So the 
conclusion here is that tank 1 is NOT the EAN48 tank! If you ask me, this looks 
like a side mount dive with two Air tanks and one EAN48 tank. But unfortunately 
that information is simply not present in the data! It only becomes visible 
after a detailed analysis of the dive. See the attached files for the manually 
fixed result.


Libdivecomputer simply doesn't try to guess and fill in missing information. It 
just represents the information that is there. That's why tanks and gas mixes 
are reported separately. Not because I think that's the best or correct 
representation, but because I can't give you information that I don't have.

In the example above, that means giving you the pressure data from two 
transmitters, the two gas mixes and all the gas switches. Nothing more, nothing 
less. Trying to link the two together, might result in incorrect information, so 
that's not an acceptable option.


There are indeed also dive computers that nicely link tanks to their gas mixes. 
And in that case libdivecomputer will also give you that information: the 
tank->gasmix field for each tank will contain the index of the corresponding 
gasmix. Note that you should look at this field, and not just assume that the 
tank index and gasmix indexes will match. Often that will be the case, but not 
always. I suspect that's exactly where things go wrong in subsurface, because it 
does seem to make that assumption in order to "merge" the tanks and gas mixes.

You are correct that this isn't the nicest or most convenient representation, 
but it's needed to support those dive computers that use this model and don't 
provide enough information to connect the dots together.

For a logbook application having the two linked together makes perfect sense, 
because of course you need a tank to carry a gas mix. But for a dive computer 
that link isn't strictly needed. For calculating deco only the gas mix is 
needed, and for most air integration features (e.g. showing tank pressure during 
the dive, calculate remaining gas time, etc) the current gas mix doesn't really 
matter. So for a dive computer the separate model makes sense too, and that's 
probably why many dive computers also use it.

Jef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dctool.xml
Type: text/xml
Size: 68208 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20211011/651dccb4/attachment-0003.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subsurface.xml
Type: text/xml
Size: 22318 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20211011/651dccb4/attachment-0004.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subsurface-fixed.xml
Type: text/xml
Size: 22370 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20211011/651dccb4/attachment-0005.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subsurface.png
Type: image/png
Size: 153738 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20211011/651dccb4/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subsurface-fixed.png
Type: image/png
Size: 159366 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20211011/651dccb4/attachment-0003.png>

More information about the subsurface mailing list