G'day,
(Related background discussion :
https://groups.google.com/g/subsurface-divelog/c/aIIr0QJuxFY/m/mtnOfhaDAwAJ)
At the moment I'm diving Sidemount again, and again having issues with
spurious cylinders due to additional gasses being defined (although
disabled) on my Shearwater computer. Recreationally I dive with 2
cylinders filled with the same gas mix (typically Air or EAN32), and
both cylinders have a transmitter. I leave my computer in "Tec" mode and
leave the common mixes I use during other dives disabled instead of
deleting them.
The imported dive has 3 cylinders shown, and cannot display or calculate
gas usage from the transmitters properly (the transmitter data is
plotted in red, no SAC is calculated).
Cylinder 1 (can be deleted with a warning) - EAN99 - transmitter 1 data
Cylinder 2 (can be deleted with a warning) - EAN51 - transmitter 2 data
Cylinder 3 (can NOT be deleted) - EAN32 - initial gaschange event
I can manually fix the gas mix for Cylinders 1 & 2 using the UI. But
the only way to currently get rid of the phantom Cylinder 3 is by
manually editing the log files and deleting the initial gas change
event.
Now, I see several simple approaches to allow the user to fix this using
the Subsurface UI:
1. Don't generate the initial "gaschange" event, which is wrong anyway.
(At this stage I'm not entirely sure if this is being sent by the dive
computer, or generated by Subsurface during the import process; still
investigating). Subsurface doesn't seem to need an initial "gaschange"
event to render a dive correctly.
2. Display the initial "gaschange" event on the dive log (it's currently
being suppressed).
This would allow the user to edit/delete the event using the UI. Having
implemented this change in my local build, I can edit the event to point
to a "real" cylinder which then automatically deletes (or hides) the
phantom cylinder. Problem solved.
3. Allow the user to delete any cylinder.
Currently the UI allows deletion of some cylinders which are "in use"
(have transmitter data attached) with only a warning being displayed,
but not others (such as the one attached to the initial "gaschange"
event). I fail to understand why the "gaschange" event is important
enough to prevent cylinder deletion, but transmitter data is not.
Any other suggestions for "simple" fixes?
Any concerns about any of these approaches breaking other functionality?
Any preference as to which approach to implement?
I also contacted Shearwater about adding gas status (on/off) to their
protocol, but did not receive a reply.
Thanks,
- Micha.
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
