CCR mode and our implementation of the setpoint

[Jef Driesen]

On 06-02-15 23:16, Robert C. Helling wrote:
> 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.

Most dive computers have a divemode setting per dive. The Shearwater is one of 
the exceptions here, with its divemode setting per sample.

I don't agree that a per dive divemode setting is a design mistake. In most 
cases changing divemode during the dive simply doesn't make any sense. For 
example, I don't know any device that supports switching from freedive/gauge to 
oc/cc (or vice versa). The only scenarios that do make sense to me are the ones 
you describe (e.g. bailout or deco). But I assume such a dive is still 
considered a CC dive, right? It's still useful info, it just serves a different 
purpose.

So I guess what we really want here is not to get rid of the per dive divemode 
setting, but some way to indicate the switch from CC to OC. That could be done 
with a per sample divemode (as the shearwater does) or a bailout event (as the 
ostc does).

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

See my response to Dirk's mail.

Jef