OT: resolution vs. accuracy

[PrinceNai]

I just finished toying with a temperature and pressure sensor, being much too hot to sleep. It is a very nice view to behold, the sensor breaks down both values down to hundreths. The problem? I just don't believe in them, because it has an accuracy of +-0,5 unit, which means those numbers behind the decimal are mostly just for show. Not to mention way bigger code if I use them all in any calculation.

So, is my sensor accurate or does it just have a (to) high a resolution? I often see those two terms (and precision) all thrown together. Which is wrong, of course. I'd rather have an ACCURATE sensor with relatively low resolution than the one with HIGH RESOLUTION and low accuracy.

ACCURATE means that what it shows is close to the true value of what is being measured. Suppose I measure a temperature of 26,3deg with a sensor and I get a 26,1deg measurement. Close enough. With +-0,5degree accuracy, i could see temperature readings from 25,8 to 26,8. Resolution sucks, though.

Than I have another sensor that shows me 28,345678912345678deg with an accuracy of +-3 deg. While this one has a way better RESOLUTION, it is never close to being as ACCURATE as the first one.

Temperature induced insomnia is no fun :-).

With kindest regards from a way too hot Montenegro,
Samo

[newguy]

The engineer's credo: calculate it to 12 decimal points, measure it with string, mark it with chalk, and cut it with an axe.

A long time ago I had a discussion with my boss regarding something similar. I had inherited a project that calculated a value to 6 significant digits (xxx.xxx). If, however, you took the maximum output of the sensor, and divided that by 4,096 steps which a 12 bit A/D will afford, the actual resolution was 0.4, rounded up. Certainly not an extra 2 digits.

In all reality, extra displayed precision is the domain of people who have no idea what accuracy nor precision actually are (and don't care). All they know is that there's a lot of digits, so those digits must be right.

Regarding your temperature sensor, do a two point calibration: immerse the sensor in ice water and give it time to reach thermal equilibrium. You know that's exactly 0C. Note the reading. Now repeat the experiment with boiling water. Call that 100C (unless you're way up in the mountains in which case you can correct for atmospheric pressure/altitude). Note the reading. Now you can apply a calibration (y = mx + b) and rest assured that your readings are going to be reasonably accurate. Add as many decimal places as you want.

[PrinceNai]

[Ttelmah]

Well done, in trying to get your head round the difference between accuracy
and resolution. It's a very 'classic' problem. For example, the PIC ADC
typically offers a 10 or 12bit resolution, but most people are using as the
'reference' something that often offers perhaps 1% at best. Even worse, a
lot of the ADC's have linearity errors as well, so the actual accuracy will be
below even the reference accuracy....

The 'textbook' answer is that 'accuracy', is how close the measurement
actually is to what is being measured. The 'resolution', is the smallest step
change that can be recorded. Better resolution gets rid of rounding errors,
but does not improve the fundamental accuracy. You can have a system
with a 16bit resolution, but this does not imply you have a genuine '16bit'
ADC.
Getting really good accuracy involves a lot of work. Resolution instead is
relatively easy.
Hearing people rolling out measurements with four decimal places on
systems that would be lucky to manage even 1% accuracy, is all too
common. Then getting just as good result 'using a piece of string', on
the final construction, is where you show how good a workman you actually
are!.

On your sensors, there will even be differences in accuracy dependant on
how they are attached to what is being measured, the surface finishes etc..
The actual 'accuracy', has to include factors like this as well...
The resolution being used, has to exceed the accuracy, or the loss of
resolution will introduce rounding errors. Imagine you have a 1.2344v
source, and measure it with a '100% accurate' DVM offering just 3 decimal
places. It reads 1.234v, so there is an error of 0.0004v, despite the
instrument claiming to be 100% accurate....

There is a third thing. Repeatability. Everything the same, does the sensor
give the same reading?. This is actually more important in many cases
than the 'accuracy', since if the repeatability is good, and you can use
a calibration source of some sort, then this inherently gives accuracy.

[PrinceNai]

Very, very true. The hardest, toughest, meanest class I attended was called "Measurements in electronics". It was a second year class from a 4,5 years program. Just for illustration, two facts: at least half of all the dropouts were because of this one single class. The second is that the University let you pass to next year until the end without finishing this one.

You got a generator, some work on the signal (sine, square, triangle) and at the end a DVM. All with their specs in accuracy and resolution. Maybe they were not sqrt instruments. What will your DVM show in the end? What does it mean when you see that? Something +- what?

What you said in the third point might be one of the best things a microcontroller can do. If you have a reference point, or even better, as Mr. newguy said, two in the range you are interested in, you can cancel out lots of things. If your readings are close at those points, of course.

[asmallri]

There are 3 components. Accuracy, resolution and repeatability. For example, you might decide a sensor reads say 1.5 degrees low implying it has an error in accuracy of 1.5 degrees. Then, knowing you have a resolution of 0.01 degrees you might think that given the accuracy error, you could determine the actual temperature to 0.01 degrees by simply adding the 1.5 degrees to the value reported by the sensor to give you an accurate temperature with a resolution of 0.01 however this failed to take into account repeatability. If repeatability error is 0.5 degrees, then resolution component becomes meaninglessness.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[temtronic]

Also , never ,EVER take ONE reading as being the REAL value ! Always take an average of say 8,16,32 ( some nice 'binary' quantity).
If you only take one, sooner or later, a 'bad' reading will occour that'll play havoc with your product......
For temperatures, I take 10 to do the 'Olympic Average'. Generally speaking 'temperatures' are slow events,so you can take LOTS of reading to get accurate results.

Jay

[asmallri]

[Ttelmah]

That actually is the 'Olympic' averaging that Jay refers to.
The name comes from a number of Olympic events like ski jumping, where
the highest and lowest scores are rejected.

Simple averaging. Add a set of numbers, and divide by how many values
there are. Most basic average, and for things with random noise 'great'.
Rolling averaging. Add each new value to a rolling sum. Divide this by
a value, and return this result as the 'average'. Subtract this from the sum.
Gives an average with decreasing weight paid to values 'back in time'.
Easy to implement, but does not reject 'spike' noise.
Median average. Take a set of values, sort, and return the middle one.
This is actually the best way to reject spike sources.
Olympic average. Take a set of numbers remove the highest recorded and
lowest recorded, and take a simple average on the remaining ones.

Then there are combinations of these. In fact the Olympic average done
with just three numbers, returns the median value. You can take a number
of median values, and perform a normal average on these, etc. etc..

The Olympic average is a very good general use algorithm. If (for example),
you for each new value, test if it is greater than 'max', and if it is replace
max, then test if it is less than 'min', and if so replace min. Add to a sum.
Then after (say) ten values, subtract 'max', subtract 'min', and divide
the 'sum' by eight, you have the average of the median eight values from
the set of ten. Reset max, min and sum, and carry on. Great thing here is
that the averaging smooths out random noise, while removing max and min
rejects momentary spike noise. So a quick to perform algorithm, that
rejects most normal types of noise.
This can be done with any binary number of samples plus two, to give
nice efficient code. The lower the number of samples, the less it smooths
random noise, but the better it is at rejecting spikes.

[asmallri]

You learn something every day. Thanks
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!