Ascertaining Uncertainty, Part One

Okay, I’ll grant you that 2 + 2 = 4, but I’m not so sanguine about 2.016 + 1.975 = 3.992.

If we measured the diameter of a pinhead with a yardstick, we will likely get a different number than if we used a micrometer.  We measurement wizards know that it is not only the number that matters, but also, how it was obtained.  By knowing that, we can determine the quality of the measurement.

We express this as the “uncertainty” of a measurement.  This is sometimes referred to as the “error,” but that term implies that there is a mistake. Nearly every measurement we make has an uncertainty.

The first thing we need to do is define the measurement conditions.  For this example, we’ll consider that we are going to measure a voltage.  The expected “nominal” is 3.0 Volts DC.  The nominal is important, because the uncertainty, as we will see, depends on the measurement magnitude.

For the purpose of this treatise, we’ll say we’re going to use a Keithley Model 2000, a high-quality, mid-range, system-capable multimeter.  For the sake of simplicity, we are only going to consider the uncertainty of the instrument, so our result will be based solely on the accuracy of the device.

The specs tell us that the 3.0V measurement will fall into the 10V range of the device.  The resolution of the range is 10µV. The 1 year accuracy spec at that point is ±45 ppm (parts per million) of reading plus 6ppm of range. After a few clicks on Mr. Gates’ calculator application:

(3.0V x .000045 = 0.000135 = 135µV) +     (10V x 0.000006 = .00006 = 60µV) =195uV

So, our total uncertainty is ±195µV.  If our multimeter is reading 03.00000V we know that the “actual” Voltage falls somewhere between 3.000195 and 2.999805 VDC.

The total uncertainty is much larger than the instrument resolution.  This is often the case.  Isn’t it good to know what the uncertainty is?

In the next installment, we’ll look at how to deal with uncertainties based on multiple measured parameters.  In the future, we’ll discuss how to measure the uncertainty of a measurement system.

When we read or hear the phrase above, we think of basketball, or here in Minnesota, hockey as well. But there are more tournaments than just those sports.  This past winter, our local high school started a team to compete in the First Robotics Competition see the First Robotics website.  They got a grant from NASA to fund the purchase of an extensive kit containing the major parts needed to construct a robot.  The kit only provides drive parts and a fairly adaptable control system.  All the mechanical parts needed to accomplish this year’s challenge, must be fabricated.  This is very challenging stuff for high school students.

A major facet of the First program is to bring the students into contact with engineers and technical people working in industry.  In my network, several engineers are very active in the First program.  I’ve always wanted to get involved; but…?

What pushed me over the edge, was an article in the local newspaper that our high school was starting a team and they were looking for volunteer help.  So, I called.  My first contact was with the faculty advisors to the team.  To say they were appreciative is a massive understatement.  A few of the fathers were helping.  Another volunteer is a machinist, who owns a complete machine shop.  Even I must admit he turned out to be the most valuable helper.   The two faculty advisors teach music and biology, respectively.  So when an electrical engineer, who also develops software, offered help they were happy to accept.

It’s been more than a few years since I attended high school.  My wife and I never had children.  I’ve gotten very used to doing things in my usual methodical, analytical, way.  To start spending two to three evenings a week with up to twenty students in an atmosphere of semi-controlled mayhem was quite shock at first!  I learned quickly that you can’t manage the kids.  One must just accept the “ready-fire-aim” methodology that comes with teenagers.  The trick is to be there when they get stuck. Then, with a suggestion, you can help them learn something.

Our regional competition was March 29-31.  It was held in a big arena of the state university, where many of these students have watched games on TV.  I was able to be there two of the three days.

The first day, I arrived separately.  I drove, they came on a bus.  I was surprised and concerned when our two programmers told me that they have made a major change to the software which is untested, and we’d be running it for the first time at the competition.  My first reaction was a bit of anger (I kept it to myself.) In a “grown-up” project, we don’t do things like that.  I asked if they kept the previous version of the software.  They assured me they had.  I decided to stuff the lecture about untested changes, and let them run with it.  This is their robot, and their competition.    Y’know, the change worked perfectly!

The take-away of all this has several aspects.  I was impressed with the intelligence and creativity of the young people.  I was very impressed with their enthusiasm and energy!  Oh, that we could bottle that!  My hope is that some of them will continue science and engineering studies in college.  My biggest realization is that they weren’t the only ones who learned!

Software never measured anything

“The software is the instrument” is the tagline of a well-known data acquisition and software company.  While it is a catchy sales slogan, taken literally, it is total baloney!

The problem is engineers, and management for that matter, mostly focus on the software aspects of test and measurement projects. Management’s focus is somewhat understandable, as software development is often the largest cost. (I’ll write about that someday, soon) Too often, engineers regard the selection of the measurement components carelessly, and only as an impediment to getting started on writing the software.(I’ll write about that someday, as well).

My point is, that at the end of the day, software only manipulates numbers.The method used to obtain those numbers needs rigorous scrutiny.  A few years ago, while I was working at a medical company, a colleague was asked to investigate a product test that was suffering a very high failure rate.  The first thing he did was to do a close examination of the data.  He quickly noticed that all the data points consisted of only two distinct numbers, identical out to many decimal places. One was in the passing range, the other was not.

He brought this interesting fact to my attention.  I asked how the measurement was done. It was obtained from the current read-back function of a programmable power supply.  That raised a red flag for me.  Power supply read-backs are not known for their high accuracy and resolution, as the intended purpose is just to provide a “sanity-check” indication of what the power supply is doing.

I don’t remember the particulars, but let’s say the expected nominal value was about 7 micro-amps.  I was familiar with the power supply, and looked up the specifications.  I found the resolution of the current read-back to be 4 micro-amps!  So, with the quantization uncertainty of +/ – 1 bit, the result was that the number captured was just a happenstance of the A/D converter.  The test engineer had never ascertained if the instrument he selected was capable of making the measurement needed.

Yes, this is an extreme example.  But this was a test being conducted on the manufacturing floor of a medical device company!  Unfortunately, I’ve seen many similar issues over the years.

I’m not saying that we need to do a gauge-capability study on every measurement we make, but at least we need to consider the range of values that may be measured, the expected nominal value, and the specification limits.  Then review the specified accuracy and resolution of the candidate instrument in the area of the anticipated values to determine if the candidate instrument is appropriate for the intended measurement.

Yes, the unofficial tagline of Measurement Engineering, Inc.  is: “software never measured anything!”

Hello World!

Welcome to Measurement Engineering’s Blog site!  The plan for this is to share thoughts on technical and business aspects of instrumentation, measurement and the other areas of our expertise.