CCR mode and our implementation of the setpoint

[Robert C. Helling]

On 06 Feb 2015, at 22:54, Dirk Hohndel <dirk at hohndel.org> wrote:

Dirk,

> Robert, Willem, you have spent more time with the code than I have. What
> am I missing?

quick answer: The problem is that it is not a _dive_ that is CCR or OC, it is really a moment in time. Actually, the realisation that it was a bad design idea to mark a whole dive (or even more stupid: a dive computer) with a dive mode (used to be dctype) is not very helpful in situations like bailout or decoing on OC (e.g. a habitat). The dive mode is really time based and should thus be handled by events. The function that you mention is there to move in that direction: It adds a corresponding event at t=0 to make the event based information (which is more fine grained) agree with the dive mode of the dive (or: dive computer). I was hoping to completely get rid of the dive mode eventually (in the per dive sense) as I think the doubled information about the dive mode has to be resolved in this direction.

But that is separate from the double semantic of SAMPLE_EVENT_PO2 which I was not aware of and which is simply bad. I am convinced, we need some event that has the meaning “this is a set-point change of a CCR with the special meaning of a set-point of zero being OC or actually non-CCR like e.g. PSCR). 

I can see that the problem is related to an earlier confusion we had between pO2 and O2setpoint (those were one variable at some point): Before we were dealing with sensor data, the only information about the gas a CCR diver was breathing, was the set point. But with sensor data (which we will be having also for pscr dives which will cause another minor headache) that is no longer true. So now, we use the set point only as a default for the actual pO2 if there is no better sensor data available.

So what is the way to proceed? We need to disentangle the two event types: CCR set point changes and high/low pO2 warnings. Did we inherit this ambiguity from libdivecomputer or is that only using that event for the latter meaning? I wrote code that inserted these events in two places: The function you quote inserts them only at t=0 and those should thus be trivial to find. But there is also the profile context menu which adds set point changes. And that also adds these events. 

Can we come up with a list of dive computers that use these events withe high/low-type warning? Then those events for all other dive computers should have the other meaning. 

What do you think?

Robert


--                                                                              
.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO 
Robert C. Helling     Elite Master Course Theoretical and Mathematical Physics  
                      Scientific Coordinator                                   
                      Ludwig Maximilians Universitaet Muenchen, Dept. Physik    
print "Just another   Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339       
    stupid .sig\n";   http://www.atdotde.de 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150206/ee07f40b/attachment.sig>