Problems with gases on Shearwater

[Linus Torvalds]

On Wed, Dec 5, 2018 at 8:18 AM Long, Martin <martin at longhome.co.uk> wrote:
>
> 1) I just imported 4 dives from last weekend, all CCR. The first 3
>    were on 13/60 diluent and the last one on 15/57. However, it put
>    all of the divers in as 15/57, which seems to just be the last
>    diluent set. The Shearwater cloud software does identify the
>    correct gas used at the start of the dive.

Hmm. We clearly do something wrong, presumably in libdivecomputer
(although it could be some gas mixup in subsurface too, but unlikely).

Just to clarify: did you have both 13/60 and 15/57 _programmed_ on the
Shearwater for all four dives, but you then activate one of the two
before the dive?

The way this all works in libdivecomputer:

 - the shearwater never really gives us a set of cylinders at all.

 - instead, each sample contains "current gas mix"

 - as the current gas changes, we look it up in the previously seen
gas mixes, and if not seen we give it a new cylinder number

In other words, the first gas mentioned in the log always ends up
being gas 0, then the next one is gas 1 etc.

But what we don't have is any knowledge of what gas the *shearwater*
considers gas 0/1/2.. and in particular we don't know how it
associates gases with transmitters.

I don't see how/why we'd get the gas mix wrong for your four dives, though.

Anyway, we do have some documentation from Shearwater, and I think it
should be possible to get the proper "these are the cylinders".

I'll just have to read it and understand it. Dirk, who actually did
the new Shearwater format (and thus probably knows it better) is off
gallivanting with real work in Asia right now, so he probably won't be
able to do much, even though he's probably a better person for it.

> 2) I'm using two transmitters on a Perdix AI. Transmitter 1 is on my
>    diluent, and transmitter 2 on my oxygen. On import it seems to
>    correctly associate my transmitter one with the diluent (apart from
>    the error in 1 above). Now, providing I don't do any gas switches
>    (e.g. a bailout) then transmitter 2 I can simply set up as 100% O2.
>    However, if I do a gas switch, the software automatically assigns
>    this gas switch to cyl 2, and so it becomes associated with the
>    transmitter data.

This is how the libdivecomputer cylinder pressure parsing works, but
we didn't know any better. The Shearwater gives us two pressures, and
we assume that the first pressure is for tank 0, and the second
pressure is for tank 1.

We have no logic to associate pressures with any other cylinders, and
I don't really know what the logic would be. But see above. Getting
the cylinder index right would probably fix things properly.

So I will look into it.

> I now have 2 choices... Either I can enter a new gas of 100% and
> manually type the start and end pressure - however I cannot remote it
> from cyl 2. Or, I can set cyl 2 as 100%, and add a new one for my
> baiout gas. However this then means the cylinder swtich then points at
> the wrong gas, and will say I switched to 100% on my bailout!

Right. These problems are related. You can't remove the second gas,
because it's mentioned as a gas switch target. And when you add the
new gas, it doesn't fix the gas switch target.

What you can do - and which will fix both issues - is to simply edit
the gas switch. You can do it either the hacky way (just edit in the
xml file or in the git repository by hand), or you can do it in the
GUI on desktop by adding a new gas switch and then removing the old
one.

But there's a downside: playing games with gas switches can also
confuse subsurface in what the pressure data is. So you may lose the
pressure data unless you are very careful (again, doing this by hand
if you know exactly what you're doing is possible, but it's all kinds
of crazy so I can't really recommend it).

> I don't have a solution to this. As the import process has no manual
> intervention, it would be tricky to have a solution which works. My
> suggestion would be to treat transmitters and gas swtiches as
> completely separate cylinders, and then allow the user to "merge" them
> later. The current assumption that transmitter 1 will be the first
> gas, and transmitter 2 will be the next one is incorrect.

Well, we should just get the mapping right and not have this problem,
but neither I nor Dirk has ever really used the Perdix AI with
multiple cylinders.

Let's see what I can do.

                       Linus