Individual O2 sensor readings

[Anton Lundin]

On 26 June, 2015 - Jef Driesen wrote:

> On 2015-06-25 10:28, Anton Lundin wrote:
> >Nowadays Subsurface have a way to represent individual o2 sensor values,
> >but none of the libdivecomputer backends export such.
> >
> >The diverite_nitekq and shearwater_predator backends have support for
> >exposing DC_SAMPLE_PPO2 samples, which looks to be the calculated / voted
> >PPO2.
> >
> >The hwOS-based HW computers have such sensor values stored, and probably
> >the Shearwater ext devices to. I was thinking about implementing support
> >for the hwOS based devices, and was thinking if anyone have some
> >preference on how such values should be represented in libdivecomputer?
> >
> >
> >Should we go for DC_SAMPLE_PPO2_SENSOR1 or something like that to expose
> >the individual sensor values? Or do anyone else have some other, better,
> >idea?
> 
> The DC_SAMPLE_PPO2 sample is intended for o2 sensors. But when we added this
> type, we didn't take into account the fact that there are typically multiple
> o2 sensors on a rebreather. That's why I haven't implemented this yet for
> the OSTC (I have the necessary code already lying around, see attached
> patch).
> 
> In order to support multiple values, we have to introduce some new structure
> that carries a sensor id (similar to DC_SAMPLE_PRESSURE):
> 
> struct ppo2 {
>     unsigned int sensor;
>     double value;
> };
> 
> And then we can easily deliver multiple DC_SAMPLE_PPO2 values, each with a
> different sensor id, to the application. But this obviously breaks backwards
> compatibility.
> 

I think we should _add_ a struct o2_sensor which contains sensor-id,
ppo2-value and mV-value, and keep the current double ppo2.

That way we keep backwards compability, and let the double ppo2
represent the calculated/voted "true" ppo2, and let the struct
o2_sensor represent the individual sensors.

> The alternative is to keep the current "double ppo2" field, and just relax
> the assumption that there can be only one DC_SAMPLE_PPO2 value per sample.
> That's what I did in the attached patch. Applications that are not prepared
> for multiple values, will automatically use only one of them (probably the
> last one). So I think that's a reasonable solution for now.
> 

You need the id<->value mapping to make something useful out of the
individual values.

Eg. If one sensor goes bad and starts returning bogus values, you would
like to know which id that is, and not just some-id.

Also, you would like to know what the computer thought was the "true"
ppo2, vs. the raw values.


> For the nitekq, I'm not 100% sure but I think it's indeed a calculated/voted
> ppo2 value. For the shearwater it's the average ppo2. I'm not sure whether
> that is an average over the o2 sensors, or a calculated value. I have the
> impression it depends on the dive mode, because the field contains a
> non-zero value for OC dives too.
> 

In subsurface we have a patch to not return those values in OC mode,
which i really think makes sense.

> The shearwaters do also record ppo2 data for up to three o2 sensors, but the
> value is in millivolts, so it can't be directly interpreted as a ppo2 value.
> I assume it's possible to convert from millivolts to a ppo2 value, because
> in the header there are several o2 sensor calibration fields present for
> each sensor (e.g. "Calibration status", "Calibration value" and "ADC
> Offset"). But I don't know how this calculation should be done.
> 

Its doable. ADC Offset is probably the offset in the Analog to Digital chip,
and the Calibration status and Calibration value is probably the mV
response for a certain fO2 calibration gas.


I have hand some ideas about doing decay analyses on O2 sensors, and for
that it would be great to follow how the mV value for the same ppo2
drops over time for a O2 sensor and thus being able to try to predict
when its time to replace it. I really don't know how feasible or
accurate such analysis would be but I would love to try to run the
numbers and see what i can come up with.

Also trying to detect and warn about current limited sensors would be
an interesting project.


So, id say a
struct o2_sensor {
	unsigned int sensors;
	double ppo2;
	double mV;
};
and a DC_SAMPLE_PPO2_SENSOR would make me a happy. Just set the
non-existant ppo2/mV to zero or -1.


The question is if libdivecomputer should just export the Shearwater
calibration data to the application and let it do any mV -> ppo2
calculations or if libdivecomputer should do those...


//Anton


-- 
Anton Lundin	+46702-161604