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