Validating data acquisition saves debugging time
Scott Rosenthal
May, 1991
One of the more difficult aspects of designing an embedded system is proving that it
works as intended. Part of the problem is that "working" takes on different
meanings if you’re the designer, salesperson or customer. However, as the designer
you’re responsible when something doesn't meet expectations. Therefore, you must do
everything possible not only to ensure that the system functions properly but also to
satisfy other parties involved in the project. Luckily numerous techniques can quantify
system performance such that others, who might not be literate in the jargon of the field,
can also understand that what you've been slaving over for the past six months actually
performs the intended task.
For an embedded measurement system to do its job, it obviously needs a sensor or
transducer such as a thermocouple or thermistor for measuring temperature, strain gauges
for weighing items and photodetectors for measuring light. After performing suitable
conditioning, an instrument can use these signals for monitoring or control.
Unfortunately, in the real world lots of little problems can creep in and render the
instrument useless. For example, too much current through a thermistor causes self-heating
and distorts the measurement. Similarly a strain gauge is sensitive to line-frequency
interference, and ambient light can destroy photodetector readings. In this regard
remember that one of your design goals isn't to isolate sensors from such error sources,
but instead you want to prove to yourself and the customer that the software interface and
its interaction with the hardware are functioning properly.
Feed a voltage in
A simple way to demonstrate that a system's working properly is to feed it a known
voltage in place of the sensor and make sure the software correctly reads and converts it
(Fig 1). This technique removes uncertainties associated with sensors and concentrates
your effort on verifying the software. This technique came in handy for me a while back
when a customer asked me to bail out a design in which nothing was working, but everyone
was screaming that the photodetector had to be the culprit. I substituted a precision
voltage source for the photodetector, showing that not only did the software have a bug in
it, but the A/D converter wasn't functioning correctly, either. In this situation
questions about the detector confused the situation and drew attention away from the real
problems.
Unfortunately, many people fail to use this technique because it's so simple. In
complicated systems where many interactions happen at once, measuring a known signal can
isolate potential problem areas. For example, consider how to debug a fluorescence
detection system where the instrument illuminates some fluorescent dye with pulsed
ultraviolet light and measures the amount of light the dye emits. Not only must the system
determine the amount of light, the measurement also depends on whether the dye system is
functioning properly. Thus you must first break the connection between the illumination
and detection and feed a known voltage into the system. That works? Great. Now take a step
back and, using suitable filters and light levels, channel the UV light directly to the
detector. Does the system still work? If so, any problems are now most likely in the dye
system.
You can easily demonstrate this technique to any layman. Just remember that as the
system's programmer you have no control over sensor measurements. Scratching the deepest
recesses of my mind brings back an old word: GIGO---Garbage In, Garbage Out. Don't confuse
an instrument's garbage readings with a software problem. Isolate the two.
A similar process is also valuable for proving out the mathematics in an instrument.
Too often I've seen embedded systems where, during the debug phase, no one knew if the
bugs were hardware or software problems. Like before, simply feed known data into the
program to check the mathematics. If generating test cases with a calculator is too
cumbersome, use a spreadsheet program. Not only is it helpful to see all the data and
formulas in a spreadsheet, this method provides an easy way to document how you debugged
the system.
A tip for process tuning
Now that you've got the instrument measuring properly, the next task is to control a
process based on the measurements. How do you prove that the control portion works
properly? Just because it appears to do so doesn't mean it's really working. A classic
example is a PID controller for dynamically managing a process in real time. Compare it to
a home thermostat, which is a primitive version of the classic Bang-Bang controller that's
either full On or full Off. A PID version of a thermostat, in contrast, would gradually
reduce the amount of heat the furnace puts out as the ambient temperature reaches the
desired setting; then it would trickle in enough heat to keep the temperature from varying
by more than a set amount. The system is always on guard for perturbations such as a door
opening or a breeze sucking air through the chimney.
If you look at a graph of the ambient temperature, the result for an efficient PID loop
should be reasonably flat. In that case, it's simple to prove to an unsophisticated
customer or even your boss that your miraculous new design is properly controlling the
process. Here, rather than supply reams of tabular data to prove the point, a graph
showing the control system's reactions to external stimulus is clearer proof (Fig 2).
When this situation comes up in my work, I use the system's serial port to transmit PID
input variables such as the room temperature and ventilator or heater control positions to
an external computer. The computer collects this data using either a custom program that
samples data every N sec or the communications module of Microsoft Works. The custom
program saves data as a comma-delimited ASCII list. After collecting the data you can
easily transfer it into a spreadsheet program such as that in Works for manipulation and
graphing. In addition, because the collection process is automatic, you avoid the work of
manual transcription errors. The spreadsheet allows you to try various mathematical
functions such as IIR or FIR filtering, and the graphics built into most spreadsheets
today make it easy to generate plots that demonstrate the effects of outside perturbations
on the system.
The result is quick proof of how the system works, presented in an easy-to-understand
manner. You can even use such a custom collection program to help hardware designers look
for drift and stability problems by evaluating data collected over several days. Software
helping the hardware, what will they think of next?
* * *
Last January this column addressed my uses of serial EEPROMs, and one example showed
such a device housed in a connector to store probe configuration data. Subsequent to that
article's appearance I received a letter from A Rather Large Company (ARLC), indicating
that it had patented the idea in 1985 and would I consent to licensing its technology? I
was appalled---not only because I've been using this technique since before the patent
date, but also because of the way American businesses are trying to squeak out profits.
For instance, last year a major semiconductor firm spun off a litigation department that
reportedly became one of its most profitable divisions. That group's task way to track
down companies infringing on patents. Apparently ARLC is trying to become profitable by
following the same route.
Obviously, ARLC has the right to pursue patent infringements. My complaint, though, is
that by scouring magazines and going after the writers, they’re shutting down the
free flow of information. A major difference between patents and copyrights is that
copyright is explicitly labeled whereas a patent isn't known unless you research it or
it's brought to your attention. But how can an author in a technical field risk the
discovery that somehow, something that seems so intuitive and non-novel, could've actually
been patented? I've talked to several publishers and authors, and none have heard of
technical writers being targeted like this before. I must now restrict myself to obvious
examples and remove personal experiences so that I don't step on anyone else's toes. It's
then up to you to investigate whether a concept is patentable or has already been
patented. Once again, John Q Public gets abused for the sake of one company's bottom line.
PE&IN
Adapted from an article that appeared in Personal Engineering & Instrumentation
News.
Return to the article index.
|
