VCO Based Sensors

Published in Embedded Systems Programming, June 1991

By Jack Ganssle

I flipped through yet another Digital Design textbook recently. It described all of the standard approaches to dealing with I/O. Processing an analog signal? Well, just feed it into an A/D convertor. The authors made it clear that all serial digital streams go through UARTs, and that everyone senses pure digital signals with some sort of parallel I/O chip (like the 8255).

They're wrong.

The microprocessor's success stems from its attractive cost/benefit ratio: for a few bucks you can add a tremendous amount of intelligence to any electronic product. A lot of embedded systems thrive on the cost reductions made possible by micros; many are so cost sensitive that they rely on extraordinarily clever design to remove every possible chip. We can often replace hardware with software, driving recurring costs down (though there is usually a corresponding increase in engineering costs).

Blending the hardware and software into one unified whole is the best part of designing embedded systems, and by far the most challenging. It requires some knowledge of both ends of the business - this really is an interdisciplinary career!

The textbook was partially correct - a lot of designs profit from conventional design practices. Low cost applications, or those with odd requirements, require a more creative approach.

One particularly interesting problem is transmitting remotely acquired data long distances. Suppose you're building a factory automation system that must measure humidity in a mill located thousands of feet away. No one in their right mind would attempt to send a raw analog signal that far. Noise and transients would swamp the signal.

One nice solution is to place a small microcontroller (say an 8051 or H8 type device) with an on-board A/D right where the measurement is to take place. Then, digitize the data and send it in serial over a fiber optic cable back to the main computer.

Another option is to use some sort of radio. Broadcast (being careful not to violate FCC regulations) the digitized data, saving the expense of running fiber. A variation of this theme is to transmit directly to a satellite. Quite a few unmanned scientific stations, located in mid-ocean or the arctic, return digitized analog this way.

Don't forget cellular phones. A simple controller might acquire and compress data until filling its buffer. Then, it could call a BBS via cellular and upload a block of data. More and more companies are now examining this option.

All of these solutions require a computer right at the sensor's site to digitize, serialize, and then transmit the data. Cost sensitive systems may find the computer too expensive. Or, in very harsh environments the computer might not survive. Remember that right outside your window is a "very harsh" environment, which in my hometown of Columbia, MD, ranges from -20 degrees C in midwinter to +40 in August. Few non-militarized chips will survive these extremes, necessitating the use of very expensive components.

Worse, how do we get a clean source of power to the computer? When implementing a simple monitor that measures temperature in dozens of rooms, do you really want to both run wires (or fiber) from each sensor, plus somehow get power to the little computer boards?

When measuring a simple parameter that changes slowly (like temperature), consider using a Voltage Controlled Oscillator (VCO) in place of the A/D converter and computer. The VCO produces a square wave whose frequency is proportional to input voltage. Any sensor whose output is voltage (or even resistance) can be the VCO's input. Then, the frequency of operation becomes proportional to the value being measured.

If you connect a thermistor to a VCO then varying temperatures produce different frequencies. Transmit this square wave back to the central computer over a pair of wires. Let the computer convert the frequency information back to temperature data.

Depending on the selection of components, 0 degrees Celsius might correspond to 500 Hertz, and 100 degrees to 5000 Hertz. Temperatures between these extremes would be linearly related to frequency.

VCOs have several advantages over conventional data acquisition devices. First, the hardware is trivial. One or two cheap ICs do all of the work at the sensor end. The old CD4000 series offers several VCOs that work over very wide environmental extremes. Second, if the VCO oscillates at reasonable frequencies you can use almost any set of wires to send it back to the main computer - even old phone lines. Finally, you can both provide power and receive signals over one pair of wires.

It might seem impossible that a single wire pair can handle both power and data, but in fact we can multiplex the data stream on

The three resistors on the right hand side of the figure form a voltage divider that develops some potential across R2. The voltage divider is located in the main computer that receives data transmitted by the remotely located sensor. This voltage goes over (possibly long) wires to the sensor assembly consisting of the sensor itself, a VCO, the transistor Q1, and a micropower voltage regulator.

The VCO oscillates a frequency that indicates the value seen by the sensor. When the VCO's output is a 1 (for 50% of a waveform), Q1 is turned on, essentially placing R4 in parallel with the remotely located R2. This of course drops the voltage seen across the wire pair, simultaneously increasing the voltage on R3.

The main computer can measure frequency by watching the voltage on R3 go up and down - the voltage on R3 reflects the VCO's oscillation frequency.

Q1's switching action drags the voltage on the wire pair down, which is nice for transmitting data but not so great for transmitting power. R4, in series with Q1's collector, keeps the voltage from going too close to 0. The micropower regulator converts the wires' data+power to the smooth DC needed to run the VCO chip.

The graph shows the voltage found on the wire pair. A VCO-produced oscillation rides above some DC bias. The regulator runs the VCO from the bias voltage. Obviously, selection of the resistors is crucial to ensure proper operation of the VCO (i.e., the bias must be above some minimum level to operate the chip).

The result - a tiny, simple and cheap sensor module supplies a fairly noise immune data stream over long distances without requiring separate power connections. The downside is that rather complicated code might be needed to make sense of the input data stream.

The computer can't directly read this signal. Being biased (possibly a lot) above 0 volts, it never really goes to a logic zero condition. We'll need some sort of level shifter to remove the bias.

One method is to feed the data stream into an A/D converter. Have the software read the digitized values and watch for transitions from N volts (the bias) to N plus some minimum value. Count the number of transitions received over a period of time (perhaps a second) and convert to frequency.

If the environment is really horrible then the bias might ride up and down a bit. Write slightly more clever software that watches minimum voltage levels and dynamically computes the current bias. Then you can even eliminate costly precision resistors for R1 to R4.

An A/D is a fairly expensive solution. Another option is to differentiate the data (with a resistor and capacitor), square it with a schmidt trigger, and then feed the output into either a parallel input on the CPU or even to an edge-triggered interrupt line. Interrupts are particularly attractive, as the software won't have to painstakingly watch for zero to one transitions. Again, count edges for some time and convert to frequency.

Things get more complex if one CPU manages many of these sensors. I once prototyped an experimental version using a dozen channels feeding into an analog multiplexor which in turn drove an A/D. The software constantly polled all 12 channels, laboriously watching for transitions. This can burn a lot of CPU time. Don't even consider trying to separately test the state of each channel. It's far better to develop a "state vector", a word with a bit representing the state of each channel. Look for transitions by exclusive ORing this against the previously read value.

You could feed all of the channels into the processor's edge-triggered interrupts, but use an interrupt priority controller to resolve the inevitable conflicts that occur when several change from zero to one at the same time.

Special Processors

If high accuracy measurements are needed on a number of channels, it makes sense to look into using special hardware to lift some of the processing burden from the main computer.

Motorola's TPU (Time Processor Unit) is an adjunct to the 68300 family designed specifically to deal with periodic input and output waveforms. Although targeted towards the huge potential market of engine controllers, its on-board time capture registers are ideal for this application.

The TPU accepts up to 16 digital waveforms. You can program it to interrupt on an edge transition from any of the 16 channels, which is not much of an improvement over using multiple interrupts into the main CPU. It does, however, let you hold off the interrupt until a specified number of edges are found. Suppose you tell it to interrupt after 100 low-to-high transitions: the TPU will automatically log the time after these 100 transitions occur, so the code can at its leisure see just how long 100 edges took. It's pretty easy to convert this to frequency, or better to the parameter being measured (say, temperature).

Intel's 8096/196 processors contain built-in support for monitoring four external time events. While perhaps not as powerful as Motorola's product, the Intel chips are part of a highly integrated chip. One part contains I/O, CPU, and memory.

The 8096/196 detects edge transitions and logs the time associate with each in a small on-board FIFO. You can delay the event capture until 8 transitions occur, giving a short term average of the input waveform.

Conclusion

The VCO, coupled with smart code, is an interesting option for sending slowly-changing analog data over long distances. Don't abdicate the hardware portion of such a design to your hardware-only counterparts; they might chose frequency ranges that demand too much from the code, or fail to consider potential software race conditions that occur when several inputs change at the same time.

Look for innovative solutions to your unique embedded problems. Squeeze the hardware and software into one integrated whole to "do more with less".