[PATCH] DLF import: set no_o2sensors in CCR/PSCR mode

Anton Lundin glance at acc.umu.se
Tue Jan 6 09:22:14 PST 2015


On 06 January, 2015 - Dirk Hohndel wrote:

> On Tue, Jan 06, 2015 at 01:23:31PM +0100, Anton Lundin wrote:
> > This triggers the rest of the code to treat the sensor value as our
> > ppO2 value.
> 
> I'm curious about this... shouldn't "every sensor reports 0" be what
> triffers this?
> 

I don't follow you here. We use a variable to tell our code how many
o2 sensors to expect. Eg. If we say we should have zero sensors, that
means no sensors. If we say we have 3 sensors and the third is reporting
zero, that one is broken.

The DLF-import code might be a bit Avant-garde in the area of CCR.

It currently uses a bit of the newer look that up until now only the
Poseidon code have.

Maybe i should turn it a bit more old-school for how until we actually
got some clearer view on how it should work.


> I guess I'm fundamentally confused about what we intend the scenarios to
> be.
> 
> Can someone create a matrix that shows:
> 
> Type of dive
> Type of data we have from the dive computer
> Which fields in the sample we use for what
> 
> I know exactly what is what in an OC dive. We need to create a better FD
> mode, but I have a good idea how that could look. But CCR and PSCR? Only
> vague guesses.
> 
> Help?

Yea, we should definitely clear that up.


Previously we didn't store any "type of dive" info. If we had a po2
value, it was a rebreather dive. The po2 value could be setpoint in the
case of fixed-setpoint devices, or the by the computer calculated po2
from its sensors, no matter how many.


Nowadays we store a dctype which flags if this was a rebreather dive or
not.

The po2 value in the xml represents the setpoint. Old o2 sensor dives
gets loaded with a "varying" setpoint.
We still import dives form libdivecomputer this way.


O2 sensors gets stored in different variables. We store the raw values
from the different sensors here.
If we should care about these numbers, we need to know how many of them
are actually expected to be there, and thats stored in the no_o2sensors
variable.


The po2 calculated by the computer might be different from the actual
sensor values, and how we would interpret them, so shouldn't we save
both/all of them?


On the area of rebreather post-dive-analysis, saving the millivolts from
the sensors would probably be nice to. If someone where to build our own
warn on decaying o2 cells analysis.


The libdivecomputer support for lots of these are slim. Will ever only
be OSTC reporting a fixed setpoint back, and only Predator who reports
PPO2 samples, and thats only for one sensor.

The OSTC3 have those values in its logbook and if i get around to it,
I'll implement reading of those.


//Anton - Somehow this became to much babble...


-- 
Anton Lundin	+46702-161604


More information about the subsurface mailing list