CCR mode and our implementation of the setpoint

[Dirk Hohndel]

OK, I'll admit it up front. I don't really care about rebreathers - they
aren't interesting to me. So I clearly haven't paid enough attention to
our CCR support.

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.

It seems we use a SAMPLE_EVENT_PO2 to change the setpoint in our code,
e.g., in void update_setpoint_events(struct divecomputer *dc) and in the
planner.

Sadly, that event is sent by many dive computers as a WARNING that you
have exceeded the useful PO2 range. You'll get this from your Suunto or
your OSTC or your Cobalt when you went too deep on your gas (and at least
on the EON Steele also when you went to shallow with a hypoxic mix).
These are the only dive computers that support this event - none of them
use it to set a setpoint.

So of course I wondered which brain dead idiot came up with that stupid
idea. And indeed, as the comments in planner.c say:

       /* this is a bad idea - we should get a different SAMPLE_EVENT type
	* reserved for this in libdivecomputer...
	* overloading SMAPLE_EVENT_PO2
	* with a different meaning will only
	* cause confusion elsewhere in the code
	*/
       add_event(dc, lasttime, SAMPLE_EVENT_PO2, 0, po2, "SP change");

Who wrote that crap? Oh. Right. I did.
:facepalm:

So I can't blame Robert for then applying the same logic when he tried to
switch a dive from OC to CCR mode or vice versa. But that doesn't change
the fact that it is simply wrong.

The only way to know if a dive is CCR or OC or something else is the
divemode (and the dctype in the XML). Anything that looks at
SAMPLE_EVENT_PO2 or the presence of setpoint in the samples is wrong.
Once you KNOW that you are in CCR mode, you can use the setpoint in the
sample to detect an OC bailout, but that's it.

This needs to get fixed.

Now the other question is, of course, how do we figure out that a dive is
in CCR mode and that therefore setpoint=0 in a sample does, indeed, imply
bailout, and anything else implies the diver is in CCR mode?

We need to go through dive computer by dive computer and figure out how we
can tell from their data. In the bug report the user has a Predator and
that tells libdivecomputer in every sample if it's in OC or CCR mode.
Right now libdivecomputer completely ignores that bit and happily sends us
setpoint data with every sample, whether the Predator is in OC or CCR
mode. I pushed a patch to the Subsurface-testing branch of libdivecomputer
that has us no longer send the (clearly redundant) setpoint values in OC
mode, but that still doesn't tell us if the dive was indeed at any point
in time a CCR dive.
Instead we need to use the DC_FIELD_DIVEMODE to tell if this is indeed a
CCR dive. So I'll add that to the Predator and to other backends that can
tell us what's what.

So how do we fix the planner? And how do we make sure that switching the
dive mode from the UI actually works and does the right thing?

Robert, Willem, you have spent more time with the code than I have. What
am I missing?

/D