On 2017-04-13 17:04, Jef Driesen wrote:
I don't entirely agree with that. If you check the available memory
dumps, 5 of them contain CCR dives. I analyzed all of them, and this
is what I found:
* petrel.marklee.bin
The three mV values in the samples are always zero. But since all
three O2 sensors have their calibrated bit in the header disabled, no
ppO2 samples are reported. So that looks good.
Sensor 0: 0 0 2100 -1
Sensor 1: 0 0 2100 -1
Sensor 2: 0 0 2100 -1
(These numbers are respectively the voted bit, the calibrated bit, the
calibration value and the ADC offset.)
* petrel.larrybainbridge.bin
The three mV values in the samples are always zero. But the O2 sensors
are calibrated, and thus we report ppO2 samples with all zeros. That's
not good. This might indicate that we need to take into account the
voted bit too, because that is disabled for all dives:
Sensor 0: 0 1 2045 44
Sensor 1: 0 1 2025 -9
Sensor 2: 0 1 2045 51
petrel.rainer.bin
Here we have non-zero mV values in the samples. The O2 sensors are
calibrated. In most samples, manually averaging the resulting ppO2
gives results that are very close to the average ppO2 value reported
by the device. In roughly 90% of the samples where the result is
different, the difference in average ppO2 is only 0.01. That might be
some rounding error. In only a few percent of the cases there is a
significant difference, and that are probably cases where a value is
voted out. So everything looks reasonable here.
Sensor 0: X 1 YYYY 0 (with YYYY ranging from 1671 to 2112)
Sensor 1: X 1 YYYY 39 (with YYYY ranging from 1810 to 2326)
Sensor 2: 1 1 YYYY 2 (with YYYY ranging from 1621 to 2108)
Note that sometimes sensor 0 or 1 have the voted bit disabled in the
header! So if we would take that bit into account (see above), then I
think we're disabling a sensor when it shouldn't. So I'm not really
sure what to do with the voted bit.
* predator.janschubert.bin
All sensors are calibrated and voted in:
Sensor 0: 1 1 YYYY -16 (with YYYY ranging from 859 to 895)
Sensor 1: 1 1 YYYY -24 (with YYYY ranging from 812 to 843)
Sensor 2: 1 1 YYYY -11 (with YYYY ranging from 827 to 856)
Note that compared to the petrel data, the calibration values are now
in an entirely different range. So the resulting ppO2 are way off.
That's what you tried to address in the second revision of you patch
with this code:
if (calibration < 1000)
calibration += 1024;
With this patch, the results look good again. When comparing the
calculated with the stored average ppO2, the largest difference is
only 0.021.
* predator.marklee.bin
All sensors are calibrated and voted in:
Sensor 0: 1 1 YYYY -41 (with YYYY ranging from 885 to 1069)
Sensor 1: 1 1 YYYY -39 (with YYYY ranging from 989 to 1016)
Sensor 2: 1 1 YYYY -5 (with YYYY ranging from 1179 to 1376)
Very similar, except that some calibration values are above and other
below 1000. And that breaks the above patch. If we always add the
value 1024 (or just 1000) unconditionally, things are getting better.
I guess that's an indication that this is something specific for the
predator, but not the petrel. But it's not perfect yet. The difference
in average ppO2 is now between 0.043 and 0.212. This is much larger as
before, and if you look at the values, it's not caused by an outlier
that is getting voted out.
A random example:
Sensor 0: 0.639 = 33 mV * (885 + 1024) / 100000.0
Sensor 1: 0.583 = 29 mV * (989 + 1024) / 100000.0
Sensor 2: 0.572 = 26 mv * (1179 + 1024) / 100000.0
But the average ppO2 reported by the device is 0.65. That's more than
our highest value, so it can't be due to sensor voting. Maybe the
calibration is done different for the predator?
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.
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? And
is correct for all Predators?
Jef
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
