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" <hell...@atdotde.de> wrote:
On 06 Feb 2015, at 22:54, Dirk Hohndel <d...@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
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface