Dr. Strangepete, or How We Learned to Stop Worrying and Love the Calibration Grind

We’ve been somewhat quiet at FieldKit for the past few months, working hard to bring our new and improved water modules into being. Here is a sneak peek into the kind of work we’ve been doing and some of the complicated problems we’ve encountered when it comes to building things that measure other things.

We knew we were in trouble when we saw a temperature of -1023.0 °C.

As you may be aware, absolute zero, the lowest temperature in the universe, is -273.15 °C. There is absolutely no physical way for a temperature to be lower than that, let alone to get to -1023 °C. Add to that the fact that 1023 is a particularly significant number for those of us working in the digital world, as it’s just one less than 210 (meaning that there’s some sort of error happening which gives us an output with all 1s). These things pointed to either a hardware or firmware error. As it turns out, it was a little bit of both.

Let’s rewind a bit: when FieldKit was first building out our water sensors, we made the decision to use another company’s OEM (Original Equipment Manufacturer) circuit, packaged as a castellated module, as part of our design. This allowed us to meet our goal to get FieldKit out into the world quicker than we would have if we designed this circuit in house. But as we discovered, the OEM modules that we were using to measure temperature, electrical conductivity, pH, dissolved oxygen, and oxidation reduction potential were suspect, and we found that pretty often they would lie to us. These modules would give us values that just made no sense. Top that off with the fact that they were drawing loads of current, limiting our battery life, and we knew we were in a bad situation. To learn more about this discovery process, check out our blog post on Building a Better FieldKit Water.

But that wasn’t all. When we looked at the calibration methods that the OEM told us to use, we were not impressed. Most of these were just single-point functional checks, which is an absolute joke to any metrologist worth their salt. What do I mean? Each kind of sensor and sensor interface has a transfer function, a behavior that allows you to put in one type of parameter (say, temperature) and get out another (in this case, resistance). When we quantify that transfer function, we can say that we’ve made a measurement. The measurand is the thing that we’re measuring, while the measurement comes at the end of what’s known as a signal chain.

In the case of the temperature module, the sensor is a tiny piece of platinum that changes its electrical resistance in a way that’s predictable and repeatable when its temperature changes. This gets used as one of the two resistors in what’s known as a voltage divider, a passive linear circuit allows us to figure out what the proportion of the temperature sensor’s resistance is to a known resistance. That number comes out as a voltage value between 0 and 2.048 V. Finally, that voltage goes into an analog to digital converter (ADC), which changes the signal from analog to digital, giving us a number that we can do math with on a computer. In order to figure out what this digital number means in terms of the initial measurand, we do a calibration, which creates a mathematical function that takes into account the entire signal chain (sensor, voltage divider, and ADC, in this case), and gives us °C out from a given digital number.

In order to create this calibration function, we need to have a number of points across the range of operation of the whole system. If you have one or two known points, you have whole families of types of functions that could satisfy fitting with those two points of data. In order to figure out what kind of function you need for certain, you need a minimum of three points***. So as we began to plan, our new design needed to be compatible with that. In addition, we found that we could even do better calibrations of the OEM modules that we were using by putting them into their factory default state, then calibrating against the raw numbers they gave us. That meant that, as long as the OEM hardware was giving us numbers that varied in a way that was deterministically linked to the variation of a physical parameter or measurand (the thing we’re measuring), we could use math to make the two numbers line up. So that solved a part of our firmware problem. Now for the hard(ware) part.

We have five different types of probes that we needed to rebuild for, based on what we had learned. Two of these (temperature and electrical conductivity) are resistance mode, or ohmic, meaning that we measure a resistance through the probe. The other three (pH, dissolved oxygen, and oxidation reduction potential (ORP)) are voltage mode, or galvanic, meaning that we’re measuring a voltage across the probe. Despite being similar, each probe requires a different circuit to allow us to get a measurement from it (which we may have learned the hard way with pH and ORP—but that’s another blog post). For both dissolved oxygen and ORP, we need to measure the voltage across the probe, but for dissolved oxygen, we additionally need to measure atmospheric pressure in order to know what the potential dissolved oxygen content in the water we’re studying is. This necessitates adding an additional sensor. For pH, the amount of current that the probe can put out is too low even for the extremely low current demands of the ADC, causing us to need a voltage follower, a buffer that allows us to demand almost no current at all from the pH probe. This follower is at unity gain, or equal voltages in and out. We also use the output signal from this voltage follower as what’s known as a guard signal, which allows us to cancel out noise that’s created by other electromagnetic fields, a must when you’re dealing with highly sensitive voltage sensing. In other words, it’s complicated.

As for the ohmic sensors, temperature is by far the simpler one, requiring only a bias resistor to create a voltage divider to read the voltage from. However, electrical conductivity is a whole ‘nother ball of fish. This is because it requires sending a current through conductive water (or a conductive aqueous solution), which leads to ion migration. When enough OH- and H+ ions migrate, you wind up with H2 and O2, meaning that you’ve just started electrolysing water into two diatomic gasses, thus making tiny (flammable) bubbles. If we can avoid doing that, that’s a good thing. Aside from this, the ion migration itself changes the conductivity by what’s known as the double-layer effect, where the ions stop the water in between the electrodes of the probe from conducting as much electricity. So, we needed a way to send a very brief pulse of electricity through the water, and measure its resistance. By using one of the chips that we already had on the boards (the MCP23008 I/O expander), we were able to create a 1 msec pulse that we were able to read with our ADS1219 ADC in high speed mode. This didn’t allow enough time for ion migration (and thus potentially dangerous results), and allowed for repeatable conductivity measurements through another voltage divider and into the ADC.

So now we had to test all of this. Sets of four of the prototypes for each modality were placed on the backplane of the same FieldKit, and calibrations were done. Then measurements of a known sample for that modality were taken again. And again. These cycles of characterization and adjustment allowed us to ensure that the sensors we use and the circuits that we use them with are exquisitely accurate, within a maximum uncertainty of 2%.

Long story short, we are now happy to offer you our very own, open source measurement circuits and module boards. This represents another pleasant departure from our previous hardware iteration, as the OEM that we were working with does not publish any information whatsoever about the circuits on their modules, and even has a patent on their electrical conductivity measurement method. This would preclude us or any other open source organization from using it without using their module in items to be offered for sale, lest we then negotiate some sort of royalty/licensing agreement with them. Since we are not interested in hiking our prices to pay tribute to a proprietary technology, we instead went our own way to bring these to you. Look for them in the shop again soon!

If you’re curious about calibration after reading this, please check out our video How can I trust anything? Transfer Functions, Calibration, and the Art of Uncertainty on our YouTube channel.

***Technically, if you are working with a less-thoroughly-studied sensor, you should do a four-or-more-point calibration in order to establish the function you need, but because we are working with well-established sensors and have a general sense of the type of function (linear, parabolic, etc.) to expect, three points will suffice.

Finally: A tip of the hat to Stanley Kubrick for the inspiration for our title.