7
9
25274 75349
0 1>
CIRCUIT
CELLAR
®
www.circuitcellar.com
T H E M A G A Z I N E F O R C O M P U T E R A P P L I C AT I O N S
$4.95 U.S. ($5.95 Canada)
#162 January 2004
ANALOG TECHNIQUES
Wire Tracker
Temperature-Testing
Chamber
Single-Pin A/D Solution
Lock-In Milliohmmeter
Now with
instrumentation-quality
programmable analog.
Powerful new programmable analog and digital
blocks with memory and MCU for less than $2.
Winner of the EDN Innovation of the Year award,
our PSoC
TM
Programmable System-on-Chip
TM
device
is changing the face of embedded design.
Replace 1,000s of fixed-function devices
with a couple of keystrokes
Dynamically reconfigure a PSoC device,
changing functionality on the fly in any
application
Select from hundreds of predefined
blocks in our mixed-signal library
Already designed into 1,000s of applications;
check out our online app note library
PSoC
™
Mixed-Signal Array.
It’ll change the way you
think about embedded design.
Instrumentation Amp with Driven Shield
Front End with Adjustable Gain
Difference Amp
Instrumentation Amp 2
CYPRESS ENHANCED ANALOG
™
(CEA
™
)
•
Rail-to-rail analog
•
Instrumentation amps
•
Lower voltage offset
•
Lower input leakage currents
•
Programmable gains
•
Better stability
One of 1,000s of examples of programmable analog blocks.
PSoC Mixed-Signal Arrays with M8 Microcontroller
CY8C27X
CY8C24X
CY8C22X
126
3
8
4
4
16K
4K
2K
256
256
256
low as $1.99
low as 99¢
low as 69¢
CEA ANALOG BLOCKS
DIGITAL BLOCKS
HI REL SONOS FLASH
SRAM
COST
Reduce board size and BOM up to 80%
before
after
Check out our free online training and our 4-hour applications support:
w w w . c y p r e s s . c o m / a d / p s o c - c e a 1
©
Cypress
Microsystems,
Inc.
2003.
PSoC,
Programmable
System-on-Chip,
Cypress
Enhanced
Analog
and
CEA
are
trademarks
of
Cypress
Microsystems,
Inc.
All
other
trademarks
are
the
property
of
their
respective
owners.
Digital Oscilloscopes
•
2 Channel Digital Oscilloscope
•
100 MSa/s
max single shot rate
•
32K samples per channel
•
Advanced Triggering
•
Only 9 oz and 6.3” x 3.75” x 1.25”
•
Small, Lightweight, and Portable
•
Parallel Port
interface to PC
•
Advanced Math options
•
FFT Spectrum Analyzer options
DSO-2102S
$525
DSO-2102M
$650
Each includes
Oscilloscope
,
Probes, Interface Cable, Power
Adapter, and software for
Win95/98, WinNT, Win2000
and DOS.
•
40 to 160 channels
•
up to 500 MSa/s
•
Variable Threshold
•
8 External Clocks
•
16 Level Triggering
•
up to 512K samples/ch
•
Optional Parallel Interface
•
Optional 100 MSa/s Pattern Generator
LA4240-32K (200MHz, 40CH)
$1350
LA4280-32K (200MHz, 80CH)
$2000
LA4540-128K (500MHz, 40CH)
$1900
LA4580-128K (500MHz, 80CH)
$2800
LA45160-128K (500MHz, 160CH)
$7000
Logic Analyzers
• 24 Channel Logic Analyzer
• 100MSa/S max sample rate
• Variable Threshold Voltage
• Large 128k Buffer
• Small, Lightweight and Portable
• Only 4 oz and 4.75” x 2.75” x 1”
• Parallel Port Interface to PC
• Trigger Out
• Windows 95/98 Software
LA2124-128K (100MSa/s, 24CH)
Clips, Wires, Interface Cable, AC
Adapter and Software
$800
All prices include Pods and Software
I
n this issue, you’ll find articles about two of the top prize-winning proj-
ects in the Motorola Flash Innovation 2003 Design Contest. Richard
Dreher, of the U.S., took home Grand Prize for his Remote Observation
Station (p. 26). Robert Lacoste, of France, won First Prize for his Smart
Tracker 2 (p. 10). Both projects are designed around the Motorola
MC68HC908QY4 microcontroller.
The impulse to start a project can come from surprising sources. I think
our contests offer some incentive, but the real impetus is the entrants’ own
drive and ambition to design something interesting, useful, and some-
times even groundbreaking. Richard was inspired to build his observation
tower after hearing countless tales about the indigenous wildlife in north-
ern Wisconsin. Viewing wild animals can prove difficult—even with binoc-
ulars—when you have to remain at a lengthy distance to keep from scar-
ing them away. So, Richard wanted to figure out a way to see them clear-
ly without getting physically close.
Building the observation tower was one thing, powering it was anoth-
er. Electric power was illogical considering that the tower would be in the
woods. Solar power would do the trick; however, that meant Richard
needed an effective charge controller to handle the voltage swings
inevitable with solar energy. Not wanting to trek to the station regularly to
check on things, he needed something different—something better—than
a standard controller. So, he designed a unique charge controller system
that remotely monitors the charge level. Using wireless transmission, he
was able to build an observation station that intrudes little on the land-
scape (keeping the wildlife at ease), and provides him a close-up view of
Wisconsin black bears, timber wolves, and whitetail deer via his TV.
Practicality was the driving force behind Robert’s Smart Tracker 2. He
endeavored to solve the wire question. Dealing with a rat’s nest of uniden-
tified wires tries a person’s patience. Robert’s problem with off-the-shelf
solutions is that they require you to identify a ground connection. Plus, the
cost can exceed the average person’s budget. So, how do you untangle
your mess of wires? Robert’s system consists of two boxes: the first is a
10-channel transmitter that sends test signals to the wires (up to 10), and
the second contains a probe that can be connected to a pair of wires for
identification. Notable benefits are, of course, that the system doesn’t
need a ground connection, and that it can also identify short circuits. And
yes, the wire tracker is inexpensive to build.
In addition to the Remote Observation Station and Smart Tracker 2,
there are a number of other innovative and helpful projects in this issue.
For example, Dick Cappels designed a digital lock-in milliohmmeter based
on Atmel’s AT90S2313 microcontroller (p. 50). Like Richard and Robert,
Dick had looked at off-the-shelf options, but decided they were too expen-
sive. Still, he wanted a way to check the trace resistance on his PCBs,
identify shorted traces, and measure the contact resistance of switches
and connectors. With a microcontroller and an op-amp, Dick was able to
inexpensively build his own milliohmmeter that effectively improves ana-
log performance.
4
Issue 162 January 2004
www.circuitcellar.com
CIRCUIT CELLAR
®
EDITORIAL DIRECTOR/FOUNDER
Steve Ciarcia
MANAGING EDITOR
Jennifer Huber
TECHNICAL EDITOR
C.J. Abate
WEST COAST EDITOR
Tom Cantrell
CONTRIBUTING EDITORS
Ingo Cyliax
Fred Eady
George Martin
George Novacek
Jeff Bachiochi
NEW PRODUCTS EDITOR
John Gorsky
PROJECT EDITORS
Steve Bedford
Ken Davidson
David Tweed
ADVERTISING
PUBLISHER
Dan Rodrigues
E-mail: dan@circuitcellar.com
ASSOCIATE PUBLISHER/DIRECTOR OF SALES
Sean Donnelly
Fax: (860) 871-0411
(860) 872-3064
E-mail: sean@circuitcellar.com
Cell phone: (860) 930-4326
ADVERTISING COORDINATOR
Valerie Luster
Fax: (860) 871-0411
(860) 875-2199
E-mail: val.luster@circuitcellar.com
ADVERTISING ASSISTANT
Deborah Lavoie
Fax: (860) 871-0411
(860) 875-2199
E-mail: debbie.lavoie@circuitcellar.com
CONTACTING CIRCUIT CELLAR
SUBSCRIPTIONS:
INFORMATION: www.circuitcellar.com or subscribe@circuitcellar.com
To Subscribe: (800) 269-6301, www.circuitcellar.com/subscribe.htm, or
subscribe@circuitcellar.com
PROBLEMS: subscribe@circuitcellar.com
GENERAL INFORMATION:
TELEPHONE: (860) 875-2199 Fax: (860) 871-0411
INTERNET: info@circuitcellar.com, editor@circuitcellar.com, or www.circuitcellar.com
EDITORIAL OFFICES: Editor, Circuit Cellar, 4 Park St., Vernon, CT 06066
NEW PRODUCTS: New Products, Circuit Cellar, 4 Park St., Vernon, CT 06066
newproducts@circuitcellar.com
AUTHOR CONTACT:
E-MAIL: Author addresses (when available) are included at the end of each article
CIRCUIT CELLAR®, THE MAGAZINE FOR COMPUTER APPLICATIONS (ISSN 1528-0608) and Circuit Cellar Online are pub-
lished monthly by Circuit Cellar Incorporated, 4 Park Street, Suite 20, Vernon, CT 06066 (860) 875-2751. Periodical rates paid at
Vernon, CT and additional offices. One-year (12 issues) subscription rate USA and possessions $21.95, Canada/Mexico
$31.95, all other countries $49.95. Two-year (24 issues) subscription rate USA and possessions $39.95, Canada/Mexico
$55, all other countries $85. All subscription orders payable in U.S. funds only via VISA, MasterCard, international postal money
order, or check drawn on U.S. bank.
Direct subscription orders and subscription-related questions to Circuit Cellar Subscriptions, P.O. Box 5650, Hanover, NH
03755-5650 or call (800) 269-6301.
Postmaster: Send address changes to Circuit Cellar, Circulation Dept., P.O. Box 5650, Hanover, NH 03755-5650.
For information on authorized reprints of articles,
contact Jeannette Ciarcia (860) 875-2199 or e-mail jciarcia@circuitcellar.com.
Circuit Cellar® makes no warranties and assumes no responsibility or liability of any kind for errors in these programs or schematics or for the
consequences of any such errors. Furthermore, because of possible variation in the quality and condition of materials and workmanship of read-
er-assembled projects, Circuit Cellar® disclaims any responsibility for the safe and proper function of reader-assembled projects based upon or
from plans, descriptions, or information published by Circuit Cellar®.
The information provided by Circuit Cellar® is for educational purposes. Circuit Cellar® makes no claims or warrants that readers have a right to
build things based upon these ideas under patent or other relevant intellectual property law in their jurisdiction, or that readers have a right to
construct or operate any of the devices described herein under the relevant patent or other intellectual property law of the reader’s jurisdiction.
The reader assumes any risk of infringement liability for constructing or operating such devices.
Entire contents copyright © 2001 by Circuit Cellar Incorporated. All rights reserved. Circuit Cellar and Circuit Cellar INK are registered trademarks
of Circuit Cellar Inc. Reproduction of this publication in whole or in part without written consent from Circuit Cellar Inc. is prohibited.
CHIEF FINANCIAL OFFICER
Jeannette Ciarcia
CUSTOMER SERVICE
Elaine Johnston
ACCOUNTANT
Jeff Yanco
ART DIRECTOR
KC Prescott
GRAPHIC DESIGNER
Mary Turek
STAFF ENGINEER
John Gorsky
QUIZ COORDINATOR
David Tweed
Cover photograph Chris Rakoczy—Rakoczy Photography
PRINTED IN THE UNITED STATES
When Off-the-Shelf Won’t Do
jennifer.huber@circuitcellar.com
TASK MANAGER
6
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
January 2004: Analog Techniques
The Innovative Wire Tracker
Robert Lacoste
Motorola Flash Innovation 2003 Design Contest Winner
Build an Inexpensive Temperature-Testing Chamber
Richard Dreher
Motorola Flash Innovation 2003 Design Contest Winner
Fault-Tolerant Electronic Systems
Single-Pin Analog-to-Digital Conversion Techniques
Microcontroller-Based Digital Lock-In Milliohmmeter
Design a Unique PC Sound Card Curve Tracer
George Steber
Harness the Power of the ’Net with the XPort Server
Jeff Bachiochi
TASK MANAGER
When Off-the-Shelf Won’t Do
FEATURES
COLUMNS
DEPARTMENTS
PRIORITY INTERRUPT
Be Careful How You Define “Convenient”
Remote Observation Station (p. 26)
Temperature-Testing Chamber (p. 16)
Check out AVR today at www.atmel.com/ad/fastavr
Introducing the Atmel AVR
®
. An 8-bit MCU that
can help you beat the pants off your competition.
AVR is a RISC CPU running single cycle instructions.
With its rich, CISC-like instruction set and 32 working registers,
it has very high code density and searingly fast execution–up to
16 MIPS. That’s 12 times faster than conventional 8-bit micros.
We like to think of it as 16-bit performance at an 8-bit price.
With up to 128 Kbytes of programmable Flash and EEPROM,
AVR is not only up to 12 times faster than the MCU you’re using
now. It’s probably 12 times smarter, too.
And when you consider that it can help slash months off your
development schedule and save thousands of dollars in project
cost, it could make you look pretty smart, too.
AVR comes in a wide range of package and performance
options covering a huge number of consumer and industrial
applications. And it’s supported by some of the best development
tools in the business.
So get your project started right. Check out AVR today at
www.atmel.com/ad/fastavr. Then register to qualify for your free
evaluation kit and bumper sticker. And get ready to take on the world.
Our AVR microcontroller is
probably 12 times faster than
the one you’re using now.
(It’s also smarter.)
AVR 8-bit RISC Microcontrollers
© 2002 Atmel Corporation. Atmel and the Atmel logo are registered trademarks of Atmel Corporation.
8
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
Edited by John Gorsky
NEW PRODUCT NEWS
NONVOLATILE D/A CONVERTER
The X79000 is a new series of DACs targeted at the
bias adjustment and calibration market. This family of
products integrates a single-channel, 12-bit nonvolatile
DAC, voltage reference with selectable gain and level
shift, a configurable output
buffer, and general-purpose
EEPROM into a single-chip
solution. The flexibile X79000
series can achieve effective
resolution of 14 to 16 bits by
using its programmability and
nonvolatile storage at a 12-bit
DAC cost.
X7900 devices provide several
nonvolatile registers whose val-
ues are restored during power-
up, making them capable of
operating independently of a
microcontroller. Users can con-
figure a nonvolatile initial
value—a Push-Pot style DAC
control—that allows increment-
ing or decrementing from the
initial DAC value in either one
least significant bit (or byte) or word steps, and nonvolatile
selection of both the upper and lower DAC ladder voltages
using a single internal voltage reference. A serial interface
allows for on-the-fly selection of these values without any
hardware changes using an inter-
nal variable gain and level-shift
circuits. This provides digital
selection for course- or fine-volt-
age output span.
The devices also feature an
unbuffered or buffered output
(configurable via external feed-
back) options and 64 bytes of gen-
eral-purpose EEPROM to store
manufacturing information, cali-
bration coefficients, and other
important information.
The X79000, X79001, and
X79002 in 20-lead TSSOP cost
$2.75, $2.70, and $2.65, respec-
tively, in 1000-piece quantitles.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
9
You may contact the quizmasters at eq@circuitcellar.com
CIRCUIT CELLAR
—
Test Y
Your E
EQ
Problem 1
—Assume that V
BE
for both transistors is 0.7 V
and V
CE(sat)
is 0.4 V. How much current gain is required
in Q1 and Q2?
Problem 2
—At what input voltage does the output switch?
Problem 3
—Why is R2 required? What about R5?
Problem 4
—What is the purpose of C1? Of D1?
Contributed by David Tweed
Edited by David Tweed
A designer was given a set of requirements for an
interface circuit for a piece of marine electronics equip-
ment. The equipment has a digital input that is meant
to accept 0- to 5-V signals. It consists of a 1000-
Ω
resistor in series with the LED of an optoisolator. The
cathode of the LED is connected to ground.
The interface circuit must accept an input voltage
that swings between 0 and 12 V or 0 and 24 V nomi-
nally, depending on whether the boat has a 12- or 24-V
(negative ground) electrical system. This input might
come from a simple mechanical switch tied to the posi-
tive terminal of the boat battery. However, the boat’s
electrical system can go as high as 30 V when the bat-
tery charger is operating, and brief surges to
±
200 V
can occur as well. Also, the circuit might be hooked up
backwards by inexperienced personnel, so continuous
inputs of up to –30 V might be applied. A 5-V power
supply is available from the equipment.
The designer came up with the circuit shown here.
V
TH
is a 3-V rail supplied by a small three-terminal reg-
ulator running off of the 5-V supply. Let’s discuss some
key points relating to this design.
C1
D1
R2
200 k
V
TH
Q1
R4
4.32 k
R3
1.00 M
R5
10 k
+5 V
Load
Output
1 k
Input
R1
100 k
Q2
lights in red, and the LED correspon-
ding to the wire connected to the
green inputs lights in green.
Sounds really easy, no? And what
about short circuits? More than one
LED lights in green or red, identifying
all of the wires short-circuited to each
input. It is a little tedious to explain,
but its use is straightforward. Take a
look at Photo 2 for clarification.
HOW DOES IT WORK?
As an experienced designer, you’re
probably thinking that the design is a
simple one—one microcontroller at
each end, and that’s it. You’re right,
and you’re wrong. If you think the
design is that simple, then stop read-
ing, grab some paper, draw the project,
and ask yourself: Is it working reliably
without any ground connection? Is it
identifying simultaneously and naming
the wires connected to each input of
the probe? Is it detecting and identify-
ing short circuits on both inputs of the
probe even if there are multiple short
circuits on every side? If you think you
have it worked out, send me your idea.
I’ll give 1 lb of mixed electronic com-
ponents to the first reader who sends
me a working concept based on an idea
other than the one described in this
article! Of course, if your design does-
n’t work, you owe me the same quanti-
ty of components. Now, let’s get to
the details of the design.
As in a lot of successful projects,
the working concept for this one came
from an unusual association of tech-
niques: UART-like digital transmis-
10
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
D
ealing with a tangle of unidenti-
fied wires can be a painful experience.
In such situations, all of the wires are
usually the same color, thanks to
Murphy’s Law. You may have a DMM
somewhere, and you can check it wire
by wire; however, the situation
becomes more than painful if the two
ends of the cable are not in the same
room (e.g., when you are installing a
new LAN or alarm system). And who
can stay quiet when a devil also has
introduced short circuits between
some of the wires?
You could purchase a wire identifica-
tion device that uses separate transmit-
ter and receiver boxes, but they all
require some kind of ground connection
(to at least one identified wire), and
they are usually not happy with short
circuits. Moreover, they aren’t cheap.
For these reasons, I decided to design
my own. I used the Motorola Flash
Innovation 2003 Design Contest as an
additional excuse. The result is the
Smart Tracker 2
With Robert’s prize-winning wire tracker, you can identify wires in even the most tangled sit-
uations. As you’ll see, the design is simple and inexpensive.
Smart Tracker 2, which is the inexpen-
sive wire tracker depicted in Photo 1.
In this article, I first describe the
device from the standpoint of an end
user. Then, I introduce you to the key
ideas behind the design; as you’ll see,
the design is not as simple as it
appears. Finally, I present the design
details and firmware, but that’s the
easy part.
END USER’S STANDPOINT
The Smart Tracker 2 is a compact,
low-cost device built as two separate
boxes. The first box is a 10-channel
transmitter that injects test signals into
up to 10 wires. On the other side, a
small probe can be connected between
any pair of wires and can identify both
of them simultaneously without a
ground connection. Moreover, even if
short circuits are present between
wires, the probe identifies all of them!
Using the Smart Tracker 2 is
straightforward thanks to an easy
color-coding scheme. Each of
the transmitter outputs is iden-
tified by a different color and
ended by a small grabber. These
outputs are connected to one
end of the wires to be identified
without any particular order.
The receiver has two inputs—
red and green—and 10 bicolor
red-green LEDs, each of which
is associated with one of the
transmitter colors. Connect the
two inputs to any pair of wires.
The LED corresponding to the
wire connected to the red input
FEATURE ARTICLE
by Robert Lacoste
Photo 1—
The Smart Tracker 2 is composed of a transmitter and
a probe with easy color-coding indications. Both components are
small and self-powered.
The Innovative Wire Tracker
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
11
measure the absolute voltage level of
the input bits.
Now you have the full picture. All
of the binary words received by the
probe with a low voltage after the
unbalanced bridge correspond to wires
connected to hot (higher) input. Those
received with a high voltage corre-
spond to wires connected to the cold
(lower) input.
THE TRANSMITTER
Figure 3 is a schematic diagram of
the transmitter. The design is simple.
An MC68HC908QY4 flash memory-
based microcontroller drives each of
the 10 outputs through a diode and a
current-limiting resistor. Pull-down
resistors were added to each output so
that at least one of them will provide a
ground loop-back connection with the
probe inputs. The diodes implement
the analog adder. If two outputs are
short-circuited, the signals are added.
The MC68HC908QY4 was a perfect
match for this project. I needed a 3-V
powered chip to use two 1.5-V AAA
batteries, low power consumption,
10 I/O pins in a small package, an on-
board oscillator precise enough for
low-speed serial data transfer, an
ADC, and a low-cost device.
That’s close to the
MC68HC908QY4’s specifica-
tions. Moreover, the flash
memory is a helpful feature
in the debug cycle, especially
with Motorola’s architecture
enabling you to use only one
pin dedicated to in-circuit
programming.
I included an in-circuit
programming header as well
as a status LED, which
blinks under software con-
sions and analog-domain tricks. For
simplicity, at first assume that there
is a ground connection. The transmit-
ter should inject something in each
line. The first trick involves the trans-
mitter successively injecting a binary
word on each of its 10 outputs using a
software-based bit-banging UART
transmitter: an ASCII “A” on the first
line, a “B” on the next, and so on (see
Figure 1). Thus, by simply “listening”
to the wire, the receiver can know
which wire it is.
Moreover, as the signals injected on
each line are spread out over time,
you also have a way to identify short
circuits, thanks to a second trick: If
you add circuitry so that, in case of
short-circuited lines, the signals could
be added, you will receive several seri-
al words identifying all short-circuited
lines. Adding logic signals is called an
OR function. I used a wired-OR func-
tion thanks to diodes on each output.
The next step is easy. With only a
UART receiver on the probe side, you
will know which line is connected to
the probe. Well, that does seem easy,
but what about the lack of ground
connection? And how can you identi-
fy the wire connected to the other
input of the probe?
The probe is connected between two
random wires (arbitrarily called hot
and cold inputs); there-
fore, assuming that the
lines are 0 V when idle,
the probe will see an
AC signal on its inputs.
It’s positive when the
hot input is receiving a
byte and the cold is
idle, and it’s negative
when the cold input is
receiving a byte and the hot is idle.
And what do you do with AC sig-
nals in a DC world? You’re right, a
diode bridge will rectify the signal and
provide a positive byte (whichever line
is carrying the byte), recreating a
ground reference.
Put a diode bridge between the two
inputs of the probe and the probe itself,
and then a UART. Now you will know
which wires are connected to either of
the two inputs. Unfortunately, you
will not be able to differentiate
between them.
Here is the last trick: Connect
the two probe inputs (red and
green) to an unbalanced diode
bridge (more voltage drop on
two opposed sides of the bridge
than on the others), as illustrat-
ed on Figure 2. With this trick,
you first reconstruct a ground
connection (as the two inputs
are considered as an AC signal).
Moreover, you have a way to
differentiate binary words coming on
each of the two inputs. Those coming
on the lower input on the diagram
have, after the unbalanced bridge, a
higher amplitude than the ones com-
ing on the other input! The probe
must then include an analog UART
receiver that’s able to receive and
decode a serial bitstream but also
Photo 2a—
The probe’s red input is connected to the blue wire, and the green input is connected to the yellow wire. The probe
then lights the green LED, which corresponds to the yellow wire, and the red one, which corresponds to the blue wire.
b—
As
you can see in the middle photo, the wires are reversed, and so are the LEDs’ colors.
c—
In the last photo, two wires are con-
nected to the same red input (short circuit), and then the two corresponding LEDs are red. Easy, isn’t it?
Transmitter
A
A
B
J
Line 10
Line 2
Line 1
Figure 1—
As you study the transmitter principle, keep in mind that a differ-
ent byte is serially transferred on each of the 10 outputs.
a)
b)
c)
A
C
A
C
Figure 2—
The key trick: An unbalanced diode bridge allows for
the conversion of serial words coming on two wires into a ground
reference and a wire summing both serial words, but with a differ-
ent absolute level, which allows you to distinguish each of them.
12
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
trol. The internal RC oscillator
clocks the microcontroller, and
all of its I/Os are used. The
PTA1 and PTA3 lines are pulled
up at startup in order to use the
boot ROM code for in-circuit
programming. For more infor-
mation about the Motorola
MCHC908QY4, refer to Jeff
Bachiochi’s column “Newcomer
Nitron: Motorola’s Leading 8/16-
Pin MCUs” (Circuit Cellar 151).
I wanted a small form-factor
device so that I could carry it in
my pocket. I built a full surface-
mount PCB, and used four surface-
mount, miniature, resistor networks
to reduce the space constraint (see
Photo 3). The resistor networks were
not easy to solder by hand (less than
0.1
″
long for eight pins). On the bot-
tom, the battery holder is soldered
directly to the PCB, as well as the out-
put plug and the in-circuit program-
ming header, as illustrated in Photo 4.
There is no space left. The full PCB
size is less than 2.2
″
× 1.3
″
.
THE PROBE
Figure 4 is a schematic of the probe.
As you can see, I was able to use
another MC68HC908QY4 to drive
10 bicolor LEDs through eight I/Os
thanks to a multiplexing scheme. The
two input wires go to the unbalanced
bridge, which is made with one diode
on three sides (0.6-V loss) and two
diodes in series on the last one (1.2-V
loss). The bridge’s output goes directly
to one of the microcontroller’s ADC
inputs; it is decoded under software
control (something like an ADC-based
bit-banging UART receiver). Another
pair of 1.5-V AAA batteries is used for
power. The PCB is also a full SMT
with the same form factor as the
transmitter (see Photo 5).
With this diode setting, the voltage
of the received signal is either 1.2 or
Figure 3—
The transmitter’s microcontroller drives each of the 10 outputs through a protective passive network. The
diode allows you to have a wired-OR configuration when wires are short-circuited.
Photo 3—
The transmitter PCB includes the microcontroller,
10 protection diodes, and six eight-pin resistor networks.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
13
0.6 V. The former is derived in
the following way:
1.2 V = 3 V – 0.6 V (transmitter
diode) – 2 × 0.6 V (probe bridge,
non reduced polarity)
The latter voltage is determined
by the following equation:
0.6 V = 3 V – 0.6 V – 3 × 0.6 V
(probe bridge, reduced polarity)
It could vary by a few hundred
millivolts because of losses in
the wires or an exhausted bat-
tery, but the software manages
this as long as the losses are not
more than 0.4 V.
Like the transmitter, the microcon-
troller is clocked by its internal RC
oscillator. The oscillator is factory-cal-
ibrated in flash memory, and it’s pre-
cise enough for a low-speed UART
like this one. Thanks to the small size
of the PCBs, it was possible to pack
three pairs of transmitter and probe
PCBs on a single 160 mm × 100 mm
Eurocard-standard PCB. This lowered
the manufacturing cost.
FIRMWARE
All of the software was written in C
because the MC68HC908QY4 has
enough memory and this was not a dif-
ficult real-time project. Metrowerk’s
CodeWarrior environment is easy to
use because it’s so straightforward.
However, on the downside, I couldn’t
use the Processor Expert tool (automat-
ic code generator) because it required
too much ROM and RAM. It required
more than the available space, even
for a small amount of firmware.
It seems that these tools are more
appropriate for high-end processors than
for entry-level ones. Nevertheless, using
a high-level language like C is extremely
helpful, especially because Motorola pro-
vides the C compiler for free. (It’s limit-
ed but large enough for such a design.)
The transmitter’s software is straight-
forward. A main loop sequentially calls
a bit-banging UART transmit routine
that outputs a predefined byte from A
to J on each of the output lines. It also
blinks the “I’m alive” status LED at the
same frequency. The UART speed is
1200 bps, so 1 byte is sent on each of
the 10 outputs 12 times per second. If
you have not worked on bit-banging
UART code, I encourage you to take a
look at the code that is available on the
Circuit Cellar
ftp site. It’s is only one
page long.
The receiver’s software is more
complex. A timer is used to execute a
main loop at a 3600-Hz frequency,
which is three times the UART
speed. Several steps are execut-
ed at each iteration. The ADC
conversion of the probe input
gives either a 0 level (less than
200 mV) or a high level (greater
than 200 mV). In the latter case,
the absolute value is also meas-
ured and compared to a thresh-
old to distinguish bytes received
on the cold input of the probe
or on the hot input.
The second step involves virtual
UART processing, which is based
on the zero and one read through
the UART. A start-bit condition is
recognized by two successive high
readings. Then, the absolute volt-
age level is stored, and 1 bit is sampled
every three cycles (3600 Hz/3 = 1200
bps). Using a clock three times higher
than the bit rate allows for a more
solid UART implementation.
Next comes an update of the LED sta-
tus buffer memory, which is based on
the received information. Finally, the
LED multiplexed display is refreshed.
Regarding the LED status, the follow-
Photo 4—
The probe PCB is nothing more than a microcontroller, 10 bicolor
LEDs, and a few passive components. Hand-soldering the LEDs is not
easy because a misaligned LED isn’t too pretty. The input unbalanced
bridge is on the right-hand side.
International Engineering
Consortium
www.iec.org
Conference Dates
February 2–5, 2004
Technology Exhibition Dates
February 3–4, 2004
Santa Clara Convention Center
Santa Clara, California
Santa Clara Convention Center
Santa Clara, California
Engineers Delivering Tomorrow's Designs
Engineers Delivering Tomorrow's Designs
14
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
ing algorithm is used: a memory byte
is reserved for each LED (1 to 10, times
two because you have red and green
LEDs). Each time a byte corresponding
to a given LED is received, the memory
byte is incremented by 127 (up to 255).
Each memory byte is then automatical-
ly decremented at a rate of 150 Hz.
Each individual LED is illuminated as
long as the memory byte value is above
128. As a result, the LED stays on for at
least 1.7 s (255/150), and each transmis-
sion error is automatically discarded.
Robert Lacoste lives near Paris, France.
He has 15 years of experience working
on innovative real-time software and
embedded systems. Specialized in cost-
optimized mixed signal designs, he has
won more than a dozen international
design contests. Robert currently man-
ages his own design and consulting
company. You can reach him at rla-
coste@alciom.com or www.alciom.com.
PROJECT FILES
To download the code, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2004/162.
SOURCE
MC68HC908QY4 Microcontroller
Motorola, Inc.
www.motorola.com
BEST OF BOTH WORLDS
Developing the Smart
Tracker 2 took me only
60 hours, two-thirds of which
were devoted to hardware
design. The software portion
took approximately 20 hours
to complete, thanks to
Motorola’s great design tools.
Using C for such a project
was definitively a plus, even
though I’m addicted to using
assembly code for time-criti-
cal applications (but this
application was not so time critical).
This small, innovative project
produces a useful, inexpensive tool.
Its design demonstrates once again
that mixed-signal solutions, which
combine the best of the digital and
analog worlds, are often extremely
powerful!
Author’s note: I’m currently looking
for a partner to build and commercial-
ize this project. (Is anyone interested?)
But, if you would like to build your
Photo 5—
A two-slot AAA battery pack is soldered to the bottom side
of each PCB. The size of the batteries dictated the size of the PCBs.
Figure 4—
The inputs go through the unbalanced bridge to an ADC input. The Motorola MC68HC908QY4 drives the 10 bicolor LEDs using a multiplexed scheme in order
to reduce the I/O pin count.
own wire tracker, drop me an e-mail. If
I receive enough requests, I will launch
a small batch of blank PCBs.
16
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
M
any electronics experimenters
and professionals have extensive home
laboratory setups, but one thing that’s
usually missing is a reliable method of
temperature testing designs for per-
formance and design-verification pur-
poses. Until recently, I was no excep-
tion. Using my wife’s oven and refrig-
erator, I would run back and forth
between the kitchen and my lab with
partially frozen and cooked PCBs. I’ve
also stuffed my boards in the odd
Styrofoam ice chest with a small
wattage light bulb, which works well
for heating, but doesn’t cool anything
unless ice is added.
I had always wanted a small, low-
cost temperature chamber with elec-
tronic controls that I could use at
home to test my circuits like I do at
work. Unfortunately, I found even the
cheapest surplus temperature cham-
bers to be bigger than necessary.
Telling myself that my money could
be used for more pressing issues, like
college for the kids, I decided to build
my own. Read on to see how I con-
MORE POWER, SCOTTY!
The TEC module itself is essentially
resistive in nature, and the one used in
this cooler is approximately 3
Ω
. (I’m
talking about large-signal, first-order
effects here. Don’t write me nasty let-
ters, because I am well aware that after
a heat differential is generated, the
TEC actually generates a back EMF
because of the thermocouple effect. My
simplifying assumption is close enough
for the use that the TEC is being put to
in this project.) This translates into a
4-A draw at 12 V. After looking at the
size of the TEC heatsink assembly and
making a few calculations, I decided
that the design would easily handle a
50% increase in operating power,
especially because it would incorpo-
rate closed-loop operation.
To this end, I used a surplus 15-V
switching power supply. With the
increased power, the slew rate of the
chamber and ability to operate with
some heat load from the electronics
under test was much improved.
Build an Inexpensive Temperature-Testing Chamber
FEATURE ARTICLE
by Steve Hageman
Most home laboratories lack sufficient temperature-testing technology, which means kitchen
ovens and refrigerators find use as heating and cooling systems for PCBs. Steve’s home lab
had been no different until he built his own benchtop temperature chamber.
verged low-cost consumer technology,
a PIC16F876 microcontroller, and a
few other odds and ends to make an
affordable laboratory-grade tempera-
ture chamber (see Photo 1).
START WITH A COLD ONE
The heart of this design is a thermo-
electric cooler (TEC) ice chest that’s
designed for use in automobiles. The
ice chest can heat or cool without a
mechanical compressor by way of the
Peltier effect. I purchased a nice little
nine-can chest at a local discount
retailer for less than $40. After a few
hours of open-loop testing, I was ready
to get out the hacksaw and do some
damage.
Let’s begin with a brief overview of
the basic unit. The chest, which oper-
ates on 12 VDC, was advertised to
heat to 50°C and cool to nearly freez-
ing. It’s an open-loop design: plug it in,
set the heat/cool switch, and go. I veri-
fied that the basic performance and
design of the chest was sufficient to
spend the time modifying for my uses.
I found a nicely engineered cooler.
Inside the chest is a thin, drawn alu-
minum pan that is thermally attached
to the TEC module. This helps spread
the heat quickly and evenly. The TEC
module itself is well designed; it’s fas-
tened in place between a nicely sized
external heatsink and the inside of the
chest with a good-looking plastic
mount. Although the door, latch, and
hinge are plastic, they look as though
they were designed to be robust
enough to provide years of service. An
effective seal around the doorframe
keeps air leakage to a minimum.
Photo 2—
The fan supplied with the cooler was
scrapped in favor of a higher volume fan that was
attached directly to the TEC heatsink. This change
greatly improves the TEC efficiency as well as its heat-
ing and cooling ability.
Photo 1
—
With a PIC microcontroller and a few hours
of work, you can transform this travel cooler into a
superb temperature-controlled test chamber for your
home lab.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
17
modified microprocessor heatsink and
fan assembly to the TEC module inter-
face inside the chamber. The fan is
small, but it moves sufficient air inside
the chamber to appreciably speed up
the heat transfer (see Photo 3).
In case things get out of hand (e.g.,
thermal runaway followed by smoke
and fire), the TEC module has a ther-
mal switch mounted on the heatsink
to shut it off if the heatsink overheats.
Don’t remove this switch during the
conversion; it’s a useful safety feature.
TO THE CHOP SHOP
Back in the workshop, I first
removed the “convenient mini-con-
sole/drink holder.” This allowed for
access to the outside heatsink, the
The key to effective heating and
cooling from a TEC module is to
make the delta temperature across the
device as little as possible. The TEC
is essentially connected between two
heatsinks, the external heatsink and
the heatsink inside the temperature
chamber. For instance, when cooling
the chamber inside, the outside
heatsink must get warm. If you can
remove heat fast enough from the
external heatsink, you will improve
the cooling efficiency inside (see
Photo 2).
To improve the efficiency of the
external heatsink, I replaced the origi-
nal cooler’s small (but quiet) fan with
a larger unit bolted directly on it. The
new fan forced a greater volume of air
directly on the heatsink fans.
The efficiency of the inside heatsink
was improved by attaching a slightly
Figure 1—
A high degree of integration is possible when you use a PIC16F876 microcontroller with a built-in A/D converter and UART. The TEC heating and cooling is con-
trolled by power relays. The user interface is composed of a rotary encoder and an off-the-shelf, 2 × 16 display module. The most complicated piece in the chamber is the
switching power supply, which was solved with a surplus unit.
Photo 3—
The heat transfer efficiency inside the cham-
ber was increased by the addition of a CPU-type heatsink
and fan. Above and behind the heatsink and fan is the in-
chamber temperature sensor (U1 on the yellow post). To
keep the sensor dry, it is encapsulated with epoxy.
18
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
fan, and the power cord. The original
on/off switch and power cord were
removed and stored safely for a future
project. The outside fan was originally
mounted to this console, so I removed
it and cut off the old mounting tabs so
that they would not interfere with the
new fan mounted directly on the
heatsink. The top portion of the cup
holder was reshaped with a file so as
to make a flat surface for the micro-
controller electronics control box.
Using a Radio Shack project box for
the microcontroller enclosure proved
to be advantageous. The box came
with a plastic cover and a thin alu-
minum cover. In this instance, the
aluminum cover proved useful
because it fit over the original cup
holder indents. This provided a nice
flat base for the project box to be
mounted to, and it also allowed some
offset for easy finger access to the
door latch. These pieces were pop-riv-
eted together.
The power supply and power relays
were mounted on a Jameco project
enclosure. I pop-riveted the enclosure
to the bottom of the chamber by
drilling eight holes through the cham-
ber’s outer cover but not all the way
through to the inside of the chamber.
The pop rivets attached to the cham-
ber’s outer cover and the project box.
Because the thickness of insulation
from the inside to the outside of the
chamber is nearly 1
″
, this in no way
compromises the insulation of the
chamber.
I added a small fan to the back of
the power supply enclosure to keep
the internal temperature from getting
out of control. Note that mounting
the power supply box under the cham-
ber is also advantageous because it
acts as a pedestal that keeps the
chamber door easily accessible when
sitting on a workbench.
The TEC module is taken apart by
removing the screws inside the cham-
ber. I used a small CPU fan/heatsink
assembly that required me to drill and
tap two holes in the thick aluminum
TEC heat-transfer plate. A better
design would have incorporated a
Photo 4—
The PIC16F876 microcontroller and associ-
ated circuitry were built breadboard-style on an ME
Labs PIC protoboard. The logic-level signals to drive
the relays are routed to the power supply unit that is
mounted underneath the chamber.
Photo 5—
Looking into the power unit, the switching
power supply can be seen along with the relay drivers
and relays. The power supply specified in the parts list
is smaller than the surplus unit that I used on this pro-
totype. The power unit fan was mounted on the back
panel (removed for this picture).
“My sample applications were
up and running quickly with
Rabbit’s RCM3200
and
Dynamic C
programming
software
.
Everything I
needed
was provided in
an
easy-to-use kit
.
”
Jan Axelson
Author of Embedded Ethernet and
Internet Complete and USB Complete
Complete Embedded Design System:
Kit Includes RCM3200 core module, Dynamic C software
(with royalty-free TCP/IP stack with source) and complete
set of development tools. Embedded Ethernet and Internet
Complete valued at $49.95 will be included at no charge.
* Order the RCM3200 Development Kit
online with priority code 9990 at
or use priority code 9990 by calling
FREE
Book
With
Dev. Kit*
$49.95 value
Axelson’s Choice
20
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
slightly larger heatsink,
which would allow attach-
ment with the existing
TEC mounting screws.
Both methods work, how-
ever. After installation, the
inside heatsink and fan
were aligned to move the
air around the inside of the
enclosure horizontally.
I spread a thin layer of
thermal grease on all of the
surfaces and reassembled
the TEC module and
heatsinks to the chamber.
After the TEC assembly
was installed back in place,
the 3
″
outside fan was
attached to the TEC
heatsink. Note that small wood screws
may be used to screw the fan mounting
holes directly to the heatsink fins. This
may require squeezing the fins together
with pliers to get them close enough to
allow the screws to bite the fins. With
proper fin spacing and screw selection,
this method of mounting the fan to the
heatsink is plenty robust for this type
of application.
A small notch and hole were added to
the back of the cup holder and to the
power supply enclosure. A similar hole
was drilled from the back of the elec-
tronics box through the cup holders to
allow control and power signals to pass.
I drilled two small holes from the
outside of the chamber to the inside.
The first is for the inside fan power
leads; the second is for the tempera-
ture sensor.
The sensor location is somewhat
critical; it should be out of the direct
airflow from the fan mounted in the
chamber and within approximately
0.375
″
from the chamber walls. I
enclosed the inside fan leads in a
length of heat-shrink tubing and
sealed the exit hole with a small
amount of epoxy to prevent air leaks.
Most temperature chambers have a
way to get wires in and out of the
chamber to allow power and control
signals to pass to the device under
test. To accomplish this task, I went
to a local hardware store and found
that a 0.75
″
-to-0.5
″
PVC pipe adapter
would work perfectly as a cable port.
Using a wood drill and hand brace, I
drilled a 1
″
hole from the outside of
the chamber to the inside. The hole’s
finished dimensions are just slightly
under the outside dimension of the
PVC adapter. To make a perfect press
fit, I used a hand-held motor tool and
router bit to slightly enlarge the hole.
The adapter fits perfectly, and it’s big
enough to allow test leads to pass
through from the outside to the inside
of the chamber. When you’re not
using the hole, plug it with a rubber
stopper or piece of foam.
At this point, I had turned a perfect-
ly good electronic travel cooler into a
hacked-up, worthless mess. If you’re
building your own chamber as you
read this, don’t show your loved ones
the project just yet!
IF ONLY I HAD A HEART
Now for the fun part. The heart of
this operation is a PIC16F876 micro-
processor, which squeezes a powerful
processor, 10-bit A/D converter,
UART, interrupts, brownout detect
circuit, watchdog timer, flash memo-
ry, and more into a small 28-pin foot-
print. All that’s needed for operation is
5 V and a resonator for the clock.
Starting from the analog end of the
PIC16F876 microcontroller, the 10-bit
A/D converter can run from an inter-
nal or external reference. Because the
accuracy of the conversion results
depends directly on the reference, this
design uses an external reference con-
figuration. I chose the Texas Instru-
ments REF3025. This 2.5-V reference
has low temperature drift
and an initial accuracy of
better than 0.1%. Note
that 2.5 V better matches
the output of the tempera-
ture sensor without the
need for any additional
gain (see Figure 1).
The temperature inside
the chamber is measured
with a Microchip
TC1047A solid-state sen-
sor IC, which outputs a
linear 10 mV per 1°C with
a precise 0.5-V offset.
Therefore, 25°C is meas-
ured as: (25 × 0.01) + 0.5 =
0.75 V. The sensor is
rated at better than 1°C
accuracy, which is good enough to
eliminate the need for calibration in
this application.
The A/D converter has the follow-
ing resolution:
The combination provides for slightly
over 4 least significant bits (LSB) per
1°C measurement resolution. Because
the goal is to have 1° set ability, this
resolution is more than sufficient
without any extra gain required
between the sensor and the A/D con-
verter (see Photo 4).
The temperature sensor (U3) was
fabricated by placing the SOT-23 sen-
sor on a small protoboard cut down to
the bare minimum. Three small gauge
wires were then attached to each leg
of U3 to allow power, ground, and the
temperature signal to get into the
chamber. A small piece of scrap plas-
tic tubing was slipped over the wire
leads toward the sensor. Next, the
entire assembly was potted in a ball of
epoxy just big enough to moisture seal
the temperature sensor (approximately
0.3
″
in diameter).
The epoxy seal drop provides some
thermal mass to help dampen the
response of the temperature sensor.
After the sensor epoxy was cured, the
sensor assembly was placed through a
previously described hole in the back
of the chamber, and then the tube was
lightly epoxied to seal any air leaks
into or out of the chamber.
2 44
2 5
2
10
.
.
mV =
V
Photo 6—
This plot shows the 25° to 50° step response of the completed chamber. The
slew rate is better than 5°C per minute. The set point bobble at 50°C is read from the
graph as 1.3° peak-to-peak. The plot was made under RS-232 control by setting the
desired temperature and reading back the internal temperature sensor at 1-s intervals.
22
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
The PIC16F876’s port B handles
reading the temperature set point
encoder, the Pause/Run switch, and
the digital drive to the various power
relay circuits. Port C drives the dis-
play LCD module and handles the
RS-232 I/O.
The most complex item in the
design is the switching power supply
(see Photo 5). I used a surplus Lambda
15-V, 10-A supply, but any 15-V sup-
ply (new or surplus) that’s capable of
at least 5.5 A should work (and will
probably be smaller than the unit I
used). My supply has an internal fuse,
so I did not add a redundant fuse to
the chamber (or the schematic). If
your unit does not have a fuse, be sure
to use an appropriate fuse from the
AC line to the power supply.
The power is switched to the TEC
and fans via simple power relays as
commanded by the PIC16F876 under
program control. Relay K1 is the TEC
mode control, which reverses the flow
of power to the TEC to allow it to
heat or cool the chamber. K2 allows
the switching in of 3
Ω
of resistance
in series with the TEC to lower the
heating efficiency. K3 is the main TEC
on/off relay.
I mostly use temperature chambers
for testing sensitive analog circuitry.
This is especially true when testing
RF oscillators and phase-locked loops.
Many of these circuits have such low
self-generated noise that any external
signals and even mechanical vibra-
tions are amplified to measurable
levels, masking the device’s actual
noise level.
To allow for measurements while
keeping the chamber powered up, a
Run/Pause switch is located on the
front panel. When Pause mode is
selected, the chamber switches the
TEC off and activates relay K4 to turn
off the fans, which allows silent run-
ning and careful measurements to be
made. In Pause mode, the chamber
continues to sample and display the
chamber’s interior temperature.
IF I ONLY HAD A BRAIN!
The brains of the temperature
chamber were developed with a low-
cost C compiler. The software is state
machine-driven. The master state is
Coast mode when the temperature is
within 0.7° of the set point. In this
state, the TEC module is turned off
and the chamber coasts until it needs
either heating or cooling to maintain
the set point. The other states
include Heat mode, Cool mode, and
Pause mode.
The on/off type of control that I
used is simple. It’s commonly referred
to as a “bang-bang” servo loop,
because the heating or cooling is
either full on or full off. More com-
plex control schemes that involve
proportional control could have been
implemented here, but it would have
been at the cost of a greatly
increased complexity in the TEC
power supply. As you can see Photo 6,
the bang-bang loop maintains the tem-
perature set point to better than 2°
peak-to-peak error.
The TEC is more efficient at heat-
ing than cooling. This causes some
control issues when the control loop
is settled around the desired set point.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
23
When the PIC16F876 senses that the
chamber is within a few degrees of
the set point, it switches in the 3
Ω
of
resistance to lower the heating effi-
ciency of the TEC. This provides for
smoother control, with less overshoot
and hunting of the loop, because the
heating and cooling efficiency are bet-
ter matched with the relays switched
in. For large set-point changes, the
resistors are switched out so as to not
slow down the large temperature
change slew rate.
I spent the first five hours of the
chamber’s life tweaking the tempera-
ture set points by watching its
response to different settings (see
Photo 7). Initially, I had the set points
turn on heating and cooling when the
temperature was more than 1°C away
from the checkpoint and then turn off
when the set point was reached. This
worked, but the peak-to-peak ripple
was greater than 2° because the
chamber was applying too much con-
trol before turning off. Eventually, I
settled on turning on and off when
the temperature is greater than 0.7°
and coasting when the temperature is
less than 0.65° from the set point.
This results in just a few LSBs of hys-
teresis and the proper amount of heat-
ing and cooling. The resulting control
loop has enough gain to have a low
steady-state error, and the oscillation
period is in the low millihertz range.
The software also handles the tasks
of writing to the LCD, reading the
A/D converter, signal averaging, and
set point calculations as required in
the state machine. A small amount of
floating-point math is used because
the PIC16F876 has plenty of program
memory room. The loop runs fairly
slowly, so speed of execution is not
an issue.
REMOTE CONTROL ANYONE?
As in most of my designs, I have the
option of using an RS-232 connection
to control the device’s operation. To
initiate RS-232 mode, the chamber
must be powered with an RS-232
cable attached to a PC. When this is
done, the RS-232, RX level will be
low, causing transistor Q5 to turn off,
which, in turn, causes pin 18 on the
PIC16F876 to be high. Starting the
Photo 7—
The control panel uses a rotary encoder to
get the desired temperature set point from the operator.
The LCD shows the set point and the actual measured
temperature of the inside temperature sensor. When the
Run/Pause switch is in the Pause position, the chamber
fans are turned off, and the chamber is set to Coast
mode operation. The temperature set point is dialed in
with a rotary encoder. The encoder input is interrupt-
driven and changes the desired temperature set point
as commanded by the operator in 1° increments.
– 2 Channels, 5mV/Div to 20V/Div, 50nS/Div to 100mS/Div, Up to 80MSPS
– 1 Analog Output, 5 Digital Outputs, Up to 80MSPS
– 16 Channels, Multiple Trigger Options, Up To 80MSPS
Two Programmable Power Supplies
24
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
chamber without an RS-232 connec-
tion results in pin 18 being low,
which allows the PIC16F876 to auto-
matically decide that it should be in
Manual mode at startup.
When the chamber starts in RS-232
mode, the front panel controls are dis-
abled, and control occurs via RS-232
with simple ASCII commands. This
allows synchronous test operation
with the temperature chamber and
measurement instruments operated
together via any control program that
can read and write to a serial port
using ASCII text, which includes
almost every programming or scripting
language and terminal emulator. Take
a look at the “Remote Operation”
sidebar to learn more about the RS-232
remote command set.
If RS-232 operation is not desired,
you may leave Q5, Q6, and their asso-
ciated circuitry off the board. Just be
sure to connect U5, pin 18 to ground.
Doing so ensures that the chamber
starts in Non-Remote mode.
FRUIT OF MY LABOR
As you can see in the photos I’ve
provided, the end result of all the chop-
If you find that the chamber is 0.5°C low at 50°C set point,
you can correct the error with a gain coefficient of 20,
which will add 20/1000 × 25 = 0.5° to the set point at 50°C
(bringing the error to zero).
This simple linear correction is amply able to get the
actual servo loop balance point to below 0.5° across the
entire temperature range of the chamber. The initial default
value of the coefficient is 0 correction factor. The correc-
tion factor for a particular chamber only needs to be set
once as the value is stored in the microcontroller’s non-
volatile flash memory EEPROM and read in each time the
chamber is powered.
Remote Operation
A PC in some form or another can control nearly every
piece of test equipment I own. Although LAN and USB con-
nections are gaining market share, the ubiquitous RS-232
serial connection is here to stay because of its low cost and
ease of implementation.
This application involves a simple command processor using
mnemonic ASCII commands. It may be remotely controlled via
a terminal program or any programming language that supports
serial communications. This even includes Word and Excel!
The commands are composed of a simple two-letter
mnemonic followed by an optional parameter if necessary.
When the command completes, the chamber sends back a
carriage return (13 hex), allowing the control program to
pace itself to the chamber’s response rate.
All of the command strings are terminated by a carriage
return (
CR). The commands recognized by the chamber are
Set Point, Actual Temperature, Pause Mode, Run Mode,
Get State, and Version (see Figure s1).
Set Point allows the temperature set point to be changed.
The set point may be any value from 0 to 60, representing
0° to 60°C (integer values only). When the command is
completed, the chamber sends back a
CR. Actual
Temperature allows reading of the chambers actual temper-
ature in degrees Celsius (floating point to one decimal
place). Pause Mode sets the chamber in Pause mode (TEC
and fans off). The chamber is in Coast mode.
Run Mode sets the chamber back to Run mode. The fans
are on and heating/cooling as needed to maintain tempera-
ture. Get State allows the reading of the chamber’s current
operating state. Version returns the firmware version.
The last two commands in Figure s1 allow you to tweak
the internal set point calculations. This is useful to adjust for
differences in temperature sensor construction, placement, or
airflow in the chamber that results in the actual balance
point of the servo loop being different than the set point.
The gain coefficient is a simple linear equation with an
intercept point of 25°C. A positive value adjusts the actual
temperature set point up by the specified amount for tem-
peratures above 25°C and moves the set point down for tem-
peratures below 25°C. The calculation used is as follows:
Internal_set_point = set_point 25
−
(
)
×
GainCoeff
1000
Set Point
Example:
SP 50CR
Sets the temperature to 50˚C.
Return:
CR
Command completed.
Actual Temperature
Example:
ATCR
Asks for the current chamber temperature.
Return:
55.3CR
The temperature is currently 55.3˚C.
PAuse Mode
Example:
PACR
Sets Pause mode.
Return:
CR
Command
completed.
RUn Mode
Example:
RUCR
Sets Run mode.
Return:
CR
Command
completed.
Get State
Example:
GSCR
Asks what the current state of the chamber is.
Return:
STATECR
Where the state is one of the following strings:
Coasting—Temerature is within the set point
Cooling—Actively
cooling
Heating—Actively
heating
Pause—In pause state
VErsion
Example:
VECR
Asks what the current firmware version is.
Return:
1.0CR
The firmware version in this example is 1.0.
Set Gain Coefficient
Example:
SG 500CR
Sets the temperature coefficient to 500 milli-degrees
per degree. The normal range is 1000 to –1000
milli-degrees with a default value of zero.
Return:
CR
Command completed. The value is now stored in the
microcontroller’s flash EEPROM and is read in
each time the chamber is powered up.
Get Gain Coefficient
Example:
GCCR
Asks for the currently stored set point coefficient value.
Return: –
20CR
Return in this case is –20 milli-degrees per degree.
Figure s1—
The temperature chamber has a simple built-in RS-232 command
processor that understands and decodes plain typed ASCII commands. This allows
nearly any program that can open a serial port to control the temperature chamber.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
25
ping, soldering, and coding is one fine
piece of equipment. The performance
is good; in fact, it’s comparable to com-
mercial temperature chambers that
cost thousands of dollars. And it won’t
break every other year like the bigger
mechanical chambers are wont to do!
Although the chamber may not be
able to test over a full 0° to 70°C tem-
perature range, it is good enough to
verify the performance and tempera-
ture stability of highly accurate cir-
cuits. At room temperature, the
chamber easily operates from 8° to
60°C with less than 1.5° peak-to-peak
error. The chamber supports a heat
load of 4 W while maintaining a set
point of 8°C. This increases to 10 W
at a set point of 25°C and higher.
The response of the chamber is
roughly 8 min. for a 25° to 50° heating
step and 12 min. for a 50° to 25° cool-
ing step. The chamber has a natural
servo response of approximately 0.5 Hz,
steady state around the set point.
Remote control operation is possi-
ble via an RS-232 connection. In fact,
the temperature response curve in
Photo 6 was made with the oven
being controlled by a simple program
written in the VEE graphical test lan-
guage. (Some newer PCs and note-
books don’t have serial ports. Your PC
may have only one such port. Don’t
worry, though, low-cost serial-to-USB
translators are available from FTDI.
This project can be seamlessly USB-
controlled.)
You may download the source code
and PIC-programming hex files for
this project from the Circuit Cellar
ftp site. If you cannot program the
microcontroller, keep in mind that I
am selling programmed PICs on my
web site.
I
PROJECT FILES
Steve Hageman has been an “analogo-
holic” since the fifth grade. He has
designed and built radios, automatic
test equipment, embedded systems, ana-
log function modules, and power sup-
plies. For more information on Steve’s
projects, visit www.analoghome.com.
You may contact him at
steve@analoghome.com.
SOURCES
PCM Compiler
CCS, Inc.
(262) 797-0455
www.pic-c.com
REF3025 Voltage reference
Texas Instruments, Inc.
(800) 477-8924
www.ti.com
VEC222 Travel cooler
Vector Manufacturing
(866) 584-5504
www.vectormfg.com
26
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
W
hen my wife and I visit my in-
laws, who live in northern Wisconsin,
we often hear tales about the wildlife
on their mostly wooded, 300-acre hobby
farm. Stories of black bears with cubs,
timber wolves, and rare albino whitetail
deer are often told. Yet, try as I might, I
had never seen any of the animals for
myself, except at extreme distances.
Because simply walking into the woods
to get a better look would scare the ani-
mals away, I needed a way to remotely
obtain a close-up view of them. So, I
went in search of a solution that would
either provide my wife and me with great
views of the indigenous wildlife or
prove that the stories were of the fish
variety. My solution was the Remote
Observation Station (see Photo 1).
The station needed to be relatively
inexpensive, easy to use, and easy to
maintain. It couldn’t rely on utility
power (it would be in the woods after
all), and it couldn’t require frequent trips
to retrieve the battery for recharging.
Solar power seemed like a logical solu-
tion. Given that it would be solar-pow-
ered, the power supply components
would have to handle the wide voltage
swings possible in solar-powered sys-
tems. I wanted a charge controller to
prevent overcharging the battery. I also
wanted an easy way to see if the battery
was recharging successfully without
having to make a trip to the remote
station. It was this last requirement
that led me to design a custom piece
of hardware instead of buying an exist-
ing battery charge controller.
about the battery’s state. Anticipating
that the station would be miles away
and already transmitting NTSC video,
it seemed natural to simply overlay sys-
tem performance information on the
video signal that shows up as characters
at the bottom of the TV screen. In other
words, an on-screen display (OSD).
To meet my objectives, I chose a
microcontroller-based design, which sig-
nificantly increased flexibility without
adding to the overall hardware complexi-
ty. To further reduce the cost of the proj-
ect, I decided to forego a traditional user
interface made of buttons, switches, and
LCDs. Instead, I wrote a configuration
program for Windows that configures the
PVCC behavior via a serial connection.
Any change to the configuration data is
stored through power cycles in a 64-byte
block of the program flash memory. The
microcontroller also allows me to fine-
tune features with little or no change to
the product’s basic hardware design.
SYSTEM OVERVIEW
The Remote Observation Station
integrates six main components: a
CCD video camera, a PV solar panel, a
rechargeable battery, a temperature sen-
sor, an RF video transmitter, and the
PVCC (see Figure 1). The control
board, which is based on Motorola’s
MC68HC908QY4 microcontroller, sits
at the center of the system; it provides a
charge controller, high-efficiency power
regulators, a video sync separator, and an
RS-232 serial interface. Photo 2 shows
the heart of the Remote Observation
To come to the point, I wanted a
system that would need as little main-
tenance as possible, and would alert
me when trouble was ahead. Finally, I
wanted to be able to turn on a TV to
watch the wildlife without any other
special receiving equipment, except
possibly a high-gain antenna.
The station’s control board, which
is called the photovoltaic charge con-
troller (PVCC), prevents the battery
from becoming overcharged and over-
discharged. It also provides feedback
Remote Observation Station
FEATURE ARTICLE
by Richard Dreher
Photo 1—
I completed the first test station in late sum-
mer. The solar panel is fixed facing due south. The
panel’s angle at this time of year is approximately
equal to the station’s latitude.
Richard’s Remote Observation Station is a nature lover’s dream. It allows you to watch
wildlife on a TV from more than a mile away. At the heart of this inexpensive solar-powered
system is an HC08-based photovoltaic charge controller.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
27
Motorola MON08 specification. JP6 is
accompanied by DIP switch S3 (MON08
isolate), which is used to disconnect four
specific microcontroller pins that are
needed by the MON08 interface.
Two DC-DC converter-type power
regulators are built on the PVCC board.
Both regulators are based on Linear
Technology’s LT1766IGN chips. These
devices are monolithic buck 200-kHz
switching regulators that accept a wide
input voltage range (5.5 to 60 V). U2 is
the 5-V version of the LT1766IGN;
therefore, it provides V
CC
(5 V) for all of
the ICs on the board. U1 provides auxil-
iary power for the video camera, the
433-MHz ATV transmitter, and any
other off-board devices. The voltage reg-
ulation point is set via resistors R7 and
R8. Note that resistors R7 and R8 are
fixed for an output of 10 V.
The LM1881 video sync separator
provides timing signals to the HC08
microcontroller that then allow the
microcontroller to generate a stable
video overlay signal synchronized to
the original video signal. This overlay
signal is added back into
the original video signal
to create the overlay
effect. Two signals are
generated by the
LM1881: a vertical sync
signal that is connected
to port PTB0, and a com-
posite horizontal sync
signal that is connected
via the microcontroller’s
IRQ input. I studied a
variety of hardware and
software schemes before
settling on this arrange-
ment, which seemed to
Station enclosed in an aluminum box.
The PVCC board provides a simple
on/off battery charger using the PV solar
panel as a power source. The control
board adds battery state information in
the form of a text overlay to the video
signal generated by the camera. A PC
can be connected to the control board
via DB9 connector J1 (see Figure 2).
The video transmitter operates in the
433-MHz amateur television (ATV)
70-cm band. The transmitter is a Video-
Lynx Model Z70A designed by Ravi
Goonasekeram (sign KA3NNJ); it has a
rated output of 50 to 100 mW while
using approximately 300 mA at 10 V. I
chose this transmitter because it pro-
vides a clean, stable signal, and it oper-
ates on a frequency that corresponds to a
specific channel on a cable-ready TV set.
Actually, one of four stations can be
selected with a DIP switch. You can also
send a test pattern directly from the
transmitter to aid in the initial setup.
Currently, the station is located
1.5 miles from the receiver. It transmits
through a quarter mile of trees. In order
to span that distance with
such low power, I needed a
high-gain antenna. I built a
15-element Quagi, designed
by Wayne Overbeck (sign
N6NB), for the 70-cm band.
This antenna provides a gain
of approximately 15 dBd.
Fortunately, the antenna is
made mostly of wood, so it
was inexpensive to build.
A 12-V valve-regulated
lead acid (VRLA) battery
powers the system. The
HC08 microcontroller’s
integrated 8-bit A/D con-
verter monitors the battery to
determine the charge state. The
battery’s temperature is moni-
tored using a Dallas DS1820 1-
Wire temperature sensor, which is
interfaced to the microcontroller
through a single I/O pin and
some software bit banging to
instruct the microcontroller to
behave as a 1-Wire master.
PVCC CONTROL BOARD
A prototype of the PVCC board is
shown in Photo 3. Figure 3 depicts
the functional block diagram.
The board, which has a 4500 mils ×
3000 mils form factor, was made on
FR4 1-oz. double-sided copper PCB.
The MC68HC908QY4CDW (U3) is a
member of the Motorola Nitron family.
This MCU features a 16-pin SOIC, 4 KB
of flash memory, 128 bytes of RAM, and
14 I/O pins. It can be powered at 3 or 5 V.
I chose the 5-V supply to allow the
MC68HC908QY4CDW to reach its
maximum clock speed of 32 MHz.
Table 1 breaks down the microcon-
troller’s resources and their uses.
A serial communications connec-
tion to the PVCC is provided via J1
and U5 (MAX232). Both transmit and
receive lines on the logic side of U5
connect to PTA0 in a half-duplex
arrangement, enabling communica-
tion with a PC. You can configure the
PVCC using the ConfigPVCC Win32
configuration program. The single-pin
arrangement is accomplished via
diode (D8) and pull-up resistor (R19).
Programming access to the microcon-
troller’s flash memory is provided via JP6,
which is wired in accordance with the
Sony 10× zoom
video camera
Shell SP65
photovoltaic (PV)
solar panel
65 W
P
NTSC
1 V
PP
0 V–20 V
4-A max
System control
board (PVCC)
Charge controller
Sensor interface
Power regulators
Video overlay gen.
RS-232 Interface
RS-232
Three wire
Personal
computer
NTSC
1 V
PP
VideoLynx ATV
transmitter
50–100 mW, 433 MHz
15-Element
Quagi antenna
Microphone
on camera
MK gel cell
battery
12 V, 84 Ah
0 V–15 V
10-A max
Temperature
sensor
DS1820
1-Wire bus
1-Wire bus
Figure 1—
The PC is only needed when configuration data needs to be changed.
Photo 2—
For outdoor projects, I found this watertight, power-
coated aluminum case by Rolec to be excellent.
Photo 3—
The power MOSFET Q1 has a 20-m
Ω
R
DS
,
which would dissipate about 2 W at a full 10-A charg-
ing current. Two watts is about all the power you would
want to dissipate from a surface-mount part.
30
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
allow the MCU response to the video
signal to be the most repeatable.
Two outputs from the microcontroller
are used in the charge control circuit.
Output PTA4 is used to control charging
via a load switch consisting of a low-
power N-channel MOSFET and a high-
power P-channel MOSFET (see Figure 4).
As you can see in Figure 2, output PTB2
is used to turn on and off the loads (cam-
era and transmitter). This is important
because the ability to turn on and off the
loads enables a low-voltage disconnect
(LVD) feature, which prevents the loads
from over-discharging the battery during
long periods without sunshine.
FIRMWARE
I developed the firmware for this proj-
ect in assembly language using Metro-
werks’s CodeWarrior HC08 version 2.1.
You may download the firmware files
(CharGenData.inc, qtqy_registers.inc,
and PVCC.asm) from the Circuit Cellar
ftp site. During development, I pro-
grammed the ’QY4’s flash memory
via a MON08 interface header using
a MON08MULTILINK pod from
P&E Microcomputer.
I devised three modes of operation:
Configuration mode, Charge mode
with OSD, and Charge mode without
OSD. I implemented them in three
separate software loops. Functionality
common to more than one mode was
implemented in subroutines that
could be called from any mode.
Just after startup, the ’QY4 checks
the current configuration data stored
in flash memory for validity by per-
forming a 16-bit cyclical redundancy
check (CRC). That CRC value is then
compared to the CRC value stored in
the first 2 bytes of the configuration
data. If the values do not match, the
configuration data is assumed to be cor-
rupt, and it’s overwritten with the man-
ufacturer’s default values stored in
another region of the flash memory.
Configuration mode allows you to con-
figure the behavior of the PVCC board. In
this mode, the MCU waits indefinitely
Figure 2—
Port pin PTA0/ADx serves a dual purpose; it is used as the serial I/O port in Configuration mode and the daylight sensor in Charge mode.
’QY4 MCU
Pin number
PVCC Usage
IRQ
9
Video horizontal sync (start of video scan line)
PTA3
8
Interface DS1820 1-Wire bus temperature sensor
OSC1
4
32-MHz External oscillator input for OSD Active mode
PTA4
5
Change enable output
AD1
12
Analog input to measure battery voltage
PTA0
13
Communications with user’s PC during Configuration mode
CdS photocell light sensor input (AD0) during Charge mode
PTB0
15
Video vertical sync detection (start of new video frame)
PTB1
14
Output to enable/disable external oscillator
PTB2
11
Auxiliary loads to on/off control output
PTB3
10
Configuration mode request jumper
PTB4–6
7, 6, 3
LED status indicator outputs
PTB7
2
Overlay text output signal (added to video signal)
Table 1—
Every I/O signal is used here. Port PTA0/AD0 pulls double duty, serving as the serial link in Configuration
mode and the light sensor input in Charge mode.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
31
for a single byte command from the
PC. If a valid command is received,
the microcontroller carries out the
command and returns to wait for the
next command. This mode is exited
by removing the shorting block on
JP5 and then power cycling.
Configuration mode makes heavy use
of ROM resident communications
and flash memory programming rou-
tines, which are listed in Table 2.
These functions are used to establish
a communications link between a PC
and the PVCC board. I wrote a simple
Windows-compatible program (called
ConfigPVCC) that allows for easy set
up of the PVCC board.
The communications data rate gener-
ated by these routines with a correctly
trimmed oscillator is approximately
12,800 bps when the MC68HC908QY4
microcontroller is using the internal
oscillator and is in User mode. The
PC achieves this data rate using a
UART clock divisor of nine. Although
12,800 bps isn’t a standard data rate, all
PC UARTs are capable of this speed.
When you select Charge mode with-
out OSD, the clock is derived from the
MC68HC908QY4’s internal oscillator.
After initializing the I/O ports, oscilla-
tor trim value, A/D converter, and sys-
tem timer, the microcontroller enters
Wait mode, during which power con-
sumption lowers. Wait mode is exited
periodically in order to reset the COP
timer and check a semaphore to see if
the user-defined sample period has
elapsed. If the user-defined sample
period has elapsed, the battery’s volt-
age and temperature are sampled.
The battery voltage is read via
input AD1. Resistors R22 and R23
form a resistor divider to scale 20 V
down to the 5 V needed by the ana-
log input. The temperature sensed
by the DS1820 1-Wire sensor is read
and checked against a user-defined
battery temperature limit. The
sampled battery voltage is com-
pared to the user-defined set points,
and the charging circuit is turned
on or off accordingly.
When the unit is operating in
Charge mode with OSD enabled, the
MCU clock is derived from an exter-
nal 32-MHz oscillator. The on-screen dis-
play logic is active and responsible for
“drawing” nine characters on the video
signal generated by the camera module.
The video signal and firmware synchro-
nize via the video’s horizontal sync com-
ponent. This component signal is
obtained from an LM1881 video sync
separator whose output is connected to
the MCU’s IRQ input. The sync pulses
are counted in order to determine when
drawing should begin on the screen in a
particular frame. The vertical sync sig-
Photo 4—
I took this shot while testing in my backyard. The “v
c
”
character indicates that the system wants to charge the battery.
32
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
nal indicates when a new video
frame is beginning, and that the
scan line counter is to be reset
to prepare for the new frame.
I had to take several creative
steps to produce overlay text
with minimal jitter and enough
resolution to be useful. The
’QY4’s response to the horizontal
sync (Hsync) pulse had to be as
consistent as possible (from scan
line to scan line). A variation of
only three clock cycles (at 8 MHz)
would be noticeable to the
viewer as a side-to-side jitter.
Logically, the IRQ input had the
best chance of reducing jitter
because of its inherent repeata-
bility. Nevertheless, even the
IRQ mechanism has a variable
latency based on the instruction
that is being executed.
The HC08 CPU family
enforces a run to completion (RTC)
interrupt semantic. This means a pos-
sible response variation of one to nine
clock cycles, with an average variation
of about three clock cycles for most
code. To eliminate this variation, I
used a tricky, but effective, technique.
When the scan line counter, which
is incremented by each Hsync pulse
in the IRQ interrupt service routine
(ISR), reaches the “starting scan line”
minus one, the IRQ ISR modifies the
stack to prevent it from returning to
the interrupted background code.
Instead, the stack is modified to
return to a
wait instruction, which
initiates Wait mode. When the next
IRQ interrupt occurs approximately
62.5 µs later, the system exits Wait
mode, and the interrupt is serviced
again. This is repeated for the next
16 interrupts (scan lines) as the text is
“drawn” onto the video signal. After
the text overlay is completed for the
current frame, the IRQ ISR again
modifies the stack and returns to the
originally interrupted code.
The entire process takes approxi-
mately 16 × 62.5 µs, or 1 ms. Because
of the consistency of interrupting the
wait instruction, this technique pro-
duces nearly jitterless overlay text,
and the background code is only inter-
rupted for 1 ms out of every 16 ms.
You can see the result in Photo 4.
The OSD feature currently displays
nine characters in an 8 × 7 dot format.
Obtaining enough resolution to be
useful for my system meant finding a
fast way to shift the character data, or
“dots,” out of port PTB7. When the
IRQ ISR has determined that it is
time to begin drawing on the
video signal, the background
code already has converted the
ASCII characters to be dis-
played, via a look-up table, into
character font data. That data is
placed into a “Video RAM”
area. The data is arranged so
that one scan line of each char-
acter (for nine consecutive char-
acters) is located in nine con-
tiguous bytes. The next scan
line follows these 9 bytes. This
repeats until the bottom scan
line of the character cell is
reached. It is then a simple
matter for the interrupt routine
to shift nine consecutive bytes
from RAM out port PTB7.
Any time spent indexing to
the next byte in RAM will
show up on the screen as a
space between the characters.
To minimize this space, I first
unrolled all loops to get rid of the
overhead of checking for loop termina-
tion conditions. Next, I pushed all of
the data for one scan line’s display
onto the stack in the reverse order.
Stack instructions take only two clock
LM1881 Video
sync separator
Overlay
brightness
jumpers
MAX232
Interface
logic
MON08
Interface
Configure
mode
jumper
Battery
voltage
scale
5-V Logic power
supply
LT1766-5 DC-to-DC
converter
Auxiliary
10-V power supply
LT1766 DC-to-DC
converter
12-V Battery
(positive)
Fuse10-A
max
Fuse
10-A max
Charge
control
circuit
PV Panel
(positive)
High side
load
switch
Charging on/off
Motorola
MC68HC908QY4
flash memory MCU
Loads on/off
V. Sync
H.
Sync
1-Wire Bus
Text
overlay
signal
Composite
video
OUT
CdS Light
sensor
Status
indicators
32-MHz
OSC
CLK
En
RS-232
Connector
16-pin
Header
Auxiliary
power
output
Composite
video IN
DS1820
Temperature
sensor
Figure 3—
The MC68HC908QY4 16-pin SOIC has just the right complement of I/O for this project.
Photo 5—
My PVCC configuration program is a simple MFC dialog app. It
uses two threads, the main GUI thread and a communications worker thread.
Inter-thread communications is handled via semaphores and messages.
34
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
cycles and require no overhead to
increment index registers. The result-
ing display resolution was approxi-
mately 167 dots per line.
Because the TV uses some of that
scan time to over-scan off the edges of
the screen, the resolution is some-
where in the 140-to-150 range. The
total time for one character and its
inter-character space is 22 clock cycles
at 8 MHz, or 2.75 µs. This means one
line could, in theory, display approxi-
mately 18 to 20 characters. Alas, my
technique uses 7 bytes of RAM for
each character being displayed, so I
elected to display nine characters, con-
suming 63 bytes of RAM—half the
total RAM on the MC68HC908QY4—
for the video OSD feature.
Ambient temperature affects batter-
ies, so I added simple linear tempera-
ture compensation to the charge con-
trol algorithm to adjust the full-charge
set point based on the battery’s tem-
perature. This allows for more accurate
charging and less chance of under-
charging or overcharging when the
ambient temperature increases or
decreases far from room temperature.
In cold weather, for example, the full-
charge set point must be slightly high-
er because of the slower chemical reac-
tions caused by cooler temperatures.
CONFIGURATION SOFTWARE
I developed a simple configuration
utility in C/C++ using Microsoft Visual
C++ 6.0 that allows me to configure the
PVCC board’s behavior (see Photo 5).
Therefore, I eliminated the need for
buttons and LCDs that would be
required to implement a user interface.
The trade-off for this low-cost approach
is the inconvenience of needing a com-
puter with a RS-232 serial port when I
want to change a setting in the field.
When I click the Get Configuration
Data button, the program requests the
configuration data currently stored in
flash memory and displays it on a dia-
log. Then, I can enter any desired
changes to the settings and click the
Send Configuration Data button. This
sends the revised data to the micro-
controller to be programmed into
flash memory, overwriting any previ-
ous data. A CRC16 check is used in
both the get and send data packets in
order to avoid accepting corrupt data.
UPDATE
I have implemented some improve-
ments since I built the original
Remote Observation Station. After
several weeks of field-testing, it
became obvious that the original 21-W
solar panel was too small for this proj-
ect, mainly because the camera now
draws about 500 mA, which is 350 mA
more than the original camera. I found
my current camera—an older Sony
handycam—on eBay for $65. Although
Figure 4—
On the station’s control board (the photovoltaic charge controller, or PVCC), the MOSFET load switch arrangements control charging and 10-V auxiliary power.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
35
SOURCES
DS1820 1-Wire temperature sensor
Dallas Semiconductor
www.maxim-ic.com
LT1766IGN Chips
Linear Technology Corp.
www.linear.com
Gel cell batteries
MK Battery
(800) 372-9253
www.mkbattery.com
CodeWarrior HC08 V. 2.1
Metrowerks
(800) 377-5416
www.metrowerks.com
MC68HC908QY4CDW
Microcontroller
Motorola, Inc.
(847) 576-5000
www.motorola.com
MON08MULTILINK Pod
P&E Microcomputer Systems, Inc.
(617) 353-9206
www.pemicro.com
Model Z70A 433-MHz ATV
VideoLynx
(240) 602-1082
www.transmitvideo.com
Quagi Antenna
Wayne Overbeck
commfaculty.fullerton.edu/
woverbeck/n6nb.htm
might want to add a real-time clock
to allow for timed operations.
Another option is to add a maximum
PowerPoint tracking (MPPT) feature
similar to the Peak Power Controller
developed by James McGuire and
Thomas Burke for the Motorola Flash
Innovation 2003 Design Contest. An
MPPT feature could provide better
impedance match between the PV
panel and the battery, and therefore
allow maximum power to be extract-
ed from the panel.
I
RESOURCES
Dallas Semiconductor, “Interfacing
the DS18x20/DS1822 1-Wire
Temperature Sensor in a Microcon-
troller Environment,” AN162.
D. Forte and H. Nguyen, “Adding a
Voice User Interface to M68HC05
PROJECT FILES
To download the code, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2004/162/.
the camera’s tape mechanism is broken,
the video section still works; it provides
an excellent 10× zoom for the station.
In addition, the need for a low-volt-
age disconnect feature became obvi-
ous while operating with the under-
sized panel. LVD, a common feature
on charge controllers, disconnects the
loads if the battery’s voltage gets too
low. This not only protects the system
from a total shutdown caused by a dead
battery, but also prevents the battery
from being discharged to a level that
will tend to shorten its service life. The
specification for the MK 8G24 valve-
regulated, gelled-electrolyte battery
states that the battery can be cycled
about 500 times if the depth of dis-
charge (DOD) is 100%. It can be cycled
1100 times for 50% DOD, or cycled a
whopping 6000 times for a 10% DOD.
I added two set points to the config-
uration software to support the LVD
feature. This provided the needed hys-
teresis. To reduce the load on the bat-
tery, the station uses a photocell to
sense the ambient light level to turn
off the camera and transmitter at
night. The remaining load from the
PVCC control board is about 30 mA
in Charge mode with OSD active.
FUTURE ENHANCEMENTS
Currently, the station is operating
reliably. It provides great views of the
local black bear and whitetail deer
population. I’m happy to report that
the stories I had heard about the local
wildlife were true, and no fish have
been spotted.
There are a variety of ways you
could enhance this project. For
instance, you could add a simple boot-
loader to allow in-field flash memory
firmware upgrades. Presently, I use a
photocell as a light-level sensor to
determine when to turn the loads on
and off for automatic operation. You
Richard Dreher earned a B.S. in
Electrical Engineering from the
University of Wisconsin, Platteville.
He worked for 10 years as a motion
control consultant for firms in the
U.S. and Europe. Currently, Richard
devotes his time to his 1-year-old son
and to various embedded systems proj-
ects. You may contact him at
rich@dreher.net. For more information
on this project, visit www.dreher.net.
ROM resident function name
Entry address in ’QY4
Description
GETBYTE
$2800
Read 1 byte from PTA0
PUTBYTE
$FEA1
Send 1 byte out PTA0
RDVRRNG
$2803
Read and verify range of flash memory
(send memory range out PTA0)
ERARNGE
$2806
Flash memory erase range
PRGRNGE
$2809
Flash memory program range
Table 2—
With the ’QY4’s limited flash memory, these built-in ROM routines come in handy.
Applications,” AN1292, Motorola,
1996.
P. Lajsner, “Developer’s Serial
Bootloader for M68HC08,” AN2295,
rev. 3, Motorola, May 2003.
S. Pope, “MC68HC908QY4 Internal
Oscillator Usage Notes,” AN2312,
Motorola, 2002.
G. Whitacre, “Using MC68HC908
On-Chip FLASH Programming
Routines: ROM Resident Routines
in the MC68HC908GR8, MC68HC-
908KX8, MC68HC908JL3, MC68HC-
908JK3, and the MC68HC908JB8,”
AN1831, rev. 2, Motorola, 2001.
Editor’s Note: James McGuire and
Thomas Burke won Distinctive
Excellence for their Peak Power
Controller design. For more informa-
tion about their project, visit the offi-
cial Motorola Flash Innovation 2003
Design Contest web site at www.cir-
cuitcellar.com/fi2003.
The causes of failures can be broadly
classified into two categories. The first
contains failures attributable to weak
design. The design may not be robust
enough for the function or the operat-
ing environment. Software bugs or
other design errors fall under the same
category. The reasons for a weak design
may be many, but the problem can be
minimized through good engineering
practice, which starts with properly
defined and understood specification,
and continues through design reviews
and analyses such as fault tree analysis
(FTA), failure modes and effects analy-
sis (FMEA), reliability prediction, etc.,
which are performed concurrently with
the design. Finally, thorough, exhaus-
tive testing will validate the design.
Failures in the second category are
unavoidable. Whether you like it or
not, failures happen: a wire breaks, a
component wears out, or a bolt of light-
ning strikes the equipment. You can’t
prevent them, but you can be prepared
by designing the system architecture in
such a way that the effects of a failure
are predictable and not catastrophic.
That’s what this article is about. I’ll
show you the different ways of mak-
ing your equipment fault-tolerant.
It is generally accepted that redundan-
cy, along with proper design, is the cure
for loss of functionality because of equip-
ment faults. You must remember, how-
ever, that there may be conditions that
cannot be foreseen or that no practical
redundant design can handle. Typically,
if the equipment is exposed to a high-
intensity radiated field (HIRF) beyond
36
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
E
lectronic systems, which are now
more sophisticated than ever, provide us
with functions and systems intelligence
that was undreamed of only a few years
ago. As users of these marvelous devices,
we have become so reliant on their flaw-
less operation that we can no longer
imagine how we could have ever func-
tioned without them. Unfortunately, all
electronic systems fail at one time or
another. The question is not if, but
rather when and how they will fail.
When the malfunction occurs, what will
be its outcome? Will it be merely the
loss of the function, which may be frus-
trating but usually acceptable, or will
the malfunction have unpredictable,
potentially catastrophic results? Will it
be only a nuisance, like not being able to
watch the latest DVD movie, or will you
be faced with a critical, perhaps cata-
strophic, event, potentially causing a
loss of property or even a loss of life?
A good example of the future focus
on fault-tolerant embedded controllers
may be the “X-by-wire” automobile
that’s expected to appear on the mar-
ket by 2005. In the new automobile,
many currently mechanical functions
will be performed by electronics (e.g.,
steering and braking). Can you imagine
having to do the infamous three-finger
salute at 60 mph while the steering
has decided to have a mind of its own?
Electronic systems failures can take
several forms. The most desirable, of
course, is fail-operational, where the
system doesn’t as much as hiccup and
continues working as if nothing has
happened. Unfortunately, for some
Fault-Tolerant Electronic Systems
There’s no escaping it: sooner or later, all electronic systems fail. As a designer of embed-
ded systems, how can you prepare for system failures? Is there a way to plan for the unfore-
seen glitches? George’s article is a must-read for anyone with an electronic system in the
pipeline.
applications, the cost of such a system
may be prohibitive.
Fail-passive is the next best thing.
Following a fail-passive failure, the
system output assumes some predeter-
mined desirable state, typically a
power disconnect. Often, the system
has a human in the loop, such as an
aircraft pilot, and reverts to manual
control or some benign state.
The third condition, fail-active, is
highly undesirable. Although it can’t be
prevented with 100% certainty, it is
usually allowed as a small probability,
typically only 10
–9
. In the fail-active con-
dition, the actuators remain active but
uncontrolled with unpredictable results.
FEATURE ARTICLE
by George Novacek
Process
Feedback
+
Microcontroller
Inputs
(sensors)
Outputs
(actuators)
Process
Feedback
+
Microcontroller
Inputs
(sensors)
Outputs
(actuators)
BIT
Figure 1a—
The basic system is comprised of input
devices, output devices, and a controller. Not all such
systems require a feedback, but it gives you some
security.
b—
Adding a BIT gives you a system capable
of fail-passive operation.
a)
b)
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
37
(BITE) that’s external to the processor
(see Figure 1b). The BITE independently
monitors the performance of the process,
including the microcontroller. The oper-
ative word here is “independently.”
Being independent makes the BITE capa-
ble of detecting faults within the micro-
controller itself. In some situations, you
may have to feed it the input signals
as well, and, as is shown in Figure 1b,
you will want the BITE to be able to
independently shut down the outputs.
The BITE performs several functions.
First, during power-up, it performs the
power-up BIT (P-BIT), which verifies the
memory integrity and exercises a number
of functions that could not be exercised
during normal operation ( e.g., the WDT).
Make sure you don’t allow the P-BIT to
overwrite stored data or cause the inad-
vertent movement of mechanical parts
that could potentially injure someone.
The P-BIT is generally allowed to
take a few seconds, but you may want
to have two versions of it: a full P-BIT
for cold boot and a short version for
warm boot, when the several seconds
of delay might not be acceptable after
a manual command to re-enable.
The continuous BIT (C-BIT), which
runs in the background during normal
operation, is the monitor that validates
data, checks for its plausibility, scans
peripheral devices for integrity, and so
on. If the C-BIT detects a problem, it
can either initiate a fault-handler rou-
tine or activate the actuator disable (or
channel control) switch. Some systems
also provide initiated BITs (I-BIT),
which are test routines that can be ini-
tiated manually during system main-
tenance to test the accuracy, control
range, rigging, and so on.
FAULT PROPAGATION
Maintaining the physical independ-
ence of the processor and the BITE cir-
cuits is paramount. A common error is
to use devices from a multiple-device
package, such as a quad op-amp, in both
the process and monitor circuits. This
may save some money and PCB real
estate, but it is an absolute no-no. You
must also ensure that a fault cannot
propagate between functional blocks.
Consider the circuit diagram in
Figure 2. A fault within the sensor
could cause its entire 28-VDC power to
normally expected levels, input signals
in all the redundant channels can be
obliterated simultaneously or a mechani-
cal failure can sever several harnesses.
The goal is to design equipment that can
handle unforeseen conditions gracefully.
In case of an HIRF, for example, your
fail-operational controller might have to
go into fail-passive mode, or hold the last
position until the interference disap-
pears. You should never consider a situa-
tion when your embedded controller
goes out of control to be acceptable.
LET’S START SIMPLE
In a basic embedded control system,
and it makes no difference whether it’s
a position control or a communications
terminal, you have at least one input
and one output device in addition to a
processing unit, typically a microcon-
troller with peripherals such as memo-
ry, address decoding, and glue logic (see
Figure 1a). The feedback is not always
necessary, although it’s a good idea
because it provides the means for estab-
lishing that the process does what you
want it to do. Don’t assume it needs to
be used only in closed-loop control sys-
tems. You may use the same principle
just as well in a communications ter-
minal. For instance, by looping the
transmitted data back to the terminal,
you can see if what you have put on the
communications lines is in fact what
you had intended.
You can improve this rudimentary
design by including software built-in
test (BIT) routines, having the microcon-
troller validate and type the input data,
test the condition of the input and out-
put devices, and validate the outputs.
You can see this fundamental approach
in every PC. By now it has become the
minimum acceptable standard for any
embedded controller. Many of today’s
input and output devices are BIT-able,
which means they provide a way for the
processor to verify their health. Some
have a separate line, while others define
a healthy operating current range, and so
on. The same can be said of some micro-
electronics with internal BIT and one
pin dedicated to signaling its status.
The internal watchdog timer
(WDT), which is pretty much standard
in every microcontroller today, can, to
some degree, keep an eye on the pro-
gram execution. The usefulness of the
internal WDT is questionable because
it can be disabled by the software it is
supposed to monitor, and because it
resides on the same substrate with the
microcontroller that it is supposed to
watch. For a little extra money, I pre-
fer using an external WDT. Many are
available, and they also include cir-
cuits for monitoring a power supply.
If the program execution goes off the
rail for some reason, the microcontroller
will fail (hopefully) to reset the WDT,
and, in turn, the WDT will attempt to
reset the microcontroller and put it
back on track. If the microcontroller
detects through its BIT routines a prob-
lem with a peripheral device, you can
have it attempt to shut down the sys-
tem or go into some predetermined
state. This is all very well as long as the
microcontroller operates properly and
the critical peripheral devices can be
controlled. If not, the system can poten-
tially go fail-active, which is the one sit-
uation you must try to avoid.
BUILT-IN TEST
The solution to the aforementioned
predicament is adding BIT equipment
Figure 2—
Always make sure faults, whether external or internal, cannot propagate through the system and
between channels.
38
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
be negligible. The probability of its
failing followed by another fault that
would, consequently, go undetected, is
extremely improbable. This brings me
to the topics of BIT coverage, testabili-
ty, and BIT effectiveness.
BIT EFFECTIVENESS
BIT effectiveness, or fault coverage,
is expressed as a percentage of all the
possible faults within the device that
the BIT will detect. Mathematically,
the formula is as follows:
where
FD
is the fault detection coverage as a
percentage.
λ
h
is the failure rate for any
one fault in the system.
λ
i
is the failure
rate for the “i-th” identified fault.
λ
d
is
the sum total failure rate for all of the
detected faults.
λ
t
is the sum total failure
rate for all of the faults identified in the
system. Finally, note that K is the num-
ber of detected failures, and L is the num-
ber of faults identified in the system.
The fundamentals of testability and
fault coverage can be found in MIL-
STD-2165A, which was replaced in
1995 with MIL-HDBK-2165A. [1] The
original document is hard to find, but
it appears that little was changed
other than the name. The document
states that 80% to 95% fault coverage
is considered an acceptable result. It
also states the obvious fact that 100%
coverage is impossible to obtain.
The document is not easy to under-
stand, so it does not surprise me that
the fault coverage number has often
been torn out of context, misunder-
stood, and has found its way into prod-
uct specifications where it doesn’t make
much sense. The problem, for example,
is that the best practically achievable
fault coverage (95%) by itself is inade-
quate for any system where predictable
performance under adverse conditions is
important. It would mean that one out
of 20 failures may go by undetected, and
its effects would be unpredictable.
That’s not acceptable under any circum-
stances. And when you consider highly
integrated systems (e.g., a single custom
λ
λ
λ
λ
d
=
and =
i
i = 1
K
t
h
h = 1
L
∑
∑
FD
d
t
=
100
λ
λ
×
be placed on the multiplexer (MUX)
input and destroy it. Often, this can be
prevented by placing a resistor, R, in
series with the source to limit the maxi-
mum current, which, together with
diodes D1 and D2, keeps the input volt-
age to the MUX within safe limits.
Many devices have the protection diodes
already incorporated on the substrate,
although I prefer to use discrete devices.
When using a single input source for
two channels it may be tempting to use
just one resistor and connect the two
MUX inputs in parallel. Don’t try to
save the few cents. Use two resistors, R
and R
l
, as shown in Figure 2. Make sure
that a fault within MUX A does not
propagate to MUX B and vice versa.
Sometimes a resistor won’t do the
trick. Suppose a sample-and-hold cir-
cuit requiring fairly low source imped-
ance follows the MUX and you have
to use a buffer. It would be tempting
to feed the buffer, usually an op-amp,
from the existing
±
12-V analog power.
But what would happen if the buffer
fails? It could feed the 12 V into the
sample-and-hold circuit, which cannot
sustain it, and thus cause the chain
destruction of the entire channel.
Another problem could arise
because of power sequencing. Not all
the operating voltages come up at the
same time. The situation is even
worse in redundant systems that use
several independent power supplies.
This sequencing delay could prove cat-
astrophic if you don’t anticipate it.
It’s no less important to ensure that the
actuators always can be disabled. Totem
pole, high-side switches are usually a
good solution. It’s absolutely crucial to
analyze all of the possible faults and see
how they will affect the rest of the sys-
tem (FMEA) before the design is frozen.
How do you verify that the monitor
operates properly? You can do so by
having the processor test the BITE. You
can inject signals out of range or other-
wise disallowed to verify that the BIT
picks them up. Some of this can be
done only during the power-up
sequence, after which it becomes a
numbers game. In other words, having
established that a certain feature
works at power-up, such as WDT time-
out, the probability of its failing dur-
ing the projected operating time must
IC with a multitude of passive compo-
nents in the I/O lines, such as EMI fil-
ters and transient protection), the fault
coverage number would be much worse
because those passives are, for the most
part, untestable by the BIT.
Does it mean that you may have,
say, 50% undetectable failures? That’s
what blindly following the book and
doing the math tells you. Should you
care? With the exception of some
extremely specific military require-
ments that are not directly related to
safety, you really shouldn’t.
To guarantee safe performance, you
don’t need to detect that R135 is open
circuit or that low-pass EMI filter F71
is no longer providing the required
attenuation at 100 MHz because the
ferrite bead inside it has disintegrated.
Such a depth of fault isolation could
make some sense for improving main-
tainability and field repair in the days
of discrete components.
Today, field repair of SMT assemblies
is not a good idea to start with. It’s
more time and cost efficient to replace
the entire circuit board. You need the
BIT to detect when the system is not
behaving properly, isolate the fault to
the replaceable unit level, and initiate a
predetermined corrective action, such
as an actuator shutdown.
You don’t need to test each compo-
nent, but you should look at the sys-
tem as a whole. FMEA helps identify
all faults and makes sure they are all
detected, albeit the majority of them
indirectly. The component faults can
be detected by the behavior of their
functional block and the probability of
their occurrence determined by the
reliability prediction. Fault tree analy-
sis is used to show that the probability
of an uncontrolled failure effect (i.e.,
the fail-active state) is less than
allowed for a given system. Your spec-
ification will customarily state that
there shall be no dormant (or unde-
tected) failures, and that the probabili-
ty of a disallowed condition after a sin-
gle failure does not exceed (typically)
1 × 10
–9
probability.
FAIL-PASSIVE SYSTEM
Take another look at Figure 1b.
Make sure the output correctly reflects
the input conditions. You should create
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
39
multiple execution paths within the
software and follow other good design
practices. (For more information on
writing software, refer to my series
titled “The Joys of Writing Software,”
Circuit Cellar
121–123.)
In many instances, it is possible to
design and verify the software in such
a way that, if the microcontroller is
working correctly, the eventuality of
an incorrect output is extremely
improbable. This means that in some
systems the job of the external BITE
design could be reduced to merely
establishing that the microcontroller
is working properly. The microcon-
troller performs the remainder of the
BIT function, including the external
BITE verification.
This is the idea behind the external
WDT. Unfortunately, a commercially
available WDT can never guarantee
that the microcontroller is running
properly. It doesn’t take much imagi-
nation to come up with a number of
conditions that can forever toggle the
single WDT line, while the rest of the
system is off track. All it takes is a
single bit in a multimegabyte program
corrupted by an external perturbation.
This problem can be solved in a
number of ways. My favorite solution
is for the microcontroller program to
generate, within a predetermined time
slot, a sequence of 4-bit tokens, which
are fed into a modified WDT. In a well
thought out concept, the probability
of a microcontroller failure corrupting
the output, while allowing the tokens
to arrive on time and within the prop-
er sequence, becomes infinitesimal.
Although many input devices are
BIT-able or can be sufficiently verified
merely by their data plausibility (e.g.,
being within a certain range or occur-
ring in combination with others), oth-
ers need to be generated by dual-
redundant devices not only to verify
validity, but also to guarantee that a
valid input is available at all times.
Devices such as dual LVDTs for dis-
placement measurements and dual
temperature or pressure sensors are
commonly used in situations where
accurate knowledge of the value is
critical for the system’s performance.
Therefore, the first step in a system
design must be a hazard analysis to
determine the criticality of individual
functions and their necessary redun-
dancy requirements.
When processing analog inputs and
outputs, such as in a closed-loop posi-
tion system, verifying only microcon-
troller performance may not be suffi-
cient to guarantee the required safety.
Should this happen, the monitor also
needs to acquire raw analog signals, as
shown in Figure 1b, and process them
internally. Often, this can be accom-
plished using the BITE FPGA plus
ADCs, DACs, and table look-ups.
Most often, the BIT needs to verify
the output to be within a certain win-
dow only. Such single-channel, self-
monitoring architecture, with the
BITE capable of shutting it down
when a fault is detected, can be used
in a fail-passive system. It will also
serve as a building block for fail-opera-
tional systems with little change.
The Premiere Embedded Signal Processing Event
The International Signal Processing Conference at GSPx 2004
SPX.com, no later than March 15, 2004.
Abstracts will be reviewed as they are received.
Modeling/Simulation
Multimedia
Navi
Questions? Contact Global Technology Conferences at (617)243-9777 or info@gspx.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
41
An obvious question arises: Why not
build two identical, simplex, micro-
controller-based channels and simply
compare their outputs, as is depicted
in Figure 3, instead of bothering with
designing an FPGA BITE? In this dual-
redundant architecture, one channel
would provide the control, and the
other would be the monitor. The chan-
nels exchange data, and if they both
agree, the system remains operational.
If they differ, the system goes passive.
This is, in fact, another common
way of building fail-passive systems.
However, to avoid common mode errors
that could be caused by design, an inter-
nal bug in the microcontroller, a software
bug, or an external condition, it is often
required that you at least use dissimilar
software in the two channels. It’s prefer-
able to use dissimilar hardware as well.
The cost of the development and
certification of what amounts to two
different controllers, usually requiring
level A software (per DO-178B), is pro-
hibitive when compared to the archi-
tecture in Figure 1b. It’s easier and less
costly to create and, more importantly,
validate a monitor fully implemented
in hardware, even with the require-
ment to follow DO-254. [2] Well-
designed hardware can be fully testable,
but software rarely is. A hardware mon-
itor may allow you to reduce the soft-
ware criticality, and the self-monitoring
channel can be a useful building block
for redundant, fail-operational systems
at little extra development cost.
Another alternative, given here
merely for completeness, is to have
the dual-redundant channels fully cre-
ated in analog circuitry (see Figure 3).
This is an obsolete concept that pro-
vides no benefit of flexibility in
today’s environment.
FAIL-OPERATIONAL SYSTEMS
By employing a pair of self-monitor-
ing controllers, you can create a fail-
operational system that dual-redun-
dancy by itself cannot. (Two channels
let you determine that they do not
agree, but you cannot tell which one is
wrong.) You only need to slightly
modify the monitors (that’s also why
using an FPGA is a good choice) to
perform arbitration and switching
between the channels. A usual alterna-
tive is to make one channel dominant
and the other submissive at power-up.
The dominant channel controls the
process, and, while relying on its own
BIT for monitoring, it also exchanges
status with the submissive channel
that is running in parallel. A problem
detected within the dominant channel
causes its shutdown and control is
taken over by the submissive channel,
which becomes dominant.
The microcontrollers exchange data
via a serial interface. CAN bus is
quite popular and reliable. But, this
data exchange is noncritical; it’s mere-
ly a performance enhancement. The
dominant-submissive switch-over
Controller
Monitor
Sensors
Actuators
Figure 3—
This is a dual-redundant system. A dis-
agreement between the processing and monitoring
channels results in the disabling of the actuator.
42
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
interface between the monitors/arbi-
trators is accomplished by a hard
connection. For obvious reasons,
microcontroller communications
would be suspect at this point.
Besides, each channel must be fully
operational with the other channel
dead. To filter out noise, the switch-
over time is usually in milliseconds,
which most mechanical systems
don’t even notice.
There are numerous ways to
arrange the operation of the chan-
nels. One typical method is to have
both channels actively control with
their outputs summed up. This can
be done in many ways. For example,
when the actuator is a current-driv-
en torque motor (electrohydraulic
servo valve, or EHSV), its two coils
may be used in parallel, each fed by
one channel. In case one of the chan-
nels shuts down, you can either
enter into a reduced authority mode
by driving the torque motor at only
50% or raise the gain of the remain-
ing operational channel to deliver
100%. Your choice depends on the
system characteristics and the result
of the hazard analysis.
Another method is to have the sec-
ond channel in a standby or powered-
down mode and to activate it only
when it’s needed to take over control.
This way, the spare channel does not
accumulate any run-time. But, in
some systems, it may take an unac-
ceptably long time for it to come up
and take over. Consequently, it is
not seen too often in safety-critical
systems.
When considering fail-operational
architecture, don’t forget the mechani-
cal aspects of the electronic controller
(i.e., the packaging design). You must
look at it as if the controller has the
characteristics of a dew worm: if you
cut it in half, each half continues to
live on its own. There must be no
fault propagation from one channel to
the other; communications between
them must be nonessential, and
absolutely no components may be
shared. Normally, a metal partition
inside the cabinet ensures that a fire,
for instance, in one channel cannot
propagate to the next. Each channel
has its own harnesses and connectors.
Some dual-channel aircraft systems
reside in two separate cabinets, each
located in a different part of the air-
craft to prevent a mechanical event
from wiping out the entire system.
TRIPLE REDUNDANCY
To further increase the reliability
and availability of fail-operational sys-
tems, triple and even higher redun-
dancy is used, as shown in Figure 4.
Microcontroller 1
BIT
Microcontroller 2
BIT
Sensors
Microcontroller 3
BIT
Major
ity v
ote logic
Actuators
Figure 4—
This triple-redundant system uses three
independent computers with majority vote.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
43
George Novacek has 30 years of expe-
rience in circuit design and embed-
ded controllers. He is currently the
general manager of Hispano-Suiza
Canada, a division of the Snecma
Group, the world’s leader in manu-
facturing propulsion and landing gear
systems. You may reach him at gno-
vacek@nexicom.net.
REFERENCES
[1] U.S. Department of Defense,
“Testability Program for Systems
and Equipments,” MIL-HDBK-
2165, 1995.
[2] RTCA, Inc., “Design Assurance
Guidance For Airborne
Electronic Hardware,” DO-254,
2000.
RESOURCES
G. Novacek, “A Sure Thing:
Guaranteeing 99.99999%
Reliability,” Circuit Cellar 129.
———, “Designing for Reliability,
Maintainability, and Safety,”
Circuit Cellar
125 and 126.
There are many aspects to consider.
You can use ordinary, simplex chan-
nels, as in Figure 1a, or self-monitor-
ing channels, as shown in Figure 1b.
For instance, in making the decision,
you will have to consider the allow-
able tracking tolerances. If the outputs
of the three channels must track per-
fectly, you will have to use three chan-
nels with identical hardware and soft-
ware, and you’ll probably end up syn-
chronizing them. But that introduces
the higher probability of a common
mode fault within the system. I can-
not think of a position control where
such perfect tracking would be
required and the accompanying danger
of common mode faults preferable to
having dissimilar hardware and soft-
ware. I would also feel more comfort-
able with the self-monitoring arrange-
ment, especially when the cost of the
FPGA monitor is negligible compared
to the entire system and its criticality.
The idea is that the triple and more
redundant systems control on the
basis of a majority vote. Voting is
accomplished in an external module;
but, the processing units often
exchange input and status data for
“pre-voting” as well. This internal
data exchange, if not properly
designed, can lead to an unwanted
effect, when no two outputs are the
same. This is called a Byzantine
Generals’ Problem. When designing
the data exchange and voting scheme,
this probability must be considered. It
can be avoided, for example, by using
the MVS algorithm, which selects the
output that is between the other two.
The external voting module can be
implemented electronically, or it can
be mechanical or hydraulic. This
depends on the specifics of the system.
We have considered what happens
when the system experiences a single
fault. Most fail-passive systems accept
a 10
–9
probability of a critical failure
(i.e., the fail-active state) caused by a
single fault. This represents one fail-
ure in more than 100,000 years. The
probability of a dual failure is expo-
nentially less. In real life, however,
the impossible does happen. As
British Prime Minister Disraeli once
said, “there are lies, damned lies, and
statistics.” One time I experienced an
“impossible” event that had a 10
–9
probability of happening within the
first minute of operation of the first
production unit. Although extremely
embarrassing, the subsequent design
review showed no design flaw. The
event hasn’t repeated itself for
almost 15 years.
What if you have a critical system
and the statistically impossible is not
impossible enough? The approach is
essentially the same as for the single
fault: you just increase redundancy.
There are, for instance, triple-redun-
dant flight computers in which each of
the three computers is triple redundant
itself, using three different processors
from three different manufacturers to
avoid common mode failures.
EXPECT THE UNEXPECTED
In summary, let’s review the differ-
ent architectures, keeping in mind
that there are many combinations of
those basic principles. Starting with
the plain vanilla simplex controller
like the one in Figure 1a, you must
recognize that it is unsuitable for any
system where safety and reliability
may be of concern. The first failure
puts it out of commission and the
repercussions are anybody’s guess.
A fail-passive system, composed of
a self-monitoring controller, as shown
in Figure 1b, or a dual-redundant con-
figuration as in Figure 3, will satisfy
many requirements. After the first
failure, it will shut down or assume
some other predetermined state with
a probability of usually less than 10
–9
of going fail-active. After the system
deactivates, a second failure should
not be a concern.
A dual self-monitoring system like
the one in Figure 5 will continue to
operate after the first failure; it goes
fail-passive after the second failure.
Triple-redundant (and higher) systems
will potentially remain fail-operational
until the last channel, which will be
fail-passive.
Finally, when designing an embed-
ded controller, it is extremely impor-
tant to consider failures that can affect
all of the channels at once. A good
example is a signal corruption, which
can be the result of a lightning strike,
HIRF, mechanical failure, etc. Such
faults differ from simple component
failures in that they can and usually
do affect the processing channels
simultaneously. Therefore, it is impor-
tant to understand how the system
will behave under such circumstances
and make sure that it does not become
fail-active. Ensuring RF immunity and
full functionality at 200 V/m is one
thing you can do. But, what happens if
the system is irradiated by a burst of
400 V/m? Or what if the shielding gets
disconnected? You must always con-
sider the unexpected and make sure
the results are predictable.
I
Microcontroller
BIT and arbitrator
Microcontroller
BIT and arbitrator
Sensors
Actuators
Figure 5—
The dual-channel system uses a self-moni-
toring pair to achieve fail-operational configuration.
charges the capacitor to the power
supply level, and the processor reads
the I/O pin as a logic high. When the
processor switches the pin to an out-
put and sets the output level to logic
low, the capacitor discharges to the V
LO
voltage level. If it’s a CMOS output, the
voltage level is close to ground.
After the capacitor is discharged and
you switch the I/O pin back to
Tristate mode (input), the processor
reads the input as a logic low level.
The capacitor again charges through
the resistor at the following rate:
[1]
The processor can track the time it
takes for the capacitor voltage to move
from a logic low representation to a
logic high. You can determine this by
solving Equation 1 for the time it takes
to go from a low level to a threshold
voltage (usually 50% in CMOS designs).
[2]
Photo 1 shows what this looks like on
an oscilloscope.
V t
V
e
t
RC
t
CC
t
RC
( )
ln
ln
.
= 0.5 = 1
0.5 =
=
−
−
(
)
−
−
( )
×
−
1
1
0 5
RC
=
RC
t
1
0 693
.
×
V t
e
t
RC
( ) = V
CC
1
−
−
44
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
I
haven’t written for a while. I’m glad
to be back. Since my last appearance
(“One Man’s Trash,” Circuit Cellar
136), I have worked for a particle accel-
erator and moved to a new state. I now
have a new job; it’s probably one of the
best jobs I’ve had so far. I think about
how to use our products in applica-
tions and implement prototypes, refer-
ence designs, and application notes.
Most of all, I still get to write about
projects, which is something I enjoy.
If you’re like me, the following may
happen to you: You’re working on a
design, and have everything figured out,
when you realize that you need to add
an analog input. Typically, you would
like to add an input to measure the tem-
perature or power supply/battery voltage
to monitor the health of your system
(e.g., when the temperature goes too
high or a power supply voltage is out
of spec, you will want a warning or per-
haps have things shut down if there is a
chance of resultant damage). But what if
you have only one digital I/O pin left?
Or, what if you’re cost constrained?
Single-Pin Analog-to-Digital Conversion Techniques
Picture this: you need to add an analog input to a design, but you have only one digital I/O
pin remaining. This month, Ingo presents an intelligent, cost-effective solution.
Traditionally, you would choose an
A/D converter to do the job. This device
takes a signal (voltage) and, using vari-
ous techniques, converts it into a digital
word. The word width varies (8 to 16 bits
are common), and reading out the data
is usually done via parallel or serial
buses. Oftentimes, they add too much
cost, or interfacing them is too bulky.
If only you could use a digital I/O
port as an analog input port. Well, in a
pinch, it’s possible to do this and get
surprisingly good results while you are
at it. It’s also inexpensive.
PULSE-BASED MEASUREMENTS
The basic idea is to use a digital bidi-
rectional I/O pin for triggering an RC-
based circuit and then measure the rise
time of the circuit. Most modern
processors and FPGAs have flexible I/O
pins that can be programmed as input
or output pins with tristate capabilities.
CMOS-compatible inputs usually
have a threshold voltage that’s about
50% of the supply voltage to ground.
CMOS outputs will switch close to
supply voltage and ground
for logic high and low. This
makes it possible to use a
CMOS output to discharge
a capacitor to ground,
switch it to Tristate mode,
and wait for a logic transi-
tion when it charges.
Let’s look at a simple
example. Consider wiring
a small capacitor between
ground and an I/O pin and
a resistor between the I/O
pin and a power supply, as
seen in Figure 1. When the
I/O pin is in Tristate mode
(input only), the resistor
FEATURE ARTICLE
by Ingo Cyliax
Figure 1—
My RC circuit is simple; it’s wired to a digital
I/O pin.
Photo 1—
The basic capacitor charge curve applies to Equation 1.
I/O
R
C
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
45
What you choose as the values for R
and C depends on various things. Picking
large R and C values makes the timing of
the circuit slow, which allows you more
time to measure the transition of low to
high. Watch out for large capacitor val-
ues, however, because they take more
current to discharge, and your I/O pin
may not have enough drive to complete-
ly reset the capacitor in time. Also, what
you are trying to measure may dictate
one of the values, perhaps R, and you
have to adapt the other components to
work with your timing technique.
There are several ways you can actu-
ally measure the pulse times. The sim-
plest, of course, is polling. To poll, you
perform the reset sequence (i.e., config-
ure a pin for output to discharge, and
then configure for input), read the sys-
tem timer value, wait until the input
reads one, read the system timer, and
compute the difference in time.
Polling is simple, but it ties up your
software while you perform the poll.
Listing 1 shows a polling setup.
If your processor supports interrupts
on input pins, you can use a rising-edge
interrupt to signal the end of the timing
cycle and read the system timer. The
interrupt service routine can then dis-
charge the capacitor and start another
timing cycle. However, there is some
uncertainty in reading the timer value
after the interrupt occurs, depending on
your system (e.g., if your system has
other interrupts at a higher priority or
sections of code in which interrupts are
disabled, these will affect your interrupt
latency and timing measurements).
Listing 2 shows a program that uses
an interrupt to measure the pulse.
The best way to do this is to use a
hardware input capture timer if your
processor has one. Start the cycle by
performing the discharge sequence and
arming the input capture timer. Then,
wait for an interrupt indicating that the
input capture timer has found the event
you are looking for (rising edge) and that
you can read the value from the capture
register. Using an input capture timer
avoids timing uncertainty and makes
for the most accurate measurements.
Hardware timers can measure shorter
delays than possible in software. Listing 3
shows a routine that uses a capture reg-
ister to measure the RC pulse time.
Listing 1—
This routine uses simple polling for measuring pulses.
main()
{
int stime,etime;
WrPortI(PEDR,&PFDRShadow,0x00);
WrPortI(PEDDR,&PFDDRShadow,0x00);
WrPortI(TBCR, &TBCRShadow, 0x08); //Clock source per clock
while(1){
costate {
//Reset the capacitor
WrPortI(PEDDR,&PEDDRShadow,0x01);
waitfor(DelayMs(10));
//Now wait for the cap to charge
stime = (RdPortI(TBCMR)<<8)|RdPortI(TBCLR);
//Read timer
WrPortI(TBCSR, &TBCSRShadow, 0x01);
//Enable timer
WrPortI(PEDDR,&PFDDRShadow,0x00);
while(!(RdPortI(PEDR)&0x01));
WrPortI(TBCSR, &TBCSRShadow, 0x00);
//Stop timer
etime = (RdPortI(TBCMR)<<8)|RdPortI(TBCLR);//Read timer
stime &= 0x3ff;
etime &= 0x3ff;
printf("%4d\r",(etime-stime)&0x3ff);
}
}
}
Listing 2—
Use interrupts when they are available.
int stime,etime;
nodebug root interrupt void ext0_isr()
{
WrPortI(TBCSR, &TBCSRShadow, 0x00);
//Stop timer
etime = (RdPortI(TBCMR)<<8)|RdPortI(TBCLR); //Read timer
}
main()
{
SetVectExtern3000(0, ext0_isr);
WrPortI(I0CR,&I0CRShadow,0x09);//Rising edge, priority 1
WrPortI(PBDDR,&PBDDRShadow,0x04);
WrPortI(PFDR,&PEDRShadow,0x00);
WrPortI(PEDDR,&PEDDRShadow,0x00);
WrPortI(TBCR, &TBCRShadow, 0x08); //Clock source per clock
WrPortI(PBDR,&PBDRShadow,0x04);
while(1){
costate {
//Reset the capacitor
WrPortI(PEDDR,&PEDDRShadow,0x01);
//Read timer
stime = (RdPortI(TBCMR)<<8)|RdPortI(TBCLR);
//Enable timer
WrPortI(TBCSR, &TBCSRShadow, 0x01);
//Start charging
WrPortI(PEDDR,&PEDDRShadow,0x00);
//Let the ISR do its thing
waitfor(DelayMs(10));
stime &= 0x3ff;
etime &= 0x3ff;
printf("%4d\r",(etime-stime)&0x3ff);
}
}
}
46
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
MEASURING STUFF
I have showed you how to measure
an RC circuit. Now, I’ll discuss how
to apply the basic time measurement
to measure useful quantities.
In the RC circuit, the pulse time
depends on the RC value. If you know
the capacitance in the RC circuit, it’s
easy to derive an equation for comput-
ing the R value with a known frequen-
cy: R = T
PULSE
(0.698 × C). Conversely,
if you know the resistance of the RC
Listing 3—
The complete thermistor code example for a Rabbit 3000 processor using the hardware input
capture timer for measuring the pulse width of the thermistor-based RC circuit.
#define RESOLUTION 0.1 //Define desired resolution in microseconds
#define CLOCK 11.1 //Clock speed in megahertz
#define Rth 10000.0 //Thermistor T25 resistance in ohms
#define Bth 3964.0 //Thermistor B value
#define Cap 0.010 //Capacitor in microfarads
main()
{
unsigned int i, j;
unsigned long k;
float Resolution;
//Sample interval in microseconds
int TAT8value;
//Timer A8 value
float PW, Freq, R, A, T;
TAT8value = CLOCK*RESOLUTION/2 - 1;
//Calculate TA8 value
if ( TAT8value>255 )
{ printf ( "Resolution too low for single counter\n\r" );
exit(1);
}
Resolution = ((TAT8value+1)*2) / CLOCK; //Calculate actual
//resolution
PW = 65535*Resolution;
Freq = 1e6/(2*PW);
//Calculate frequency
//Compute A
A = 1/298.0 - ((1/Bth) * log(Rth));
WrPortI(PBDDR, &PBDDRShadow, PBDDRShadow | 0x04);
BitWrPortI(PBDR, &PBDRShadow, 0, 7);
//Drive output low
WrPortI(PDDDR, &PDDDRShadow, PDDDRShadow | 0x20);
BitWrPortI(PDDR, &PDDRShadow, 0, 5);
//Drive output low
WrPortI ( TAT8R, NULL, TAT8value );
//Set TA8 prescale
WrPortI ( ICS1R, NULL, 0x88 );
//Start/stop = PF1
WrPortI ( ICCR, NULL, 0 );
//Disable interrupts
WrPortI ( ICT1R, &ICT1RShadow, 0x10 | 0x08 | 0x01 );
//Counter disabled, latch on Stop,
//Start on falling edge, Stop on rising edge
WrPortI ( ICCSR, &ICCSRShadow, 0x4 ); //Normal IC operation,
//reset counter
WrPortI ( ICT1R, &ICT1RShadow, 0x40 | 0x10 | 0x00 | 0x01 );
//Counter runs from Start to Stop,
//latch on Stop, Stop on rising edge
while(1){
costate {
WrPortI(PFDDR, &PFDDRShadow, PFDDRShadow |0x02);
WrPortI(PFDDR, &PFDDRShadow, PFDDRShadow & ~0x02);
WrPortI(ICT1R, &ICT1RShadow, 0xC0 | 0x10 | 0x00 | 0x01 );
waitfor(((RdPortI ( ICCSR ) & 0x10) == 0x10 ));
i = RdPortI(ICL1R);
//Read low byte
j = RdPortI(ICM1R);
//Read high byte
k = i + (j<<8);
//Combine them
PW = Resolution*k;
//Convert to usec
R = PW / ( 0.7 * Cap );
//Compute resistance
T = 1 / (A + ((1/Bth)*log(R))); //Compute temperature
//inKelvins
printf ( "R=%7.1fOhm T=%7.1fC %7.1fF\r",
WrPortI ( ICCSR, &ICCSRShadow, 0x4 );
}
}
}
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
47
circuit, finding the capacitance is sim-
ple: C = T
PULSE
(0.698 × R).
This is pretty cool because you can
directly measure the resistance or
capacitance of components. With an
A/D converter, you would have to add
additional circuitry in order to meas-
ure these directly. For instance, you
would have to build a voltage divider
to measure a resistor or some sort of
capacitor-based converter to measure
the value of a capacitor indirectly.
You can measure inductances, too.
This is a bit trickier. Inductors are
current-based devices:
[3]
For instance, an RL circuit behaves like
an RC circuit, but in a dual-current volt-
age representation. Consider the series
RL circuit in Figure 2. The expression
for the current building up in a series RL
circuit with a constant voltage source is:
[4]
You can measure the current by meas-
uring the voltage across the resistor.
RL circuits have an expression for the
time constant (i.e., 63% of the charge):
[5]
Let’s take a look at an example. If
your processor can supply a maximum
current of 10 mA at 3.3 V, then the
resistor has to be approximately 330
Ω
.
At 330
Ω
, the series resistance of the
coil is not significant, so you can
ignore it. You can use a time constant
of approximately 1 ms to make meas-
uring this in software possible: L =
0.001 × 330 = 0.33 H. A 0.33-H coil is
extremely large. Typical coil values for
air coils are in the microhenry range.
In order to use RL circuits, you have
to use either extremely fast pulse-tim-
T
L
R
=
I t
tR
L
( ) = I
e
MAX
1
−
−
V t
Ldi
dt
( ) =
ing hardware or low-resistance (high-
current) setups to slow the response
time of the RL circuit. So, although
it’s possible, implementing an RL cir-
cuit is tricky.
Finally, measuring voltage levels is
possible with an RC circuit. Consider
the RC setup again, but this time,
vary the input voltage:
[6]
Measure the pulse width until the
low-to-high threshold is normal. But,
now the expression simply becomes:
:
[7]
To make this work well, you need a low-
impedance voltage source, or you must
use an op-amp-based voltage follower
to isolate the source from the circuit.
REAL-WORLD EXAMPLES
The most common use for this tech-
nique is adding a temperature sensor
to an unused I/O pin on a processor.
Thermistors are temperature-sensitive
resistors. They are actually semicon-
ductors that have a negative tempera-
ture coefficient (NTC), which means
their resistance decreases as tempera-
ture increases. They are extremely
inexpensive, and because they behave
like resistors, you can use them in an
RC circuit.
Also, NTCs come in a variety of
resistance values and are characterized
by their resistance at a particular cali-
bration temperature, typically 25°C.
Common R
25
values are 3 and 10 k
Ω
.
A 10-k
Ω
thermistor with a 1-µF capac-
itor will make a timing constant of
approximately 6.93 ms at 25°C:
[8]
That’s easy enough to measure.
Thermistors, however, are not linear
devices. They can be approximated
with the following expression:
[9]
where B (beta) is provided by the ther-
mistor’s vendor and can be found in
T
A
B
KEL
=
+
ln R
TH
1
1
×
(
)
t
t
=
10 k 1 f
= 6.93 ms
1
0 693
.
×
×
Ω
µ
V
IN
t
RC
= 1.65 V
e
×
−
−
1
V t
t
RC
( ) = V
e
IN
1
−
−
the component’s datasheet. A is com-
puted in the following way:
[10]
Putting all of this together, Listing 3
contains the code for reading a thermis-
tor and converting the reading to degrees
Celsius or Fahrenheit. If you don’t care
about the accuracy over a wide range,
you can simply use a linear approxima-
tion by calibrating several temperature
values and interpolating the result.
Another interesting application for
measuring capacitance directly is the
use of a proximity detector. You can
take advantage of the variance in an
air capacitor using electrodes in an RC
circuit. When an object with a higher
dielectric constant than air comes
close to the electrodes, the capacitance
increases. Interestingly, humans are
easily detected with this method
because we are made mostly of water
and have a fairly high dielectric con-
stant. Distilled water has a constant
that is 80 times higher than that of air.
Figure 3a shows a simple proximity
sensor and circuitry. The electrodes
can be nearly anything metallic, such
as unused PCBs or copper/aluminum
foil with adhesive on the back. The
more area and the closer to the object
you are trying to detect they are, the
more sensitive they will be.
Proximity detectors are useful as
touchless switches (you can wear gloves)
and fluid-level detectors. (Make sure the
electrodes are insulated from the fluids
you are trying to measure.) Inductors are
A
T
B
R
=
1
1
−
ln( )
R
V
SQUARE
V
r
L
Figure 2—
V
SQUARE
is a square wave source for this
basic RL circuit.
I/O
R
Electrode
Electrode
Figure 3a—
Simple RC circuitry is the basis for this
proximity sensor setup.
b—
A metal detector system is
a great tool for sensing cars in your driveway.
R
0.25 L293
Out
In
12 V
N = 10
a)
b)
48
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
useful for finding ferroelectric metal.
An air coil inductor’s inductance will
increase if material with a constant per-
meability higher than air is brought into
the inductor’s field. Figure 3b shows a
simple circuit. Envision using this tech-
nique to detect cars in your driveway.
Earlier, I described some of the chal-
lenges that arise when using an RL-
based circuit. Let’s examine a new
setup. If you use a large coil in the drive-
way, the inductance is approximately:
[11]
where N is the number of turns, d is
the diameter in inches, and l is the
length (width of coil).
Assume a 9
′
loop with 10 turns of
wire:
[12]
The length of the wire is 595
′
(length =
π
× 9 × 12), and the wire resistance is:
[13]
At 12 V, this gives you a maximum
current of 2.28 A. To limit the current
to 1 A (a nice round number), add a
5.6-
Ω
resistor in series, and you’ll
arrive at a time constant of:
[14]
Adding a car significantly increases
the inductance, and thus the time con-
stant increases. Therefore, you should
be able to tell if a car is present or not.
There is a downside. To make this work,
you need a high-current driver that’s
able to switch the coil at 12 V and 1 A.
Finally, you can measure physical
displacement using capacitors. You
already know about variable capacitors,
which you can measure with an RC
circuit, but how about using two tele-
T =
H
= 50 ns
5 98
12
.
µ
Ω
R
WIRE
=
= 6.3
10 5
1000
.
’
Ω
Ω
L
L
=
9
12
9 12" + 40 0.125"
= 5.9
100
18
2
×
×
(
)
×
×
(
)
×
(
)
"
8
8 H
µ
L H
N d
d
(
)
µ
=
+ 40l
2
2
18
scoping metal tubes that are insulated
from each other (see Figure 4)? The
more the tubes slide out, the less the
coupling and the lower the capacitance.
WATCH OUT
Digital inputs are meant for digital
signals, which means they typically
don’t like to see voltages higher than
the V
CC
or lower than GND. Digital
inputs are protected with small diodes
in order to dissipate static electricity
and surges from getting into the chip’s
logic where they can break down the
insulation. These protection diodes
typically cannot handle large currents.
When you hook up analog devices to
inputs, make sure the voltage levels
stay within the rated levels of the digi-
tal input. If they don’t, then add exter-
nal diodes to bypass to either the power
supply or ground supply circuits. See
the illustration in Figure 5 to learn
how to do this. This is especially nec-
essary when dealing with inductors,
because they cause largish voltage
spikes when switched too quickly.
I hope you find all of this useful.
The next time you need to add a sim-
ple temperature sensor or voltage
monitor, and you have only a pin or
two left, you should consider these
techniques.
I
I/O
R
Figure 4—
The telescoping tube sensor measures lin-
ear displacement.
47
MMBD7000DL
I/O
Figure 5—
Use a dual diode to protect digital inputs
from over/under voltage.
Ingo Cyliax received a B.S.C.E.E. from
Purdue University. Ingo has worked for
universities and small companies, and
he has been consulting on his own and
writing for many years. He currently
works as an application engineer at
Z-World. You may reach him at cyli-
ax@ezcomm.com.
SOURCE
.
Rabbit 3000
Rabbit Semiconductor
(530) 757-8400
www.rabbitsemiconductor.com
charges up. At the end of the burst, the
time it takes the integrator to discharge
at a constant rate is measured to deter-
mine the size of the charge. That is
how the average amplitude of the signal
applied to the integrator is determined.
Because random noise is not syn-
chronized with the switching in the
synchronous demodulator, it is not rec-
tified; it averages out to nearly zero.
The longer the integration time, the
less proportionate effect a given small
pulse of noise has on the integrator’s
output and the more gain the integra-
tor has for the 1-kHz burst. Integration
is the wonder of lock-in amplification.
GETTING THE DROP
One critical part of measuring an
extremely low resistance is developing an
IR drop across the resistance, and meas-
uring only that. Getting the IR drop itself
is easy. A PNP switching transistor is
driven into saturation with the 1-kHz
burst, and the transistor’s collector deliv-
ers 5-V
PP
pulses to a 220-
Ω
resistor in
series with the resistance being tested
(see Figure 2). The voltage across the
220-
Ω
resistor is virtually constant as
long as the transistor is always driven
into saturation and the resistance under
test is low. A 100-m
Ω
resistance will
have a maximum voltage drop of 2.3 mV,
so the error introduced by using a 220-
Ω
resistor instead of a constant current
source is only 0.05% (2.3 mV/5 V). I
think you will agree that this approach
is sufficient for a 100-count meter.
As I tested the circuit, it surprised me
that when leaving the input open cir-
cuited, the meter gave an extremely low
50
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
A
milliohmmeter is just the tool for
checking trace resistance on a PCB,
tracking down shorted traces, and meas-
uring the contact resistance of a switch
or connector. It’s the kind of tool that
occasionally comes in really handy, but
not often enough to justify shelling out
hundreds of dollars for one. Wanting one
anyway, I set out to make my own.
This project was not only exciting; it
was a true adventure of discovery
because it provided a window into the
workings of lock-in amplifiers. With a
lock-in amplifier topology, a microcon-
troller and a little firmware make the
venerable (if somewhat noisy) LM324
bipolar op-amp provide high gain. It
reduces noise at the same time. Improve
analog performance with a microcon-
troller? Now this is a fun project!
My main concern for the milliohmme-
ter design was how to get stable resist-
ance readings with a suitably low test
current. After all, I wanted to look at a
few milliohms (or few tens of milliohms).
I also wanted to keep the test current low
so as not to exceed the current ratings of
some of the parts that I wanted to test,
and so I could run it all from a battery.
For starters, 25 mA × 1 m
Ω
= 25 µV.
This meant I would have to be able to
measure and display voltages in the range
of tens of microvolts per count in a stable
and repeatable manner. I also wanted the
circuit to be forgiving of my hand-wired
breadboards (see Photo 1). That is what
led me to the lock-in amplifier.
LOCK-IN WONDER
A lock-in amplifier provides gain for
the signal at a specific frequency and
Microcontroller-Based Digital Lock-In Milliohmmeter
A milliohmmeter is a handy tool for tasks like measuring a switch’s contact resistance and
checking the trace resistance on a PCB. Dick built his own microcontroller-based digital mil-
liohmmeter using lock-in amplifier topology. The project is simple as long as you follow Dick’s
instructions. Get ready to improve analog performance with a microcontroller.
phase while reducing other signals,
including noise. It’s almost like getting
something for nothing, but that’s not
really the case. You have to effectively
average numerous measurements to
improve the signal-to-noise ratio, so
what you are really doing is trading
away bandwidth and responsiveness to
improve the signal-to-noise ratio.
In this circuit, a 1-kHz burst of 5-V
PP
pulses is applied to a series-dropping
resistor to establish a pulsing current
through the resistance being tested (see
Figure 1). The IR drop across the resis-
tor being tested is a voltage proportion-
al to the value of the resistance. After
passing through a high-pass filter to
eliminate the DC component of the sig-
nal, it is rectified by a synchronous
demodulator. For a period of time corre-
sponding to the burst, the rectified sig-
nal is applied to an integrator, which
FEATURE ARTICLE
by Dick Cappels
Photo 1
—
Because it integrates the signal over
999 cycles, the lock-in amplifier is extremely forgiving of
my layout and wiring. The microcontroller is at the
opposite end of the board from the analog circuitry. An
additional transistor inverter is an RS-232 receiver left
over from an earlier project. The current-switching PNP
and input-shorting push buttons are on a small daugh-
terboard. You can also see a 100-m
Ω
test resistance.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
51
the Zero Input button attenuates
the signal to well below 23 mV
(less than one count).
It is necessary to have a resist-
ance under test connected to the
test leads while zeroing so that
the offset signals are the same for
the case of zeroing the meter
and taking actual measurements.
Perhaps a more careful layout in
addition to some shielding would
eliminate the need to do this.
THE PREAMP
The first part of the circuit that
the voltage across the resistance goes to
is an AC amplifier with adjustable gain
that doubles as a high-pass filter. The AC
coupling on the input and feedback paths
are required to eliminate the DC compo-
nent of the signal from the resistance
under test. The high-pass filter is helpful
in reducing noise pickup from power
lines as well as rejecting some of the 1/f
and shot noise in the op-amp itself.
The input capacitor and 1-k
Ω
bias
resistor shown in Figure 4 set the
high-pass corner frequency for the
input at 480 Hz, which was derived
from the following equation:
where R is the resistance in ohms, and C
is the capacitance in farads. The 4.7-k
Ω
resistor and 0.047-µf capacitor in the
feedback loop set a second high-pass pole
at approximately 720 Hz. This means
that the amplifier’s frequency response is
fairly flat for frequencies above 720 Hz.
For frequencies below 480 Hz, the
amplifier’s response is reduced by a
factor of 0.25 each time the input fre-
quency is cut in half; there-
fore, at 60 Hz, where power
line interference in North
America is a concern, the
amplifier’s gain would be
down to one-sixty-fourth of
its response at 1 kHz. Because
AC coupling was necessary,
positioning the poles at these
frequencies enhances the
noise performance of the cir-
cuit at no additional cost.
The circuit has a voltage
gain of 1 for DC because there
is no attenuation of the DC
480
1
2
Hz =
π
RC
resistance measurement. I spent a long
time looking over the firmware, search-
ing for mathematical errors or register
use conflicts, before I decided to take a
look at the circuit with an oscilloscope.
I saw that there was virtually no signal
across the input terminals when the
meter’s input terminals were unloaded.
Without the test resistance in series
with the 220-
Ω
resistor, there was no
signal. The input just charged up to 5 V
and wiggled a little because of capaci-
tive coupling between the transistor’s
base and collector. That’s when I added
the 10-k
Ω
resistor from the PNP’s col-
lector to ground. I should have taken
my earliest mentor’s advice, “Always
look for the simplest explanation first.”
To make sure that I was only measur-
ing the resistance of the thing I was try-
ing to measure and not the resistance of
my test leads, I used a four-wire meas-
urement system. Two wires were used
to deliver the test current. Two separate
wires were used to measure the voltage
drop. Simple enough, but how did I keep
the test current ground return path sepa-
rate from the voltage sense ground line?
Therein lies much of the art
involved with circuit layout.
As you can see in Figure 2,
the “test current return” ter-
minal connects directly to the
battery’s negative connection
to the circuit. The “small sig-
nal return” signal connects to
the rest of the analog circuit’s
grounds and then joins with
the battery ground at the
point in the circuit where the
1.8-V reference voltage is gen-
erated. The overall grounding
scheme is depicted in Figure 3.
The big trick here is to keep the vari-
ous 1-kHz signals from the synchro-
nous demodulator and currents from
the test current circuit out of the signal
from the resistance being tested. The
circuit is somewhat forgiving in that
the unintentional signals end up affect-
ing the integrator’s output as offset and
gain errors. The gain error is easily
taken care of in calibration. The offset
error is automatically taken out by the
firmware in the microcontroller.
Another challenge involved finding a
convenient way of shorting the input
signal to zero the meter. I wanted to get
an effective short of 1 m
Ω
or less, but
FETs were out of the question for this
kind of resistance, and the mechanical
push buttons I had were coming out
between 10 and 30 m
Ω
after a few dozen
operations. (One of the nice things about
having a milliohmmeter is that you can
actually measure these parameters.)
I finally settled on the solution of put-
ting a 4.7-
Ω
resistor in series with the
signal path. If the test leads are connect-
ed to a low-value resistor (i.e., less than
a couple hundred milliohms), pressing
Integrator
Signal
Control
Comparitor
Microcontroller
Data
Out
Reference
Dropping
resistor
Resistance
under test
High-pass
amplifier
Test bursts
Synchronous
demodulator
5-V
PP
, 1-kHz Bursts
60 µV
PP
/count
30 µV
P
/count
6.4 mV/count
Figure 1
—
The lock-in amplifier detects and integrates bursts of 1-kHz pulses that result from the IR drop across the resist-
ance being tested. The result is 46 db of signal gain while vastly improving the signal-to-noise ratio. The preamplifier doubles
as a high-pass filter to remove the DC component of the pulses and reduce flicker and burst noise from the op-amp.
Figure 2
—
The 1-kHz switching signal to the base of the 2N2907 causes 5 V
PP
to be applied to the 220-
Ω
resistor in series with the resistance under test. This
triggers 23 mA
PP
to flow through it.
52
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
erance of any of the components in the
circuit. Looking back, I could have
made the adjustment range much small-
er to make the adjustment less critical.
SYNCHRONOUS DEMODULATORS
As a kid, when I would switch on my
dad’s tube-type car radio in the quiet
of early mornings, I would hear a faint
hum of a few hundred hertz from under
the dashboard before sound started
coming out of the speaker. It was the
vibrator power supply, and its oscillat-
ing electromechanical contacts were
performing the functions of the power
switch and synchronous demodulator.
These days, synchronous demodula-
tors based on an FET switch, diode
bridges, and transconductance multipli-
ers are used in everything from power
supplies to Bluetooth receivers. They all
have the same basic function: rectifying
the incoming waveform by switching the
waveform into a filter or integrator using
signal in the feedback path. When I first
built this circuit, the 1-k
Ω
bias resistor
was much larger. I was disappointed
when I realized that a large offset volt-
age on the output had resulted from the
op-amp’s input bias current. I could
have switched to an FET input amplifi-
er, but at least half the fun in this proj-
ect involved trying to get impressive
performance with a cheap bipolar op-
amp, so I lowered the input resistor to
1 k
Ω
and the offset became small enough
to compensate for using the offset
potentiometer. There was no DC gain
in that stage, so it was not important to
try to match the input bias between the
two inputs. Therefore, I didn’t feel com-
pelled to make the input resistance on
the inverting input match the resist-
ance on the noninverting input.
The AC gain is adjustable from
approximately 1:1 to 1:10. This allowed
me to calibrate the milliohmmeter
without having to worry about the tol-
a signal that is synchronized with the
desired incoming signal. Last October,
Ed Nisley discussed a communications
application of a synchronous rectifier
similar to the synchronous demodulator
described here (“Modulation and
Demodulation,” Circuit Cellar 159). The
terms “synchronous rectifier,” “synchro-
nous modulator,” and “synchronous
demodulator” tend to be used inter-
changeably to describe this type of cir-
cuit and its operation, with the usage
seeming to depend on where and how
the circuit is used.
I used an inverting amplifier and
two sections of a CD4066 quad-bilat-
eral switch to make the synchronous
demodulator. Instead, you could use
the 74HC4066. The block diagram of
the demodulator is shown in Figure 5.
When the incoming waveform is posi-
tive, the incoming signal itself is con-
nected to the circuit’s output. When
the input signal swings negative, the
Figure 3
—
Grounding is important for keeping offsets below the allotted maximum. Be sure to keep power supply currents from returning through the small signal grounds. If
the RS-232 input is not connected to a serial output, the 1N916 and 1-µf capacitor may be omitted and the lower end of the 4.7-k
Ω
resistor grounded.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
53
inverted version of the input signal,
which is positive, is connected to the
circuit’s output, so the output signal is
always positive. The output of the cir-
cuit drives an op-amp integrator.
INTEGRATE AND MEASURE
The integrator shown in Figure 6 is
at the heart of the milliohmmeter’s
operation. It is used to integrate the
signal from the detector to provide
gain, while reducing noise, and meas-
ure the level of the signal. The signal
from the demodulator causes the
charge in the 0.047-µf integration
capacitor to build up, driving the out-
put toward ground from its 1.8-V refer-
ence. After the nine hundred ninety-
ninth cycle of the 1-kHz test burst, the
synchronous demodulator is turned off
by stopping the switching pulses.
To read out the total charge in the
integrator, the FET switch U3C is
turned on to discharge the integrator
capacitor with a constant current of
240 µA (1.8 V/7.5k = 240 µA), produc-
ing a linear positive-going ramp at
5100 V per second (240 µA/0.047 µf =
5100 V per second) on the output of
the op-amp.
While the output of the op-amp is
ramping back toward the 1.8-V reference,
the AT90S2313 micro sits in a loop incre-
menting a counter every 1.25 µs until the
comparator changes state, indicating that
the ramp has reached the 1.8-V refer-
ence. The A/D conversion sensitivity is
6.375 mV per count (1.25 µs per count ×
5100 V per second).
The gain of the integrator is equal
to 212.5 V out per volt in, or 46 db,
which is derived in the following way:
The conversion factor for the entire
process, which includes both integra-
tion and measurement, is 30 mV
P
per
count, which is derived from:
Because the signal is AC-coupled and
peak-to-peak equals two times peak, the
sensitivity is 60 µV
PP
input per count.
The input amplifier sees 23 µV
PP
per
count on its input (23 mA × 1 m
Ω
), so
6 375
212 5
.
.
mV per count
212 5
0 999
100 000
0 047
.
.
,
.
=
peak input voltage
f
s
×
µ
the input amplifier needs a gain of
about 2.6:1 (60 µV/23 µV). However,
because the low-frequency roll-off in
the high-pass filtering results in wave-
form distortion, the input amplifier
needs a gain of about 4:1. Hence the
preamp’s adjustable gain of 1:1 to 1:10.
When the integrator finishes ramp-
ing back to the 1.8-V reference, FET
switch U3C is turned off and FET
switch U3D is switched on to short
the integrator capacitor and clamp the
op-amp’s output to the 1.8-V refer-
ence. If, for some reason, the circuit
were to find itself with the op-amp
output more positive than the 1.8-V
reference at the end of the integration
period, the circuit would latch up.
This reset pulse ensures that the cir-
cuit would not be in that state for
more than one cycle.
MILLIOHMS TO DIGITS
All of the timing is performed with
an AT90S2313 microcontroller run-
ning at 4 MHz. The presence of an
analog comparator on the chip and
fast program execution with low cur-
rent requirements make this AVR (and
similar ones) ideal for this project. The
on-chip UART, baud rate generator,
interrupt timer, and EEPROM were
also nice to have. I could have used a
PIC, but I was already familiar with
AVRs, which, as I just explained, are
well suited to this application.
The 1-kHz burst is generated by a
4-kHz interrupt that causes a 4-bit
waveform image to be shifted out to the
output pins a quarter cycle at a time. I
reused code designed to produce quadra-
ture signals for an earlier project. The
firmware counts 999 cycles of the 1-kHz
square waves to make a 999-ms burst. It
counts 999 1-kHz cycles per burst for
the integration period, and then allo-
cates 250 µs for the measurement, using
a timing loop that’s 1.25 µs long. The
firmware allows a maximum of
190 counts (237.5 µs) so the measuring
routine will fit within a 250-µs inter-
rupt. After the measurement, it applies
the clamp pulse for 750 µs before start-
ing the next measurement cycles.
The firmware keeps track of odd and
even measurement cycles. On odd meas-
urement cycles, the test burst is not sent
to the PNP transistor, although the
demodulator operates and the integra-
tion and measurements take place. The
measured value during the measurement
cycle without the test burst is an
extremely low count; it is stored to be
used as the measurement offset value.
On even measurement cycles, the
burst is sent to the PNP transistor to put
5 V
PP
across the 220-
Ω
resistor and the
resistance being tested, while the result-
ing IR drop is integrated and measured.
The measured offset value is subtracted
from the measured resistance, and then
the value obtained with the input short-
ed is subtracted. The result is converted
from binary to ASCII digits and sent via
the on-chip UART to be displayed.
Figure 4
—
The signal from the resistor under test is
AC-coupled to an amplifier biased to the 1.8-V refer-
ence supply.
Figure 5
—
The switching signal is synchronized with the incoming signal, which results in the full-wave rectification
of the incoming signal. Signals that are not at the switching frequency or odd harmonics are not rectified.
54
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
Because the maximum A/D count is
190 m
Ω
, the A/D dynamic range has
to be shared by the zero input value,
the A/D zero value, and the resistance
being tested. The A/D is adjusted with
the 50-k
Ω
offset potentiometer in the
integrator circuit. I set it to about
10 counts so it can drift either way
and not cause clipping of the measured
signal. This is the offset that is auto-
matically measured and removed in
every pair of measurement cycles, so
the drift of this parameter will not
affect the displayed resistance unless
the offset goes below 0
Ω
or causes the
measurement to exceed the A/D con-
verter’s maximum count of 190.
The input zero value is the measure-
ment taken by the A/D converter with
the measurement leads connected to a
low-value resistor and the input zero
button pressed. This value is stored in
the on-chip EEPROM so it is retained
when power is removed.
The output data display is composed
of two lines that can be displayed on
an RS-232 ASCII terminal or, as in my
case, on a 2 × 16 character LCD with
RS-232 input:
mOhms Offset
101 8 [13]
The top line shows the labels for
measured milliohms and the offsets.
The lower line displays the resistance
reading in milliohms, the A/D con-
verter offset count, which is con-
trolled by the offset potentiometer and
zeroed out one each pair of measure-
ment cycles, and
the input zero off-
set, in square brack-
ets, which is stored
in EEPROM. Note
that the offsets dis-
played to the right
are used to aid in
zeroing the meter.
Because it takes
two measurement
cycles to measure
the offset and the
resistance being
tested, and because
each measurement
takes 1 s, I added
an LED to indicate
when an actual measurement is taken.
The LED is particularly useful while
zeroeing the input. Hold the input-
shorting button, momentarily press
the Zero button, and wait for two full
cycles of the LED before releasing the
input-shorting button.
I set this up so that the serial LCD
gets its power and data from a single
connector on the milliohmmeter
board. The entire thing runs on a sin-
gle 9-V battery. Most of the time, it
can sit on the shelf, and it’s a snap to
move to the bench and use whenever I
need it. It’s surprising how often I’ve
used this little meter.
THE WONDER CONTINUES
The lock-in amplifier described as
part of this millihommeter has wider
applicability. I have experimented
with the circuit in conjunction with a
simple 54-dB preamp (a gain of 500),
which is also based on the LM324, to
raise the sensitivity for stable readings
to 160 nV
PP
per count. (If you are
familiar with the LM324, this last
statement alone is enough for you to
fully appreciate the lock-in amplifier!)
I have used it to pull 1-kHz VLF elec-
tric field signals out of the noise, to
detect 1-kHz signals buried in the
noisy output of a TRF VHF AM detec-
tor, and to look at the output of a pho-
totransistor sensing radiation from a
laser pointer modulated at 1 kHz and
bounced off a nearby building. All of
these experiments hinted tantalizingly
at some of the amazing possible appli-
cations for lock-in amplification.
I
Figure 6
—
The amplitude of the signal from the demodulator determines the
slope, charging the integrator toward ground from the 1.8-V reference. The slope
of the discharge back up to the 1.8-V reference is constant.
Dick Cappels enjoys tinkering with
and writing about analog circuits and
microcontrollers. He has published
several papers relating to electronic
displays in computer systems, and is
currently active in the Society for
Information Display. Dick holds 17
U.S. patents in areas including dis-
play technology, color management,
and capacitive proximity sensing. You
may reach him at projects@cappels.org.
PROJECT FILES
To download the code, go to ftp.cir-
cuitcellar.com/pub/Circuit_Cellar/
2004/162.
RESOURCES
Atmel Corp., “8-bit AVR
Microcontroller with 2K Bytes of
In-System Programmable Flash:
AT90S2313,” 0839I, 2002.
AMETEK, Inc., “What is a Lock-in
Amplifier?” TN1000, www.signal
recovery.com.
National Semiconductor Corp.,
“LM124/LM224/LM324/LM2902
Low Power Quad Operational
Amplifiers,” SA009299, 2000.
Texas Instruments, Inc.,
“CD54HC4066, CD74HC4066,
CD74HCT4066 High Speed CMOS
Logic Quad Bilateral Switch,”
MTSS001C, 2003.
SOURCES
AT90S2313 Microcontroller
Atmel Corp.
(408) 441-0311
www.atmel.com
LM324 Op-amp
National Semiconductor Corp.
(800) 272-9959
www.national.com
CD74HC4066 Switch
Texas Instruments, Inc.
(800) 336-5236
www.ti.com
56
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
I
n years gone by, the venerable curve
tracer was one of the most prized labo-
ratory instruments. With it, you could
easily plot device behavior (current
versus voltage) from which you could
empirically derive useful circuit mod-
els. Plots of the I-V characteristics of
diodes, transistors, and other devices
help you understand their nonlinear
operation. From these plots, you can
determine bias points, load lines, and
the limitations of the devices. But,
alas, many of you have not seen these
plots first hand; you have seen them
only in manufacturers’ databooks.
And, indeed, the I-V curves of many
devices may not be documented at all
or only in a generic sense.
In this article, I attempt to remedy
the situation by describing an econom-
ical way of obtaining the I-V curves of
two- and three-terminal devices using
a PC and a Windows-compatible
sound card. As far as I know, this is a
new method that has not been accom-
plished before. My research shows
that using a computer for curve trac-
With an elegant solution to the cou-
pling problem in hand, it’s obvious that
a curve-tracing project can be imple-
mented using almost any PC because
you don’t have to modify it. You can
use a newer 2-GHz PC or dust off that
old 100-MHz PC sitting on the shelf.
You don’t have to open the cabinet of
the PC because access to the sound card
line input jack is all that’s required, and
this is usually accomplished from a
panel on the rear of the computer. Of
course, I cannot guarantee that this
project will work with your system.
However, I will say that I have tested
it with a 200-MHz Pentium Pro, a
500-MHz Pentium III, and a 1.1-GHz
AMD Athlon processor running
Windows 98 with Sound Blaster Live!
and the SB AWE32 sound cards.
So, if you have a Pentium or AMD
PC with a Windows-compatible sound
card, you probably have the basis for a
good Windows-driven curve tracer. All
you need to do is build the simple cir-
cuit described in this article, connect
it to your computer sound card, and
run the program.
My curve tracer allows you to accu-
rately plot the current-versus-voltage
characteristics of two- and three-termi-
nal devices such as resistors, diodes,
Zener diodes, LEDs, transistors, and an
exotic device that I’ll describe later.
Data is captured via the sound card
stereo input, processed, and plotted on
the screen. The circuitry is inexpensive
ing has been done before; however, in
the two cases that I’m aware of, the
parallel port and extremely special-
ized circuitry were required.
No one has used the sound card
inputs of the PC for curve tracing.
There is a good reason for this. All
sound card inputs are AC-coupled,
which means that there is a blocking
capacitor in series with each input.
The capacitor has the effect of remov-
ing the DC component of the signal.
When tracing a nonlinear device like
a diode, there is a significant DC com-
ponent. For accurate curve tracing, the
DC component must not be filtered
out. My friends have remarked that the
PC sound card is great for audio but
inadequate for the data acquisition of
signals with a DC component because
of the capacitor coupling. This is unfor-
tunate because the PC sound card has a
nice pair of 16-bit A/D converters with
relatively good accuracy.
The more I had thought about it,
the more I became convinced that
there must be a way around this prob-
lem. I suppose you could open
the PC case, remove the
sound card, and bypass the
coupling capacitors with
resistors, but what an inele-
gant solution! It turns out
that there is a better way that
doesn’t involve modifying the
sound card, but I’m getting
ahead of the story (smile).
Tracing Current and Voltage
FEATURE ARTICLE
by George Steber
George has come up with a new method for obtaining the I-V curves of two- and three-ter-
minal devices. Following his lead, you’ll be able to plot the I-V characteristics of diodes and
transistors. If you have a PC and a Windows-compatible sound card, you’re well on your way
to being able to trace current and voltage from your workbench.
120 VAC
R1
R2
I(t) DUT
Vertical (y)
V(t)
Horizontal (x)
I(y)
V(x)
Figure 1—
Use this simple curve tracer circuit with a DC-coupled
oscilloscope.
Design a Unique PC Sound Card Curve Tracer
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
57
shown in Figure 2a. The step
response is depicted to the
right of the circuit.
The signal rises instantly to
the value of the step, and then
decays exponentially to zero.
If you apply a step input to
your sound card input, record
it, and view it, that’s what
you will see. The voltage
transfer function of this cir-
cuit, using the Laplace vari-
able s, is given by:
[1]
Now consider the addition
of another transfer function,
G
2
(s)
, in cascade with G
1
(s)
as shown
in Figure 2b. If you could make G
2
(s)
equal to 1/G
1
(s), the overall transfer
function would be unity and you would
see a flat step response at point V
3
.
Note that in Equation 1, there is a zero
at the origin. Thus, G
2
(s)
would have a
pole at the origin making it marginally
stable. However, if you limit time to a
short interval, the potential instability
can be managed well.
You don’t want to open the PC and
add the circuit for G
2
(s)
to the sound
card, so what can you do? The best
approach is to use a discrete time digi-
tal filter in software that recursively
solves a difference equation given the
initial conditions and input data
sequence from the ADC. In effect, you
must use a sampled version of G
2
(s)
,
which I’m calling “G
2
(z).”
How can you design a digital filter
that satisfies the specifications of the
analog filter G
2
(s)
? Mathematically,
you use the following bilinear
transformation:
[2]
where T is the sampling period, and
z
is the z transformation of s. In
this particular case, the resulting
G
2
(z)
is given by the following
equation:
[3]
To prevent aliasing, you must
limit the input frequencies to less
than one-half of the sampling fre-
G z
T
R C
V z
V z
2
1
1
1
1
3
2
2
1
1
( )
( )
( )
= 1 +
+ z
z
=
×
−
−
−
s
T
=
z
+ z
2
1
1
1
1
×
−
−
−
G s
R C s
R C s
V
V
1
1
1
1
1
2
1
( ) =
+ 1
=
(less than $2) and uses readily
available parts. You can build
up the circuit on a solderless
breadboard, like I did, or design
a PCB. In any case, you will
need a digital voltmeter (DVM)
for calibration purposes.
CURVE TRACING 101
Operating a curve tracer is
simple in principle. You need to
apply a varying voltage to the
device under test (DUT) and
plot its current versus voltage.
In the old days, often times
you would put together a curve
tracer by using an AC voltage
source, a transformer, a few
resistors, and an oscilloscope. Figure 1
shows a simple curve tracer circuit.
The transformer provides isolation
and voltage reduction from the AC
source, usually 120 VAC 60 Hz.
Resistor R1 limits current, and R2 is
used as a current measuring element.
The oscilloscope is used in DC-cou-
pled y-x mode. The oscilloscope x-
input measures the DUT voltage, and
the oscilloscope y-input measures the
voltage across R2, which is proportion-
al to current. For instance, if R2 equals
100
Ω
and there is 1 V across it, you
can deduce that there is 10 mA in the
DUT. Or, you might say that you have
a sensitivity of 10 mA per 1 V for this
channel. Notice that because the
ground point for the oscilloscope is at
the connection of R2 and the DUT,
the current signal measured by R2 will
be inverted. This usually can be cor-
rected at the oscilloscope by reversing
the polarity of the channel.
For measuring low-voltage parts
like diodes and Zener diodes, a
120- to 12-VAC step-down trans-
former is typically used. Resistor
R1 is around 500
Ω
. You can use
other combinations as long as you
realize the implications of higher
voltages on your components and
the power dissipation of the resis-
tors. Assuming the DUT is a direct
short is a good way of estimating
the maximum power lost in these
parts. If you wish to curve trace at
a frequency other than 60 Hz, an
audio generator driving an audio
transformer may be used.
Although the aforementioned curve-
tracing approach is straightforward,
there are some things to consider. You
need access to an oscilloscope and
must know how to use it. Another
consideration is that of saving and
printing the curves. A digital oscillo-
scope makes life a bit easier.
I use this curve-tracing setup with
my Tektronix TDS 360 digital real-
time oscilloscope. It allows me to cap-
ture traces that I can then transfer to
my PC for observation and compari-
son. Thus, I am able to verify the
veracity of the sound card method
described in this article.
SOUND CARD COMPENSATION
Sound card inputs are AC-coupled by
means of large capacitors. This allows
the frequency response to go down to
low frequencies, typically 20 Hz. A
generic model of one channel is
R1
Buffer
V2 G
2
(s)
V3
R1
Buffer
C1
C1
V1
V1
V2
V3(t)
V2(t)
Time
Time
Figure 2a—
This is a typical sound card input and its step volt-
age response.
b—
I added a hypothetical compensation circuit
and corrected step response.
a)
b)
Photo 1—
In this instance, the main window of the Windows curve tracer pro-
gram shows the user controls as well as two captured traces in the Y Versus T
mode of a 3.3-V Zener diode.
58
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
quency. Implementing the digital filter
given by Equation 3 on the sound card
data will correct it and compensate for
the effect of the coupling capacitor.
One slight problem remains: you don’t
know the values of R
1
and C
1
. This is
not much of a problem because you
can empirically determine their effect
on the filter. If you apply a step input
to the sound card, the resulting output
can be observed on the screen. Then
you can adjust the parameters of the
filter until you get a flat response.
Knowing the exact value of the step
amplitude, as measured with your
DVM, also allows you to accurately
calibrate the sound card.
NEW CURVE-TRACING CIRCUIT
The simple curve-tracing circuit men-
tioned earlier is not appropriate for this
approach, because it doesn’t provide a
step output for calibration, and it cannot
start and stop on command. Figure 3
shows the unique circuit designed for
this project. It is easy to
assemble on a solderless
breadboard.
As you can see, there are
CD4066 CMOS switches
scattered about. They are
there to provide the pre-
dictable and repeatable
starting of the oscillator and
step generator. Circuit oper-
ation is initiated by opening
SW1. This causes all of the
CMOS switches to open.
U1A and U1B together with
a few components comprise
a triangle wave generator.
Resistor R4 is adjusted to
get a frequency of approximately 215
Hz. This can be verified with the soft-
ware, which has frequency
measuring cursors. U2A and
U2B form a power buffer for
the triangle wave. After a
few cycles are captured,
SW1 closes.
U3A is a simple step
generator that provides a
step at about one-half the
supply voltage when SW1
opens. Jumper block J1 is
used to select the step or
triangle wave. A current-
measuring resistor, R
M
, is
typically 100
Ω
and con-
nected in series with the
DUT. You can change this
to suit your requirements.
R13 and R14 form an attenuator to
reduce the voltage to something the
sound card line input can accept with-
out overloading, typically approxi-
mately 1 V. The voltage across the
DUT is buffered, similarly
attenuated, and fed to the
left channel. The current
through the DUT is the dif-
ference between the right-
and left-channel voltages
divided by R
M
. This value is
calculated in the software.
I used bipolar power sup-
ply voltages ranging from
±
9
to
±
12 V. The limiting factor
is the CD4066 breakdown
voltage. I also noticed that
the triangle wave had a slight
asymmetry, approximately
0.74 V, which was probably
because of the unsymmetrical output of
the LM324. This doesn’t affect operation
but can be compensated for by increas-
ing the negative supply voltage by that
amount or alternatively putting a silicon
diode in the negative supply rail.
The circuit is potentially harmful to
some devices because it sweeps through
both positive and negative voltages. To
restrict the voltage sweep to only posi-
tive or negative excursions, a diode can
be placed across the DUT.
The circuit can be easily modified
to handle higher voltages and cur-
rents. It is only a starting point. Like
professors often say, I’ll leave that as
an exercise for the reader. As it stands,
a great number of devices can be
curve-traced with this circuit.
CURVE TRACER PROGRAM
A major bump in the road occurred
when I discovered that drivers for
sound cards are not available for QBA-
SIC, the language I had wanted to use.
After some casting about, I decided to
try Visual Basic and make the soft-
ware run in Windows.
As a side note, I have been around
computers since the early days of the
LPG-30 magnetic drum computer, IBM
1620, and DEC PDP-8. I even designed
one using ancient 2N28 transistors
(grin). So, programming in FORTRAN,
BASIC, machine language, and C was
part of my learning process. Naturally,
I thought writing a program in Visual
Basic would be a walk in the park. Not!
After going through much wheel spin-
ning trying to figure out how to cap-
ture data with the sound card, I finally
Photo 4—
As you study the 1-V trace of a lambda diode, note region
of negative resistance on the right side.
Photo 3—
The 1-V trace of 2N3904 transistor shows saved traces for
two values of base current. Note the area of negative resistance on the
left side.
Photo 2—
Yes, this is a display of the Zener diode in Photo 1, but here
it is in Y Versus X mode. The cursor reads out data in the small window
below the plot screen.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
59
had some success. A major benefit is
that the software is now written for a
generic Windows sound card.
After the data is captured, process-
ing and displaying it on the screen is
straightforward. But not content to
leave it there, I have provided a few
niceties such as cursors for y-x and y-t
measurement, reference memories for
saving and comparing data, scaling
controls, printer output, screen cap-
ture, and file saving for use by Excel
or other programs.
Photo 1 shows a screen shot of the
main window. The display shows both
left- and right-channel traces in the
Dual mode (y versus t) of a 1N4728B
3.3-V Zener diode. Photo 2 illustrates
the same data displayed in Y Versus X
mode. This is basically an I-versus-V
plot of the device, where “I” is the ver-
tical axis and “V” is the horizontal axis.
The program controls are self-
explanatory. There is a detailed help
file if necessary. Screen displays of
600 × 800 (SVGA) or more are recom-
mended, although it will display on a
VGA screen, albeit with cursors. I
have run the program only in
Windows 98SE, but, theoretically, it
should run in Windows 95 and XP.
Again, there are no guarantees because
this is my first VB program.
SYSTEM CALIBRATION
First, you need to set the mixer line
input control for your sound card.
Mixer software for the sound card is
already installed on your system if
you have a card. The mixer has a Play
and Record section. Adjust the line
input control to maximum in both the
Play and Record sections and set the
stereo Balance sliders to the center
position. If your mixer has a record
gain option, set it to a gain of one. If
these setting are changed between
uses of the tracer program, they will
need to be reset.
The calibration of the system needs
to be performed only once, because
the parameters are saved in a file
(CTinit) as you exit. (You may down-
load CTinit as part of the program
from the Circuit Cellar ftp site.) If
done correctly, good accuracy can be
achieved. What follows is a general
overview of how it is done.
First, remove the DUT. Next, set
the jumper J1 on the circuit so that
the step voltage is applied to R
M
. Run
the program, click Start, and wait for
the “TrgRdy” indicator to turn red.
Next, apply the step voltage by opening
switch SW1 on the circuit. After the
capture of the step voltage data, the
“TrgRdy” indicator will revert to green.
Measure the step voltage at J1 with a
good voltmeter, preferably a digital one,
and write it down. View the data cap-
tured by the program using the left cur-
sor in Dual mode. You should see a
large step voltage on L channel (green)
and small voltage on R channel (blue).
The data should start out clean with-
out much noise. If there is a lot of
noise at the start of capture (probably
because of SW1 bounce), close SW1 and
repeat the capture until clean.
The captured data is used to cali-
brate the program. Click the Calibrate
button to begin. Change the values
shown in the Calibrate box as needed.
This may be repeated until the best
60
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
calibration is achieved. All calibration
is done on the originally captured step
voltage. It does not need to be recap-
tured each time.
The volts-per-bit calibration is done
on the L channel of the sound card.
Activate the cursors and measure the
voltage of the L channel. Adjust this
value until the cursor value is close to
the value you measured with the volt-
meter earlier. Adjust the channel bal-
ance value until the R channel is
close to zero. Adjust the compensa-
tion value until there is no droop or
rise of the step voltage of the L chan-
nel. It should be a straight horizontal
line across the window of the oscillo-
scope. Make corrections in extremely
small amounts.
Each time you close the Calibration
box, these values are applied to the
captured data. You will immediately
see the results on the screen. Use the
left cursor to measure the data on the
L and R channels as needed. Repeat
the procedure until the best calibra-
tion is achieved.
MORE CALIBRATION VALUES
Trigger Level controls the trigger
level at which the input signal is cap-
tured. If you get false captures, you
can increase this value. If the value is
too high, you will miss the leading
edge of the captured waveform. If it is
too low, you will get false triggers due
to noise.
Some sound cards invert the signal.
The SB Live! inverts the data, so the
Invert Input box needs to be checked
to correct the input polarity. The SB
AWE32 does not invert the signal, so
uncheck the box. To determine if your
sound card inverts the data, look at
the step waveform of the L channel; it
should start out positive for a positive
input such as provided by the hard-
ware circuit. If not, you need to check
the box to invert the data.
For R
M
, enter the value of the cur-
rent-measuring resistor in ohms. The
R channel cursor will calculate and
display current based on this value
using Ohm’s law.
The following are values used with
my SB Live! Card: the channel balance
is 0.9531; the compensation is 10; the
volts per bit are 0.00032172; the trig-
ger level is 200; R
M
is 98.8; and the
Invert box is checked.
MAKING TRACES
It is easy to curve-trace a compo-
nent, assuming that the hardware cir-
cuit is connected to the sound card
and the DUT is connected to the cir-
cuit. It is further assumed that the
software is running and the circuit is
calibrated. To capture data from the
DUT, follow these steps closely: Click
the Start button. The green “Trig
Rdy” LED will turn red, indicating the
trigger is ready. Initiate the capture by
opening the switch SW1 to generate
the DUT signals for the sound card.
After a short time, the “Trig Rdy”
LED will revert to green, indicating
that the data has been captured. Use
the controls to display the plot.
If the trigger does not occur for
some reason, you can use the Stop
button to manually reset the “Trig
Rdy” LED. Normally, this is not
required. You cannot exit the program
unless the “Trig Rdy” LED is green.
The sound card tracer is accurate,
but I have observed errors. For
instance, offset errors as high as 50 mV
have been measured. Although this is
small, it leaves room for improve-
N-Channel
MPF102
g
d+
s
+
s
d
g
P-Channel
2N4342
Figure 4—
You can connect two FETs to form a lambda
diode.
Figure 3—
Use the curve tracer circuit with the sound card. J1 selects either the step or triangle signal for testing. The R
CH
and L
CH
outputs connect directly to the sound card
line inputs.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
61
SOURCES
Sound Blaster Live!
Creative Technology
(800) 998-5227
www.creative.com
TDS 360 Digital real-time oscillo-
scope
Tektronix, Inc.
(800) 833-9200
www.tektronix.com
RESOURCES
C. Grantham, “Trace Voltage-
Current Curves on Your PC,” EDN
Magazine
, October 2001.
Maxim Integrated Products, Inc.,
“PC Printer Port Controls I-V
Curve Tracer,” 253, July 2001.
PROJECT FILES
To download the code, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2004/162.
George R. Steber, Ph.D., is emeritus
professor of Electrical Engineering and
Computer Science at the University of
Wisconsin, Milwaukee. He has con-
siderable industrial experience as a
corporate officer, consultant, and
product designer, and has been issued
more than a dozen patents. In his
spare time, George enjoys reading,
playing his Bach trumpet, editing old
videos, and astronomy. You may
reach him at steber@execpc.com
Write “Curve Tracer” in the subject
line of your e-mail.
ment. Also, the sound card used
seems to have an effect. The SB Live!
is less noisy than the SB AWE32.
FINAL TRACES
Curve-tracing various components is
interesting and instructive. Resistors, of
course, plot as straight lines. Choosing
a point on the line with the cursor and
using Ohm’s law can check their val-
ues. Capacitors provide unusual rectan-
gular plots, not circles, because the
driving voltage is triangular and charg-
ing is approximately linear.
Diodes, Zener diodes, and LEDs
show plots similar to Photo 2. The
collector curves of a 2N3904 transistor
are shown in Photo 3. You need to
provide a simple base current source
for transistors. To display more than
one curve, you can use the memory
buttons. Normally, you would not
trace the negative voltage region; but,
in this case, it is interesting to see the
negative resistance region of a reverse
biased transistor.
My final example is the I-V curve
for a strange device called a lambda
diode (see Photo 4). Notice the large
negative resistance region. Combining
back-to-back N-channel and P-chan-
nel FETs, as shown in Figure 4, makes
this device, which would be useful in
an oscillator circuit.
Analog signature analysis is an
interesting application for this proj-
ect, but I’ll leave that for another
time. Meanwhile, if you discover
other uses or enhancements for this
project, please let me know.
I
CMCs low cost converters adapt
any RS232 port for RS422 or RS485
operation. These converters provide
your RS232 device with all the
including reliable high speed operation
transmission distances up to 5000 feet.
Two AD422s can be used to extend
any RS232 link up to 5000 feet.
Completely transparent to the system;
no software changes of any type are
Adds multidrop capability to
Mention this ad when you order and deduct 5%
Use Visa, Mastercard or company purchase order
WWW.2CMC.COM Fax:(203)775-4595
PO BOX 186, Brookfield,CT 06804
The resulting file, test.S, contains the
human-readable assembly generated
from test.c.
You can also specify a number of
source files in addition to your target
image as follows:
gcc -o myimage test.c test2.c test3.c
This line compiles the three C source
files, and produces an executable
called
myimage.
Finally, you can also specify the
inclusion of a library just as you
would an object. The following exam-
ple illustrates the inclusion of the
test.lib:
gcc -o myimage test.c test2.c
test3.c test.lib
Later in this article, I’ll show you how
libraries are created.
OPTIMIZING WITH GCC
The
gcc compiler can help build
efficient applications using the opti-
mizer. Without optimization, the
compiler quickly produces debug-
gable code.
Four levels of optimization are pro-
vided by
gcc. The first level of opti-
mization,
-O1, enables some of the
simpler optimizations (e.g., avoiding
threaded jumps). The second level,
-O2, enables all other optimizations
that don’t involve a space-speed trade-
off. The final level,
-O3, enables all
other optimizations (including func-
tion inlining).
Another level that’s a subset of the
62
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
T
he GNU compiler toolchain is a
model of flexibility. The GNU compil-
er collection (GCC) supports three
dialects of C, C++, Objective C,
Fortran, Java, Pascal, and Ada95.
GCC can be hosted on more than
50 different types of hosts, and it can
generate code for more than 40 differ-
ent target architectures (from 1750a
to winnt). This is an amazing feat to
say the least.
Now, I’ll take you on a whirlwind
tour of the GNU tools and how they
can help you build application soft-
ware. Given the wide range of host
and target possibilities, I’ll focus on
building native applications for a
Linux target. In the end, I’ll explore
the use of GNU cross development
tools for an embedded target.
COMPILING WITH GCC
Let’s first look at how we can
compile C source into objects and
native images. The GNU C compil-
er is called
gcc. Although it
includes a large number of options,
I can describe some of the most
common features that you’ll
encounter.
In the simplest case, you can com-
pile a source file called test.c into an
object by typing:
gcc -c test.c
The
-c option tells the compiler to
perform only compilation. In other
words, do not link the object to cre-
ate an executable image. The result
of this operation is an object file
GNU Development
Flexibility in software design is essential in many situations. That’s why Tim likes working
with the GNU compiler toolchain. It gives him the freedom of choice. This month, he gives us
a guided tour of the GCC.
called test.o. If you don’t like the
name of the object, you can change
it using the
-o option:
gcc -c test.c -o test1.o
If you want to build an executable
image, simply type:
gcc test.c
which produces an a.out file (in
a.out format). The a.out format is
the oldest image format used in
Unix-style systems. It includes the
.text, .data, .bss, and symbol table.
This file can be executed directly on
a Linux host.
Although
gcc includes a large
number of options, I’ll illustrate a
few to provide some insight into its
capabilities. During compilation,
gcc can identify both errors and
warnings in the source code. A use-
ful option to identify the most com-
mon types of warnings that can
occur is the
-Wall option:
gcc -Wall test.c
This identifies such issues as unini-
tialized variables among others. Other
warning options can be specified, but
gcc requires these to be specified
implicitly.
If you’re interested in the assembly
that’s being generated, you can use the
-S option (combined here with -c, to
compile only):
gcc -c -S test.c
FEATURE ARTICLE
by M. Tim Jones
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
63
The
Makefile in Listing 1 is synony-
mous with simply typing the line:
gcc -Wall test.c -o test
However, the
Makefile has an inter-
esting advantage, even in this
extremely simple case. When you
perform
gcc from the command line,
gcc willfully creates the test applica-
tion by compiling the source file and
creating the image. Unfortunately, it
will do this every time, regardless of
whether or not the source file has
changed. The
Makefile will only cre-
ate (or recreate) the image if the
source file has changed.
Let’s now decompose the simple
Makefile in Listing 1 to understand
exactly what’s shown. The
Makefile
contains a single rule. A rule is made
up of three parts: a target, zero or
more prerequisites, and one or more
commands. The target, at line 5, is the
default target of the
Makefile (the
image name). Here, it’s simply called
“
test.” A single prerequisite is
defined at line 5, which is the source
file of the image (
test.c). The prereq-
uisite defines the dependency of the
image on the source. Finally, the com-
mand is defined at line 6, which
defines which action should take
place if the prerequisites have
changed. Note that line 6 starts with a
tab rather than eight spaces. Failure
to use a tab for command lines will
result in an error in the
Makefile.
To execute the
Makefile, you can
simply type
make in the subdirectory
where the
Makefile is stored. You
could also specify the target (
test), or
identify the
Makefile that you wish
to use with the
-f option. Each per-
forms the same action with varying
levels of control. The
make variants
include:
make
#Assumes Makefile
make test
#Explicit definition
of target
make -f Makefile #Explicit definition
of source Makefile
Now, let’s look at a slightly more
complicated example that illustrates
some of the other features of the
Makefile. Consider the Makefile
second level is called
-Os for optimize
size. This level includes the
-O2
optimizations, but it disables cer-
tain optimizations that tend to
increase the size of the resulting
code. The optimizer can be disabled
using
–O0. The compiler also
includes a number of architecture-
specific optimizations that can be
explicitly enabled.
BUILDING LIBRARIES
Sometimes, you’ll build software
services instead of end applications.
In these cases, it can be worthwhile
to build libraries that other applica-
tions can link in for their use. This
is especially important when the
library includes more than one
object.
A library is simply a collection of
objects. Given two C files, test1.c
and test2.c, you can create a library
for their objects using the following
commands:
gcc -c test1.c
gcc -c test2.c
ar -cru test.lib test1.o test2.o
The
ar, or archive, command pro-
vides the ability to create, modify, or
extract from archives. The
-c option
creates a new archive if it doesn’t yet
exist. The
-r option specifies that
you wish to insert the objects into
the archive with replacement. The
-u option specifies that the object
is updated in the archive only if it
is older than the object already in
the archive.
The
ar utility also can be used to
list the object files in the library as:
ar -t test.lib
The utility can also maintain
libraries. For example, if an object is
to be removed, the
-d option can be
used (with
v for verbosity):
ar -dv test.lib test1.o
The
-x option can be used to
extract an object from an archive. It
uses the following form:
ar -x test.lib test1.o
This command results in the test1.o
object being extracted (but not delet-
ed) from the library and created in the
current directory.
Large libraries can sometimes
reduce the speed at which applications
are built. To combat this problem, the
ranlib utility can be used. The ran-
lib utility creates an index within the
library that helps speed the linking
process when the library is used.
Usage of the
ranlib utility is provid-
ed as:
ranlib test.lib
This also can be performed using the
ar utility with the -s option:
ar -s test.lib
BUILD AUTOMATION WITH MAKE
The
make utility is a tool that on the
surface can automate the generation
of executables from source files.
However, its usefulness goes beyond
simply generating images.
The
make utility follows a user-
defined set of rules to arrive at a spe-
cific goal. Therefore, it can be used for
tasks such as system configuration or
even program installation. Let’s look
at a simple example, and then a slight-
ly more complex example, to see how
make provides for program construc-
tion. The
Makefile contains the rules
for the process. Listing 1 contains a
simple
Makefile that builds an image
from a single file.
Listing 1—
The simple
Makefile
builds an image from a single file. It has a single rule.
1: #
2: # Makefile
3: #
4:
5: test:
test.c
6: gcc -Wall test.c -o test
64
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
linking. The
-o option identifies the out-
put file, in this case
$@ representing the
target file
($(TARGET) or serv). Finally,
the automatic variable
$+ is specified,
which represents the list of prerequisites
with spaces between each. Note that
$+
represents the
$(OBJS) variable.
Two items have yet to be discussed
shown in Listing 2. Line 5 defines the
variable
OBJS. Variables in the Makefile
represent strings that are substituted
when encountered in the
Makefile
(such as line 10). The
OBJS variable
represents two object file names.
Lines 6 and 8 declare two additional
variables:
TARGET, which represents
the final target image name, and
CFLAGS, which represents the flags
that you’ll present to
gcc.
Line 10 declares your first target
(
serv, after applying the substitution).
Using the
$()—or ${}—allows the
variables to be referenced. Because the
serv target is dependent upon the
object files, the C source files must be
converted to objects before linking
may occur (at line 11). A rule is pro-
vided for this conversion at lines 16
through 17. The rule specifies that
.c
files be converted to
.o files using the
command at line 17. The
gcc compil-
er options are specified with the vari-
able
CFLAGS. The -c option specifies
compile only, and the special automat-
ic variable
$< (a replacement of the .c).
Returning to line 11,
gcc is used for
in this
Makefile, lines 13 through 14
and 19 through 20. The simple rules
defined at lines 13 through 14 represent
dependencies for the objects in include
files that they use. These rules, which
include no command section, specify
that if the prerequisites have a date
later than the target, then the target
must be recreated. This is useful in the
cases where a recompile should be per-
formed if a dependent file has changed
(an extremely useful operation).
Finally, lines 19 and 20 provide another
rule for clean-up purposes. The
clean
target is used to remove the working files
from the directory. When invoked, the
command specifies that the object files,
image target, and any core file that may
be present can be removed. Note the use
of a “
-” in front of rm. This specifies that
if no files were found for removal, the
error code returned by
rm will not cause
the
make processing to stop.
Three basic invocations are possible
with this
Makefile. They are provided as:
make serv #Build the serv target
make #Synonymous with make serv
make clean #Perform cleanup
DEBUGGING WITH GDB
The topic of GDB could fill volumes.
For brevity, I’ll give you an introductory
look at GDB and some of its basic com-
mands. GDB is the GNU source debugger
and provides a command line interface.
For this demonstration of GDB, I use
the C source file shown in Listing 3.
Listing 2—
This
Makefile
example is a bit more advanced. It has multiple rules and targets.
1: #
2: # Makefile
3: #
4:
5: OBJS = service.o common.c
6: TARGET = serv
7:
8: CFLAGS = -Wall
9:
10: $(TARGET): $(OBJS)
11: gcc -o $@ $+
12:
13: service.o: common.h
14: common.o: common.h
15:
16: .c.o:
17: gcc $(CFLAGS) -c $<
18:
19: clean:
20: -rm -rf $(OBJS) $(TARGET) core
Audio, Video, VGA, keyboard, mouse
(2) USB, (1) Serial, (1) Parallel ports
10/100 Ethernet port, (1) PCI Slot
Optional Sheet Metal Enclosure
Our new Thin Client system performs like a desktop PC equipped
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
65
In order to source debug with GDB,
the source must be compiled with the
-g flag. The -g flag produces debugging
information in the resulting image
that can be used by the debugger.
Additionally, optimization should be
disabled in this mode because it can
create inconsistencies between the
source and the target assembly, making
source debugging confusing. Therefore,
debug compile flags should be:
DBGFLAGS = -g -O0
The resulting image (e.g.,
serv) can be
debugged by typing:
# gdb serv
...
(gdb)
At the
gdb prompt, you can specify
the initial breakpoint (shown here as
the main function) and then start run-
ning the image (see Listing 4).
Now that you have control, you can
step through your program and
the contents of your variables:
(gdb) step
19
b = 7;
(gdb) print a
$1 = 5
(gdb)
Listing 3—
The C source file is for the
gdb
test image.
1: /* test file for gdb */
2: #include <stdio.h>
3: #include <assert.h>
4:
5: int myFunc( int a )
6: {
7: int d;
8:
9: d = a;
10: assert( 0 );
11: return( d );
12: }
13:
14: int main()
15: {
16: int a, b, c;
17:
18: a = 5;
19: b = 7;
20: c = a + b;
21:
22: myFunc( c );
23: printf( “%d\n”, c );
24:
25: return 0;
26: }
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
67
You can list your program (which
isn’t necessary in a graphical debugger
such as ddd or xdb) using the
list
command. An extremely useful
command to understand from whom
you were called is provided by the
backtrace command, which tells
you each function call along the way
that got us to the current source line.
Additionally, you can see the argu-
ments passed along the way (see
Listing 5).
This tells you that you’re currently
in
myFunc, having received the argu-
ment level with a value of 12. You
were called from the main function at
line 22. You can continue to
step
through the program, or set additional
breakpoints and use the
cont com-
mand to continue execution.
Another valuable use of GDB in the
native Linux environment is the
debugging of core dumps. Using the
GDB debugger can pinpoint the loca-
tion where the program aborted using
the following command:
[mtj@plato] gdb test core
where test is your image and core is
the core file resulting from a prior
execution of test. After GDB has
started, you can issue a
backtrace
command to see where the error
Listing 5—
Here, you can see how to set another breakpoint and resume execution.
(gdb) break myFunc
Breakpoint 2 at 0x8048416: file test.c, line 9.
(gdb) cont
Continuing.
Breakpoint 2, myFunc (a=12) at test.c:9
9
d = a;
(gdb) backtrace
#0 myFunc (level=12) at test.c:9
#1 0x8048411 in main () at test.c:22
Listing 4—
With this snippet, you can see how to set the breakpoint and start execution in GBD.
(gdb) break main
Breakpoint 1 at 0x8048b3d: file test.c, line 18.
(gdb) run
Starting program: /home/mtj/test
Breakpoint 1, main () at test.c:8
18
a = 5;
(gdb)
68
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
occurred (if it’s not apparent from the
initial GDB output). For an example,
see Listing 6.
Parsing through the output, you see
that
main (#5) called myFunc (#4),
which then called an
assert(), caus-
ing the abort. Although this has been a
quick introduction to source debugging
with GDB, the Resources section at the
end of this article provides additional
information to help you go further.
OTHER USEFUL UTILITIES
The GNU provides a number of use-
ful binutils that offer a variety of
capabilities. The
objcopy utility pro-
vides the ability to translate object
files from one format to another. For
example, you can translate an object
file (or image) from binary format into
s-record format, which is suitable for
downloading to embedded targets,
using the following command line:
objcopy O srec image image.srec
This converts the image file
image
into an s-record formatted file called
image.srec.
The
objdump utility provides a
number of useful features. It can pro-
duce the target architecture instruc-
tions for a given image using the fol-
lowing command line:
objdump --disassemble image
The result is the disassembly of the
image for each of the sections identified
in the executable. This also can be done
on an intermediate object file. You also
can output interspersed source code (if
available) with the disassembled assem-
bly by adding the
-S option:
objdump --disassemble -S image
You can explore the symbol table
for your image, using the
--syms
option, as:
objdump --syms image
The symbols also can be extracted
using the
nm utility. A similar usage
involving
nm is:
nm image
RESOURCES
Free Software Foundation
www.fsf.org
GNU Compiler collection
gcc.gnu.org
GNU Debugger
www.gnu.org/manual/gdb-5.1.1/
gdb.html
www.redhat.com
GNU Make
www.gnu.org/software/make/
manual/
Intel GNUPro Tools for XScale
www.intel.com/design/intelxscale/
dev_tools/020523/
M. Tim Jones is a software engineer
and the author of
TCP/IP Application
Layer Protocols for Embedded Systems
(Charles River Media, Hingham, MA,
2002) and
BSD Sockets Programming
from a Multilanguage Perspective
(Charles River Media, Hingham, MA,
2003). His engineering background
ranges from the development of ker-
nels for geostationary spacecraft to
embedded networking protocols and
firmware. Tim is currently a senior
principal engineer at Emulex. You
may reach him at mtj@mtjones.com.
The
size utility allows you to
understand the section sizes for an
object. In its simplest form—
size
image—it provides the text, data, bss,
and total size for the object (in both
decimal and hex formats).
EMBEDDED CONSIDERATIONS
Although the discussion thus far
has concentrated on native uses of
GNU tools, their use for embedded
systems is surprisingly similar. For
example, rather than using GCC to
compile sources to objects,
arm-elf-
gcc is used to build code for the arm
architecture in ELF. Other variants
exist, such as
xscale-elf-gcc for
the XScale architecture and
sh-elf-
gcc for Hitachi’s SuperH family.
Similarly, the other tools discussed
here have their own variants when
they refer to a specific architecture
family (e.g.,
arm-elf-objcopy and
sh-elf-objdump). (Do you see a
pattern?)
One of the most useful aspects of
GNU tools for embedded development
are the instruction set simulators.
Using the run utility, a cross-compiled
version of an image for the given
architecture can be simulated on the
host. This process is illustrated by:
xscale-elf-gcc -Wall test.c -o test
which results in the image
test in
XScale ELF format. This image can
run natively (simulated) using the run
variant for XScale, as:
xscale-elf-run test
With an image compiled for debug
(-g), you can start the xscale debug-
ger to debug in the simulator environ-
ment:
xscale-elf-gdb test
And finally, the size of the various
sections of the test image can be iden-
tified using:
xscale-elf-size test
You get the picture. The GNU tools
provide a varied and robust platform
for the development of both native
and cross-compiled applications. As
an embedded developer, you’re likely
to run across GNU tools at some
point in your career, so understanding
their capabilities is a valuable asset.
I
Listing 6—
Using back-trace in the core dump, you can identify the cause of the abort.
(gdb) backtrace
...
#3 0x400303ce in __assert_fail (assertion=0x80484ee “0”,
file=0x80484e7 “test.c”, line=10, function=80484e0 “myFunc”)at
assert.c:49
#4 0x8048432 in myFunc (a=12) at test.c:10
#5 0x804846d in main () at test.c:22
calls, faxes, and emails. The
the click of a button - without
e
waiting hours or even days for a
machinist to review your job.
Your total project time
is reduced up to 90%.
emachineshop
uses a revolutionary combination
of the internet, software, and
automated machines. Since the
The first true Internet machine
shop, eMachineShop gives you:
lDesktop convenience
lLow cost
lInstant pricing
lInstant expert feedback
lInstant ordering
Machine your parts by milling,
turning, punching, laser cutting,
extruding, bending, tapping,
thermo-forming, finishing, and
more.
Why waste time with shop visits,
Expert feedback - with the
intelligent software you'll know if
your design can be machined at
MachineShop intelligent
software tells you if your design
can be machined - at the click of
a button.
For more information, or to get
started, please go to
www.emachineshop.com and
discover cyber machining!
eMachineShop.com
666 Godwin Ave.
Midland Park, NJ 07432
Try eMachineShop today.
Try emachineshop once and
Low cost -
you'll never want to work any
other way.
software is so smart and
ordering is electronic, labor is
minimized whether you order
one part or one million. The cost
savings are passed on to you.
Instant pricing - get exact
pricing in seconds - no
cumbersome quotations
involved. And you can get as
many "what if" prices as you like.
the Internet Machine Shop Beta release
Click to
order
Download
FREE software
Design
your part
Now you can design and
order custom parts online!
Easy, convenient, new service
Electronic enclosures, front panels, robot parts,
electro-mechanical devices, special heat sinks,
optic holders, brackets, inventions, and more!
70
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
T
oday, when electricians wire a new
building, they have to contend with
much more than simply running AC
from the utility grid, through a distribu-
tion panel, and into each room. Often,
telecommunications equipment is dis-
tributed everywhere. Pre-wiring cable,
and even LAN distribution, is much easi-
er when a structure’s studs are exposed,
so they are finding their way into stan-
dard building design. There are great uni-
versal wall plates that are available with
between one and six holes through which
a variety of connectors can be inter-
changed. You can have multiple telco,
RG-45, and coax connectors in the same
low-voltage utility box. (AC should not
be included in the same junction box.)
The code in my area calls for AC out-
lets located no more than 6’ apart
around the perimeter of a room. I added
a second box for low-voltage stuff on the
opposite side of every stud that has an
AC box on it. A short section of plastic
wiring pipe leads from the low-voltage
box, through the floor, and into the cel-
lar, where I can easily run or remove
wiring as I change the room’s design.
My ISP is the local phone company,
which delivers the Internet through my
office computer. Currently, I use a wired
LAN for computer-to-computer connec-
tions throughout my house. In addition
to file and printer sharing, this provides
Internet access through the LAN.
Everyone seems to be talking about
Internet-enabling every possible embed-
ded product. Although the need for
embedded Internet might be a stretch for
than an RJ-45 footprint; its XPort embed-
ded device server is the most compact
serial-to-RJ-45 interface I’ve ever seen.
XPort
Integrated in an RJ-45 connector are
a 10/100 Ethernet transceiver, a
Global XPortation
FROM THE BENCH by Jeff
Bachiochi
some products, it makes sense for many
others. There are numerous ways to
accomplish this, but most require adding
a good deal of software and hardware,
which takes up valuable real estate.
Fortunately, Lantronix has found a way
to squash all of this into slightly more
With Lantronix’s XPort embedded device server, you can Internet-enable embedded prod-
ucts without wasting too much time, money, and design space. This month, Jeff shows you
how he used the XPort to allow a Java-enabled browser to communicate with a thermostat.
Offsite temperature control just got a whole lot easier.
Harness the Power of the ’Net with the XPort Server
Configur
ab
le pin 1
Configur
ab
le pin 2
Configur
ab
le pin 3
DSTni-LX
Serial data out
Serial data in
10-Mb Status LED
100-Mb Status LED
2.5-VDC
Regulator
Voltage
supervisory circuit
Power filters
External reset
3.3-VDC Power
Isolation
and filtering
magnetics
512-KB
Flash memory
Chassis
(earth) ground
48-MHz
Clock
25-MHz
Clock
Signal ground
OEM Specific
Device server application
SNMP, DHCP SMTP, Rijndael Web server, TFTP, telnet
TCP, UDP
IP, ICMP
Ethernet
Operating system
Drivers
RJ-45 Wiper
contacts
Ethernet
transmit and receive
Figure 1—
The DSTni-LX 186 controller and flash memory make up the heart of the XPort, which is the most com-
pact Internet connectivity solution available.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
71
can be used locally through the serial
port, the XPort is also remotely config-
urable by means of telnet or a ’Net
browser. The flash memory-based
storage even allows for software
upgrades, so the XPort can stay on
the cutting edge. For projects
that require high security, you
can get XPort with data encryp-
tion using a 128-bit standards-
based (AES) algorithm.
Packing all of this into a shield-
ed (extended) RJ-45 connector
allows the unit to meet class B
emissions levels, which frees you
from having to deal with high-
speed design issues. Note that
384 KB of the 512-KB flash memo-
ry are dedicated to web server
storage. This gives you plenty of
room for your web pages and Java
applets. To understand how the
conversion works, you must take
a look at a bit of network protocol.
ETHERNET PROTOCOL
Ethernet originated at Xerox in the
1970s. Xerox gave up its trademark
DSTni-LX 186 controller, memo-
ry, a high-speed serial port, diag-
nostic LEDs, and three program-
mable I/O pins (see Figure 1). The
XPort integrates a TCP/IP net-
work stack and operating system
to allow access to a local network
and the Internet. An embedded
web server can be used to remotely
configure, monitor, or trouble-
shoot an attached device. The
serial port is configurable between
300 bps and 230 kbps.
The XPort requires 3.3 V.
Therefore, any 5-V circuitry may
require level conversion inter-
faces even though the XPort has
5 V-tolerant I/O.
Think of the XPort as a conduit
to your serial device via a network
or the Internet. For simplicity, it
can serve Java applets to a Java-
enabled browser, giving you access any-
where without special software.
Although installation and setup tools
Preamble (7 bytes)
Start frame delimiter (1 bytes)
Destination address (6 bytes)
Source address (6 bytes)
Length or type (2 bytes)
Data (46 to 1500 bytes)
Frame check sequence (4 bytes)
Ethernet frame
Version (4 bits)
Internet header length (4 bits)
Type of service (8 bits)
Total length (16 bits)
Type of service
Identification (16 bits)
Flags (3 bits)
Protocol (8 bits)
Header checksum (16 bits)
Source address (32 bits)
Destination address (32 bits)
Options (optional, length varies)
Data (suggested maximum of
576 bytes including IP Header)
IP Datagram
Fragment offset (13 bits)
Time to live (8 bits)
Ethernet frame (data field)
Source port number (16 bits)
Destination port number (16 bits)
Sequence number (32 bits)
Acknowledgement number (32 bits)
Header length (4 bits)
Reserved (6 bits)
Control bits (6 bits)
Urgent pointer (16 bits)
Options (optional, length varies)
Data (suggested maximum of
576 bytes including IP Headers)
TCP Datagram
Window (16 bits)
Checksum (16 bits)
IP Datagram (data field)
Figure 2a—
The Ethernet frame is the outside wrapper for all network communications. Because each Ethernet device has a unique address number, Ethernet frames are
easily monitored for a destination address match.
b—
The Internet protocol datagram, which is a wrapper for Internet communications, travels in the data portion of the Ethernet
frame.
c—
One of the most popular data-transmission protocols is the transfer-control protocol. The TCP datagram travels in the data portion of the IP datagram. This combi-
nation is often referred to as TCP/IP communication.
a)
b)
c)
Photo 1—
The Lantronix installer application can search the network for
XPort devices, assign an IP to an XPort, ping the IP, update the parti-
tions, upgrade the firmware, and launch telnet and browser applications.
72
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
rights to Ethernet to create an open stan-
dard for computer networks working
with Digital Equipment and Intel. (“The
needs of the many outweigh the needs of
the one,” as Mr. Spock would say.)
Information is passed on a network
using an Ethernet frame, which is a
minimum of 72 bytes in length consist-
ing of seven fields. This minimum
frame size includes a minimum 46-byte
data field (even if only 1 byte of data
needs passing). In addition to other
fields, there is a 6-byte destination and
6-byte source address (see Figure 2a).
Each piece of Ethernet hardware has a
24-bit IEEE-issued manufacturer’s code
(OUI) followed by a unique 24-bit serial
number code issued by the manufacturer
(unique Ethernet address). This value is
often expressed as six dashed hexadeci-
mal bytes (xx-xx-xx-xx-xx-xx). If each
Ethernet device assumes it has a unique
48-bit address, then any Ethernet frame it
sees with a destination address match-
ing its own has found its home. The
Ethernet frame doesn’t care what’s in its
data field as long as the minimum num-
ber of bytes is 46 (maximum 1500 bytes).
Messages that travel on the Internet
must use Internet protocol
(IP). IP datagrams can be found
embedded in Ethernet frames.
Some common Ethernet proto-
cols are IP (0x0800), ARP
(0x0806), and RARP (0x8035).
On a local network, the
address resolution protocol
(ARP) and reverse ARP (RARP)
Ethernet frame can be used to
determine how Ethernet and
IP addresses are related.
INTERNET PROTOCOL
An IP datagram, which is
similar to an Ethernet frame,
UDP datagrams contain a header with
only four fields: source port number,
destination port number, UDP datagram
length, and UDP checksum (optional)
preceding the data. Data transported
with the UDP protocol is considered
unreliable because there is no hand-
shaking or flow control. This means
that the UDP format does not inherent-
ly acknowledge data or label it in a way
to assure that pieces can be reassembled
in the correct order. The TCP datagram
includes this as part of its protocol.
As you can see in Figure 2c, the TCP
header has 10 fields. Communication
requires the establishment of a con-
nection between two end points (ports
or sockets). There are three parts to a
TCP communication: requesting a
connection, sending data, and closing a
connection. Control bits act as hand-
shaking between the sending and
receiving endpoints to assure complete
communication. Using sequence and
acknowledgement numbers label file
fragments as to where each belongs
within the original file.
TEST BOARD
The XPort test board consists of an
XPort module interfaced with a level
shifter and DE9F as an Ethernet-to-seri-
al bridge (see Table 1). As you can see in
Photo 1, the XPort has three I/O bits.
They can be configured as handshak-
ing/flow control for the serial port or as
I/O that’s controlled via the Internet.
The XPort has numerous configura-
tions (see Figure 3). Out of the box, so to
speak, it is configured with an IP address
of “0.0.0.0.” You can change this by
using the serial port log-on procedure,
the network connection with
telnet, or the XPort Installer
program on the PC. If left
alone, it will accept an IP
from a dynamic host configu-
ration protocol (DHCP) serv-
er on your network or give
itself one of the IPs reserved
for AutoIP-enabled devices.
An AutoIP will also send an
Ethernet address resolution
protocol (ARP) frame to
make sure no one else is
using the selected IP.
The XPort uses the IP for
addressing, routing, and
is used to get data to a particular desti-
nation. The IP header is a minimum of
20 bytes and consists of 12 or 13 impor-
tant pieces of information, including
the source and destination IP addresses
(see Figure 2b).
These 32-bit IP addresses are familiar
in the format of dotted quad-decimal
bytes (xxx.xxx.xxx.xxx). The IP header
includes a protocol identifier byte.
Common IP protocols are transmission
control protocol (TCP, 0x06), user data-
gram protocol (UDP, 0x1), and simple
message protocol (SMP, 0x79). The
domain name system (DNS) is a resource
that allows domain names to be matched
to IP addresses. A DNS datagram and
HTTP web pages are examples of data
transmitted via an IP protocol.
TCP VERSUS UDP
These two datagram protocols are
responsible for much of the Internet traf-
fic. Although you speak of sending data
from one computer to another, the data
really begins in an application on the
sending computer and ends in another
application on the receiving computer.
Each application creates a socket or
logical port connection through the
physical interface. To reduce confu-
sion, some ports are used for specific
protocols like DNS, FTP, HTTP, and
POP3. The Internet assigned numbers
authority (IANA) maintains a port
number list of assigned ports and their
standard processes. An Ethernet
address identifies a specific piece of
interface hardware, and an IP address
identifies a specific computer. A UDP
or TCP port address identifies the
process used by the application.
Photo 2—
The test board comes as part of the devel-
opment kit. Notice how the XPort module (on the left
edge) is not much bigger than an RJ-45.
Photo 3—
The thermostat emulator is shown on the left. The browser window on the
right shows the remote thermostat. Controls operated at either end of the network link
affect the thermostat.
Enjoy Winning Strategies at
Media Sponsors
START >
START >
Technical
Conference
Professional
Development
Proceedings
CD-ROM
PC
B
Top Gun
Expert
Speak
ers
Official
Sho
w Guide
Opening Night
Reception
Keynote
Addresses
Two-Day
Exhibition
Netw
orking
Ev
ents
Dr
awings and Contests
PC
B
Test Driv
e
The Premier Conference and Exhibition
For Engineering, Design and Manufacture Professionals
Conference:
March 15-19, 2004
Exhibition:
March 16-17, 2004
San Jose Convention Center, San Jose, CA
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
75
data block handling over the network;
it supports ARP, UDP, TCP, ICMP, tel-
net, TFTP, AutoIP, DHCP, HTTP, and
SNMP. TCP assures that no data is lost
or duplicated and that everything sent
to the connection arrives correctly at
the target. UDP is typically used in
datagram applications, in which devices
interact with other devices without
maintaining a point-to-point connec-
tion. TCP, UDP, and telnet handle con-
nections to the serial port. TFTP is for
firmware and web page updates.
Network connections are through a
standard RJ-45 connector supporting
10/100BaseT half- and full-duplex
transmissions with autosensing. At the
opposite end, the serial port is user con-
figured for 300 bps to 230.4 kbps using
a 7/8-E/O/N-1/2 data format. It can
also be configured for hardware, soft-
ware, or no handshaking/flow control.
The XPort is extremely flexible.
Take a look at the user’s manual to
get a true picture of just how flexible.
Let’s review what is available.
Connect, Disconnect, and Flush
modes define how the unit makes and
breaks a connection, how it reacts to
incoming connections over the network,
and how the data in the I/O buffer is
handled. E-mail can be sent to multiple
recipients when a specific trigger event
occurs. There are three separate triggers
that are based on any combination of the
configurable pins (PIO) when selected as
user I/O functions. A 2-byte serial string
also can be used to initiate a trigger.
Expert settings allow you to adjust
telnet timeout defaults. Security set-
tings enable and disable various func-
tions, preventing access to and from
the XPort like disabling TFTP
firmware updates. The XPort is avail-
able with and without a 128-bit
Rijndael encryption algorithm. This
feature is also configured via the
security settings.
*** basic parameters
Hardware: Ethernet TPI
IP addr 0.0.0.0/DHCP/BOOTP/AutoP, no gateway set
DHCP device name : no set
***************** Security *****************
SNMP is enable
SNMP Community Name: public
Telnet setup is enabled
TFPT Download is enabled
Port 77Feh is enabled
Web server is enabled
ECHO is disabled
Encryption is disabled
Enchanced password is disabled
***************** Channel 1 *****************
Baudrate 9600, I/F Mode 4C, Flow 00
Port 10001
Remote IP Adr:--- none---, Port 00000
Connect Mode : C0 Disconn Mode: 00
**************** Expert *****************
TCP Keepalive : 45 s
ARP cache timeout : 600 s
***************** E-Mail *******************
Mail server: 0.0.0.0
Unit :
Domain :
Recipient 1:
Recipient 2:
*** Trigger 1/2/3
Serial sequence: 00,00
CP1: X
CP2: X
CP3: X
Message :
Priority: L
Min. notification interval: 1 s
Re-notification interval : 0 s
Flush Mode :00
Figure 3—
The XPort’s default values are configurable
via the serial port or the network by means of a telnet
or browser connection.
Signal name
XPort pin number
Primary function
GND
1
Circuit ground
VCC
2
3.3-V Power in
Reset
3
External reset in
Data out
4
Serial data out (connects to RX of attached DTE device)
Data in
5
Serial data in (connects to TX of attached DTE device)
CP1 (configurable pin 1)
6
Configurable pin 1 can be configured as:
• Flow control (connects to CTS of attached DTE device)
• Programmable digital input or output
• Status LED 1
CP2 (configurable pin 2)
7
Configurable pin 2 can be configured as:
• Modem control (connects to DCD of attached DTE device)
• Programmable digital input or output
CP3 (configurable pin 3)
8
Configurable pin 3 can be configured as:
• Flow control (connects to RTS of attached DTE device)
• Modem control (connects to DTR of attached DTE device)
• Programmable digital input or output
• Status LED 3
Table 1—
Interfacing to XPort is a cinch. Only eight connections are necessary. (That’s the same number as an
RJ-45 connector.)
76
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
thermostat to communicate as if they
were one embedded hardware device.
The XPort on the test board must be
programmed with the thermostat inter-
face web server. The web page includes
a Java applet capable of serving a canvas
containing thermostat graphics.
Stacked graphics are separately enabled
to display various function states.
These states come from serial commu-
nication requests with the thermostat.
The purpose of this application is
more than simply viewing the status of
each thermostat in an apartment build-
ing. A renter can adjust the tempera-
ture of the apartment so that it’s comfy
upon arrival. On the other hand, the
apartment manager can keep tabs on
empty apartments and allow realtors to
adjust the temperature prior to showing
an apartment to a potential renter.
The web server’s thermostat can be
controlled from a browser or application
as if you had pushed buttons on the
LANTRONIX DEMO
I used the XPort installer application
on my PC and located the XPort test
board on my network (see Photo 2). I
assigned a fixed IP of 192.168.0.200 to
the XPort.
Lantronix provides application code
for thermostat control in an apartment
complex. There are three pieces to this
application: the thermostat control
application (PC), the thermostat inter-
face web server (XPort), and the ther-
mostat (PC emulator). Ordinarily, the
thermostat would be a piece of hard-
ware with an embedded microcon-
troller allowing it to integrate the XPort
serial-to-network bridge. In this case,
a PC is used as the thermostat.
A VB application emulates the ther-
mostat. You can see the thermostat on
the PC screen and use a mouse to
press its control buttons. A serial port
on the PC interfaces to the XPort test
board, which allows the XPort and
Table 2—
This command set (2/3 ASCII characters) is passed between the application (Java applets running on the
browser) and the serial device (thermostat emulator).
Outgoing data from emulator Incoming data to emulator
Prefix Value
Details
Prefix
Value
Details
F
Fan
F
Fan
0
Auto
0
Auto
1
On
1
On
M
Mode
M
Mode
A
Auto
A
Auto
H
Heat
H
Heat
C
Cool
C
Cool
O
Off
O
Off
H
Heat set point
H
Heat set point
##
Temperature as an integer
##
Temperature as an integer
C
Cool set point
C
Cool set point
##
Temperature as an integer
##
Temperature as an integer
S
HVAC Status
S
HVAC State
I
Idle
0
Off
H
Heating
1
On
C
Cooling
O
Off
I
N
Returns to current emulator state
T
Current temperature
##
Temperature as integer
A
Set low temperature threshold
##
Temperature as an integer
E
E-mail trigger
0
Safe temperature
Z
Set high temperature threshold
1
High temperature
##
Temperature as an integer
2
Low temperature
N
E-mail triggers
0
Disable
1
Enable
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
77
Jeff Bachiochi (pronounced BAH-key-
AH-key) has been writing for
Circuit
Cellar since 1988. His background
includes product design and manu-
facturing. He may be reached at
jeff.bachiochi@circuitcellar.com.
RESOURCE
Lantronix, Inc., “XPort: User Manual
and Development Kit,” revision B,
2003.
SOURCE
XPort Embedded device server
Lantronix, Inc.
(949) 453-3990
www.lantronix.com
actual thermostat in the apartment. I
will skip showing you the thermostat
control application because I want to
simplify the demo. I will show you how
I used my browser as the user interface.
LOAD APPLICATION
In addition to its use as a configuration
tool, the XPort Installer also allows for
the updating of the operating firmware
and web pages. Web pages are stored in
one of six 64-KB partitions. Each page or
group of pages must be less than 64 KB.
Three partitions were used for this
application, two for the thermostat web
page and one for the configuration page.
These were already installed in my
XPort. The XPort installer can load
them if necessary.
RUN EMULATION
After connecting a serial cable
between the XPort test board and
your PC, start the thermostat emula-
tion program (thermostat.exe). This
program defaults to COM1, but you
may reconfigure it for another COM
port by choosing Options in the Tools
pull-down menu. The emulation pro-
gram will vary the temperature so the
Heat and Cool settings are exercised.
CONNECT WITH BROWSER
Open your browser to the XPort’s IP
address. If you don’t have Java
installed on your browser, you will
have the chance to install it automati-
cally. After it’s installed, the XPort’s
thermostat.html web page will appear
on your browser.
You can have both the emulator and
the browser open at the same time
(see Photo 3). Clicking on the thermo-
stat buttons in either the emulator or
browser windows will show control
over the thermostat while both dis-
play identical settings.
TRAFFIC
On the network side, TCP packets are
transferred between the browser and
the XPort. The browser sends an ARP
to find the IP’s Ethernet address. The
XPort returns an ARP with a reply
identifying itself. The browser then
uses TCP to open a connection to port
80 on the XPort. XPort acknowledges
the request and the browser acknowl-
edges the response.
Next, the browser requests the ther-
mostat.html page, and HTTP packets
are transferred. The graphics files that
make up the thermostat graphic are
included. The Java code executing on
the browser opens a connection to port
10001 on the XPort. What is visible on
the thermostat is based on the values
of certain data passed back and forth
between the browser and serial port (the
thermostat emulator in this case). This
is the TCP data that flows through the
XPort bridge linking the browser with
the XPort’s serial port (see Table 2).
EOF
Now you have a Java-enabled
browser (think My Application) com-
municating directly with a thermostat
(think My Embedded Device) using a
special protocol (think My Protocol).
To help you develop special ’Net
applications, Lantronix offers a free
programmer kit (CPK). Note that the
kit isn’t available on the company’s
web site, so you must contact a com-
pany representative with your request.
At a required floor space of less than
one square inch, XPort is the coolest
packaging job that I have seen in a long
time. Lantronix has plenty of experi-
ence in this field; they’ve been produc-
ing similar products for years. XPort
gives you the power of the Internet
without placing huge demands on real
estate or design engineering.
I
78
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
O
nce again, I enjoyed my annual
summer getaway to the Hot Chips
conference, which just celebrated its
fifteenth anniversary. Over the years,
the chips have come and gone, but for-
tunately the Hot Chips recipe remains
the same: good chips, chow, and chat
served up in the laid-back atmosphere
of Stanford University. As the confer-
ence name implies, Hot Chips is gen-
erally about the performance-at-any-
price chips only a rocket scientist
could love, and this year’s gathering
was no exception.
Make no mistake, I daresay few of
you will have an immediate use for any
of these high-end hotties. However,
when it comes to silicon, it’s safe to say
that today’s high-end is tomorrow’s low-
end. What I’ve learned over the years is
that keeping up with the bleeding edge
is a good way to get a glimpse of what
might be around the next corner.
SUPERDUPERS
You think your Commodore 64 is really
neato
What kinda chip you got in there, a
Dorito?
…In a 32-bit world, you’re a 2-bit user
You’ve got your own newsgroup,
alt.total-loser
Your motherboard melts when you try
to send a fax
Where’d you get your CPU, in a box of
Cracker Jacks?
–––Weird Al Yankovic, “It’s All About
the Pentiums,” Running with Scissors,
Volcano, June 1995.
Circuit Cellar
113). The explicitly par-
allel instruction computing (EPIC)
architecture is kind of a VLIW-in-
drag—no mean feat considering the
thing still has to run old x86 binaries.
Even so-called RISCs are hardly
“reduced” anymore, but Itanium takes
the cake with practically every architec-
tural trinket ever conceived, and then
some. Indeed, the knock on Itanium has
been that all the complexity holds back
the clock rate, in turn resulting in a net
decrease in performance relative to
simpler but higher-speed chips (i.e.,
1.5-GHz Itanium versus 2-plus-GHz
Pentiums). Although perhaps a Freudian
slip, Intel draws attention to the fact
that clock rate is king when they brag
that the new 1.5-GHz version is “deliv-
ering on the promise of 30% to 50%
performance improvement” over the
1-GHz version.
Easy to overlook in all the desktop
CPU hoopla is the fact Intel is still in
the single-chip MCU business. With an
ARM-based super-pipelined 32-bit core
surrounded by megabytes of memory
(flash memory and SRAM) and a
plethora of peripherals, maybe the
PXA800F is the 8051 for the twenty-
first century. Targeting mobile applica-
tions, the ’800F also includes a dedicat-
ed DSP subsystem, the so-called
“Micro Signal Architecture” jointly
developed with Analog Devices.
That trend, combining complemen-
tary applications and signal processors
on a single chip, is clearly taking hold.
Numerous examples were presented
Hot Chips 15
SILICON UPDATE
by Tom Cantrell
For Intel at Hot Chips, it was all
about the Itaniums—the Itanium 2 6M,
to be specific. This latest and greatest
example of silicon excess with a 6-MB,
on-chip L3 cache crams a whopping
410 million transistors under the hood.
That qualifies Itanium 2 6M as the
most radical chip on the block, at least
until the forthcoming Itanium 2 9M
(a.k.a., Madison), which boosts the L3
cache to 9 MB!
I put in my two cents on the
Itanium architectural concepts long
ago (“Test Drive a Merced With Pins,”
Last summer’s Hot Chips conference at Stanford University was the coming-out party for
many of the industry’s newest high-end chips. As usual, Tom was in attendance, doing the
rounds and taking copious notes at all of the meetings and presentations. This month, he
provides a glimpse of the high-end silicon that will drive your future designs.
Figure 1—
Multithreading delivers much of the feel and
benefits of multiprocessing, but at much lower cost.
Notice the significantly better execution unit utilization
delivered by IBM’s POWER5 simultaneous multithread-
ing compared to earlier schemes.
FX0
FX1
FP0
FP1
LS0
LS1
BRX
CRL
FX0
FX1
FP0
FP1
LS0
LS1
BRX
CRL
FX0
FX1
FP0
FP1
LS0
LS1
BRX
CRL
FX0
FX1
FP0
FP1
LS0
LS1
BRX
CRL
Single thread
Coarse-grain threading
Fine-grain threading
Simultaneous multithreading
Thread 0 executing
Thread 1 executing
No thread executing
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
79
including Janus from Atmel
(ARM7 + VLIW DSP), RAMP-
IV from the Semiconductor
Systems Laboratory of the
Korean Advanced Institute of
Science and Technology
(ARM9, graphics accelerators,
and 29 Mb of graphics
DRAM), the data-over-NTSC
ReX from Dotcast (V850 CPU
and a Configurable Stream
Processor), Broadcom’s Edge
(ARM9 and TeakLite DSP),
Texas Instruments’s DM310
(ARM9 plus C54x DSP), and
the Telarity TVP400 (32-bit
scalar plus four-pipe, vector-
processing DSP).
Most of the high-end processors, such
as the IBM POWER5, have adopted
another popular technique you may
have heard about—multithreading. To
make a long story short, despite all the
fancy three-level caching and sophisti-
cated static and dynamic instruction
scheduling, execution unit utilization
remains a meager 20% to 25%, accord-
ing to IBM (i.e., the delivered instruc-
tions per clock is a small fraction of the
number of execution units).
Multithreading attempts to better uti-
lize resources by mapping multiple vir-
tual CPUs on a single physical one by
duplicating a few key resources such as
an extra program counter and register
file. That way, while one of the virtual
processors is stalled (say, waiting for a
cache to reload), the other is allowed to
run. As shown in Figure 1, IBM’s latest
embellishment, simultaneous multi-
threading, even allows multiple threads
to proceed in the same clock cycle.
The benefit is that the virtual per-
formance increase exceeds the extra
cost for the multithreading logic.
However, the benefit is somewhat
application-dependent, with the best
ROI naturally reserved for workloads
that are not execution unit limited.
The Tricore folks have thrown in
their own two cents with a simpler mul-
tithreading scheme that focuses on
cache stalls. It would seem reasonable
that if cache stalls are the problem, try-
ing to run two cache-starved virtual
processors isn’t going to help. Their
answer relies on using dedicated scratch-
pad memory for one of the threads,
which allows both threads to proceed
quickly without cache contention.
Performance isn’t the only hot topic.
Whether avoiding meltdown at the high
end or stretching battery life at the low
end, the need to reduce power consump-
tion is something everyone agrees on.
Reducing the voltage is the way to go,
because it cuts power consumption of all
types (e.g., static, dynamic, and leakage)
by a squared factor (i.e., cut the voltage
in half and the power is cut by a factor
of four). A presentation from ARM high-
lighted the use of the latest technique,
adaptive voltage scaling (AVS), based on
a scheme known as PowerWise from
National Semiconductor.
The idea behind AVS is to dynamical-
ly reduce voltage to the minimum nec-
essary to achieve the performance
required at a given instant (see Figure 2).
This is a closed-loop adaptive system
that takes into account all aspects of
operation including process variations
and even ambient tempera-
ture to deliver the absolute
lowest voltage required to
get the job done.
That’s not to say that
there aren’t challenges. The
system relies on the fre-
quent coarse- and fine-tun-
ing of both the clock rate
and voltage. Recalling the
dilemma with asynchronous
no-clock designs, a slippery
clock can be a concern for
hard real-time applications.
Meanwhile, changing the
voltage hither and yon leads
to some head scratching
over level shifting (i.e., how to accom-
modate the fact that different portions
of the system may have to operate at a
fixed or only slightly variable voltage).
If the chips we’re discussing are
Doritos, then a supercomputer—like the
Japan Marine Science and Technology
Center’s Whole Earth Simulator—is the
Nachos El Grande. Start with 5120 arith-
metic processors, each a 60M transistor,
140-W behemoth in it’s own right. Then,
throw in 10 terabytes of DRAM, 640 ter-
abytes of disk, and 1.5 petabytes of back-
up storage for good measure. With a die
size (i.e., specially constructed building)
of over 3000 square meters and an 8-MW
(as in megawatt) power supply, this
“hot chip” delivers up to 40 teraflops
of peak performance. Put that in your
pipeline and smoke it!
HARD HAT SILICON
More MIPS is grand, but not if it just
means mistakes get made faster than
ever. Whether it’s the space shuttle, the
power grid, or your favorite chip, does
anyone argue a greater focus on quality
and reliability isn’t in order?
Thus, other than its early Sunday
morning start, the timing for the “Robust
System Design Techniques” tutorial was
especially fortuitous. Although the pres-
entation by Subhasish Mitra, Ph.D., a
senior staff engineer at Intel, naturally
started with the challenges posed by the
latest generation of silicon, I found much
of his presentation broadly applicable to
many aspects of system design.
On the chip front, a number of the key
points nicely dovetailed with last year’s
tutorial on the challenges facing Moore’s
100%
Conventional
on/off power
management
0%
100%
0%
Dynamic
voltage
scaling
Energy
used
t
Energy
used
t
Processor
utilization
Figure 2—
When it comes to battery-powered applications, the metric of interest is the
total energy required to get the job done on time. Like the hot-rodder that races
between stoplights compared to a smooth driver, traditional sleep modes aren’t as effi-
cient as modern dynamic voltage scaling techniques.
Photo 1—
In the quest to find ways to make chips and
systems more reliable and robust, some must perish.
This too-hot chip gave its all, a victim of thermal run-
away during burn-in. (Mark Miller, “Next-Generation
Burn-In & Test System for Athlon Microprocessors:
Hybrid Burn-In,” Burn-In & Test Socket Workshop,
2001.)
M e e t f a c e - t o - f a c e w i t h t h e c o m p a n i e s
t h a t h a v e t h e t o o l s a n d t e c h n o l o g i e s
y o u n e e d :
Amplifiers/Oscillators
Active Components/Semiconductors
Basic Materials & Packaging
Cables & Connectors
Computer-Aided Design
Electronic Design Automation Tools
Embedded Systems
As a designer or manufacturer of
wireless products, systems or services
for consumer, business or industrial
applications, Wireless Systems Design
Conference & Expo is a must-attend
event. See, test and compare the very
latest wireless device components,
subsystems, software and tools. Choose
from dozens of sessions covering all
aspects of wireless design. Network
with fellow engineers, specifiers and
buyers who face the same issues and
challenges.
Silver Sponsor:
Media Sponsors:
Produced By:
R
M a r c h 8 – 1 0 , 2 0 0 4
S a n D i e g o C o n v e n t i o n C e n t e r, S a n D i e g o , C A
Conference Tracks Include:
Broadband/Wideband Networks
Cellular/3G
Components
Handset Design
Low-Power Applications
Mobile & Wireless
Power Management
Software Development
Test & Measurement
Wireless Networks
Wireless Security
WLAN Technology
K e y n o t e
Henry Samueli, Ph.D.,
CTO and Chairman of the
Board of Directors,
Broadcom Corporation
K e y n o t e P a n e l s
Using PoE to Empower the
Proliferation of Wireless Devices.
Where is the Wireless Industry
Going?
Fiber Optics
Passive Components
Services, Publications
Software
Systems & Subsystems
Test Equipment &
Instrumentation
...and much more!
w w w . w s d e x p o . c o m
R e g i s t e r To d a y !
Log onto http://www.wsdexpo.com
F o r M o r e I n f o r m a t i o n o n E x h i b i t i n g
Sharon Pierce, Director of Sales, 203/559-2968,
spierce@penton.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
81
Law that I wrote up in my column titled
“Hot Chips, Cold Sweat” (Circuit Cellar
149). You will recall that there are a lot
of obstacles on the horizon, many of
which boil down (pun intended) to the
issue of hot chips that are too hot for
their own good (see Photo 1).
Smaller geometries and reduced volt-
ages are inevitable but introduce new
concerns of their own. It turns out that
chips literally wear out because of phe-
nomenon like electromigration and
oxide breakdown, a problem made all
the worse by shrinking feature size.
Although a life span between seven
and 15 years may be fine in the PC
world where a system more than five
years old is considered a boat anchor,
can the same be said for long-lived
embedded apps? Fortunately, for the
time being, the mainstream MCUs
used in blue-collar designs are hardier
by virtue of their less advanced, and
thus less fragile, design rules.
Ever-tinier transistors with ever-lower
voltage thresholds are also threatened by
all manner of noise from crosstalk to
cosmic rays. Don’t laugh, it’s getting to
the point where heavyweights like IBM
are studying the effect of altitude on sys-
tem reliability. They are worrying about
the fact the cosmic ray flux in Denver is
five times that of New York City.
The culprit is the so-called single
event upset (a.k.a. SEU or flaky bits).
Indeed, SEUs are not only a threat,
they’re already a fact of life. For
instance, cache memories in nearly all
top-end chips are routinely ECC pro-
tected, and that’s just the start. Already,
designers are looking at adding ECC
protection for latches and other logic.
If there’s good news, it’s the recogni-
tion that systems may tolerate SEUs
with little or no effect on system opera-
tion. Consider your PC. If a bit glitches
on the screen, in stale cache or some-
where in the megs of comatose code
(i.e., routines rarely executed), you may
never notice. Furthermore, although
small solace, other sources of errors
such as shoddy software, power fail-
ures, and cockpit errors are much more
likely sources of trouble.
However, SEUs are already a fact of
life in other high-end systems. Some
of the first problems were noted in
network gear, which uses lots of
SRAMs. [1] SRAMs used to be consid-
ered trustworthier than DRAMs, but,
in fact, that’s no longer the case. The
ever-lower cell capacitances that give
them their high-speed and low-power
advantages also make fine geometry
SRAMs more susceptible to SEUs.
Whatever the application, I expect
more emphasis on defensive design
than in the past. The tutorial dis-
cussed a variety of techniques in a
hierarchy from simply avoiding faults
in the first place, to fault detection,
recovery, and even repair. What follows
is a sampling of some interesting ideas
you might consider for your next high-
er-than-ever-reliability design.
Everyone’s familiar with the watchdog
timer concept, which is already a fixture
in most MCUs. It’s lovable and better
than nothing, but a bit dumb. Without
care on the designer’s part, you can end
up with a watchdog that howls at every
passing siren but wags its tail at the thief.
A technique called structural integri-
ty checking gives the watchdog an IQ
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
83
implant. A dumb watchdog just barks
sometime after things have gone awry,
with possibly disastrous consequences
in the interim. By contrast, a smart
watchdog immediately barks the
instant operation deviates in any way
from the norm by monitoring the
sequence of activity (see Figure 3).
Redundancy is a common approach
to fault tolerance, with two-way mas-
ter/checker configurations and even
three-way voting schemes. But watch
out, all of the extra circuitry involved
can make the reliability situation
worse if you’re not careful. Practice has
shown that brute force redundancy best
serves short duration, mission-critical
tasks, such as an aircraft landing.
One of the challenges for redun-
dancy is common mode failure. It
does no good to have three comput-
ers running things if they all crash at
the same time for the same reason.
This brings up the concept of design
diversity. It’s common practice in the
highest of high-rel space, military,
and avionics applications to explicit-
ly require that the multitude of sys-
tems come from a variety of different
sources to specifically guard against
common mode failures.
At a lower level, the technique is
being applied to circuit design as well.
The tutorial showed how pairing two
slightly different versions of a logic func-
tion produced a hybrid much more
robust (i.e., more tolerant of circuit
faults and less likely to generate unde-
tected errors) than simply duplicating
the function.
Software can do its part as well. A
simple approach for dealing with SEUs is
just to duplicate all of the instruc-
tions and data in the form of master and
shadow versions and compare the
results, thus minimizing the chance a
flaky bit somewhere will get by unno-
ticed. A variation exploits the aforemen-
tioned diversity concept by using master
and shadow routines that are semantical-
ly equivalent but not exact duplicates
(see Figure 4).
Yes, it is brute force and consumes a
lot of resources (nominally two times
the registers, memory, cycles, etc.). On
the plus side, the compiler can handle
the grunt work automatically.
Furthermore, the results can be
impressive. In space, SEUs aren’t bad
luck, they’re a way of life, averaging
5.5 per megabyte of memory per day.
One space-based experiment with a
commercial off-the-shelf (COTS) micro-
controller (i.e., not radiation hardened)
used master/shadow and signature-
checking error-correction techniques to
extend the time between crashes from
less than three days to 12 days. [2]
The frontier now extends to systems
that can fix themselves. The Stanford
Reliability Obtained by Adaptive
Reconfiguration (ROAR) program takes
advantage of the dynamic reconfigura-
tion capability of FPGAs. Should a por-
tion of the FPGA circuitry permanently
fail, an alternative configuration that
bypasses the failed portion is installed.
Because it can take awhile to compile a
new bitstream, the system relies on pre-
compiled configurations that each
bypasses a different column of CLBs in
the FPGA. However, a bunch of precom-
piled bitstreams consumes a lot of mem-
ory; therefore, ROAR exploits the fact
that each version is similar (they just dif-
fer by which column isn’t used), so only
the difference needs to be noted. With
compression, the precompiled bit-
streams for a 10-column FPGA require
only fractionally more storage (1% to
30%), not 10 times more storage.
NANU-NANU TECH
I keep getting press releases and
announcements about something called
“nanotech.” I confess to not under-
standing much beyond the obvious goal
of making things smaller, ostensibly on
a molecular or atomic scale.
I’m still no expert, but thanks to a
presentation covering ongoing research
at Caltech (“Sub-Lithographic
Semiconductor Computing System”),
I now have a better understanding of
nanotech, at least as it applies to the IC
biz. The title says it all.
Once again, recalling the last confer-
ence’s tutorial on the “Wall” (i.e.,
challenges to the march of Moore’s
Law), it’s clear that conventional, or
lithographic, IC production techniques
are doomed to run into fundamental
limits. Nanotech is arguably a con-
tender for the paradigm shift that gets
us beyond the limits of lithography.
The research at Caltech focuses on
so-called nanowires, which are silicon
wires only a few nanometers thick that
self-assemble as shown in Figure 5. The
next step is to introduce dopants dur-
ing wire growth to create differentiat-
ed wires such that portions of the
wire exhibit different threshold volt-
ages. In turn, these coded wires are
the building blocks for higher-level
logic functions such as an address
decoder, memory, and ultimately a
Conduct only
with field < 1 V
Conduct any field < 5 V
Figure 5a—
Silicon nanowires self-assemble them-
selves according to nature’s way.
b—
By introducing
dopants at certain times, a differentiated wire can be
grown. In turn, differentiated wires can build gates,
memories, programmable logic arrays, and ultimately
full-fledged nanocomputers.
a)
b)
i=0; x=1; y= 5;
While (i < 10) {
z = x + y * i;
i = i + 1;
}
i = 0, x = 1, y = 5
i < 10
z = x + y * i
i = i + 1
i = 0, x = –2, y = –10
i > –20
z = x – y * i / 2
i = i – 2
i=0; x=–2; y= –10;
While (i > –20) {
z = x – y * i / 2;
i = i – 2;
}
Condition
Transform
Expression
Transform
Figure 4—
One approach to detecting errors simply
duplicates code and data and then compares the
results. Adding design diversity enhances the error
detection capability by transforming the checker code
to exercise different portions of the logic and compiler.
Block 1
Block 2
Block 3
Block 4
i < 10
J > 5
Block 1 signature
to watchdog
Block 2 signature
Block 3 signature
Block 4 signature
SIC Example
Figure 3—
A structural integrity-checking watchdog,
keeping track of basic block sequences, is far more alert
than the traditional puppy that only barks after the fact.
84
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
REFERENCES
[1] A. Cataldo, “SRAM Soft Errors
Cause Hard Network Problems,”
EE Times
, August 17, 2001.
[2] M.N. Lovellette, “Strategies for
Fault-Tolerant, Space-Based
Computing: Lessons Learned
from the ARGOS Testbed,”
Proceedings IEEE Aerospace
Conference, vol. 5, 2002.
Virgin charged with the immaculate
conception of a new operating system
that would save us from ourselves, not
to mention Microsoft. The idea may
have been cool, but the company never
seemed to get beyond the hype-and-
hope stage. A succession of politically
anointed leaders, a process akin to
choosing a new pope, ultimately found
the severance package cooler than actu-
ally cranking any code. The ultimate
downer was when the final handpicked
successor had the temerity to die in
office, arguably doing capitalism a good
deed by taking Taligent with him.
Nick Tredennick has been around,
having anted up at literally dozens of
startups. Unfortunately, most of them
lost money while those that managed
to make some money always seemed
to make it for somebody else instead
of Nick. Put his list of companies that
were start-up disasters together with
his list of disasters in progress, and
you end up with something along the
lines of the NASDAQ. The causes of
disaster in Figure 6 sum up the hard
lessons Nick learned in the course of
living the dream.
Or make that a Dilbert-esque night-
mare, according to Dave Wyland, who
pointed out something most engineers
learn early on: your own company
also can be your own worst enemy!
He got a laugh with a story from his
corporate days, telling of the time he
confronted a manager from another
department with a time- and money-
saving technique. The erstwhile com-
rade (bitter rival) could only respond
with a lame, “That’s not fair.”
Jim Turley finished up his presenta-
tion by calling attention to the core
temperature monitor that America’s
favorite astronaut-senator John Glenn
courageously swallowed on his Space
Shuttle flight. This PIC-based proces-
sor pill was designed to drift around
his guts—“Amazing Voyage”-style—
and keep track of his vital signs.
However, I don’t think this qualifies as
a disaster but rather a blessing. Glenn
himself noted that he much preferred
it to the earlier rectal probe version.
HOT CODE?
Speaking of superdupers, reliability,
and disasters, we’ve got superduper
PCs, but there’s a problem. The soft-
ware that runs on them isn’t very reli-
able. That’s why we’ve got disasters,
like the latest rash of virus attacks.
The final straw was when I heard a
virus was exploiting a newly discov-
ered buffer overflow bug. You’ve come
a long way, baby?
At least the pain hardware engineers
face on the reliability front can be
considered the price paid to get ever
faster and cheaper hardware. Yet the
best software engineers can do is spit
out another buffer overflow hack?
Maybe it’s time for a Hot Code confer-
ence? Tutorials could describe the fancy
tools and advanced techniques needed to
get beyond the seemingly intractable
buffer overflow. Other sessions could
examine the challenge posed by Bill’s
Law, which apparently states that soft-
ware becomes both more juvenile and
more senile over time. Evening panel
sessions might have titles like “GOTO,
GOTO, Gone In 60 Nanoseconds” or
“Mars and Metric Done Me Wrong.”
That would be really cool!
I
programmable logic array (PLA), the
basis for nanoscale computing.
It sounds good, but even beyond the
obvious fabrication challenges there is
a possible gotcha. Although nanotech-
niques may offer the promise of mak-
ing circuits smaller, the story about
performance and power consumption
is less clear. Yes, small is beautiful,
but only if it delivers the goods per-
formance-wise and deals with show-
stoppers of power consumption and
heat stroke.
IN SPACE, NO ONE CAN HEAR
YOU SCREAM
The Monday night panel session,
“Disasters I Have Been Involved With,”
brought tears to my eyes—tears of
laughter that is. What engineer hasn’t
been swayed by dreams of hitting it big
with a Silicon Valley startup? You drive
your cool sports car to your cool office
with the cool chair. The office has the
cool gym, day care center, and espresso
bar. Sit around in some meetings shoot-
ing the breeze about cool stuff with
other cool folks. After awhile, there’s an
IPO and your stock options make you a
cool million. Of course, the money is
just an attaboy because your life is
already perfect. Cool.
But panelist Jim Turley, the Jay Leno
of the micro biz, reminded us that the
Kiss of Death #1 foretelling impending
doom is when the pitch starts with,
“This is really cool.” He proceeded to
skewer an eclectic collection of iffy
ideas, everything from pay radio (“We’ll
get people to pay for something they
already get for free. Cool!”) to the bloat-
ed Microsoft/Harman Kardon universal
remote that purports to “take control”
of everything, no doubt including your
money and sanity.
No mere Microsoft basher, Jim put
up a slide titled “Java: Hoax or
Malicious Prank?” and proceeded to
relate how Java inventor James
Gosling, when asked to explain the
popularity of the Java bandwagon,
answered, “You mean, besides drugs?”
Speaking of cool, was there ever a
company as cool—and as quickly for-
gotten—as Taligent? Remember them?
Former exec Jack Grimes wistfully
recalled the tale of this joint brainstorm
of Apple and IBM, the would-be Holy
Tom Cantrell has been working on
chip, board, and systems design and
marketing for several years. You may
reach him by e-mail at tom.cantrell@
circuitcellar.com.
Causes of disaster (ranked by cause)
Whacko management
IIII IIII
Clueless board
IIII III
Money
IIII
II
Idiotic strategy
IIII
Acquire and kill
II
Poor timing
II
Other
II
Goofy engineering
Figure 6—
It isn’t pretty, but Nick Tredennick’s career
path provides a valuable lesson for startups. He noted
with the items in blue that when it comes to the causes
of disaster, there appears to be an inverse relationship
between competence and compensation.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
85
IDEA BOX
THE
DIRECTORY
OF
PRODUCTS AND
SERVICES
AD FORMAT
: Advertisers must furnish digital submission sheet and digital files that meet the specifications on the digital submission sheet.
ALL TEXT AND OTHER ELEMENTS MUST FIT WITHIN A 2
″″ ××
3
″″
FORMAT
. Call for current rate and deadline information. Send your disk and digital submis-
sion sheet to: IDEA BOX, Circuit Cellar, 4 Park Street, Vernon, CT 06066 or e-mail kc@circuitcellar.com. For more information call Sean Donnelly at (860) 872-3064.
The Suppliers Directory at www.circuitcellar.com/suppliers_dir/
is your guide to a variety of engineering products and services.
turn serial data into video text
Insert-ready Single Board Computer modules in sub-miniature
dimensions (as small as 47x55 mm) populated by:
applicable controller signals extend to standard pin header (2.54
mm) or high-density Molex (0.625 mm) connectors, enabling SBC
to be plugged like a big chip into OEM targets
achieved via GND circuitry, multi-layer PCB, by-
pass capacitor grid and short signal traces achieved via small
footprint and use of 0402 SMD passive components
32 KB to 64 MB external SRAM and Flash (controller-dependent)
CAN, Ethernet, RS-232 and RS-485 interfaces; ADC, DAC
(controller-dependent); freely-available /CS and I/O lines
AC adapter, serial cable and SPECTRUM CD with eval software
tools, electronic documentation and demos
: insert-ready PHYTEC SBC modules accompany you
from evaluation through protyping to end production...
accelerating your design cycle and reducing your time-to-market
86
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
Interface Keypads, Switches, or RS-232 to your PC Keyboard Input
Up to 12 x 12 matrix Programmable RS-232 Port Macro Capability
The KE24 is the ultimate in flexibility. Inputs or serial data can
emulate any of the 101 keys from a standard keyboard.
Up to 9 x 9 matrix 2.5" x 3.0" Size PC Keyboard Port PCXT, AT Compatible
The KE18 combines a multitude of features with small size at an
economical price. Custom units available.
Phone: 607-533-4441 Fax: 607-533-4443
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
87
• Control or monitor 12 I/O’s of digital
or analog input and digital outputs
88
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
sales@sealevel.com 864.843.4343
• Supports data rates up to 921K bps
• Ethernet 10/100Base-T (autosense)
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
89
90
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
91
Ready-Made Graphical User Interface
Bright, High Contrast 1/4 VGA (320x240 pixel)
Electroluminescent (EL) or Monochrome Display
Precoded menu managing software
Real-time Multitasking Executive
tel: 510-790-1255 fax: 510-790-0925
92
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 162 January 2004
93
Wireless Vehicle Tracking: Part 1—System Basics
Wireless Water Heaters
$1 Wireless Interface
Wi-Fi-Enabled Embedded Control
Wearable Wireless Transceivers
CoolRunner-II-Based Digital Telemetry Transmitter
I Above the Ground Plane: Filters and Firmware
I Applied PCs: Picking Apart Microchip’s dsPIC
I From the Bench: The Growth of the Atmel AVR Family
I Silicon Update: ’51 Flavors
Preview of February Issue 163
Theme: Wireless Communication
94
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
91
Abacom Technologies
89
ActiveWire, Inc.
75
All Electronics Corp.
93
Amazon Electronics
93
American PCB Assembly
92
AP Circuits
9
Arcturus Networks
7
Atmel
91
Bagotronix, Inc.
90
Basic Micro
76
Bellin Dynamic Systems, Inc.
41
CadSoft Computer, Inc.
87
Carl’s Electronics
12
CCS-Custom Computer Services
92
Conitec
61
Connecticut microComputer, Inc.
73
CTIA Wireless 2004
85
Cyberpak Co.
1
Cypress MicroSystems
65
CWAV
91
DataRescue
85
Decade Engineering
13
DesignCon 2004
12
DLP Design
23
Dynon Instruments, Inc.
66
Earth Computer Technologies
87
EE Tools
(Electronic Engineering Tools)
The Index of Advertisers with links to their web sites is located at www.circuitcellar.com under the current issue.
Page
55
Electronica USA
61
EMAC, Inc.
69
eMachine Shop.com
55
Embedded Systems Conf.
89
emBoot, Inc.
85
Eric Senter Embedded Design
22
ExpressPCB
85
FDI-Future Designs, Inc.
92
Front Panel Express
39
GSPX Forum/Conf.
87
Grid Connect
86
Hagstrom Electronics
40
HI-TECH Software, LLC
42
ICOP Technology Inc.
89
IMAGEcraft
12
Innoventions, Inc.
86
Intec Automation, Inc
90
Intrepid Control Systems
91
Intronics, Inc.
81
IPC Expo
64, 86
JK microsystems, Inc.
86
JPA Consulting
46
JR Kerr Automation & Engineering
46
LabJack Corp.
46
Lakeview Research
77, 89
Lemos International
2
Link Instruments
59
Linx Technologies
48
MaxStream
90
MCC (Micro Computer Control)
67
Microchip
92
microEngineering Labs, Inc.
82
Micromint
90
MJS Consulting
91
Mosaic Industries, Inc.
49
MVS
86
Mylydia Inc.
C2
NetBurner
93
NPE, Inc.
88
OKW Electronics, Inc.
92
Ontrak Control Systems
31
PCBpro
8
PCBexpress
87
PCB Fab Express
74
PCB West Design Conference
C4 Parallax, Inc.
85
Phytec America LLC
87
Phyton, Inc.
88
Picfab Inc.
93
Pioneer Hill Software
88
Precision Technologies, Inc.
93
Pulsar, Inc.
88
Quality Kits & Devices
25
R2 Controls
Page
Page
Page
21
R4 Systems Inc.
19
Rabbit Semiconductor
8
Remote Processing
15
Renco Electronics, Inc.
5, 33
Renesas Technology Corp.
90
RLC Enterprises, Inc.
3
Scott Edwards Electronics Inc.
88
Sealevel Systems
95
Sierra Proto Express
85
Signum Systems
88
Softools
31
Systronix
C3
Tech Tools
28, 29
Technologic Systems
90
Technological Arts
89
Tern Inc.
86
Trace Systems, Inc.
91
Triangle Research Int’l, Inc.
67
Trilogy Design
93
Weeder Technologies
80
Wireless Systems Conf. & Expo
86
Zagros Robotics
91
Zanthic Technologies Inc.
89
Zexus Technologies Ltd.
March Issue 164
Deadlines
Space Close: Jan. 9
Material Due Date: Jan. 19
Theme:
Embedded Applications
A
TTENTION
A
DVERTISERS
e-mail: sean@circuitcellar.com
INDEX OF ADVERTISERS
BONUS DISTRIBUTIONS
Embedded Systems Conference
Electronica USA
PCB West
Their boards come with a
packing slip. Ours come
with a
Microsection
Analysis Report
In today’s competitive climate, offering the
best product at a competitive price is a must
to satisfy your customers. Sierra Proto
Express offers the fastest, most reliable, turns
at the highest quality. And we’ll prove it in
every shipment with our unique Evidence of
Quality reports, so you know your board is
right the first time. One proof of quality is
our Microsection Analysis Report, as
featured here, so you can see the quality
inside your board. And that is just part of
our comprehensive quality tests. It’s in our
process, not in our price. In fact, it is our
commitment to total quality that enables us
to run our operation cost effectively. And
that comes back to you in our competitive
price. Talk to a Sierra Proto Express Account
Manager about our commitment to quality,
our range of technology, and our 99%
on-time track record of delivery. Call
1.800.763.7503 from 6 a.m. to 6 p.m. PST
or email your design to
files@protoexpress.com and receive a quote.
Mention code: PPDC00093
For proven quality that never costs
extra, put Sierra Proto Express on
your team today.
14 Layer Board
Microsection
Learn more about our unique Evidence of
Quality report that comes with every PCB
at www.protoexpress.com
I
laughed at some of the predictions that were made 20 years ago about how computers and interactive communication would infiltrate our lives.
It isnt that I go kicking and screaming into every technological advancement. Its just that I like to see personal benefits before I adopt new ways
of doing things. In curmudgeon speak, this translates as, if it aint broke, dont fix it.
In truth, Im not quite as crusty as Id like people to think. I tend to own the latest computer architecture. I bought a PDA before they were pop-
ular. I own a car that is intimidating to all but computer-generation people. And, I set up a wired/wireless house long before others saw the ben-
efits. Still, Im not sure Im ready for the one prediction that is only now coming to fruitionwireless identification tracking.
One of the more outlandish past predictions was the ubiquitous Internet-connected appliances and the infamous refrigerator that monitored
its contents and automatically ordered things from the grocery store. The shock of such an idea at the time wasnt because we couldnt conceive
of an Internet-interface and LCD screen in a refrigerator. (After all, who in 1920 could have conceived of an automatic ice cube maker in every
refrigerator?) It was the absurdity of thinking that someone would actually want to go through the trouble of scanning the bar code on every item
entering or leaving the refrigerator just so they could say the refrigerator handled the inventory. This idea was nutty, and anything requiring this
much manual involvement is hardly useful.
But, you can teach an old dog new tricks. Your next refrigerator may have this capability for real, thanks to cheap radio-frequency identifica-
tion (RFID).
RFID isnt new. Were all familiar with the antitheft clothing tags in department stores. A transmitter in the doorway energizes the RFID circuitry
through a flat antenna in the tag. The energy received through this antenna powers a radio transmitter embedded in the tag that sends out the
equivalent of a radio bar code. Conceivably, by comparing the information from the tag to sales receipt information from the cashiers system, the
stores information system can know everything about the product passing through the doorway and whether or not it was paid for.
Today, because RFID is still relatively expensive per ID point (approximately $0.50 to $1), it is applied mostly in supply-chain and high-end
inventory applications. Adding a $1 tracking tag to shipping containers, fur coats, expensive machinery, laboratory equipment, and even military
hardware is an easy decision.
As RFID becomes less expensive (a couple pennies or less), we will see it incorporated into many more high-volume applications. In the
future, the luggage tag attached to your suitcase when you check in at the airport will contain an RFID chip that interacts with the automatic bag-
gage routing system. Conceivably, every item on the store shelves will have an ID tag embedded in its label. Then, you could walk down the
aisles of a grocery store and directly fill your shopping bags. As you exit the store, a scanner interrogates your grocery cart and automatically
charges the credit card it senses in your wallet. When you get home, you fill the refrigerator shelves and it also scans and records its contents.
Eventually, the system we live in will have the hands-off ability to gain complete knowledge of our purchasing, consumption, travel, and com-
munications history, all in the name of convenience.
The bad news is that when such a system has all the details of your life, its just a matter of connecting the dots. Its a wonderful idea that the
clothes you wear could have electronic ID tags that a clothes washer can identify. Undoubtedly, Maytag will be among the first manufacturers to
automatically set the optimum washing cycle by scanning your load of laundry. Or better yet, the washing machine will alert you when something
in the pile is labeled dry clean only. This sounds ridiculous, but it will happen.
We will also have to contend with the fact that someone out there will indeed be connecting the dots. Unless RFID tags can be disabled at
will, the credit card information (hence, your complete ID) used to purchase a new pair of shoes will be irrevocably linked to those shoes. So, you
could be tracked whenever you wear them.
Its only the tip of the iceberg of what could ultimately come to pass, but the little bit of dot-connecting and tracking we see today points to
what could happen in the future. Turn on your cell phone, make a credit card transaction anywhere, or pass through a highway toll using E-Zpass
and theyve got you! Be careful how you define convenient.
Be Careful How You Define Convenient
steve.ciarcia@circuitcellar.com
96
Issue 162 January 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
by Steve Ciarcia, Founder and Editorial Director
PRIORITY INTERRUPT
Wyszukiwarka
Podobne podstrony:
circuit cellar1994 01
circuit cellar1997 01
circuit cellar2002 01
circuit cellar1996 01
circuit cellar1995 01
circuit cellar2001 01
circuit cellar2003 01
circuit cellar1997 01
circuit cellar1994 01
circuit cellar2004 01
circuit cellar1996 01
circuit cellar1990 12,1991 01
circuit cellar1992 12,1993 01
więcej podobnych podstron