CCR mode and our implementation of the setpoint

Dirk Hohndel dirk at hohndel.org
Fri Feb 6 14:55:52 PST 2015


On my phone.
We should just add our own event and not abuse the existing event.
Actually, have to events
Divemodechange and Setpointchange
That way setpoint of 0 is no longer ambiguous

/D


On February 6, 2015 2:14:00 PM "Robert C. Helling" <helling at atdotde.de> wrote:

>
> 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
>




More information about the subsurface mailing list