[PATCH] Visualisation of individual oxygen sensor data for CCR dives

Anton Lundin glance at acc.umu.se
Wed May 10 02:33:14 PDT 2017

On 10 May, 2017 - Jef Driesen wrote:

> On 2017-04-17 21:49, Jef Driesen wrote:
> >On 14-04-17 22:04, Anton Lundin wrote:
> >>On 14 April, 2017 - Jef Driesen wrote:
> >>
> >>>On 2017-04-13 17:04, Jef Driesen wrote:
> >>>I tried a different approach yesterday. Instead of adding 1024 to
> >>>the calibration value, I simply used the stored value as is, and
> >>>calculated the average ppO2 over all three sensors. Then I plotted
> >>>all those values against the average ppO2 reported by the device.
> >>>And guess what, there is a nice linear relationship between the two!
> >>>Doing a linear regression on the data gives a scaling factor of 2.2.
> >>
> >>Interesting find.
> >>
> >>>For the example above this gives:
> >>>
> >>>Sensor 0: 0.642 = 33 mV * 885 / 100000.0 * 2.2
> >>>Sensor 1: 0.630 = 29 mV * 989 / 100000.0 * 2.2
> >>>Sensor 2: 0.674 = 26 mv * 1179 / 100000.0 * 2.2
> >>>
> >>>As you can see, the average ppO2 (0.648) is now very close to the
> >>>average ppO2 reported by the device (0.65). This seems to be true
> >>>for all samples. The largest difference is now 0.018.
> >>>
> >>>The next question is of course what's the source of this factor 2.2?
> >>
> >>Could it be that the calibration value is stored in some odd
> >>format, and
> >>thats where the / 100000.0 * 2.2 part comes from?
> >
> >My first thought was that it represents some kind of relative value.
> >If you look at one of my previous emails, you'll notice that the
> >default value for the calibration (when not yet calibrated) is 2100
> >for the Petrel. And the calibration values for the Predator are all
> >near the value 1000. Relative that's a factor of 2.1. That's not close
> >enough to 2.2 to produce correct ppO2 values, but it's the only
> >explanation I have that makes some sense to me.
> >
> >BTW, the fact that the calibration values are near 1000 is also why
> >adding 1024 worked for most samples. If the value is a bit higher than
> >1000, then the result is pretty close to multiplying with 2.2.
> >
> >>>And is correct for all Predators?
> >>
> >>How did it line up on the petrels?
> >
> >I only checked for the predators. For the petrel, the results are
> >already correct without the 2.2 scaling factor. So applying it there
> >too, will produce wrong results. So this is most likely something
> >specific to the predators only.
> I've implemented the scaling factor now. See attached set of
> patches. It took me a bit longer than expected because there were a
> few cases where the ppO2 still ended up being zero. And that turned
> out to be for dives without external O2 sensors enabled (e.g. fixed
> setpoint mode). But the tricky part was that the external PPO2 bit
> seems to be reversed. According to the documentation [1] external
> PPO2 is 1 and internal PPO2 is 0. But based on the data I have, it
> seems to be the opposite.
> BTW, I wonder if we should ignore the setpoint value when external
> O2 sensors are used? Are setpoint still used in such case?

Do we have any data from a Shearwater running as solenoid controller?

Ex. On the JJ-CCR's they use a Shearwater Petrel with sensors which
controls the o2 solenoid to try to get the o2 sensor values to match
your configured setpoint.

That said, I think setpoint values are still interesting to see, to
validate how well the controller did manage to try to keep the o2 close
to the setpoint.

Attached is the last iteration I did of the sensors patch. It has some
minor differences from the one you included, but most of them isn't that

The only relevant information is that the adc offset value is probably
in 0.025 mV as unit.
Thats party based on the information in

The only real comment about the code is that I would have liked to see
the calibration factor kept as a int, and just change the unit factor
from .00001 to .000022, between the models.


Anton Lundin	+46702-161604

More information about the subsurface mailing list