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

Jef Driesen jef at libdivecomputer.org
Wed May 10 01:36:53 PDT 2017

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?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Predator-don-t-report-PPO2-unless-in-CC-mode.patch
Type: text/x-diff
Size: 1209 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170510/ccd726e0/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-shearwater-Report-individual-sensor-values.patch
Type: text/x-diff
Size: 2735 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170510/ccd726e0/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Use-an-extra-scaling-factor-for-the-calibration.patch
Type: text/x-diff
Size: 6231 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170510/ccd726e0/attachment-0002.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Report-the-ppO2-in-external-O2-sensor-mode-only.patch
Type: text/x-diff
Size: 1925 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170510/ccd726e0/attachment-0003.patch>

More information about the subsurface mailing list