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.
//Anton
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.
Steve
More information about the subsurface
mailing list