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
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
