On 10 December, 2017 - Davide DB wrote: > On 7 December 2017 at 15:12, Jef Driesen <[email protected]> wrote: > > So all three have and ADC offset of -1, although there are CCR dives > > present. > > > >> Regarding the question if sensor #2 was voted out. I don't think so. When > >> one or more sensors are voted out their pO2 value is clearly displayed in > >> yellow. I never saw something strange going on in water. I guess even the > >> SD software should report a similar event which is not. > >> From the Petrel manual I see that a sensor is voted out for a percentage > >> difference >= 20%. In the last part of my deco I see a max difference of > >> 10% I think. > > > > > > Well, what I see is the following. The patch I attached in my previous > > email, logs the millivolt (for each of the 3 sensors) and ppO2 values > > (respectively the stored average, the calculated average, the delta between > > the two, and also the 3 ppO2 after the conversion). To make it easier to > > filter on ppO2 values with a large delta between stored and average, those > > lines are marked with an extra "Voting" prefix. So you get something like > > this for each sample: > > > > Status 00: gasswitch=0 extppo2=0 setpoint=0 sc=0 oc=0 > > mV: 54 55 54 > > ppO2: 98 114.1 16.100 113.4 115.5 113.4 > > Voting: 98 114.1 16.100 113.4 115.5 113.4 > > > > (I've attached the full output for your dive.0001.bin file.) > > > > In this case there is a delta of 16.1 between the stored avgppO2 value (98) > > and the calculated value (114.1). But the values of the three sensors are > > reasonably close together. So that means this delta is clearly not due to a > > sensor being voted out. They all have the same amount of error from the > > stored avgppO2 value, and also every sample has this kind of large delta. So > > this is most likely an error in the conversion from millivolt to ppO2. > > > > > > If you compare this with the deltas I see in some of the other datasets > > where larger deltas occur, they look different: > > > > Status 00: gasswitch=0 extppo2=0 setpoint=0 sc=0 oc=0 > > mV: 68 67 69 > > ppO2: 123 132.2 9.213 121.9 149.3 125.4 > > Voting: 123 132.2 9.213 121.9 149.3 125.4 > > > > Again a large delta 9.213, but this time we have one ppO2 value (149.3) that > > is much larger than the other two (121.9 and 125.4). If we assume that > > sensor got voted out, and calculate the average over the remaining two, then > > we get an average value (123.65) that is close the the stored avgppo2 (123). > > > > This is a sample from the petrel.stevewilliams dataset. And there the voted > > bit for sensor 1 is indeed zero! I haven't checked all samples, but the few > > I checked were all similar. > > > > > > Now, the interesting part is that all three datasets show the same problem. > > What they have in common is not only that ADC offset of -1, but also the > > calibration value of 2100. Based on the other datasets, that appears to be > > some kind of factory default value. And the more I think about it, the more > > I believe that's the value we should be looking at. I assume you have > > calibrated your sensors at least once, right? In that case I would expect to > > see some different value from the default. None of the other datasets with > > CCR dives and extppo2 monitoring enabled have the default calibration value. > > > > If I do a simple linear regression (on your dive.0001.bin data) between the > > millivolt values and the stored avgppo2, then I find these calibration > > values for each sensor: > > > > Sensor 0: 1861 > > Sensor 1: 1765 > > Sensor 2: 1874 > > > > On average that's a difference with a factor 0.873! > > > > Jef > > I calibrate my two Petrels ALWAYS when I assemble my unit as part of > my checklist and ALWAYS the same day I dive and. No calibration No > party. > I made other dives and all of them show the same error. Shearwater > desktop tell me that everything is ok (like my Petrel underwater) > while Subsurface reports pO2 over 1.6. > Thank you for the detailed explanation. > Where do we go from here?
Is this a divecan unit or something? I'm just guessing that it might affect how/where the cal factors are stored. //Anton -- Anton Lundin +46702-161604 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
