On 20/05/2014 09:29, Dirk Hohndel wrote:
You're getting lost here.
a) while I can see that CCR divers might be interested in two cylinders at
a time, who would ever want more than that? So wouldn't it make more sense
to have a "secondary_cylinderindex" for the dilutent?
b) gas composition and partial pressures don't depend on cylinder
pressures at all - they have nothing to do with any of this. They depend
on the pO2 settings of the rebreather and the current depth.
c) whatever we do, we will NOT make the common case for 99% of the divers
more complicated / convoluted. I said this before, I'm open to adding
features for CCR divers but ONLY if they don't negatively impact OC
divers. And two events, disconnect and connect? Nope, not happening.
I'll consider tracking a secondary cylinder. If we have a clean design to
do so.
The most important point is, if one provides for more than two
cylinders, that one does this in a way that provides maximum
adaptability in future.The Poseidon MkVI tracks the O2 and the diluent
cylinders simuntaneously. Currently the Galileo provides for
simultaneous tracking of up to four cylinders. If you are prepared to
throw enough money at it, the APD Inspiration will track the O2 and up
to six different diluent gases. This is not first hand knowledge,
though. In the coming weeks I will have some close contact with APD
equipment and will be able to speak more authoritatively.
I would be perfectly happy to work with only two cylinders. But this
should preferably be done in a way that allows for relatively easy
expansion, in future, to more than two cylinders, should there be a
need. But this means that the single variable (e.g. the pressure[]
variable in plot_data would probably need to become an array, keeping in
mind that half of pressure is used for storing interpolated values). If
this becomes an array (more accurately, a [2][2] array), the question is
whether one should not provide for MAX_CYLINDERS different cylinders (I
think currently 7). Personally I am not sure why anyone would really
like to track more than 2 cylinders (CCR) or more than one cylinder
(OC), but that is not the point. In terms of processing it comes down to
it that, instead of storing the log as one long list list, the pressure
data from the different cylinders need to be stored in separate places
and this has marked effects on how processing takes place.
Another point. I think the existing code provides for good agreement between
the order of cylinders in the equipment tab (or, more precisely, in the dive
structure) and cylinder order in the plot_info structure. However, one needs
to think of potential situations that can destroy this agreement. I think
this would mostly relate to the way the dc reports cylinder pressures and
how the user manually adds cylinders after the dive.
Please explain more what you think could destroy this relationship? Right
now we have the frustrating reality that most dive computers cannot deal
with multiple cylinders using the same gas (and some don't even allow you
to enter more than one cylinder with the same gas) because they don't
report switches between cylinders but switches between gases.
I was thinking of making ensuring that this relationship could not be
upset by the user tinkering with the equipment tag. What would happen if
the user messed around with the information in italics, provided by the
dc, possibly overwriting the existing cylinder-specific info?
Fortunately the user can only insert an additional cylinder at the
bottom of the list, not higher up. I do not think this is an important
problem area, just something to watch because the syncronisation of the
cylinder fields with the data in the profile is critical. This relates
to your final comment below.
We adopted
that model from libdivecomputer and therefore have some flexibility
regarding the association of a pressure graph with the corresponding
cylinder, but I would actually like to modify this specifically in order
for people to have more than one cylinder with the same gas and to switch
between them (this is a common request we get from side mount divers, for
example). So whatever new design we come up with needs to keep that
direction in mind as well.
I do sidemount diving with a Galileo and it records switches in
cylinder, not in gas and it works perfectly. In order to explore any
problems/limitations with Subsurface, I am borrowing some sensors and
will be logging some multi-sensor sidemount dives within the next few
weeks. But your point is taken that we should keep that aspect in the
eye, as well.
If there are any clear constraints that need to be kept to for
maintaining compatibility with libdivecomputer, then it is important to
define them clearly.
My thinking would be to have each cylinder get a (per dive) unique ID
assigned and then reference that ID in gas switches. Obviously today that
unique ID could be the sequential number in the cylinders array - if you
believe that that won't work, please explain why and how you think we
should arrange things.
At the moment this is surely the best solution.
Kind regards,
willem
_______________________________________________
subsurface mailing list
[email protected]
http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
