rebreathers on Subsurface (2)

[Willem Ferguson]

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