7
9
25274 75349
0 2>
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)
#163 February 2004
GPS Vehicle Tracker
Web-Enabled
Water Heater
Low-Cost RFID Solution
Digital Telemetry Transmitter
WIRELESS COMMUNICATION
GPS Vehicle Tracker
Web-Enabled
Water Heater
Low-Cost RFID Solution
Digital Telemetry Transmitter
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
W
e have an amazing collection of wireless projects this month. These
articles showcase a number of different ways to go wireless. In this issue,
you can learn how to build a wireless communication link from the ground
up, a GPS-based vehicle tracking system, and a wireless interface.
Russ Lindgren designed a wireless communication link using the Xilinx
CoolRunner-II (p. 10). As Russ explains, using a CPLD with fast output
buffers enabled him to create a design that works well for small battery-
powered applications. Based on only three ICs, the system is ideal for
temperature and pressure data transmission.
Also interested in data transmission, Ken Merk chose GPS technology
to devise a system that would track vehicles for his friend’s company (p.
20). His friend is an electrical contractor whose V6 power generators (on
trailers) had a knack for walking off the job site at night. Ken’s solution was
to design a GPS tracking system with an easy user interface that his friend
could use virtually anywhere. His wireless system is activated when the
GPS detects vehicle movement. Then, data including longitude and lati-
tude coordinates, bearing, and the vehicle identification number is con-
verted to speech and relayed via the user’s cell phone. One of the best
features of this design is that it does not require a computer interface, so
the user can be notified of a problem quickly whether he’s on-site, on the
road, or at home.
Gaining in popularity (or perhaps notoriety) is another device for wire-
less transmission: radio frequency identification devices. With basically a
coil, a capacitor, and a transistor, Larry Martin designed a wireless inter-
face that emulates RFID tags. In case you have any questions about how
the technology works, Larry provides a thorough explanation. What
intrigued him about RFID is how inexpensive it is to implement. Turn to
page 50 to learn how Larry used an Atmel e5551 tag to develop a wire-
less communication system that fits into anyone’s budget.
One of our special features this month is an overview of some of the
short-range RF projects being developed at the MIT Media Lab (p. 28).
Associate Professor and Director of the Responsive Environments Group
at MIT Joseph Paradiso and graduate student Mathew Laibowitz discuss
the wireless wearable platforms they’ve been working on, including high-
tech digital name tags and shoes that help physicians detect gait defects.
Combining their personal interests in the lab, they have also incorporated
wireless RF links in shoes for theatrical performance. Mat has studied film
and animation at NYU and designs electronic musical instruments. And,
Joe designs synthesizers and musical interfaces. With the Responsive
Environments Group, they designed a card that attaches to a dancer’s
shoe to acquire data based on the dancer’s movements. A PC then inter-
prets the data to generate music based on the movements.
The variety of projects in this issue is a testament to the limitless
nature of wireless communication. With the ever-increasing quality and
continual decrease in cost of transmission methods, it’s clear that the only
limitation is imagination.
4
Issue 163 February 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
Five Ways to Lose Your Wires
jennifer.huber@circuitcellar.com
TASK MANAGER
6
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
February 2004: Wireless Communication
CoolRunner-II-Based Digital Telemetry Transmitter
Wearable Wireless Transceivers
Mathew Laibowitz and Joseph Paradiso
TASK MANAGER
Five Ways to Lose Your Wires
Picking Apart Microchip’s dsPIC
The Growth of the Atmel AVR Family
FEATURES
COLUMNS
DEPARTMENTS
PRIORITY INTERRUPT
Moving Forward
A dsPIC Tour (p. 40)
Wearable Wireless
Platforms (p. 28)
Wireless Vehicle Tracking (p. 20)
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.
DEVELOPMENT SYSTEM SPEEDS WIRELESS INTEGRATIONS
8
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
Edited by John Gorsky
NEW PRODUCT NEWS
The MDEV-HP3-xxx Wireless Development System
contains all the tools necessary to fully explore the capa-
bilities of the HP-3 series
RF modules. The develop-
ment system is designed to
assist in the rapid evalua-
tion and integration of the
HP-3 modules, which allow
for the cost-effective wire-
less transfer of serial data or
audio/analog content
beyond distances of up to
1000
′
. The master develop-
ment boards feature
encoder/decoder ICs with
audible and relay-switched
outputs for range testing, an
RS-232 or USB interface for
protocol development,
demonstration software, and
an on-board prototyping
area with breakout headers
and a regulated power sup-
ply. The master development kit includes four HP modules,
two preassembled development boards, two antennas, bat-
teries, a software CD, and com-
plete documentation.
When you are ready to begin
development, a convenient pro-
totyping area with break-out
headers and a regulated power
supply allows for rapid testing
and interface. Finally, when
you have integrated the mod-
ules into your own product,
the kit will continue to serve
as a valuable benchmark to
compare the performance of
your own layout and design.
The development system costs
$299 for the RS-232 version
and $324 for the USB version.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
9
You may contact the quizmasters at eq@circuitcellar.com
CIRCUIT CELLAR
—
Test Y
Your E
EQ
Problem 3
—What’s a simple way to reduce
or eliminate the effects of a single ghost in a
TV image?
Problem 4
—Describe an algorithm that can
find a 2-D convex hull, which is defined to be
the smallest polygon that encloses a set of
points in a plane.
Contributed by David Tweed
Edited by David Tweed
Problem 1
—Draw the circuit for a “window
comparator” for voltages, where the output is
high whenever the input voltage (V
IN
) is
between two other variable voltages—V
1
and
V
2
—and low otherwise.
Problem 2
—A TV antenna is being used to
receive a commercial broadcast station (i.e.,
over the air, not via cable). However, a strong
ghost image is observed on the TV screen
about 2
″
to the right of the main image. If the
TV screen is 20
″
wide, how can you locate
the source of the ghost?
a low-frequency data clock to synchro-
nize the serial data, and a modulator to
combine the two. Add the most basic
antenna, a single strand of wire that’s at
least one quarter wavelength in length,
and the modulator can stream the RF
energy outward. Because the modulator
is digital, it requires only two features to
send wireless data: speed and output
drive. CPLDs built for interfacing to
CPU busses have both features.
Just like wired serial data (which is
what this RF information will become
after the receiver), a structure to the
data is needed to tell the decoder, at the
receive end, when to start capturing the
data, how to verify synchronization,
and to check (repairing if needed) the
serial data as it streams in. Fortunately,
these considerations just reflect the
logic built into the receiver firmware
and have only a minor impact on the
complexity of the data transmission
hardware and its power draw.
Now that most implications for a one-
way digital wireless data link are clear,
let’s look at a specific implementation
that needs only three ICs. IC1, the real
powerhouse of the design, is a CPLD
that provides an ideal development plat-
form: reconfigurable logic. I chose the
Xilinx CoolRunner-II because it has
extremely fast output buffers that are
capable of generating RF carrier frequen-
cies beyond 1 GHz, requiring less than
2 mA from a 1.8-V supply in the process.
These are the features that help you con-
struct small battery-powered devices for
wireless sensor data transmission. In
addition, this programmable logic device
offers a range of packaging options. It
has sufficient logic capabilities to handle
10
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
W
ith the inroads that programma-
ble logic has made into CPU interfaces,
new versions of these JTAG programma-
ble devices have now gained sufficient
bandwidth to directly transmit wireless
data. Take a look around. Integrated
wireless ICs abound, and wireless data
communication builds on each part’s RF
capabilities. Although many off-the-shelf
products for wireless data transmission
are available, that usually means living
with someone else’s design decisions
that may not match the design require-
ments you have in mind. And, if you’re
working on a battery-powered wireless
system, then power draw and reception
range are likely two features of the cir-
cuit design that you’ll need to optimize.
For sensor applications, though, it’s
easy to build a simple low-power, mod-
erate-speed wireless link that you can
add to a battery-powered microcon-
troller circuit to transmit one-way infor-
mation such as temperature, pressure,
or something more dynamic and com-
plex like acceleration. As an embedded
programmer, you know the versatility of
a serial datastream. Let’s consider the
circuit needed to take that serial data
onto the wireless highway, and then,
with the help of a commercial radio
receiver, build a local off-ramp for your
serial data. Through all of these trans-
formations, keep in mind that wireless
data transmission might just as well be
called making electromagnetic interfer-
ence (EMI) work for you as digital radio.
THREE ICs TO WIRELESS DATA
Building a wireless communication
link from the ground up starts with the
selection of specific hardware options (i.e.,
With the proper guidance, it’s fairly easy to build a wireless link for a sensor application that
transmits one-way information like temperature and pressure. In this article, Russ shows you
how to build your own wireless link with a CoolRunner-II CPLD.
frequency bands, transmission speeds, and
power requirements), moves to related
firmware protocols that help the receiver
verify that the data received matches the
information sent, and is completed by dis-
playing or data logging of the informa-
tion sent. Conceptually though, sending
wireless data comes down to one feature
at the digital level—modulating an RF
carrier with digital data.
Because the digital datastream consists
of binary data (1-0-1-0), the hardware
requirements for a low-power digital data
transmitter are considerably simpler, and
usually more integrated, than the modu-
lation needed for analog information.
And, most importantly, low-power, 1.8-V
digital circuits are extremely fast.
Given this starting point for function-
ality, the core components that a digital
transmitter needs to float your serial
data on the airwaves requires just three
operating blocks: a source oscillator that
generates the RF transmission frequency,
FEATURE ARTICLE
by Russ Lindgren
Photo 1—
With the JTAG programming cable on the left,
you can reconfigure the 44-pin PLCC for both AM and
FM modulation. The top right of the PLCC is the anten-
na. To the right of the PLCC is the 50-MHz RF source
oscillator. The surface-mount circuit below the PLCC is
the 32-kHz data clock oscillator. Between the AA battery
pack and the 32-kHz oscillator is a 1.8-V regulator.
CoolRunner-II-Based Digital Telemetry Transmitter
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
11
cross it to a number of other vendors’
SMT products. Given the programma-
ble features of the CPLD, you might
ask why I did not use a couple of CPLD
pins as the RF oscillator. The program-
mable logic features allow the designa-
tion of two pins to act as a simple
inverter, with an ABLE equation such
as:
outputpin = ! inputpin ;.
Generally, CPLDs make poor crystal
oscillators. The reason lies in the com-
plexity of the CPLD’s I/O structure. Each
pin has a variety of options for pull-up,
pull-down, and input voltage selection,
which is a configuration the designer
sets up via the WebPACK design tools.
For the lowest power operation of
40 µA (to extend battery life), and to
have a product that can take some
rough handling in the field, the global
pull-up is required. CPLD crystal oscil-
lators won’t work with this designa-
tion, because the weak current pull-up
doesn’t allow the input to float midway
between the power supply and ground
potential, and the oscillator can’t start.
Moving on, I’ll consider the specifics
of the external RF oscillator.
To improve operating speed, IC3 is
powered from the battery voltage, which
can range from a maximum of 3.6 V to a
minimum of 2 V. (This range is set by
the I/O voltage limits of the CPLD.)
Also, having this oscillator on a separate
voltage from the low-frequency crystal
oscillator improves the noise immunity
of the lower frequency data clock by
keeping any RF-induced transient pulses
from directly affecting the 1.8-V power
line. They would have to go through the
1.8-V regulator circuit (U4) and another
set of decoupling capacitors (see Figure 2).
(Well, it’s true that the complete circuit
actually requires four ICs, but because
the regulator is not inside the wireless
data loop that I’m considering, does it
really count as part of the wireless
data circuit?)
GATED CRYSTAL CLOCKS
This RF source circuit, which is
also shown in Figure 1 and built with
NAND logic, is a classic example of a
gated digital crystal oscillator. There
were two main reasons why I used a
gated oscillator in this application. First,
the power draw of the circuit increases
fiftyfold when the RF oscillator is run-
a variety of transmission protocols and,
when not transmitting the modulated
RF carrier, sips power at 40 µA when
clocked at 32 kHz.
Also, the Coolrunner-II toolset is free.
Xilinx WebPACK includes design cap-
ture, HDL logic processing, JTAG pro-
gramming, and, if you register, HDL-
based timing simulation. However, if
you don’t have a standard JTAG-to-PC
parallel port programming cable,
which is necessary to configure the
CoolRunner-II CPLD, you’ll be set back
approximately $100.
By the way, the logic reduction capa-
bilities of the toolset gives the 64-macro-
cell version of the CoolRunner-II
(XC2C64) the ability to store more
than 128 bits (organized as four blocks
of 32-bit data) of ID information,
which can provide a simple yet power-
ful way to communicate change-of-
state information with almost no
uncertainty at the receiver. But that
explanation will wait until error cor-
rection codes (ECC) are taken into
consideration later in this article.
Given that the design is going to gener-
ate a strong RF signal, the next step in
building a reliable wireless data transmit-
ter is a stable data clock. Although gener-
ating a good low-frequency data clock
usually isn’t too difficult with a line-pow-
ered supply, building low-power transmit-
ters that run from a 12-mAh watch bat-
tery is a different story. For my remote
telemetry applications, the only way to go
is to use a Schmitt trigger oscillator for
the source data clock. This logic type will
provide the noise immunity to prevent
RF glitches from mixing in with slower
data clock pulses, a feature that’s especial-
ly important with a fast device like the
CoolRunner-II that responds to input
clocks shorter than 10 ns wide.
In this design, the data clock source,
U2, is National Semiconductor’s
NC7SZ14 (see Figure 1). The actual
prototype circuit (see Photo 1) has this
32-kHz oscillator in the lower center
section of the image (below the 44-pin
PLCC version of the XC2C64
CoolRunner-II CPLD). I mounted the
low-frequency oscillator on prototype
SMT boards (Surfboards from Digi-Key).
Furthermore, because smaller component
sizes reduce RF pickup, the production
version of the design uses the SC-70
package, which has the P5 extension.
Data clock stability has many aspects.
For frequency stability over temperature
and small size, a 32-kHz watch crystal is
ideal. These low drive crystals are influ-
enced by lead inductance, and surface
mount assembly is a must for consistent
operation. Even on the prototype circuit,
I use 0603-style SMT packages for all pas-
sive components. These crystals also
require high-impedance feedback; there-
fore, R1 is 10 M
Ω
, and capacitors C1 and
C2 are 5 pF. R2, with a value of 1 M
Ω
,
matches the NC7SZ14 drive impedance
to the 32-kHz crystal’s internal imped-
ance. Without this resistor the circuit
will likely oscillate at an odd harmonic
of the crystal frequency, which may
change over supply voltage and tempera-
ture. Without the crystal attached, the
R-C Schmitt trigger oscillator will oper-
ate at approximately 8.5 kHz, which is a
nice feature because it simplifies opera-
tional testing during quantity production.
The third IC in the trio is used for
generating the base frequency for the
RF carrier. I built it with the fastest sin-
gle NAND gate IC family that’s readily
available, the TC7SZ00. Although
Toshiba manufactures the part, you can
Figure 1—
An extremely similar digital oscillator design
with crystals can be used for both low- and high-fre-
quency clock generations. The differences are that U2
is a Schmitt trigger that provides noise immunity, and
U3 is a NAND gate that creates a restartable oscillator.
12
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
ning. Second, the oscillator causes signif-
icant interference, especially in the pro-
totype form, to other data transmitters,
and a gated clock allows a simple time-
sharing of the transmission frequency
band. Timesharing in this context means
the data transmitter is on briefly and
then shuts off (i.e., a low duty cycle,
which conserves battery power).
Other assembly techniques help
when building prototype oscillators.
Keeping the feedback connections as
close as possible, bypassing the power
near to the IC body, and using SMT
passive components for C3, C4, and
R3 in the 0603 case give reliable start-
up and stable frequency generation.
These considerations usually keep the
oscillator’s start-up time under 25 ms.
The reason the oscillator start-up
time has to be considered in the data
transmission logic is that the frequen-
cy and power of the transmission
won’t be equal over the data transmis-
sion time. (For my designs, the time is
typically 125 ms with a 512-Hz data
clock.) Without the delay, data errors
may result that could reduce the
chance for correct reception of the
wireless data at the receiver.
The configuration of the prototype
circuit helps to illustrate the integra-
tion of these logical, electronic, and
physical considerations. Photo 1 illus-
trates the way I assembled the proto-
type for the data transmitter using sur-
face-mount prototype boards and wire
wrap wires for major circuit block con-
nections. The surface-mount circuit in
the upper right corner is the RF source
oscillator, which I constructed with a
50-MHz, third overtone Epson CA-301
quartz crystal (Digi-Key SE3455).
The RF source oscillator shown in
Figure 1 operates reliably with all CA-
301-type quartz crystals, both funda-
mental and third overtone, for frequen-
cies ranging from 4 to 60 MHz. However,
note that in the RF spectrum, frequency
accuracy is often closely linked to the
physical layout. The prototype RF source
oscillator in Photo 1 actually operates
at 50.083 MHz, which is almost a 0.2%
shift from its specification.
Considering the passive parts in the
RF source oscillator, what function
could the 0-
Ω
R4 perform? As you
likely guessed, R4 will help you fix
the shift in frequency, again by match-
ing the output impedance of the driver
(TC7SZ00) to the crystal in the cir-
cuit. I specifically used the phrase
“crystal in the circuit” because all of
the factors of layout, IC and passive
component packages, and even the
weather have some influence on a
quartz crystal’s oscillation frequency.
The prototype version of the design
uses the SOT-23-5 package to ease
assembly. Therefore, because the opti-
mum value of R4 may vary (and I
might have to change C3 and C4 by
up to 5 pF, as well), I selected 0
Ω
as
the way to indicate that the value
might change over component and
layout variations. This frequency shift
isn’t too much of a problem if you’re
building a few data transmitters as
prototypes because the circuit stabili-
ty is quite good. It’s only a matter of
tuning the ICOM IC-R3 receiver
(which I recommend for radio recep-
tion) up or down in frequency. But for
production situations building quite a
few data transmitters, each one needs
to be right on track. When using a
range of crystal types and suppliers,
having a means to tune the source
crystal to 0.001% or better is required
depending on which part of the RF
spectrum you designate to carry wire-
less data.
Figure 2—
The core of the wireless data transmitter is U1, a 64-macrocell Xilinx CoolRunner-II, which is powered
by the 1.8-V low dropout regulator (U4).
14
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
PICK A MULTIPLIER
How exactly do you pick the wire-
less frequency for data transmission
and get the simple three-IC circuit to
transmit it? Let’s consider using a
serial datastream input and applying it
to the airwaves.
At this point, it’s clear that modulat-
ing an RF source frequency with a serial
stream of bits is one way to transmit
wireless data. Assume that IC3 oscil-
lates with a 50-MHz crystal, that source
frequency is applied to the CPLD pin as
signal RFOSC. In addition, you select as
the serial data input another CPLD I/O,
which I’m calling SERIALIN (the input
pin could be any of the unused ones, and
there’s quite a few to select from), and
program the device with the following
equation:
RFOUT = RFOSC & SERIALIN.
(The
& operation is the logical AND
function in ABEL code.)
After creating the JTAG program-
ming file with the Xilinx WebPACK
toolset and downloading it to the IC1,
the CPLD acts like an AND gate,
turning the 50-MHz RF source fre-
quency on and off. It sends that signal
to the RFOUT pin. The CPLD opera-
tion is wireless data transmission,
because the 50-MHz signal goes out
RFOUT to the antenna and through
the airwaves to the radio receiver.
Because the 50-MHz signal is continu-
ously transmitted when there’s a one
in the serial data, this type of data
modulation is referred to as “continu-
ous wave” (CW).
Photo 2—
I applied GoldWave for the waveform plot. Using a PC’s sound card to capture wireless data from an
ICOM radio receiver provides a good tool for monitoring data transmissions. Here, Goldware.exe displays a 32-bit
data chirp that represents a data ID code of 536.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
15
cuit would require, making this
design ideal for battery operation.
Given that we are most interested in
the harmonics of the RF source clock,
let’s consider how to keep this fre-
quency transmission on track as part
of the design considerations.
Small variations in the RF source
frequency can add up—or, to be pre-
cise, multiply up—when the wireless
data transmission frequency is a large
multiple of the source frequency. For
instance, the prototype circuit trans-
If you tune the receiver to 50 MHz,
you can hear the pulsed data, or see
each transition (0 to 1 and 1 to 0) of
the serial datastream. Note that the
serial data acts as if it is AC coupled
(i.e., through a capacitor), so only the
data transitions are visible. Study
Photo 2 to gain an idea of how each
data transition looks after the receiv-
er. The graph was captured using a
PC’s sound card (at 44.1 kHz). It plots
the IC-R3 radio’s audio output over
time. So far, so good. But what if
you’re interested in a 450-MHz band,
how do you generate that signal?
The answer lies in the multiplier.
Nine times a 50-MHz signal is 450 MHz.
How do you get the lower frequency
multiplied to a higher frequency?
Again, digital circuits solve the prob-
lem because they work with square
waves. Unlike a sine wave, which is a
pure tone, a square wave is the sum of
all the odd harmonics (i.e., odd multi-
pliers). So, a 50-MHz square wave the-
oretically contains the following
sequence of frequencies at each edge
transition: 50, 150, 250...
If your CPLD has output drivers
that are fast enough and can supply
enough impulse current to keep the
50-MHz edges fast, a small pulse of
RF energy is transmitted at each tran-
sition of the RF source clock. All it
takes to generate the RF for a wireless
signal is a sufficiently sharp digital
transition (0 to 1 or 1 to 0). That’s
why I started this article with the fol-
lowing idea: wireless data transmis-
sion might just as well be called mak-
ing electromagnetic interference (EMI)
work for you as digital radio.
The analogy continues, though,
because I am talking about digital
radio, which is a pulsed, not continu-
ous, transmission. Recall how the
serial datastream appeared as a set of
pulses for each data transmission.
Each transition of the 50-MHz source
clock similarly creates a pulse of high-
er frequency RF, which is what the
ICOM IC-R3 will receive if you tune
it to a higher multiplier frequency of
450 MHz. But even though the circuit
transmits at this high frequency, it
still draws power as a 50-MHz circuit,
which requires far less current than a
continuous wave 450-MHz digital cir-
mits strongly at 150.25 MHz (close to
three times the source RF frequency of
50 MHz). At the same time, if you
check a different part of the RF spec-
trum, the prototype’s transmission
strength is just above the receiver’s
noise threshold at 350.58 MHz (seven
times the source RF frequency). This
power loss, as you move higher in the
RF spectrum, is mainly the result of
the CoolRunner-II’s large 44-pin PLCC
package and the wire wrap wiring.
Because the self-inductance of a wire
16
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
increases with increasing frequency,
and because electronically you can’t
instantaneously change the current
through an inductor, longer wires load
down the CPLD’s output drivers and
slow down the edge. This reduces the
transmitted RF energy at the higher
frequencies. The Fourier components
of a square wave of frequency F are
proportional to:
[1]
Lower frequency crystals, ranging
between 7 and 20 MHz, are also useful
for generating a range of RF transmis-
sion frequencies because the first
overtone crystals generate a sharper
frequency from the RF source oscilla-
tor than the third overtone crystals.
With the production version of the
design that I customized for underwa-
ter transmission, I often use a 10.6244
(Digi-Key SE3422) crystal to generate a
transmission frequency of 148.76 MHz.
This transmission frequency is
14 times the source oscillator frequency.
1
n
nF
n = 1, 3, 5 ...
×
( )
sin
,
Therefore, the RF source oscillator’s
accuracy requirements are signifi-
cantly increased. A small shift in the
RF source clock shows up as an
error—or frequency shift—14 times
larger at the IC-R3 receiver. But, keep-
ing the circuit small helps maintain
RF oscillator accuracy.
For circuit size comparison, con-
sider the production version of the
CoolRunner-II transmitter shown in
Photo 3. The main portion of the cir-
cuitry is just slightly larger than the
pink eraser on your standard Dixon
Ticonderoga pencil. And, with a 50-MHz
crystal, the circuit transmits accurately
(without the adjustment of R4) at
150.00 MHz. Only at the eighteenth
harmonic (50 to 900 MHz) does the lim-
itation of the crystal accuracy begin to
crop up with a variation of 0.02 MHz.
What’s more, the microBGA package
size of the CPLD, IC1, has a significant
influence over the range of frequencies
available for the circuit’s wireless data
transmission. That’s because the tiny
version of the circuit is capable of gen-
erating a strong RF signal for room use
even in the 2.4-GHz spectrum.
The RF characteristics of the CPLD
tend to spread the frequency range
because of internal drivers and con-
nections. Thus, even multipliers of 10,
12, 14, and higher are usually able to
generate a strong RF signal, which is
another unanticipated feature of the
programmable logic device. But this
frequency extension occasionally
works to your disadvantage too,
because some odd multipliers are
attenuated internally.
Testing is the best way to optimize
the selection of source oscillator fre-
quencies and the multiplier that gen-
erates the band for wireless transmis-
sion. And, as the modulation of the
RF source clock becomes more com-
plex, the spacing of frequencies trans-
mitted by the CPLD expands as well.
Let’s apply a continuous low frequen-
cy to the RF source signal through the
CPLD logic to see how it works out
through the RF spectrum.
WHIR OR DATA
Next, I’ll show you how to use the
low-frequency data clock and the RF
source clock to create a variety of RF
modulations. The technique you’ve
seen so far—where the designer
selects a frequency band and develops
CPLD logic to modulate its amplitude
with a serial datastream—is the famil-
iar amplitude modulation (AM). With
the data clock running at 32.768 kHz,
a simple divide-by-64 counter gener-
ates a 512-Hz data clock. It’s then
used to modulate the RF source clock,
which, in this example, is running at
10.6244 MHz. Listing 1 shows the
ABEL code for the operation that I
programmed into in the production
version of the CPLD board (like the
one in Photo 2).
On the receiver side, the IC-R3 audio
speaker sends out a loud whirring sound.
Setting the IC-R3 to AM reception at
148.76 MHz and selecting its bandscope
function with a sweep range of 5 kHz
generates the display shown in Photo 4.
The vertical height of the bar represents
the signal level at each frequency step.
Listing 1—
This is the complete Abel code for continuous AM/FM transmission at 512 Hz.
module microRFtone
title ' Micro ID-RF ' //BGA pin locations noted in ''
p20 pin 20 ;
//'K2' //32-kHz clock in
rft pin 44 ;
//'F1' //RFTransmit
hin pin 42;
//'E1' //RFOSC
p19 pin 4;
//'G10' //RFEnable
s0,s1,s2,s3,s4,s5 node ;
scale = [s5..s0] ;
equations
p19 = 1 ;
//RF on
rft = hin & s5 ;
//Modulate RF source with 512-Hz tone
scale := scale + 1 ;
//Divide by 64 counter
scale.clk = p20 ;
end
Photo 3—
To illustrate just how small you can make a
stand-alone wireless data transmitter, the circuit board
just below the pencil contains all the circuitry in the
hand-wired prototype. Because of the small size of the
circuit board layout, this design is capable of transmit-
ting RF data from 1 MHz up to 2.4 GHz, depending on
the RF crystal (which is the larger of the two) that you
select. Below the circuit board is the encapsulated
waterproof version that contains a battery and an iden-
tical circuit board to the one above it (except the pro-
gramming edge connector is trimmed off).
ful for data, has a 24-kHz bandwidth
(i.e., 148.76 MHz
±
12 kHz) and a wide
FM (WFM) mode that corresponds to
your standard analog FM tuner with a
150-kHz bandwidth. By the way,
many commercial radios (e.g., the
ICOM IC-R10, which is a less expen-
sive receiver than the IC-R3) offer two
more reception modes, lower side
band (LSB) and upper side band (USB).
These two bands correspond to sub-
tracting or adding the frequencies and
then using output filtering to remove
the upper or the lower—just as pre-
dicted by the Fourier theory.
Any type of wireless transmission
will be subject to noise, which may
result in transmission errors. By
adding extra bits to the serial data
transmission, it’s possible for data pro-
cessing at the receiver to detect bit-
level errors and correct them.
Although you might build the encod-
ing logic into the CoolRunner-II oper-
ations, I prefer to work out the codes
in advance and then assign a complete
data word, including four synchro-
nization bits, a 14-bit ID value, and a
14-bit correction code into a single
32-bit (4 + 14 + 14) ID code.
Building upon the features of the
CoolRunner-II and the WebPACK
design tools, it’s possible to store four
ID codes of 32 bits in length in the
CPLD logic and still have room for
the timing and control logic, which
makes a complete, stand-alone data
transmitter. Rather than using only
AM encoding for the ID code trans-
mission, the 512-Hz data clock is
ANDed with the serial ID code to cre-
ate a self-clocking code. What this
means is that two pulses represent a
one and no pulses represent a zero.
Photo 2 illustrates the transmission
of the 32-bit word, which represents
an ID value of 536. By processing this
code at the receiver, not only is the
error-correction code (ECC) capable
of determining if there are errors, but
it also can correct up to three bit
errors. And, most importantly, the
reliability of the ECC algorithm is a
million to one.
ANTENNA LENGTH
One more theoretical point, center-
ing on wave mechanics, will help you
Given that there are 20 bars for a 5-kHz
display, each horizontal bar represents a
frequency step of 250 Hz. Rather than
seeing just a single bar at 148.76 MHz, a
range of bars is shown. This display
illustrates how the modulation of a
higher frequency by a lower frequency
actually causes a frequency spread in the
RF spectrum. This type of response is
predicted by the Fourier theory, which
defines how two frequencies interact by
adding and subtracting the frequencies
in the RF spectrum.
Given that the higher frequency of
148.76 is amplitude modulated by the
lower frequency of 512 Hz, Fourier pre-
dicts that the actual spectrum output is
the sum and difference of the frequen-
cies (i.e., 148.76 MHz – 512 Hz and
148.76 MHz + 512 Hz). The IC-R3 AM
bandscope display shows this operation.
Interestingly, if you shift to frequen-
cy modulation (FM) reception on the
radio, the audio signal reception is the
same. Despite the fact that the CPLD
uses square waves and the Fourier the-
ory applies to pure tones, or sine
waves, a similar spectral response
results. Digitally modulating the car-
rier with a lower frequency clock cre-
ates a frequency-modulated signal.
The IC-R3 radio offers two types of
FM reception. The first, which is use-
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
17
Photo 4—
One nice feature of the ICOM IC-R3 radio
receiver is the bandscope function, which scans a
range of frequencies and plots the signal intensity. Set
for AM reception at 148.76 MHz, the bandscope shows
how a modulation frequency of 512 Hz spreads the
spectrum of the 148.76-MHz carrier.
18
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
optimize the transmission of the
radio signal from the CPLD circuit:
selecting the correct antenna length
for a single wire. By changing the
physical size of the antenna, which
connects to C5 on the circuit, you
can roughly adjust the amount of
energy that the CPLD pours into
each spectral band.
As an engineering approximation,
if the antenna wire is at least one-
quarter the wavelength of the wire-
less frequency being transmitted by
the CPLD, the antenna will efficient-
ly output that frequency. Lower har-
monics that are one-half, one-third,
one-quarter, or less don’t transmit as
well from a shorter antenna. Also,
the higher harmonics—two, three,
four, or more times the frequency for
which you calculated the antenna
length—will be attenuated because
of the increasing self inductance of
the wire.
The following is a sample calculation
for the antenna length at 148.76 MHz
(Note that the speed of light, c, is
3 × 10
10
cm per second, so the antenna
length is in centimeters.):
Consequently, a quarter-wavelength
antenna for 148.76 MHz is equal to
50.42 cm in length (in air).
Other antenna options that can help
keep the RF energy in the spectrum that
you’ve selected are available from sever-
al manufacturers. Linx Technologies
(www.linxtechnologies.com) provides
antennas on the SMA-style mount or as
flat planar antennas (Splatch) that are
tuned to frequency bands such as 315,
433, and 916 MHz. Of course, to really
tune the output selectively, a series LC
filter tuned to the following frequency
is necessary:
I have also tested a range of LC fil-
ters, which, when tuned to a specific
frequency range, can give a roll off of
60 dB per octave. This degree of nar-
rowband frequency response usually
requires the manual selection of com-
ponents for accurate tuning.
f =
LC
2
π
c
wavelength
c
fr
= wavelength frequency
antenna =
×
1
4
e
equency
4
×
CAVEATS
For the low-power RF design pre-
sented in this article, I have not
attempt to filter the output, giving a
maximum range at all harmonics. As
you know, there is the minor influ-
ence of C5, the 47-pF output capaci-
tor, and its interaction with the anten-
na wire. Also note that because of the
RF crystal, you get an extremely spe-
cific range of harmonics, finely tuned,
from the CPLD output. And, for a
pulsed datastream (as seen in Photo 2),
the average power output becomes
even lower, averaging only one thir-
ty-second of the total continuous
output power with a 4-s spacing of
data chirps. However, the power out-
put of a 1.8-V RF transmitter is well
below 1 W, and it usually requires a
large antenna on the receiver side to
gain a reception distance beyond a
few meters.
By the way, an underwater applica-
tion of these transmitters has a great
influence on the spectrum output
because any RF harmonic above
250 MHz is greatly attenuated in fresh
water. The selection of a 47-pF output
capacitor and a 15-cm antenna matches
the impedance of water at 150 MHz
and provides the best reception range.
I
Author’s Note: Visit www.biotags.com
if you’re interested in purchasing a
wireless development kit. The kit,
which costs $75, includes a BGA ver-
sion of the radio tag described in this
article, a plug-in cable adapter, and a
documentation package that includes
schematics, circuit operating data,
and example programming files for
use with the X i l i n x W e b P A C K
s o f t w a r e .
Russ Lindgren earned a B.S. in
Engineering Science at Tufts University.
He has been designing with program-
mable logic devices for more than 21
years. Russ enjoys making specialized
communication devices that help the
environment. Some of his devices are
currently used to track fish and under-
ground materials. An avid skier, Russ
hopes to add wireless communication
to the lift tickets used in the southern
Vermont ski areas that he frequents.
You can reach him at tech@biotags.net.
SOURCES
CA-301 Microprocessor crystals
Epson Corp.
www.epson.com
NC7SZ14M5 Inverter
Fairchild Semiconductor Corp.
www.fairchildsemi.com
GoldWave
GoldWave, Inc.
www.goldwave.com
IC-R3 Data receiver
Icom America, Inc.
(425) 454-8155
www.icomamerica.com
JTAG Programming cable
Nu Horizons Electronics Corp. (dis-
tributor)
www.nuhorizons.com
S-81218SG Regulator
Seiko Instruments, Inc.
www.siielectroniccomponents.com
TC7SZ00F
Toshiba
www.toshiba.com
CoolRunner-II CPLD, WebPACK
Xilinx, Inc.
(408) 559-7778
www.xilinx.com
PROJECT FILES
To download the complete parts
list, go to ftp.circuitcellar.com/pub/
Circuit_Cellar/2004/163.
RESOURCES
Epson Corp., “Oscillation Circuit
Design Guide,” rev. B, 1993.
Fairchild Semiconductor Corp,
“NC7S14: TinyLogic HS inverter
with Schmitt Trigger Input,”
DS012135, 1999.
Seiko Instruments, Inc., “High-
Precision Voltage Regulator:
S-812XXSG Series.”
Toshiba, “TC7SZ00F, TC7SZ00FU,”
1998.
REFERENCE
[1] E. Nisley, “Multiplying, Dividing,
and Filtering,” Circuit Cellar,
issue 161, December 2003.
20
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
I
f you’re an electronics enthusiast,
sooner or later an acquaintance of yours
will request help with a problem that he’s
struggling with. He’ll ask you because
he’ll realize the solution to the problem
is “electronic”—that magic black box
stuffed with PC boards, microcontrollers,
components, and blinking LEDs. It hap-
pened to me, and that’s how I came to
build a GPS-based vehicle tracker. In this
two-part series, I’ll show you how I did it.
THE DILEMMA
Not too long ago, an electrical contrac-
tor friend of mine asked for my advice
concerning a situation his company was
facing. As he started describing his dilem-
ma, my mind was already selecting the
microcontroller, software language,
power solution, and all the bells and
whistles that the little marvel would
need. At the time, my friend was
involved in the installation of cellular
sites, mainly power services and
tower work. The sites were usual-
ly finished before the local hydro
company would run power to the
buildings so portable power genera-
tors were used to bring the sites up
for testing. The generators, which
are powered by V6 motors, were
pulled like trailers to the different
job sites. Sometimes the generators
were used for days while every-
one waited for hydro to hook up.
That’s when my friend’s prob-
lems started. Three of his gen-
erators were stolen from the
job site.
and the important information (lati-
tude/longitude) could be extracted and
converted into speech, my friend could
use a cell phone to listen to the message
with the critical information. There
would be no need for a computer inter-
face because the information would be
received as a spoken message over a cell
phone. The information also would be
passed on to the police so the stolen
property could be recovered and the
thieves brought to justice. It sounded
like a plan, so I started working.
FIRST THINGS FIRST
There are usually a million deci-
sions to make when starting a new proj-
ect, so you should prioritize them and
start from the top. I needed the vehicle
tracking system as quickly as possible,
so I didn’t have time to build a micro-
controller board from scratch. I also
needed off-the-shelf building blocks. I
wrote the software in a higher
language to speed up the code
writing and debugging processes.
Finally, I decided to make the
device user friendly so that a
nontechnical person could under-
stand and operate it. (You don’t
have to set up COM ports, null
cables, data rates, and parity.
There’s no PC either.)
This project requires several
important pieces of hardware. The
GPS module allows you to receive
satellite information (i.e., lati-
tude/longitude position and speed).
I went with the Garmin GPS LP
Wireless Vehicle Tracking
FEATURE ARTICLE
by Ken Merk
Part 1: System Basics
My friend tried different things to pre-
vent this. He would take the tires off his
trailers, chain them to trees with special
locks and chains, and position the gener-
ators where they would be difficult to
access. All of these precautions failed,
which caused the insurance company to
stop further coverage on his equipment.
My task was to come up with some
way to stop this from happening.
THE SOLUTION
The plan was to use GPS technology
to track the equipment by sending back
the latitude and longitude information
to pinpoint its location. I wanted to use
a cellular transceiver as the wireless
link between the target and the user.
I knew that the GPS data (NMEA0183
string) could be sent and displayed on
a PC with moving map software, but I
wanted a simpler user interface. Because
the NMEA0183 string could be decoded
Photo 1—
The vector board was used to mount the rest of the components.
The top module is the CVDM-3 cellular transceiver; below it is the Garmin
GPS. Coax RF cables route radio signals to the front-panel connectors.
Ken developed a GPS-based wireless tracking system in an effort to help an electrical con-
tractor keep tabs on the whereabouts of his mobile power generators. In the first part of this
series, Ken describes the hardware components and how to mount them on a PCB.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
21
uploaded via the serial port to
the flash memory disk. Your pro-
gram will run automatically at
power-up. Note that the Flashlite
SBC is also designed to piggy-
back on a system controller
board via header connectors.
A PCB motherboard mounts
and ties the components togeth-
er. APCircuits made my proto-
type board (see Photo 3).
HARDWARE CONTROL
After collecting all of the
hardware, I had to choose the
appropriate software. I went
with the Forth programming
language on the Flashlite SBC
because it gets this project up
and running faster than any
other language.
With Forth you simply make small
subroutines—which perform all of the
low-level nitty-gritty stuff like bit bang-
ing, creating read/write strobes, I/O hand-
shaking, etc.—and assign them names.
These words are called “primitives.”
They can be coded in assembler for speed
or in Forth itself. The words are stored in
25 series because its compact pro-
file and shielded circuitry make it
easy to embed. The GPS25, which
has 12 channels, uses an RS-232
port to talk to the outside world.
A cellular transceiver sends
you the GPS data (speech). I used
a CVDM-3 cellular voice and
data module to supply the needed
wireless link (see Photo 1). The
CVDM-3 is a 3-W transceiver
using the AMPS network. A host
controls the module through a
9600-bps RS-232 port. A special
protocol, which is called PDI, is
used to answer and originate calls.
GUI software (CellAssist) is also
available to assist with applica-
tion development (see Photo 2).
A V8600A text-to-speech voice
synthesizer translates GPS data to speech.
Basically, it converts plain English ASCII
text into a high-quality male voice. Note
that it is designed to piggyback on a sys-
tem controller board via two 12-pin
headers, and is easily interfaced to any
microcontroller parallel bus.
A JK Microsystems Flashlite-V25 SBC,
which is based on the NEC V-25 proces-
sor (8086-compatible), controls the
show and does all of the housekeeping
(see Figure 1). The SBC runs on 5 V,
and it has 20 parallel I/O lines and
512-KB SRAM and 512-KB flash memory.
The flash memory is configured as a
disk drive controlled by an on-board
DOS. Applications can be written on a
PC, compiled into .EXE format, and
Figure 1—
The Flashlite SBC is a workhorse with plenty of I/O to control all of the tracker’s components. The GPS and CVDM-3 cell transceiver are controlled through a
shared RS-232 port. The rest of the components are controlled through parallel I/O lines. The power supply input to the tracker is reverse-polarity and over-voltage-protected.
A DC/DC converter supplies all of the 5-V components and gives some isolation from the harsh vehicle power environment.
Photo 2—
CellAssist is a GUI user interface software program that allows
you to work all the features of the CVDM-3 cellular transceiver. This pro-
gram
configures the cell phone with its phone number ready for activa-
tion with your cellular provider. With the supplied headset, you can make
calls using CellAssist. For development purposes an on-screen protocol
analyzer is available to monitor PDI packets between the host and CVDM
module. This will help you understand the rules of the PDI protocol for code
22
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
a dictionary and executed by typing them
on the keyboard command line.
The ability to execute any word by
itself and see the results is like having a
built-in debugger. After the words are
debugged and work as desired, you can
forget about the code that makes them
and use them as building blocks for
higher-level words. Any defined word
can be used to build other words. Picking
words that best describe your application
makes the code easy to read and follow.
Debugging becomes easier as new
words are constructed using other
pretested words. Continue building
until you have one main word that
becomes your application (hence the
term “threaded code”).
There is no distinct line where Forth
ends and your application begins. It all
becomes one, and your application
becomes part of Forth. You are basically
creating your own application-specific
computer language.
OPERATION
Before you can start writing software,
you need a clear understanding of how
the vehicle tracker operates. The tracker
is installed on a vehicle that you want
to monitor. A GPS antenna, cellular
antenna, and 12-VDC power source are
the only external components necessary
for complete installation (see Photo 4).
A simple phone call to the unit acti-
vates a voice message that gives the
vehicle’s positional data. A tripped
alarm status occurs when the GPS
detects the vehicle’s movement. The
tracker dials a preprogrammed num-
ber and the voice message is activated.
The voice message includes the fol-
lowing: the alarm status (i.e., Armed,
Tripped, or Canceled), latitude/longi-
tude coordinates, and the vehicle’s
status (i.e., moving or stationary);
speed (km per hour) and bearing (from
true North); the number of satellites
in use; the link status to the satellites
(i.e., good data or no data); and vehicle
identification (e.g., “Unit #123”).
If the GPS receiver loses the commu-
nications link with the satellites, the
last-known location is transmitted in
the message. The vehicle tracker pow-
ers up in Armed mode. When the GPS
detects movement that’s faster than
8 km per hour, the vehicle tracker
attempts to call the preprogrammed
number. If the call does not make it
through (e.g., the line is busy or there’s
no cell coverage), the cell phone stays
active for 5 min., hangs up, and tries
again 1 min. later. The cell site might
dump the call before the 5-min. period
is up. This continues over and over
until the call gets through.
If the call gets through, the talking
message will indicate a tripped alarm. To
cancel the alarm, press the zero button
for 3 s. Press the one button for 3 s to
rearm the unit. The talker board will
indicate the state of the alarm. The
message can be monitored over the
phone for 5 min. before the cell hangs
up. This prevents unauthorized callers
from locking up the alarm system and
restricts the calls to answering
machines. To continue monitoring the
message, call the vehicle tracker and con-
tinue on for another 5 min.
If someone is monitoring the vehi-
cle tracker’s messages in Armed mode
and the GPS detects movement, the
call is canceled and the tracker calls
the preprogrammed number. This
ensures that the preprogrammed num-
ber will be called if an outside user is
monitoring the messages at the time.
To stop the vehicle tracker from
calling out, the alarm status must be
set to Canceled mode. If the alarm is
left in Tripped mode and you hang up,
the vehicle tracker will call the prepro-
grammed number after 1 min. Setting
the alarm to Canceled mode acknowl-
edges that someone has received the
call and the voice message.
TROUBLESHOOTING
A few special features have been
embedded in the system to help trou-
bleshoot the hardware. The vehicle
tracker has a connector into which
you can plug in a speaker and monitor
the voice message (see Photo 5).
A Test button is used to force the
tracker into Diagnostic mode. Holding
the Test button during power-up forces
the unit into Test mode, which causes
the talker board to speak its message
continuously. In Test mode, move-
Photo 3—
A prototype motherboard was made to
mount the Flashlite SBC, which is the board on the left,
and the talker board, which is on the right. The 10-pin
header in the top-right corner is the connection for the
RS-232 console port. This is connected to a PC for
uploading software and development/diagnostic pur-
a)
b)
Photo 4a—
I installed a low-profile MaxRad cellular
antenna on my 1999 Ford Windstar, which I used as a
test vehicle. This type of antenna can be easily mounted
in other locations where it would be less visible.
b—
The
GPS patch antenna has a built-in pre-amp that is pow-
ered by the GPS module through the coax cable. The
antenna is visible in this photo, but it can be mounted
under the plastic wiper cowling keeping it out of sight.
Photo 5—
After you slide the boards into the enclo-
sure, the end plates lock them in place. This makes for
a clean installation. The two pins in the center of the
power connector are for the speaker hook-up, which is
used for monitoring the voice message in Test mode.
The small hole in the bottom-left portion of the face-
plate is the push button that forces the tracker into
Test mode if held in on power-up. (The aluminum box
is a free sample from XTech. Thanks guys!)
24
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
ment will not be detected and the sys-
tem will not trip. The vehicle can be
driven while listening to the voice
message. To cancel Test mode, turn off
the power and then turn it back on.
If the Test button is pressed after
power-up, it forces a tripped condi-
tion, and the vehicle tracker calls its
preprogrammed number. This way,
you can test the cellular link without
moving the vehicle.
An LED on the circuit board indi-
cates when the unit is talking.
Another LED indicates valid DTMF
tones received from the cell phone.
The Flashlite SBC board has an
RS-232 console port that’s used to
upload software to its flash memory
disk. When the vehicle tracker is in
use, the port can be used to monitor all
GPS and cellular activity. All the infor-
mation that the talker message con-
veys is sent out of this port as text.
Raw GPS NMEA0183 strings can be
viewed in real time, and the data sent
to and from the cellular CVDM-3 mod-
ule (PDI protocol) can be monitored.
PDI CELL INTERFACE
The operation of the CVDM-3 cellu-
lar transceiver is controlled through a
two-wire RS-232 interface using a pro-
tocol called packetized data interface
(PDI). The PDI is a method of passing
data back and forth from a host to the
CVDM. PDI features guaranteed deliv-
ery through the use of acknowledg-
ments and periodic resending. The data
is error-checked via a 16-bit CRC with
byte stuffing in order to identify the
beginning and ending of packets, and to
keep the packet boundaries in sync.
All packets start with a start of pack-
et (SOP) D1 hex and end with an end of
packet (EOP) DF hex. If the data in the
packet contains an SOP, EOP, or STF,
an STF (byte-stuffing byte) DE hex will
precede it. This ensures that SOP and
EOP are not falsely detected. The STF
byte is not included in the CRC cal-
culation. If the packet-decoding soft-
ware receives an STF, the next byte
received becomes the actual valid
data byte and is included in the CRC
calculation. If the EOP and SOP are
received without a preceding STF,
then it is a valid packet boundary.
An SEQ field keeps track of the
Listing 1—
With this code, you can create and set up the timers that you need.
\ PDI software timers
variable stime1 0 , \ Tx Retry timer
variable stime2 0 , \ Tx Ack failed timer
variable stime3 0 , \ Rx Inactive timer
variable stime4 0 , \ Originate to conversation timer
variable stime5 0 , \ Offhook timer
: Txretry.reset \ Reset every time a packet is sent
gettime T>B \ On time out another packet would be sent
stime1 2! ; \ Get DOS time (HM SH) and change to binary
\ Store binary double number in stime1
: TxAck.reset
gettime T>B \ When a packet is sent, an Ack is expected
stime2 2! ; \ Times out when an Ack is not received
\ within 3 s.
: Rxinactive.reset \ Reset when a valid packet is received
gettime T>B \ If expires, it indicates that the PDI
stime3 2! ; \ link is no longer active.
: Call.reset \ After call is made this timer is started
gettime T>B \ Expects a connection before it times out
stime4 2! ; \ Indicates call failure after 60 s
: Offhook.reset \ Times the cell call
gettime T>B \ Restricts call time to 5 min.
stime5 2! ;
: Reset.all \ Reset all timers
Txretry.reset
TxAck.reset
Rxinactive.reset
Call.reset
Offhook.reset ;
: B>10TH \ Change binary time to tenths of second
0 100 UM/MOD drop
10 UM/MOD NIP ;
: Txretry.elapsed \ Timer1 elapsed time in tenths of second
gettime T>B \ Get current DOS time in binary
stime1 2@ \ Last binary DOS time
4dup du<
IF 5947 15203 T>B 2SWAP D- D+
ELSE D-
THEN B>10th ;
: TXack.elapsed \ Timer2 elapsed time in tenths of second
gettime T>B \ Get current DOS time in binary
stime2 2@ \ Last binary DOS time
4dup du<
IF 5947 15203 T>B 2SWAP D- D+
ELSE D-
THEN B>10th ;
: Rxinactive.elapsed \ Timer3 elapsed time in tenths second
gettime T>B \ Get current DOS time in binary
stime3 2@ \ Last binary DOS time
4dup du< \
If current is larger than last = midnight X
IF 5947 15203 T>B 2SWAP D- D+ \ midnight cross
ELSE D- \ no midnight cross
THEN B>10th ;
: Call.elapsed \ Timer4 elapsed time in tenths of second
gettime T>B \ Get current DOS time in binary
stime4 2@
\ Last binary DOS time
4dup du<
\
If current is larger than last = midnight X
IF 5947 15203 T>B 2SWAP D- D+ \ midnight cross
ELSE D- \ no midnight cross
THEN B>10th ;
: Offhook.elapsed
\ Timer4 elapsed time in tenths of second
gettime T>B \ Get current DOS time in binary
stime5 2@ \ Last binary DOS time
4dup du< \ If current is larger than last = midnight X
IF 5947 15203 T>B 2SWAP D- D+ \ midnight cross
ELSE D- \ no midnight cross
THEN B>10th ;
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
25
Send/Ack handshaking, which
ensures packet delivery, pack-
et ordering, and flow control.
All packets start with D1 and
end with DF. The second byte is
the SEQ field. Only the lower
nibble is used. Bits 0 and 1 make up the
Ack Seq field. Bits 2 and 3 make up the
Send Seq field. When a connection is
first established between the CVDM
and host, the sequence numbers are
both reset to zero.
SEQ Field ---> XXXX 01 11 Ack = 3
Send = 1
A packet must be sent regularly to the
CVDM in order to keep the PDI link
active. Any type of packet will do. An
idle packet can be sent if there’s nothing
else to send. The PDI will time out if no
packet is sent within 3 s. If a packet is
sent every 2 s, the PDI will maintain the
link. To send a new data packet, the Send
Seq must be incremented. After the data
packet is sent, a return packet will arrive
from the CVDM with the Ack Seq equal
to the sent Send Seq. When this happens,
you’ll know the data packet has arrived
and has been accepted by the CVDM.
If a corresponding Ack Seq is not
received, the message will be transmit-
ted continuously until a proper response
is received or a timeout occurs. To keep
the PDI link active when no new data
packets need to be sent, idle packets can
be used. Incrementing the Send Seq is
not required when idle packets are sent.
If you receive a packet from the
CVDM with the Send Seq incremented,
it indicates a new packet. You must
send a packet with the Ack Seq equal
to the received Send Seq. This must be
sent within 3 s to keep the link active.
If the host does not keep the PDI link
active, the CVDM will shut down the
PDI link and no other messages will
be received from the CVDM.
In order to regain the PDI link, the
host must initiate the PDI activity. This
can be as simple as sending an idle pack-
et to the CVDM or a valid command.
The host and the CVDM must adhere to
the aforementioned rules to keep the
link between them active. The host
software must monitor the exchange
of packets to ensure these rules are
not broken. You must incorporate
timers in software to maintain proper
packet protocol.
The Tx Retry timer is required to con-
trol the resending of packets to the
CVDM. This timer is reset every time a
packet is sent to the CVDM. When the
timer expires, another packet is sent.
The timer is set to 2 s, which
keeps the CVDM from timing
out. The Tx Retry timer is the
only timer allowed to expire.
When a packet is sent to the
CVDM, an acknowledgement is
expected within 3 s. The Tx Ack Failed
timer monitors this parameter. If the
timer expires after 3 s, the host assumes
the packet wasn’t successfully deliv-
ered to the CVDM.
A third timer is needed to deter-
mine if the PDI link is still active.
SOP
SEQ
CMD …DATA (may contain byte stuffing)… CRC
EOP
1 byte 1 byte 1+ bytes
0+ bytes
2 bytes 1 byte
Figure 2—
T
he PDI packet format is used to communicate with the CVDM-3
module.
26
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
The Rx Inactive timer is reset every
time a valid packet is received. If this
timer expires, it indicates that the PDI
link is down. This timer is set to 3 s.
Listing 1 shows you how to create
and set up the timers you need in soft-
ware. The Flashlite SBC runs an on-
board embedded DOS, which has a sys-
tem tick timer running in the back-
ground. The tick timer and its interrupt
occur 18.2 times per second, which
updates and maintains the DOS clock.
You can create and use as many
timers as you want. Listing 1 shows you
how to create the Tx Retry timer. First,
create a variable
stime1 for storage pur-
poses. The word
Txretry.reset gets
the current DOS time (
gettime), con-
verts it to binary
T>B, and stores it in
variable
stime1 (stime1 2!). This
resets the timer and timing begins.
When you want to see how much time
has elapsed since the reset, use the word
Txretry.elapsed. This words gets the
current DOS time, converts it into bina-
ry
gettime T>B, fetches the time stored
in
stime1 (stime1 2@) when the timer
was reset, and subtracts the two values
D-. The result is converted to tenths of a
second (
B>10th). Getting a value of 35
indicates 3.5 s. Two extra timers
Call
and
Offhook were also created to detect
a call failure and to restrict the tracker’s
airtime to 5-min. blocks.
Take a look at Figure 2. The com-
mands in the Command field (CMD)
are used to send and receive cell phone
calls. The CMD field can be 1 or 2 bytes
long, indicating the type of message.
The first byte is the “primary type,”
which all messages have. It indicates a
group of commands that have a com-
mon function. The second byte is the
“secondary type,” which defines the
parameter of each command.
Depending on the command field
that’s sent, you can do the following:
originate calls (20 01), answer calls
Ken Merk is an electronics technologist
with a degree from The British
Columbia Institute of Technology. He
currently works for Canadian Pacific
Railway, where he is involved with
radio-controlled locomotives. Embedded
PROJECT FILES
To download the code, go to ftp.
circuitcellar.com/pub/Circuit_
Cellar/2004/163.
SOURCES
PCB Prototype
APCircuits
www.apcircuits.com
CVDM-3 Cellular transceiver module
CSI Wireless
www.csi-wireless.com
GPS25-LVS GPS Module
Garmin
www.garmin.com
Flashlite-V25 SBC
JK Microsystems
www.jkmicro.com
FUGAWI Moving map software
Northport Systems, Inc.
www.fugawi.com
V8600A Text-to-speech synthesizer
RC Systems
www.rcsys.com
F-PC Forth V. 3.60
Tom Zimmer
www.forth.org
RS-6030 Extruded aluminum enclo-
sure
Xtech, Inc.
www.extrutech.com
RESOURCES
Garmin, “GPS 25 LP Series
Technical Specification,” 190-
00125-00 rev. E.
JK Microsystems, “Flashlite User’s
Manual,” doc. part no. 98-0001,
November 1996.
Wireless Link Corp., “CVDM-3 PDI
Interface Specification Manual,”
rev. 3.1, April 1998.
(20 02), disconnect calls (20 03), set
audio receive volume (20 05), transmit
DTMF tones (20 07), call processing sta-
tus (20 08), and idle (01 --). As you can
see, the primary type 20 handles call
processing. An idle packet is an example
of a CMD field with 1 byte. The primary
type contains 01.
The Data field contains data needed
for the appropriate CMD. For instance,
to originate a call using the phone
number 1-800-123-4567, the packet
would consist of the following: 20 01
18 AA 12 34 56 70 00 00. The Data
field would contain the phone number.
Note that the hex value “A” replaces
the digit “0,” and “0” terminates and
pads the end of the phone number.
The CRC field is a 16-bit CRC-CCITT
that’s performed on all of the bytes in
the packet. It starts from the SEQ field
and ends with the last data byte.
LOOKING AHEAD
So far, I have described all of the nec-
essary hardware components needed to
build the vehicle tracker, demonstrated
how to mount them on circuit boards,
and explained how they are installed in
an aluminum enclosure (see Photo 6). I
used an on-board Forth compiler to
write code for communicating with
and controlling the cellular transceiver
module. Next month, I will show you
how to generate code to interface
with the text-to-speech board and GPS
module. You will learn how Forth, as a
word-based language, is suited perfectly
for speech synthesis. Furthermore, I
will show you how to tie everything
together for a working application.
I
a)
Photo 6a—
The entire assembly is ready to be fitted into an enclosure. Flat ribbon cable is used to tie the two boards
together. This makes a flexible joint so the two boards can be folded and stacked.
b—
By folding the boards together,
they can be slipped into its aluminum enclosure. Slots in the box accept the circuit boards and hold them in place.
b)
projects are his passion, and Forth is his
language of choice. Ken has been read-
ing
Circuit Cellar since the first issue
(which he still has) was published. You
may contact Ken at krem@telus.net.
regulated band in Europe, but it recently
became license-exempt. In both markets,
2.4 GHz is also license-exempt, as are
several other higher frequency bands.
In general, devices using frequencies
below 1 GHz have lower power con-
sumption and longer communication
range than devices using 2.4 GHz. They
also don’t have to worry about interfer-
ence from the now ubiquitous WLAN
and Bluetooth networks. However, the
2.4-GHz channel offers higher band-
width and greater data rates.
Although not all short-range devices
(SRDs) come equipped with hard-coded
channel-sharing procedures, they all need
to have some sort of protocol for working
in the chosen frequency band with other
devices—either other devices in the same
system or unknown devices using the
same frequency band. This is especially
important in the heavily used 2.4-GHz
ISM band. Techniques for sharing the air-
waves include time division multiple
access (TDMA), carrier sense multiple
access (CSMA), frequency division multi-
ple access (FDMA), frequency hopping
spread spectrum (FHSS), and direct
sequence spread spectrum (DSSS).
[1]
TDMA is a system by which differ-
ent devices use the medium at different
times, usually by allocating different
time slots to different transmitters.
CSMA is a technique whereby a device
first checks whether or not the medium
is available before transmitting. This
can still lead to collisions if multiple
devices are waiting for the medium to
become available, so collision avoid-
ance schemes—such as a random back
28
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
N
ot too long ago, incorporating a
wireless RF link in an electronics proj-
ect implied mastery of the mysteries of
RF electronics and layout, or the need
to incorporate a fairly cumbersome
subsystem into your design. This has
changed enormously over the past few
years with the introduction of embed-
ded modules that encapsulate the
radio’s electronics in a compact device,
which can be easily mounted on a
small part of your project’s circuit card.
The embedded RF arena is now explod-
ing with the development of new prod-
ucts. Although many small hybrid trans-
mitter, receiver, and transceiver modules
are on the market, the latest entries
include totally integrated RFICs that put
the radio on a CMOS chip with a micro-
controller, in some cases adorned with
peripherals such as ADCs, DACs, timers,
etc. These elements are intrinsically
interconnected, with signal strength,
transmit frequency, and other radio
parameters digitally accessible as proces-
sor registers, and protocols available as
subroutines or resident in the device’s
firmware. Although you may still need to
be mindful of proper antenna matching,
appropriate bypassing, zero-balancing, and
interference issues, incorporating radio
links into projects has never been simpler.
In this article, we will present a
quick snapshot of the state-of-the-art in
embedded RF devices. We’ll also discuss
an application that we built around one
of them in a wearable badge platform to
facilitate social interaction at large
events. We’ll conclude by briefly men-
tioning how we used embedded RF in a
Wearable Wireless Transceivers
It’s becoming easier to incorporate wireless RF links in electronics projects, especially when
you know how to select the proper short-range RF device. Mat and Joe first bring you up to
speed on the newest embedded RF devices. Then, they describe how such devices were
used in a series of wireless wearable platforms developed at the MIT Media Lab.
dense wearable sensor platform and
point to RFICs built around heavier pro-
tocols such as Bluetooth and ZigBee.
RF DEVICE SELECTION
Bearing in mind that the field is devel-
oping so quickly that any survey will
rapidly become dated, Table 1 compares
a range of currently available devices,
including small hybrid, multicomponent
modules, and single-integrated CMOS
chips (RFICs). Although many of the list-
ed manufacturers provide a range of dif-
ferent offerings that address various
requirements, we selected one represen-
tative product from each company. (A
longer list of manufacturers and devices
is posted on the Circuit Cellar ftp site.)
The selected devices work in the 300-
to 1000-MHz range or in the 2.4-GHz
band. The operating frequency is proba-
bly the first decision you must make
when selecting an RF device. In the U.S.,
the frequency bands 260 to 470 MHz and
902 to 928 MHz are license-exempt and
open for use, provided you transmit at an
FCC-approved transmission strength and
duty cycle. In Europe, the license-exempt
bands are centered at 433.92 and
868 MHz. The latter was previously a
FEATURE ARTICLE
by Mathew Laibowitz & Joseph Paradiso
Photo 1—
In this photograph of a functional RFRAIN
card, the wire antenna protrudes from the right.
nal at the receiver is high, it is usually
because another nearby device is trans-
mitting and the medium is busy.
Besides the RF-specific parameters, all
the standard factors for selecting any
electronic component still apply. The
power consumption is broken down into
three zones: receiver power consumed
while the chip is listening for incoming
data; standby current that’s used while
the chip is waiting for a carrier; and
transmit power that’s consumed while
sending. These devices also usually have
a Sleep mode that draws negligible cur-
rent. It is important to balance these val-
ues against the requirements of your
application. If, for example, you need
only to transmit, then just the transmit
power is important, and the expected
power drawn from the RF system is the
transmit load weighed by the transmis-
sion duty cycle. In addition, there are
Devices with different hopping sequences
can coexist on the same channel. DSSS
systems are based on spreading the signal
energy across subchannels by XORing
the data signal with a pseudorandom
spreading code. Different devices in a sys-
tem can use different spreading codes to
support multiple access, which is known
as code division multiple access (CDMA).
It is important to have a general idea of
the band-sharing scheme that will be
used before selecting your RF device. If
you are going to use a spread-spectrum
scheme or FDMA, you must select a chip
that will support it in hardware, usually
by allowing the frequency to be easily
changed in real time by the application
software. If you are going to use a CSMA
type of scheme, it is a good idea to pick a
chip with a receiver signal strength indi-
cator (RSSI) output that can be polled by
an application. If the strength of the sig-
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
29
off (waiting for a random interval to
elapse before transmitting)—are usually
implemented. The example application
described at the end of this article uses
CSMA with such an approach. FDMA
is a system whereby the frequency band
is divided into smaller subchannels that
are assigned to different devices in the
system. Devices operating with the
same subchannel cannot be in overlap-
ping physical range space.
With spread spectrum, the transmitter
rapidly jumps from subchannel to sub-
channel. In FHSS, each device can have a
different sequence of frequencies that it
follows, minimizing the probability that
two devices will occupy the same fre-
quency simultaneously and interfere.
FHSS broadcasts are difficult to listen in
on without knowing the hopping code.
And frequencies that contain interference
can be removed from the hop sequence.
Table 1—
These are the basic specifications for several currently available small-footprint, short-range RF devices. Refer to the Circuit Cellar ftp site for a longer list of manufacturers.
Chipcon CC1010
Nordic nRF24E1
RF Monolithics TR1100
RFWaves RFW102-M
Xemics XE1203
Frequency range
300–1000 MHz
2.4 GHz
916.5 MHz
2.4 GHz
433, 868, and 915 MHz
Methodology
FSK
FSK
OOK
DSSS, OOK
FSK
Maximum bit rate
76.8 kbps
1000 kbps
1000 kbps
1000 kbps
152.3 kbps
Standby power
1.3 mA
2 µA
0.7 µA
2.6 µA
1.10 mA
Receiver power
9.1 mA
19 mA
8 mA
38 mA
17 mA
Transmit power
8.9 mA at –5 dBM
10.5 mA at –5 dBM
12 mA at 0 dBM
21 mA at 2 dBM
40 mA at 5 dBM
Receiver sensitivity
–107 dBM
–90 dBM
–87 dBM
–80 dBM
–100 dBM
RSSI Output
Yes
No
No
No
Yes
Package and size
64TQFP
36QFN
SM-20H
Module
48VQFN
12 mm × 12 mm
6 mm × 6 mm
8 mm × 11 mm
11 mm × 16 mm
7 mm × 7 mm
External components
RX match, TX match, EEPROM for code,
Antenna filter, passives
None
RX match, TX match, VCO tank,
(not including antenna)
VCO inductor, crystals crystal for
frequency synth. filter, crystal
for
microcontroller
microcontroller
Comments
Integrated 8051,
Integrated 8051, power
OEM module is
Three-chip solution on
Several other chips available
hardware DES,
ratings are for RF and
recommended, which
module, built-in DSSS
OEM module available
supports frequency
don’t include MCU,
requires no external
protocol, simple
hopping, supports two supports frequency
components
interface to main
crystals for low-power hopping
processor, OEM
operation
module available
Photo 2a—
Take a look at the UbER-Badge with a cover (
a
) and without a cover (
b
).
c—
The RFRAIN daughtercard is visible at the top of the back side of the UbER-Badge.
b)
c)
a)
30
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
their chip and include all of the
required external components on a PCB
for easy integration into an application.
Recently, devices have become avail-
able that integrate both a microcon-
troller and an RF transceiver in a single
CMOS chip. Table 1 includes two such
chips: the Chipcon CC1010 and the
Nordic nRF24E1. (The rfPIC integrates
a transmitter with the processor. More
information on the rfPIC is available in
the expanded list on the Circuit Cellar
ftp site.) These chips contain a flash
ways of duty-cycling the receiver (e.g.,
some devices support power manage-
ment schemes where the device is
mainly in Sleep mode and woken up at
periodic intervals to check for the pres-
ence of a carrier signal).
It is also important to consider the
space requirements of the chip and the
ensemble of external components that
it requires, as well as any requirements
for the layout of the circuit board in
order to support the chip. Some manu-
facturers offer complete modules with
memory-programmable 8051 with a full
set of peripherals (UARTs, ADC, etc.)
on the same piece of silicon as the RF
transceiver. This reduces component
count, board space, and overall cost.
This tight integration between the RF
transceiver and the microcontroller
allows the transceiver to be controlled
by simply writing and reading 8051 reg-
isters and servicing RF-specific inter-
rupts. We recently used the Chipcon
CC1010 in the RFRAIN project
described below.
Figure 1—
The RFRAIN schematic is based on Chipcon’s reference design, which is tuned for 433 MHz. There are two choices of antennas, four LEDs, a five-way switch, and
an optional temperature sensor. The external connectors and necessary pull-up resistors are omitted for clarity.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
31
IMPLEMENTATION: THE RFRAIN
The RF random access integrated node
(RFRAIN) device was developed by the
Responsive Environments group at the
MIT Media Lab as an original part of the
Ubiquitous Experimental Research
Badge (UbER-Badge), which is a compact
platform designed to explore applica-
tions at the convergence of wearable and
social computing. The RF subsystem
developed for the badge has considerable
stand-alone utility for other projects;
therefore, it was designed as a separate
daughterboard called the RFRAIN.
Figure 1 is a schematic of the RFRAIN
board, which is assembled in Photo 1.
The board contains the CC1010, an
8-MHz crystal, a 32-kHz crystal for
low-power operations, an antenna match-
ing/filter circuit, and an inductor for the
RF VCO. In addition, it includes two
choices of antennas, a four-way selector
switch, four LEDs, and connectors break-
ing out all external I/O connections to
the CC1010. The hardware is based on
Chipcon’s reference design. The compo-
nent values for the antenna circuit and
VCO were calculated by SmartRF Studio,
which you may download from
Chipcon’s web site (www.chipcon.com).
The software on the RFRAIN board
running in the integrated microcontroller
handles the media access using CSMA
and the protocol needed for random-
access, peer-to-peer networking. It also
buffers incoming and outgoing data and
provides a serial interface to a connected
application microprocessor—although
stand-alone applications also can be
developed directly on the RFRAIN board.
The software for the RFRAIN project
was based on Chipcon’s Simple Packet
Protocol (SPP). The packet structure was
modified to increase the address space
from 8 to 16 bits, and a packet ID was
added. Chipcon’s SPP software also con-
tains code to handle acknowledgments
and retries. The retry code was removed,
because this was handled at a higher level
to support the CSMA back-off scheme.
Listing 1 includes sample code that
illustrates the transmission, retry, and
back-off protocol. This code section
resides in the main application loop and
is executed while the receiver is looking
for a preamble of a transmission. If the
receiver is not idly looking for a pream-
ble, the code is not executed.
If there is a packet to transmit,
tx_outgoing will be set and the code
will begin to execute. The first thing
that happens is that the receive signal
strength indicator is read. This detects
whether some sort of carrier is being
received. If a carrier signal is present, the
execution of this code stops, cycles
around the main loop, and then returns
to this same check. When this check
shows that the channel is empty, execu-
tion continues with a random wait. This
prevents all the devices waiting to trans-
mit on the same channel from being in
sync and colliding with each other.
If
tx_attempts is equal to zero, we
are about to transmit a new packet. If it
is greater than zero, we are about to send
a retry because a previous transmission
did not receive an ACK. If it is a new
packet, we load the packet into the trans-
mit buffer, increment the packet ID, and
set
tx_attempts to the number of
attempts that will be tried. After the
packet is loaded and ready to go, the
channel is checked again to see if it is
Listing 1—
Embedded C code is used in the main loop of the CC1010 microcontroller on the RFRAIN. This
fragment is taken from the transmission section and illustrates the CSMA scheme.
if (tx_outgoing == 1) {
//If we have a packet to send
tmp_RSSI = rfdcReadRSSI();
//Read signal strength
if (tmp_RSSI < RSSI_THRESHOLD){//Carrier sense
//No Carrier detected
halWait(rand(), CC1010DC_CLKFREQ);
//Random wait
//Check if we have more attempts to make on last TX
if (txAttempts == 0){
//No more attempts
//Load next packet from buffer
. . .
txAttempts = myRetryCount; //Reset attempts
TXI.pkid = ++my_pkid;
//INC Packet ID
}
tmp_RSSI = rfdcReadRSSI();
//Read signal strength
//Check carrier sense and that RF transceiver is not currently
//receiving a packet
if ((RXI.status == SPP_RX_WAITING) && (tmp_RSSI < RSSI_THRESHOLD))
{
//Media free
sppReset();
//Reset receiver
//Transmit packet
if (sppSend(&TXI) == SPP_TX_STARTED) {
BLED = LED_ON;
//Indicate transmission
//Transmission is interrupt drivem
//ISR will update SPP_STATUS
//Wait until status changes
do { } while (SPP_STATUS() != SPP_IDLE_MODE);
//Check transmit status
if (TXI.status == SPP_TX_FINISHED) {
//Packet sent successfully, ACK received if ACK requested
GLED = LED_ON;
//Send return code
. . .
} else {
//Packet failed, collision or no ACK
if (--txAttempts == 0) {
//No more retries
RLED = LED_ON;
//Check if there are any other packets to send
if(tx_buffer_empty()) tx_outgoing = 0;
//Send return code
. . .
} //Else a retry a will occur on next loop
}
}
//Restart receiving allowing carrier sense for next retry
//or new packet sppReceive(&RXI);
}
}
}
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
35
clear. If it is clear, we send the packet,
and wait for the ACK if requested. If the
channel is busy, we start all over again,
wait for the channel to become clear, and
perform the random wait. If an ACK is
not received, we start the loop again, but
do so without loading a new packet into
the transmit buffer, and continue until
we run out of retry attempts or an
ACK is received. Between retries we
return to Receive mode to check for
incoming packets.
The reception and transmission of
bytes in each packet is handled by an
interrupt service routine (ISR). Whenever
the RF transceiver finishes receiving or
transmitting a byte, it triggers the RF
interrupt. The ISR related to this inter-
rupt executes a finite state machine
(FSM), the code for which is shown in
Listing 2. The first function,
RF_ISR, is
the main ISR that the code vectors to
after completion of transmission or
reception of a single byte. This func-
tion invokes a callback function,
sppRFStateFunc(), which executes a
function for the particular state of the
FSM. Example FSM functions for receiv-
ing a packet are given following
RF_ISR.
Each of these functions represents a
single state in the FSM for reception. In
general, these functions store the received
byte appropriately, check if the packet is
still valid, and set the callback function to
the next state. The first state is executed
after reception of the sync byte, after
which this byte is dropped and the state
machine is advanced to the first destina-
tion address byte. After receiving this
byte, the firmware checks if the address is
the receiving node’s address or the broad-
cast address. If it is not a valid address, it
sets a flag and continues listening. It does
not stop receiving if the packet is not
intended for it; instead, it continues
receiving, and drops the entire packet at
the end. This keeps the node from trans-
mitting while the channel is active (e.g.,
another two devices are communicating).
This procedure, combined with the check
of the signal strength indicator, works
well to avoid interference.
The reception state machine then con-
tinues by receiving the lower byte of the
destination address and repeating the
check. It then receives the 2-byte source
address, the packet ID (which is used
elsewhere to determine if the packet is a
repeat transmission), the length of the
data payload, a byte containing flags, and
a CRC8 byte as a check on the header. If
the CRC8 fails, the packet is dropped and
the receiver is reset. If this check is suc-
cessful, the receiver acquires the data
payload and a CRC16 check on the data.
If the data is valid, the function checks
the flags to see if an acknowledgement is
requested. If it is, the state machine will
go to Transmit mode and begin the
acknowledgement process. If not, the
state machine returns to idle, and the
main application is notified that a new
packet has arrived.
We have written a series of similar
state machine functions for sending the
acknowledgement, sending a packet, and
receiving an acknowledgment. You may
download the code from the Circuit
Cellar
ftp site or the RFRAIN web site.
For more information, go to www.media.
mit.edu/resenv/rfrain.
HOST SYSTEMS
A wide range of applications can be
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
36
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
supported by the RFRAIN, as well as
by similar circuits hosting embedded
wireless devices. The RFRAIN was
originally developed for use in the
UbER-Badge (see Photo 2)—the latest
in a series of badge platforms devel-
oped at the MIT Media Lab.
[2]
The UbER-Badge was designed to be
worn as a digital name tag at large events
such as trade shows. In addition to the RF
link provided by the RFRAIN card, the
UbER-Badge features the following: line-
of-sight IR transceivers for face-face com-
munication, a 5 × 9 LED matrix display
capable of presenting bitmap graphics and
scrolling text that users in the vicinity
can read, a 2 × 2 brightness-controllable
blue LED matrix for indicating badge sta-
tus, a three-state pressable thumbwheel
for user input, an on-board microphone
sampled into 12 bits, a 12-bit audio out-
put, a pager motor vibrator for tactile
feedback, three on-board processors,
capacity for up to 256 MB of flash memo-
ry for storing audio or user data, provi-
sions for connecting two LCDs, and con-
nectors that mate into the stack sensor
platform and allow for the integration of
a wide variety of different sensors. (We’ll
come back to the stack sensor later.)
The RFRAIN system is used to net-
work these badges in an ad hoc, infra-
structureless way, allowing message pass-
ing, location of colleagues and points of
interest, and transfer of contact informa-
tion across a wide vicinity without the
line-of-sight restriction imposed by the IR
system, which talks only to a badge or IR
beacon that’s directly facing you. The
UbER-Badge uses the RFRAIN and its
embedded microcontroller to handle its
wireless communication (RF only). (The
IR is handled by a separate processor
mounted on the badge.) The RFRAIN
stores incoming and outgoing packets,
and it provides a simple serial interface to
the main application processor on the
badge: a Texas Instruments MSP430F149
16-bit microcontroller. More details on
the UbER-Badge can be found at
www.media.mit.edu/resenv/badge.
Wireless sensing devices are another
common use for these short-range radio
modules—which have enabled compact
sensor platforms such as the Berkeley
Motes and the Smart-Its (developed by a
European university consortium)—
through which researchers prototype sen-
Listing 2—
The finite state machine implements the reception packet in the interrupt service routine of the
CC1010 microcontroller on the RFRAIN.
*****************************************************************
//void RF_ISR (void) interrupt INUM_RF
//Description: RF interrupt service routine runs the SPP finite
//state machine.
// The packet sequence bit:
// TX: Toggle when finished (sppIntData.pTXI->status = SPP_TX_FINISHED).
// RX: The user application must examine the sequence bit.
*****************************************************************
void RF_ISR (void) interrupt INUM_RF {
INT_GLOBAL_ENABLE (INT_OFF);
INT_SETFLAG (INUM_RF, INT_CLR);
if (sppIntData.mode != SPP_IDLE_MODE) {
sppRFStateFunc();
}
INT_GLOBAL_ENABLE (INT_ON);
return;
} // RF_ISR
*****************************************************************
// RX FUNCTIONS
*****************************************************************
void RX_WAIT (void) {
// Drop the sync byte
RF_LOCK_AVERAGE_FILTER(TRUE);
sppIntData.mode = SPP_RX_MODE;
sppRFStateFunc = RX_DABH;
}
void RX_DABH (void) {
sppIntData.pRXI->status = SPP_RX_RECEIVING;
FAST_CRC8_INIT(sppIntData.crc8);
FAST_CRC8(RF_RECEIVE_BYTE(), sppIntData.crc8);
if ((RF_RECEIVE_BYTE() == sppSettings.myAddressH) ||
(RF_RECEIVE_BYTE() == SPP_BROADCAST_H)) {
sppIntData.rx_address_valid = 1;
} else {
sppIntData.rx_address_valid = 0;
}
sppRFStateFunc = RX_DABL;
}
void RX_DABL (void) {
sppIntData.pRXI->status = SPP_RX_RECEIVING;
FAST_CRC8(RF_RECEIVE_BYTE(), sppIntData.crc8);
if ((RF_RECEIVE_BYTE() == sppSettings.myAddressL) ||
(RF_RECEIVE_BYTE() == SPP_BROADCAST_L)) {
} else {
sppIntData.rx_address_valid = 0;
}
sppRFStateFunc = RX_SABH;
}
void RX_SABH (void) {
sppIntData.pRXI->sourceH = RF_RECEIVE_BYTE();
FAST_CRC8(RF_RECEIVE_BYTE(), sppIntData.crc8);
sppRFStateFunc = RX_SABL;
}
void RX_SABL (void) {
sppIntData.pRXI->sourceL = RF_RECEIVE_BYTE();
FAST_CRC8(RF_RECEIVE_BYTE(), sppIntData.crc8);
sppRFStateFunc = RX_PKID;
}
void RX_PKID (void) {
sppIntData.pRXI->pkid = RF_RECEIVE_BYTE();
FAST_CRC8(RF_RECEIVE_BYTE(), sppIntData.crc8);
sppRFStateFunc = RX_DATA_LEN;
}
void RX_DATA_LEN (void) {
sppIntData.pRXI->dataLen = RF_RECEIVE_BYTE();
FAST_CRC8(RF_RECEIVE_BYTE(), sppIntData.crc8);
sppRFStateFunc = RX_FLAG;
}
(Continued)
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
37
sor networks and ubiquitous computing
environments. Our group has developed
several dense, multisensor wireless plat-
forms for wearable applications. One
example is a card that acquires 16 differ-
ent tactile and free-gesture sensor parame-
ters from a dancer’s shoe (see Photo 3).
This produces data interpreted by a rule
base running on a PC generating interac-
tive music, putting the dancer in control
of the composition. Data is acquired by
a PIC16C711 and transmitted from the
shoe by a Radiometrix TX-series trans-
mitter. Visit www.media.mit.edu/resenv/
danceshoe.html for more information.
A more recent example in this area is
our stack sensor architecture (see Photo
4). The stack is a series of compact inter-
changeable circuit boards, each perform-
ing a specific function such as six-axis
inertial measurement sensing, sonar prox-
imity measurement, tactile interfaces
(bend, pressure, and capacitive sensors),
and processing and wireless communica-
tion. The wireless board contains an RFM
wireless transceiver and a Cygnal 8051-
based processor that handles a TDMA
communication protocol. It snaps togeth-
er with any combination of sensor boards
to form a compact wireless sensing suite.
We are currently using this device in a
shoe designed in collaboration with the
Biomotion Group at the Massachusetts
General Hospital to acquire data for diag-
nosis of gait defects and to develop inter-
active therapy for patients with difficulty
walking. Refer to www.media.mit.edu/
resenv/Stack for more information about
the stack sensor architecture. Visit
www.media.mit.edu/resenv/gaitshoe.html
for more information about the Gait
Sensing Shoe.
NETWORKING STANDARDS
Several higher-level standards have
been established atop the low-level proto-
cols that we reviewed earlier. Although
many manufactures provide chipsets that
implement 802.11, or Wi-Fi, its power
requirements and associated complexi-
ty often preclude adoption in small
battery-operated devices, which don’t
often need its high data rates and
heavy protocol stack.
Bluetooth, which is a well-established
standard that describes hardware and a
software protocol for wireless network-
ing, provides a simpler and less power-
Listing 2—
Continued.
void RX_FLAG (void) {
sppIntData.pRXI->flags = RF_RECEIVE_BYTE();
FAST_CRC8(RF_RECEIVE_BYTE(), sppIntData.crc8);
sppRFStateFunc = RX_CRC8_HEADER;
}
void RX_CRC8_HEADER (void) {
FAST_CRC8(RF_RECEIVE_BYTE(), sppIntData.crc8);
sppIntData.counter = 0;
if (sppIntData.crc8 == CRC_OK) {
if (sppIntData.pRXI->dataLen == 0 &&
sppIntData.rx_address_valid == 1) {
SPP_DISABLE_TIMEOUT();
if (sppIntData.pRXI->flags & SPP_ACK_REQ) {
SPP_FAST_POWER_UP_TX();
sppRFStateFunc = RXACK_START;
} else {
sppIntData.pRXI->status = SPP_RX_FINISHED;
FSM_RESET();
}
} else if (sppIntData.pRXI->dataLen > sppIntData.pRXI-
>maxDataLen) {
sppIntData.pRXI->status = SPP_RX_TOO_LONG;
FSM_RESET();
} else {
sppRFStateFunc = RX_DBX_START;
}
} else {
FSM_RESTART_RX();
}
}
void RX_DBX_START (void) {
sppIntData.pRXI->pDataBuffer[sppIntData.counter] =
RF_RECEIVE_BYTE();
FAST_CRC16_INIT(sppIntData.crc16);
FAST_CRC16(RF_RECEIVE_BYTE(), sppIntData.crc16);
sppIntData.counter = 1;
if (sppIntData.counter == sppIntData.pRXI->dataLen) {
sppRFStateFunc = RX_CRC16_DATA_H;
} else {
sppRFStateFunc = RX_DBX;
}
}
void RX_DBX (void) {
sppIntData.pRXI->pDataBuffer[sppIntData.counter] =
RF_RECEIVE_BYTE();
FAST_CRC16(RF_RECEIVE_BYTE(), sppIntData.crc16);
sppIntData.counter++;
if (sppIntData.counter == sppIntData.pRXI->dataLen) {
sppRFStateFunc = RX_CRC16_DATA_H;
}
}
void RX_CRC16_DATA_H (void) {
FAST_CRC16(RF_RECEIVE_BYTE(), sppIntData.crc16);
sppRFStateFunc = RX_CRC16_DATA_L;
}
void RX_CRC16_DATA_L (void) {
FAST_CRC16(RF_RECEIVE_BYTE(), sppIntData.crc16);
if (sppIntData.crc16 == CRC_OK && sppIntData.rx_address_valid == 1) {
SPP_DISABLE_TIMEOUT();
if (sppIntData.pRXI->flags & SPP_ACK_REQ) {
SPP_FAST_POWER_UP_TX();
sppRFStateFunc = RXACK_START;
} else {
FSM_RESET();
sppIntData.pRXI->status = SPP_RX_FINISHED;
}
} else {
FSM_RESTART_RX();
}
}
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
39
hungry option. By conforming to a stan-
dard like Bluetooth, different companies
can ensure that their devices will be able
to communicate with one another. Some
manufacturers, including Cambridge
Silicon Radio (www.csr.com), SiliconWave
(www.siliconwave.com), and Zeevo
(www.zeevo.com), offer single-chip solu-
tions that not only perform RF communi-
cation, but also handle the high-level pro-
tocol described in the Bluetooth standard.
These chips offload much of the required
processing and allow the use of a low-
power micro to handle the application
software without sacrificing board space,
power consumption, or cost. Furthermore,
single-chip solutions integrating the proto-
col stack, the RF hardware, and a power-
ful microprocessor (with enough capacity
to handle both the user’s applications
and the wireless network) are starting to
emerge from manufacturers like Motorola
and National Semiconductor.
With a maximum data rate of 1 Mbps
and power consumption at 0.3 mA in
standby (30 mA max. while transferring at
full speed), Bluetooth is intended for high
data rate applications such as streaming
audio and video in battery-powered
devices. A new standard developed under
IEEE 802.15.4 called ZigBee is emerging
that aims to do the same thing for
lower-bandwidth, lower-power apps, such
as home automation and sensor teleme-
try. Chipcon recently announced an RFIC
(the CC2420) that is ZigBee-enabled. And,
Motorola is starting to enhance devices
such as sensors with ZigBee to provide
single-chip solutions that perform a task
and handle all of the communication
hardware and software. The soon-to-be-
released Motorola NeuRFon chips (e.g.,
the MC13192) will integrate an 802.15.4
radio with a digital state machine to
handle low-level ZigBee protocol.
I
Authors’ Note: We would like to thank
our colleagues in the Responsive
Environments Group, Ari Benbasat
and Stacy Morris in particular, for their
contribution to several of the projects
introduced in this article. We are grateful
for the support of the
Things That Think
consortium and other sponsors of the
MIT Media Laboratory.
a)
b)
Photo 4a—
The stack sensor architecture is a compact,
configurable, multimodal wireless sensing platform. You
can see the processor/RF card, tactile sensor interface,
and six-axis IMU.
b—
Here is its application in a shoe to
monitor gait characteristics.
Mathew Laibowitz earned a diploma
from Columbia University in Electrical
Engineering and Computer Science. He
is currently a second-year graduate stu-
dent at the MIT Media Lab in the
Responsive Environments Group and a
Motorola Fellow. Prior to joining the
Media Lab, Mat worked for three years at
IBM Research and two years at XanBoo,
where he developed wireless products for
Internet-controlled home automation. You
may contact Mat at mat@media.mit.edu.
Joseph Paradiso, Sony Career
Development Associate Professor at the
MIT Media Lab, directs the Responsive
Environments Group, which develops new
sensor architectures for interactive sys-
tems. He received his B.S. in Electrical
Engineering and Physics from Tufts
University in 1977 and his Ph.D. in
Physics from MIT in 1981. Prior to joining
the Media Lab, Joe worked at Draper
Laboratory in Cambridge and ETH in
REFERENCES
[1] T.S. Rappaport, Wireless
Communications: Principles and
Practice
, Prentice Hall, Upper
Saddle River, NJ, 2002.
[2] R. Borovoy, M. McDonald,
F. Martin, M. Resnick, “Things
That Blink: Computationally
Augmented Nametags,” IBM
Systems Journal
, vol. 35, nos. 3
and 4, 1996.
PROJECT FILES
To download the code and table, go
to ftp.circuitcellar.com/pub/
Circuit_Cellar/2004/163.
RESOURCES
J. Adams, “Meet the ZigBee Stand-
ard,” Sensors Magazine, June 2003.
A.Y. Benbasat, S.J. Morris, and J.A.
Paradiso, “A Wireless Modular
Sensor Architecture and its App-
lication in On-Shoe Gait Analysis,”
Proceedings of the 2003 IEEE
International Conference on
Sensors
, October 2003.
Berkeley motes, ebs.cs.berkeley.edu/
tos/hardware/hardware.html.
J. C. Haartsen, “The Bluetooth
Radio System,” IEEE Personal
Communications
7, no. 1, 2000.
L. E. Holmquist, et al., “Building
Intelligent Environments with Smart-
Its,” IEEE Computer Graphics and
Applications Magazine
, December
2003.
J. Paradiso, K. Hsiao, A. Benbasat,
and Z. Teegarden, “Design and
Implementation of Expressive
Footwear,” IBM Systems Journal,
vol. 39, nos. 3 and 4, October 2000.
SOURCE
CC1010 Transceiver
Chipcon
(408) 973-7845
www.chipcon.com
Photo 3—
This is expressive footwear. Sixteen diverse
sensor channels wirelessly transmit from the foot of a
performer for producing dance-driven interactive music.
Zurich on high-energy physics detectors,
spacecraft control systems, and underwater
sonar. You may contact him
atparadiso@media.mit.edu.
40
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
T
here aren’t many of you out there
who haven’t done something at one time
or another with one of Microchip’s PIC
microcontrollers. Although there seems
to be a million different varieties of PICs
to choose from, there’s always the appli-
cation that needs just a bit more internal
RAM or a few more bytes of program
memory. To meet your application needs,
Microchip has always come through by
introducing newer and faster PIC variants
with more internal goodies and larger
SRAM and program memory spaces.
Regardless of the size and speed of the
PIC in your application, when you stop
and think about it, everything you do
with a PIC simply comes down to sensing
real-world events and acting on them
by manipulating the PIC’s supporting
hardware with the logic you’ve loaded
into the program memory area of the PIC.
PICs can be instructed to sense events
in many ways, with the most commonly
used PIC sensor interface being the PIC’s
on-chip A/D converter subsystem. In
some cases, the PIC may use an external
piece of hardware as a sensor,
which requires the PIC to be
able to communicate with the
device that is acting as the
sensor. To those ends, there
are PICs equipped with multi-
ple-input A/D converters,
standard serial interfaces that
support RS-232 and RS-485,
master and slave I
2
C function-
ality, and SPI capability.
Well, Microchip has once
again turned up the heat
under the dancin’ chicken. A
Find yourself a comfortable chair,
because I’m about to adjust the gain
knob on your geek node, narrow your
nerd coefficient, and push the limits of
your dweeb limiter. Buckle up and pull
that shoulder strap tight. You’re about
to take a ride on the new Microchip
dsPICDEM 1.1 development board.
WHAT’S A dsPIC?
That really depends on how you look
at the part. From a programmer’s point
of view, the dsPIC is a 16-bit core device
that includes a collection of 16 16-bit
working registers that can independent-
ly act as data, address, or offset registers.
In many instances, two of the working
registers (W15 and W14) are dedicated
to acting as stack pointer and stack
frame pointer respectively. Other work-
ing register sets are predetermined
sources and sinks for certain math
operations like dividing and multiply-
ing or multiplying and accumulating.
Regardless of their preassignments,
some of the working registers can
revert to standard duties
when not being accessed by
a particular function or
instruction. One example is
W14, which can be used as a
general-purpose working reg-
ister when it is not being
accessed using the link
(LNK) and unlink (ULNK)
instructions. On the other
hand, some working regis-
ters are working stiffs in a
dead-end job. Working regis-
ter W0, for instance, is desig-
Picking Apart Microchip’s dsPIC
APPLIED PCs
by Fred Eady
new PIC technology with a feature-rich
and easier-to-use 16-channel, 12-bit
A/D subsystem is here. The new PIC
also incorporates an enhanced com-
munications subsystem, which
includes two USARTs, master and
slave I²C hardware, and a dual 8- or
16-bit SPI communications subsystem.
Depending on the application, micro-
controller timing is just as important as
sensing and I/O operations. So, the next-
generation PIC has gone through a timer
facelift as well. Some of the new PIC’s
five internal 16-bit timers can be com-
bined to create single 32-bit timers. There
are even a couple of CAN modules and a
data converter interface that can be used
to talk to an audio CODEC in the new
PIC’s bag of tricks. As you would expect,
there is plenty of SRAM (8 KB) and pro-
gram memory (48 KB) to support the bevy
of new and improved internal PIC hard-
ware modules. However, the real heat
that dancin’ chicken is feeling comes
from a DSP engine that’s embedded with
the enhanced PIC hardware modules.
You’ve heard a lot about dsPIC technology. Now it’s time for the specifics. This month, Fred
takes you on a dsPIC tour, covering both the hardware and software. Whether you’re a DSP
veteran or new to the game, this dsPIC primer is just what you need to get moving on your
next project.
Photo 1—
This was the beginning. I think the original idea was to have a separate dsPIC
microcontroller board that could plug to any number of peripheral expansion boards.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
41
nated as WREG and can-
not be reassigned.
In addition to the stan-
dard MCU core, the dsPIC
includes a high-speed DSP
engine that is supported
by a 17- × 17-bit multipli-
er, two 40-bit accumula-
tors, a 40-bit ALU, and a
40-bit bidirectional barrel
shifter. The extended
dsPIC instruction set
(88 instructions instead of
the normal 35) consists of
two classes of instructions,
DSP and MCU, which are
designed to meld together
and form a seamless logi-
cal bond between the DSP
engine and MCU. All of
the program instructions
are executed by the MCU core, but both
the DSP engine and the MCU use work-
ing registers within the working register
array according to the class of instruction
that is being executed at the time.
To further enhance the DSP engine’s
capabilities, the 64 KB of addressable
dsPIC data memory area is split into X
and Y data memory blocks, with each
block of memory being supported by
an independent address generation unit
(AGU). The MCU class instructions
never see the Y data area and run on
the premise that the X data memory
area is the whole enchilada.
On the other hand, the DSP class
instructions can see both X and Y data
areas. In specific instances, they can split
the full complement of data memory into
separate X and Y data areas and use the X
AGU and Y AGU to independently access
data in each respective data memory area.
Although the parting of data memory is
a good thing as far as the DSP engine is
concerned, the programmer has no con-
trol over how the memory is split because
that is a device-dependent feature.
If SRAM is in short supply (and most
of the time it is), it’s advantageous to
code constants into program memory
space. An 8-bit program space visibility
page (PSVPAG) register allows the
dsPIC programmer to access hard-coded
values in program memory as if they
were located in data memory.
Using the PSVPAG register invokes
the first rule of embedded computing:
“Nothing is free.” That’s because the
price for the PSVPAG service is an
extra cycle and access to the lower
16 bits of the instruction word only. I
used “instruction word” here because,
in reality, the page’s code and data are
visible, and you’re the one that
decides what is data and what is an
instruction when the program space
visibility feature is being used.
To help offset the toll collected by
using the PSVPAG route, a set of no-
overhead do loop registers (DSTART,
DCOUNT, and DEND) is available to
help the dsPIC programmer perform
repetitive hardware loop operations. With
all that data whirling around between the
dsPIC internal modules, there must be a
way to monitor the status of all of the
processes that act on the working register
set and the hardware do loop registers. A
16-bit status register is provided to assist.
A hardware designer’s view of a dsPIC
is extremely different. This guy or gal
sees a lot of high-current I/O pins mixed
in with a number of external interrupt
sources, capture inputs, PWM outputs,
communications interfaces, and high-res-
olution A/D inputs that can utilize the
processing power of the combined high-
speed DSP and MCU engines. In other
words, you can hang lots of stuff off of
the dsPIC and service it all really quickly.
dsPICDEM BOARD
My dsPIC experience started some
time ago. What you see in Photo 1 is
actually the meeting of two
boards, the dsPIC processor
board 80P and an expansion
board EX1, which, when
combined, are called
dsPICDEM 1. After a bit of
filtering, what you see in
Photo 1 transforms into the
new dsPICDEM 1.1 shown
in Photo 2. The boards are
functionally identical, with
the only physical difference
being the lesser number of
MCP602 op-amps on the
new dsPICDEM board.
From what I can tell by
comparing the schematics,
the audio input circuit was
slightly modified, which
accounts for one less op-amp
on the new dsPICDEM 1.1
development board.
The dsPICDEM 1.1 development
board can best be described as a number
of subsystems that are being serviced by
a high-end ds30F6014. The ds30F6014 is
the largest device currently in the dsPIC
family; it supports the dsPICDEM 1.1
development board’s audio codec,
RS-232/485, CAN, A/D, and LCD sub-
systems. A separate PIC18F242 that’s fed
by an SPI connection originating from
the ds30F6014 controls the LCD directly.
The remaining MCP602 op-amps on the
new dsPICDEM 1.1 development board
are employed as low-pass filters for the
TC1047A temperature sensor and the
MCP41010 digital potentiometer.
An MPLAB ICD 2—which is also
known as the “hockey puck”—is all
that’s required to program and debug the
dsPICDEM 1.1 development board’s
ds30F6014. By simply moving a couple of
jumpers, the PIC18F242 LCD controller
also can be serviced by the dsPICDEM 1.1
development board’s on-board ICSP port.
In addition to blinking lights, push
buttons, and a fancy LCD, the
dsPICDEM 1.1 development board also
squawks DTMF tones. All you need to
experience that is a set of headphones
or a passive PC speaker system. A pair
of inexpensive Sennheiser HK212Pro
headphones (32-
Ω
impedance) works
well with the codec subsystem of the
dsPICDEM 1.1 development board.
In my opinion, only half of the fun
lies in the dsPIC hardware. Although
Photo 2—
Here’s today’s dsPIC digital signal controller development board. The whole of
what you see in Photo 1 is squeezed nicely into a single board. The dsPIC is socketed for
easy removal and replacement on both the old and new dsPIC boards.
42
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
the dsPIC was designed with C in
mind, almost all of the code for the
dsPIC demo program is written in
assembler. The dsPIC assembler source
code is easy to follow because it is
written in a modular fashion. I found it
easy to convert the dsPIC assembler
statements into C source that I could
run and test through the Microchip
C30 C compiler, which supports the
dsPIC digital signal controller family.
Whether you prefer the assembler
approach or C, the dsPIC demo code is
a good source of “how to” code that
you can use to build your own dsPIC
routines. For instance, the proper use of
the PSVPAG register and program space
visibility is demonstrated throughout
the dsPIC demo code modules.
STARTER SERIAL PORT
In preparation for writing this text,
and to make sure I had some idea of
what I was doing, I’ve read all I want-
ed to read about DSP devices and their
innards. I’ve studied the Microchip
dsPIC demo code and datasheets to
the point of memorization. I’ve writ-
ten tons of PIC code in my time, but
after all of the DSP prep, I’m really
anxious to write and run some dsPIC-
targeted C routines to exercise some
of the hardware on the dsPICDEM
development board.
I was fortunate enough to be includ-
ed in the Microchip Early Adopter
Program for the dsPIC, which provided
datasheets, example code, and updated
dsPIC tools via downloads from a spe-
cial FTP site. After gathering all of the
dsPIC tools and code that I thought I
would need to get started, I sat down
and proceeded to load the latest
MPLAB IDE and the Microchip C30 C
compiler. Everything installed without
a hitch. After communications between
the MPLAB ICD 2 and the dsPICDEM 1
development board were established, I
wiped the ds30F6014 clean. A rush of
quiet came over the Florida room as I
sat there in realization that I was total-
ly on my own in a PIC land unknown.
My first instinct was to bring up a
serial port. So, I dialed up the dsPIC
datasheet in my Adobe Acrobat Reader
and picked out what I thought would be
enough bit settings to bring a simple
serial port to life. To my amazement,
the little bit of serial port code you see
at the top of Listing 1 spit out just what
I had put into it the first time. Success
is a great motivator. I pointed my
Adobe Acrobat Reader toward the C30
compiler’s dsPIC peripheral library ref-
erence guide. Once there, I found yet
another way to activate my dsPIC serial
port. As you can see in the latter part of
Listing 1, I didn’t have to “PIC” through
the bits to use the
OpenUART1 function
to initialize my new dsPIC serial port.
During my study of the dsPIC and
the dsPICDEM 1 development board, I
was introduced to various dsPIC assem-
bler routines that are used to initialize
and control the dsPIC’s internal hard-
ware. Early in my reading, I figured that
I was going to have to put together
some of my own little functions to get
the C part of this project going. As it
turned out, Microchip was on top of it.
The dsPIC hardware peripheral library
contains C functions for all of the
major subsystems. All I have to do to
use them is include the library
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
43
p30F6014.a in my MPLAB project.
Before I move on to writing some dsPIC
peripheral C code, there’s one more
visual aid to bring to life using C, the
dsPICDEM development board’s LCD.
dsPICDEM 1.1 LCD
As I mentioned earlier, everything per-
taining to hardware and software that I
discovered on the original dsPICDEM 1
development board works identically on
the new dsPICDEM 1.1 development
board. So, from this point on, I’ll discuss
and use the newer 1.1 version of the
development board and the tools includ-
ed on the companion dsPIC CDROM.
A custom driver loaded into a
PIC18F242 drives the 32 × 122
dsPICDEM 1.1 development board LCD.
Using the PIC18F242-based LCD driver,
I can draw lines, generate pixel graphics,
and communicate with a human by dis-
playing text. The design of the LCD
driver incorporates a buffer that allows
the dsPIC to send an entire screen of
LCD characters without the fear of an
LCD buffer overrun. An 8-bit SPI data
path links the dsPIC to the PIC18F242
LCD controller. If flow control is ever
needed, the PIC18F242 returns the
buffer count to the dsPIC following each
byte that is received. The LCD buffer is
186 bytes deep. Even though all of these
safety mechanisms are in place, the idea
is to not have to use any type of flow
control mechanism to transfer data from
the dsPIC to the LCD.
The LCD command structure also
has some built-in synchronization fea-
Listing 1—
The upper portion of this listing is the caveman way of initializing the dsPIC’s USART1. It may
take a bit more finger work to bring up USART1 using the dsPIC hardware library routines, but time is really
saved in that you don’t have to figure out the correct bit pattern by rambling through the dsPIC datasheets.
Another plus to using the dsPIC library is that the source code is easier to read.
#include "p30F6014.h"
#include <stdio.h>
#include <uart.h>
int main ()
{
unsigned int spi2cfg_1,spi2cfg_2;
U1MODE |= 0x8000;
U1BRG = (((7372800/9600) /16) - 1);
U1STA |= 0x0400;
while(1){printf("Circuit Cellar dsPIC Primer");}
******************************************************************
unsigned int baud,uartmode,uartsta;
baud = (((7372800/9600) /16) - 1);
uartmode = UART_EN & UART_NO_PAR_8BIT & UART_1STOPBIT;
uartsta = UART_TX_ENABLE & UART_TX_PIN_NORMAL;
OpenUART1(uartmode,uartsta,baud);
while(1){printf("Circuit Cellar dsPIC Primer");}
}
44
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
Listing 2—
The Microchip C30 C compiler moaned and groaned at some of my source coding. So, I decid-
ed to fly blind using “instruments” only. I wrote the C source and then peeked at the assembler that my C
statements generated using the MPLAB ICD 2 hockey puck. The C30 compiler doesn’t directly support
program space visibility like the assembler does. I had to bend my PSV C code to emulate the special
dsPIC assembler operators
psvpage
and
psvoffset
.
#include "p30F6014.h"
#include <stdio.h>
#include <spi.h>
void display_char(char ascii_char);
unsigned int spi_in;
int *textin;
char realtext;
// Put these strings in program memory
const __attribute__((section(".const_cc"),space(prog)))
char ccllar_text[20] = {" Circuit Cellar "};
const __attribute__((section(".primer_cc"),space(prog)))
char primer_text[20] = {" dsPIC Primer "};
const __attribute__((section(".complicated_cc"),space(prog)))
char compli_text[20] = {"It's NOT Complicated"};
const __attribute__((section(".embedded_cc"),space(prog)))
char embedded_text[20] = {" It's EMBEDDED! "};
void display_char(char ascii_char)
{
LATGbits.LATG9 = 1;
LATGbits.LATG9 = 0;
spi_in = ReadSPI2();
WriteSPI2(0xA8);
while(!(DataRdySPI2()));
LATGbits.LATG9 = 1;
LATGbits.LATG9 = 0;
spi_in = ReadSPI2();
WriteSPI2(ascii_char);
while(!(DataRdySPI2()));
spi_in = ReadSPI2();
}
int main ()
{
unsigned int spi2cfg_1,spi2cfg_2,x;
CORCONbits.PSV = 1;
PSVPAG = 0;
// Set up SPI2 SS line LATG9
LATGbits.LATG9 = 1;
TRISGbits.TRISG9 = 0;
// Initialize and activate SPI2
spi2cfg_1 = FRAME_ENABLE_OFF &
ENABLE_SDO_PIN &
SPI_MODE16_OFF &
SPI_SMP_OFF &
SPI_CKE_OFF &
SLAVE_ENABLE_OFF &
CLK_POL_ACTIVE_HIGH &
MASTER_ENABLE_ON &
PRI_PRESCAL_64_1;
spi2cfg_2 = SPI_ENABLE &
SPI_IDLE_CON &
SPI_RX_OVFLOW_CLR;
OpenSPI2(spi2cfg_1,spi2cfg_2);
// Initialize the LCD
LATGbits.LATG9 = 1;
LATGbits.LATG9 = 0;
spi_in = ReadSPI2();
WriteSPI2(0x82);
while(!(DataRdySPI2()));
(Continued)
www.circuitcellar.com
Issue 163 February 2004
45
CIRCUIT CELLAR
®
tures. The first byte of a command
always has the most significant bit
set. A command can vary from 1 to
3 bytes with the second and third
bytes having their most significant
bits clear. There is one exception to
this rule, and it applies to column
commands in which all of the com-
mand bytes may have their most sig-
nificant bits cleared. The LCD driver
firmware is written to identify and
parse the column commands as nec-
essary. To keep things simple, the
data that follows a command is in its
native format and is not altered, com-
bined, or compressed.
To put some characters on the
dsPICDEM 1.1 development board’s
LCD required first initializing the sec-
ond SPI port, SPI2. I again called on the
functionality of the dsPIC peripheral
library. This time using the
OpenSPI2
function, I set up the SPI parameters set
forth by the dsPICDEM 1.1 develop-
ment board LCD documentation in the
new dsPICDEM 1.1 user’s guide. After
the SPI2 interface was up, I took control
of the LCD chip select line and sent a
command to initialize the LCD (0x80).
Here’s a good place to use the pro-
gram space visibility (PSV) feature of
the dsPIC. After the PSV bit is enabled
in the core control (CORCON) regis-
ter, the contents of the PSVPAG are
valid and point to the 32-KB program
memory page that you want to access
your program memory-coded data
from. I’m going to use an arbitrary
example to help you cut through the
PSV datasheet mumbo jumbo.
Let’s assume you have a small pro-
gram that completely resides in pro-
gram memory page 0. Your data is an
81-byte ASCII message that is located
at offset 0x0184 in program memory.
The dsPIC on the dsPICDEM 1.1
development board ds30F6014 con-
tains 8 KB of SRAM, which means the
usable SRAM area ranges from 0x0000
to 0x1FFF. The dsPIC can address an
SRAM area of 64 KB, which extends
your logical SRAM reach from 0x1FFF
to 0xFFFF. Let’s also assume you’re
not using DSP instructions, and the
X data memory area is your destina-
tion overlay area.
The dsPIC datasheet tells you that
program space visibility allows you to
map a 32-KB area of program memory
into the upper 32-KB area of data
memory. A bit of hex math reveals
that 32 KB below the X data memory
address ceiling address of 0xFFFF puts
the data area overlay window start
point at 0x8000. Because you know
that your ASCII message resides at
Listing 2—
Continued.
LATGbits.LATG9 = 1;
LATGbits.LATG9 = 0;
spi_in = ReadSPI2();
WriteSPI2(0x82);
while(!(DataRdySPI2()));
// Display the program memory strings
for(x=0;x<20;++x)
{
textin = &ccllar_text[x] + 0x8000;
realtext = *textin;
display_char(realtext);
}
for(x=0;x<20;++x)
{
textin = &primer_text[x] + 0x8000;
realtext = *textin;
display_char(realtext);
}
for(x=0;x<20;++x)
{
textin = &compli_text[x] + 0x8000;
realtext = *textin;
display_char(realtext);
}
for(x=0;x<20;++x)
{
textin = &embedded_text[x] + 0x8000;
realtext = *textin;
display_char(realtext);
}
while(1);
}
Listing 3—
The dsPIC vector functions are designed to work against fractional vector values, which range
from –1 to 1. However, because you have to determine if a number is fractional or not, I can show you
some simple vector operations using integers as their basis.
#include "p30F6014.h"
#include <stdio.h>
#include <dsp.h>
int vector1[8],vector2[8],vector3[8],vector4[8],vector5[8];
int main ()
{
unsigned int x,y,z;
y = 0x0FEE;
z = 0x1001;
for(x=0;x<8;++x)
{
vector1[x] = y++;
vector2[x] = z++;
vector3[x] = 0;
}
VectorAdd(16,vector3,vector1,vector2);
VectorCopy(16,vector4,vector2);
VectorNegate(16,vector5,vector1);
while(1);
}
46
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
Listing 4—
I enlisted the USART code to help display the voltage readings in a Tera Term Pro emulator win-
dow. There are plenty of dsPIC A/D knobs to turn, but after you tune them in, acquiring the data is relatively
easy going.
#include "p30F6014A2.h"
#include <stdio.h>
#include <uart.h>
#include <adc12.h>
#define
esc
0x1B
int main ()
{
unsigned int x;
unsigned int channel,adc12cfg_1,adc12cfg_2;
unsigned int adc12cfg_3,adc12cfg_p,adc12cfg_s;
unsigned int baud,uartmode,uartsta;
baud = (((7372800/9600) /16) - 1);
uartmode = UART_EN & UART_NO_PAR_8BIT & UART_1STOPBIT;
uartsta = UART_TX_ENABLE & UART_TX_PIN_NORMAL;
OpenUART1(uartmode,uartsta,baud);
// Make sure analog input pins are actually inputs.
TRISBbits.TRISB4 = 1;
TRISBbits.TRISB5 = 1;
TRISBbits.TRISB6 = 1;
ADCON1bits.ADON = 0;
channel = ADC_CH0_POS_SAMPLEA_AN4 &
ADC_CH0_POS_SAMPLEA_AN5 &
ADC_CH0_POS_SAMPLEA_AN6;
SetChanADC12(channel);
ConfigIntADC12(ADC_INT_DISABLE);
adc12cfg_1 = ADC_MODULE_ON &
ADC_IDLE_CONTINUE &
ADC_FORMAT_INTG &
ADC_CLK_MANUAL &
ADC_AUTO_SAMPLING_OFF;
adc12cfg_2 = ADC_VREF_AVDD_AVSS &
ADC_SCAN_ON &
ADC_SAMPLES_PER_INT_16 &
ADC_ALT_BUF_OFF &
ADC_ALT_INPUT_OFF;
adc12cfg_3 = ADC_CONV_CLK_INTERNAL_RC;
adc12cfg_p = ENABLE_AN4_ANA &
ENABLE_AN5_ANA &
ENABLE_AN6_ANA;
adc12cfg_s = SKIP_SCAN_AN0 &
SKIP_SCAN_AN1 &
SKIP_SCAN_AN2 &
SKIP_SCAN_AN3 &
//SKIP_SCAN_AN4 &
//SKIP_SCAN_AN5 &
//SKIP_SCAN_AN6 &
SKIP_SCAN_AN7 &
SKIP_SCAN_AN8 &
SKIP_SCAN_AN9 &
SKIP_SCAN_AN10 &
SKIP_SCAN_AN11 &
SKIP_SCAN_AN12 &
SKIP_SCAN_AN13 &
SKIP_SCAN_AN14 &
SKIP_SCAN_AN15 ;
OpenADC12(adc12cfg_1,adc12cfg_2,adc12cfg_3,adc12cfg_p,adc12cfg_s);
do{
for(x=0;x<16;++x)
{
ADCON1bits.SAMP = 1;
while(!ADCON1bits.SAMP);
ConvertADC12();
while(ADCON1bits.SAMP);
while(!BusyADC12());
while(BusyADC12());
}
adc4_in = ReadADC12(4);
adc5_in = ReadADC12(5);
adc6_in = ReadADC12(6);
printf("%c[1;1H Voltage 1 (AN6/RP1) = %f",esc,adc6_in * .00122);
printf("%c[2;1H Voltage 2 (AN4/RP2) = %f",esc,adc4_in * .00122);
printf("%c[3;1H Voltage 3 (AN5/RP3) = %f",esc,adc5_in * .00122);
}while(1);
}
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
47
offset 0x0184 in real program memory,
that puts the PSV ASCII message
access point at 0x8184. The good news
is that if that didn’t make any sense at
all, you can actually see this relation-
ship of program memory area versus
data memory area from MPLAB ICD 2
PSV window views within the MPLAB
IDE. Photo 2 reveals the ASCII mes-
sage that was generated by the PSV
code snippet in Listing 2.
VECTORS 101
When I think of the word DSP, the
word “math” always pops up with it.
The problem with most DSP texts out
there is that they were written assum-
ing the reader could comprehend all of
the exotic mathematical functions the
book’s author could print. In the long
run, the math does rule; but for the
short term, let’s use some real num-
bers and take a look at basic DSP stuff
that is the basis for the exotic DSP
stuff. The idea here is to use the
MPLAB ICD 2 and MPLAB IDE to
show you some functions that use the
dsPIC’s basic DSP hardware (40-bit
accumulator, hardware DO Loop, etc.).
A vector is one simple data element
form that can be useful in DSP process-
ing. A vector is nothing more than a
collection of values that are normally
contained in a contiguous area of mem-
Photo 3—
This is a bit busy, so I’m trying to give you enough landmarks to be able to navigate between the words and
windows. The File Registers:2 window consists of five eight-word vectors beginning at address 0850. Vector 3 is the sum of
associated vector elements from vectors 1 and 2. Vector 4 is a copy of vector 2. Vector 5 is the result of negation of vector 1.
ory. For the dsPIC, a vector is made up
of an arbitrary number of 16-bit words
with the first element of the vector
lying at the lowest memory address
of the vector. In a sense, a vector is
simply an array of N elements with
the first element being the access han-
dle, or base address, for the vector.
Listing 3 is a simple look at how
easy it is to use the Microchip C30
DSP library functions to manipulate
vectors. The results of my vector
manipulations are shown in Photo 3.
JUST THE BEGINNING
For all of you experienced DSP types
out there, yes, the dsPICDEM 1.1
development board comes with a full-
blown FFT and filtering demo that
you can toy with at your leisure. For
the rest of you, I hope this dsPIC
primer will give you enough confi-
dence to jump off the fence and try
coding some dsPIC code of your own.
Lots of things can happen in the
Florida room between paragraphs, and
I’ll leave you with Photo 4 and some
additional dsPIC analog-to-digital code
to go with it in Listing 4. Be sure to
get the download package that
accompanies this text as I’ve provided
the results of my dsPIC experience
with fully commented C code. The
dsPIC can be as complicated as you
want to make it, but it’s still deeply
embedded.
I
48
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
PROJECT FILES
To download the code, go to ftp.
circuitcellar.com/pub/Circuit_
Cellar/2004/163.
SOURCES
Fred Eady has more than 20 years of
experience as a systems engineer. He
has worked with computers and com-
munication systems large and small,
simple and complex. His forte is
embedded-systems design and com-
munications. Fred may be reached at
fred@edtp.com.
RESOURCE
Microchip Technology, Inc.,
“dsPICDEM Starter Demo Board
User’s Guide,” DS51425A, 2003.
Photo 4—
I’ve inserted the Tera Term Pro terminal emulator window to show you the human aspect of the collection of
bits in the MPLAB session. The ANX entries represent the dsPIC analog input channel that is being measured. RPX
identifies which potentiometer on the dsPICDEM 1.1 development board influences the measured voltage. For those that
can count in hex and binary easier than they can in decimal, I’ve also provided a full view of the raw A/D registers in the
shot.
economically important devices. The
correct usage of the terms is this: Passive
tags communicate by backscatter, so a
tag can be passive even if it has a bat-
tery backup. Active tags do not use
backscatter, but they incorporate low-
power radios something like radar IFF
systems. Of course, active tags need a
battery or some other power source—
they cannot scavenge enough power
from the reader’s field to run that radio.
California-based Savi Technology has
an active tag, readers, and LAN protocol
that together provide a complete vertical
solution for tracking shipping containers.
Savi’s big application is military shipping
containers, which were tried out in the
first Gulf War. Now every container
bound for Iraq and Afghanistan is identi-
fied with a Savi active tag. For another
application, most RFID-based toll pay-
ment systems work with active tags.
At the moment, active tags are more
expensive than passive tags because of
the battery. But that gap is closing, too,
because the difficulties of passive anten-
na design and bonding tag silicon to
antenna take center stage as the most
expensive aspects of producing tags.
The biggest commercial application for
passive tags is car immobilization. The
large plastic knob at the end of new car
keys typically holds a passive tag. The
50
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
T
he RFID industry has been in the
news lately with big support from
Gillette, Wal-Mart, and the U.S.
Department of Defense. With that sort
of heavy money lined up, the technology
is poised to take off. The widespread
adoption of RFID will have effects
beyond the RFID industry itself. People
are already discussing RFID tags as the
leaf nodes in an “Internet of things,”
suggesting that RFID is also poised to
generate a flood of data, driving the sale
of routers, storage, and processing capac-
ity in an effort to keep up. The Internet
holds a growing body of RFID informa-
tion. One good place to start reading is
the RFID Journal (www.rfidjournal.com).
In general, RFID systems follow a
simple model. A device usually called a
“reader” creates a field. One or more
tags communicate with the reader by
varying the amount of energy reflected
back to the reader by the tag. This
process is called “backscatter.” The real-
ly neat thing about backscatter is that it
$1 Wireless Interface
Do you want a wireless interface for your next project? With a coil, a capacitor, and a tran-
sistor, you can make your next project emulate a radio frequency identification device (RFID),
commonly called a “tag” or “RFID tag.” In this article, Larry shows you how.
enables extremely cheap devices to com-
municate wirelessly (see Figure 1).
WHAT’S IN A TAG?
The general mechanism for creating
backscatter is to detune a tuned element.
The tuned element can be a resonant cir-
cuit or a dipole antenna, depending on
the tag’s frequency range (more on that
later). The point is this: your tag can be
tuned, or it can be detuned, without cre-
ating much of a stir. But when the tag
changes from one state to the other, it
creates a disturbance in the field. A well-
timed series of such disturbances starts
to look like a datastream. An RFID tag
contains the minimum possible circuitry
needed to produce that datastream: the
antenna itself, a diode and capacitor to
scavenge power from the field, another
diode or transistor to detune the anten-
na, and a little intelligence.
There are many types of RFID tags.
Some fill unique market niches; some
embody really cool technology. Others
are just there because somebody thinks
they can make a buck on them. The dif-
ferent tag types can be divided in a few
ways, the most useful of which are pas-
sive versus active, tag talk first versus
reader talk first, and frequency range.
PASSIVE VS. ACTIVE
When people talk about passive tags,
they usually mean tags that get their
power entirely from the RF field gener-
ated by the reader. The same people use
the term “active tag” to mean tags that
get their power from a battery and use
the reader’s field only for communica-
tions. But that’s not technically correct,
and it fails to cover some of the most
FEATURE ARTICLE
by Larry Martin
Reader
Field
Tags
Figure 1—
The RFID system includes a reader with an
antenna, a field, and several tags with antennas. The
big arcs going to the right show the field generated by
the reader, or the forward link. The smaller arcs going
to the left indicate the tags’ replies, or the return link. If
the tags are active tags, the return link will be radio sig-
nals driven by the tags. If the tags are passive tags, the
return link will be forward link energy backscattered by
the tags’ circuitry, as this project illustrates.
Range
Frequency
LF
125 and 135 kHz
HF
13.56 MHz
UHF
Approximately 915 MHz
MW
Approximately 2.4 GHz
Table 1—
RFID operates in four frequency bands. The
bands are different outside of the United States.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
51
frequency tags, “cpb” stands
for (carrier) cycles per bit. At
125-kHz carrier, each cycle
takes 8 µs, so 128 cpb trans-
lates to 128 × 8 µs, or 1 ms,
per bit. Why so slow? There
are a couple of reasons.
First, a slow interface mini-
mizes the effect on your pro-
ject’s compute cycles. Second,
slow transitions on the air
interface are easier to detect,
which means you will have
additional range and more reliable com-
munications. Finally, the reader used to
verify this design reads the Atmel tag con-
figured this way by default, and it doesn’t
require set-up commands to do so.
I will skip over the question of how to
modulate bits onto the air interface and
go directly to the bit pattern you must
create. I originally had planned to show
an RS-232-to-RFID air interface convert-
er that translates your keystrokes into
RFID signals, but the overhead of that
application tended to obscure the sim-
plicity of the air interface. So, this arti-
cle just shows the transmission of
canned data (this sequence emulates a
MAXBLOCK setting of 4):
0x01010101
0x02020202
0x03030303
0xdeadbeef
Simple, eh? Look for this pattern later
in the RFID reader’s output.
embedded computer of cars
equipped with this kind of
system will not allow the
car to be started or driven
unless it sees data it recog-
nizes on the key’s RFID
tag. Each car company has
its favorite tag, but the
market leader is Microchip
Technology, the company
that brings us the PIC
processor. Another familiar
application is the key fob
that lets you buy gas and fast food
without pulling out your credit card.
WHO TALKS FIRST?
The RFID world has intermittent
religious wars over which component
of the system should talk first, the
reader or the tag. Readers typically
communicate with tags by creating
timed gaps in the field. The gaps have
to be long enough to be sensed at a
distance, but short enough that tags do
not lose power during the gap interval.
Most tags wait for a command—a
series of gaps—from the reader before
modulating the field. These are known
as “reader-talk-first” tags. Some tags,
however, start modulating as soon as
they power up (or, in the case of active
tags, as soon as they detect a reader’s
field). These are known as “tag-talk-
first” tags. Each approach has its own
strengths and weaknesses, but it’s
obvious that tag-talk-first is the sim-
plest approach, and it’s the one I used
in this demo project.
FREQUENCY RANGE
In the United States, RFID operates
in four frequency bands set aside for
industrial, scientific, and medical (ISM)
purposes (see Table 1). Although the
terms have other meanings, within the
RFID industry, the terms LF, HF, UHF,
and Microwave are used as shorthand
for the ISM bands used for RFID in
those larger regions of the spectrum.
Outside of the United States, the
bands differ slightly, mainly in the
UHF range. European UHF is defined
in the middle 800-MHz range. In
Japan, UHF is higher in the 900-MHz
range. Other countries also have dif-
ferent rules for hopping, duty cycle,
power, and bandwidth.
LF and HF tags couple to the readers
inductively, using coils as antennas
and enabling the readers to be electri-
cally simple. UHF and MW tags cou-
ple radioatively, requiring more com-
plex reader electronics but providing
more range in return.
e5551 AIR INTERFACE
You can add an extremely cheap wire-
less interface to your next project by
making it act like an RFID tag. The
Atmel e5551, which is a tag-talk-first
passive tag, is the tag best suited to this
application for a few reasons: as an LF
tag, its inductive interface is easy to
duplicate; it can run slowly for good
range from a weak inductor; as one of the
older tag protocols, many readers support
it; because it is tag-talk-first, you don’t
have to decode traffic from the reader;
and its air interface is posted on the ’Net
by the manufacturer. (Many RFID pro-
tocols are available only under NDA.)
The e5551’s default behavior is to
backscatter its data on the air inter-
face whenever it is energized by the
field from a reader. So, you can set up
your hardware to continually
backscatter the data you want to
transmit. If a reader is there, the data
will be transferred. If no reader is
there, then you are not losing any-
thing beyond a few compute cycles.
The e5551 has many configuration
options. You don’t have to worry about
handling all of them. Just pick one,
and set up your system to emulate it.
Referring to the tag’s configuration
word in the e5551’s datasheet, you’ll
want to emulate a Manchester tag with
sequence termination running at 128 cpb.
You can emulate a MAXBLOCK of 1
through 7 based on how much data you
want to handle. In the language of low-
Output bit set
Output bit
clear
0
1
2 3 4
5
6
7
Full or half bit times:
Values of TE_STSTATE
when :TE_ST executes
F
H
First 0
bit
F
H
F
H
F
Last 0
bit
First 1
bit
First byte, 0 × 01
Sequence terminator
Figure 2—
Take a look at the sequence terminator and first byte of the sample message
(hex 01). The bold line is the transistor base voltage (output on port B pin 4). When the
output bit is set, the transistor conducts and the field is modulated. When the output bit
is clear, the transistor shuts off and the field is not modulated. In Manchester encoding,
the sequence terminator is a pair of on-off-on-on sequences, each 0 bit is an off-on
sequence, and each 1 bit is an on-off sequence.
2
3
1
2N3904
10 nF
162 µH
TTL Signal source
Figure 3—
This has got to be one of the simplest dia-
grams ever presented in an electronics magazine. The
transistor type is unimportant, as long as it is an NPN
device. The capacitor and coil together must resonate at
125 kHz. When the base voltage is low, the transistor is
shut off, and the LC tank is free to resonate whenever
an RFID reader is in the vicinity. When the base voltage
is high, the transistor swamps the LC tank. Each transi-
tion between resonating and swamped states produces
an edge in the reader’s detection circuits. The edges
are generally decoded in software to reconstruct the
original message. The coil is hand wound from magnet
wire (30 turns 2.5
″
diameter, 0.05
″
length).
52
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
The key to understanding the e5551 air
interface is understanding the data encod-
ing method. This example uses the
Manchester encoding method, which is
illustrated in the e5551’s datasheet. The
tag is expected to modulate (“damp”) the
field in the first half of a bit time for a 1
and in the second half of a bit time for a
0. The second part of Figure 2 shows the
signal sequence for the first data word,
0x01010101. Assume that the field is
modulated when the MOD signal is high.
So, to send data, simply shift it onto
the air interface, right? Well, not quite.
If you are going to repeatedly send your
data without being asked for it, you
should provide some way for the listen-
er to know when you are done with one
round and starting another. The e5551
provides a sequence terminator (ST) for
just this purpose. For RFID, the main
feature of the ST is typically an inten-
tional violation of Manchester timing.
The first part of Figure 2 shows the ST
sequence followed by the first data bits.
If you send this bitstream into your
antenna and put an RFID reader close
to your antenna, you will see your data
in the RFID reader’s output.
That leaves only the question of how
to modulate or damp the field. Well, LF
and HF tags both work through induc-
tance. The air interface is basically a
loosely coupled transformer with the
reader’s antenna as the primary and
each tag’s antenna serving as a second-
ary winding. (Yes, there can be more
than one tag present in some protocols.
The e5551 supports that to some extent,
but it’s too much to get into at this
point.) Your output circuit is a parallel
LC tank circuit tuned to 125 kHz. To
support modulating the field, place a
transistor across the tank. When the
transistor is off, the circuit is tuned.
When the transistor is on, the circuit is
detuned, and the air interface is damped.
Figure 3 shows the general scheme
with typical component values. With
all the elements in place, you’re ready
to look at the project.
THE SAMPLE PROJECT
The signal input in Figure 3 is labeled
“TTL Signal Source.” I used a Scenix
SX28 prototype board. Listing 1 shows
the interesting part of the Scenix pro-
gram. Most of the listing is the sample
Listing 1—
This is the most interesting part of the Scenix program.
;; TagEmulator
TagEm
=
serial
TE_STState
ds 1
; TagEmulator Sequence Terminator State
TE_BBState
ds 1 ; TagEmulator Bit Boundary state: 0 = full
; bit, ff = half bit
TE_ClkCnt
ds 1
; TagEmulator Clock Interrupt Count
TE_BitCount ds 1
; TagEmulator bit count 0..7 in byte
TE_ByteAcc
ds 1
; TagEmulator Byte Accumulator, copy from
; data and shift out
TE_BytePtr
ds 1
; TagEmulator Byte Pointer, offset from
; start of tag data
TE_tmpds
1
; TagEmulator temp byte
TE_OutBit
=
rb.4
;; end TagEmulator
org 0
;
;
; Interrupt routine - virtual peripherals
;
interrupt bank timers
;1
;; TagEmulator:interrupt every 3.12 uS for 19.2 kbaud soft UART
bank
TagEm
decsz
TE_ClkCnt
jmp
:TE_Done
:TE_512Us
;; set up TE_ClkCnt for next half-bit: 157 interrupts * 3.12 uS
;; equals 512 uS
mov
W,#157
mov
TE_ClkCnt,w
;; Are we doing the ST or not?
mov
w,TE_STState
mov
TE_tmp,w
mov
w,#8
sub
TE_tmp,w ; subtract W from FR
snb
C
; carry set for FR values 0..8 (nine states)
jmp
:TE_Bit
:TE_ST
;; select action based on Sequence Terminator State 0 through 7
;; a jump table would save a few words here
mov
w,TE_STState
mov
TE_tmp,w
snb
Z
setb
TE_OutBit
; 0
dec
TE_tmp
snb
Z
clrb
TE_OutBit
; 1
dec
TE_tmp
snb
Z
setb
TE_OutBit
; 2
dec
TE_tmp
snb
Z
setb
TE_OutBit
; 3
dec
TE_tmp
snb
Z
setb
TE_OutBit
; 4
dec
TE_tmp
snb
Z
clrb
TE_OutBit
; 5
dec
TE_tmp
snb
Z
setb TE_OutBit
; 6
dec
TE_tmp
snb
Z
setb TE_OutBit
; 7
dec
TE_tmp
snb
Z
setb TE_OutBit
; 8
;; set up for next time, first byte in case this is the last time
inc
TE_STState
clr
TE_ByteAcc
clr
TE_BytePtr
(Continued)
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
53
program provided with the SX28 devel-
opment kit. The TagEmulator string
sets off everything added to this project.
You may download the full source code
from the Circuit Cellar ftp site.
The Scenix processors are interesting
because they have few dedicated
peripherals. Scenix (now Ubicom) pro-
vides a fast chip with a lot of I/O, so
that peripherals can be implemented
in software rather than hardware.
With clock rates up to 100 MHz, the
performance of Scenix processors
approaches that of programmable logic.
For example, the program as posted still
includes the software UART, which bit-
bangs RS-232 data through any I/O pins
you want to use for that purpose.
The program’s canned output string
is at label
_RFID_Data. The ISR (label
:TE_512Us through :TE_Done, where
TE stands for tag emulator) gets output
bytes from program memory and shifts
bits out to the air interface in 512-µs
intervals. The interval timing is con-
trolled by the two lines at
:rxdone,
which push the immediate value
-163
into the RTC at the end of the interrupt.
That value leads to an interrupt every
3.12 µs, which is important for the soft-
ware UART timing. To generate the
512-µs intervals for the air interface,
code at
:TE_512Us checks the value of
TE_ClkCnt. When that register counts
down to zero, you are at a 512-µs bound-
ary and ready to handle the air interface.
One of the first things the code does is
reset
TE_ClkCnt to 157, because 157 ×
3.12 µs is as close to 512 µs as possible.
The Scenix board has two outputs,
a circuit common and the transistor’s
base. The base signal is on port B, bit 4.
When that signal is low, the transistor is
off and the LC tank resonates at its nat-
ural frequency. Note that there is no
power connection to the tuned circuit.
This interface takes almost no power
from your project, and it adds noise only
when an RFID reader is close by. When
the transistor base signal is high, the
transistor conducts, swamping the tuned
circuit. As you know, neither state is
particularly memorable. But if you care-
fully change states at the right time
intervals, you can create data, which
is exactly what happens in Photo 1.
With the tag emulator circuit running,
an RFID reader placed nearby detects
Listing 1—
Continued.
dec
TE_BytePtr
; to -1
clr
TE_BBState
not
TE_BBState
; to FF
mov
W,#8
mov
TE_BitCount,W
; trick byte read logic into getting the
; first byte
jmp
:TE_Done
:TE_Bit
;; Are we on half or full bit boundary?
not
TE_BBState
sz
jmp
:TE_HalfBit
:TE_FullBit
;; get next bit
inc
TE_BitCount
sb
TE_BitCount.3
; quick test for 8
jmp
:TEFB_ShiftBitAcc
:TEFB_RefreshBitAcc
;; get the next byte from program memory
inc
TE_BytePtr
mov
w,#_RFID_Data
add
W,TE_BytePtr
xor
W,#_RFID_DataEnd
sz
jmp
:TEFB_GetNextByte
;; we've hit the end of data, double back to the ST code
clr
TE_BytePtr
clr
TE_STState
jmp
:TE_ST
:TEFB_GetNextByte
mov
m,#0
mov
w,#_RFID_Data
add
w,TE_BytePtr
IREAD
; get instruction word at m:W, store in m:W
mov
TE_ByteAcc,W
clr
TE_BitCount
jmp
:TEFB_BitAccIsSetUp
:TEFB_ShiftBitAcc
clrb
C
rl
TE_ByteAcc
:TEFB_BitAccIsSetUp
;; shift it out
sb
TE_ByteAcc.7
clrb TE_OutBit
snb
TE_ByteAcc.7
setb TE_OutBit
jmp
:TE_BitDone
:TE_HalfBit
sb
TE_ByteAcc.7
setb TE_OutBit
snb
TE_ByteAcc.7
clrb TE_OutBit
:TE_BitDone
:TE_Done
[snip Soft Peripheral code]
:rxdone
mov w,#-163
;1 ;interrupt every 163 clocks, 3.26 uS:
;serial baud rate depends on this
retiw
;3
;
; Data
;
_hellodw
13,10,13,10,'SX Virtual Peripheral Demo',13,10,0
_prompt
dw 13,10,'>',0
_errordw
'Error!',13,10,0
_hex
dw '0123456789ABCDEF'
_RFID_Data
dw 1,1,1,1, 2,2,2,2, 3,3,3,3, $de,$ad,$be,$ef
;
TagEmulator
_RFID_DataEnd
dw 0
; TagEmulator
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
55
another fun project. The real adventure
will be implementing the forward link,
but that will require hardware changes.
I
and displays your data. Listing 2 is the
output from the SAMSys LF reader
used to verify my prototype.
NEXT STEP
Where to go from here? Well, you
could easily modify the sample program
to run, say, RS-232 data to the air inter-
face. You could experiment with differ-
ent data lengths and formats, or you
could cycle your data so that everything
you want to say is presented over a set of
reader output lines. As you experiment,
you may notice that the data coming out
of the RFID reader is sometimes different
from what you had intended. Most RFID
tags implement a CRC to keep that from
happening. One of the great things about
the e5551 is that the tag enforces no
CRC, so you can implement readers (and
they can implement tags) fairly easily.
The downside is that your data has no
error protection. Implementing error pro-
tection at the application layer would be
Larry Martin is an embedded system
programmer in Research Triangle Park,
North Carolina. He got into embedded
systems after working for 10 years as
an electronics technician. He has
worked in the nuclear, medical, aero-
space, and telecom industries, and is
now the senior programmer for RFID
startup SAMSys Technologies. You may
contact Larry at Larry@GlueLogix.com.
SOURCES
e5551 Tag
Atmel Corp.
(408) 441-0311
www.atmel.com
LF reader
SAMSys Technologies, Inc.
(905) 707-0404
www.samsys.com
Scenix SX28 Prototype board
Parallax, Inc.
(916) 624-8333
www.parallax.com
PROJECT FILES
To download the code, go to ftp.
circuitcellar.com/pub/Circuit_
Cellar/2004/163.
RESOURCE
Atmel Corp., “e5551: Standard R/W
Identification IC with Anticollision,”
rev. A3, October 2000.
Listing 2—
The output from the SAMSys LF reader is used to verify the prototype.
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
{Rd,d:010101010202020203030303DEADBEEF,t:T128M;04
Photo 1—
The RFID reader was used to read the tag
producing the output shown in Listing 2. The circuit
board is the Scenix SX28 demo board by Parallax.
That board is the TTL signal source. Black wires carry
common. The clear speaker wire provides base voltage
from Scenix rb.4 to the transistor. The green wire car-
ries collector current from the top of the LC tank.
varies by more than 1 or 2 Hz, which
may happen during major load or gener-
ation faults.
Although most electric clocks now
use quartz-crystal oscillators, the utili-
ties ensure that the total number of
cycles per day remains correct within
about 10 cycles. The adjustments occur
on the hour or half hour by varying the
frequency approximately 0.02 Hz.
In addition to the desired frequency
variations, the power line carries all man-
ner of hash: X10 signals, power line com-
munications signals, lamp dimmer noise,
motor commutator spikes, and other
ABOVE THE GROUND PLANE
by Ed Nisley
56
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
F
iltering can enhance a desired signal
or reject unwanted signals. The circuit-
ry in my December 2003 column con-
verted a 10-MHz sine wave into an
11.25-MHz microcontroller clock by
successively extracting the third har-
monic of square waves (“Multiplying,
Dividing, and Filtering,” Circuit Cellar
161). This month, the filter extracts the
fundamental 60-Hz power line signal.
The two frequencies meet inside a
microcontroller, and I’ll you show why
a simple combination of hardware and
firmware squanders most of the resolu-
tion implied by a GPS-locked reference
clock. A microcon-
troller may be vital to
your design, but with-
out a little care, it can
convert those last few
digits into noise.
FEEL THE POWER
The nominal North
American power line fre-
quency is 60 Hz. Power
generation depends on
rotating machines,
which change their speed
depending on the average
electrical load, with fre-
quency regulation on the
order of 0.1%, or
0.06 Hz. Automatic pro-
tection circuits discon-
nect parts of the grid
when the frequency
garbage. The first task is to get rid of that
junk by extracting the 60-Hz component.
The easiest way to do that is to borrow
a trick from FM radio circuitry: throw
away all the amplitude information.
The power supply shown in Figure 1
has two functions. The lower row of
parts is an ordinary full wave-rectified
and regulated 5-VDC source, while the
upper row produces a 60-Hz square
wave from the transformer’s output.
The input voltage is about 10 V
P
,
and the optoisolator turns on and off
at about 1 V. Unless the noise occurs at
the switching point or is large enough
to push the voltage
back through the
switching threshold, it
will have no effect on
the output. The
optoisolator acts as a
voltage limiter that
saturates on either side
of its 1-V threshold.
The LM311 com-
parator converts that
soft-edged square wave
into a crisp digital sig-
nal that eliminates the
last traces of its analog
heritage. Next, a band-
pass filter must select
the 60-Hz fundamen-
tal of the square wave
and, in so doing, con-
vert it to the analog
domain. All you need
Filters and Firmware
As Ed explains, filtering can be used to enhance desired signals or refuse unwanted ones.
In his December 2003 column, he explained how his circuitry converted a 10-MHz sine wave
into an 11.25-MHz microcontroller clock. This month, Ed shows you how another filter
extracts the 60-Hz power line signal. And, he explains why a combination of hardware and
firmware squanders most of the resolution implied by a GPS-locked reference clock.
Figure 1—
The optoisolator and LM311 comparator produce a reasonably square 60-Hz signal from
the AC wall wart. The remainder of the power supply is entirely conventional.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
57
is a band-pass filter centered at 60 Hz.
The same formulas that apply to a
band-pass filter at 10 MHz work just
as well at 60 Hz. In fact, any lumped-
component filter design can be scaled
to any frequency. Assuming that the
new filter has the same input and out-
put impedances, simply multiplying
the existing inductances and capaci-
tances by the ratio of the two frequen-
cies will do the job.
For example, to convert the aforemen-
tioned 15-MHz filter to a 60-Hz center
frequency, multiply the L and C values by:
The inductors become 375 mH, and
the capacitors jump to 7.7 µF. Those
are huge components, particularly
250 000
15
60
,
=
10
6
×
because magnetic materials don’t work
well at 60 Hz. In fact, stock PC-board
inductors top out in the low millihenry
range, so obtaining a few hundred mil-
lihenrys poses a major problem.
Fortunately, there is a better way for
many low-frequency filter applications.
A switched-capacitor filter takes advan-
tage of the precise component matching
available on integrated circuit chips to
implement filters that don’t require
hulking inductors or capacitors.
SWITCHED CAPACITORS
The MAX267 in the upper-left corner
of Photo 1 implements a 60-Hz band-pass
filter with a Q of 16 in about one square
inch of board space. The only reason it’s
that big is because I brought out its pin-
programming leads to jumpers for easy
tweaking, as shown in Figure 2.
Switched-capacitor filters are basically
Figure 2—
A stable and accurate 11.25-MHz clock from a GPS frequency standard meets a 60-Hz signal derived from the utility power line in an AT89C52 microcontroller. The
measured frequency value appears on an LCD panel for viewing and goes out the serial port for logging. The MAX267 band-pass filter is jumper-configured for a 60-Hz center
frequency with Q = 16. The MAX267 normally runs from symmetric ±5-V supplies, but here it uses 5 V/2.5 V and ground.
Photo 1—
The AT89C52 in its hulking ZIF socket domi-
nates the board. The MAX267 switched-capacitor
band-pass filter in the upper-left corner is the key com-
ponent. The 74C244 in the upper-right corner produces
the –5-V LCD bias voltage through a capacitor charge
pump. The black coax delivers the CPU’s 11.25-MHz
clock signal derived from my GPS frequency standard.
58
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
resistor-capacitor filters in disguise. The
datasheets and app notes explain how the
circuitry simulates high-value resistors
by switching capacitors in and out of the
signal path. They also show how combi-
nations of switched-capacitor RC net-
works and op-amps within a single chip
can produce low-pass, high-pass, band-
pass, and band-reject filter responses.
In addition to the basic filter function,
you also can choose the shape of the fil-
ter response from a list of the usual sus-
pects: Bessel, Chebyshev (with a variety
of spellings), Butterworth, elliptical, and
so forth. The steepness of the filter cut-
offs also may be programmable. In short,
you can implement nearly any type of
filter you need with a switched-capaci-
tor filter chip and perhaps a few external
resistors and op-amps. You definitely
won’t need any inductors!
Any given chip provides only a subset
of all those features. The MAX267, for
example, includes two second-order band-
pass filter sections and an
uncommitted op-amp. I used
one filter section, because I did-
n’t need steep skirts or dramatic
stopband performance.
The clock input to a
switched-capacitor filter deter-
mines its center or corner fre-
quency, linking the stability of
the filter to the stability of the
clock. An on-chip frequency
divider sets the ratio between
the external clock and the fil-
ter’s frequency. The F inputs
on the MAX267 select one of
32 ratios between about 100
and 200; therefore, the input
clock must be between 6 and
12 kHz to produce a 60-Hz
center frequency.
I used 74HC161 counters
rather than flip-flops in the
9:8 frequency multiplier
simply because I had them
on hand. The final divider
produced the 11.25-MHz
microcontroller clock,
but it also generated
1.406 MHz from its low-
order bit. That’s a factor of
117 higher than 12 kHz.
Hmm, dividing
1.406 MHz by 128 produces
10.984 kHz. Bingo! I glued
an old CD4020 14-stage binary divider
to the multiplier board in dead-bug style
and used its Q7 output. Setting the
MAX267’s F inputs to 26 (hex 1A)
divides 10.98 kHz by 182.21 for a center
frequency of 60.28 Hz. Close enough!
The Q inputs set the filter’s Q, the
ratio between its center frequency and
bandwidth. The 127 possible values (Q =
0 turns the filter off) range from Q = 0.5
to 64. I picked a 4-Hz bandwidth (Q = 16)
as a compromise between the expected
power-line variation and the need to
filter out extraneous signals.
Photo 2 shows the result: a not-
quite-square 60 Hz from the compara-
tor becomes a clean, symmetric sine
wave. I used a signal generator to verify
the center frequency and bandwidth,
which were exactly as predicted.
Your application may require careful
attention to the filter shape, in which
case combining the two filter sections
using the op-amp and some external resis-
tors will produce a classic filter. Maxim
provides some filter design software that
should help, but it was written back in
the DOS days and doesn’t run on any of
the Windows or Linux boxes I now use.
Fortunately, the datasheets include all the
relevant formulas and look-up tables.
Switched-capacitor filters have one
major shortcoming: their output
sports a breathtaking amount of clock
feed-through noise. Photo 3 shows the
choppy output direct from the chip.
Because the ratio between the clock
and filter frequencies is at least 100
(182 in this design), a simple low-pass
RC filter easily eliminates the noise.
Another LM311 digitizes the filtered
sine wave to drive a 74HC74 dual flip-
flop that produces 30- and 15-Hz square
waves. Jumper SJ13 connects the 15-Hz
signal to the 89C52’s T2EX input.
That’s the final step in the electronic
domain. From here on, it’s all firmware!
FIRMWARE
The micro drives two output devices.
I used a small graphics LCD
panel as a front-panel readout
and a serial port for long-term
data logging on a PC. That’s all
standard stuff that you can read
about in the downloadable files
posted on the Circuit Cellar ftp
site, so I’ll ignore it here.
The Timer2 hardware in
8052-class microcontrollers
includes a register that cap-
tures the Timer2 count at a
falling edge on the T2EX pin.
Measuring the width of a
pulse thus requires nothing
more than starting Timer2
when the pulse goes high,
waiting for the hardware to
signal that the pulse has
ended, and then reading the
Photo 3—
Capacitor filters suffer from clock feed
through, as shown in the stair-stepped left trace. A
one-pole RC filter produces the right trace. An LM311
converts this back into a digital signal.
Photo 2—
The MAX267 band-pass filter isolates the fundamental fre-
quency of the not-quite-square power line signal. A bandwidth of 4 Hz
allows small frequency variations around the nominal 60 Hz.
Photo 4—
The power line frequency varied from approximately 59.960 to 60.050 Hz
over the course of 50 hours during a weekend with an average of 60.003 Hz,
which indicates a residual measurement error of one CPU machine cycle. The
Bezier smoothing in this plot removes short-term variations and reduces the peak
values to make the trends more visible.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
59
capture register. Listing 1 shows the
few instructions at each pulse edge.
The
JNB T2EX,$ instruction is a two-
cycle spin loop that waits for the rising
edge of the pulse on the T2EX pin and
introduces zero to two cycles of delay.
The
SETB TR2 instruction adds another
cycle before Timer2 begins ticking, so
the total delay averages two cycles.
The 8051’s edge-detection hardware
requires that the signal on T2EX be
high on one cycle and low on the next
before recording the transition and cap-
turing Timer2 on the following cycle.
This introduces one to two cycles of
delay, an average of 1.5 cycles.
The two delays partially cancel out,
leaving the measured pulse width about
half a cycle too short with a jitter of up
to three machine cycles. That has a sig-
nificant effect on the accuracy and reso-
lution of the results.
The 15-Hz square wave’s pulse width
at T2EX is two 60-Hz cycles wide, or
33.333 ms, exactly 31,250 counts in
Timer2. Dividing that count by two gives
the period of a single 60-Hz cycle: 15,625
counts. Converting from a period meas-
ured in machine cycles to a frequency in
hertz uses the following equation:
15,625
60
1000
×
×
period
The factor of 1000 provides three deci-
mal places of frequency resolution in
an integer variable: 60.000 Hz is repre-
sented as 60,000. For obvious reasons,
the firmware uses 32-bit integers for
all these calculations.
However, a one-machine-cycle error
in the pulse width measurement causes
a frequency error of 0.004 Hz. Three
cycles of pulse-width jitter becomes
0.012 Hz of frequency jitter. Any error
in the 11.25-MHz clock looks complete-
ly irrelevant next to those numbers!
Halving a double-width pulse
reduces the average error and measure-
ment jitter by a factor of two, but the
resolution remains 0.004 Hz. The
microcontroller hardware thus limits
the results to about 0.01%, roughly
the same as the grid’s regulation. If
you want precise time measurements,
you can’t use a bare microcontroller.
The firmware averages 36 succes-
sive frequency measurements, which
is a simple form of digital filtering
that takes about 5 s. It then displays
the result and sends five ASCII digits,
without a decimal point and ending
with a linefeed character, to the serial
port. A terminal program can capture
that text and tuck one day’s worth of
data into a 100-KB file.
Photo 4 shows 50 h of frequency varia-
tion during a holiday weekend. Importing
and manipulating a file of 36,000 integers
brings an ordinary spreadsheet program to
its knees, so I used Gnuplot to display the
samples. A Python program reported the
overall average frequency was 60.003 Hz,
with a range of 59.956 to 60.048 Hz.
That 0.003-Hz error is most likely the
result of the measurement technique
rather than the power line because it’s
pretty close to one extra cycle. As they
say, more study is needed.
CONTACT RELEASE
The firmware is about 4 KB long, but
most of that deals with the LCD panel
and can be easily stripped out. In fact,
the essential code with just the serial
output would probably fit neatly in a
PIC. Feel free to add features, improve
the sampling technique, and let me
know how it works out.
Now go forth and filter!
I
Listing 1—
The 89C52’s Timer2 provides a convenient way to measure the input pulse width. The code
starts Timer2 when the input goes high and waits until the hardware captures the timer’s value on the falling
edge, although starting and stopping the timer introduces a significant amount of jitter.
WORD TMR_GetPW(void) {
WORD retval;
setbit(T2EX); // set high to allow inputs
//--- Wait for next falling edge
// timing here is not critical
clrbit(EXF2);
asm {
JNB EXF2,$-2 // goes high on falling edge
}
//--- Set up and capture the pulse
// timing is very critical...
clrbit(EXF2); // clear timer capture flag
clrbit(TR2); // ensure Timer 2 is off
TH2 = TL2 = 0; // start count from zero
asm {
JNB T2EX,$ // stall until rising edge
SETB TR2 // start T2
JNB EXF2,$ // high on falling edge
}
//--- Return captured pulse width
retval = RCAP2H;
retval = (retval << 8) + RCAP2L;
return retval;
}
PROJECT FILES
RESOURCE
North American Electric Reliability
Council, “NERC Operating
Manual,” October 10, 2003,
www.nerc.com.
SOURCES
AT89C52 Microcontroller
Atmel Corp.
www.atmel.com
Micro-C developer’s kit
Dunfield Development Systems
www.dunfield.com
Gnuplot data plotting software
www.gnuplot.info
Python programming language
www.python.org
Ed Nisley is an E.E., P.E., and author
living in Poughkeepsie, NY. You may
reach him at ed.04.nisley@pobox.com.
Type “Circuit Cellar” in the subject
line to evade the spam filters.
Technologies announced its Airborne
module at the Sensors Expo in
Anaheim, California last September, I
ordered an evaluation kit on the spot. I
believe that my purchase order, which
is written on the back of one of my
business cards, was their first order!
The Airborne evaluation kit arrived
promptly (see Photo 1). I was surprised
that it was completely turnkey. Even
though I have Wi-Fi in my office, they
assume the worst and provide a complete
package, which includes all the imagina-
ble cables as well as a Netgear Wi-Fi
Gateway. Following the quick-start guide,
I had the demo up and running quickly.
The Airborne module is designed to
mount directly to my PCB. Although
it has a 36-pin connector, many of the
pins may be left open (see Figure 1).
Unlike the PC Card dumb radios,
the Airborne module is a complete
application processor that combines
60
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
I
have built scores of embedded
devices ranging from banking terminals
to semiconductor fabrication con-
trollers. These devices have used a vari-
ety of processors from 4 to 32 bits. The
nearly universal theme of these embed-
ded devices has been communications.
Few devices exist as islands unto them-
selves. I have used RS-232, RS-422,
RS-485, LonWorks, Ethernet, and oth-
ers. I am always on the lookout for a
better way of communicating.
Wireless communications always have
been attractive. Eliminating wires makes
the product look cleaner and simplifies
connecting. At one of my prior compa-
nies, we did some pioneering work
15 years ago networking VHF radios.
Those industrial products made it to mar-
ket in spite of being slow and expensive
(approximately $1000 per node). This sys-
tem helped me understand the issues and
complexities of the radio media. The
design problems—such as interference,
data dropouts, hidden nodes, and roaming
across access points—have not changed,
but they have been solved and stan-
dardized with 802.11. (Well, at least
802.11b 11 Mbps is stable.)
I have been enticed by some of the low-
cost radio modems. Many of them work
in the 450-MHz industrial band. They are
attractive because of their low cost and
the fact that they are low power/unli-
censed. But I always go back to the prob-
lems that we had with our VHF network:
to get a good, reliable system, we would
be inventing RF-friendly protocols that
deal with temporary interference recov-
ery, frequency hopping (if supported by
the radio), and so on. Suddenly, my time-
saver technology becomes a time-sink
Wireless Water Heater
Some people like to remotely start their cars when it’s cold outside. Dan took this idea one
step further by Internet-enabling his mountainside retreat’s hydronics system. The Airborne-
based system allows him to warm the house well in advance of his arrival.
quagmire. So, I go back to tried-and-true
options like Ethernet and RS-232.
802.11 MODULES
The price of PC card 802.11b mod-
ules has fallen through the floor. I
often see cards from reputable compa-
nies advertised for approximately $20.
This component price is attractive
and fits great into WinCE solutions.
Just add a PC card interface and go.
Unfortunately, most of my deeply
embedded designs are cost-sensitive.
Doing a WinCE design adds between $50
and $75 for bigger CPUs, more memory,
and a PC card socket. So, a $20 Wi-Fi
card really costs between $70 and $95
in my design. Consequently, I have not
jumped on using PC Card modules.
DPAC AIRBORNE WI-FI MODULE
I had been looking for an embedded
RF solution for years, so when DPAC
FEATURE ARTICLE
by Dan Beadle
SRAM
128K × 3
Flash
memory
512K × 3
Application
processor
Web server
RTOS
TCP/IP stack
Command interface
I/O support
802.11b
Baseband
processor
MAC
RF
transceiver
VREG
2.5 V
Ground
POST
CONN
LINK
RF Status
V
DD
3.3 V
GPIO
Analog
SPI
Tx
Rx
CTS
RTS
ISP/Debug
2.5-V Ref
802.11b Radio
T/R
A/B
External
antenna
Airborne wireless LAN node module
Figure 1—
The Airborne module includes everything needed for remote data acquisition and control.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
61
ter reliability. My next thought
was to use simple copper to do
the hook-up. I started planning
a cable from my office/DSL
entry up to the logical thermo-
stat location. Then I procrasti-
nated. I could not bring myself
to run the wires along the sur-
face of my redwood paneling.
(And it was not at all feasible
to remove the paneling.)
Wireless makes the prob-
lem a lot simpler: there are no
wires to run, and the applica-
tions processor and digital I/O
on the module make the
hardware design trivial.
Normally, I set all of my thermostats
down around 50°F to keep the pipes
from freezing. My first-cut strategy was
to simply set the living room thermo-
stat to 70°F and then use the DPAC
module to disable it. The living room
might drop below 50°F, but enough
heat will transfer from the other 50°F
zones to keep it from freezing. Then,
before going up the mountain, I would
VPN into my desk computer and use it
to access the Airborne web server and
turn on the living room thermostat via
a relay connected to a digital output.
Kludgy? I guess, but it’s the first-
generation prototype (see Figure 2).
The first release of the Airborne web
server does not allow me to directly
control the digital I/O from the web
server. But it does provide a simple
way to do it via telnet by issuing com-
mand line interpreter (CLI) commands.
To provide a basic layer of security,
the Airborne server requires user-
name/password authentication. After
authentication, I have access to a rich
set of CLI commands that let me con-
trol all aspects of the module (e.g.,
radio settings, network settings, and
digital I/O settings). In my case, I want-
ed to use port F2, an available GPIO.
First, the port must be set to output
with the
IO-Dir F2 Out CLI com-
mand, which sets the port direction
register to output. Then, controlling
the relay is as simple as
IO-Write F2 1
to set the relay on, and therefore
enable it to warm my house to 70°F.
Although it isn’t perfect, I decided to
start with this simple solution in an
effort to protect against the possibility
the radio and a 120-MIPS web
server CPU into a small 1
″
× 1.5
″
package. All of this costs
approximately $80. After a lit-
tle fumbling to reread the
directions (Who really does
that?), I was browsing the
Airborne server from my
desktop via two wireless hops.
GETTING EMBEDDED
The Airborne module is
designed for embedded appli-
cations. Its primary purpose
appears to be for remote sens-
ing and control. Interfaces
include eight digital I/O ports
(3.3- and 5-V tolerant), eight analog
10-bit ADC inputs with a built-in
2.5-V reference, and one high-speed
serial port (up to 921.6 kbps)
My imagination started running wild
with ideas about how to apply this. I
immediately incorporated Airborne
into a bid for a system to monitor the
status of a medical infusion pump. For
that design, I plan to mount the module
on a PCB with an RS-232 level shifter
and a power supply, and I instantly will
have an RS-232-to-Wi-Fi converter.
More importantly, I can manage the
physical packaging to attach it to my
customer’s pump.
WIRELESS HEATER CONTROL
My mountain home, where I have
vacationed for years, is well insulated,
making it a snap for the heater system
to keep warm. I have a small, efficient
heater; however, it takes forever to
warm the house from a 50°F standby
to a livable 68°F. Typically, I arrive
late and shiver in my jacket for three
or four hours until the house warms
up—and that does not warm the entire
house, just the portion needed to get
through the night.
I had been thinking for a while about
Internet-enabling the system. The idea
was to turn on the heater before we
start up the mountain. I have DSL at
the house with a fixed IP. So, it seemed
like it would be a simple task to enable
a thermostat. I considered using an X10
thermostat, but, after a few of our
X10-enabled lights found a mind of
their own, I decided that I wanted bet-
Figure 2—
The heater water flow valves are controlled by a relay driven by the
Airborne’s DIO port.
Power
jack
DB25F
DB9F
ISP and debug header
Serial port
9-V
Battery
Power
supply
Power
I/O Signals
Prototyping
area
Peripheral
Mixed signal
I/O
Communication
High-speed
serial
TX
RTS RX
CTS
RS-232
Wireless
LAN node
module
ANT1
ANT2
POST
LINK
WLN CFG
CONNECT
G0
G1
RF ACT
RESET
G2
G3
RP-SMA
External
antenna
Header for development access
Figure 3—
The evaluation kit includes a prototyping area and headers to connect to all of the module pins for easy
breadboarding.
62
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
heat exchanger/holding tank to supply
hot water to the faucets in the house.
The single boiler concept allows an
extremely efficient heater to supply all
of the house’s heating needs. Although
my system was state-of-the-art when
it was installed a few years ago, it is
not without limitations.
For one thing, I often find myself tak-
ing a cold shower in the morning. I
have found the 50-gallon water supply
more than adequate for three or four
people, but when I have a house full of
guests, I often run out of hot water. The
cooler water refilling the holding tank
of my system failing and the house
freezing—not a pleasant thought.
IN HOT WATER
I have a hydronics system with a sin-
gle boiler for both my space heating and
water heating needs. The system is kind
of like the boiler/radiator system, except
the water is not boiled, it’s just heated to
between 180° and 200°F and circulated to
the various rooms. The same hot water
is circulated over and over throughout
the house to rooms calling for heat. The
lower temperature results in lower pres-
sures, which allows heat radiators to be
placed in creative ways. Plastic PEX
coils are placed in the floor, along the
walls, and even in the towel holders.
The same recirculated water is fed to a
explains some of this. But I have specu-
lated that most of the slow recovery in
winter is because the energy from the
combustion is going not only to the
water tank but also to warm the rooms.
This seems really stupid. The rooms are
well insulated and may only drop 1°
per hour, but the hot water tank drops
several degrees per minute. Why bother
heating four space zones when the
water tank needs to heat my shower?
My ultimate goal is to reduce the
heating control system to an embed-
ded processor bolted to the heater sys-
tem in the basement. Before designing
Figure 4—
The selected sensors interface directly to
the Airborne’s ADC ports.
Task
Server
Comment
Listing
Data presentation
ASPX Server (1) (see Figure 3) Focuses on the user experience Heater.aspx
Data server
Web service (2)
Wraps the data and presents it
GetZones.asmx
over the ’Net to the ASPX server
Communicating with Web service (2)
Interfaces to LAN via TCP/IP
HeaterController
Airborne server
to Wi-Fi
.vb CLI.vb
Data acquisition
Airborne module (3)
Acquires ADC Counts
Table 1—
In addition to listing the tasks, I’ve provided you with names of the appropriate files, which you may
download from the Circuit Cellar ftp site.
64
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
the system, however, I
wanted to experiment
with algorithms. I could do
that faster on my desktop.
So, the next step was data
gathering. The most criti-
cal data seemed to be
monitoring calls for heat
from the various zones and
understanding the heat
exchanger efficiencies. The
data I wanted is available
at the heater, not in my office.
The next step in the process of
understanding the system had to do
with monitoring temperatures coming
out of the boiler and returning from
each of the five zones (four space
heating zones and one water heating
zone). To do that, I needed to connect
temperature sensors to the Airborne
wireless module. I elected to use the
evaluation kit because I could directly
connect the sensors (see Figure 3).
I chose a couple simple temperature
sensors from National Semiconductor,
the LM35DZ and LM61CIZ. I selected
these two sensors for their simple
transfer functions and to cover the
needed temperature ranges.
The LM35DZ has a range from 0° to
100°C. Because the water should nei-
ther freeze nor boil, this sensor is ade-
quate for the recirculation system. It
provides a simple output of 10 mV per
1°C. The 0- to 1000-mV output is with-
in the 2.5-V range of the analog-to-digi-
tal converter (ADC). The LM61CIZ is
used for ambient temperatures, which
can reach to –15°C on occasion. It pro-
vides a simple output of 600 mV + 10 mV
per 1°C for temperatures from –30° to
100°C. Both sensors use the same
hook-up (see Figure 4).
Like most analog-
to-digital converters,
the output is in
counts rather than in
direct physical meas-
urements. The
Airborne module ana-
log-to-digital convert-
er provides 2
10
steps of
the 2.5-V reference, or
about 2.4 mV per
count. Applying cer-
tain formulas converts counts back to
temperature. For the LM35DZ:
For the LM61CIZ:
.NET WEB SERVER
I need to be able to access my heater
controller over the ’Net for it to be
useful. I have been told that the next
version of the DPAC system will let
me directly view the temperatures and
control the relays via Java Script. For
now, I have to issue Airborne CLI
commands. More importantly, I must
have a degree of security. I don’t want
hackers reprogramming my shower.
I decided to use .NET technology to
build a simple, secure system to access
the Airborne server. The general topol-
ogy is shown in Figure 5. .NET allows
processing to be compartmentalized
across servers and disciplines. Refer to
Table 1 to see how I broke up the
tasks of displaying the current temper-
atures.
This small, but powerful, system
has several important benefits. For
instance, the complexities of the data
acquisition system are hidden from the
.aspx web programmer. Furthermore,
the data server can be anywhere, and
data acquisition and display are decou-
pled for simpler maintenance.
Let’s dig into the key files. I have
spent most of my career programming
in C or C++. With the release of .NET,
I added VB.NET to my tool kit. Unlike
prior versions of VB, I consider
Temp
ADC
V
.
.
=
Counts
V
Counts
mV
×
×
2 5
1024
1000
6
−
0
00 mV
×
°
10 C
mV
mV
V
Temp
= ADC Counts
V
Counts
mV
= mV
×
×
×
2 5
1024
1000
.
.
1
10 C
= ADC
V
Counts
mV
10 C
°
×
×
×
°
2 5
1024
1000
.
V
m
mV
Photo 1a—
T
he Airborne evaluation kit comes with a Wi-Fi access point, cables, and a prototyping
area.
b—
The DPAC module provides a complete Wi-Fi embedded processor in 1.5 square inches.
a)
b)
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
65
nection with the host on port 23. As
with the other routines, most of the
code involves catching errors. I elected
to dump them to the debug console
and continue.
Read and Send routines perform
similar functions. Windows uses 2-byte
Unicode characters. The ’Net is based
on ASCII. The bulk of the routines
call the system encoding methods to
convert between ASCII and Unicode.
They also use the socket stream
underlying the
TcpClient to perform
the actual reads and writes from and
to the network link.
VB.NET a real language. One of the
key features is its full support for
object-oriented programming (OOP). I
find I program desktop applications
much faster than in the past.
.NET AND INHERITANCE
TCP/IP clients are extremely simple
with .NET. The CLI Class inherits from
the .NET built-in class
TcpClient.
This provides a rich wrapper around the
lower-level
Sockets class. Listing 1
shows the Class Inheritance for CLI and
its subclass,
HeaterController.
TcpClient, a built-in .NET class,
inherits from
Sockets, providing a
programmer-friendly wrapper to
Windows TCP/IP socket services.
CLI further refines
TcpClient to
provide telnet connection setup and
conversion between Unicode and
ANSII. Finally,
HeaterController
inherits these tools to do the real
work of sending CLI commands to
the Airborne controller and format-
ting the results (see Figure 6).
CLI.VB
CLI.VB provides a TCP/IP link to
the Wi-Fi bridge and ultimately access
to the Airborne module (see Listing 1).
You may download the complete list-
ing for this file and all of the other
files from the Circuit Cellar ftp site.
As you can see in Listing 1, there
are only a couple of functions that I
added in my CLI subclass:
Open,
Read, and SendCR. The Open routine
is where the magic happens. The
inherited
TcpClient Connect
method is used to handle all of the
details of establishing a telnet con-
HeaterController
Zone temperature
Ambient temperature
CLI
Open Telnet connection
Unicode read/send CR
Tcp Client
–Sockets wrapper
Sockets
–TCP/IP Routines
Figure 6—
The HeaterController borrows features from
the TCPClient through inheritance.
’Net
ASPX Web server
1
2
3
Web
service
server
Wi-Fi base
station
C
Figure 5—
Serving up the current temperature involves
several computers, a Wi-Fi access point, and the
DPAC Airborne module.
66
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
HeaterController.VB
After getting the CLI layer debugged,
I decided I needed more functionality.
To keep things simple, I decided to fur-
ther subclass CLI to add new function-
ality. So, I created
HeaterController,
which inherits from CLI, which inher-
its from
TcpClient, and so on.
HeaterController’s job is to issue
the actual CLI commands needed to
manipulate the Airborne application
layer. The key CLI commands are list-
ed in Table 2.
I have included three public proper-
ties:
RelayState (r/w), AmbientTemp
(ro), and
ZoneTemp (ro). Other private
functions provide the interface to the
Airborne analog-to-digital converters
and perform the count-to-temperature
calculations.
The helper routine
ADC(n) gets the
counts for a given Airborne port by
sending
adc-read g followed by the
port number, n. It then reads the
response and converts the hex count
string to an integer.
WEB SERVICE WRAPPER
I could put the HeaterController.vb
right in the .ASPX file, but that would
mean hosting the display page on my
home server. I don’t like that idea
from a security standpoint. Instead, I
prefer to use a web service that sits
behind a firewall.
GetZones.asmx provides a simple
WebMethod wrapper around the
HeaterController object (see
Listing 2). A cool thing about web servic-
es is how easy they are to test. I invoked
the service directly from a web browser.
Note that the web service passes an
array of floating-point temperatures,
which are all in a readable XML format.
The
Zones WebMethod builds an
array and populates it by creating a
HeaterController object and using
it to get each
ZoneTemp. It then closes
the object to drop the telnet connec-
tion to the Airborne module.
SERVING UP THE ’NET
Heater.aspx uses .NET ’Net controls
to display the data (see Listing 2).
The
Update routine does most of the
work by creating a web services object
and using it to access the
Zones
WebMethod running on a different
(and firewalled) computer. Update
simply fetches the temperatures for
each zone and populates a text box.
Two buttons are provided. One con-
verts between Fahrenheit and Celsius,
and the other forces an immediate
update of the web page.
I used one little trick to store the
F/C state. With web pages, each server
query is an independent event. In the
old days, you had to perform a lot of
tricks to store state information. With
.NET, ’Net controls automatically
store their state from call to call. So, I
decided to store the unit’s type in an
invisible label, SelectedUnits.Text.
Other than that trick, the ASPX code
is plain vanilla.
Listing 1—
These excerpts from HeaterController.vb and CLI.vb use inheritance to access Windows TCP
sockets.
Imports System.Net.Sockets
******************************************************************
// Heater Controller - Inherits from CLI and TcpClient
// See HeaterController.vb on Circuit Cellar ftp site
******************************************************************
Public Class HeaterController
Inherits CLI
ReadOnly Property AmbientTemp() As Integer ' Ambient Temp in C
Get
Return LM65(2)
‘ Ambient is ADC port 2
End Get
End Property
' ADC Conversion Routine for Ambient
Private Function LM65(ByVal Port As Integer) As Integer ' Read LM65
Dim V As Single = ADC(Port) / 1024 * 2.5 * 100 - 60
Return Int(V + 0.5)
End Function
' ADC Access Routine
Private Function ADC(ByVal Port As Integer) As Integer
Me.SendCr("adc-read g" + Port.ToString())
System.Threading.Thread.Sleep(100) ' Wait for response
Dim R As String = Me.Read()
Dim i As Integer = R.IndexOf("0x") ' replace 0x with &h
If i >= 0 Then R = "&h" & R.Substring(i + 2)
Return Val(R)
End Function
' See Site for complete source
End Class
******************************************************************
// TCP/IP Class to talk to Airborne module
******************************************************************
Public Class CLI
Inherits TcpClient
Dim Stream As NetworkStream
' The Socket stream
' Open Telnet Connection with remote host
Overridable Sub Open(ByVal hostname As String)
Try
Me.Connect(hostname, 23)
' Open host on telnet port
Stream = GetStream()
‘ Use inherited method
Console.WriteLine("Telnet Connection Opened")
Catch e As SocketException
Console.WriteLine("SocketException: {0}", e)
End Try
End Sub
' Read response from Airborne
Function Read() As String
Dim Data As Byte() = New [Byte](256) {}
' Read the first batch of the TcpServer response bytes.
Dim n As Int32 = Stream.Read(Data, 0, Data.Length)
Dim s As String = System.Text.Encoding.ASCII.GetString(Data, 0, n)
Console.WriteLine("Read {0}", s)
Return s
End Function
' ..... Other methods
End Class
For obvious reasons, this public view
of my page does not expose the relay
control. Listing 3 gives a skeleton for
using the
HeaterService web service.
.NET calls this “consuming a serv-
ice.” The web page’s
Load routine sim-
ply creates a
WS object to connect to
the web service provider
Wi-FiHeater
on server
dan. It then invokes the
Zones method to return the array of
single precision temperatures. From
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
67
detect occupancy). Furthermore, they
will provide the option of overriding
preprogrammed temperatures, and
they will display current temperature
and target temperature.
In addition to using these sensors in
the rooms, I plan to put them outside
to monitor outside air temperature so I
can make better decisions. For exam-
ple, if there is a small spread between
the desired and actual temperature but
the sun is shining, should I heat now,
or wait for nature?
These will report to the heater con-
troller in the basement. I have decided to
go ahead and add a microcontroller to
manage the valves. The controller will do
all the things that typical zone setback
thermostats do, but it will also integrate
the outside sensors. And, for sure, it will
give priority to my shower! Stay tuned for
the ultimate Wi-Fi heater controller!
I
there, I simply format
them into a text box and
mark the update time.
WHERE FROM HERE?
Now that I am captur-
ing data, I am off to build
the ultimate temperature
management system. Sensors in each
room will monitor temperature, light-
ing, and motion (the latter two to help
PROJECT FILES
To download the code, go to ftp.cir-
cuitcellar.com/pub/Circuit_Cellar/
2004/163.
SOURCES
Airborne evaluation kit and
Airborne module
DPAC Technologies Corp.
(800) 642-4477
www.dpactech.com
LM35DZ and LM61CIZ
Temperature sensors
National Semiconductor Corp.
(800) 272-9959
www.national.com
Dan Beadle leads a contract product
development company that takes
products from concept to production.
Dan has been developing embedded
systems for more than 20 years. He
has a B.A. in Physics from UC Irvine
and an M.B.A. from Pepperdine
University. You may contact him at
dan.beadle@inclinesoftworks.com.
Listing 2—
Web services wrap the
HeaterController
object and convert to XML—all behind the scenes.
******************************************************************
Excerpts from HeaterService
******************************************************************
Imports System.Web.Services
<System.Web.Services.WebService(Namespace:="http://tempuri.org/
HeaterService/Service1")> _
Public Class WiFiHeater
Inherits System.Web.Services.WebService
<WebMethod()> _
Public Function Zones() As Single()
Dim Z(6) As Single
' Array of floats
' Create Object to access WiFi server
Dim Heater As New HeaterController("192.168.111.60")
' Local Address
Z(0) = 5
' Zones(0) holds number of real zones
Z(1) = Heater.ZoneTemp(1)
...
Z(5) = Heater.ZoneTemp(5)
Heater.Close()
Heater.Dispose()
Return Z
End Function
End Class
Listing 3—
These excerpts from Web Client demonstrate the consuming of a web service.
*****************************************************************
// Heater Web ASPX web page (DotNet)
*****************************************************************
Public Class WebForm1
Inherits System.Web.UI.Page
‘ Page Load Routine - first time loaded.
Private Sub Page_Load(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles MyBase.Load
Dim Ws As New dan.WiFiHeater
' create link to WebService on Dan
Dim Z() As Single = Ws.Zones()' Zones returns array of
temperatures
Dim i As Integer
TextBox1.Text = "" ' Clear out the text box
For i = 1 To 5
' display temp for each zone
TextBox1.Text += "Zone " & i.ToString & ": " & Units(Z(i))
+ vbCrLf
Next
lblUpdated.Text = "Last Updated " & Now.ToShortTimeString()
End Sub
End Class
CLI Command
Function
Example
Auth
Authenticate (log in)
auth user pw
io-write
Write to port bit
io-write g0 1
adc-read
Read ADC counts
adc-read g2
Table 2—
CLI commands are necessary for manipulating the Airborne
application layer. Note that Airborne requires lowercase commands.
68
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
E
ach time I look at my lawn (I use
the word “lawn” loosely), I can’t help
but think that if I would treat it to a bit
of weed killer, I would have a nicer-
looking yard. I don’t do this for a num-
ber of reasons. First, I like the look of
green, as opposed to brown dying weeds.
Second, I’d have to mow it on a weekly
basis rather than a monthly basis. My
lush green weeds seem to grow at a
much slower rate than my neighbor’s
patchy tufts of green grass. On the
sunny side of the yard, I have a crop of
nice green vegetation (albeit not grass).
On the shady side, I have a nice carpet
of cushy green moss—and moss
doesn’t need trimming at all! I
feel sorry for the lawn-care
folks who constantly call and
want to help me rid the area of
weeds. They just don’t get it.
I used to play golf. Yes, mani-
cured courses look great. But it
just isn’t high on my list of pri-
orities to sink a lot of money
into my lawn to bring it up to
perfection. I know someone
who hates grass enough to drop
mulch all over it. Now, he does-
n’t even need a lawn mower!
Although I haven’t gone to that
extreme, I’ll choose the ham-
mock over the mower and live
amongst my green weeds.
I keep with the ideas that
seem to work for me. As you
know, I’ve always been a big fan
of flash memory-based micro-
registers with most of the instructions
running in a single cycle. A well-defined
I/O structure with an internal oscillator,
timers, UART, SPI, pull-up resistors,
pulse width modulation, ADC, analog
comparator, and a watchdog timer limit
the need for external components. AVR
instructions minimize the size of your
program whether you write in C or
assembly. The AVR will optimize costs
and get your product to market quickly
by way of on-chip/in-system programma-
ble flash memory and EEPROM.
There are actually three separate
spaces mapped into an AVR microcon-
troller. The address space is a
linear 64 KB in a 16-bit word
format (16-bit instructions). The
program counter covers the
complete flash memory (word)
range of each part. There are
two data spaces, one for EEP-
ROM (when available) and the
other for SRAM. As you can see
in Figure 1, 32 general-purpose
registers (0x00–0x1F) combine
with the ALU to make up the
central core. The AVR uses
Harvard architecture (separate
memories and buses for pro-
gram and data). Almost half of
the instructions are executed in
one clock cycle with the CALL
and RET instructions requiring
up to five cycles. (They must
adjust the stack.)
In a typical ALU operation,
two operands are output from
The Growth of the
Atmel AVR Family
FROM THE BENCH by Jeff
Bachiochi
controllers. Atmel began its AVR line of
in-circuit programmable, flash memory-
based processors in 1997. What were only
four products just a few years ago have
blossomed into a dozen or so today. You
don’t get this kind of growth in a product
line unless the first seeds have produced
a bountiful harvest. Atmel credits this
to a soaring price performance level.
WHAT IS AVR?
The CPU—which was developed by
a pair of researchers in Trondheim,
Norway prior to 1995—resembles most
RISC processors, although it has smaller
The Atmel AVR family has been growing rapidly since its debut in the late 1990s. Today, you
have several AVR products to choose from when preparing for a project. This month, Jeff
delves deeper into the AVR story, and provides an example of how an AVR-based design
allows him to control a thermostat.
JTAG
Interface
Flash
memory
Four-wire in/out
OCD
Instruction
register
Instruction
register
Serial
peripheral
interface
Three-wire in/out
EEPROM
Program
counter
32 General-
purpose
registers
RAM
ALU
Watchdog
timer
I/O
ports
Interrupts
Timer/
counters
Control
lines
Analog
comparator
A/D
Converter
LCD
interface
USART
SPI
TWI
CPU
Figure 1—
The AVR CPU core uses 32 general-purpose registers having direct
access to the ALU. A generous portion of peripherals is interfaced through the
system address and data bus. Total ISP gives access to both flash memory and
optional EEPROM memories.
CONTEST PPRIMER
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
69
pair R0:R1. Branch instructions have
a relative offset of 7 bits (63 to –64).
Relative jumps and calls use a 12-bit off-
set (2047 to –2048). Indirect operations
use one of the 16-bit register pairs X, Y,
or Z (26:27, 28:29, or 30:31); therefore,
they can cover a 64-KB address range.
For devices with a larger address space,
the EIND register in extended I/O space
holds the upper bits of an extended
indirect operation.
A large group of the instructions
deals with bit manipulation and
branching based on the outcome of an
arithmetic, logic, or manipulation oper-
ation. This is ideal for control applica-
tions and makes tight code possible.
For a more detailed description of the
AVR’s innards, refer to my December
1998 column, “Learning to Fly with
Atmel’s AVR,” (Circuit Cellar 101).
BRANCHING OUT
It wasn’t so long ago that the first
AT90S part made its way onto the
scene, followed by the ATiny and
ATmega series. Today, the success of the
AVR core is a reflection of the growing
AVR family; it has enabled the product
line to branch out in many directions.
The AVR core can be found in FPSLIC,
the 5000- to 40,000-gate FPGA. It is also
used in the DVD/CD storage chipsets
(along with the ARM micro). Wireless
support comes from the SmartRF series
of AVR MicroTransmitters and Micro-
Transceivers. The secureAVR microcon-
trollers include a crypto-coprocessor
for secure encryption and authorization
functions. A range of USB controllers use
the AVR core supporting full-speed
USB 2.0. The ATmega series has expand-
ed and now includes AVR micros with
built-in LCD controller/drivers.
FPSLIC
You may remember Atmel’s 2001
Design Logic FPSLIC contest. The AVR
core in this SRAM-based FPGA gives
your design a high degree of system
level integration. The FPGA macro
library has plenty of custom peripher-
als, which help augment the feature-
packed fixed peripherals of the AVR
micro. An import feature of the FPGA
is the internal interrupt architecture
allowing rapid response to that circuit-
ry. A JTAG interface provides extensive
on-chip debug support and boundary
scan capabilities to the AVR ports.
The 3- to 3.6-V operating voltage
assures low-power consumption while
being 5-V I/O tolerant. Oscillator
speeds to 40 MHz can provide a
throughput of up to 30 MIPS. Both
instruction code and configuration is
loaded from EEPROM at power-up. The
core’s cache logic also allows for some
dynamic (no data loss) configuration
changes. FPSLIC can handle compute-
intensive arithmetic functions such as
those used in filters and transforms.
DVD/CD STORAGE CHIPSETS
Let’s face it, eight-tracks are dead.
(Although some people say they never
existed. When my son Kris asked why
some of my records had this little plas-
tic doohickey in the large hole, I knew
I was teetering on the edge of being
labeled Cro-Magnon.) The compact disk
media has officially stolen the show.
Even the 12
″
laserdisc is nothing but
junk because DVD formats push the
envelope of storage. A DVD/CD ATAPI
controller, servo controller, laser power
controller, amps, and pre-amps are nec-
essary to provide compact audio and
video enjoyment. The AVR core is used
in Atmel’s DVD/CD ATAPI chipset to
perform internal data path and buffer
management control.
SmartRF
Adding high-performance PLL-based
RF circuitry to the AVR core creates a
convenient and cost-sensitive solution
for wireless control and telemetry. The
transmitter solution has ultra-low
shutdown current until a button is
pressed. The microcontroller controls
the register file, the operation is executed,
and the result is stored back in the regis-
ter file in one clock cycle. Six of the 32
registers (0x1A–0x1F) can be used as three
16-bit indirect address register pointers
(X, Y, and Z) for data space addressing
(enabling efficient address calculations).
Address pointer register Z (0x1E–0x1F)
also can be used as an address pointer for
look-up tables in flash program memory.
The I/O memory space contains
64 addresses for CPU peripheral func-
tions as control registers, SPI, and
other I/O functions. The I/O memory
can be accessed directly, or as the data
space locations following those of the
register file (0x20–0x5F). Larger
devices have extended I/O addresses
(0x60–0xFF) in data space.
Figure 2 shows the linear make up of
the data space including the register file,
I/O registers, extended I/O registers, and
the internal data SRAM. On the
ATmega169, there are 1024 bytes of avail-
able RAM beginning at address 0x100.
INSTRUCTION SET
The RISC instruction set is broken into
five areas: arithmetic and logic, branch,
data movement, bit manipulation, and
CPU control. The instructions that
manipulate data use either direct address-
ing or indirect addressing. The former is
to a working register, I/O or extended I/O
register, or the SRAM. The latter is ref-
erenced by a 16-bit register, 16-bit register
with offset, or 16-bit register with a pre-
execution decrement or a post-execu-
tion increment of the register.
The instructions that manipulate the
program counter load a new address
either directly or indirectly (from a work-
ing register pair). When instructions deal
with retrieving from or storing to the
program memory (flash memory), the
16-bit register pair Z is used. Because
program addresses are word-sized (16
bits), Z’s LSB indicates which of the
bytes within the word to deal with.
Most operations that deal with two
registers can use any of the 32 working
registers (0–31). The operations that
include a constant (0–255) must use the
upper 16 working registers (16–31). For
those devices with a hardware multiply,
the result of an 8-bit multiplication with
two working registers is 16 bits. The
16-bit result is placed in working register
Data memory
32 Registers
64 I/O Registers
160 Ext I/O Registers
Internal SRAM
(1024 × 8)
0×0000 – 0×001F
0×0020 – 0×005F
0×0060 – 0×00FF
0×0100
Figure 2—
The data space consists of general-purpose
registers and I/O registers. Devices stuffed with periph-
erals use an extended I/O register space. Note that
1 KB of internal SRAM begins at address 0x100 for
the ATmega169.
70
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
power output while the
PLL uses the crystal to
maintain a stable carrier.
The transceiver solu-
tion brings secure com-
munication allowing
handshaking procedures.
Its flexible configuration
covers a best fit for
bandwidth, selectivity,
immunity, and range.
The RF receiver can supply a wake-up
signal to the microcontroller for power-
conserving measures when idle. Covering
the 400- to 950-MHz bands, the SmartRF
data throughput can reach 64 kbps.
SECURITY FOR SMARTCARDS
As we become more comfortable with
a cashless society, the risk of identity
theft continues to rise. We dislike being
held captive by a simple multidigit
number. In the future, transactions will
be based on more than just this fragile
key. Smartcards are becoming the new
cache. Without knowledge of the data
held securely within, it becomes use-
less to everyone but the owner. Thus,
the security of a smartcard is its most
valuable asset. The AVR architecture
becomes the hidden strength of the new
plastic via ISO 7816 external interfacing.
Security features must protect data
from not only direct software access
but also from hardware probing. The
secure AVR-based micros employ volt-
age and frequency control, secure lay-
out, and bus encryption security fea-
tures. Atmel’s commitment to support
is reflected in the application develop-
ment tools they make available for all
of the AVR products.
USB CONTROLLERS
Atmel understands the importance of
USB to the future of computing. It has an
extensive line of USB hubs, microcon-
trollers, and hosts. This guarantees that
the company will be part of that future.
Many products are based on AVR
microcontrollers offering low- and
full-speed USB peripherals. Low-power
AVR micros can run directly from the
USB bus thanks to internal 3.3-V regu-
lators. The array of on-board peripher-
als simplifies designing even the most
I/O-intensive user devices.
Software support includes the USB
54-Hz refresh rate (based
on a 3.58-MHz system
clock). This allows the
proper output signals to
be generated for the
LCD’s segments and four
back planes (commons).
Segments are mapped
into 20 data registers
(LCDDR0–19), with five
registers for each com-
mon (LCDDR0–5 for COM0, etc.). Only
25 bits are needed (one for each segment
output) in each group. That’s three full
bytes and the LSB of the fourth byte.
(The remaining bits are unused.)
Character data consists of 16 seg-
ments (14 for character segments and
two for glyph segments), with 4 bits in
each of the four back plane groups. This
puts the same 4 bits for character 1 and
2 into LCDDR0, 3 and 4 into LCDDR1,
and 5 and 6 into LCDDR2. Therefore,
the look-up table data can be masked
directly into 1 of 3 bytes (with the data
nibble swapped for even characters).
When a bit in one of these registers is
written with a one, the corresponding
LCD segment is enabled (masking the
reflectivity of the background and show-
ing up as black). Bits written with a zero
allow the segment to remain transpar-
ent. The glyphs share bit locations with
character segments with the same byte,
which requires masking bits when
updating data. This means that updating
the data for a character must not alter
the data for any glyphs and vice versa.
The
LCD_Update routine tests vari-
ables to determine which glyphs and
characters need to be updated. The mode
byte has four possibilities: H (heat), C
(cool), A (auto), and O (disabled). The Fan
byte indicates whether the fan is a one
(on) or a zero (auto). A byte value for
HVACSTATUS is dependent on mode,
temperature, and set point; it indicates
when the furnace/air-conditioner is
required to run. The values are “H” (call
for heat), “C” (call for cool), “I” (idle),
and “O” (disabled). Although the charac-
ter data comes from a look-up table con-
sisting of characters 0 through 9 followed
by “-,” “H,” “C,” “degree sign,” and “F,”
one of three displays can be requested.
The DISPLAYMODE byte can be one
of three values: 0x00 (temperature), 0x01
(heat set point), and 0x02 (cool set
library and applications Wizard. This
tool produces code, based on user input,
including USB descriptors, reports, and
even complete applications.
LCD CONTROLLERS
Almost every product that requires a
user interface takes advantage of an LCD
for rendering important information.
Whether the display has graphic glyphs
or alphanumeric characters, it’s just a
mater of segment control. Empowering
an AVR core controller with an LCD
controller simplifies your job. This
peripheral can driver up to 25 segments
and four back planes. To support the nec-
essary multiplexing, the controller sup-
ports various duty and biasing, as well as
flexible frame frequency control.
Atmel’s ATSTK500/502 starter kit is
a great platform for helping you design
applications for an AVR microcontroller
with a built-in LCD peripheral con-
troller. As I was working on last
month’s column, I thought virtual
peripherals were fine for demonstrating
a point, but I’m the kind of guy that
likes hardware. So naturally I was look-
ing for an alternative to the virtual ther-
mostat used to demonstrate an applica-
tion of the Lantronix XPort Ethernet-to-
serial ’Net-enabling device. The
ATmega169 has the right features to
demonstrate a true hardware applica-
tion of last month’s virtual thermostat.
STARTS WITH THE DISPLAY
The display supplied on the ATSTK502
has many glyphs as well as seven charac-
ters as seen in Photo 1a. I chose to use a
subset of this (see Photo 1b). The up-
and down-pointing arrowheads indi-
cate various enabled modes and func-
tions, while only four characters are
needed to show temperature.
The LCD controller is first initialized
for quarter duty, 3.0-V contrast, with a
Command type
Command
Fan
F0 or F1
Mode
MA, MH, MC, or MO
Heat set point
Hxx (where xx = HEATSETPOINTH, HEATSETPOINTL)
Cool set point
Cxx (where xx = COOLSETPOINTH, COOLSETPOINTL)
HVAC Status
SI, SH, SC, or SO
Temperature
Txx (where xx = TEMPH,TEMPL)
E0, E1, or E2
Table 1—
The thermostat sends these commands whenever a change occurs (i.e., you change
the heat set point or the temperature falls below the heat set point).
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
71
point). The temperature (DISPLAY-
MODE) displays the measured tempera-
ture of a thermistor displayed as “## °F”
(more on this later), while the set point
(DISPLAYMODEs) display “H- ##” (heat
set point) and “C-##” (cool set point).
THERMISTOR
A negative temperature coefficient
(NTC) thermistor is used as the lower
leg of a voltage divider with a 10-k
Ω
resistor to V
REF
. Because the thermis-
tor has a 10-k
Ω
resistance at 25°C,
the voltage at the junction of the two
devices (and the input to an A/D
channel) will be 0.5 V
REF
at room tem-
perature. The thermistor’s equation
for temperature is:
where
β
is 3450, V
REF
is 1.263 V, T
ZERO
is 273°K, T
AMB
is 298°K (273° + 25°),
and V
ADC
is the analog-to-digital con-
version voltage.
To allow this project to proceed
without some serious calculation rou-
tines, I used my trusty Radio Shack
scientific calculator to solve for the
V
ADC
values for all the Fahrenheit
temperatures between 40° and 99°F.
The V
ADC
values were then converted
to the 8-bit conversion equivalents
and stored in a look-up table.
The ADC is initialized for continu-
ous single ended conversions of chan-
nel 0 using a division factor of 32 on
the system clock. The ADC actually
does a 10-bit measurement conversion
and stores the value either left or
right justified into a 16-bit extended
I/O register. By using left justification,
the high byte of the conversion is the
high 8 bits of a 10-bit conversion (or
an 8-bit conversion value). Eight of
these conversions are added together,
and the total is shifted right 3 bits to
divide the total by eight and end up
with an average. A low conversion
value of 99 corresponds (coincidental-
ly) to a high temperature of 99°F. A
high conversion value of 180 corre-
sponds to a low temperature of 40°F.
To find the actual temperature, the
conversion average is compared to the
first value in the TEMP_TABLE (with
the first entry 180 = 40°F). If the table
entry is greater than the conversion
average, then the temperature vari-
able, which is initialized to 40, is
incremented and the next table value
is grabbed and the comparison repeats
until the TEMP_TABLE entry value is
less than or equal to the conversion
average. The temperature variable has
now incremented to the temperature
in degrees Fahrenheit that corresponds
to the appropriate average A/D conver-
sion value. To stay compatible with
the thermostat conversion protocol
that I discussed last month (“Global
XPortation,” Circuit Cellar 162), the
temperature is finally converted into
two ASCII digits as TEMPH and
TEMPL. You’ll notice that all vari-
ables are stored as ASCII values to
remain compatible with the protocol.
BUTTONS
Five user inputs provide local mode
changes to the thermostat. The first
button, Mode, increments the
MODE
variable through four possibilities: H, C,
A, and O. Heat places the thermostat in
Heat mode and asks the furnace for
heat if the temperature falls below the
heat set point by setting the HVAC-
STATUS to “H” (heating). HVACSTA-
TUS returns to “I” (idle) when the tem-
a)
b)
Photo 1a—
The LCD used on the STK502 adapter has a number of glyphs as well as 12-segment alphanumeric
digits.
b—
I used the arrowheads as function indicators and only four of the available digits.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
73
perature rises to heat set point + 4°F
(an arbitrary delta I added here, but is
not present in the virtual thermostat).
Cool places the thermostat in to
Cool mode and asks the air condition-
er for cool if the temperature rises
above the cool set point by setting the
HVACSTATUS to “C” (cooling).
HVACSTATUS returns to “I” when
the temperature falls to cool set
point – 4°F (an arbitrary delta).
Auto places the thermostat into
both Heat and Cool modes (i.e., it can
call for heating or cooling as neces-
sary). Obviously, if the heat set point
and cool set point are too close, the
systems will fight. Although this was-
n’t implemented in the virtual ther-
mostat, it is prevented here in the
Change_Plus and Change_Minus
routines by comparing the heat and
cool set points. They are automatical-
ly adjusted to keep a two times delta
distance between them. Off, or disable
mode, shuts down the call for
heat/cool operation by setting HVAC-
STATUS to “O.”
The second button, Fan, sets the
FAN variable to either a one (on) or a
zero (auto). The one value forces the
furnace/air conditioner fan on; the
zero value allows the furnace/air con-
ditioner to determine the state of the
fan based on its own criteria.
The third button, Set point, allows
you to change the heat and cool set
points. This button sets the display
mode to one of three values: 0x00,
0x01, and 0x02. A display mode value
of 0x00 indicates the LCD should dis-
play the actual temperature. A value
of 0x01 indicates the LCD should dis-
play the heat set point. A value of
0x02 displays the cool set point.
After the heat set point or cool set
point has been selected, the fourth
button increments the set point by
one. The fifth button decrements the
set point by one.
TALK AND LISTEN TO XPORT
The thermostat conversion protocol
is based on a serial data rate of 9600
bps using a data format of 8N1. The
ASCII commands for this protocol
make debugging simple. For the most
part, every time something changes
(e.g., the temperature), a command is
sent to the XPort. All commands are
two or three characters (see Table 1).
E-mail notices can be enabled and dis-
abled only through the XPort.
The XPort is responsible for passing
on thermostat commands to anyone
on the Ethernet who has opened a
connection with it. This might be you
and your browser. After all, you might
want to adjust the heat set point of
the thermostat from work so it’s
toasty when you get home. Or, this
might be the XPort located at the fur-
nace/air conditioner in the basement
where a command from the thermo-
stat to warm up the house could be
carried out.
The thermostat must not only send
changes as commands to the XPort; it
must also respond to commands from
the XPort (or the Ethernet). Many com-
mands are similar to those the thermo-
stat may send itself (see Table 2). These
commands can change variables in the
Photo 2—
I placed a small front panel over the LCD on
the STK502 adapter. The ZIF socket on the left holds
the ATmega169 device. Black dots on the front panel
indicate the positioning of push button switches. The
physical switches on the STK500 demo board are actu-
ally along the bottom edge of the PCB just out of view.
Command type
Command
Fan
F0 or F1
Mode
MA, MH, MC, or MO
Heat set point
Hxx (where xx = HEATSETPOINTH, HEATSETPOINTL)
Cool set point
Cxx (where xx = COOLSETPOINTH, COOLSETPOINTL)
Table 2—
These commands are sent to the thermostat whenever a change occurs via Ethernet (i.e., you change
the heat set point from a browser).
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
75
information. I wanted to leave this
interrupt routine to handle that, so I
tagged the need for this using the T
bit (user bit) in the status register.
Normal program execution proceeds
as follows. Do an ADC loop for temper-
ature conversion and do a table look-up
of the conversion result to degrees
Fahrenheit. Then, based on the selected
mode and current temperature, make
any changes necessary and send any
command changes to the XPort. Next,
look for button pushes, make any
changes necessary, and send any com-
mand changes to the XPort. Finally,
update the LCD and check the T bit in
the status register to see if the XPort
has requested information (
IN). If neces-
sary, send the XPort all of the com-
mands indicating the current status and
go back to begin the loop once again.
PLUG IT IN
Now, it’s time to make the magic
happen. Both demo PCBs have a DE-
9F for serial communication. Of
course, using the XPort and AVR
microcontroller in a design does not
require any RS-232 converters or con-
nectors; but, jury-rigging the demo
boards requires a cable. Try and find a
DE-9M-to-DE-9M cable when you
need one. Forget it. Fiddling around in
the junk box I found two crimp-on
DE-9Ms and a short piece of ribbon
cable. I plugged it in and, voila, no
magic. Doh! This needs to be a null
modem cable.
After the physical connections are
completed correctly, things started to
look up. Using my browser, I contact-
ed the XPort and got a pop-up com-
ment on installing the Java environ-
ment. Then up came the thermostat
layout that I showed you in my
“Global XPortation” column (Circuit
Cellar
162).
thermostat like a user when thermo-
stat buttons are pushed. Five additional
commands also change variables in the
thermostat, but they do not have sim-
ilar local input (see Table 3).
The
Sx command updates the vari-
able
STATE to enable/disable the ther-
mostat’s ability to request heat/cool
from the furnace/air conditioner. The
IN command requests that the ther-
mostat send the status, mode, fan,
heat set point, cool set point, and
actual temperature.
The low and high temperature
thresholds are similar to the heat set
point and cool set point; however,
instead of requesting heat/cool from
the furnace/air conditioner, e-mails
can be automatically sent by the
XPort to signify that the thermostat
has reached an unsafe temperature.
The thermostat indicates this to the
XPort using the
Ex command (0 =
safe, 1 = high temperature warning,
and 2 = low temperature warning).
The
Nx command updates the TRIG
variable to enable/disable the report-
ing of
Ex e-mail commands.
Only USART interrupts are used in
this application. Although the normal
program flow can place data to be sent
in a ring buffer, it must set the
USART data register empty bit to
allow the transmit interrupt routine
to empty the buffer. The receiver,
however, is always enabled, and fills a
second ring buffer with received char-
acters until a
<cr> is received. The
ring buffer is searched for the first
character less than ASCII zero. The
next three or four characters are
placed in temporary variables and ver-
ified for legal data. If all passes
muster, then interrupt routine branch-
es to handle each command. Most of
these commands just update a vari-
able, but the
IN command requests
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.
PROJECT FILES
To download the code, go to ftp.
circuitcellar.com/pub/Circuit_
Cellar/2004/163.
SOURCES
ATmega169 Microcontroller
Atmel Corp.
(408) 441-0311
www.atmel.com
This time, however, the XPort talks
to the AVR microcontroller, and the
information displayed on the LCD is
reflected on the display in the browser
window (see Photo 2). I can click on
the browser’s buttons and the changes
are sent back to the thermostat. Yes.
EXPANDING UNIVERSE
From the standard eight-pin ATiny
controllers to the ATmega with high-
density in-system programmable flash
memory, there’s an AVR solution tai-
lored to meet your most specific needs.
And note that both the instruction set
and architecture are the same for all
AVR products. So, when your code
increases, you can easily and quickly
port to a larger device. AVR comes
three ways: as a standard package prod-
uct, an application-specific standard
product, and an ASIC core integrated
into a System-on-a-Chip solution.
You can depend on Atmel to contin-
ue expanding its collection of successful
AVR products. The RISC core’s single-
cycle instructions result in serious code
efficiency. The AVR’s flash memory
technology provides in-circuit program-
ming thanks to a separate “boot flash.”
You can smile, knowing that Atmel
is constantly improving its suite of
program and system development
tools. It’s the kind of support that ends
up saving you precious design time.
After all, if your design time decreas-
es, then you’ve earned a little free
time. And what better way to make
use of it than to lie in a hammock and
watch the grass (or weeds) grow.
I
Command type
Command
State
S0 or S1 (0=off, 1=on)
Request information
IN
Low temperature threshold
Axx (where xx = LOWWARNINGH, LOWWARNINGL)
High temperature threshold
Zxx (where xx = HIGHWARNINGH, HIGHWARNINGL)
E-mail triggers
N0 or N1 (0=disable, 1=enable)
Table 3—
These commands can be sent to the thermostat via Ethernet. They adjust variables that cannot be
changed via local control (i.e., the e-mail triggers are only enabled and disabled through the Ethernet). The thermo-
stat has no local control over this function, although it is responsible for sending an
Ex
command if e-mail triggers
are enabled.
76
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
I
t doesn’t get the same headlines as
big-ticket chips, but the lowly 8-bit
MCU continues to drive the silicon
revolution with gusto far beyond its
place in the processor pecking order.
The bottom line is that the 8-bit
MCU marches on. Even the recent
recession proved little more than a
stutter step in its relentless climb to
10 million units a day and beyond.
And when it comes to 8-bit MCUs,
the venerable 8051 stands out. First,
even in a market still dominated by
old-timers, the ’51’s late-1970s birth
time and place give it a lot of seniori-
ty. Second, and more importantly, the
’51 has emerged as the de facto
“VolksMCU,” with versions offered
by a dizzying array of suppliers rang-
ing from worldwide heavyweights to
starry-eyed start-ups.
It seems like hardly a week goes by
during which I don’t find a press
release for a new ’51 gadget in my in-
basket. Now I see that ST
Microelectronics, one of the world’s
biggest IC companies, has jumped into
the ’51 fray, combining a hopped-up
version of the MCU with the combo
memory/PLD chip (the programmable
system device, a.k.a. PSD) they
acquired some years back. (Refer to
my July 2000 column, “Swiss Army
designed at the request of outsiders.
The 4004 was a calculator chip built
for a Japanese company, while the
8008 was commissioned by Datapoint
for a terminal.
In fact, by the late ’70s Intel’s micro
prospects were arguably sketchy. The
8080 and its rather milquetoast follow-
on, the 8085, were getting dissed by
upstart Zilog and their whizzier Z80.
Meanwhile, the brand new 8086 was
caught in a three-way standoff with the
Motorola 68000 and Zilog Z8000, not
to mention a dysfunctional shotgun
second-source marriage with AMD.
Perhaps it’s no surprise that Intel’s
own MCUs, the 8048 and various deriv-
atives, got little attention. It is not hard
to imagine how the company, captivat-
ed by visions of 16- and 32-bit angels
(such as the obtuse iAPX432), might
overlook these runts of the litter.
Nevertheless, in a few cubicles
buried deep in the maze of Santa Clara 4,
the MCU mantra went on, chanted by
true believers. I recently had the
pleasure of meeting with one of them,
a fellow named John Wharton.
WOULD YOU BUY AN MCU FROM
THIS MAN?
John’s an interesting fellow who’s
had more than his 15 minutes of
fame. Included among his many tech-
nical accomplishments, this former
Intel engineer, Microprocessor Report
analyst, high-tech consultant, and
Stanford lecturer is largely credited as
a driving force behind the creation of
’51 Flavors
SILICON UPDATE
by Tom Cantrell
Chip,” Circuit Cellar 120.)
Then there’s Actel announcing a ’51
soft-core that runs in their FPGAs.
Going one, actually multiple, cores
further is Quickcores with their novel
’51-based multiprocessing scheme—
kind of a mini-me supercomputer.
Indeed, it has been a long, strange trip
for the 8051, a little chip that’s still
making a big difference.
FLASHBACK
In the 1970s, Intel was quite a differ-
ent place than today. The IBM PC that
would fundamentally transform them
from a “chip” to a “computer” compa-
ny was still years away. Silicon Valley
was the Wild West, and micros were
the six-shooters with everybody from
AMD to Zilog vying to be top gun.
Intel had a bit of an advantage by
virtue of micro leadership, albeit
reluctant some would say, with the
earlier 4004 and 8008. As the story
has been retold, you may get the
impression that Intel precisely execut-
ed a clever strategic plan to invent the
micro and germinate the applications.
As is often the case, history has a way
of making something complicated and
messy seem simple in hindsight.
The fact is, these first-generation
micros got their start as custom chips
“The chip that wouldn’t die.” That’s how Tom characterizes the 8051, which first hit the scene
in the late 1970s. The chip has persevered, and today, some of the hottest chips on the mar-
ket, such as the Cygnal (now Signal Laboratories) C8051F120, owe much of their success
to the 8051 architecture.
Table 1—
Only a few of the fanciest processors can actually deliver one or more instructions per clock in real appli-
cations. Nevertheless, running at up to 100 MHz, the ’F120 delivers extraordinary performance for an 8-bit MCU.
Clocks to execute
1
2
2/3 2
3/4 4
4/5 5
8
Number of instructions
26
50
5
14
7
3
1
2
1
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
77
the 8051. On the lighter side, John
also tells tales of winning a Porsche in
a design contest, playing a bit part in a
Ron Howard film (“EDtv”), and doing
lunch with Jodie Foster, not to men-
tion the time he took a shower live on
the Late Show with David Letterman.
The story starts, as many of the
most interesting stories do, with a
small happenstance that would other-
wise seem of little import. In the case
of the ’51, the curtain opens on a day
way back in 1977 when John hap-
pened to forget his wallet. Left in the
lurch at lunch, John dropped in on his
boss, a fellow named Lionel Smith, to
see if he could wangle a you’re-buying
meal. Instead, Smith suggested John
come along to a noontime meeting
where sandwiches and the like would
be served.
It turned out that the meeting was
the latest in an ongoing series of meet-
ings bouncing around ideas for the lat-
est and greatest extension to the 8048
line. The good news was that Intel had
made a lot of headway with their orig-
inal 8048, going so far as to introduce
a number of derivatives targeting par-
ticular markets such as toys, appli-
ances, and industrial control. The bad
news was that the proliferation of
parts was rather ad hoc and chaotic.
The particular design team for each
variant felt free to add their own
tweaks with an eye toward engineer-
ing expedience and less regard for an
overall strategy. Every chip had an
instruction set and programming
model slightly different from the oth-
ers. Unlike chip designers, as an appli-
cation engineer, John felt the pain of
customers struggling with the result-
ing mish-mash of device-specific docu-
mentation, software tools and
libraries, design kits, emulators, and
all the rest.
As an uninvited outsider at the
meeting, John managed to bite his
tongue through the presentation of yet
more seemingly shoot-from-the-hip
upgrades. Although that was the way
chips got designed at the time, John
could see the approach was doomed in
the long term. After the meeting,
when his boss asked him his thoughts,
John just offered a tempered and tact-
ful “I would have done it differently.”
John was given the go-ahead to write
up his ideas. Although the first wafer
wouldn’t arrive for more than two
years, the date of birth for the ’51 is
arguably January 18, 1978, when John
came up with his propos-
al for an 80XE Version II
combining some of the
existing work with his
own new ideas (see
Photos 1a and b).
In retrospect, it’s iron-
ic that the expandability
John called for to serve
Intel’s upgrade strategy
(e.g., a large special func-
tion register space to
allow for easy I/O add-
ons) ultimately enabled
the proliferation of the
MCU across the dozens
of suppliers that serve
the ’51 market today. Of
course, from Intel’s per-
spective, later events
(Can you say, “IBM
PC”?) would subsequent-
ly render the entire 8-bit
MCU subject moot. But,
for the rest of us, after
more than 25 years and
literally billions of ’51s
later, we can all look
back and say that that
was one free lunch that
really paid off.
BACK TO THE
FUTURE
The Cygnal (now
Silicon Laboratories)
C8051F120 is an MCU
Digital
power
V
DD
V
DD
V
DD
DGND
DGND
DGND
Analog
power
AV+
AV+
AGND
AGND
JTAG
Logic
Boundary scan
Debug HW
TCK
TMS
TDI
TDO
*RST
V
DD
Monitor
WDT
MONEN
Reset
External oscillator
circuit
XTAL1
XTAL2
PLL
Circuit
Calibrated internal
oscillator
System
clock
VREF
VREF
VREFD
DAC1
(12 bit)
DAC0
(12 bit)
DAC1
DAC0
VREF0
AIN0.0
AIN0.1
AIN0.2
AIN0.3
AIN0.4
AIN0.5
AIN0.6
AIN0.7
AMUX
Prog
gain
ADC
100 ksps
(12 bit)
Temperature
sensor
CP0
CP1
8051 Core
SFR Bus
256-byte
RAM
8-KB
XRAM
External data
memory bus
128-KB
Flash
memory
64 × 4 byte
Cache
Port I/O
configure
UART0
UART1
SMBus
SPI Bus
PCA
Timers 0,
1, 2, 4
Timers 3/
RTC
P0, P1,
P2, P3
Latches
Crossbar
configure
Crossbar
P0
Drv
P1
Drv
P2
Drv
P3
Drv
•
•
•
P0.0
P0.7
•
•
•
P1.0/AIN2.0
P1.7/AIN2.7
•
•
•
•
•
P2.0
P2.7
•
•
•
P3.0
P3.7
CP0+
CP0–
CP1+
CP1–
•
•
•
VREF2
ADC
500 ksps
(8 bit)
AMUX
8:1
Bus control
CTL
Address bus
Addr
Data bus
Data
P4 Latch
P4
DRV
P4.0
P4.4
P4.5/ALE
P4.6/RD
P4.7/WR
P5 Latch
P5
DRV
P5.0/A8
P5.7/A15
•
•
•
P6 Latch
P6
DRV
P6.0/A0
P6.7/A7
•
•
•
P7 Latch
P7
DRV
P7.0/D0
P7.7/D7
•
•
•
Prog
gain
Figure 1—
There’s a lot to talk about comparing Cygnal’s latest and greatest ’51 to the original, but “You’ve come a long way, baby”
sums it up.
78
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
that respects its ’51 roots, even
as it thoroughly freshens the
design with the latest and great-
est (see Figure 1). I’m reminded
of the finesse with which
Volkswagen successfully updat-
ed to the New Beetle. The new
version is a much faster and
more comfortable ride, but it’s
still a happy-go-lucky bug.
The same goes for the ’F120.
It’s still a ’51 at heart, but with a
window sticker full of options.
And it’s faster—way faster.
Although the New Beetle is twice
as fast as the original, the ’F120 is
fully 100 times faster than its circa-
’70s ancestor. It’s true that the origi-
nal ’51 was a slowpoke; its 12 clock
per cycle core was as pokey as an old
Volkswagen huffing and puffing up a
steep hill. It’s all the more ironic then
that the ’F120 isn’t just a super fast
’51, it’s also one of the fastest 8-bit
MCUs you can buy—period!
Just how fast is it? The easy answer is
100 MIPS at 100 MHz, but your mileage
may vary. To Cygnal’s credit, there’s no
intent to mislead. They repeatedly note
that 100 MIPS is a peak or “up to” num-
ber. Determining the actual performance
you’re likely to get involves taking a
closer look at the details.
First, only about a quarter of the
chip’s 109 discrete opcodes actually
execute in a single clock (see Table 1).
As usual, the fastest instructions are
the simple register-to-register ALU ops.
At the other extreme, nobody will
begrudge the fact a DIV(ide) instruction
takes eight clocks. It may be the slow-
est instruction, but it’s surely one of
the least frequently used as well.
Most of the instructions take two
clocks, either because the instruction
is more than 1 byte long or it involves
an indirect memory reference (i.e., the
register operand contains an address
pointing to the actual data in memory
thus requiring two-step retrieval). In-
between, clocking in at somewhere
between three and five cycles, are the
branches of various sorts including
subroutine CALLs and RETurns.
Simply computing the average by
summing up the clock counts and
dividing by the number of opcodes in
the instruction set can yield a mis-
leading result. Such so-called static
analyses fail to account for the fact
that some instructions (notably
branches) tend to be executed more
frequently than others. A dynamic
analysis uses the actual mix of
instructions represented in a particu-
lar benchmark. My guess is that a typ-
ical program is likely to average about
three clocks per instruction.
FLASH CACHE
Raw clock counts also can be mis-
leading to the degree that they ignore
memory bandwidth. The fact is,
you can’t execute instructions
faster than memory can deliver
them, and nobody, including
Cygnal, has the sub-10-ns flash
memory that could directly deliv-
er on the 100-MIPs promises.
The answer of course is some
kind of pipelining and caching
scheme, and Cygnal has come
up with a novel combination of
prefetch engine and branch tar-
get cache that attempts to keep
up with the processor’s voracious
appetite for opcodes (see Figure 2).
Here’s how it works: Let’s start with
the prefetch engine, which relies on a
32-bit connection to the on-chip flash
memory to fetch 4 bytes at a time. So,
yes indeed, if you have a stream of
sequential (no branches) 1-byte/1-clock
opcodes, the prefetch engine alone can
keep up (i.e., 4 bytes fetched out of
40-ns flash memory equals 1 byte
every 10 ns or 100 MIPS).
As usual, branches are what muck
up the works. Here’s where the branch
Flash
memory
Prefetch
engine
Branch
target
cache
Instruction
data
CIP-51
Instruction address
Figure 2—
The prefetch unit fetches 32 bits at a time to overcome the
flash memory access time bottleneck while the branch target cache
helps reduce the branch penalty.
UART0
SPI
SMBus
UART1
PCA
Computer
Outputs
T0, T1
T2, T2EX,
T4, T4EX
*INTO0,
*INT1
Highest
priority
Lowest
priority
(Inter
nal digital signals)
Priority
decoder
Digital
crossbar
2
4
2
2
7
2
8
XBR0, XBR1,
XBR2, P1MDIN
Registers
*SYSCLK divided by 1, 2, 4, or 8
CNVSTR0/2
2
P0
P1
P2
P3
(P0.0–P0.7)
8
8
(P1.0–P1.7)
(P2.0–P2.7)
8
8
(P3.0–P3.7)
Port
latches
To external
memory
interface
(EMIF)
8
8
8
8
P0
I/O
Cells
P1
I/O
Cells
P2
I/O
Cells
P3
I/O
Cells
•
•
•
P0.0
P0.7
Highest
priority
Lowest
priority
•
•
•
P1.0
P1.7
•
•
•
P2.0
P2.7
•
•
•
P3.0
P3.7
To
ADC2
input
•
•
External
pins
P0MDOUT, P1MDOUT
P2MDOUT, P3MDOUT
Registers
Figure 3—
Thanks to a built-in cross-point switch, now you can have it your way when it comes to mapping I/O
functions to pins.
80
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
target cache comes in. It’s a bit differ-
ent from a conventional instruction
cache, which typically retains any and
all instructions that are executed.
Rather, the Cygnal approach caches the
4 bytes of instructions residing at the
target of branches, relying on the
prefetch engine to keep up with the
sequential code in between. With
64 entries (actually 63 because the first
entry is reserved), it’s roughly the
equivalent of a conventional 256-byte
instruction cache, except for the fact
that all of the instructions cached
reside within 4 bytes of a branch target.
The good news is that the cache can
help mitigate the so-called branch
penalty that would otherwise lead to
stalls. The bad news is that all cache
schemes introduce a degree of timing
uncertainty sometimes referred to as a
lack of determinism. That can make it
difficult or even impossible to predict
how long a particular section of code
will take to execute because the tim-
ing will vary depending on what is and
isn’t cached at a particular moment.
That’s why I’m generally opposed to
caching in embedded chips ostensibly
designed for real-time applications. A
cache is designed to optimize average
performance across an unknown
workload. By contrast, real-time appli-
cations call for the predictable per-
formance of a fixed program whose
behavior is completely understood. An
embedded programmer knows exactly
which parts of their program need the
highest and hardest real-time perform-
ance and can partition the code across
the memory hierarchy accordingly, in
essence acting as an a priori human
cache controller.
To Cygnal’s credit, their scheme
includes all the hooks necessary to
harden real-time performance. The
determinism issue can be brute-forced
by simply turning off the cache and
the prefetch engine. An option with a
little more finesse is to preconfigure
and lock a portion of the cache yield-
ing the best of both worlds—fast deter-
minism where you need it and statisti-
cal speed-up for the rest of your code.
More thought-provoking features
include the option to automatically
cache interrupt service routines.
Another is the ability to choose
whether or not the target of a RETI
instruction should be cached. For
example, it usually wouldn’t make
sense to cache return addresses asso-
ciated with an asynchronous interrupt,
because the return address (i.e.,
instruction that was interrupted) is
likely different every time.
The cache offers two replacement
algorithms that define what happens
when all the slots are filled. The first,
pseudo-random, is fairly self-explana-
tory (i.e., the dice are thrown to
decide which unlocked slot to over-
write). This fits well with the statisti-
cal underpinnings of the cache con-
cept, spreading the speed-up around in
a random fashion.
The other replacement strategy is
known as “rebound,” which simply
ping-pongs (i.e. after the sixty-fourth
entry is filled, the cache controller
starts working backwards from the
sixty-third to the sixty-second and so
on). To my mind, overwriting more
recently used branch targets while
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
81
makes for all of those MIPS super-
charges the peripherals as well. For
example, the fancy six-channel pro-
grammable counter array (PCA) can
run off the system clock as a time
base, delivering class-leading 10-ns
resolution. The ’F120 makes serial
port friends easily with UART, SPI,
I
2
C, and SMBus modes—and they
all run really fast too.
Cygnal targets the analog niche,
so it’s no surprise that the ’F12x
excels with two separate convert-
ers, one 8-bit (500 ksps) and one
10- or 12-bit (100 ksps). Each con-
verter has eight input channels
with programmable single-ended or
differential configuration. Besides
the converters, the analog subsys-
tem includes the variety of add-ons
that can otherwise cause sticker
shock at design time such as a pro-
grammable gain amplifier, an accu-
rate voltage reference, a built-in
temperature sensor, and so on. And
what the heck, Cygnal even throws
in two 12-bit DACs and two com-
parators for you to play with.
With the understanding that any-
thing with an A/D converter is inher-
ently a signal processor, the higher-
saving those encountered long ago
seems counterintuitive. Maybe
there’s a scenario where it makes
sense, or maybe it just kind fell out
of the design and became a feature.
More typically found on a 32-bit
chip, the ’F120 even has fancy
instrumentation features such as a
miss accumulator that provides a
measure of how well the cache is
working, allowing the programmer
(or even the program itself) to opti-
mize the cache configuration.
I/O U
Beyond benchmarks, MCU
design decisions are usually as
much about the quantity and capa-
bility of on-chip I/O as they are
about MIPS ratings. You can stick a
souped-up motor in an old bug, but
that doesn’t mean the heater will
work any better than it did before.
Fortunately, as you can see in the
block diagram in Figure 3, the
’F120 goes way beyond the original
’51’s basic complement of peripherals.
Furthermore, the same 100 MHz that
Photo 1a and b—
John Wharton relives the 8051’s youth with his
original 1978 proposal and one of the first wafers.
a)
b)
82
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
end members of the lineup include a
16 × 16 MAC (multiply accumulate)
engine—just the thing for cranking
through those pesky DSP inner loops
at a speedy two clocks per.
In the seemingly unlikely case that
you need to add some memory or I/O
externally, the ’F120 obliges with an
external expansion bus. It can be con-
figured for either multiplexed (i.e.,
’51-compatible) or nonmultiplexed
(more useful these days) operation.
Note that the external bus, like on-
chip RAM, is for data only, because
the one and only place the ’F120
fetches instructions from is the on-
chip flash memory. The software
(MOVX instruction) and hardware
(programmable setup and hold times
and wait states) overhead associated
with data transfer is considerable.
But, as they say about racecars,
there’s no substitute for cubic inches.
The 100 MHz under the hood can
easily pump many megabytes per sec-
ond to and from the pins under soft-
ware control.
One of the most wonderful I/O fea-
tures isn’t a port or converter at all.
Rather, it’s a crossbar switch that
allows you to take advantage of all
the I/O that’s on-chip (see Figure 3).
How many times have you struggled
to compromise with MCUs that limit
certain peripheral functions to certain
pins? The ’F120 scheme says you’ve
got 32 pins that you can individually
allocate to specifically those I/O func-
tions and internal signals required for
your particular application. Another
nice touch is that although the MCU
is a 3-V chip, the I/O pins can tolerate
the 5-V TTL levels that are still found
lurking in the embedded space.
GLUE CREW
If the processor core is the motor
and the I/O is where the rubber (ones
and zeros) meets the road (pins), con-
sider glue logic to be the transmission
that puts it all together. You can have
a hot motor and big slicks, but you’ll
go nowhere fast with a bucket-of-bolts
tranny.
For instance, just where does that
100 MHz come from? Maybe the fine
print says you need to add an expen-
sive 100-MHz oscillator to your
design. Or how about reset? Is the cir-
cuit reliable, or do you have to experi-
ment with adding components to
meet an obscure rise-time spec only
to find it may glitch depending on
what kind of power supply you end up
using? Sure the datasheet says the
flash memory is “in-system program-
mable,” but does that mean only if
you happen to have an extra power
source to deliver some off-the-wall
programming voltage?
Glue logic is all too easy to take for
granted—at least until some seeming-
ly minor omission or flaw leads to
endless head scratching. Fortunately,
MCU designers have gotten really
smart over the years, and Cygnal is no
exception.
Let’s start with the clock. Like
many of the newer MCUs, Cygnal
includes a built-in oscillator. Relative
to the competitors, I am impressed
with the speed (24.5 MHz), and even
more impressed with the accuracy
(about
±
2%), of Cygnal’s design.
Although not accurate enough to
stand in for a real-time clock (2%
could drift about 30 min. per day),
compared to chips with sloppier on-
chip clocks (e.g., +=10%) , the Cygnal
design is accurate enough to deliver
standard data rates for the serial ports.
Alternatively, you can add an external
clock (crystal, RC, or C variants) and
use the internal clock as a backup, but
I suspect the speed and accuracy of
the on-chip clock will suffice for
many applications.
Whatever the clock source, an on-
chip phase-locked loop (PLL) acts as
the turbocharger, boosting the clock
rate up to the 100-MHz speed limit.
Note that just like a turbocharger, the
PLL exhibits a fair amount of lag (i.e.,
time to lock on and stabilize at the
target clock rate). The amount of lag
varies depending on the specific
combination of PLL input and out-
put clock rates. For instance, with a
25-MHz input (i.e., the internal oscil-
lator) and 100-MHz output, it takes
the PLL 42 µs to lock on. Other com-
binations can take hundreds of
microseconds. This is a factor to con-
sider in short latency situations (e.g.,
interrupt handler), where it may be
best to run at the slower rate rather
than wait for the PLL to lock.
When it comes to reset, all of the
bases are covered with seven sources
calling for an aptly named funnel (a
big OR gate) to handle them (see
Figure 4).
As I mentioned earlier, the chip
runs on a 2.7- to 3.6-V supply. The
only caveat is that higher speed opera-
tion (greater than 50 MHz) calls for a
tighter 3- to 3.6-V spec. A notable plus
is that there are no power supply
restrictions for flash programming. If
the chip has enough voltage to run
Photo 2—
The cost of the ’F120 evaluation kit is pleasing and the JTAG is jiffy, but it’s the quick and easy setup
and checkout that a harried editor really appreciates.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
83
SOURCE
C8051F120 Microcontroller
Silicon Laboratories, Inc.
(512) 327-7088
www.silabs.com
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.
(enforced by an on-chip voltage moni-
tor), it has enough voltage to program
the flash memory. Flash memory pro-
gramming is relatively easy thanks to
self-timing. The flash memory can
be used for code or data with two
special 128-byte small-sector blocks
specifically set aside for the latter. If
you use the flash memory for fre-
quently updated data, don’t overlook
the fact that the minimum write
endurance spec is only 20,000 cycles
(100,000 typical).
The flash memory also has plenty
of security features, including a novel
software read limit that allows speci-
fying a portion of the flash memory as
inviolate and unreadable by software.
This supports so-called value-added
firmware (i.e., vendor A can program a
portion of the flash memory and ship
the part to vendor B, who can add
their own software to the remaining
flash memory but can’t change or
access vendor A’s code).
DEBUG FOR DUMMIES
As with the parts themselves, most
MCU suppliers have got their act
together when it comes to evaluation
kits and debugging. Even against wor-
thy competitors, the ’F120 evaluation
kit that I played with stands out as a
good example of the breed.
The Cygnal parts rely on a JTAG-
based debugging scheme, which is the
most popular approach these days.
Unlike the typical ROM monitor,
none of the MCU’s application
resources (i.e., memory, ports, and
pins) are hijacked for debug duty. And,
although it lacks the most advanced
features of a traditional in-circuit emu-
lator (e.g., real-time trace), JTAG is
much cheaper and uses the actual pro-
duction part installed on your board
rather than a cumbersome socket
adapter that could otherwise degrade
the analog (analog-to-digital, digital-to-
analog) functions. That puts an end to
the dreaded “it works with the emula-
tor but not with the part” dilemma.
In addition to debugging, the JTAG
port also provides a means to program
the flash memory. And, unlike some
non-IEEE standard pseudo-JTAG
schemes, Cygnal offers full boundary-
scan capability (i.e., the ability to set
and interrogate the state of each pin),
which is something that can come in
handy when testing and debugging
your own PCBs.
Besides a decent price (only $149), I
was impressed with the package’s over-
all friendliness and attention to detail.
The first thing you see when you open
the box is a large “getting started” fold-
out, which includes pictures that lead
you step-by-step through the setup
process (see Photo 2). All the bits and
pieces (e.g., wall wart power supply and
serial cable) are included. In just a few
minutes, you’ve got the hardware
hooked up, the IDE software installed,
and are stepping through an example
program that blinks the LED.
I took advantage of the setup to dab-
ble with the ’F120 cache and prefetch
features. Although the blinky LED pro-
gram is admittedly a toy example, it is
illuminating to note that performance
was just about twice as fast with the
cache and pre-fetching enabled.
THE CHIP THAT WOULDN’T DIE
So there you have it, the latest and
greatest incarnation of the ’51. Who
would have thought such a little chip
could have such a big and long-lasting
effect?
Give credit to the original team of
inventors—folks like John Wharton,
who did the right thing from the engi-
neering perspective, surely never
expecting the “little chip that could”
would ever go so far.
What does the future hold for the
’51? Although the architecture itself is
arguably stretched nearly to the limit,
I fully expect to see the continued
proliferation of parts and suppliers and
new innovations in peripherals and
packaging.
Happy twenty-fifth anniversary my
MCU friend, and, until next time, for
there will surely be a next time, many
happy RETurns.
I
(Port I/O)
Crossbar
CNVSTR
(CNVSTR
reset enable)
CP0+
CP0–
+
–
Comparator0
(CP0
reset enable)
Internal
clock
generator
PLL
Circuity
OSC
System
Clock
Clock select
Extended interrupt
handler
CIP-51
Microcontroller
core
Missing
clock
detector
(one-
shot)
EN
MCD
Enab
le
WDT
EN PRE
WDT
Enab
le
WDT
Strobe
Software reset
System reset
+
–
Supply
monitor
Supply
reset
timeout
(wired-OR)
XTAL1
XTAL2
Reset
funnel
*RST
V
DD
Figure 4—
A missing clock detector, analog comparator, and even an extra pin (CNVSTR) are just some of the
additions to the original 8051’s single-minded reset pin (*RST).
84
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
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
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
85
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.
86
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
Expansion options with Peripheral Boards
Telecom Hardware/Software Developers
http://www.digitalproductsco.com
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
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
87
• Control or monitor 12 I/O’s of digital
or analog input and digital outputs
88
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
sales@sealevel.com 864.843.4343
• Supports data rates up to 921K bps
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
89
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
91
92
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 163 February 2004
93
Backpack Water Level Monitor
BasicCards 101: Part 1—Program Your First Smartcard
Wireless Vehicle Tracking: Part 2—Forth-Based Speech Synthesis
Low-Cost Intelligent Sensors Network
Software-Only Hardware Simulation
Ultimate NCO
TTP/A Protocol and Design
I Applied PCs: The UCA93LV Advantage—Implement I
2
C on Your PC
I From the Bench: Intelligent Current Sensors
I Silicon Update: Memory Memoir
Preview of March Issue 164
Theme: Embedded Applications
94
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
91
Abacom Technologies
86
ActiveWire, Inc.
17
AeroComm, Inc.
89
Akida LLC
46
All Electronics Corp.
92
Amazon Electronics
93
American PCB Assembly
12
AP Circuits
7
Atmel
13
AVR 2004 Contest
91
Bagotronix, Inc.
90
Basic Micro
12
Bellin Dynamic Systems, Inc.
80
CadSoft Computer, Inc.
87
Carl’s Electronics
89
CCS-Custom Computer Services
92
Conitec
35
Connecticut microComputer, Inc.
88
Copeland Communications, Inc.
84
Cyberpak Co.
1
Cypress MicroSystems
65
CWAV
91
DataRescue
84
Decade Engineering
86
Digital Products
12
DLP Design
9
DPAC
The Index of Advertisers with links to their web sites is located at www.circuitcellar.com under the current issue.
Page
8
Dynon Instruments, Inc.
19
Earth Computer Technologies
87
EE Tools
(Electronic Engineering Tools)
35
EMAC, Inc.
63
Embedded Systems Conf.
89
emBoot, Inc.
74
Emerging Robotics Conf.
85
Eric Senter Embedded Design
15
ExpressPCB
84
FDI-Future Designs, Inc.
92
Front Panel Express
91
Futurlec
81
GSPX Forum/Conf.
87
Grid Connect
85
Hagstrom Electronics
49
HI-TECH Software, LLC
14
ICOP Technology Inc.
89
IMAGEcraft
89
Innoventions, Inc.
86
Intec Automation, Inc
85
Intrepid Control Systems
91
Intronics, Inc.
64, 86
JK microsystems, Inc.
85
JPA Consulting
44
JR Kerr Automation & Engineering
44
LabJack Corp.
44
Lakeview Research
25
Lemos International
2
Link Instruments
38
Linx Technologies
71, 73
MaxStream
90
MCC (Micro Computer Control)
62
Microchip
92
microEngineering Labs, Inc.
79
Micromint
90
MJS Consulting
93
Motion Encoders
86
Mosaic Industries, Inc.
72
MVS
86
Mylydia Inc.
C2
NetBurner
93
North American Radio Solutions
84
NPE, Inc.
88
OKW Electronics, Inc.
92
Ontrak Control Systems
81
PCBpro
47
PCBexpress
87
PCB Fab Express
C4 Parallax, Inc.
84
Phytec America LLC
87
Phyton, Inc.
90
Picofab Inc.
93
Pioneer Hill Software
88
Precision Technologies, Inc.
Page
Page
Page
93
Pulsar, Inc.
88
Quality Kits & Devices
88
R2 Controls
34
R4 Systems Inc.
23
Rabbit Semiconductor
42
Redpoint Controls, Inc.
47
Remote Processing
5, 27
Renesas Technology Corp.
90
RLC Enterprises, Inc.
43
Saelig Co. Inc.
3
Scott Edwards Electronics Inc.
88
Sealevel Systems
95
Sierra Proto Express
84
Signum Systems
85
Softools
86
TAL Technologies
C3
Tech Tools
32, 33
Technologic Systems
90
Technological Arts
89
Tern Inc.
85
Trace Systems, Inc.
91
Triangle Research Int’l, Inc.
62
Trilogy Design
93
Weeder Technologies
86
Zagros Robotics
91
Zanthic Technologies Inc.
86
Zexus Technologies Ltd.
April Issue 165
Deadlines
Space Close: Feb. 10
Material Due Date: Feb. 18
Theme:
Robotics
A
TTENTION
A
DVERTISERS
e-mail: sean@circuitcellar.com
INDEX OF ADVERTISERS
BONUS DISTRIBUTION
Trinity College
Fire-Fighting Robot Contest
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
O
K, I admit it. Ive been at this game for quite a few years. I want you to know it was a choice. It isnt like I was too lazy to look for a job someplace,
and so I ended up hanging around in the cellar inventing stuff. Im one of those fortunate people who really got to tailor his career to be in line with his
interests.
The downside is being reminded that I started all this 25 years ago, and the clock has kept moving ever since. I wish I had a nickel for every time
someone came up to me at a trade show and said, Ive been reading you since BYTE. Of course, I realize they mean this as a compliment even
when they tell me that they were in high school at the time or that they now own a company and have piles of grandchildren. The reality of being one
of the few successful magazines in the embedded electronics business is that we are, by definition, in it for the long haul. I guess it was finally time to
update the picture. Yeah, its grayer. But lets think of it as wiser too. ;-)
So, how has Circuit Cellar sustained its relevance and prospered while others have failed over the years. For those of us old enough to remember
BYTE, there is a lesson. BYTE was at the top of its game when it switched directions to follow the money instead of the readership. They switched from
being a broad-based technology magazine to just another PC-centric magazine following the advertising rainbow. We all know how that story turned out.
The level of technology in this issue of Circuit Cellar is certainly greater than the first issue, but the message is still the same, and we said it first:
Inside the box still counts. Along with trusted staff members like Jennifer Huber, Dave Tweed, and John Gorsky, weve endeavored to stay relevant
and broad-based. The fact that Circuit Cellar is revered as a reference-quality magazine isnt because Im some great Editorial Director; its only because
of the great authors and designers who fill our pages. I give them the vehicle to publish it, but it is their talented designs that make it all relevant.
So whats one of the best ways to find these great projects and great authors? Contests, of course!
While we have more editorial than we need, sometimes in the past we have had difficulty planning specific theme issues. For example, its good
to actually have a few wireless design articles when you plan a wireless theme issue <grin>. Editorial quality and technical variety is a numbers game.
If you have 10 manuscripts to review, a few will be great, a couple will be perfect for special issues, and the rest youd prefer to pass on. If this num-
ber is 100 manuscripts, then the percentage that is considered great and unique is enough to fill half the editorial calendar. Give me 100 contest proj-
ects a year and Ill show you what a reference-quality magazine is all about.
If youve ever wondered why Circuit Cellar design contests are managed so much better than anywhere else, its because our relationship with the
contestants starts when they enter a project, not ends with it. Win or lose, Ill work with you to maximize the benefits of putting the work into a contest
project. For some of you, this means publishing a feature article in the magazine, while for others its an opportunity to have your project posted on a
major semiconductor manufacturers web site. For everyone, it just might be the boost you need to launch a product or a career.
Circuit Cellar will continue to host two official Circuit Cellar design contests again this year. (In fact, were already booked through 2005 for these
kinds of contests.) The first is the Atmel AVR 2004 Contest that starts this month. The second is a Cypress MicroSystems PSoC contest that starts in
August. Finally, if two contests arent enough for you, we will be announcing two more during the year as well. Just watch our web site for details.
Probably the best reinforcement that we must be doing something right is the number of contest regulars we seem to have. Just for the heck of
it, I made a list of all the project entries for the eight contests held during the last three years. I have 35 people who have entered at least two differ-
ent contests during that period. Six people had the fortitude to enter five separate contests: Bruce Pride (USA), Indranil Majumdar (India), Lindsay
Meek (Australia), Radu Constantinescu (USA), Seenath Punnakkal (USA), and Virachat Boondharigaputra (Thailand). Of course, the trophy for the
most enteredsix contestsgoes to Robert Lacoste. (For anyone worried about competing with Robert, since his contest-stimulated consulting busi-
ness took off, he seems to be limiting himself to two contests a year. ;-)
Just so you know that all this repeat activity isnt wasted, 60% of the 35 people who entered two or more contests have ended up as winners.
Eighty-five percent of the 19 people who entered three or more contests ended up as winners at least once. And, 100% of the nine people with four
or more contest entries were winners. Perseverance counts.
Yup, its a new picture, but its the same old story, and knowing its history could be helpful to you. I once used a magazine and a few design projects to
launch a career. Perhaps its worth thinking about whether this could be the same success formula for you. Pick a contest and start with the design project.
Moving Forward
steve.ciarcia@circuitcellar.com
96
Issue 163 February 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
by Steve Ciarcia, Founder and Editorial Director
PRIORITY INTERRUPT
Wyszukiwarka
Podobne podstrony:
circuit cellar2000 02
circuit cellar1995 02
circuit cellar1991 02,03
circuit cellar1994 02
circuit cellar2003 02
circuit cellar2002 02
circuit cellar1993 02
circuit cellar1997 02
circuit cellar1990 02,03
circuit cellar2001 02
circuit cellar1996 02
circuit cellar1992 02,03
circuit cellar2000 02
circuit cellar1992 02,03
circuit cellar1993 02
circuit cellar1991 02,03
circuit cellar1994 02
więcej podobnych podstron