CCR mode and our implementation of the setpoint

[Jef Driesen]

On 06-02-15 22:54, Dirk Hohndel wrote:
> 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.

That's because SAMPLE_EVENT_PO2 was designed as a high/low ppO2 warning. Using 
it as a setpoint (or ppO2) value is plain wrong.

To report ppO2 values libdivecomputer has two sample types: DC_SAMPLE_SETPOINT 
and DC_SAMPLE_PPO2. As the name indicates, the first one is intended for 
rebreathers with fixed setpoints. The second is for rebreathers with oxygen 
sensors or just any dive computer that reports the ppO2 value (most likely a 
calculated value in this case).

[Note that oxygen sensor support in libdivecomputer is currently flawed, because 
it can only support one value, while typically you have multiple sensors. That's 
for example why I'm unable to support ppO2 in the ostc backend. The ostc records 
the value from all 3 sensors, and not just the final "averaged/voted" value.]

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

I don't have a good answer, but I can tell you what I did for the ostc. The ostc 
has a bailout event to indicate a switch to OC. The event data contains the O2 
and He percentages of the bailout mix. Since libdivecomputer doesn't have a 
bailout event, I modeled this as a normal gas change.

The idea behind this is that for rebreather dives, you normally shouldn't get 
gas changes (you get setpoints instead). So if you have a rebreather dive, and 
you suddenly get a gasmix change, then you know there must have been a bailout 
to OC.

Note, I'm not a rebreather diver. I know the basics, but I'm far from an expert. 
So please correct me if I'm talking nonsense. Having said that, I think the main 
thing that distinguishes between OC and CC is that the former is based around 
the concept of gas mixes, while the latter is based on setpoints. Is it safe to 
assume an OC dive should never have any setpoint samples, and a CC dive should 
never have gaschanges (unless you switched to OC)?

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

You're slightly wrong here. For the predator/petrel, the libdivecomputer does 
not give you setpoint data. It gives you the average ppO2. That's a different 
thing. For the petrel there is also a current setpoint in each sample, but it's 
stored at offset 18, not 6. The predator doesn't have this setpoint, but it does 
have high/low setpoint bit, which I assume refer to the high/low setpoint values 
in the dive header. (The petrel has this bit too, but I guess that's just for 
backwards compatibility with the predator.)

Does anyone have data from a predator and/or petrel in CC mode? I don't, so the 
parser hasn't really been tested against CC dives. (And if I do have some CC 
data without me knowing, I didn't really pay attention to CC when I implemented 
the predator/petrel parser.)

Anyway, based on this knowledge, I think the patch you send me is wrong. I think 
the right thing to do here is to leave the ppO2 sample as-is, and instead emit a 
setpoint sample in CC mode.

Jef