Understanding cylinder creation and assignment on CCR

[mwe...@gmail.com]

First time back in the water after nearly a year with 3 dives on a Triton mCCR. This CCR is dived with a small onboard cylinder of O2, and a combined offboard Diluent/bailout cylinder of usually air. On the third dive I also took along an additional offboard  bailout cylinder of EAN51.

My Triton does not have any AI, nor does the Petrel attached to it.

The only AI transmitter on all the dives was on my diluent bottle, and my backup computer was reading the pressure (Perdix AI).

After downloading the dives using my phone (Android Subsurface  3.4.8), each dive showed up with 3 cylinders, all of which were incorrectly assigned. Fair enough, Subsurface isn't a mind reader and I'm aware of the 1:1 mapping of cylinders and sensors in the order they are received.  IMHO as soon as there are multiple cylinders and sensors, there needs to be a way for the user to define which sensor belongs to which cylinder instead of the software "guessing" it.

I later opened up the data on my desktop for actually writing up the dives etc (Linux Subsurface 5.0.10), and two of the cylinder cannot be deleted in the UI. I believe I mentioend this before, but I strongly disagree with blocking the user from deleting/modifying things. The user knows best, and if they stuff up, they can always revert. At the very least the software should provide an indication of why it thinks a particular cylinder can't be deleted.

Manually opening up the files, the "Dive" file contains definitions for 4 cylinder, even though only 3 are shown in the UI. All bottles are marked as "diluent" (information which is not exposed in the UI). The dive computer log files are as expected - the Perdix one has the AI data for my diluent tank, and the Petrel one has the O2 sensor data.

So... where do all these cylinder definitions come from in the first place?

Why does subsurface believe some cylinders are being used and blocking me from deleting them when there's no sensor or other data for them, and conversely allowing me to delete the only cylinder which actually does have sensor data?

This is somewhat annoying if I need to manually sort this out after every CCR dive moving forward; I can't remember this happening last year (although that is a fair while ago).


PS. I just looked up the original import data, and each dive log started off with  _6 cylinders_ as directly imported!!

My Petrel and Perdix were both configured in CCR mode, with a single bailout of "Air" on the first two dives, and a bailout of "Air" and one of "51%" on the last dive. So _at most_ I would expect 4 cylinders if CCR mode "magically" creates the "standard" O2/Dil onboard cylinders, and Subsurface automatically added the configured (but unused) bailout cylinders as additional cylinders.

Example (last dive, CCR mode, 3 physical cylinders, and onboard O2, an offboard diluent/bailout of Air and a bailout of 51% configured); after downloading the Perdix AI data:
>>>

+duration 78:10 min
+cylinder vol=10.0l description="10.0ℓ" o2=99.0% depth=6.026m
+cylinder vol=10.0l description="10.0ℓ" o2=51.0% use="diluent" depth=21.227m
+cylinder vol=10.0l description="10.0ℓ" o2=32.0% use="diluent" depth=39.845m
+cylinder vol=10.0l description="10.0ℓ" use="diluent" depth=66.019m
+cylinder vol=10.0l description="10.0ℓ" o2=99.0% use="diluent" depth=6.026m
+cylinder vol=10.0l description="10.0ℓ" use="diluent" depth=66.019m

<<<

This looks like it is creating a cylinder for ALL configured gases, whether they are "on" or "off" from the dive computer - a total of 2 gases for CC mode, and 4 for BO mode.

After downloading the data from the Petrel,  two cylinders were deleted for no apparent reason, but still leaving me with more than I physically actually have:

>>>

-duration 78:10 min
+duration 78:00 min
 cylinder vol=10.0l description="10.0ℓ" o2=99.0% depth=6.026m
 cylinder vol=10.0l description="10.0ℓ" o2=51.0% use="diluent" depth=21.227m
-cylinder vol=10.0l description="10.0ℓ" o2=32.0% use="diluent" depth=39.845m
 cylinder vol=10.0l description="10.0ℓ" use="diluent" depth=66.019m
 cylinder vol=10.0l description="10.0ℓ" o2=99.0% use="diluent" depth=6.026m
-cylinder vol=10.0l description="10.0ℓ" use="diluent" depth=66.019m

<<<

Thank you,

 - Micha.

[Jef Driesen]

On 5/07/2023 00:14, mwe...@gmail.com wrote:
> Manually opening up the files, the "Dive" file contains definitions for 4
> cylinder, even though only 3 are shown in the UI. All bottles are marked as
> "diluent" (information which is not exposed in the UI). The dive computer log
> files are as expected - the Perdix one has the AI data for my diluent tank, and
> the Petrel one has the O2 sensor data.

There is an option in the settings: Equipment -> Show unused cylinders in the
Cylinders table of the Equipment tab.

The shearwater computers don't record whether a gas mix is on or off, so
libdivecomputer will always return all configured gas mixes.

If you send me the libdivecomputer log of the download from your Petrel and
Perdix, I can have a closer look at your data:

http://libdivecomputer.org/subsurface.html#desktop-dives

Jef

[Michael Keller]

Hi Micha.


Fully agreed with Jef's statement about part of this being caused by the
limitation in Shearwater's protocol that the enabled / disabled
information for individual gasmixes is not transmitted when downloading
dives. I suspect that the cause for this might be that Shearwater
computers did not support enabling / disabling gasmixes way back when
the protocol was specified. But feel free to open a support request with
Shearwater and ask them to add this information to their protocol - how
are they supposed to know what features their customers are missing in
their products if nobody tells them.

On 5/07/23 10:14, mwe...@gmail.com wrote:
> IMHO as soon as there are multiple cylinders and sensors, there needs
> to be a way for the user to define which sensor belongs to which
> cylinder instead of the software "guessing" it.

Fully agreed. Nobody has designed a UI and implemented functionality for
this yet. Any volunteers wanting to help with this is welcome.

> I later opened up the data on my desktop for actually writing up the
> dives etc (Linux Subsurface 5.0.10), and two of the cylinder cannot be
> deleted in the UI. I believe I mentioend this before, but I strongly
> disagree with blocking the user from deleting/modifying things. The
> user knows best, and if they stuff up, they can always revert. At the
> very least the software should provide an indication of why it thinks
> a particular cylinder can't be deleted.

Couple of things here (and to some extent me making educated guesses as
I do not have access to the logs for your dives):

- Subsurface prevents the user from deleting any gasmixes that were
recorded as being used during the dive. This makes sense as without this
a lot of functionality, like calculating a deco ceiling and tissue
saturations would not work;

- in the case of Shearwater dive computers, they seem to be reporting
the gas that the dive was started on by sending a 'gaschange' event with
a timestamp 2 seconds into the dive. This means that the first gas in
the list is (somewhat naively) tracked as 'being used' for the first two
seconds of the dive:


  <extradata key='PPO2 source' value='cells' />
  <event time='0:02 min' type='25' flags='7' name='gaschange'
cylinder='6' />
  <sample time='0:02 min' depth='1.5 m' temp='13.0 C' sensor1='0.629
bar' sensor2='0.617 bar' sensor3='0.641 bar' po2='0.7 bar' />


I suspect a more user friendly approach would be to be pragmatic and for
Shearwater dive computers discard the gas information for the first 2
seconds of the dive.

> Manually opening up the files, the "Dive" file contains definitions
> for 4 cylinder, even though only 3 are shown in the UI. All bottles
> are marked as "diluent" (information which is not exposed in the UI).
> The dive computer log files are as expected - the Perdix one has the
> AI data for my diluent tank, and the Petrel one has the O2 sensor data.

This has been fixed and the proper usage type will be shown in the UI in
the next release of Subsurface:
https://github.com/subsurface/subsurface/pull/3576

> So... where do all these cylinder definitions come from in the first
> place?

They are reported by the dive computers. Unfortunately another
shortcoming of the current implementation is that only a very
rudimentary attempt is made to merge gasmix information when logs for
the same dive are imported from multiple dive computers.

> Why does subsurface believe some cylinders are being used and blocking
> me from deleting them when there's no sensor or other data for them,
> and conversely allowing me to delete the only cylinder which actually
> does have sensor data?

Right now the 'cylinder' table is mostly driven by the gasmix
information, and the tank sensor information is mapped into it 1:1 -
this isn't helpful for technical diving, and should be improved.

One factor in why this has not yet been done is that it is likely that >
95% of the dives logged in Subsurface are recreational dives with 1
gasmix and (at most) 1 tank sensor, and for these dives the existing
functionality works just fime. So adding functionality that forces the
user to map gasmixes to tanks for every dive they import will make the
UX worse for > 95% of users, unless it is done in a way that 'works out
of the box' for recreational dives.

> This is somewhat annoying if I need to manually sort this out after
> every CCR dive moving forward; I can't remember this happening last
> year (although that is a fair while ago).

There was a change in how gasmix information is imported - originally
only gasmixes that were used (i.e. switched to on the dive computer)
during the dive were imported into Subsurface. This was somewhat
limiting, especially for CCR dives, as the information about what
bailout gases were carried was discarded during the import unless a
bailout happened during the dive. So this was changed, and the
preference setting to hide unused gases was introduced.


Cheers

  Michael Keller

[Michael Werle]

Thanks for your replies, Jeff and Michael.

So my take-away from the replies is:

* Shearwater doesn't distinguish whether or not a gas is "on" or "off"

* Subsurface now imports every configured gas as a cylinder

* The logic to determine whether a cylinder/gas is actually used or not is not optimal, and the program refuses to let the user delete a cylinder which it thinks is in use in order to preserve calculations which are wrong anyway in the case where a cylinder didn't even physically exist in the first place.

* The logic in Subsurface changed "recently" to import all gas mixes whether used or not in order to make it better for CCR divers to record carried-but-unused gas mixes

Fully agreed with Jef's statement about part of this being caused by the
limitation in Shearwater's protocol that the enabled / disabled
information for individual gasmixes is not transmitted when downloading
dives.

How does this explain why some gases/cylinders were then deleted from my files following import from a second dive computer for the same dives. That sounds unintended to me because these gases/cylinders were actually deleted and not just hidden.

 

But feel free to open a support request with
Shearwater and ask them to add this information to their protocol - how
are they supposed to know what features their customers are missing in
their products if nobody tells them.

Thank you for the suggestion; I will do that.

 

Fully agreed. Nobody has designed a UI and implemented functionality for
this yet. Any volunteers wanting to help with this is welcome.

Unfortunately my time is somewhat limited at present, but I can have a stab at working on a UI to match sensors to gas mixes/cylinders over winter, if nobody else has beat me to it by then.

- Subsurface prevents the user from deleting any gasmixes that were
recorded as being used during the dive. This makes sense as without this
a lot of functionality, like calculating a deco ceiling and tissue
saturations would not work;

 

I disagree here - let the user delete things which the user _knows_ to be incorrect. The user (should) know better than some heuristic of the program. Calculations based on invalid data are wrong anyway, to the point of being potentially dangerous if a user relies on them for future dive plans. There MUST be a way for a user to fix any invalid assumptions which the program has made.

I also think that it is a bug if the program lets me delete a cylinder which has pressure readings (and thus is definitely "in use"), but does not let me delete a cylinder which just has some spurious "gas change" event from who knows where which never even existed in the first place. So I'd be interested to figure out exactly where Subsurface gets the data from to determine whether  a cylinder is "in use" or not..

 

I suspect a more user friendly approach would be to be pragmatic and for
Shearwater dive computers discard the gas information for the first 2
seconds of the dive.

I guess this feeds more into the issue that Subsurface doesn't know whether a gas is actually configured to be used or not from a Shearwater dive computer?

Or is this actually information which came from the computer? In that case, it would (presumably) only issue a gas-change event for a gas which was "on"?  On all of my dives I configured both computers to only have the gases I physically carried with me as "on" - otherwise any bailout calculations would be incorrect, and yet I ended up with "used" gas mixes which simply never existed on those dives.

 

This has been fixed and the proper usage type will be shown in the UI in
the next release of Subsurface:
https://github.com/subsurface/subsurface/pull/3576

Cool! So presumably the user will also be able to edit the gas usage type?

 

One factor in why this has not yet been done is that it is likely that >
95% of the dives logged in Subsurface are recreational dives with 1
gasmix and (at most) 1 tank sensor, and for these dives the existing
functionality works just fime. So adding functionality that forces the
user to map gasmixes to tanks for every dive they import will make the
UX worse for > 95% of users, unless it is done in a way that 'works out
of the box' for recreational dives.

I see this as a non-issue. If there's only 1 cylinder and 1 sensor then the 1:1 assignment is trivial and should always happen. There's no need to (re)map anything if there are no alternative possibilities..

There was a change in how gasmix information is imported - originally
only gasmixes that were used (i.e. switched to on the dive computer)
during the dive were imported into Subsurface. This was somewhat
limiting, especially for CCR dives, as the information about what
bailout gases were carried was discarded during the import unless a
bailout happened during the dive. So this was changed, and the
preference setting to hide unused gases was introduced.

Hmm; matter of opinion here. Personally I find it easier to add an unused bailout gas than to not even be able to delete a "phantom" cylinder without manually editing the data files. But at least this explains why I can't recall having this issue before!

Room for improvement; I'll see if I can get some time to work on this, since it seems I'm the only one affected (or at least vocal) about this :)  Alternatively I don't have a problem giving people access to my data for investigation/improvement work, although I'd need to re-import the data for libdivecomputer logs. I can see about creating a standalone case data file for this with all logs etc.

--

 - Micha

"The Glass is neither half-empty nor half-full; it is twice as big as it needs to be!"

[Michael Keller]

Hi Micha.

On 7/07/23 13:39, Michael Werle wrote:

* Subsurface now imports every configured gas as a cylinder

Not quite - Subsurface imports every _active_ gasmix. As you state above, since on Shearwater computers all gases are returned with no active / inactive flag, all of them are considered to be active.

A 'cylinder' in Subsurface is an amalgamation of gasmix and tank pressure information reported by a dive computer.

* The logic to determine whether a cylinder/gas is actually used or not is not optimal, and the program refuses to let the user delete a cylinder which it thinks is in use in order to preserve calculations which are wrong anyway in the case where a cylinder didn't even physically exist in the first place.

Yes, correct, for the first two seconds of every dive downloaded from a Shearwater computer the calculations are based on a potentially invalid gas - not sure that I would agree with your conclusion that in this case that all of the saturation calculations for the entire dive become invalid because of this.

Fully agreed with Jef's statement about part of this being caused by the
limitation in Shearwater's protocol that the enabled / disabled
information for individual gasmixes is not transmitted when downloading
dives.

How does this explain why some gases/cylinders were then deleted from my files following import from a second dive computer for the same dives. That sounds unintended to me because these gases/cylinders were actually deleted and not just hidden.

It doesn't. But the explanation for this behaviour is that during the merge of the cylinders when more than one dive computer is used for the same dive only 'used' cylinders are considered: https://github.com/subsurface/subsurface/blob/90e5de83573254cd251fef243aef991d51f60d4b/core/dive.c#L1948-L1949

This could potentially be changed to be dependent on the 'show unused cylinders' setting in the preference, and include unused cylinders if this preference is enabled.

Fully agreed. Nobody has designed a UI and implemented functionality for
this yet. Any volunteers wanting to help with this is welcome.

Unfortunately my time is somewhat limited at present, but I can have a stab at working on a UI to match sensors to gas mixes/cylinders over winter, if nobody else has beat me to it by then.

Thanks!

- Subsurface prevents the user from deleting any gasmixes that were
recorded as being used during the dive. This makes sense as without this
a lot of functionality, like calculating a deco ceiling and tissue
saturations would not work;

 

I disagree here - let the user delete things which the user _knows_ to be incorrect. The user (should) know better than some heuristic of the program. Calculations based on invalid data are wrong anyway, to the point of being potentially dangerous if a user relies on them for future dive plans. There MUST be a way for a user to fix any invalid assumptions which the program has made.

I also think that it is a bug if the program lets me delete a cylinder which has pressure readings (and thus is definitely "in use"), but does not let me delete a cylinder which just has some spurious "gas change" event from who knows where which never even existed in the first place. So I'd be interested to figure out exactly where Subsurface gets the data from to determine whether  a cylinder is "in use" or not..

I think I can't quite follow you here - first you postulate that it should be possible to delete a cylinder that your dive computer reported you breathed from during the dive (albeit in your case only due to a bug in the Shearwater data import), which would result in making any saturation calculation based on actual dive data impossible. And then you postulate that you should not be able to delete a cylinder that has pressure information - even if the pressure information came from your dive buddy's or a student's tank, or from one that you used it to inflate a lift bag. Not sure where you want to go with this.

Also, can I please get you to read the warning that is shown in Subsurface for all dives planned in Subsurface:

I am struggling to understand how you seem to be willing to dive with a dive computer that is set to use a gas mix that is incorrect to the extent that the resulting decompression information is rendered invalid, but then expect to be able to somehow 'fix' the incorrect information used on the dive, and after this safely use Subsurface to plan follow up dives.

I suspect a more user friendly approach would be to be pragmatic and for
Shearwater dive computers discard the gas information for the first 2
seconds of the dive.

I guess this feeds more into the issue that Subsurface doesn't know whether a gas is actually configured to be used or not from a Shearwater dive computer?

Or is this actually information which came from the computer? In that case, it would (presumably) only issue a gas-change event for a gas which was "on"?  On all of my dives I configured both computers to only have the gases I physically carried with me as "on" - otherwise any bailout calculations would be incorrect, and yet I ended up with "used" gas mixes which simply never existed on those dives.

It's similar but different, and yes, this is what comes from the dive computer - the log 'file' header does not specify which gas was used at the start of a dive, but then at 2 seconds into the dive it reports a gas change to the initial gas that was used at the start of the dive. Subsurface naively assumes that the first gas in the gas list (ordered by O2 content on Shearwater computers) is the gas that is used from the start of the dive until 2 seconds in. This is a bug and should be fixed.

This has been fixed and the proper usage type will be shown in the UI in
the next release of Subsurface:
https://github.com/subsurface/subsurface/pull/3576

Cool! So presumably the user will also be able to edit the gas usage type?

Yes.

One factor in why this has not yet been done is that it is likely that >
95% of the dives logged in Subsurface are recreational dives with 1
gasmix and (at most) 1 tank sensor, and for these dives the existing
functionality works just fime. So adding functionality that forces the
user to map gasmixes to tanks for every dive they import will make the
UX worse for > 95% of users, unless it is done in a way that 'works out
of the box' for recreational dives.

I see this as a non-issue. If there's only 1 cylinder and 1 sensor then the 1:1 assignment is trivial and should always happen. There's no need to (re)map anything if there are no alternative possibilities..

Fair enough, thanks for putting thought into this, keen to see the pull request for the change.

There was a change in how gasmix information is imported - originally
only gasmixes that were used (i.e. switched to on the dive computer)
during the dive were imported into Subsurface. This was somewhat
limiting, especially for CCR dives, as the information about what
bailout gases were carried was discarded during the import unless a
bailout happened during the dive. So this was changed, and the
preference setting to hide unused gases was introduced.

Hmm; matter of opinion here. Personally I find it easier to add an unused bailout gas than to not even be able to delete a "phantom" cylinder without manually editing the data files. But at least this explains why I can't recall having this issue before!

Not sure I can follow your logic here - you are essentially saying that just because you are using a dive computer for which the log import in Subsurface has got a bug all users of all dive computers should be made to enter the data for their bailout tanks twice (on their dive computer and in Subsurface) - wouldn't it be a better approach to get the bug fixed and spare everybody the extra work?

Room for improvement;

Welcome to open Source! You only get what somebody is willing to put effort into. :-)

Kia mārū

  Michael Keller

[Michael Werle]

On 07/07/2023, Michael Keller <mike...@042.ch> wrote:
> It doesn't. But the explanation for this behaviour is that during the
> merge of the cylinders when more than one dive computer is used for the
> same dive only 'used' cylinders are considered:
> https://github.com/subsurface/subsurface/blob/90e5de83573254cd251fef243aef991d51f60d4b/core/dive.c#L1948-L1949
>
> This could potentially be changed to be dependent on the 'show unused
> cylinders' setting in the preference, and include unused cylinders if
> this preference is enabled.
>

Ok, thanks for the explanation. So I need to read the code in more
detail, but roughly it seems that all used gases from both computers
are added to the result, with duplicates merged. (I originally thought
it only keeps gases which are defined by both computers, but reading
the code this does not appear to be the case)

So this throws out any gases which Subsurface deems as having been
unused. But based on your other explanations, Subsurface marks all
gases defined by the dive computer as being in use, so I would have
expected _all_ gases from both computers to be in the results, with
any duplicates merged.

I guess we might need to go back and review the design goals here and
then validate that the code implements those.

Sorry; let me rewind; I think we're starting to talk at cross-purposes here.

My dive has ended up with 3 cylinders (4 in the actual data file,
although toggling the unused gases setting in the UI did not change
anything).

1) Air with pressure data (actual real cylinder; CCR diluent + bailout)
2) EANx51 (phantom cylinder; never existed in the
real world)
3) O2 (actual real cylinder; CCR onboard O2)

Subsurface allows me to delete cylinder #1. It does not allow me to
delete #2 or #3.

Now, out of all those cylinders, only #1 has _real_ data (the pressure
sensor data) attached to it. #2 and #3 are only from the configured
gases on my Shearwater (according to explanations from this thread).

Now, my personal impression is that of those 3 cylinders, if any,
Subsurface should only prevent me from deleting #1, since it has
actual data attached to it. Instead, it only pops up a warning that
deleting it will delete the attached sensor data as well.

#2 and #3 Subsurface blocks me from deleting at all. Why not be
consistent and just pop up a warning?

It doesn't matter whether or not the cylinder only exists due to a bug
(edge-cases and bugs will always crop up); let the user fix it and
then recalculate things based on the fixed data set.
If I don't import the data from a dive computer, but enter it all
manually, Subsurface works perfectly happily with that data as well.

> Yes, correct, for the first two seconds of every dive downloaded from a
> Shearwater computer the calculations are based on a potentially invalid
> gas - not sure that I would agree with your conclusion that in this case
> that all of the saturation calculations for the entire dive become
> invalid because of this.
>

Well, you say that allowing a user to delete a cylinder breaks "a lot
of functionality". My counter-claim is that the functionality is
incorrect anyway, because the cylinder/gas mix physically never even
existed in the first place. They are purely an artifact of the import
process. Hence I disagree with not allowing the user to delete them
only because Subsurface thinks they are in-use. Especially if they are
only "in-use" for 2 seconds!

> Also, can I please get you to read the warning that is shown in
> Subsurface for all dives planned in Subsurface:

Yes; I understand this. But then why be so adamant to prevent deleting
of cylinders in order to preserve the calculations in Subsurface?

> I am struggling to understand how you seem to be willing to dive with a
> dive computer that is set to use a gas mix that is incorrect to the
> extent that the resulting decompression information is rendered invalid,
> but then expect to be able to somehow 'fix' the incorrect information
> used on the dive, and after this safely use Subsurface to plan follow up
> dives.

My dive computers are set up correctly for the mixes I actually carry
with me on a dive. Subsurface has an issue with importing them
correctly (or rather, as you explained, the core issue seems to be
with Shearwater not sending information whether a gas mix is enabled
or disabled. My issue with Subsurface is that I can't correct this
information using the UI)

I use Subsurface mostly as a recording tool. When I do use it to plan
more "interesting" dives then I sanity check those plans against other
calculations and information. Not everybody might. Hence why I believe
that showing no information is better than showing (potentially) wrong
information.

> Fair enough, thanks for putting thought into this, keen to see the pull
> request for the change.

Won't be anytime "soon" unfortunately, but I'll see about writing up a
detailed ticket in case somebody else gets time/is interested
beforehand.

> Not sure I can follow your logic here - you are essentially saying that
> just because you are using a dive computer for which the log import in
> Subsurface has got a bug all users of all dive computers should be made
> to enter the data for their bailout tanks twice (on their dive computer
> and in Subsurface) - wouldn't it be a better approach to get the bug
> fixed and spare everybody the extra work?
>

Ah.. my apologies.. yes, I was a bit fixated on my issue, and didn't
appreciate the fact that this might be a non-issue for people using
other dive computers.

>> Room for improvement;
>
>
> Welcome to open Source! You only get what somebody is willing to put
> effort into. :-)
>

Absolutely :)

Cheers,
- Micha.