Incorrect gas assignment when importing from Perdix2
anderson...@gmail.com
Michael Keller
On 12/06/23 08:55, anderson...@gmail.com wrote:
> Just finished a few dives on independent doubles (21%) with a
> deco/pony bottle (34%).
> Gas switching between the back gas every 500psi or so, and then switch
> to pony for the simulated deco / safety stop.
>
> After the import, the 34% mix is assigned to the wrong cylinder, and
> as a result an incorrect gas switch event is created as well.
>
> I have to review the logs on the Perdix2 to confirm start/end
> pressures and then manually assign the correct mixture. . . followed
> up by editing the gas switches.
pressure readings that are shown for the 34% gasmix in the 'Equipment'
tab are the readings from one of the 21% sidemount tanks?
If this is the case then unfortunately I suspect this will not be an
easy fix. In essence the dive computers with 'air integration' on the
market today treat gas mixes and tank sensor readings as two completely
independent things. So for Subsurface to properly support air
integration - in particular for 'edge cases' like sidemount setups where
two sensors are supplying data for the same gasmix a there is need for a
UI and business logic to support creating and maintaining arbitrary
0...n to 0...m mappings between gasmixes and tank sensors. And
Subsurface doesn't have this at the moment - it simply does a 1:1
mapping of gas mixes and tank sensors in the order they are reported by
the dive computer.
> Can provide any extra info to help sort it out.
it can be shared.
Unfortunately the log collection in
https://github.com/subsurface/large-anonymous-sample-data does not
contain much in the way of logs with 'advanced features' like air
integration or CCR / SCR logs, I have started adding some data to
address this:
https://github.com/subsurface/large-anonymous-sample-data/pull/1 But not
sure if adding this to the single huge compressed log file is the best
approach, as handling this is a bit ungainly.
Ngā mihi
Michael Keller
anderson...@gmail.com
Jef Driesen
> If this is the case then unfortunately I suspect this will not be an
> easy fix. In essence the dive computers with 'air integration' on the
> market today treat gas mixes and tank sensor readings as two completely
> independent things. So for Subsurface to properly support air
> integration - in particular for 'edge cases' like sidemount setups where
> two sensors are supplying data for the same gasmix a there is need for a
> UI and business logic to support creating and maintaining arbitrary
> 0...n to 0...m mappings between gasmixes and tank sensors. And
> Subsurface doesn't have this at the moment - it simply does a 1:1
> mapping of gas mixes and tank sensors in the order they are reported by
> the dive computer.
https://github.com/libdivecomputer/libdivecomputer/commit/becb8bd36e595b7efec39266b1e590e4f8dc703e
When the tanks are correctly configured as sidemount tanks on the Shearwater
dive computer (tank named 'S'), the tanks will get labeled as DC_USAGE_SIDEMOUNT
by libdivecomputer. That info can be used in subsurface as a hint that both
tanks contain the same gas mix.
Jef
Michael Keller
Hi Matthew and Jef.
Mike -
You are spot-on correct.
When I import a dive with x3 tanks from Perdix 2 in sidemount mode (x2 are %21, x1 is 34%). Subsurface sets the 34% mixto one of the other two (21%) tanks, as evidenced by the different starting pressures.
I downloaded the dives to the Shearwater Cloud Desktop app to confirm the proper tanks/pressures/mixes.So I'm assuming that the correct information (gas mix, starting pressure, tank name) is available in the data downloaded -Just need to figure out why Subsurface isn't processing it properly.
I had a quick peek at your logs, and yes, this is exactly what it is.
The problem is not so much that the data is not imported into
Subsurface, but that it is grouped in the wrong way. Subsurface
uses libdivecomputer to import a list of gasmixes, and a list of
tank sensors. In the very same step, right
after import it then pairs them 1:1 as gasmix[0] -
tanksensor[0], gasmix[1] - tanksensor[1],... And this pairing is
then used everywhere throughout Subsurface: In the data model
where it is persisted in the 'cylinder' element, in the
'Cylinders' table in the 'Equipment' tab, ...
As evidenced in your case this will obviously not work for sidemount configurations where more than one tank sensor is used for what is tracked as a single gasmix, and it will also not work for a number of other technical configurations - especially as in the case of Shearwater dive computers the ordering of the list of gasmixes is dictated by their composition and there is no way for the user to set it up so that the gasmixes in the tanks that are equipped with sensors come first in the gasmix list.
In order to make these cases (and a number of other cases, like tanks with sensors that the diver doesn't breathe from) work the only way I can see is to change Subsurface to treat gasmixes and tank data separately, instead of as one 'cylinder' entity. Unfortunately this will be a fairly massive change, as it will affect the data model and storage (possibly introducing backwards incompatibility), and will require additional UI to manage the mapping between gasmixes and tank data.
From my point of view, another consideration is that it is likely that for the vast majority of users and dives with tank sensor information logged in Subsurface this will not be a problem, as these will be recreational single tank dives with a single sensor. Especially as this will also include all dives logged with dive computers that have an integrated tank pressure sensor. So I think changes like splitting the 'Cylinders' into two parts will have a very dubious value proposition, improving things for a minority of users while adding unneeded complexity for a majority. We'd probably rather keep the existing table, showing the result of applying a user defined mapping between gasmixes and tanks, and have a separate UI for managing the mapping. And we'd probably want a way for the mapping (or even multiple mappings) to be persisted, assuming that a user will be diving the same or a similar configuration of tank sensors for most of their dives.
If you (someone else?) would be able to point me in the right direction where that logic is located in the source, I would be happyto start working on a fix.
I think starting at the point that we incorrectly create the 1:1 pairing of gasmixes and tank info, and then checking what can be done to improve this will be a good starting point:
What's the preferred method for pulling a set of logs?
For my purpose the .ssrf that you have shared is all that I need.
For sidemount dives, this commit might help a little bit:
https://github.com/libdivecomputer/libdivecomputer/commit/becb8bd36e595b7efec39266b1e590e4f8dc703e
When the tanks are correctly configured as sidemount tanks on the Shearwater dive computer (tank named 'S'), the tanks will get labeled as DC_USAGE_SIDEMOUNT by libdivecomputer. That info can be used in subsurface as a hint that both tanks contain the same gas mix.
Unfortunately there doesn't seem to be a hard link between how the names for tanks are set and the dive computer treating them as sidemount tanks. And their documentation fails to point this out, with most of their examples showing sidemount tanks labelled with 'T' and not 'S':
So I doubt that users will pick up on what they need to do to correctly configure their dive computer, and once this change gets pulled into Subsurface the documentation should be updated to make users aware of this requirement, or there will be users getting unintended consequences from arbitrarily choosing names for their tanks.
Kia mārū
Michael Keller
Jef Driesen
> Thanks Jef - I will check out the sidemount code.
>
> Attached is a dump of two dives as described earlier for those who are interested.
would like to have a look at the raw dive data to check an improvement for
sidemount diving. Can you send me the libdivecomputer log from the download?
Instructions are available here:
https://libdivecomputer.org/subsurface.html#desktop-dives
Jef