CCR mode and our implementation of the setpoint

[Dirk Hohndel]

On Sat, Feb 07, 2015 at 02:46:56PM +0100, Robert C. Helling wrote:
> > On 06 Feb 2015, at 22:54, Dirk Hohndel <dirk at hohndel.org> wrote:
> > 
> > But a bug report from an OC diver forced me to dig into this and what I
> > think I'm beginning to understand doesn't make me happy.
> 
> Double use of the event is not nice, but it does not seem to be the
> problem here: When the interpretation is „set-point change“, the name of
> the event (the fourth argument of add_event) is always „SP change“ and
> whenever we read this event, we not only compare the event type but also
> the name. So there cannot be any confusion from that point. The double
> use should be resolved, but this is not the problem in #826.

Oh good. So I was less of an idiot than I thought.
Still, we should change that, but since we always store both name and type
in our data files this is something we can cleanly address.

> The problem for the user arises (as you comment in trac correctly) as
> the predator reports pO2 even in OC mode (probably a value that it
> computed) and historically (from the time before we had a dive-mode or
> even dctype) we determined a CCR from the fact that there was pO2
> information. That should not be there. I would say, the bug is here.

Yes, I agree.

> So, how shall we proceed? In the future, I would say, we should not save
> those values.

A patch that does just that has been added to our Subsurface-testing
branch of libdivecomputer. I'll also send it to Jef for inclusion in
master.

> What about old logs? We could delete all those pO2 values if the dive
> computer is a Predator and the user selects OC as dive mode?

I have a draft patch that does that but wanted to talk to you about it.
This is a non-reversible change. So if the user has a dive that includes
pO₂ values in the samples, we show that dive as CCR. If the user then
switches to OC we can easily clear out the pO₂ values, but of course if
those were not just calculated values but in fact were setpoint data that
the user entered during a dive (i.e., if the switch to OC was a mistake),
then that data is gone.

I think that's acceptable, but I wanted to run this by others before
pushing that patch.

With the two patches that I have (one for libdivecomputer, one for
Subsurface), the bug the user reported won't happen again and the files he
has already downloaded can be fixed, so I think this is "about right" for
fixing the situation in 4.4.

The other question, of course, is what to do in the future. As you
correctly point out in another email, CCR/OC is /not/ a property of a
dive. Freedive / Scuba is. I don't know how PSCR fits into this whole
discussion as I don't have the slightest idea what a PSCR even is :-)

So I'd love to see a proposal of how we should manage this information in
a SANE way and how we should respond to state changes. Can a diver switch
from PSCR to OC? Or to CCR? Or the other direction? What does that mean
for our visualization? Or are we over-engineering this?

> Independent of that, the SP change at t=0 should not be displayed to the
> user as that is actually the dive mode at the start of the dive which is
> selected in the combo box. But that is a display problem (that can
> easily be solved).

Yep, that's straight forward.

/D