Overthinking on sensor accuracy

Steve stevewilliams at internode.on.net
Wed May 24 18:17:35 PDT 2017

On 12 May, 2017 - Davide DB wrote:

> Hi,
> While thinking to the work on oxygen sensor data you are doing, I had 
> a couple of somewhat foolish thinking.
> In eccr mode the unit is working at a given setpoint for part of the 
> dive. The set of ppO2 values from the three sensors will follow the 
> setpoint.  the set can be said to be precise if the values are close 
> to the average value of the quantity being measured, while the set can 
> be said to be accurate if the values are close to the true value of 
> the quantity being measured, aka the setpoint.
> So my question is. Do you think will be possible to analyze those data 
> set (each data set is one sensor) to understand if there is one sensor 
> which show a different behaviour while measuring the ppO2?
> Formerly, from my ancient college studies, I was thinking to the 
> variance but it express variation respect the dataset average value. I 
> think it's really a question of "accuracy".
> I wonder if we can have a sort of accuracy of each sensor respect the 
> setpoint for each dive and maybe during the time I can spot an aged 
> sensor...
> I'm realizing that the above doens't fit in mCCR mode where you do not 
> have precise setpoint. So I had another foolish thinking.
> Perhaps more simply we could just correlate sensor readings trying to 
> spot if there is always a sensor value which distances from the 
> others. Maybe after several dives I could find that the same behaviour 
> comes from the same sensor. Again I could spot an aged sensor.
> Something similar to the controller's voting logic but applied after 
> the dive to the entire dataset which we have.
> Maybe it's something so obvious that already other people tried to do 
> something like this proving it wrong.
> l go dive.

I have bin thinking about the same problem, and how it might be possible to try to detect sensor degradation in a early state, and I think this would be a cool and useful feature, but its its only useful for a selective few, and will be pretty tricky to implement.

One would for example be required to "log" when you replace a sensor, to suppress false positives.

On the up side, its a feature which is really unlikely to cause bugs for "normal" users so its pretty safe to add to the code base.

I did some playing around with different metrics, but either the sensors are way too good in my test data, or I did just draw a blank on the thinking department.

I think I should plunder all the ccr data I can on the next dive trip and try to figure out any better metrics to detect misbehaving sensors.


It would be great as a first step to even be able to visualise the computers individual sensor data in the profile like the picture in the user manual for more computers.
I am just about to replace sensors so I have some data where the sensors are not in perfect sync which I can send you offline if it will help.


More information about the subsurface mailing list