7
9
25274 75349
0 6>
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)
#167 June 2004
MEASUREMENT & SENSORS
Sensor Solution
Tames Turbocharger
Smart Sensor Design
Adaptable Wireless Monitor
Low-Cost Monopole Antenna
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 a number of exciting projects this month. I’m not surprised
that the annual Measurement & Sensors issue always generates an espe-
cially high number of article proposals. This is a topic every engineer deals
with. We hope that the tips and solutions provided in this month’s features
and columns leave you with fresh ideas on how to approach even your
most difficult applications.
First up, we have Alberto Ricci Bitti’s award-winning wireless monitoring
system from the Motorola Flash Innovation 2003 Design Contest (p. 10).
The MC68HC908-based system monitors data from 20 sensors. A com-
puter-controlled receiver, an LCD, and a relay output comprise the moni-
toring station. Data collected from the sensors is displayed on the LCD.
Alberto enhanced the system by enabling the computer-controller receiver
to trigger an automatic dialer to call the user’s phone with an alarm mes-
sage.
In this issue, you’ll also find an interesting article about the “crank trig-
ger thing” (p. 20). It might not sound sophisticated, but don’t let that fool
you. This is a project for gearheads who want to give their cars a little more
kick. Using a Microchip PIC microcontroller and a Motorola pressure sen-
sor, Pete Rizun and William Hue designed a system that eliminates the
engine knocking typically caused by aftermarket turbochargers.
Commercial systems designed to stop engine knocking work by slowing
the ignition timing, often so aggressively that it sacrifices power. Pete and
William’s system improves upon commercial solutions by allowing more
gradual, adjustable retardation of the crank trigger sensor’s timing signal
so that the engine retains its horsepower.
You may remember a few names from the next team of writers from an
article they wrote in November 2002 titled “A Low-Power Embedded
Thermal Sensor System” (Issue 148). The team of researchers from North
Dakota State University is back (with a couple new members) with a prac-
tical solution for wireless sensor projects (p. 28). Commercial antennas
can be pricey, and are often too expensive for a modest budget. Not will-
ing to settle for an “under-performing” antenna, the team wanted to devise
something new that would be just as effective as commercial whip anten-
nas. Interestingly, they discovered that a steel guitar string could be used
to create an inexpensive and highly effective monopole antenna.
Fred Eady also needed to watch his pennies when he took a job design-
ing a system to monitor temperature in a small holding tank. He needed to
build a control panel interface that uses resistance temperature detectors
(RTD) so that the temperature could be monitored in the field. What he
came up with is portable and significantly less expensive than lab-grade
commercial equipment, yet just as accurate. In his column, “Adaptable
Temperature Measurement System,” Fred describes the system, which is
designed around a Microchip PIC18F452 and a PRTD from RTD Company
(p. 60). He also included Bluetooth modules to add wireless capability.
Lastly, for those of you who find designing smart sensors complicated,
you’re not alone. Jeff Bachiochi discusses the finer
4
Issue 167 June 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 © 2004 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
CONTROLLER
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
Tips and Solutions
jennifer.huber@circuitcellar.com
TASK MANAGER
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
6
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
June 2004: Measurement & Sensors
Alberto Ricci Bitti
Flash Innovation 2003 Design Contest Winner
TASK MANAGER
Tips and Solutions
Adaptable Temperature Measurement System
FEATURES
COLUMNS
DEPARTMENTS
PRIORITY INTERRUPT
To TiVo or Not to TiVo
Crank Trigger Modification Eliminates Engine Knocking
Pete Rizun and William Hue
B. Thurow, J. Jorgenson, D. Kakumanu,
B. Morlock, and M. Schmitz
Renesas H8 Design 2003 Contest
Simple Bluetooth Integration (Part 2)
Interfaces and ECI Protocol
Anders Rosvall
ZRT Real-Time Operating System
New Microcontrollers Meet Increasing Demand
Scott Pape
Designing with the Nios (Part 1)
Second-Order, Closed-Loop Servo Control
George Martin
Back-to-Basics Lesson in Robotics (p. 56)
Wireless Monitoring System (p. 10)
8
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
NEW PRODUCT NEWS
ISOLATED ADC
The AD7400 and AD7401 provide an isolated sigma-delta
solution, featuring 12-bit linearity and sample rates up to
20 msps. They are ideal for current monitoring in motor con-
trol applications. Varying the input signal controls motor speed
in lifts, pumps, and fans. The integration of iCoupler isolation
technology allows for isolated, high-speed data rates with low
power. The ADC inputs are optimized for monitoring current
through shunt resistors while protecting the digital communi-
cation lines with a 3.75-kV reinforced isolation barrier.
The converter operates from a 5-V power supply and accepts
a
±
200-mV signal range, making it suitable for direct connec-
tion to current shunts. The converter’s offset drift is 5 µV/°C,
half that of competitive solutions. Two versions are available:
the AD7400 features an internal clock to minimize exter-
nal components, and the AD7401 uses an external clock to
synchronize multiple con-
verters.
The AD7400 and
AD7401 are available in 16-
lead SOIC packages and
cost $4 in 1,000-piece
quantities.
Analog Devices, Inc.
www.analog.com
Edited by John Gorsky
IN-CIRCUIT PROGRAMMING ADAPTER
The ISPICR1 adaptor enables the in-circuit programming
of a variety of PIC microcontrollers. It also can be used with
other serially programmed parts.
The adaptor interfaces between the ZIF socket of the user’s
existing programmer and the target board. The ISPICR1 is com-
prised of an adapter PCB and connecting cable that terminates
in a Molex Picoflex socket. A mating Picoflex plug, which is
designed for mounting on the target PCB, is also supplied.
Custom connectors may be included.
After the adapter is fitted between the ZIF socket and the
target PCB, programming using the ICXP technique can take
place in exactly the same way as if the device were mounted
directly in the ZIF socket. The ISPICR1 costs $35.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
9
You may contact the quizmasters at eq@circuitcellar.com
CIRCUIT CELLAR
—
Test Y
Your E
EQ
Problem 4
—
What is the following circuit?
Contributed by David Tweed
Edited by David Tweed
Problem 1
—
How does an insulated gate bipo-
lar transistor (IGBT) work? Draw the equivalent
circuit.
Problem 2
—
What is the basic topology of a
switch mode buck regulator?
Problem 3
—
What is the basic topology of a
switch mode boost regulator?
Coil
Input
Diode
Switch
#2
Output
Capacitor
Switch
#1
addition, mouse sensors must be bat-
tery operated, so the batteries must
last for years of continuous service.
This calls for low-power parts and
carefully designed software.
Another requirement is that the sys-
tem be able to resolve collisions that
result from the simultaneous trans-
mission of two or more mouse sen-
sors. It should also tell you when the
batteries need to be replaced and be
able to detect when a trap is lost or
destroyed, which isn’t an unlikely
event in industrial environments.
And, of course, the system must be
simple, resistant to dirt, reliable, and
easy to manufacture.
On the receiver side, the monitoring
station must be cost-effective, depend-
able, and easy to set up and use. It
must show complete trap information,
and the configuration data must be
retained after power interruptions.
The design should be compact, modu-
lar, and flexible. As with all new prod-
ucts, additional requirements are
expected to emerge as work on the
design progresses; therefore, high-level
programming languages are preferable.
MCU SELECTION
Not many years ago, I would have
started this design by selecting a spe-
cialized remote control encoder/
decoder IC pair, looking for ultralow-
power parts, and adding glue logic. If a
microcontroller were required, I
would have selected an MCU with a
familiar architecture and instruction
10
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
O
ne of the things I have learned
from my everyday engineering prac-
tice is that there is always room for
ingenuity and improvement. This is
particularly true for this project,
which applies a couple of inexpensive
microcontrollers to an unusual device:
a live-catch mousetrap.
Mousetraps of this kind imprison
mice instead of killing them with
chemicals or bloody mechanisms.
They are useful when regulations,
laws, or just plain common sense for-
bid the use of poisons and chemicals.
This applies to the food industry, from
farms to your preferred restaurant, as
well as places like schools and homes
(where children and pets can open
traps) and even hospitals and pharma-
ceutical facilities (where contamina-
tion should be avoided). As you can
see, I’m talking about a worldwide
market with millions of customers.
Unfortunately, live-catch traps are
extremely expensive to maintain
because of the labor costs required to
continuously check them. Although a
single mouse catch is a rare event in
today’s hospitals or pharmaceutical
depots, the traps must be checked
every few days. Making matters
worse, the traps are often located in
places that are difficult to access.
I designed my system with the
objective of drastically cutting the
labor costs involved with checking
traps (see Figure 1). Now you can
leave the traps unattended until the
system calls for assistance.
Alberto’s MC68HC908-based wireless monitoring system is adaptable for use in domes-
tic and industrial settings. The central monitoring station, which consists of a computer-
controlled receiver with a relay output and LCD, logs and displays data from up to 20 dif-
ferent sensors. Read on to learn how to build, program, and test your own system.
My system consists of a monitoring
station—a computer-controlled receiv-
er with an LCD and relay output—and
up to 20 mouse sensors. It works by
placing a mouse sensor (a small plastic
box) inside each trap. When a mouse
is captured, the sensor transmits its
trap identifier to the monitoring sta-
tion, which logs and displays it where
it’s conveniently viewed.
Alternatively, the receiver can dis-
patch the call to an external service,
triggering an ordinary automatic
phone dialer connected to its relay
out. Refer to the “The System at
Work” sidebar for more information.
NONTRIVIAL REQUISITES
Although conceptually simple, such
a system design is nontrivial. The
parts count must be kept to a mini-
mum in order to contain costs. The
dimensions are essential to fit even
the smallest traps on the market. In
FEATURE ARTICLE
by Alberto Ricci Bitti
Trap transmitters
Monitoring
station
Phone dialer
Figure 1—
My goal was to cut labor costs and elimi-
nate the need for weekly trap checks. A transmitter is
placed in every trap to signal the presence of mice. If a
trap needs to be emptied, the system automatically
calls home.
Wireless Monitoring System
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
11
set. The time it takes to learn the
development tools (not to mention
the cost) would have influenced my
choice.
Nowadays, the design path is some-
what reversed: MCU selection is one
of the first steps in the design process.
You can use general-purpose, low-cost
microcontrollers for tasks previously
done with dedicated ICs, with the
extra advantage of adding functionali-
ties in the software. Tools are inex-
pensive and sometimes free. In addi-
tion, it’s no longer necessary to know
assembly language because high-level
language compilers are available for
programming (including the smallest
possible controllers).
I selected the 8-bit MC68HC908
microcontroller for this design. The
same MCU core comes in a tiny eight-
(QT suffix) or 16-pin (QY) package, with
128 bytes of RAM and 1 to 4 KB of
flash memory. This IC includes unique
features that make it perfect for this
application. It does not require external
reset, and its flash memory-calibrated
internal oscillator is suitable for bat-
tery-operated devices because it keeps
steady despite varying power voltages.
Therefore, all of the pins—except the
power supply—are available for input
and output, which makes the eight-pin
packaging effective for the trap trans-
mitter. The 16-pin version nicely fits
the receiver’s requirements.
At an aggressive price, I’m talking
about a truly classic MCU, with a
true stack, capable of running true
ANSI C code. Note that there is also
hardware support for one-pin in-cir-
cuit debugging (ICD), so
an emulator isn’t
required. Furthermore,
flash memory can conve-
niently emulate EEP-
ROM, a feature I used to
store trap IDs.
As for the tools, the
Metrowerks Codewarrior
IDE includes an assem-
bler, ANSI C compiler,
simulator, programmer,
in-circuit emulator/
debugger, and even a light
version of Processor
Expert, which is an auto-
matic C code generator.
Although the tools are professional-
grade, they are available for free.
SYSTEM BUILDING BLOCKS
The block diagrams here show how
most of the building blocks have
moved from external hardware to inter-
nal software modules. The transmit-
ter’s block diagram counts only three
blocks outside the chip, as opposed to
six internal function blocks supported
by the MCU through a combination of
software and on-chip peripherals (see
Figure 2). The parts outside the micro-
controller are the sensor mechanism
and reed relay, two keys for setting up
the trap ID and arming the trap, and a
433-MHz low-power transmitter with a
rod antenna. The power comes from a
couple of button batteries.
Inside the microcontroller, software
modules implement a digital generator
for encoding data to be transmitted, a
scheduler for cyclic “keep alive”
transmissions, storage of user-pro-
grammable nonvolatile ID data, a
detector for the battery charge state, a
manager for a simple mechanism to
prevent overlapping transmissions,
and a module for administration of the
low-power modes.
The monitoring station includes a
433-MHz receiver module and its
antenna, a relay stage for driving an
external alarm or phone dialer, a 2 ×
16 LCD module, and a five-button
keyboard. I powered the unit with a
wall-cube mains adapter through a lin-
ear regulator stage. As for the trans-
mitter, many of the functional blocks
are implemented by the MCU that’s
MCU (QT)
• RF Encoder
• Scheduling
• Nonvolatile trap ID
storage
• Low-battery detect
• Collision prevention
• Low-power
management
Trap unit
(up to 128 different trap IDs)
Battery
2 × button cell
433-MHz
Transmitter
Mouse
sensor
Keyboard
433-MHz
Receiver
Keyboard
MCU (QY)
• RF Decoder
• Error/collision
detection
• User interface
• Nonvolatile
configuration
• Trap database
Relay
output
Power
supply
Monitoring station
(up to 20 traps per station)
LCD
Figure 2—
As you study the transmitter and receiver block diagrams,
keep in mind that the microcontrollers contain most of the functions
required by the system. This keeps the number of external parts to a min-
imum. The functions listed in the MCU boxes are implemented with a
mixture of software and on-chip peripherals.
THE SYSTEM AT WORK
The system is in Automatic mode
at power-up. Photo 1a is the mes-
sage for normal operation when no
traps are triggered.
Photo 1b depicts a situation when
a trap trigger is signaled immediately.
The system supports up to 20 trap
memories. Trap IDs can range from 0
to 127. If more than one trap triggers,
their respective messages scroll auto-
matically every few seconds. Press
Clear to reset the message.
The system checks if a trap gets lost
(no signal is received for more than 6
h), as well as if its battery is exhausted
(see Photo 1c). To select Manual mode,
press the Forward or Back keys in order
to browse trap messages (see Photo 1d).
In Manual mode, you can check data
for all of the 20 trap memories, includ-
ing those still free (see Photo 1e).
The Setup key enters Setup mode.
To add a new trap, search for free
memory and press Rearm on the
trap itself. Its ID will appear imme-
diately on the screen. Press Store to
assign it to the memory currently
selected (see Photo 1f).
Press the Clear button to delete a
trap and free its nonvolatile memory.
A trap’s Rearm key also serves as
reset after a trigger is detected and
the trap is emptied. The Setup key
on the transmitter changes the trap
ID, scrolling IDs from zero to 127.
You can check the new ID on the
screen because it is immediately
transmitted with each key press.
Photo 1—
Here’s how it works step by step.
a)
b)
c)
d)
e)
f)
12
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
in charge of decoding the receiver out-
put and discriminating errors that
result from bad reception, interfer-
ence, or the simultaneous transmis-
sion of two or more mousetraps.
The MCU also stores trap informa-
tion. It registers trap IDs in (internal)
nonvolatile memory and programmati-
cally updates trap status records in
RAM. The user interface block con-
sists of a trap data browser and a con-
figuration mode for learning trap IDs. A
monitor station can handle up to 20
transmitters—although a transmitter ID
can range among 128 different IDs—to
allow more than one monitor to oper-
ate on the same or overlapping areas.
MOUSE SENSOR
The first problem I had to solve was
how to sense the presence of mice. I
discarded electronics-only methods
(e.g., photocells and capacitive sens-
ing) one after another. Some were too
sensitive to dirt, expensive, and diffi-
cult to clean; others were too accessi-
ble to munching rodents and con-
sumed too much power. In this con-
text, drawing a continuous 5 µA
(equivalent to a 1-M
Ω
resistor at 5 V)
represents significant power!
I was about to give up, when I saw a
program on the National Geographic
Channel showing the natural curiosity
and vitality of mice. Realizing this, I
added a little balance to the trap trans-
mitter (see Photo 1). Sooner or later,
an unwary mouse—frantically search-
ing the trap for an escape route—will
reach the balance. The balance freely
pivots on the transmitter’s aerial. A
small magnet glued on one side coun-
terweights it. I placed a reed-relay
inside the sensor body to detect mag-
net movements and to trigger in turn
the eight-pin processor. Bingo! It’s like
having the mouse switch on the trans-
mitter for you!
Photo 1—
The trap sensor/transmitter unit prototype is
housed in a small plastic box. Putting your fingertip on
the balance brings the magnet in front of the reed
switch. Note how the antenna doubles as a pivot for the
balance.
Figure 3—
The 68HC908QT4 is the heart of the trans-
mitter. It embeds a brownout reset as well as a cali-
brated oscillator that makes reliable data transmission
possible without crystals or resonators. The TX module
can be changed in order to suit national regulations
and frequencies. The reed switch closes when the
mouse moves the sensor balance.
Figure 4—
The receiver has few parts. Pull-ups, an oscillator, reset generation, and EEPROM are all included in the MCU. Connections to LCD pins 15 and 16 (backlight) and
R2 can vary to suit your LCD’s specifications. Older LCDs need a contrast control voltage to be set on pin 3. The relay can trigger a phone dialer when a trap triggers.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
13
TRANSMITTER CIRCUIT
The transmitter’s schematic dia-
gram accounts for few parts other than
the eight-pin processor (see Figure 3).
The more that’s inside the MCU, the
less that’s outside. This means not
only a leaner bill of materials, but also
a small circuit footprint, which is
important in this application.
I connected two of the six available
I/O pins to push buttons for rearming
the trap after trigger detection and to
set up the trap ID. Another pin goes to
the reed-switch trap trigger. These pins
are pulled up internally by the MCU.
A fourth pin drives the 433.92-MHz
2-5000-786 thick film transmitter
module. It is compliant with European
frequency standards and measures
only 25.5 mm × 12.5 mm. The modu-
lation method is on/off keying (OOK)
according to the status of the PTA5
pin. When it isn’t transmitting, the
module consumes as little as 0.1 µA
(more on this later). Check this figure
when replacing it with similar parts,
because it is vital for battery life.
The only remaining components on
the board are a bypass capacitor (CF1)
and an electrolytic capacitor (C1)
required to lower the output impedance
of the two button-type batteries that
power the circuit. The circuit is compat-
ible with user-monitor mode in-circuit
programming. Connect the ICD inter-
face to pin 7 to watch the code run.
MONITORING STATION
Figure 4 reveals the receiver’s inter-
nals. I used modules for the LCD and
the radio receiver; therefore, the
design is noticeably neat and contains
few parts. The MC68HC908QY fea-
ture set contributes to the circuit’s
tidiness. It includes input pull-ups, a
steady internal clock oscillator, a
brownout detector and reset genera-
tion, and flash memory that can be
used as a replacement for EEPROM.
The 433.92-MHz receiver module
takes the signal from the antenna and
converts it to a more manageable digital-
level pulse train. The receiver can be
replaced with similar models to suit
national regulations and frequencies.
The microcontroller processes the
pulse train in order to distill meaningful
signals from the inevitable RF noise
background. It then displays the results
on the 2 × 16 LCD module, which is
connected in 4-bit mode, requiring six
out of the 14 available MCU I/O pins.
The LCD software driver assumes
pins DB0 through DB3 to be at logic
level 1 or unconnected. Depending on
your LCD module, you may need to
apply a contrast control voltage from 0
to 5 V to pin 3. Recent modules usually
work well with this pin unconnected.
The keyboard, which consists of
five push buttons, takes another five
pins, which have their internal pull-
ups enabled. I kept ICD pin (port A0)
free for in-circuit debugging, as I did
for the transmitter, making the board
user monitor-debug compatible.
The last available pin is used to
drive the relay output, which is real-
ized with a classic transistor stage and
a diode for protection against coil’s
over-voltages. The circuit is mains
powered through a wall adapter sup-
plying 9 to 12 VDC, regulated to 5 V
by IC2, a classic 7805 stage. Diode D2
14
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
protects the circuit from
power reversals. Resistor
R2 limits the current for
the LED backlight to a
safe 40 mA. The back-
light works from an
unregulated power supply.
CONFLICT
PREVENTION
To ensure reliable data
circulation, the system
must cope with the pos-
sibility of a simultaneous
transmission from two or
more traps. Another cause
of trouble is interference
from the cluttered license-
exempt RF band. To pro-
tect the integrity of the
data, the system acts on
both the transmitter and
receiver ends.
With a period determined
by its heartbeat function,
the transmitter sends the
trap status, encoding it as a
packet of 11 width-modulated pulses. It
repeats the pulse train numerous times
to add redundancy.
In order to distinguish RF noise from
real data, the receiver checks the shape
of the pulses before accepting them.
Pulses too long or too short are discard-
ed. As an additional requirement, it
rejects any data that isn’t preceded by a
silence gap. Lastly, the receiver must
get two identical data packets consecu-
tively in order to validate them.
Simple redundancy like this does not
protect against the unwanted synchro-
nization of two or more transmitters,
which, for example, can happen as a
consequence of clock frequency drifts
over long periods. To minimize this
problem, I altered the data repetition
rate and heartbeat period in accordance
with trap IDs, as shown in Figure 5.
If two traps start transmitting at the
same time, their repeated packets over-
lap at different points at each repetition
because of the variable spacing between
them. The receiver discards this vari-
able interference pattern because the
redundancy check requires two identi-
cal packets to accept data.
There is always the possibility that a
transmission will get lost as a result of
complete overlapping. In that case, you
must wait the long retransmission peri-
od (heartbeat) for another chance at
receiving the information. There will be
no collisions on the next heartbeat,
because the heartbeat period differs
from one transmitter to another as it
varies according to trap ID. Therefore,
the system occasionally allows heart-
beat signals to be missed as a conse-
quence of external interference, poor
reception, and (although not particular-
ly likely) trap-to-trap overlaps. The
Trap 1
Trap 2
Pulse train
Train repetition gap,
varies with ID
Long retransmission period,
varies with ID
Receiver
Discard
(not repeated)
Discard
(gap missing)
Accept
Discard
Accept
(two identical + gap) (not rep.)
(two identical + gap)
Figure 5—
To protect data integrity, actions are taken on the transmitter and receiver ends. The
transmitter repeats its data after a short pause, whose length varies in accord with ID. The
receiver discards any data that is not repeated. ID-dependent gaps are also used for longer peri-
odic retransmissions in order to avoid the parasitic synchronization of two or more transmitters.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
15
receiver knows that a trap is still alive
from its heartbeat. If more than 6 h slip
away without receiving a single heart-
beat, the receiver deems the trap lost
and sends you a signal.
SOFTWARE BASICS
I wrote the C code for the transmit-
ter first. I didn’t have a prototype at
the time, so I ran the software on the
Motorola QT demo board, using an
oscilloscope to verify the signals. The
demo board runs in User Monitor
mode. It is preloaded with a small
monitor program that fits a handful of
unused flash memory bytes and uses
interrupt table relocation to offer sin-
gle-pin, in-circuit emulation and pro-
gramming. I changed the value of
InitConfig1 to %00100111 to allow
for the use of the
STOP instruction.
The demo board circuit and user-
monitor program are detailed in Jim
Sibigtroth’s application note titled
“User Mode Monitor Access for
MC68HC908QY/QT Series MCUs.”
You must use the user monitor to
load and run the transmitter and
receiver software. To do so, follow the
procedure described in John Suchyta’s
application note, “Reprogramming the
M68DEMO908QT4.” The transmitter
code structure is straightforward,
although it requires special program-
ming to optimize power consumption.
I grouped hardware-specific details
in the hardware.c file, which you may
download from the Circuit Cellar ftp
site. It hides port and register initial-
izations, aliases for all of the pins used,
macros for manipulating them (to dis-
able trigger input pull-ups), functions
and macros to go in Stop and Wait
modes, and interrupts. Where possi-
ble, I prefer to handle port pins at the
bit level, setting bits individually
instead of setting the entire port at the
same time. This makes the code more
flexible, allowing painless pin swapping
when routing a PCB for production.
The main.c file, which is the appli-
cation’s body, implements the usual
big endless loop found on most
embedded systems. At each loop, the
MCU awakens from Stop mode and
checks if it has been called by the
keyboard interrupt (buttons pressed,
sensor triggered) or the wake-up timer.
It also checks the battery level. If the
sensor detects a mouse or key press (or
at almost every hour), the MCU for-
mats and transmits the trap status.
The trap status is formatted for
transmission, assembling a start bit,
the 7-bit ID, and the trap-triggered and
low-battery flags, in addition to a spe-
cial test flag (set when the Rearm but-
ton is pressed) that’s used when con-
figuring the system. As you can see in
Listing 1, the code word is handed to
the
rf_encoder() routine, which
uses the 16-bit timer combined with
the processor’s Wait mode to generate
a train of 33% or 66% duty cycle puls-
es (see Figure 6).
The monitoring station software is
more complex. Refer to Figure 7 for
help understanding its main structure.
The receiver gets the most recent data
from the radio decoder. Should the
data match any of the traps stored in
its internal database, the respective
record is updated to reflect the new
status. The receiver presents trap
information according to the current
user-interface mode (Automatic or
Manual Scroll mode), which deter-
mines how to layout LCD data and
react to keyboard clicks.
In order to execute time-scheduled
housekeeping routines, the receiver
checks the timeflags structure. Its dif-
ferent bits are set by the timer inter-
rupt routine to indicate if twentieths,
Listing 1—
The routine in charge of transmitting the code word invokes
WAIT_MODE to wait one-third bit
time in Low Power mode.
TX_ON and TX_OFF macros drive the RF module. The hardware.h file hides
implementation details for the macros, making the code easier to read.
static void rf_encoder(unsigned int codeword)
{
unsigned int mask;
//Prepare for timer overflow every 0.33 ms (a bit third)
//Overflow will wake up from Wait mode
TMOD = CLOCK_FREQ * BIT_THIRD_DURATION;
//Prepare mask for filtering leftmost bit
mask = 1 << (CODE_BITS - 1);
while( mask != 0 )
{
TSC_TSTOP = 0;
//Restart timer
WAIT_MODE;
//Go in low-power mode until a 0.33-ms
//period expires.
if ( (codeword & mask) == 0 )
//Are you transmitting a zero?
TX_ON;
//Yes, force a 66% duty cycle.
WAIT_MODE;
//Go in low-power mode until a 0.33-ms
//period expires.
TX_ON;
//Set output to ensure a duty cycle no
//less than 33%.
WAIT_MODE;
//Go in low-power mode until a 0.33-ms
//period expires.
TX_OFF;
//Turn off transmitter
mask >>= 1;
//Prepare mask for filtering next bit.
};
TSC_TSTOP = 1;
//Stop timer before exit to reduce power
//consumption.
}
11 Pulses
Pulse train gap greater
than 11 ms
Pulse duration = 3 × 0.33 ms = 0.99 ms
Start
7-bit ID
Trigger
1
0
1
1
1
0
1
1
1
1
0
Low battery
Test mode
Figure 6—
Transmitter data is packed in 11-bit code words. Pulse-width modulation is used for transmission, with
66% and 33% duty cycle pulses representing zeros and ones respectively. To add redundancy, code words are
repeated and spaced apart at least 11 ms. (The exact value varies according to the trap ID.)
seconds, minutes, or hours
have elapsed. Every second,
the receiver updates a time-
out that serves to restore
Automatic mode after a
short period of nonuse.
Every hour, the receiver
updates the trap heartbeat
counter. Finally, if a trap
needs to signal an alarm
condition, the receiver acti-
vates the relay output and
repeats the entire cycle
from the beginning.
According to good pro-
gramming style, I encapsu-
lated the various functions
(radio decoder, trap database
manager, flash memory-
based EEPROM emulation, keyboard
and LCD drivers, delay routines, and
hardware-related primitives) in separate
files orchestrated by main.c. Note that
trap ID codes are stored in flash memo-
ry, which is used as a sort of EEPROM.
[1]
Contrary to popular belief, C lan-
guage code and data encapsulation are
not flash memory-hungry ogres. In
fact, the complete application requires
only 3 KB. This suits these little 4-KB
devices nicely, leaving plenty of space
for future expansions.
CUT THAT POWER BILL
Getting minimal power consump-
tion requires careful design and pro-
gramming—no detail can be ignored.
The CR2025 lithium battery can sup-
ply 170 mAh. This translates to an
average of 19 µA over a one-year peri-
od. The single sensor internal pull-up
can easily draw 10 times that current
(see Figure 8)! Therefore, it’s wise to
disable the pull-up after a trap trigger
is detected: simply switch its data-
direction bit, making the pin an out-
put, and set the output to zero. (Refer
to the
REED_ENABLE
and
REED_DISABLE
macros in hardware.h.)
Another trick is to
enable pull-ups for port B.
Although not bonded
out on the eight-pin QT
part, they exist on the
silicon. This is why I
included QY in place of
QT header files in the
transmitter project.
Most of the time, the
MCU is in Stop mode,
relying on an automatic
wake-up timer and key-
board interrupts to get
16
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
back on from time to time.
The timer interrupt replaces
the usual software-based wait
loops, making the MCU rest
in Wait mode during transmis-
sion in order to reduce power.
To save additional current, I
disabled the ADC and stopped
the 16-bit timer when it was-
n’t in use. Refer to Donnie
Garcia’s “MC68HC908QT4
Low Power Application” for
tips about low power.
Photo 2 shows the current
drawn by the prototype during
transmission. I took the meas-
urement from the voltage drop
through a 100-
Ω
resistor in
series with the positive supply.
A 5-V bench supply powered the circuit.
The average current over a full
transmission cycle (see cursors) is just
1.9 mA. The trap transmits for up to
200 ms every hour during operation
(i.e., 1/18,000 of the time), requiring
0.1 µA (1.9/18,000) on average. This
contributes to the current required by
the circuit in Stop mode, which can be
anywhere from 0.1 to 5 µA, according to
the datasheets. My prototype required
approximately 3 µA, which means
that it can theoretically run for about
55,000 h from a 170-mAh charge. That’s
six years! In practice, the actual battery
life might be noticeably shorter than
this because of environmental condi-
tions, tolerances, and discharge curves.
SYSTEM TEST
I built a couple of prototypes to per-
form preliminary tests. I used dual-in-
Manual
mode?
Setup
mode?
Initialize register, timer,
keyboard, radio, LCD,
relay, trap data
Get data from radio
receiver/decoder
Use radio data to update
trap database
Automatic user interface
1 s elapsed?
1 h elapsed?
Any active trap?
Clear relay output
N
N
N
N
N
Manual
user interface
Setup
user interface
Y
Y
Update
interface timeout
Update
heartbeat counters
Set relay
output
Y
Y
Y
Figure 7—
The software is in charge of polling the RF
module, updating the trap database, running the user
interface, and performing time-scheduled checks. A differ-
ent
interface is presented according to the operating
mode: Automatic, Set Up, or Manual. The timeout flag
and RF module data is updated by interrupt service rou-
PUEx = 1
30 k
Ω
Input
DDRx = 0
PTx = 0 or 1
PUEx = 0
30 k
Ω
Output = 0
DDRx = 1
PTx = 0
Figure 8a—
When the switch is closed, the input pull-up (ranging from 16 to
36 k
Ω
) can eat up 10 times the average current required by the entire cir-
cuit. b—To avoid unnecessary current leaks, after a switch closure is
detected, the pull-up is disabled and the pin direction is changed to an out-
put, whose value is set to zero.
a)
b)
Photo 2—
The batteries last for years. Using Wait mode limits the average current
during transmission to 1.9 mA. The overall average consumption is just 3.1 µA
because data is transmitted only one time per hour (voltage drop on a 100-
Ω
series resistor: vertical = 100 mV/div, horizontal = 10 ms/div).
18
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
SOURCES
4M50RR30SF Receiver module
Aurel S.p.A.
+39 0546 941124
www.aurel.it
Codewarrior Development Studio for
HC08
Metrowerks
(800) 377-5416
www.metrowerks.com
2-5000786 Transmitter module
Mipot
+39 0481 630200
www.mipot.com
68HC908QT4 and 68HC908QY4
Microcontrollers
Motorola, Inc.
(800) 521-6274
www.motorola.com
PROJECT FILES
To download the code, go to ftp.
circuitcellar.com/pub/Circuit_Cellar/
2004/167.
REFERENCE
[1] P. Topping, “EEPROM Emulation
Using FLASH in MC68HC908QY
/QT MCUs,” Motorola, AN2346/D,
September 2002.
RESOURCES
D. Garcia, “MC68HC908QT4 Low
Power Application,” Motorola,
AN2310/D, August 2002.
J. Sibigtroth, “User Mode Monitor
Access for MC68HC908QY/QT Series
MCUs,” Motorola, AN2305, July
2002.
J. Suchyta, “Reprogramming the
M68DEMO908QT4,” AN2322/D,
August 2002.
line MCU samples that are suitable
for prototype boards and manual sol-
dering. I placed the transmitter inside
an off-the-shelf plastic box measuring
only 54 mm × 58 mm × 28 mm, which
looks spacious (see Photo 1). Production
units can be much smaller than this.
An older solder station case, refur-
bished for the occasion and completed
with a few Dremel tool touches, pro-
vided an excellent enclosure for the
receiver board (see Photo 3).
You can place the transmitter inside
most commercial traps without diffi-
culty. However, the transmitter range
is greatly reduced for all-metal traps
because of the shielding effect. A
future release should provide an exter-
nal aerial. Special hardened plastic
must be used for the transmitter box
because it’s likely that some rodents
will try to bite it. I am also consider-
ing reducing the number of possible
trap codes from 128 to 64, or even 32,
to make the ID set up less tedious.
The system works well, with nei-
ther false nor missed triggers. At last,
I can monitor traps in the attic and
basement from my desktop!
PLEASURE TO DESIGN
This project was a pleasure to
design. The result is a simple and
viable solution with excellent overall
features. I hope you acknowledge its
technical merit, too!
The system is highly optimized,
with only a few components on the
transmitter and receiver boards.
Therefore, the system is definitely cost-
effective, particularly the trap unit.
Because there are up to 20 traps per
receiver, even a $0.05 saving grows to
be a dollar for a complete system.
Before starting this design, I was
skeptical (to say the least) about the
possibility of writing true C code for an
eight-pin processor with only 128 bytes
of RAM. Now I’m glad that I tried it.
The compiler does a wonderful job of
optimizing every single bit, and I had
no trouble porting portions of code
that were originally written for larger
processors.
In the race for a better mousetrap
there is no shortage of competition. I
hope to see this unit in production
some day. In my opinion, the design
suits series-production technologies
because it is easy to manufacture and
test, and it doesn’t require calibration.
Nevertheless, being modular by
design and flash memory microcon-
troller-based, you can easily adapt the
system and add new features. System
variants can range from translation to
languages other than English and inte-
gration in a home control system, to the
use of different radio frequencies. For
use in your home, you can replace the
LCD with a few LEDs. Furthermore,
you can use the same basic design for
other tasks, like checking if all of your
windows and doors are closed. But
that’s another story.
I
Photo 3a—
The receiver box is recycled from an old soldering station. b—The receiver is simple enough to be assem-
bled on a prototype board. The display and keyboard are fixed to the front panel with thick double-adhesive tape.
a)
b)
Alberto Ricci Bitti holds a degree in
Computer Science from the University
of Milan. He has more than 10 years
of experience designing and writing
software for embedded systems.
Alberto currently designs industrial
controllers and instrumentation for
Eptar. In his free time, he enjoys com-
peting in design contests. Alberto has
been awarded several prizes. You
may visit his web site, www.ricci
bitti.com, or write him at a.riccibitti@
iname.com.
enough to stop the knocking without
robbing precious horsepower.
Because our device modifies the tim-
ing signal from what’s known as the
“crank trigger sensor,” we called it the
“crank trigger thing,” or CTT for short.
The rest of this article describes our
CTT, how it works, how it integrates
with a vehicle, and how it feels to drive
with it. Let’s begin with some theory.
IGNITION TIMING
To understand how the CTT works,
you need to know a bit about ignition
timing and engine knocking. The
modern automobile engine operates on
the Otto cycle with four distinct
cycles, or “strokes”: intake, compres-
sion, power, and exhaust. Ignition tim-
ing is measured as degrees of crank-
shaft rotation relative to the top-dead-
center (TDC, the highest point) posi-
20
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
O
ur friends at Momentum Motor
Parts had a problem after installing
aftermarket turbochargers in their cus-
tomers’ Volkswagens: when a car was
driven hard, the engine would knock,
placing dangerous stress on the
engine’s components.
The company’s first solution was a
commercial system made by Brand X.
Brand X’s system monitors tur-
bocharger boost pressure and retards
the ignition timing by 18
°
when the
boost pressure reaches a certain level.
Although the Brand X system elimi-
nated the knocking, there was a dis-
tracting lurch the instant the device
kicked back the timing and a notice-
able loss of horsepower after that. The
customers were dissatisfied.
After hearing about this problem,
we decided to design an improved
device that would not cause such a
noticeable loss of power
when the timing was
changed. We decided that
the device would be based
on the same principle of
retarding ignition timing
as the boost pressure
increases, but the timing
delay would be more grad-
ual, hopefully eliminating
the sudden loss of power.
Also, the pressure thresh-
old for the onset of timing
retardation would be
adjustable so that the tim-
ing could be delayed only
Turbocharged Upgrade
If you push a car with an aftermarket turbocharger too hard, its engine will knock. You don’t
need to be a trained mechanic to know that this puts stress on an engine. As a solution,
Pete and William put a PIC16F73 and an MPX4250AP pressure sensor to work in a device
that eliminates engine knocking without draining too much horsepower in the process.
tion of a given piston between its
compression and power strokes.
Timing of –35
°
means the spark plug
fires 35° before the piston gets to TDC.
Similarly, timing of 5
°
means the spark
occurs 5° after TDC.
Performance sports car tuners know
that advancing ignition timing gener-
ates more horsepower. They also know
that if timing is increased too much the
fuel will begin to preignite and cause
knocking (see Figure 1). Tuners know
that the best performance is achieved
when the timing is advanced almost to
the point of knocking. Car manufactur-
ers know this too, and they equip new
engines with knock sensors and feed-
back mechanisms to retard ignition
timing if knocking is detected.
[1, 2]
Theoretically, maximum engine
horsepower is achieved if all of the
air/fuel mixture in the combustion
chamber explodes the
instant the piston passes
TDC—when the gas mix-
ture is at maximum com-
pression. In reality, the
air/fuel mixture requires a
finite amount of time to
burn. To maximize engine
horsepower, tuners set the
timing to ignite the fuel at
a point before TDC, so the
peak pressure occurs
slightly after TDC. In this
case, the explosion of the
highly compressed gas
performs the maximum
FEATURE ARTICLE
by Pete Rizun & William Hue
Nor
mal
Knoc
king
Figure 1—
Here you see the normal combustion process and the knocking combustion
process. Two wave fronts collide to produce a ping, or a knock, during a knocking com-
bustion process.
Crank Trigger Modification Eliminates Engine Knocking
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
21
The ECU must receive a signal to
indicate how far the engine’s crank-
shaft has rotated. In Volkswagens,
there is a toothed gear attached to the
crankshaft. Each tooth represents 6
°
of
crankshaft rotation. Because there are
360
°
around the entire gear, this gear
would have 60 teeth, but it is designed
so that two of the teeth are missing, as
indicated in Figure 2. The crank trigger
sensor (a magnetic variable-reluctance
sensor) monitors this gear and outputs
a pulse for each tooth that passes in
front of it. The sensor’s output is read
by the ECU. The ECU waits for the
two-tooth gap, counts 11 teeth, and
knows at this point that the first
cylinder is at TDC (see Figure 3).
To fool the ECU into firing the spark
plugs later, the CTT intercepts the tim-
ing signal from the crank trigger sen-
sor, measures the boost pressure, and
then modifies the timing signal so that
it appears delayed by an amount that
depends on the boost pressure. This
prevents engine knocking by allowing
the engine to run slightly cooler.
RETARDING THE SIGNAL
The simplest method for retarding
the signal is to add one or more addi-
tional teeth in the two-tooth gap and
delete an equal number of teeth after
the gap, as shown in Figure 4. Because
there is room for 60 teeth on the
crank trigger gear, adding an extra
tooth delays the gap by 6
°
(360
°
/60).
At maximum boost pressure, we
wanted to retard the signal by the
same 18
°
(three teeth) as the Brand X
system because we knew its system
eliminates knocking in all cases.
There are four modes of signal retarda-
tion: mode 0, when the signal passes
through unmodified; mode 1, when one
extra tooth is added; mode 2, when
two extra teeth are added; and mode 3,
when three extra teeth are added.
The amount of timing delay depends
possible amount of work on the piston.
Knocking occurs in several steps.
During the compression stroke, the
air/fuel mixture becomes hot because
of adiabatic heating. Then, the spark
plug fires, the fuel begins to burn, and
the temperature and pressure increase
further. The explosion of the air/fuel
mixture doesn’t occur instantly; a
flame front initiated by the spark plug
begins to expand within the cylinder.
The growing flame front pushes on
the hot, unburned gas, increasing its
pressure. The sudden rise in pressure
causes the additional adiabatic heating
of the unburned fuel. If hot enough, the
unburned fuel auto-ignites, and a new
flame front grows and eventually col-
lides with the original spark-induced
flame front, producing a pinging, or
knocking, sound. This phenomenon is
known as spark knock. It results in
dangerous stresses and increased wear
on the engine components.
[3]
Retarding the ignition timing can
cure knocking. When the timing is
retarded, the explosion occurs at a
later time. The bulk of the explosion
takes place at a lower pressure
because the piston is past TDC.
Decreasing pressure results in less adi-
abatic heating of the combustion mix-
ture and consequently a reduced risk
of auto-ignition. Additionally, the
peak temperature of the explosion is
reduced so there is less heat transferred
to the cylinder head and walls to spawn
preignition. Unfortunately, there is a
loss of horsepower because the bulk of
the explosion occurs at a lower pres-
sure. This is why the best performance
occurs when the timing is advanced
almost to the point of knocking.
In an aftermarket turbocharged
vehicle, much more horsepower is
produced than the engine was origi-
nally designed for. This leads to hot-
ter-than-expected cylinder head tem-
peratures and an elevated risk of
knocking. Although most modern
engine con-
trollers dynam-
ically correct
for knocking
by adjusting
the ignition
timing, they
work only over
a finite operat-
ing range. To compensate for the
increased horsepower and temperature
with the turbocharger, you need to
reengineer the engine’s spark curve—
the mechanism that dynamically
adjusts the timing. To do so, you can
fool the engine control unit (ECU) into
firing the spark plugs a bit later.
Knocking is eliminated
with this method, and
the ECU operates cor-
rectly because it
believes the engine is
operating within its
specified range.
FIRING THE SPARK
PLUGS
To stop the knock-
ing, you need to trick
the ECU into firing the
spark plugs a bit later.
But how does the ECU
decide to fire the spark
plugs in the first place?
Timing signal
CTT
Sensor
ECU
Modified
timing
signal
Boost pressure
Turbo
Timing
gear
Figure 2—
Without the CTT, the timing signal from the
crank trigger sensor arrives unmodified at the ECU . With
the CTT, the timing signal arrives at the ECU delayed by
an amount that depends on turbo-boost pressure.
Tooth #: 1
2
3
4
5
6
7
8
9
10 11 12 13
56 57 58 59 60 1
2
Figure 3—
The signal from the crank trigger contains 58 pulses followed by a two-pulse
gap. The ECU determines top dead center by counting 11 pulses after detecting the gap.
Mode 0 (0°)
54
55
56
57
58
1
2
3
4
5
6
54
55
56
57
58
2
3
4
5
6
54
55
56
57
58
3
4
5
6
54
55
56
57
58
4
5
6
59
59
60
59
60
61
Mode 1 (6°)
Mode 2 (12°)
Mode 3 (18°)
Figure 4—
The signal sent to the ECU is modified from the original (mode 0)
by adding one or more teeth before the gap and removing an equal number
of teeth after the gap. This delays ignition timing by 6°, 12°, or 18°.
22
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
among other things. A suffi-
ciently fast microcontroller
is necessary. We decided to
use the PIC16F73 because it
can run at 5 million instruc-
tions per second and has
three hardware timer/coun-
ters—Timer0, Timer1, and
Timer2—for timing and
counting pulses. It has a
five-channel A/D converter for reading
both the output of the turbocharger
boost pressure sensor and the poten-
tiometers that set the pressure thresh-
olds for the onset of timing retarda-
tion. Additionally, the PIC16F73 is
less expensive than other PICs with
similar peripherals.
To measure the turbocharger boost
pressure, we chose Motorola’s
MPX4250AP absolute pressure sensor
for its 0- to 5-V temperature-compen-
sated output, and the temperature of
the cylinder heads scale with absolute
pressure rather than gauge pressure.
on boost pressure (see Table 1). More
timing delay is needed at higher boost
pressure because boost pressure increas-
es horsepower and engine temperature.
The pressure ranges are adjustable via
potentiometers so that tuners can
achieve optimum performance with
various engine setups. The hex file
provided on the Circuit Cellar ftp site
does not allow for tuning.
PIC & PRESSURE SENSOR
The CTT must quickly process the
incoming signal from the crank trigger
sensor, count teeth, and time pulses,
SAFE DESIGN
We knew the CTT would be used in
high-performance vehicles driven at
high speeds, so our first priority was
to make the device safe. Should the
CTT malfunction, we didn’t want the
ignition-timing signal to the ECU to
cut out—this would prevent the engine
from firing the spark plugs, thus slow-
ing down the car in a surprising hurry.
We wanted to operate on the crank-
trigger timing signal passively. The idea
we had was that if the microcontroller
on the CTT does nothing, then the tim-
ing signal passes through unaffected.
When the microcontroller does some-
thing, it overrides the timing signal with
its own signal. The CTT schematic is
shown in Figure 5. The differential sig-
nal from the crank trigger sensor is
clipped by diodes to approximately 0.5 V
prior to being processed by the com-
parator. Positive feedback in the com-
parator circuit results in hysteresis, pre-
venting digital flicker. The digital sig-
Mode
Timing delay
Pressure
Mode 0
0
°
0 to 5 psi
Mode 1
6
°
5 to 10 psi
Mode 2
12
°
10 to 15 psi
Mode 3
18
°
Greater than 15 psi
Table 1—
As the turbo boost pressure increases, it is necessary to
delay ignition timing by a larger amount in order to eliminate knock-
ing. The values listed here are the default timing delays versus turbo
boost pressure.
Figure 5—
The heart of the CTT design is the signal chain between the crank trigger sensor input and the output to the ECU. Driving pin B3 on the microcontroller to a logic
level overrides the signal from the crank trigger sensor.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
23
6
°
, 12
°
, and 18
°
of delay. We used a
digital oscilloscope to verify that the
timing signal was being delayed. A
timing strobe light was used to ensure
that the engine was actually firing the
spark plugs late by the expected
amount. Both tests were positive,
proving that the device functioned as
intended. Figure 6 shows an oscillo-
scope screenshot as the CTT delays
the timing signal by 6
°
(one tooth).
At this point, the CTT had been
tested only with the car idling. When
the revolutions per minute were
increased by stepping on the throttle, the
CTT stopped working above 4100 rpm.
Inspecting the signal from the crank
trigger sensor showed that the first
tooth after the gap was being driven
to a low voltage (see Figure 7a). The
result was that after signal condi-
tioning, the first tooth was com-
pletely eliminated. We felt that this
problem had something to do with
the input impedance seen by the
timing signal. We measured the
impedance that the signal would see
if it were directly connected to the
ECU and recorded 7 k
Ω
. Because we
had only 10
Ω
of input impedance,
we increased this to 7 k
Ω
and the
nal out of the comparator is then ready
to be processed by the microcon-
troller. To pass the signal through unaf-
fected, the microcontroller sits dormant
with pin B3 in High Impedance mode.
Despite the series 10-k
Ω
resistor, the
signal from the comparator has
enough current to turn on or off the
output stage transistors. These transis-
tors excite the output transformer to
produce a differential signal with prop-
erties similar to the original signal
from the crank trigger sensor.
To modify the signal, the microcon-
troller outputs a one or a zero on pin
B3. Because this pin is tied directly to
the output transistors, rather than tied
through a resistor, the signal on pin B3
dominates the signal from the com-
parator. Thus, if pin B3 is driven to a
one or a zero, the signal will override
the original timing signal.
Each engine revolution, the turbo
boost pressure is determined by reading
the MPX4250AP using the PIC’s ADC.
The pressure is compared to a table in
the PIC. Depending on the pressure, up
to three teeth are added to the signal.
To add extra teeth, the PIC counts
teeth using Timer0 in Counter mode
after detecting the two-tooth gap. A
Timer0 interrupt occurs on the rising
edge of the fifty-eighth tooth. Timer2
interrupts are immediately enabled
with an interrupt period equal to one-
half the average length of a tooth. Each
time the Timer2 interrupt occurs, pin
B3 outputs a value to generate the
appropriate amount of extra teeth, fol-
lowed by a delayed two-tooth gap. The
values to be output on pin B3 are
stored in an array. Each time the
Timer2 interrupt occurs, the value in
the array at the indexed position is out-
put, and then the index is incremented
in preparation for the next interrupt.
If the PIC’s counter misses a tooth,
it loses track of its position and begins
to generate the two-tooth gap in incor-
rect locations. This is bad. So, it’s nec-
essary for the PIC to check its synchro-
nization with the gap in the original
signal each rotation of the crankshaft.
The resynchronization is done
using the PIC’s pin-change interrupt.
The PIC is set to interrupt on a
change in the signal from the crank
trigger sensor. The lengths of the high
time and low time of the signal are
recorded in this interrupt service rou-
tine by reading Timer1 and then
resetting it to zero. If the value of
Timer1 is more than twice the length
of the previous measurement, the last
bit is assumed to be the gap. When
the gap is detected, the tooth counter
(Timer0) is reset to 199 (256 – 58 + 1)
so that it triggers an interrupt after it
detects the fifty-eighth tooth.
Now we’ll switch gears and focus
on the results. Let’s start with the
hardware.
CTT PRODUCTION VERSION
After verifying our design with pro-
totyping boards, we manufactured the
final circuit board, found a nice plas-
tic case, and printed some
cool stickers. The production
CTT is shown in Photo 1.
The circuit board and cables
are shown in Photo 2.
After successful simulations,
the CTT was ready to be tested
in a Volkswagen (see Photo 3).
The response of the engine to
the modified timing signal
was unknown, so we proceed-
ed with caution and tested
the CTT with the car parked.
Switches were used to
change the modes from 0
°
,
Photo 1—
What do you think of the CTT production ver-
sion?
Photo 2—
Take a closer look at the CTT circuit board
and connectors.
Photo 3—
Here’s the Volkswagen that we tested at
Momentum Motor Parts in Port Coquitlam, BC.
1
2
Ch1
1 V
Ch2
2 V
2ms Ch1
> 1.84ms
CH
1 Freq
802.7 Hz
Low signal
amplitude
Tek Hold: 125KS/s
31 Acqs
Figure 6—
The upper trace is the input timing signal. The lower
trace is the modified output signal.
24
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
device worked properly
(see Figure 7b).
The CTT was properly
retarding the timing sig-
nal at all revolutions-per-
minute levels; however,
the car often stalled
while changing modes
(e.g., while making an up
transition from mode
0—a 0
°
delay—to mode
1—a 6
°
delay). Stalling
was not acceptable.
Our first guess was
that the engine
becomes confused when it detects
extraneous teeth. A cycle of 57 teeth
(instead of 58) occurred each time the
mode decremented. A cycle of 59 teeth
occurred each time the mode incre-
mented. This was exactly when the
car would stall.
58 TEETH REQUIRED
The extraneous teeth are removed
by inserting a tooth in the middle of
the cycle when the CTT makes a
down transition to a lower mode (e.g.,
mode 2 to 1) and deleting a tooth when
the CTT transitions up to a higher
mode. This ensures that the ECU
always sees 58 teeth per revolution.
Microcontroller code was written to
compress three teeth into four for
down transitions; it stretches five
teeth into four for up transitions (see
Figure 8). The code used is exactly the
same as the code used for inserting
the extra teeth to delay the two-tooth
gap: Timer2 generates an interrupt at
an accurate rate, only this time the
interrupt period is a quarter of the
tooth length. Timer2 has a prescaler
that allows making the interrupt peri-
od a power of two (2
±
n
) times the
tooth period easy—it just involves set-
ting the prescaler appropriately. Thus,
the division of each tooth into four
intervals made stretching and com-
pressing the teeth mathematically
convenient (see Figure 8).
The CTT with modified software
was tested on the same Volkswagen
with successful results. The car no
longer stalled during mode transi-
tions. The mode transitions proceeded
smoothly with only a slight change in
the tone of the engine.
INTERFERENCE
The next day, before taking the
Volkswagen on the road, we tested
the CTT to verify that nothing had
changed. Something had changed.
When the CTT attempted to delay
the timing signal, the engine would
bog, rev, burp, bump, make all sorts
of other sounds, and then stall. It
wasn’t working at all.
We inspected the circuit board for
shorts, missing traces, and broken com-
ponents. We reviewed the source code
in an effort to determine what could’ve
caused such a marked difference in
operation. We even loaded the micro-
controller with old code that was sort
of working, but it didn’t work either!
After six hours of confusion, a clue
to the problem came when we caught
a voltage spike on the timing signal
with the oscilloscope. We then
noticed that the timing signal cable
was lying next to a spark plug coil
pack. We moved the cable away from
the coil pack and the CTT began to
work. We then realized that we had
not attached the shielding on the tim-
ing signal cable to ground. After we
attached the shielding to ground and
placed the timing sig-
nal cable next to the
same coil pack, the
CTT continued work-
ing. With the CTT
functioning properly, it
was time for a road
test.
ROAD TEST!
An experienced tuner
and track racer from
Momentum agreed to
drive the car for a road
test. We left
Momentum’s shop in the early evening
and headed to a quiet road where we
could drive fast enough to ensure that
the TT was working. Although it was a
cool night, it was well above freezing, so
ice was not a concern.
We removed the Brand X system so
that the timing would be unmodified.
The CTT wasn’t installed yet. We
drove around conservatively to give
the engine time to warm up. When
the engine was warm, we did some
acceleration runs from a rolling start to
about 140 km/h. With 260 front-wheel
horsepower in a car that only weighs
2600 lb, this was more than frightening!
When the turbochargers began to
make meaningful boost at 60 km/h,
the tires began to spin and continued
to do so all the way to 80 km/h. We
were convinced that the operator was
well trained, but we still couldn’t
relax. We tried hard to make the
engine knock, but we were unsuccess-
ful. So, we took the operator’s word
for it: had it not been such a cool
night, or had the turbo boost pressure
been slightly higher, or had the fuel’s
octane level been slightly less, we
surely would have heard it.
Tek Run: 125MS/s Sample
200µs Ch1
> 2.25µs
5 V 200µs
A-1
A
B
A-3
20 V 200µs
Ch1
> 2.25µs
Tek Run: 125MS/s Sample
200µs
A
B
Figure 7a—
The CTT malfunctioned above 4100 rpm because the first tooth after the gap was
removed (bottom trace).
b—
Matching the input impedance of the CTT to the input impedance of the
ECU’s timing signal input made the CTT function properly again.
a)
b)
1
2
3
4
5
1
1
1
2
2
2
3
3
3
4
4
4
5
5
5
6
6
6
7
Down transition
Up transition
Figure 8—
The lower waveform in the top graph shows an extra tooth being added during a down transition. The
lower waveform in the bottom graph shows a tooth being removed during an up transition.
Pete Rizun designs and manufactures
electromechanical devices. He has a
B.A.Sc. in Engineering Physics from the
University of British Columbia and is
currently a graduate student in the
departments of Physics & Astronomy
and Clinical Neurosciences at the
University of Calgary. You may reach
him at pete@rizun.com.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
25
William Hue owns HUE-Mobile
Enterprises and specializes in embedded
systems, real-time control systems,
PROJECT FILES
To download the code, go to ftp.circuit
cellar.com/pub/Circuit_Cellar/2004/
167.
REFERENCES
[1] W.J. Bolander and R.S. Milunas,
“Knock Control Using Fuzzy
Logic,” Saturn Corp., Canadian
patent #2125934, 1994.
[2] J.L. Harned and T.C. Wolanzyk,
“Engine Spark Timing System
with Knock Retard and Wide Open
Throttle Advance,” General Motors,
Canadian patent #1089004,
September 1977.
[3] L.C. Lichty, Combustion Engine
Processes
, McGraw-Hill, NY, New
York, 1967.
industrial-grade systems, RF technology,
communications systems, mixed signal
designs, automotive technologies, and
data acquisition systems. He holds
B.A.Sc. (honors) and M.A.Sc. degrees in
Electrical and Electronics Engineering
from Simon Fraser University. Contact
him at william@hue-mobile.com.
RESOURCES
Microchip Technology, Inc., “PIC16-
F7X Data Sheet,” DS30325B, 2002.
CCS, Inc., “PCB, PCM, and PCW
PIC C Compiler Reference Manual,”
July 1999.
SOURCES
PIC C Compiler
CCS, Inc.
www.ccsinfo.com
PIC16F73 Microcontroller
Microchip Technology, Inc.
www.microchip.com
CTT Kit
Momentum Motor Parts
www.momentummotorparts.com
MPX4250AP Absolute pressure sensor
Motorola, Inc.
www.motorola.com
PCBs
Omni Graphics
(604) 276-9717
www.omnigraph.com
We hooked up the CTT with mode 1
(6
°
delay) activating at 4 psi and mode 2
(12
°
delay) activating at 8 psi. The car’s
maximum turbo boost pressure was 10
psi, so mode 3 would never be activated.
We repeated the acceleration run and
observed a more mild-mannered engine.
The wheels did not spin at 60 km/h as
they had done before. When 12
°
of lag
kicked in, we felt a slight lurch, suggest-
ing that mode 2 was activating at too low
a boost pressure. We then modified the
set points to 6 psi for mode 1 and 12 psi
for mode 2. We did the acceleration run
again and noticed an improvement in
smoothness and power compared with
the previous run. The transition from
0
°
delay to 6
°
delay was completely
smooth and without a distracting lurch.
We decided it would be best for the
operator to critique the performance of
the CTT. Before taking us for the ride,
he performed a similar acceleration test
with the Brand X timing system. He was
therefore in a position to comment on
the stock setup compared to the Brand X
system and our CTT. He felt that the
Volkswagen was faster with the CTT.
Furthermore, he said it would eliminate
knock unlike the stock chip and that it
was completely tunable for different
engines, gas octane levels, turbo boost
pressure, and weather conditions.
The CTT’s tunability allowed the
performance car tuner to slightly
delay timing to stop engine knocking
and still run with the timing advanced
enough to generate serious horsepow-
er. As for performance car enthusiasts,
the CTT allows you to bring the
engine electronics back in “spec” with
modified engines producing horsepow-
er far beyond what the original engine
electronics are designed for.
I
The antenna connection to most
radio frequency transceivers has an
input impedance of 50
Ω
. In order to
ensure impedance matching and maxi-
mum power transfer to the antenna,
the characteristic impedance of the
circuit board signal traces must be
matched to the transceiver and the
antenna. This effort is relatively easy
because the characteristic impedance
of circuit traces is defined by the
geometry of the conductor. By choos-
ing the appropriate trace width and
separation from the ground plane, you
can design the characteristic imped-
ance to match the transceiver.
However, the input impedance to a
quarter-wave dipole over ground is not
50
Ω
. Therefore, additional circuitry
needs to be added for impedance match-
ing. To determine the necessary circuit-
ry, the antenna structure is analyzed
for impedance at 916 MHz. To charac-
terize this input impedance, we chose
the EZNEC design program. EZNEC is
intended for designing and characteriz-
ing antennas based on lengths, possible
multiple lengths, and any pos-
sible grounds. This is the
ideal software for characteriz-
ing our antenna.
Using the EZNEC design
tool, we determined that the
input impedance of our
antenna is 41.64 + j24.35
Ω
.
It is necessary to match this
impedance to our 50-
Ω
sys-
tem. This can be accom-
plished in a variety of ways.
One common method is the
use of an open or short-circuit
stub-tuning strip implemented
28
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
W
ireless products are following
the same general trend of all electron-
ic products: they’re becoming smaller
and less expensive while becoming
more complex and capable. Advances
in off-the-shelf transceiver compo-
nents make today’s communication
circuits radically different from those
of the past. Miniaturized integrated
circuits now replace the bulky discrete
components. This greatly simplifies
the designer’s task and eases the
tedious chore of test-selecting resis-
tors for a given assembly.
The performance of an antenna in a
wireless system is often one of the
dominant factors in the overall per-
formance of a wireless link. Because
cost and simplicity tend to be deciding
factors in antenna design for these
simple wireless systems, the use of
under-performing antennas is often an
unfortunate trade-off for a simpler
design. In an effort to design an inex-
pensive yet efficient antenna, we
developed and characterized an anten-
na constructed with a steel guitar
wire. The antenna has proven
to be as effective as commer-
cial whip antennas that cost
considerably more.
ANTENNA DESIGN
One of the highest perform-
ing and simplest antenna con-
figurations to characterize is a
quarter-wave monopole over
ground. This antenna operates
almost exactly as a half-wave
dipole would without a
ground plane. An electromag-
netic radiation field that is
Having trouble selecting an antenna for your new wireless system? Check out how this
North Dakota State University design team used a guitar string antenna in a wireless sen-
sor project. It’s a great alternative to the expensive whip and surface-mount antennas that
you’re used to.
highly omnidirectional summarizes
these characteristics (see Figure 1).
A straight segment of guitar string is
used to create this monopole. The seg-
ment’s length is determined by the oper-
ating frequency, or wavelength, of the
wireless system. For a radio wave propa-
gating in free space, the wavelength is:
where
λ
is the wavelength, f is the fre-
quency of the signal, and c is the
speed of light.
The associated wavelength is 32.7 cm
for our 916-MHz design; therefore, our
quarter-wave section is approximately
8.2 cm. The antenna design calls for
this segment of guitar string to be sit-
uated over a ground plane. For the tar-
geted wireless systems, the guitar
string is soldered to a PCB. Therefore,
we can simply design a ground plane
in the PCB, something that is often
available already in the circuit board
for signal integrity and EMI considera-
tions.
λ
=
c
f
FEATURE ARTICLE by B. Thurow, J. Jorgenson, D. Kakumanu, B. Morlock, & M. Schmitz
z
y
x
Ground plane
Elevation
z
y
Monopole
Azimuth
y
x
Figure 1—
Take a look at the characteristics of a monopole antenna and the
radiation patterns. The polarization is linear (vertical as shown). Note the typical
half-power beam width (45° × 360°). The bandwidth is narrow, and there is no
frequency limit.
Monopole Antenna Design
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
29
standing wave ratio (SWR) of
the antenna circuit. The
information shows exactly
where the antenna is radiat-
ing as well as the bandwidth
of the antenna. The antenna
we tested is an extremely
good radiator at 916 MHz
and has a sharp bandwidth
about that frequency.
The network analyzer is
also helpful for finding the
actual input impedance at
the operating frequency.
This information validates
the simulation of the input
impedance to the antenna
as well as the matching L-C
circuit to the 50-
Ω
system.
This design can be easily
adapted to other applica-
tions where a narrow band-
width, omnidirectional antenna is
needed. Because of the increase in size
that results from the lowering of the
frequency, this antenna is better suit-
ed for operation in the UHF range.
Adapting the design is not complicat-
ed. You can cut the steel guitar string to
the length of one-quarter the wave-
length of the operating frequency and
attach it to a PCB with a ground plane.
Using the aforementioned free tools, a
matching circuit can be designed, which
will always consist of a shunt and series
component. Matching is often done to
50
Ω
, but a circuit can be matched to
any input impedance that is required
by the test equipment or transceiver.
ANTENNA APPLICABILITY
The guitar string antenna has been
implemented in a variety of wireless
as a microstrip line on a
PCB. The main benefit in
this design decision is the
cost. No additional compo-
nents are necessary. This
does, however, require addi-
tional board space, so you
must be careful with dimen-
sions of the stub itself.
Possibly the easiest and
most failsafe matching net-
work is the lumped model
L-C combination network.
This network consists of
two reactive components: a
shunt element and a series
element. For calculations,
the characteristic impedance
of our transmission line is
defined as Z
O
. The input
impedance to our load
(antenna) is R
L
+ jX
L
.
Because R
L
is larger than Z
O
for our
system, use the following set of equa-
tions to find the appropriate values:
These equations, as well as other
impedance-matching tools, are avail-
able for free on the ’Net
(venus.ece.ndsu.nodak.edu/~ronel-
son/). Using this tool, the matching
circuit required is a capacitive series
element of 4 pF and an inductive
shunt element of 19.39 nH. With the
antenna design complete for operation
at 916 MHz and a matching network
incorporated for connection to a 50-
Ω
system, the functionality of this
antenna is characterized (see Photo 1).
PROTOTYPE BOARD
We designed a PCB for the testing
and characterization of the antenna. It
consists of a connection for the guitar
string antenna, an L-C matching cir-
cuit implemented in surface mount
components, and a 50-
Ω
SMA connec-
tor that allows for a connection to test
equipment (see Photo 2).
The antenna with matching L-C cir-
cuit is linked to the SMA connector by
a matched 50-
Ω
microstrip trace imple-
mented as a coplanar wave-guide. This
trace can be implemented as a standard
Series
R Z
Shunt
Z
Z
R
L
O
O
O
L
=
R
X
=
R
L
L
L
±
−
(
)
−
±
−
1
microstrip or strip-line trace, provided
that it is designed with proper dimen-
sions for matching to 50
Ω
. We select-
ed a microstrip construction because
the board design requires only an inex-
pensive two-layer board.
There is a lot of documentation on
the impedance matching of strip-line
and microstrip PCB traces as well as
free tools for design. One such tool is
Agilent’s AppCAD. The impedance can
be realized as a coplanar wave-guide
over a ground plane with a 41-mil trace
spaced 8 mil from the ground plane, or
a coplanar wave-guide (not over a
ground plane) with a 32-mil trace and
8-mil spacing. A minimum of 8-mil
copper spacing was chosen to meet
manufacturing requirements. Photo 3
shows the analysis of the high-speed
performance of the circuit trace as
characterized by AppCAD.
The antenna was specifically built
for wireless systems operating in the
900-MHz ISM region. We used the RF
Monolithics DR3000 transceiver, oper-
ating at 916 MHz with an on-off key-
ing modulation scheme. This trans-
ceiver was chosen because of its low-
power requirements (4 mA at 3 V),
low cost, ease of use, and availability.
PROTOTYPE TESTING
A network analyzer was attached to
the SMA connector on the test board.
This was used first to determine the
Photo 1—
We analyzed the matching network needed for the guitar string antenna,
characterized by a 50-
Ω
source and transmission line.
Photo 2—
The prototype antenna board was designed
to determine the characteristics of the guitar string as
an antenna.
30
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
sensors designed at North Dakota
State University. In redesigns of
existing circuits, the guitar string
replaced whip antennas (and SMA
connectors) and patch antennas at a
cost reduction ranging from $10 to
pennies. No performance issues were
noted, and the resulting circuit card
area was reduced.
The guitar string antenna also has
been designed in circuits with multi-
ple communication schemes. It’s used
for 915-MHz ASK communication in
the wireless temperature sensor
shown in Figure 2. The antenna pro-
vides nearly ideal omnidirectional per-
formance without interfering with the
other circuits. The footprint on the PCB
is minimal (only a plated through-hole
with a 20-mil finished inside diameter).
The only thing we need
is mechanical strain relief.
The physical properties of
the antenna allow for
mechanical movement
and displacement, but
with applied stress at the
solder joint. To eliminate
the possibility of cracking
the solder joint, you can
add a mechanical means
of support, or the antenna
can be flattened to the cir-
cuit card and glued to
eliminate the strain on
the joint.
EASY INTEGRATION
Our inexpensive antenna works
well: its performance is as predicted
for a monopole device, and it is easily
adapted from higher frequency opera-
tion (900 MHz) to lower frequencies.
Analytical measurements confirmed
the operation, and the antenna has
been successfully integrated into wire-
less communication designs.
Although the antenna by itself is
not matched to standard 50-
Ω
charac-
teristic impedance, adding a few com-
ponents in series and in shunt assist
in the matching. Tuning the antenna
is straightforward. To do so, simply
cut it to length.
Finally, keep in mind that the
antenna is mechanically robust. You
Photo 3—
We used AppCAD to determine the impedance matching for a
coplanar wave-guide.
Figure 2—
Our wireless temperature sensor uses a guitar string antenna for communication.
SOURCES
EZNEC Antenna software
www.eznec.com
DR3000 transceiver
RF Monolithics, Inc.
(972) 233-2903
www.rfm.com
MSP430x12xx Microcontroller
Texas Instruments, Inc.
(972) 644-5580
www.ti.com
PROJECT FILES
To download the code and more pho-
tos, go to ftp.circuitcellar.com/pub/
Circuit_Cellar/2004/167.
Mike Schmitz is a graduate student at
North Dakota State University. You
may contact him at michael.schmitz
@ndsu.nodak.edu.
Brian Morlock is a Ph.D. student at
North Dakota State University. You
may contact him at brian.morlock
@ndsu.nodak.edu.
Divyata Kakumanu is a Ph.D. student
at North Dakota State University.
You may reach her at divyata.kaku-
manu@ ndsu.nodak.edu.
Joel Jorgenson is an associate professor
in North Dakota State University’s
Department of Electrical and Computer
Engineering. You may contact Joel at
joel.jorgenson@ndsu.nodak.edu.
Brad Thurow, B.S.E.E., is a graduate
research associate with North Dakota
State University’s Center for Nanoscale
Science and Engineering. You may
contact Brad at ndsu@thurow.net.
Authors’ Note: We’d like to thank all
those in the North Dakota State
University Department of Electrical
and Computer Engineering who sup-
ported us, most notably Dr. Robert
Nelson and Oscar Blaskowski, whose
guidance, assistance, and review
helped guide this project. A final note
of appreciation must be given to Ron
Gilbert, who inspired this project.
can bend, twist, and compress it with
no long-term physical degradation.
I
When designing high-speed applications,
working with surface-mount technology
components and soldering by hand can be
tedious. The H8/3687 microcontroller-
based SMT Reflow Oven Controller trans-
forms a conventional infrared toaster oven
into an effective reflow oven that ensures
thermal control. The EVB87 evaluation
board provides an on-chip analog-to-digital
converter, LCD, push buttons, and an
ample supply of RAM and program memo-
ry. The simple, streamlined design
required adding just two small circuits, a
thermocoupler interface, and a driver for
an external relay to turn on and off the
reflow oven. And the best part is that the SMT Reflow Oven
Controller cost hundreds of dollars less to build than traditional
reflow ovens.
Grand Prize
First Prize
Telephone Message Watchdog
The low-cost Telephone Message Watchdog is a mes-
sage-forwarding system for home telephones. Based on
the H8S/2398 microcontroller, the software-only design
uses a touch-tone detector and DTMF generator. The
Robert Lacoste
France
rlacoste@alciom.com
www.circuitcellar.com/renesas.
touch-tone detection system is triggered when the
home answering machine picks up a phone call. A
recorded message prompts callers either to leave a
voice message or punch in a callback number, which
is stored in on-chip memory. After the caller hangs
up, the system uses the touch-tone generator to for-
ward messages to a preset pager number. If the
caller left a phone number, the system will send it to
the pager. If not, the system will send the owner’s
home number as an indication to call home to listen
to the message.
Jingxi Zhang, Yang Zhang, and Huifang Ni
U.S.
zhang@jvclab.com
SMT Reflow Oven Controller
Second Prize
Programmable Yoga Timer
www.circuitcellar.com/renesas.
With the proliferation of home video and audio devices, the IRMA Video Hub
offers a welcome management strategy. Housed in a 19
″
rack-mounted chas-
sis, the H8/3687 microcontroller-based hub provides an efficient and central-
ized system for the variety of electronic devices within a home. The IRMA
routes video signals and infrared commands and con-
nects modulated video signals to four sets of two-to-one
video selectors. Using IR repeaters, the system sends
and receives IR commands to control audio and visual
equipment. With RS-232 and RS-485 communications
interfaces and the capability to download updated code,
the system is designed to accommodate future electron-
ics upgrades without hardware modifications.
Kenneth Lumia
U.S.
klumia@adelphia.net
Third Prize
IRMA Video Hub
The Programmable Yoga Timer allows users to pre-
program time intervals for a conventional timer so
that the timer does not have to be reset multiple
times. A simple user interface enables users to easily
manage time-sensitive activities without having to
constantly reset the timer. The system takes advan-
tage of the H8/38024F demo board’s on-board micro-
controller, four-digit LCD, and RS-232 serial interface
for flash memory downloading. The H8/38020 micro-
controller-based prototype incorporates a voltage ref-
erence, a piezo speaker, and several switches. Nine
preprogrammed sequences with as many as 20 time
steps of up to 99 min. and 59 s each can be stored.
Richard Wotiz
U.S.
dick601@mystics.org
Complete entries available at
www.circuitcellar.com/renesas.
CPU-Controlled Inverting Switcher for LCD Backplane
Based on the HD64F2398F20 microcontroller from the 2398 H8S starter
kit, this system provides a low-cost way to generate a negative LCD power
supply. The system is especially useful for applications that involve LCDs
because it can delay the application of the LCD backplane voltage after
power-up. The microcontroller’s high-speed on-board ADC coupled with a
simple control loop enable the system to use minimal CPU resources, free-
ing the CPU for other tasks. Additionally, the power supply is regulated,
temperature-compensated, and can be adjusted via software.
Romano Bernarducci
Italy
r_bernarducci@yahoo.com
Stepper-Controlled Coil-Winding Machine
Designed around the RSK2329 evaluation board, the Stepper-Controlled
Coil-Winding Machine controls a stepper motor-based coil winder. The
coil winder hardware is constructed out of 0.75
″
medium density fiber-
board (MDF) and commonly available 28TPI threaded rod. Using 7.2°-
per-step unipolar stepper motors, the system can achieve a stepping pre-
cision of 0.0007
″
per step with impressively low backlash. The system
can accommodate coils up to 12
″
, making it a versatile solution for
numerous applications. It works especially well for small quantity produc-
tion of flyback transformers and special RF chokes, among other prod-
ucts.
Jay Shroff
U.S.
jshroff@hotmail.com
Handheld Power Meter
The optical Handheld Power Meter was built for use in fiber optics labs.
The unit is designed around the H8/38024 microcontroller, which enables
the implementation of battery-powered devices with the addition of a bat-
tery-based power supply. The microcontroller’s on-board LCD drivers are
used for the four-digit, seven-segment LCD. And the on-board SCI is used
for RS-232 communication with a PC. The power meter calibration is han-
dled by a Windows-based application.
Seenath Punnakkal and Sameer Cholayil
U.S.
seenat@hotmail.com
Rotating Propeller-Type LED Display
For this project, LEDs were mounted on a propeller in order to create a
rotating display. By using red, green, and blue LEDs, the system offers
numerous possible color combinations for a versatile display. The text or
designs are sent to the system for display via a wireless battery-operated
terminal. The heart of the project is a H8S/2633 microcontroller, which pro-
vides enough processing power RAM, flash memory, and peripherals to
operate in single-chip mode without many external components. Video files
available on the contest web site show the rotating display in action.
Johann Gysin
Switzerland
john@jogy.ch
HEATimer: Vehicle Heater Timer/Controller
The forward-thinking HEATimer is designed to remotely control auxiliary
after-market heaters installed in cars. Users can program 10 or more dif-
ferent reprogrammable options to individualize heating patterns for both
the engine and the interior of a car. Patterns can range from 1 to 120
min. This is a marked improvement over typical OEM timers that allow
only one to three one-time-programmable options. The HEATimer also
eliminates the need for a separate switch to initiate summer mode, dur-
ing which time the timer activates the fan for ventilation, thus reducing
the load on the A/C system.
Marek Niedostatkiewicz
Poland
niedost@eti.pg.gda.pl
3-Axis DRO for Small Lathe and Milling Machines
This low-cost digital readout project enables lathe and milling machinists
to change the position of a machine tools table without having to remem-
ber the previous position of the dial or the number of turns. Inexpensive
sliding scales are used to read the XYZ position of the table. Data is
much easier to read than on conventional DROs, with typically small
LCDs, because it is presented on a seven-segment LED display.
Accuracy is rated at 0.001
″
. For increased functionality, the HD64F3664-
based DRO can display in both the metric and inch-pound systems.
Virachat Boondharigaputra
Thailand
vcb73@yahoo.com
Emergency Power Pack
The battery-backed Emergency Power Pack produces enough power to
run some household items during a power failure, including a few lamps
and a television. An inverter originally designed to plug into car batteries
plus a pair of 12-V, 17-Ah seal lead-acid batteries comprise the
Emergency Power Pack. The compact 200- to 400-W inverter produces
120 VAC, which is suitable for powering home electronics. The Tiny 3687
microcontroller-based system controls battery charge and monitors vari-
ous battery functions. It also enables users to recharge the battery with a
car battery, which can be particularly useful during prolonged power out-
ages.
Brian Millier
Canada
brian.millier@dal.ca
ECG Monitor
Electrocardiogram (ECG, or sometimes referred to as EKG) machines
are used to monitor heart activity in order to detect malfunctions. The
advanced Tiny 3687-based ECG Monitor records four different ECG sig-
nals and the heart rate and displays the data on a 128 × 128 graphical
LCD. The monitor enables users to study ECG waveforms in minute
detail. The recorded pattern can be uploaded to a PC via a serial port.
Users can modify the software to perform further analysis for specific
heart conditions such as arrhythmia. This kind of versatility makes the
ECG Monitor indispensable.
M. Ganesh Raaja
India
graaja@eth.net
Honorable Mention
device when power-save modes are
applied. Also note that the reset input
must be open-collector/drain.
The power-up sequencing is simple
if the inputs V
DD
, V
DD_IO
, and ON are
tied together, typically to 3.3 V.
Otherwise, special precautions must be
taken for power-up and power-down.
The ROK104001 doesn’t contain an
internal antenna. As you can see in
Figure 1, an SMA connector is drawn
for flexibility in selecting a suitable
antenna. A surface-mount antenna also
can be used (e.g., gigaAnt’s
Mica 2.4-GHz patch antenna).
Now let’s take a look at the
schematic for the cB-OEMSPA
(see Figure 2). There are some
similarities and some differ-
ences. The asynchronous serial
interface includes the TxD,
RxD, RTS, and CTS signals also
found in the ROK104001. There
are two additional signals: data
set ready (DSR), which is used
to control power saving func-
tions, and data terminal ready
(DTR), which allows the host to
detect if the module is up, run-
ning, and ready to receive data.
The cB-OEMSPA module is
different from the ROK104001
in another way. It’s possible
to select interface voltage lev-
els, either RS-232 levels or
ordinary logic levels. The
interface is selected with a
pull-down resistance on the
RED/MODE signal. The state
is sampled directly after
power-up. If no pull-down
36
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
L
ast month I introduced you to two
new products that make it easy to
integrate Bluetooth communication in
a design: Infineon’s ROK104001 and
connectBlue’s cB-OEMSPA family.
Both have a common background and
are built with the same hardware and
firmware. In addition, they have the
same embedded communication inter-
face (ECI) despite their different physi-
cal features and mounting.
Now that you are familiar with the
protocol’s principle design, I’ll focus
more closely on ECI. I will
also go into more detail
about the physical interfaces
to the ROK104001 and cB-
OEMSPA modules.
PHYSICAL INTERFACES
The modules have an ordi-
nary asynchronous serial
interface (8N1, with a variety
of standard bit rates).
Obviously, RxD and TxD are
used to transfer data to and
from the modules. Even
though the internal UART has
a 128-byte FIFO, buffer over-
run can occur at high bit
rates. Therefore, RTS and CTS
are used to regulate the data
flow (i.e., prevent temporary
UART buffer overrun). Using
RTS/CTS is not mandatory,
but it’s highly recommended.
The RTS/CTS flow control
can be switched off via a con-
figuration setting; but again,
use RTS/CTS so you don’t
lose data and synchronization
Simple Bluetooth Integration (Part 2)
Last month Anders explained how the ROK104001 and cB-OEMSPA13i make Bluetooth
integration a cinch. Now he covers the interfaces and ECI protocol. Bluetooth integration
is in your future.
with the module. Only a hardware
reset can regain synchronization.
Keep in mind that the serial inter-
face should be connected in a null-
modem fashion. The local TxD should
be connected to the remote RxD, and
the local RTS should be connected to
the remote CTS and vice versa.
Figure 1 is a diagram of the
ROK104001. The serial interface levels
are not true RS-232 but logic level (i.e.,
0 V and V
CC-IO
typically 3.3 V). Observe
the Schottky diode used to wake up the
FEATURE ARTICLE
by Anders Rosvall
Figure 1—
Take a look at the simple interface to the ROK104001. The serial
channel is in the upper left corner. B2 through B7 are six general-purpose
inputs/outputs.
Interfaces and ECI Protocol
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
37
and do not need buffers. There are also
buffers on the module’s output sig-
nals. These may be necessary; it
depends on the logic level require-
ments on the microcontroller’s inputs.
Both modules can drive LEDs to
indicate status. ROK104001 has six
general-purpose I/Os, any three of
which can be used for driving the RGB
LED. The other I/Os can be used as
outputs and inputs in any combina-
tion. cB-OEMSPA has three dedicated
I/Os for the RGB LED. Table 1 lists
the status signaling.
There are small differences between
the modules. cB-OEMSPAs sometimes
distinguish between Data and
Command modes, and this can be
signaled by the RGB LED. The Idle
state has two substates: Idle Data
mode (green) and Idle Command
mode (orange).
If the current through
the LEDs is moderate
(less than 2 to 4 mA),
the modules can drive
them directly.
However, if the cB-
OEMSPA is used in
UART mode, a high-
impedance buffer is
required to prevent the
RED/MODE signal
from being pulled up
via the LED. Figure 4
illustrates the RGB
LED connected through
buffers. Observe that
the supplying voltage
is 5 V. A blue LED
requires a forward volt-
age drop of about 3.5 V
(up to 4.5 V in the
worst case). Hence, in a
3- to 3.3-V system, V
CC
cannot be used to drive
a blue LED. Note that
there are single-gate
resistance exists, RS-232 will be used,
and a pull-down will activate the
logic-level interface. Both interfaces
cannot be active simultaneously. Note
that CTS requires a pull-up resistor,
typically 82 k
Ω
, if logic levels are used
and flow control isn’t.
The module has an internally regulat-
ed V
CC
, which is 2.9 V,
and a guaranteed mini-
mum V
OH
of 2.8 V at
4 mA. This is also the
logic level for the serial
UART interface. The
input voltage for feeding
power is more flexible
than the ROK104001’s.
cB-OEMSPA accepts
3 to 6 V (3.3 to 6 V for
100-m modules).
Another feature is the
restore-to-factory-set-
tings switch, which is
sampled directly after
power-up. Many config-
uration settings can be
stored in a start-up data-
base (e.g., bit rate, use
of RTS/CTS, and many
other Bluetooth related
functions). Pressing the
switch during power-up
restores all settings to
default values.
MICRO INTERFACES
Now that I’ve covered the modules’
interfaces, it’s time to connect them
to a microcontroller. How this is done
depends on the voltage levels the
microcontroller’s I/O operate on.
A 3- to 3.3-V system can be con-
nected directly to the logic level pins
of both modules. However, I recom-
mended using a series resistor (100
Ω
)
for protection and to minimize cur-
rent to 1 to 2 mA if the logic levels do
not match exactly (between the mod-
ule’s internal V
CC
and the microcon-
troller’s V
CC
). Figure 3 illustrates the
simple connection.
A 5-V system must adjust logic lev-
els. This is easy with resistive dividers
and buffers. Resistive dividers with 18
to 22 k
Ω
are recommended for 5-V sys-
tems and speeds up to 115.2 kbps. For
higher speeds, a divider of 1.8 to 2.2 k
Ω
and a buffer are recommended, because
stray capacitances create a low-pass filter
that becomes noticeable if 18 to 22 k
Ω
is used. The schematic in Figure 3
illustrates the simple connections. An
extra buffer is placed on the RxD
input because it’s a high-speed signal
and needs to drive the 1.8- to 2.2-k
Ω
divider. The other control signals have
much lower frequency components
Figure 2—
After you study the cB-OEMSPA, go back
and compare it to the ROK104001. Note the similarities
and differences.
Figure 3a—
Here is the interface if the CPU external interface operates on 5 V. Observe that U1 is
powered from the host side (i.e., the CPU I/O voltage).
3b—
The interface if the CPU external inter-
face operates on 3.3 V.
Status
RGB LED
Idle
Green
Connecting
Purple
Connecting and transferring data Flashing purple
Connected
Blue
Connected and transferring data Flashing blue
Table 1—
As you know, both modules can drive LEDs to
indicate status. This table lists the status signaling.
a)
Host
ECI Controller
b)
Host
ECI Controller
38
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
packages (if not exactly four or eight
gates are required in the design).
ECI PROTOCOL
Now let’s study the ECI protocol. As
I mentioned last month, ECI is a pack-
et-based protocol with eight different
packets types.
You will start by setting up a mod-
ule as a server (i.e., accepting incom-
ing serial profile connection requests).
Unfortunately, you will not get by
without reading the ECI specification.
This description will get you up and
running quickly; but, for more
advanced functions and features, you
must consult the protocol specifica-
tion. I guess that this is how most
projects work anyway. You start with
something simple, try to get it to
work, and then gradually add more
advanced functions to the project.
When a module operates as a server,
allowing other devices to connect to
the module, a server service must be
enabled. After such a service is
enabled, the module registers a so-
called service record, which allows
other devices to discover this specific
service. Remember that Bluetooth
allows devices to discover which serv-
ices are in near proximity and then
use them accordingly.
When acting as a server, the role (or
service) DevB must be enabled. This
is accomplished by sending an
Enable_DevB_SP_Profile_Using_Serial
request packet to the module. If the
role has been successfully enabled, a
confirm packet is returned. This packet
includes a service handle, which is
returned in the confirm packet. It has
two purposes: when disabling a service,
the service handle identifies the service
to disable; and when a remote device
connects to a specific service, the serv-
ice handle identifies which service the
remote device is connected to.
When enabling a service in a module
with the Enable_DevB_SP_Profile_
Using_Serial request packet, one of the
parameters is called “Auto Accept.” If
set to true, the module automatically
accepts incoming connection requests to
the service. If set to false, the module
asks the ECI host to accept or reject the
connection. This is done using a
Serial_Accept_Connection indication
packet. A Serial_Accept_Connection
response packet must be sent as a
response.
Finally, when a connection is estab-
lished (automatically or via ECI host
interaction), a Serial_Connection_
Established event packet will be sent
to the ECI host. This packet contains
a number of parameters: service handle,
which identifies the connected service;
connection handle, which is used when
sending and receiving data over the
established connection, when closing a
connection, and when the remote side
closes the connection; and remote
address, which identifies the device
connected to the service (the 48-bit
Bluetooth address).
Up to two DevB serial port profiles
services can be enabled at the same
time, allowing two different devices to
connect simultaneously to a module.
This limit is purely an implementa-
tion limit. Future modules may have
other limits. Figure 5 illustrates the
packet flow.
Before an established connection
can be used to transfer data, it has to
be prepared. As you’ll recall from last
month’s article, each connection has
its own flow control that regulates the
serial data packet flow between the
ECI controller and the ECI host. This
flow control is symmetric (i.e., the flow
is controlled in each direction). The
preparation is needed in order to set up
this flow control for the new connec-
tion. Sending a Prepare_Serial_Data_
Connection request packet does it.
The packet contains the following
parameters: the connection handle,
which identifies the connection to
prepare for data traffic; the available
number of buffers, which is the num-
ber of buffers reserved for this connec-
tion in the ECI host (i.e., in your appli-
cation program); the buffer size, which
is the maximum size, in bytes, of each
buffer that has been reserved in the
ECI host (no data packets sent from
the ECI controller to the ECI host may
be larger in size); the suggested number
of buffers, which is a suggestion for the
modules of how many buffers to
ECI Host
(your application)
ECI Controller
(Bluetooth module)
Request: Enable_DevB_SP_Profile_Using_Serial
Confirm: Enable_DevB_SP_Profile_Using_Serial
Indication: Serial_Accept_Connection
Response: Serial_Accept_Connection
Event: Serial_Connection_Established
Request: Prepare_Serial_Data_Connection
Confirm: Prepare_Serial_Data_Connection
Data transfer
Event: Serial_Connection_Closed
Request: Close_Serial_Connection
Confirm: Close_Serial_Connection
A connection
request occurs
If “Auto Accept”
is false
Client side
close
Server side
close
Accept
or reject
connection
Figure 5—
Take a look at the message sequence diagram when the host operates as a server, and waits for con-
nections from other clients.
Figure 4—
The RGB LED is connected through buffers.
Keep in mind that the supplying voltage is 5 V.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
39
reserve for this specific connection;
and the suggested buffer size, which is
a suggestion for the buffer size, in
bytes, being reserved in the ECI con-
troller (no data packets sent from the
ECI host to the ECI controller may be
larger in size).
The module sends a confirm packet
in response. The actual reserved
number of buffers and their size is
conformed in this packet. Note that
the module can accept the suggested
values or change them (to lower val-
ues, not higher).
Data transfer can begin after the con-
nection is established and prepared.
Both sides must follow the rules of flow
control: it is only allowed to send a data
packet if the recipient has a free buffer.
Both sides must keep count of the free
buffers on the other side.
The ECI host uses the Consumed_
Serial_Data_Packets command packet
to inform the ECI controller that it
has consumed a number of received
data packets. The ECI controller uses
the Consumed_Serial_Data_Packets
event packet to inform the ECI host
that it has consumed a number of
received data packets. Both packets
contain a connection handle to identi-
fy a specific connection because many
can be active simultaneously.
When it is time to close a connec-
tion, either the server or the client can
initiate the operation. Figure 5 illus-
trates both situations. If the server
decides to close the connection, a
Close_Serial_Connection request
packet is sent (containing the connec-
tion handle to identify the connection
to close). If the client (the remote
device) decides to close the connection,
the ECI host receives a Serial_
Connection_Closed event packet
informing of the event.
Note that when the ECI host
enables a service, it implicitly regis-
ters to receive the packet’s Serial_
Connection_Established event, Serial_
Accept_Connection indication (only if
Auto Accept is set to false), Serial_
Connection_Closed event, Consumed_
Serial_Data_Packets event, and Serial
data for the connection.
A client connects to a server (i.e.,
initiates a connection). Now I’ll
explain how a serial connection is cre-
ated as opposed to how an incoming
connection request is accepted. Using
Bluetooth serial port profile terminol-
ogy, this is the DevA role.
Serial connections are created with
the Connect_To_Serial_Service request
packet. The confirm packet to this
request contains a connection handle,
which uniquely identified the connec-
tion (when sending and receiving data,
closing a connection, and when the
remote side closes the connection).
Remember that a device connects to
a specific service in the remote device.
Sometimes the ECI host doesn’t care
about which instance of a service to
connect to (if there are several in the
remote device). In this case, it is possi-
ble to allow the ECI controller to auto-
matically select an instance (a parame-
ter in the Connect_To_Serial_Service
request packet). However, if it is of
importance, the client must first per-
form a service search on the remote
device. This is accomplished by send-
ing a Service_Search request packet to
40
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
can be performed with the ECI proto-
col also can be performed in AT mode.
Connections are set up in AT mode as
well as service searches. After a con-
nection is established, the mode
switches to the transparent Data
mode. Buffer handling is no longer an
issue because the data flow control is
handled by using the RTS/CTS control
signals. This may be the protocol’s
biggest advantage. A drawback is the
inability to handle several concurrent
data channels, because there is no way
to distinguish data on one channel from
another channel. However, this is not a
problem in many applications because
only one channel is active at a time.
An AT command can be one of the
following: read commands without
parameters (AT<command>?<CR>),
read and write commands with param-
eters (AT<command>=<parameter1>,
<parameter2>, ... <parameterN><CR>),
or write commands without parame-
ters (AT<command><CR>).
Various responses, such as a suc-
cessful final message
(<CR><LF>OK<CR><LF>), can be sent
back. A successful intermediate/final
message can be sent with parameters
that follow an OK message in some
commands. The OK message works
only as a confirm message in this case
(<CR><LF><result_response>:<parame-
ter1>, parameter2>, …<parameterN>).
the ECI controller. As a result of a
service search, a confirmation packet
is returned containing the number of
services found in the remote device.
Following that, a number of result
packets (the same number as the num-
ber of services found) are also returned.
Given this information, the ECI host
(i.e., your application) can select which
service instance to connect to and then
pass this information as a parameter in
the Connect_To_Serial_Service
request packet. Figure 6 illustrates the
packet sequence.
AT COMMAND PROTOCOL
Do you think that the ECI protocol
is complex and cumbersome? If so,
you’re in luck. There is a simpler pro-
tocol for the cB-OEMSPA modules:
the AT command protocol.
When using this protocol, the mod-
ule operates in one of two different
modes: AT mode (accepting commands)
and Data mode (transferring data).
Figure 7 illustrates the different opera-
tion modes and the transitions between
them. The module always starts in
Data mode. Moving to AT mode is
achieved with the AT*ADDM com-
mand. Going back to transparent Data
mode is achieved with a configurable
escape sequence (by default three con-
secutive forward slash characters).
Basically, all of the operations that
The last possible response is an error
message (<CR><LF>ERROR<CR><LF>).
PROJECT TIME
Now that you have the schematics
for connecting almost any microcon-
troller with an asynchronous serial
port to the ROK104001 and cB-
OEMSPA Bluetooth modules, it’s time
to tie all the parts together. I used the
LPC2106 ARM7 and ATmega128 AVR
microcontrollers. Both are excellent
choices capable of running large appli-
cations. They have on-chip, 128-KB
program flash memory.
The ROK104001 and cB-OEMSPA
are excellent products. Figure 8 illus-
trates one system that I recently
worked with: the LPC2106 and cB-
OEMSPA. It’s a simple setup suitable
for initial experimentation.
The system comes complete with
bootloader functionality. (Use the ISP
program from Philips to download pro-
gram code into the microcontroller.) In
addition, no extra hardware other than a
serial cable is needed to download code.
The code posted on the Circuit
Cellar
ftp site will help you get up and
running in no time. It demonstrates a
server application in which the device
waits for clients to connect. You can
easily modify it for a client-side applica-
tion. The AT protocol is used for sim-
plicity, but nothing is stopping you from
experimenting with the ECI protocol.
I’ve included all the parts you need
to start working with easy-to-use
Bluetooth modules. The application is
up to you. Last month I suggested a
mailbox checker, but there are many
other possibilities. Home automation
applications are well suited for wire-
less communication so that you don’t
have to put wires in every corner of
your house (assuming, of course, that
AT mode
Transparent
Data mode
Start-up
AT escape
sequence
AT*ADDM
Figure 7—
The module operates in one of two different
modes. Note the transitions between the AT mode and
the transparent Data mode.
ECI Host
(your application)
ECI Controller
(Bluetooth module)
Request: Service_Search
Confirm: Service_Search, N found
Result: service record 1
Request: Prepare_Serial_Data_Connection
Request: Connect_To_Serial_Service
Confirm: Connect_To_Serial_Service
Data transfer
Event: Serial_Connection_Closed
Request: Close_Serial_Connection
Confirm: Close_Serial_Connection
Server side
close
Client side
close
An optional
initial service
search on a
specific device
Result: service record 2
Result: service record N
. . . .
Confirm: Prepare_Serial_Data_Connection
Request
connection
Prepare
connection
Figure 6—
Have a look at the message sequence diagram when the host operates as a client and connects to a
server. An optional service search is also included.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
43
the devices are battery-operated).
ADVANCED APPS
I covered only the serial port profile
in this article, and last month I men-
tioned the dial-up networking and LAN
access profiles. With these profiles,
you can build advanced applications.
For instance, if you have a LAN access
point in a device with PPP, TCP/IP, and
a web server, you basically have a really
nice user interface to that device!
You can use a Bluetooth-enabled
PDA or laptop to access (configure and
control) the device through a web
browser. The possibilities are endless
with such systems. Using the dial-up
networking profile allows you to
extend the limited range of Bluetooth
with a GSM modem, for example.
IT’S SO EASY
It has never been easier to use Blue-
tooth. The ROK104001 is suitable for
products with somewhat higher vol-
umes because of its lower unit price.
The cB-OEMSPA is perfect for experi-
mentation.
I recommend that you read the
datasheets, user manuals, and protocol
specifications. There is a lot more to be
said about these products. I’ve present-
ed the most basic functions and fea-
tures. Now it’s your turn to explore!
I
Anders Rosvall is CTO of Embedded
Artists AB, which is a Sweden-based
company that provides industrial
communication solutions. He has a
long industrial background and has
held various positions within the ABB
Group. Anders is also a lecturer at
several of Sweden’s leading universi-
ties. You may contact him at Anders.
Rosvall@EmbeddedArtists.com.
PROJECT FILES
To download the code and informa-
tion about connecting to existing
SOURCES
ATmega128
Atmel Corp.
(408) 441-0311
www.atmel.com
cB-OEMSPA13i
connectBlue
+46 (0) 40 6307102
www.connectblue.com
ROK104001 Bluetooth module
Infineon Technologies
+49 (89) 234-28480
www.infineon.com
ARM7 GCC compiler
Keil Software, Inc.
www.keil.com
LPC2106 Microcontroller
Philips Semiconductors
www.semiconductors.philips.com
Figure 8—
The microcontroller has a 1.8-V core voltage and a 3.3-V I/O voltage. Internally, the processor runs at up to 60 MHz (i.e., the external 10-MHz crystal is multiplied by
six with a PLL).
products, go to ftp.circuitcellar.com/
pub/Circuit_Cellar/2004/167.
44
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
I
wrote a preemptive operating sys-
tem for the Zilog Z8 microcontroller.
In this article I’ll show you how to use
the Z8 Encore! evaluation board to do
it yourself.
When you have several isolated
tasks that need periodic servicing, you
can execute each one in sequence (see
Figure 1). This is a reasonable approach
if each task is short (e.g., sampling the
state of a switch). But what happens
when you have a long compute-bound
task and also need to periodically per-
form other tasks? Or worse, what if you
don’t know how long your tasks take to
execute? What if they change dynami-
cally? These nondeterministic factors
led to the development of preemptive
multitasking operating systems.
Such features can also lead to soft-
ware that is easier to write and main-
tain. For instance, the task of computing
an output value and presenting it can be
decoupled. In the ZRT sample code,
there are three competing tasks: a sim-
ple counter, an algorithm to compute pi,
and a routine to display the results. The
display routine has attributes of the
observer pattern described in Design
Patterns: Elements of Reusable Object-
Oriented Software
, by R.C. Holt et al.,
where the change of a value by one sub-
system is propagated to other subsys-
tems. Using patterns like this is a good
way to produce more robust software.
REAL TIME
Strictly speaking, nothing is real
time. For an operating system, however,
“real time” generally means that you
have a guaranteed interrupt or response
latency. In other words, you know that
including all the other applications, to a
grinding halt. Of course, you wouldn’t
tolerate that kind of scheme today. Now
you realize that even programmers with
the best intentions make mistakes, and
you need a way to take control away
from an application and return it to the
operating system. Indeed, the current
OS-X Macintosh operating system is
based on a Unix variant. With ZRT you
can also have a preemptive operating
system for the Z8.
Work on Unix began at Bell Labs in the
late 1960s, long before Microsoft and
Apple were even blips on the radar screen.
The preemptive nature of Unix meant
that sometimes it had nothing to do when
all the tasks were finished computing.
The creators of Unix devised another
task, the idle task, to fill up the spare
time. Rather than spin in a useless loop,
they had it calculate pi to a large number
of decimal places. The
piThread() in
ZRT also does this, admittedly in an inef-
ficient manner and only to the precision
of a 32-bit double. However, it’s a good
example of a compute-bound task.
The long lineage of the original IBM
AT, which was introduced in the early
1980s, isn’t forgotten here either. It
had a timer tick that you could access
from the DOS BIOS. For reasons based
on the early hardware, they chose a
timer tick of 18.2 per second, or once
every 55 ms.
[1]
This interrupt was often
used to create a rudimentary bitasking
operating system under DOS. The
same time slice is used in ZRT.
STACK FRAME
When a function is called, four
things are pushed on the stack. First
ZRT Real-Time Operating System
FEATURE ARTICLE
by Gareth Scott
after an event occurs, you will have to
wait only a certain amount of time
before the microcontroller responds.
In ZRT you can still place interrupts
at a higher priority than the scheduler.
These take precedence over servicing
the threads. In the threads themselves,
because you control the time slice of
the scheduler and you know how
many threads are being serviced, you
know what the worst-case time will
be to react to an event.
UNIX & THE IBM AT
Unlike DOS, Windows 3.x, and the
first Macintosh operating systems,
Unix was originally designed as a pre-
emptive multitasking operating system.
The Unix architecture has withstood the
test of time as evidenced by the increas-
ing popularity of Linux. In contrast,
Windows 3.x and the Mac were coopera-
tive multitasking operating systems.
The implications of this were huge. It
meant that every task had to voluntarily
return control to the operating system in
a timely manner. If one task got stuck in
a loop, it could bring the entire system,
Gareth’s small preemptive multitasking operating system runs on Zilog’s Z8 microcontroller.
The system—which consists of lightweight threads, a round-robin scheduler, and a binary
semaphore—has the ability to voluntarily relinquish control back to the scheduler. Get ready
to incorporate multitasking in your next project.
Figure 1—
Several short tasks can be handled without
preemption.
Task A
Task B
Task C
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
45
The ZRT scheduler is called periodi-
cally by a timer interrupt, and it is
responsible for passing control to the
next waiting thread. The scheduler’s
responsibilities include saving the cur-
rent thread context, restoring context
for the next thread, and returning con-
trol to the next thread.
CONTEXT SWITCH
Each thread or function has a con-
text or state associated with it that
consists of the current program count-
er, the stack, the content of the cur-
rent register group (R0–R15), and the
register pointer itself. This context is
defined in
struct thread in zrt.h
(see Listing 2). The scheduler main-
tains an array of these structures, one
for each thread.
The price for preemptive multitask-
ing is in the context switch. The
penalty is about 3% for a time slice of
18.2 ms. Obviously, the longer the
time slice, the closer you approximate
the case where you perform one task
to completion and then start on the
other. At 100 ms, there is no measura-
ble penalty compared to the case
where there is no task switching. The
context switch penalty is shown in
Photo 1.
WAIT, SIGNAL, & SLEEP
Multitasking operating systems have
to implement a mechanism to allow
resource sharing between threads. ZRT
does this by implementing a semaphore
using the standard P and V notation
(after the Dutch computer scientist E.J.
Dijkstra), which stand for the Dutch
come the function arguments followed
by the return address. R15 and the vari-
ables local to the scope of the called
function are pushed last (see Figure 2).
The C code and corresponding assem-
bly language for a simple function that
produces this kind of stack frame is
shown in Listing 1. As you can see in
Figure 2, positive indices on R15 are
used to access function parameters and
negative indices access local variables.
ZRT provides separate stack frames
for each thread. The scheduler then
forcibly changes the stack pointer each
time control is given to a new thread.
Because each thread’s stack grows
down, care must be taken not to run
into the stack from another thread, as
shown in Figure 3.
THREADS
Threads are separate entities of exe-
cution. From a logical standpoint, you
should think of them running inde-
pendently of the other threads. In
ZRT, they are implemented as func-
tions, and because they can share
resources, like global variables, they
are known as lightweight threads.
There are three sample threads in
the ZRT source code.
piThread()
calculates the value of
π
/4. The
counterThread() function is a count-
er.
displayData() displays both the
value of
π
/4, the number of iterations
of
piThread(), and the value of the
counter in
counterThread(). The
code takes advantage of the LEDs on
the Z8 Encore! evaluation board to dis-
play these values. Because each LED
has 35 dots (7 × 5), a 32-bit binary value
can be easily displayed in each one.
SCHEDULER
The scheduler is implemented as a
timer interrupt service routine (ISR)
called
isr_thread(). This routine is
just like an ordinary function except that
it is preceded by the
#pragma inter-
rupt statement in C code. This pragma
tells the compiler that the stack frame
will be set up in a slightly different man-
ner than a normal function call.
In addition to the program counter,
the flags register is also pushed on the
stack. Because of this, an ISR must
execute an
IRET assembly instruction
to return to the place before the
interrupt is handled. Interrupt rou-
tines also use a different register
pointer (RP) to point to a new group of
16 working registers.
Listing 1—
The C code and corresponding assembly listing generate a simple function.
char simple(char p)
{
char l;
l = p;
return l;
}
*PUSH R15
*LDX R15, SPL
*SUBX R15, #1
LD
R0,3(R15)
LD
-1(R15),R0
LD
R0,-1(R15)
*LDX SPL, R15
*POP R15
*RET
Top of stack
Function arguments
Program counter low
R15
Local variables
Stack grows down
in this direction.
The stack pointer is
here at the end of setting
up the stack frame and
entering the function body.
Program counter high
Figure 2—
Take a look at the stack frame. Positive
indices on R15 access function parameters. Negative
indices access local variables.
counterThread stack frame
piThread stack frame
displayData stack frame
Figure 3—
Each thread has its own separate stack that
grows downward toward lower memory values.
46
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
equivalent of wait and signal.
[2]
Refer
to the Circuit Cellar ftp site for more
information on semaphores.
Consider the situation in which you
have one thread generating a value and
another displaying that value. Indeed,
this is the situation in the sample
threads in ZRT. When one thread is
modifying or looking at a value, you
don’t want another thread changing that
value. So, when
piThread() is updat-
ing its value of pi, it uses a semaphore
to create a critical section to ensure that
the display thread won’t be using par-
tially loaded data (see Listing 3).
P and V, which are implemented
using the macros shown in Listing 4,
are applied as a macro for a couple of
reasons. First, the macro avoids the
overhead of a function call; it’s the
equivalent of a C++ in-line function.
In addition, because the test-and-set
nature of
P() must be an atomic (i.e.,
indivisible), you have to disable inter-
rupts in order to avoid having the
scheduler take control away and per-
haps (with bad consequences) give
control to another thread that also
happens to be in a call to
P().
The ability to give control back to
the scheduler is implemented by the
sleep macro, which is also shown in
Listing 4. It is the equivalent of issu-
ing a timer interrupt, which causes
the next thread to be executed.
TERMINATING THE THREAD
You may be wondering what hap-
pens to threads that terminate, or even
whether or not it’s possible to kill a
thread asynchronously. The normal
way for a thread to terminate is just to
have it return. But where does this
function return to (because it doesn’t
have a normal caller)?
You may remember from the discus-
sion on the stack that the calling func-
tion pushes the program counter’s (PC)
Listing 2—
As you study a thread’s context, note that the program counter isn’t stored here because its
value, like the flags register, is pushed onto the stack when the interrupt routine is called.
struct thread {
unsigned int sp;
// Stack pointer
unsigned char r15; // This is similar to the base pointer
BP in Intel’s 8086 architecture.
unsigned char rp; // The register pointer points to a
group of 16 registers. It’s used to
access r15.
unsigned char r14, r13, r12, r11, r10, r9, r8, r7, r6,
r5,r4, r3, r2, r1, r0;
unsigned char inUse;
};
Listing 3—
Use a semaphore to make sure the value won’t be displayed until it’s completely loaded. The
critical section of code is between P and V.
void loadLEDData(unsigned long x, char led)
{
P();
LEDarray[led].col0 = x & 0x7f;
LEDarray[led].col1 = (x >> 7) & 0x7f;
LEDarray[led].col2 = (x >> 14) & 0x7f;
LEDarray[led].col3 = (x >> 21) & 0x7f;
LEDarray[led].col4 = (x >> 28) & 0x0f;
V();
}
Listing 4—
The implementation of a semaphore has to be efficient.
// P = wait
#define P() DI(); for (;;) { DI(); if (semaphore == 0)
{SLEEP();} else {semaphore = 0; break;} }/*for*/ EI()
// V = signal
#define V() DI(); semaphore = 1; EI()
#define SLEEP() DI(); IRQ0 |= TIMER0_ENABLE; /*_sleep();*/ EI()
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
47
low and high bytes onto the stack
before calling a function. Those 2 bytes
show the callee where to return to
after it’s finished. The threads in ZRT
are the callee functions. In the
createThread() function, you push
the PC for a special function called
_cleanupThreads().
There are a couple of tricks involved
here. First, before pushing the return
pointer for
_cleanupThreads(), you
also push a byte that contains the
index of the thread that you’re clean-
ing. You’ll know the thread index
when you create it, but not when you
terminate, so this is a perfect time to
store it. This byte is a local variable
and therefore stored on the stack.
When the thread returns, use this
index to clear the inUse flag of the
scheduler so that you don’t try and
run the thread again.
ZRT actually jumps to the middle
of
_cleanupThreads() so that the
local variable
index doesn’t get over-
written. It’s easy to determine how
many bytes to jump (11H in this case)
by looking at the listing file generated
by the compiler.
The other way to forcibly terminate
a thread is to clear the inUse flag so
that the scheduler no longer allocates
time slices for that thread. This func-
tionality, although easy to implement,
has not been included in ZRT.
ENHANCEMENTS
The ZRT is written in small model,
which means that globals, locals, and
the stack must reside within the
20H–FFH range. That’s only 256 bytes,
but it’s enough to run three threads.
The large model isn’t nearly as restric-
tive. It uses the 00H–EFFH range,
which provides more space, but runs
slower because memory accesses are
not as efficient.
Because of the limited stack space,
you can’t have a large call stack of func-
tions. Also, recursion (when a function
repeatedly calls itself) is out of the
question without the large model. You
can tell if too much space is taken up
on the stack in your program by look-
ing at the .map output. The top of
RDATA should be less than the bottom
of the call stack for the last thread.
I hope you have fun with this little
Gareth Scott, who started programming
with the Altair 8080 in 1975, earned
degrees in Computer Science and
Electrical Engineering from Sonoma
State University and Cleveland State
University, respectively. He worked for
10 years at Autodesk as a programmer
on AutoCAD. He now works as a con-
sultant. Gareth’s interests include dis-
tributed microcontroller systems and
industrial control. You may reach Gareth
at embeddedcontrollers@yahoo.com.
PROJECT FILES
RESOURCES
E. Gamma, et al., Design Patterns:
Elements of Reusable Object-
Oriented Software
, Addison-Wesley,
Boston, MA, 1995.
Zilog, Inc., “Z8 CPU User Manual,”
UM12802-1002.
REFERENCES
[1] L. J. Scanlon, Assembly Language
Programming for the IBM PC AT
,
Prentice Hall, 1986.
[2] R.C. Holt, et al., Structured
Concurrent Programming with
Operating Systems Applications
,
Addison-Wesley, Boston, MA, 1978.
operating system. At the very least, it
should show you how to incorporate
multitasking in your own projects.
Furthermore, it should show you what
is going on in commercial multitasking
operating systems. Only this operating
system is freeware and has an extreme-
ly small memory footprint.
I
Photo 1—
There’s hardly any performance penalty for
multitasking.
with a battery-powered system, you need
to consider the total energy needed by all
of the components in the system. But,
for this discussion, I will concentrate
on the current used by the MCU.
As consumers have demanded longer
operation from smaller batteries, there
has been continuous pressure to
reduce the power consumption of MCU
systems. At the same time, shrinking
profit margins have forced MCUs into
smaller geometries to reduce die size
and cost. The smaller geometry process-
es result in transistors that cannot toler-
ate the direct application of 3- to 5-V
external power sources. As a result, a
regulator is used to drop the voltage
applied to most of the internal logic of
the MCU. This regulator adds to the
MCU’s overall power consumption.
Other pressures to increase MCU
performance have further complicated
this problem. Power consumption is
directly proportional to bus speed, so
increasing bus speed to improve per-
formance causes a corresponding rise
in power consumption.
These issues force the MCU to rely
heavily on power management
modes to keep the overall operat-
ing current down while still sup-
porting regulated power supplies
and increased clock speeds. New
MCUs provide multiple low-power
modes to address these needs.
Figure 2 shows how the power
consumption changes during the
different modes of operation in
the exercise bike example. The
light blue bars are the lowest
power mode. It’s the single
biggest factor in extending the
battery life in this application.
48
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
T
oday’s applications, and the end
users’ expectations for them, are placing
new demands on the venerable 8-bit
microcontroller. Therefore, MCUs must
continuously evolve to meet these new
demands. In this article I will look at
two areas in which application require-
ments have recently resulted in changes
to the MCU: reduced power consump-
tion and clock system flexibility. I’ll
also explain how to use new MCU
functions to address these new appli-
cation requirements.
EXAMPLE APPLICATION
I will use an exercise bike to illus-
trate how new MCU features would be
used to address these areas in a typical
application (see Figure 1). The MCU
controls all of the bike’s functions,
including saving user information, con-
trolling the pedal resistance, and track-
ing the exercise time, calories burned,
speed, and distance pedaled. For this
example, two alkaline C batteries power
the electronics and motor for controlling
the bike’s pedal resistance tension.
The MCU stays in the lowest power
mode until you press the Start
button. Then, the MCU prompts
you for a profile selection, exer-
cise time, and difficulty level
while running at the slowest bus
frequency. In this mode, you can
save these personal settings in
the flash memory.
After the ride starts, the MCU
goes into a low-power mode,
where it can periodically wake up
based on a real-time interrupt.
Every second, the MCU incre-
ments the elapsed-time counter
and updates the display. Every 2 s,
Survival of the fittest? You bet. Scott describes two areas in which MCUs are evolving to meet
the demand for cutting-edge apps: reduced power consumption and clock system flexibility.
the MCU’s timer is used to measure the
speed. After the speed is measured, the
MCU’s bus speed increases to its maxi-
mum in order to compute calories burned
and distance traveled based on the average
speed, elapsed time, and pedal resistance.
Every minute, the profile is checked,
and the pedal resistance is updated by
controlling a stepper motor with a
timer PWM signal. When the elapsed
time equals the programmed ride
time, an alarm is sounded, the pedal
resistance is reduced to its minimum,
and a summary of the exercise data is
displayed for 30 s. Your history can be
updated in the flash memory while the
summary data is on display. Finally,
the MCU returns to its lowest power
mode when the bike isn’t in use.
REDUCED POWER CONSUMPTION
The exercise bike uses C batteries
because it needs enough current to oper-
ate a small stepper motor that adjusts the
mechanism that controls pedal resist-
ance. This stepper motor draws a lot of
current when it runs; fortunately, it does-
n’t run too long or often. When working
FEATURE ARTICLE
by Scott Pape
Four-button
keypad
4
Keyboard
interrupts
60-KB
Flash memory
HCS08
CPU
LVI with
battery detect
10-bit
ADC
40-MHz
ICG
IIC
4-KB
RAM
General-
purpose I/O
Four-channel
timer
2 × SCI
SPI
Two C
batteries
32.768 kHz
V
S
V
D
+
+
IIC
LCD Drivers
and display
Piezo
buzzer
V
D
V
D
V
S
MC9S08GB60 MCU
Figure 1—
I created this block diagram for an exercise bike. It’s used to
demonstrate the methods modern MCUs use to reduce power consumption.
New Microcontrollers Meet Increasing Demand
MCU Evolution
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
49
that still provides minimum
regulation for retaining RAM
and I/O register contents.
Several interrupt sources can
wake up the MCU from Stop3,
as can the RESET pin. Stop3 is
the only stop mode in which
the low-voltage inhibit (LVI)
module can be enabled. It is
also the only stop mode in
which the crystal oscillator can
remain enabled. Stop3 is used
when the register configurations
must be maintained during stop
mode. It is also used when the
LVI or crystal oscillator need to
be running during stop mode.
In my exercise bike example,
Stop3 mode can be used while the
bike is in use to pause for 1 s between
each display update. The RTI function
that runs in Stop3 mode controls the
1-s interval for tracking elapsed time.
Stop2 mode provides a little less func-
tionality, but it reduces power con-
sumption even further. The voltage reg-
ulator is powered down, but the RAM
contents are still retained. The I/O reg-
isters are not retained in this mode and
need to be reconfigured after waking up
from stop. Also note that fewer inter-
rupt sources are available in Stop2 mode
to wake up the MCU. It is used when
the RAM needs to be retained, but the
I/O registers can be restored upon wak-
ing up. Although internal peripherals
are powered off in Stop2 mode, the
MCU pins maintain the states they
were in when the mode was entered.
Because a typical household exer-
cise bike is in use less than 1 h a
day, it spends 95% of its life in
this mode, making the lowest
power mode the most important
to minimize. Freescale’s new
MC9S08GB60 MCU consumes
approximately 25 nA in its low-
est power Stop1 mode.
The dark blue bars represent
the low power mode with an
automatic wake-up feature
enabled. The MCU spends
roughly 75% to 95% of the
exercise time in this mode,
making it the second most
important to minimize for
extended battery life. Referring
the MC9S08GB60 once again, the cur-
rent is typically less than 1 µA.
The gold bars represent power con-
sumption when the MCU is running at
a slower frequency. Slow frequencies are
beneficial when the CPU is not execut-
ing many instructions and is instead
waiting for input or taking a sensor read-
ing. In my bike example, the low-fre-
quency operation is used when selecting
the exercise program, when the MCU
is taking a speed measurement with a
timer module, and when adjusting the
pedal resistance through inputs to a
stepper motor. The frequency should
be selected to be the lowest one that
enables the peripherals to function.
Finally, the orange bars represent
the MCU at its highest frequency oper-
ation. The benefit of running at the
highest frequency occurs when the
CPU is not waiting on other peripherals
and instead has a set of calculations to
make or I/O ports to configure. In these
circumstances, you want the CPU to
finish its task quickly and allow the
system to return to a lower power
mode. In my example, this occurs when
the MCU calculates the current values
for elapsed time, speed, distance trav-
eled, and calories burned, and then
updates the display with these values.
It might seem that the faster bus
speeds and the additional regulator are
contrary to low-power consumption,
but it’s important to consider the
entire MCU system to understand the
real effects. For example, if you assume
that you can reduce power consump-
tion to nearly zero during times of inac-
tivity, the faster bus speed may mean
that you finish your work faster so the
MCU can spend more time in the
extremely low-power condition. And
because power is the product of voltage
and current, a 1.8- to 3-V system with
a regulator still may have lower power
than a 5-V system without a regulator.
MCUs have various power-saving
modes that reduce power during inac-
tive periods. For instance, the
MC9S08GB60 has four low-power
modes: Stop1, Stop2, Stop3, and Wait.
At reset, Run mode is the normal
mode of operation. By executing a wait
instruction, the MCU can enter Wait
mode, where power is reduced by turn-
ing off the CPU clock and leaving the
clocks enabled to other MCU peripher-
als like A/D converters, timers, and seri-
al communication modules. This mode
is useful for saving power
when the peripherals need to
function, but the CPU has
nothing to do until a periph-
eral completes a task.
The three stop modes can
be used to further reduce
power consumption. After a
stop instruction is executed,
one of three stop modes is
entered. Stop1, Stop2, and
Stop3 each provide different
levels of operation that
reduce power consumption.
In Stop3 mode, which pro-
vides the most functionality
of the stop modes, the on-
chip voltage regulator goes
into a power-saving mode
High-frequency Run mode when
updating display once per second
Low-frequency
Run mode when
controlling stepper
motor for pedal
resistance
once per minute
Low-frequency Run
mode when checking
speed every 2 s
Low-power
mode with
automatic wake-up
Lowest power
mode when
not in use
Start
button
pressed,
low-
frequency
Run mode
for user
input
Time
Power
Figure 2—
In my exercise bike application, power is managed by alternating
between short bursts of high activity and longer periods of inactive low-
power modes.
Photo 1—
The battery life calculator for the MC9S08GB60 family of
MCUs lets you estimate the average battery life of your application.
Estimates are based on a variety of inputs about the MCU’s operat-
ing conditions.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
51
In the exercise bike example, Stop2
mode can be used in place of Stop3
mode to reduce power consumption a
little more. The RTI function and RAM
both work in Stop2 mode, so you can
still track the elapsed time. Because the
registers return to their reset value,
they have to be reconfigured. However,
if the code is written so that the regis-
ters are configured from scratch each
time a particular function runs, then
resetting the registers should not pres-
ent a problem. For instance, if the timer
registers are initialized each time a
speed measurement is made, there is
no need for these registers to retain
their value during the stop period.
Stop1 mode, which is the lowest
power mode of the MCU, powers the
voltage regulator down completely
along with all of the peripherals and
the CPU. RAM and I/O register con-
tents are not retained. Only the reset
and IRQ pins can wake up the MCU.
Stop1 mode is used when the MCU can
be put into a powered-down state, but
still needs to respond to an external
stimulus such as the press of a button.
In my bike example, Stop1 mode is
entered when the bike is not in use.
(That’s 100% of the time for some
people!) Because none of the peripherals
and memory are needed when the bike
isn’t in use, shutting them down with
Stop1 mode puts the MCU in the low-
est possible power mode without actu-
ally removing power from the chip.
Why not just remove power from the
chip? Removing power requires either a
mechanical toggle switch or an exter-
nal circuit to disable power to the chip.
Toggle switches, which are typically
more expensive than push button
switches, can be harder to incorporate
into the smooth control panels that are
common today. An electric circuit to
remove the power adds extra compo-
nents to the design that naturally add
cost. So, Stop1 mode is perfect for
keeping the design simple and inexpen-
sive while consuming almost no current.
Listing 1 shows an example of how
you can choose different low-power
modes depending on the state of the
application. In this example, as long as
the user flag EndOfRideF is clear, the
MCU is configured to enter the partial
power-down mode, which allows for the
use of the MCU’s real-time interrupt
function and preserves the RAM values.
Because the I/O registers are lost in this
mode, the code excerpt also shows how
to configure a list of register addresses to
preserve their values in RAM and restore
them after the next system wake-up.
ESTIMATE BATTERY LIFE
System designers have so many
options available to extend battery life
that they are now faced with the diffi-
cult task of estimating and comparing
the power consumption of various
power mode scenarios. Does alternat-
ing between a powered-down mode
and full run mode consume less cur-
rent than spending the same time in an
intermediate mode? To see the effects
on average power consumption of vari-
ous MCU configurations, Freescale has
a battery life calculator that estimates
Listing 1—
This code excerpt demonstrates how to configure the M9S08GB60 for different low-power
modes based on the current status of the application. There also is a method for preserving register values
when the MCU’s partial power-down mode is used.
// Save_IO_Registers: move register values into RAM
void Save_IO_Registers(void) {
for (reg = 0; reg < RegCount; reg++) {
Saved_Reg[reg] = *Reg_Array[reg];
};
}
// End Save_IO_Registers()
// Restore_IO_Registers: load register values from RAM
void Restore_IO_Registers(void) {
for (reg = 0; reg < RegCount; reg++) {
*Reg_Array[reg] = Saved_Reg[reg];
};
SOPT = 0xf3;
// Configure MCU option register
SPMSC1 = 0x00;
// Configure LVD options register
if (EndOfRideF==1) {
// If the ride is over,
SPMSC2 = 0x06; // enable full power-down mode at
// next STOP
}
else {
// If the ride is continuing,
SPMSC2 = 0x07;
// enable partial power-down mode at
// next STOP
}
}
// End Restore_IO_Registers()
// Main program loop
void main(void) {
// The PPDF flag in the SPMSC2 register will be set if the MCU
woke from STOP2 and will be clear if the MCU woke from STOP1.
if (SPMSC2_PPDF == 1) { // Enter if waking from stop2
Restore_IO_Registers(); // Restore register values
Inc_Elapsed_Time();
// Set flags based on current ET
if (MeasSpeedF == 1)
// Speed measured every 2 s
Measure_Speed(); // Measure speed and update global var
if (CheckProfileF == 1) // Profile is checked every minute
Check_Profile();
// Checks current profile against ET
Set_Bus_Clock(HiSpeed); // High speed for calculating values
Update_Display();
// Update user display
}
else { // Enter if waking from stop1
Init_IO_Registers(); // Init. I/O registers and global vars
Set_Bus_Clock(LoSpeed); // Low speed for receiving user input
Get_User_Profile();
// Prompt user for exercise routine
Start_Elapsed_Time();// Init. s/w counters and select timeout
Set_Pedal_Resistance(); // Sets the pedal resistance for time
// = 0
}
if (EndOfRideF == 0) {
// If the ride is continuing,
Save_IO_Registers();
// save registers to RAM
}
asm(stop); // Enter stop1 or stop2 depending on
// settings
}
// End main()
52
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
the life of a selected battery type based
on the MCU’s operating conditions.
Photo 1 is a screen shot of the bat-
tery life calculator. The top left box
contains the input fields for the bat-
tery capacity (mAh) and the self-dis-
charge current of the battery type (in
percentage capacity loss per year).
Several popular battery types are pre-
defined in the pull-down boxes, or you
can enter a numerical value.
The bottom left box is where the duty
cycle is set. Here you can enter the per-
centage of operating time the MCU
spends in the Run, Wait, and three stop
modes. The percentages must add up to
100%, or an error will occur and no cal-
culation is made. Also, at the bottom is
the input field for the wake-up inter-
val. This is the period of time from the
start of one full-active wakeup to the
start of the next full-active wakeup.
The box on the right contains input
fields for several operating parameters
of the MCU from which the current is
calculated. The area for the number of
ADC conversions per cycle pertains to
the number of A/D conversions made
during the wake-up interval. The LVI
and RTI enabled when the stop modes
are initiated are simple yes/no inputs
to determine if these features are in
use. Make sure you enter a valid con-
figuration because the RTI and LVI are
not available in all three stop modes.
Input fields for bus frequency (mega-
hertz) and average VDD (volts) are
entered next. If more than one bus fre-
quency is used, enter the time-averaged
frequency used during the run and
wait intervals. Similarly, VDD should
use a time-averaged value because the
voltage will decrease as the battery dis-
charges. A pull-down box is provided
for the average temperature during the
operation of the MCU. In this case, you
cannot enter a custom value, so sim-
ply select the closest value.
After all the inputs are entered,
clicking on the Calculate button gen-
erates the estimated battery life and
updates the bar graph on the bottom
of the page. Also displayed are the
results from several intermediate cal-
culations used to determine the final
result. Keep in mind that the results
are estimates. The equations used to
generate the estimates are based on
actual measured values. However, the
actual device may not always behave
exactly as the equation used to simu-
late it because of process variation or
external application circuitry.
CLOCK SYSTEM FLEXIBILITY
The first MCUs used a crystal as
their clock source. This approach has
worked well over the years, and it is still
the best choice for many applications.
More recently, though, some MCUs
have integrated a phase-locked loop
(PLL) so an application can use a 32-kHz
crystal and drive the frequency up to
faster bus speeds. But PLLs often require
external filtering components and use up
a few precious pins on the MCU. The
most recent clock development on some
MCUs is an internal self-clocked oscilla-
tor that completely eliminates external
components and doesn’t use MCU pins.
The MC9S08GB60 provides the
advantages of all of these approaches
and replaces the PLL with a frequency-
locked loop (FLL), which doesn’t
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
53
than 20 µs, even at low voltages!
Another advantage of internal oscil-
lators is the elimination of external
components. The better internal oscil-
lators do not require so much as a
capacitor or resistor (no components).
The benefits include fewer parts to
stock, less required board space, lower
board assembly cost, and improved
reliability because of the elimination
of solder joints.
Reduced EMI emissions is yet anoth-
er advantage of internal oscillators.
External components aren’t necessary, so
you don’t need an I/O pad to propagate
the clock signal. Therefore, bond wires
don’t carry the clock signal to a package
pin, and clock traces aren’t required on
the PCB. All of these elements con-
tribute to EMI noise on traditional
crystal/ceramic resonator oscillators.
Clock accuracy is the drawback to
using these internal oscillators.
Allowing for wafer fabrication vari-
ables, internal oscillators can vary
±
25% from their base frequency. Many
versions of internal oscillators include
a trimming function to compensate
require any external components or
pins. Depending on the application, you
can use a traditional high-frequency
crystal (with or without FLL multiplica-
tion), a 32-kHz crystal (with or without
the FLL), or the internal self-clocked
frequency source. Using a low-frequen-
cy crystal reduces power consumption
even if you use the internal FLL to
multiply the bus frequency to a faster
rate because relatively high-capaci-
tance external pins do not need to
switch at high frequency. In addition,
you can manage power consumption
by using the FLL to increase frequency
during times of high CPU demand and
then decrease the frequency when the
CPU demand is lower.
Using the internal self-clocked fre-
quency source has numerous advan-
tages. First, it starts much more
quickly than a crystal. High-speed
crystals require 1 ms or more to stabi-
lize at full speed, especially at low
voltages (less than 2.5 V). Low-speed,
32-kHz crystals can take up to 0.5 s to
stabilize. In contrast, internal oscilla-
tors can start and stabilize in less
for these fabrication variations.
However, even with a trim function,
internal oscillators typically cannot
perform better than
±
1% or 2% of the
base frequency over even limited tem-
perature and voltage variations. So, if
timekeeping accuracy is important, a
crystal-based oscillator is required.
However, even if you use a crystal
in your application, the internal oscilla-
tor can provide benefits. Most MCUs
with internal clock sources default to
the internal source at power-up. This
provides a fast, efficient, reliable clock
when coming out of the power-on-reset.
This allows you to turn on the external
source and verify that it is stable before
switching to it. It also allows you to
run initialization code while waiting for
a slow-starting crystal to stabilize.
A similar advantage can be had when
the MCU is recovering from one of the
low-power stop modes after the external
oscillator is powered down. Some inter-
nal clock modules allow you to switch
between the different internal and exter-
nal clocks. By switching to the internal
clock just before entering a stop mode,
54
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
you force the MCU to recover from it
by using the fast-starting internal
clock, and you can drastically reduce
the time between the signal’s waking
up and the beginning of code execu-
tion. Just as with power-up, you can
execute code while waiting for the
external oscillator to stabilize.
Some internal clock modules also pro-
vide external clock monitoring to pro-
tect against the loss of an external clock
signal. If the external clock is lost, the
MCU automatically switches to the
internal source. Full-featured clock mod-
ules also provide options to reset or
interrupt the MCU when this occurs,
therefore eliminating the need for soft-
ware to poll the clock status flags.
Listing 2 shows how to select differ-
ent clock configurations based on the
application’s state. A lower speed is used
whenever the CPU demand is lower and
the peripherals dominate the MCU
activity. Whenever CPU demand
increases (e.g., when the display values
are about to be calculated), a higher bus
frequency is selected to quickly make
the calculations and allow the MCU to
quickly get back into a low-power state.
ADAPTATION CONTINUES
Now you’re familiar with two areas in
which MCUs are evolving to meet the
demands of modern applications. I
explained how to selectively use the
Stop and Wait modes to force some sys-
tems into low-power standby modes
while keeping other systems awake to
keep track of time and periodically wake
up the MCU. I also described how more
sophisticated clocking systems, includ-
ing internal oscillators and FLL circuits,
get high-speed bus clocks from low-
speed crystals. These clock improve-
ments help reduce power consumption,
start-up time, and EMC emissions.
These are just two of the areas in
which MCUs are evolving. Other areas
include higher-performance flash mem-
ory and feature-rich, in-circuit debug-
ging. As the demands of modern appli-
cations increase, the microcontroller
will adapt to meet these demands.
I
SOURCE
MC9S08GB60 Microcontroller
Freescale Semiconductor
e-www.motorola.com
Scott Pape is a systems engineer with
the 8/16-Bit Products Division at
Freescale in Austin, Texas. He has
14 years of experience with microcon-
trollers as both a product and systems
engineer. Scott earned a B.S.E.E. at the
University of Texas. You may reach
him at scott.pape@motorola.com.
Listing 2—
Now you can configure the clock module based on the status of the application. This excerpt also
shows you how to configure the M9S08GB60’s real-time interrupt function.
// Set_Bus_Clock: set the bus speed to one of two preset frequencies
void Set_Bus_Clock(byte BusSpeed) {
if (BusSpeed == HiSpeed) { // Set ICG for highest speed
ICGTRM = TRIMLOC;
// Get stored trim value
if (SavedFLTU!=0 && SavedFLTL!=0) {
ICGFLTL = SavedFLTL;
// Check for saved value for…
ICGFLTU = SavedFLTU;
// …DCO filter for faster lock
}
ICGC2 = 0b01110000;
// Multiplier=x18; Divisor=/1
ICGC1 = 0b00001000;
// Select FLL enabled with int ref
SavedFLTL = ICGFLTL;
// Save value of DCO filter…
SavedFLTU = ICGFLTU;
// …to use to speed next FLL lock
}
else {
// Set ICG for default frequency
ICGC1 = 0b00000000;
// Select Self Clock Mode
}
}
// End Set_Bus_Clock()
// Inc_Elapsed_Time: increment the s/w ET clock and sets job flags
void Inc_Elapsed_Time(void) {
Job_Flags = 0;
// Clear all job flags
ElapsedTimeSec += 1;
MeasSpeedF = ETS_BIT0;
// Gets set every odd second
if (ElapsedTimeSec == 60) { // Rollover seconds, inc minutes
ElapsedTimeSec = 0;
CheckProfileF = 1;
// Set "CheckProfileF" every minute
ElapsedTimeMin += 1;
if (ElapsedTimeMin==RideTimeMin)
EndOfRideF = 1;
// Set if ET = selected ride time
}
}
// End Inc_Elapsed_Time()
// Start_Elapsed_Time: init s/w clock and configure the RTI for 1 s
void Start_Elapsed_Time(void) {
ElapsedTimeSec = 0;
// Reset ET counters to zero
ElapsedTimeMin = 0;
SRTISC = 0b01010111;
// Init RTI for 1.024-s timeout
}
// End Start_Elapsed_Time()
// Main program loop
void main(void) {
// Beginning of ride tasks:
Init_IO_Registers();
// Init registers and global vars
Set_Bus_Clock(LoSpeed);
// Low speed for initialization
Get_User_Profile();
// Prompt user for exercise routine
Start_Elapsed_Time();
// Init. s/w counters and RTI
Set_Pedal_Resistance();
// Set pedal resistance for time = 0
// Tasks at wake-up intervals:
Inc_Elapsed_Time();
// Flags set based on current ET
if (MeasSpeedF == 1)
// Speed measured every 2 s
Measure_Speed();
// Measure current speed
Set_Bus_Clock(HiSpeed);
// High speed for calculating
if (CheckProfileF == 1)
// Profile is checked every minute
Check_Profile();
// Checks profile against ET
Update_Display();
// Calculate and update display items
}
// End main()
equations dealing with motion along a
straight line or around one axis. This may
seem restrictive, but mobile robots spend
most of their time moving forward,
backward, and making simple turns.
In one-dimensional kinematics, the
robot shrinks to a point located at s
0
on a line, with an initial velocity of v
0
along that line. Negative positions and
velocities are traditionally seen as
being leftward.
If v
0
is zero, then the robot just sits
at s
0
forever. A nonzero v
0
is more
interesting because the robot’s posi-
tion s at time t becomes:
The robot’s velocity remains constant
unless it undergoes acceleration.
Positive acceleration increases the veloc-
ity to the right; negative acceleration
increases the velocity to the left. The
derivatives of acceleration known as jerk
and snap are important for delicate
structures but don’t affect sturdy robots.
The robot’s velocity, v, with a con-
stant applied acceleration, a, is:
and its position is:
Simple mathematical hocus-pocus
produces two other handy equations:
v
2
= v + 2a s s
0
2
0
−
(
)
s
v
t
= s +
+ v
0
1
2
0
(
)
s
at
= s + v t +
0
0
1
2
2
v = v + at
0
s
t
= s + v
0
0
ABOVE THE GROUND PLANE
by Ed Nisley
56
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
P
rogramming can be quite seductive:
within the confines of your CPU, pretty
much everything works the way you
want. Once you understand that the
computer does what you actually pro-
gram, not what you mean, you can do
nearly anything.
Ordinary applications programming
uses that model because it has essen-
tially no connection to the real world.
Input comes from disk files, control
from a keyboard, and output goes to
more disk files and perhaps a graphics
display. All of those have simple, digi-
tal interfaces that work pretty much
as described in The Fine Manuals.
Writing programs for robots, on the
other hand, requires knowledge of both
ordinary programming techniques and
real-world physics. Although an algo-
rithm may command a robot to stop
instantly, real-world objects just don’t
work that way.
I gave a talk on robot mechanics at
the 2004 Trinity College Fire Fighting
Home Robot Contest and thought that
this topic would be of interest to you
too. Let’s take a look at what happens
where the rubber tires meet the arena.
KINEMATICS
Kinematics describes how objects
move while ignoring details like mass,
force, and friction. You can’t apply kine-
matics in the real world without those
details, but you can’t control a real
robot’s motions without kinematics.
Although you probably learned basic
kinematics in high school, a quick
review is in order. To keep it quick, I’ll
concentrate on the one-dimensional
Rotational kinematics follows similar
equations, with
θ
,
ω
, and
α
in place of s, v,
and a, respectively. That’s theta for angu-
lar position, omega for angular velocity,
and alpha for angular acceleration. Just
substitute the Greek letters into the previ-
ous equations and you can solve rota-
tional problems as easily as linear ones.
The units of linear kinematics are
meters and seconds, with velocity
measured in meters per second (m/s)
and acceleration in meters per second
squared (m/s
2
). Rotational kinematics
uses radians rather than degrees:
The customary unit for angular
velocity is revolutions per minute, with
this conversion to radians per second:
To the level of accuracy you need,
1 rad/s equals rpm/10. Thus, a small
motor turning at 1000 rpm is rotating
at 100 rad/s. The next step, dynamics,
builds on kinematics by adding the
real-world properties of mass, force, and
friction to those point-like objects.
DYNAMICS OF PUSH
The most fundamental property of
an (idealized) object is its mass—the
amount of “stuff” it contains. A cubic
centimeter of aluminum has a mass of
2.7 g. Iron weighs 7.9 g/cm
3
, and com-
mon steel alloys weigh about 7 g/cm
3
,
while plastics and rubbers hover near
1 g/cm
3
, the density of water.
Stop right there while I sort out a
ω
=
rev.
min.
s
rad
rev.
min.
.
×
° ×
×
°
360
1
1
60
1
57 3
1
360
2
radian =
= 57.3
π
°
Robot Mechanics
Writing a program for a robot requires an understanding of both physics and standard pro-
gramming techniques. This column contains all of the basic information—essential formu-
las included—every serious robot designer should know.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
57
common confusion: weight is a force
and mass is, well, mass. Force can be
measured with either the newton (N)
or the kilogram-force (kgf), so a scale
showing a “weight” of 1 kg is actually
reporting 1 kgf. The situation with
nonmetric units (poundals? slugs?) is
so baffling that I’ll ignore it.
An object of mass m moving at a veloc-
ity v possesses a property called “momen-
tum,” which is abbreviated p, with
units of mass times velocity: p = mv.
Force is the push required to change
an object’s momentum:
In the general case, an object’s
momentum changes with differences
in both velocity and mass; rocket sci-
entists know this fact well. Most
robots have a constant mass. Because
acceleration is the time derivative of
velocity, we get Newton’s second law:
The units of force are thus kilogram-
meters per second squared (kg-m/s
2
),
which is the definition of a newton.
Earth-normal gravity provides an accel-
eration of 9.8 m/s
2
, so a weight of 1 N
has a mass of 0.10 kg. Conversely, a 1-kg
mass weighs 9.8 N. A weight of 1 kgf
equals a mass of 1 kg only on Earth.
Along with momentum, a moving
object also possesses kinetic energy
(KE), which is defined as:
Energy is measured in joules, equiva-
lent to kg-m
2
/s
2
, or N-m. Raising a
mass in a gravitational field imparts
potential energy equivalent to the force
times the distance, which means you
can figure how far up a ramp a robot
will coast on just its kinetic energy.
The units of power are kg-m
2
/s
3
, N-
m/s, or J/s. As in electronics, 1 J/s
equals 1 W. A mechanical watt is exact-
ly the same amount of power as an elec-
trical watt. Finally, you have enough
math to do something interesting!
FROM PUSH TO GO
The robots entered in the fire-fight-
ing robot contest range from simple
KE
mv
=
1
2
2
f
dv
dt
= m
= ma
f
dp
dt
=
Lego Mindstorms creations to intricate
mechanical structures. Regardless of
whether they use wheels, treads, or feet
(honest!), their motions remain subject
to both kinematics and dynamics. The
trick is to figure out how these equa-
tions apply to the robots.
Each robot must fit into a 31-cm cube,
with no restrictions on weight. The light-
est robots, made largely of plastic with a
few motors and a battery pack, weigh
perhaps 0.5 kgf. The heaviest one I saw,
a tank-tread monster hewn from alu-
minum slabs, must have weighed at least
20 kgf. Let’s assume you have a 1-kgf
robot; that may be on the light side, but
it makes the numbers work out nicely.
The robots must maneuver within a
simulated four-room house, with the
longest straight path approximately
250 cm along the main hallway. Let’s
suppose the robot will drive 200 cm
along that path, beginning and ending
at zero velocity. The kinematic equa-
tions tell you the velocities and accel-
erations, while the dynamic equations
limit what you can do.
For example, kinematics may require
an extremely high acceleration, but tire
traction and motor torque set the actual
upper limit. A few examples will show
you how to apply both sets of equations.
Most robots run on soft rubber tires
with a coefficient of friction near one.
You can measure that coefficient, at least
roughly, by pinning the robot’s wheels so
they cannot turn and measuring the force
required to drag it across the floor.
I measured a coefficient of friction
of about 0.9 for 81.6 mm × 15 mm
Lego tires skidding across a Formica
desktop. That means a 1-kgf robot can
exert at most 0.9 kgf of traction, and
its maximum acceleration will be:
That’s just under 1 G, which is pretty
good for a sports car.
With constant acceleration, the fastest
trip from one point to another requires
accelerating to the midpoint of the route
and then decelerating to the endpoint.
Zipping along the 2-m hallway produces
this peak velocity at the midpoint:
The elapsed time to the midpoint is:
The complete trip takes just under 1 s,
which would certainly draw cheers
from the audience. Unfortunately,
Lego Mindstorms motors aren’t capa-
ble of sports car performance levels.
FROM TURN TO PUSH
A motor’s ability to turn its shaft is
given by its torque in units of length ×
force. Although a motor’s torque
depends on many factors, to a decent
first approximation, it’s simply the prod-
uct of the heaviest weight it can lift
times the distance from the motor’s axis.
Torque (
τ
) has units of meter-newton
(m-N), which may appear the same as
the unit of energy (N-m). In fact, torque
and energy measure completely differ-
ent quantities. You should never con-
vert torque measurements into joules
or other energy units that don’t explicit-
ly show the length component.
I built the simple dynamometer in
Photo 1 from standard Lego Mindstorms
parts. The wheel radius is 33 mm, with
a strip of black tape as a target for the
blue-brick optical sensor located
behind the motor.
Photo 2 shows the current drawn
for four different loads, using a 0.1-
Ω
resistor in series with the battery pack
to convert current to voltage. Notice
that the motor draws nearly 300 mA
for a few milliseconds as it starts up.
The current falls as the gear train gets
up to speed, rises as the string stretch-
es while accelerating the load, and
then levels out as everything reaches a
steady state.
t =
1 m
m/s
= 0.47 s
2
2
9
×
2 9 m/s 1 m = 4.2 m/s
2
×
×
0 9
1
.
9.8
N/kgf
kg
= 9 m/s
2
kgf
×
Photo 1—
Measuring a motor’s torque requires a
known weight applied at a specific wheel radius. A 0.1-
Ω
resistor converts current into voltage for the oscillo-
scope. My daughter insisted on a few more gears and
decorations than absolutely necessary.
58
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
The motor stalls with a 150-gf weight
and can barely lift 120 gf, so its maxi-
mum torque is:
If the 1-kgf robot drove those big 81.6-mm
rubber tires with this motor, the trac-
tion force becomes:
The acceleration is:
The midpoint speed is:
The time to the midpoint is:
Thus, reducing the acceleration by a
factor of nine increases the time by
approximately a factor of three, as
you’d expect from the kinematic
equations. This robot would traverse
the hallway in 3 s, which might not
draw as many cheers as a 1-s run.
ENERGY, POWER, & CURRENT
Accelerating a robot up to speed
from a standing start requires energy.
Using more energy requires larger bat-
teries, which increase the robot’s mass
and reduce the acceleration possible
from a given motor torque. Carried to
an extreme, you have a robot that’s so
heavy it can’t move.
A 1-kgf robot traveling at 4.2 m/s
has a kinetic energy of:
2 1 m
1.3 m/s
= 1.5 s
2
×
2 0.93 m/s 1 m = 1.3 m/s
2
×
×
0 93
1
.
N
kg
= 0.93 m/s
2
0 038
0 041
.
.
m-
N
m
= 0.93 N
τ
= 0.033 m 0.12 kgf
N
kgf
= 0.038 m-
N
×
×
9 8
1
.
Remember that the kinetic energy
associated with a given speed is inde-
pendent of the time or acceleration
required to reach that speed. However,
the power required to accelerate the
object definitely depends on time.
Under traction-limited acceleration,
the average power is:
The Lego motor would reach 4.2 m/s in:
with an average power of:
A simple DC motor produces power
by drawing current from a fixed-volt-
age source, which means the current
is directly proportional to the output
power. The Lego Mindstorms motors
run from six AA cells for a nominal
9 V, but actually deliver only 6.8 V to
the motor at 300 mA. The other 2.2 V
vanishes in the battery pack’s internal
resistance, the wiring, the controller’s
switching transistors, and so forth.
Supplying 4 W to the motor requires
440 mA at 9 V or 600 mA at 6.8 V,
much more than I actually measured.
Given the cumulative inaccuracies of
the measurements and assumptions,
that’s reasonably close. Of course, you’re
welcome to improve my techniques!
Because the force generated by a Lego
motor is far less than the traction limit,
two motors can produce twice the trac-
tion force and (nearly) twice the accelera-
tion. Of course, they’ll draw
twice as much current from
the batteries, but that’s an
easy trade-off to accept.
ROTATING IN PLACE
Linear momentum, the
product of mass and
velocity, determines the
force required to acceler-
ate an object in a straight
line. A similar quantity,
angular momentum,
comes into play when an
8 8
. J
2.1 s
= 4.1 W
4 2
0 93
.
.
m/s
m/s
= 2.1 s
2
8 8
0 47
.
.
J
s
= 20 W
1
2
2
1 kg 4.2 m/s = 8.8 J
×
×
(
)
Photo 2—
These superimposed traces show battery current while hoist-
ing four different loads. The motor’s maximum load current is about
300 mA, and it hits that peak even with no mechanical load.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
59
object rotates. The formula is decep-
tively simple: L = I
ω
.
The object’s moment of inertia, I,
can be calculated from first principles
if you spend time wrestling with the
references. Many robots entered in the
Trinity contest were roughly disk-
shaped, with their mass on a base plate
atop two driving wheels, so I’ll approxi-
mate them as a thin disk of mass, m, and
radius, r, rotating about its central axis
(think of a spinning plate) with I = mr
2
/2.
The torque required to accelerate an
object around an axis is:
The power in watts required to spin an
object is simply
τ
×
ω
. There’s one
advantage of pure metric units: no
weird conversion factors!
The kinetic energy of a spinning
object is:
That 1-kgf robot must rotate (and thus
accelerate) around its vertical axis to turn
before entering a room. Assuming that
the mass is distributed uniformly across
the base plate, its moment of inertia is:
The traction force generated by a
pair of counter-rotating Lego motors,
each driving one of those big rubber
tires, is 1.9 N. If the motors are each
10 cm from the robot’s midline, the
torque around the central axis is:
Knowing both I and F, you can find
the angular acceleration:
As with linear travel, the fastest way
to make a turn is to accelerate halfway
and decelerate halfway. The elapsed
time for an eighth of a turn (half a quar-
ter turn) will be:
That means the robot can make a
quarter turn in just over half a second.
t =
2
rad/s
= 0.3 s
2
×
2
8
17
π
α
τ
= =
m
N
kg
m
= 17 rad/s
2
2
I
0 19
0 011
.
.
-
-
τ
= 0.1 m
× 1.9 Ν = 0.19
m-
Ν
I =
1 kg 0.15 m
= 0.011 kg-
m
2
×
(
)
2
2
KE
I
=
1
2
2
ω
τ
ω
α
=
= I
= I
dp
dt
d
dt
PROJECT FILES
To download the code, go to
ftp.circuitcellar.com/pub/Circuit_
Cellar/2004/167.
RESOURCES
HyperPhysics, Georgia State
University, hyperphysics.phystr.gsu.
edu/hbase/hframe.html.
Physics at School for Champions, www.
school-for-champions.com/science.
Physics information, Wikipedia,
en.wikipedia.org/wiki/Physics.
Trinity Firefighting Robots contest,
www.trincoll.edu/events/robot/.
Lego Mindstorms motor torque
sensor, www.plazaearth.com/usr/
gasperi/speed.htm.
Ed Nisley is an E.E., P.E., and author
living in Poughkeepsie, NY. You may
contact him at ed.nisley@ieee.org. Put
“Circuit Cellar” in the message’s sub-
ject line to clear the spam filters.
The crowd probably won’t go wild, but
they’ll certainly enjoy the show.
CONTACT RELEASE
You’ll find many simplifications in
these calculations. I’ve ignored the diffi-
culty of accelerating a mass that can stall
the motor at full load, how a motor’s
speed varies with its load, the problem of
decelerating a DC motor, the effect of
maximum motor speed on acceleration,
and so forth and so on. All those issues
are relevant, but they become important
only after you work through the funda-
mentals of your robot’s mechanics and
know what’s required in the first place.
The basic lesson: Use the kinematic
equations to find the acceleration
required for the performance you want,
and then work through the dynamic
equations to find out what that per-
formance will cost. Next, measure
some physical values, work through the
equations again, and see how well these
models work. Those results will teach
you how the real world works, generate
still more questions, and eventually
lead you to a solid understanding of
how your robot runs. You’ll learn some
physics along the way, too!
I
60
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
T
emperature measurement is an
extremely important component in
the world of electronics these days.
Validating this point, just about every
evaluation board I’ve come across lately
demonstrates the measurement of tem-
perature in one way or another. The
process of measuring temperature has
also spawned an entire market segment.
You can purchase hand-held VOM-like
devices that sport high-temperature
thermocouple probes. However, some-
times it is not in the stars to buy an off-
the-shelf temperature-monitoring solu-
tion. The fancy LCD-laden, VOM-style
temperature meters are wonderful in
the lab, but you can’t stuff one of those
commercial marvels into that embed-
ded gadget on the bench beside it.
On the other side of that fancy com-
mercial meter, there are specialized elec-
tronic devices that are small enough to
stash in an embedded design. In addition
to being compact, many of these widely
available off-the-shelf temperature-sens-
ing devices are easy to use. A simple tem-
perature sensor that immediately comes
to mind is National Semiconductor’s
LM35, which outputs a linear 10 mV per
1°C, can operate over a wide voltage
range, draws little current, is reasonably
accurate, and, most importantly, is inex-
pensive and easily obtained. A simple
resistor and a negative power source are
all you need to reach below 0°C. The
LM35 is a great choice for noncritical
temperature measurement projects in
which the sensor isn’t exposed to temper-
atures above 150°C and below –55°C.
During a typical reflow cycle, my hot
air rework station stabilizes PCBs at
151°C and liquifies solder on the pre-
heated board at approximately 240°C.
to have to interface the thermometer of
choice to the logic within your embed-
ded design.
Recently, I was given the “opportuni-
ty” to design a simple control panel
interface that uses an RTD to monitor
the temperature within a small holding
tank. The maximum temperature the
holding tank can experience is approxi-
mately 220°C. The resolution of the tem-
perature measurements was not super
critical because the tank temperature
would be raised above a certain point and
held there for a specific amount of time.
Therefore, I set it at
±
1°C.
Basically, I wanted to be able to obtain
a relatively accurate report of the tank’s
temperature. The idea was to free the
tank from its high-cost, high-tech bench
temperature measuring equipment so
that the tank and its associated mechan-
ics and electronics could be tested and
monitored in the field. To make things
interesting, the small control panel had
to include a virtual dial set that allows
the maximum and minimum tank
temperatures to be set dynamically.
THERMOMETER DESIGN
Mechanical things in motion inside
the holding tank precluded me from
using any of the fancy prepackaged
RTD or thermocouple elements. (I
can’t tell you what’s going on inside
the tank without having to liquidate
you.) Because the tank heats and cools
gradually, the fast response time of a
thermocouple is unnecessary. Also,
the tank isn’t submitted to excessive
abuse because it is enclosed inside a
protective fiberglass covering.
Considering the aforementioned
environmental and operational factors,
Adaptable Temperature
Measurement System
APPLIED PCs
by Fred Eady
My tabletop rework station is by no
means an embedded device. A bevy of
thermocouples monitor the air tem-
perature delivered to the target PCB
and its associated electronics, which is
relayed to the rework station’s micro-
controller-based controller. The rework
station controller uses the thermocou-
ple data to regulate the air temperature
during the solder reflow process and to
provide a visual indicator of the heated
air via an LCD. Obviously, you can’t
use a bunch of LM35s to monitor a sol-
der reflow process. So what do you do
when you have to measure tempera-
tures above 150°C or below –55°C?
THERMOCOUPLE OR RTD?
The answer is either one. But, I’m not
going to try to make that decision for
you here. The type of thermometer you
choose depends on your application.
Resistance temperature detectors
(RTDs) cost more than thermocouples
because they are usually more accurate.
A high-quality RTD may be able to
measure up to 1000°C; thermocouples
can reach 2000°C and beyond. Another
factor to consider is the thermometer
output. Thermocouples produce voltages,
whereas RTDs produce a change in
resistance relative to temperature. No
matter which way you go, you’re going
Fred recently designed a PIC18F452-based temperature measurement system for a small
holding tank. Toss in a pair of Promi-SD202 Bluetooth modules, and you have wireless control.
Photo 1—
This is a leaded thin film PRTD. You can also
get PRTDs in SMD and wire-wound configurations.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
61
I decided to use a thin film RTD to
take the holding tank’s temperature
from the outside (see Photo 1). Some of
the other good things that follow the
RTD decision are better accuracy and
long-term stability. In addition to being
housed in a protective casing, the
holding tank is insulated. Mark, my
machine-head buddy, designed and fab-
ricated a custom thermally potted bolt-
on mount to thermally attach the RTD
assembly to a strategic point on the
tank’s outer wall under the insulation.
Now let’s focus on circuitry to convert
the holding tank’s RTD resistance to
something that makes sense. The first
order of business is to choose an appro-
priate RTD. I chose a 1000-
Ω
platinum
RTD (PRTD) from RTD Company.
Although 100-
Ω
PRTDs are the standard,
you’ll see that there are a number of good
reasons for choosing a 1000-
Ω
PRTD.
The 650P6B204 is a standardized
1000-
Ω
PRTD with a temperature
coefficient of resistance (TCR) of
0.00385
Ω
/
Ω
/°C. Therefore, the PRTD
will change its average resistance by the
TCR value for every unit of tempera-
ture change between the freezing and
boiling points of water. As the TCR
value increases, the change in resistance
grows larger versus a given change in
temperature. The math behind this
stems from the repeatability and lineari-
ty versus temperature change exhibited
by the platinum that makes up a PRTD.
TCR is computed in the following way:
[1]
R
100
is the resistance of the sensor at
100°C, and R
0
is the resistance of the
PRTD at 0°C.
Plug in 1000
Ω
for R
0
and 1385
Ω
for
R
100
, and you end up with 0.00385 as the
chosen PRTD’s TCR. If you’re wonder-
ing where the 1385
Ω
value comes from,
note that the selected PRTD’s properties
are based on a set of standard curves that
define the resistance versus temperature
characteristics of a 100-
Ω
platinum sen-
sor over a defined temperature range.
This set of standardized curves is called
the DIN standard. The PRTD happens to
fall into the DIN B
±
0.12% curve.
Obtaining the 100°C resistance of
PRTD was as simple as looking up the
value in the PRTD resistance-versus-
TCR
C
R
C
Ω Ω
/
/
°
(
)
−
° ×
=
R
R
0
0
100
100
temperature table, which you can find
on many Internet temperature sensor
web sites as well as in RTD Company’s
sensor guide. To get the number for the
1000-
Ω
PRTD, simply multiply the
100-
Ω
PRTD value by 10.
The temperature readings depend on
the total resistance shown to the circuit
by the PRTD and its connecting wires,
so the resistance of the PRTD con-
necting wires must be accounted for.
Fortunately, I used a 1000-
Ω
PRTD and
extremely short 22-AWG leads. The
PRTD run is less than 2
′
, which adds a
maximum of 0.0648
Ω
to the PRTD’s
total resistance. Because a current source
must feed the PRTD to produce a volt-
age that can be read by a microcon-
troller’s A/D converter, PRTD self-
heating may occur. At this point I don’t
think the overall accuracy will be greatly
affected by the length of the PRTD con-
nection run or the self-heating that
occurs within the PRTD. Some simple
math should support my intuition.
It’s clear that the 1000-
Ω
PRTD has a
TCR of 0.00385
Ω
/
Ω
/°C, which equates
to a sensitivity of 3.85
Ω
/°C. You can
compute the error with Equation 2.
[2]
where
∆
R
is equal to the sum of the
PRTD and connection wire resistanc-
es minus the PRTD resistance. When
you plug in the
∆
R
values you get the
following:
[3]
1000
3 85
+ 0.0648 1000
/ C
Ω
Ω
Ω
Ω
−
°
.
Temperature
R
ERROR
=
/ C
∆
°
3 85
.
Ω
The result is 0.016831°C of temperature
error throughout the temperature range.
My call to RTD Company’s technical
support department was not returned.
Furthermore, there is no package ther-
mal resistance information in its OEM
temperature sensor guide, so I can’t
give you a real number concerning self-
heating. However, the thermal resist-
ance of the PRTD would have to be
ridiculously high to put a dent in the
final temperature value.
HARDWARE CONNECTIONS
Now you have a pretty good idea of
how the 650P6B204 PRTD is going to
act out in public. Just for grins, I con-
nected an ohmmeter across the PRTD to
see if I could calculate the Florida room’s
temperature using the PRTD’s resistance
reading and the PRTD temperature ver-
sus the resistance table. I noted the
Florida room’s temperature at 75°F and
read 1.095 k
Ω
across the PRTD. The
closest temperature in the table that cor-
responded to the PRTD resistance read-
ing was 24°C, which is 75.2°F. Although
it’s nice that I can use a VOM to ball-
park temperature readings, and verify
that I’m actually in the ballpark as far as
the PRTD math goes, I can’t use a VOM
to take readings from the holding tank
when it’s out in the boonies.
I couldn’t get much just hanging the
PRTD leads across the input of a
microcontroller’s A/D converter. I
needed to drive the PRTD with a con-
stant current source to be able to get a
resultant voltage that represents a tem-
perature into the microcontroller’s A/D
Figure 1—
Note that I used the ADT70 op-amp as a buffer. If you really want to dial in the precision, a potentiome-
ter can be used in conjunction with the NULLA and NULLB pins to match the current being provided to the PRTD
and the reference resistor.
62
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
converter. The ADT70 PRTD condi-
tioning circuit and temperature con-
troller IC provided everything I need to
excite a PRTD and retrieve data from it.
The ADT70 is designed for 1000-
Ω
PRTDs; and, with a
±
5-V power source,
it can easily measure temperatures
between –50° and 500°C. If you don’t
need to measure below 0°C, a single 5-V
power source is all you need. If a posi-
tive supply voltage is all you’ve got, you
can still measure negative temperatures
without the need for the negative sup-
ply rail by shifting the ADT70’s instru-
mentation amplifier ground reference
using the ADT70’s on-chip uncommit-
ted op-amp and 2.5-VDC reference.
The ADT70 makes a PRTD useful by
providing a pair of nominal 1-mA cur-
rent sources to drive the remote PRTD
and a reference resistor. An integral
instrumentation amplifier uses the dif-
ference in the voltage drops across the
PRTD and reference resistor to supply
an amplified output voltage that is based
on the measured temperature. The
instrumentation amplifier is a separate
subsystem of the ADT70, which means
you still have the services of the afore-
mentioned op-amp plus the functionali-
ty of the instrumentation amplifier.
The ADT70 configuration I used is
shown in Figure 1. Note that one of the
ADT70 current sources is driving the
PRTD, while the second current source
is driving a 1-k
Ω
reference resistor. The
reference resistor, which isn’t mounted
with the PRTD, is kept near the ADT70.
For this particular application, the rea-
sons for keeping the reference resistor in-
house is to eliminate any possibility of
connection lead resistance error and to
minimize any effects temperature may
have on the reference voltage because
of the heating of the reference resistor.
By using a 1-k
Ω
PRTD, a 1-k
Ω
refer-
ence resistor, and a 49.9-k
Ω
instru-
mentation amplifier gain resistor, and
by shorting the ADT70 BIAS and
V
REFOUT
pins together, the ADT70
forms a PRTD system with the fol-
lowing transfer function:
[4]
where
∆
R
equals the PRTD resistance
V
OUT
= 1.299 mV/ C R
° × ∆
less the reference resistance.
You already know that the PRTD
sensitivity is 3.85
Ω
/°C. So, by setting
∆
R
to 3.85
Ω
, which represents a
change of 1°C, you can determine the
PRTD’s system output voltage per
1°C, which turns out to be 5 mV/°C.
Changing the value of the instrumen-
tation amplifier gain resistor can alter
the ADT70 PRTD system transfer func-
tion. Using a 49.9-k
Ω
instrumentation
amplifier gain resistor sets the ADT70’s
instrumentation amplifier gain at 1.299.
Equation 5 shows the mathematical
relationship between the instrumenta-
tion amplifier’s gain and the instrumen-
tation amplifier’s gain resistor value:
[5]
The holding tank that the PRTD is
attached to is externally heated. So, the
requirement to read temperatures below
0°C is not present at this point. There are
a couple of ways to read temperatures
below 0°C if you have to. The first
solution is to simply use a
±
5-V supply.
The negative voltage rail (–V
S
) must be
at least –1 V for the ADT70 to be able
to resolve temperatures below 0°C.
Instrumentation amplifier gain =
1.299
k
RESISTO
49 9
.
Ω
R
GAIN
R
R
Figure 2—
The bias voltage in this configuration is used to provide the uplift voltage for the ADT70 GND SENSE
pin through the ADT70’s op-amp.
Listing 1—
This code snippet is all you need to get the PRTD data back to the laptop.
#include <18f452.h>
#device *=16
#device ADC=10
#include <f452.h>
#use delay(clock=20000000)
#fuses
NODEBUG,HS,NOWRT,NOWDT,NOPUT,NOPROTECT,NOBROWNOUT,NOLVP,NOCPD,NOE
BTR
#use rs232(baud=57600, xmit=PIN_C6,rcv=PIN_C7)
void main()
{
int16 tanktemp;
int8 templo,temphi;
delay_us(100);
do{
read_adc(ADC_START_ONLY);
*****************************************************************
// Do other tasks here.
*****************************************************************
tanktemp = read_adc(ADC_READ_ONLY);
temphi = make8(tanktemp,1);
templo = make8(tanktemp,0);
sendchar(“T”);
sendchar(temphi);
sendchar(templo);
} while(1);
}
64
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
An alternate solution is to use the
ADT70’s GND SENSE pin. The ADT70
PRTD system I’ve described outputs a
full-range voltage level that spans from
–1 to 4 V. When the ADT70 negative
voltage rail (–V
S
) is at 0 V, it isn’t possible
for the instrumentation amplifier to gen-
erate the voltages resulting from temper-
ature readings that are less than 0°C. By
applying 1 V to the ADT70 GND SENSE
pin, you can offset the instrumentation
amplifier’s output so that the output of
the ADT70 PRTD system runs from 0 to
5 V full range. Of course, the translation
of the offset voltages to correct tempera-
If your eyes agree with my eyes, you
can assume that one tick of the 10-bit
A/D converter is equal to approximately
1°C. Now, wrap a PIC18F452 around that
A/D converter module, and you end up
with the simplified code in Listing 1. All
you have to do is read the voltage from
the ADT70’s instrumentation amplifier,
break it down into a couple of bytes, and
ture readings would be taken care of in
the computing system that is gathering
the temperature data from the ADT70.
A downside to this method is that if
you choose not to add additional major
components, you will end up consum-
ing the ADT70’s op-amp (see Figure 2).
The ADT70 PRTD system hardware I
built is shown in its entirety in Photo 2.
THERMOMETER FIRMWARE
From what I’ve shown you so far,
you can see that the ADT70 allows for
easy scaling and manipulation of the
PRTD temperature data to suit your
system needs. My goal was to keep the
PRTD system as simple as possible and
use compute power to convert the data
into logical and human form.
Assuming you don’t have to read
temperatures below 0°C, the ADT70’s
5-mV/°C output plays almost perfectly
into the hands of any 10-bit A/D con-
verter. If everything is perfect, a 10-bit
A/D module has a resolution of
0.0048 V per step with a 5-V reference.
Tap on the meter face. That sure looks
like 5 mV to me. How about you?
Photo 2—
It’s always better to have more pads than
fewer pads. This is a shot of the test fixture. I cleaned
this up in the final version.
Photo 3—
This shot shows the tank controller in Idle
mode. The PRTD is just hanging out in the open on the
Florida room bench. I dialed in some arbitrary values
and selected some heating elements to give you a feel
for what the panel looks like to the tank technician.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
65
send it down the line unaltered.
At the beginning of each cycle, the code
in Listing 1 initially allows some time for
the PIC’s A/D sampling capacitor to com-
pletely acquire the voltage to be sampled.
The
read_adc(ADC_START_ONLY) state-
ment kicks off the PIC’s A/D module and
the conversion begins. There are other
tasks being performed that are not related
to the temperature data performed in the
meantime. After all of the assigned
tasks are finished for this cycle, the
read_adc(ADC_READ_ONLY) statement
retrieves the temperature data from the
PIC’s A/D buffer. The 10 bits of tempera-
ture data are then broken down into
2 bytes and sent along to the remote host
preceded by an ASCII “T” to let the host
software know what the data is for.
SIMPLE SOFTWARE
The temperature data from the ADT70
that was processed by the PIC18F452 is
passed via a serial connection to a laptop
computer that travels with the tank tech-
nician. Although the temperature is not
precisely controlled, it is the star of the
show. Using the data from the PRTD and
ADT70 to generate heating and cooling
cycles, the PIC controls a number of
heating elements that are built into the
tank’s frame. In addition to doing temper-
ature control duty, the PIC is also respon-
sible for activating valves and relays in
various timed sequences. There’s no rock-
et science involved. The I/O is straight-
forward, and the PIC’s internal timers
generate the timing cycles.
The control of the tank system was
a bit too complex to be implemented
using a standard character terminal
interface. So, I decided it was time to
go with something that emulated a
physical control panel. Again, I want-
ed to keep it as simple as possible.
I chose Visual Basic as the thermometer
software programming language because
it is easy to whip up simple, nice-looking
graphical programs. Although Visual Basic
comes with a serial interface component,
it doesn’t work too well. So, I went to
MarshallSoft Computing and obtained its
serial communications library for Visual
Basic. Problem solved.
Next, I attempted to see how difficult it
would be to build graphical knobs and
switches that I could use in the Visual
Basic GUI. After an hour or so of explor-
ing the ’Net for ideas, I came across a
company called Century Soar Technology.
It was immediately obvious that I could
use its graphical knob software to save
time and spare myself the grief of putting
together the graphic objects from scratch.
The results of mixing MarshallSoft’s
Visual Basic communications library
code and the CST knob and LED objects
are shown in Photo 3. Integrating the
knobs, displays, and LEDs was really
easy. Each object is defined with Visual
Basic properties that describe its color,
value, position, and so forth. For
Listing 2—
This is tight code.
Private Sub looptimeknob_Turn()
looptimeled.Value = looptimeknob.Value
End Sub
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
67
instance, the two-digit yellow display
object above the Loop knob (defined as
looptimeknob) is defined logically as
looptimeled. The Loop knob is defined
to present a value between zero and 60
in a single turn. All I had to do to see the
value of the Loop knob was pass the
value of
looptimeknob to the loopti-
meled object. Listing 2 shows the ultra-
complicated code I wrote to do this.
All of the yellow displays above the
knobs are paired with the knobs below
them. They work together in this man-
ner to give a visual indication of the
value that has been dialed in. The dialed
in values, which are subsequently sent
to the PIC, are used to adjust timing
intervals and control the temperature of
PROJECT FILES
To download the code, go to ftp.circuit
cellar.com/pub/Circuit_Cellar/2004/167.
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
SOURCES
ADT70 PRTD Conditioning circuit
and temperature controller
Analog Devices, Inc.
www.analogdevices.com
Promi-SD202
Lemos International
www.lemosint.com
MPLAB ICD 2 and PIC18F452
Microchip Technology, Inc.
www.microchip.com
650P6B204 PRTD
RTD Company
www.rtdcompany.com
the contents of the holding tank.
The MarshallSoft serial communica-
tions code made getting the data from
the PIC’s serial port a snap as well. I’m
particularly interested in the section of
Listing 3 that executes when an ASCII
“T” is received by the laptop. As you can
see in the Visual Basic code snippet, all I
had to do was recombine the 2 bytes that
represented the 10-bit temperature value
that was taken from the PIC’s A/D con-
verter and pass the value to the
tem-
pdisplay LED object, which is the
group of large red LEDs in Photo 3.
Sending settings to the PIC is just as
easy. I used the same scheme to send
data from the laptop to the PIC (see
Listing 4). Each data identification
Listing 4—
All of the statements that begin with
Sio
are MarshallSoft calls. In this code snippet, I’m send-
ing the values that were dialed into the GUI knobs down to the PIC.
Private Sub settimebtn_Click()
Dim cycletimehigh As Integer
Dim cycletimelow As Integer
Code = SioPutc(ThePort, Asc(“Z”))
Code = SioPutc(ThePort, holdtimeknob.Value)
Code = SioPutc(ThePort, Asc(“C”))
Code = SioPutc(ThePort, cycletimeknob.Value)
Code = SioPutc(ThePort, Asc(“L”))
Code = SioPutc(ThePort, looptimeknob.Value)
Code = SioPutc(ThePort, Asc(“D”))
Code = SioPutc(ThePort, heatsoakknob.Value)
Code = SioPutc(ThePort, Asc(“X”))
Code = SioPutc(ThePort, hightempknob.Value)
Code = SioPutc(ThePort, Asc(“Y”))
Code = SioPutc(ThePort, lowtempknob.Value)
End Sub
Listing 3—
The status values are used to illuminate LEDs in the Visual Basic GUI. Writing a value to an
LED is easier here than it is with real hardware and firmware.
Sub GetIncoming()
Dim charin As Integer
Dim arghigh As Integer
Dim arglow As Integer
Dim fullarg As Integer
Dim I As Integer
charin = SioGetc(ThePort)
Select Case charin
Case Asc(“W”)
holdstatusled.Value = SioGetc(ThePort)
Case Asc(“R”)
relaystatusled.Value = SioGetc(ThePort)
Case Asc(“H”)
heatmodestatus.Value = SioGetc(ThePort)
Case Asc(“T”)
arghigh = SioGetc(ThePort)
arglow = SioGetc(ThePort)
fullarg = (arghigh * 256) + arglow
tempdisplay.Value = fullarg
End Select
End Sub
ASCII character is followed by data
from a knob or switch object.
CHILLING OUT
To make things really nice for the
field technician, I decided to add a pair
of Initium Promi-SD202 Bluetooth mod-
ules to the mix. He can simply walk
within a few feet of the tank and com-
municate with the PIC-based tank con-
troller without doing anything but firing
up his laptop.
Another reason for choosing the
PIC18F452 for the controller is the
fact that I can place an in-circuit seri-
al programming (ICSP) port on the
tank controller. The tank tech can use
his laptop in conjunction with a hock-
ey puck (MPLAB ICD2) to perform
any firmware upgrades and repairs.
Before releasing the tank to the field
tech, I tested the functionality of the
PRTD thermometer system. It tracked
temperature readings degree for degree
right along with the lab temperature
monitor. My simple little temperature
measurement system isn’t complicat-
ed. It’s embedded.
I
68
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
A
s engineers, we design to monitor
temperature. We design to provide
access and prevent unauthorized access.
We design to weigh vehicles. We design
to move robotic arms. You name it, we
design it. Why? To improve life as we
know it. That’s our job.
And just how is this accomplished?
The design process starts with a task
for automation, which requires a trans-
ducer to be monitored, controlled, or
both. You’re given a particular sensor or
actuator that has been chosen for the
task, or you need to investigate what’s
out there and select your own technolo-
gy. Sometimes you’re required to use a
specific microcontroller; other times
you’re free to choose your favorite. No
doubt the one you use requires some
kind of signal conditioning to allow for
interfacing between the microcontroller
and the sensor or actuator.
Engineers have been trying to make
peace between digital and analog sig-
nals for a long time now. Depending
on where your roots are, you can
demonstrate the importance of both.
And let’s face it, neither one is likely
to go away any time soon.
Finally, this design may be a small
tem configuration steps. In addition, it
supports a general transducer data, con-
trol, timing, configuration, and calibration
model. To help achieve this, each trans-
ducer must carry its own transducer
electronic datasheet (TEDS).
IEEE 1451
Most transducer (both sensor and actu-
ator) manufacturers cannot possibly pro-
vide specialized interfaces for every net-
working scheme in use today, not to men-
tion those that have yet to be conceived.
IEEE 1451 is an attempt to separate the
need for network interfacing from the
transducer itself by standardizing an inter-
face for all transducers independent of
the network it will be used on.
Figure 2 shows the IEEE 1451 family
broken down into five substandards
(1451.1 through 1451.5). The first two
members have been adopted; the oth-
ers are works in progress. Although
new transducer technologies are easily
cast using the early substandards, the
use of a single networked interface
handling multiple transducers or fitting
the existing transducers into the
scheme of things requires additional
work (substandards).
Smart Sensor Design
FROM THE BENCH by Jeff
Bachiochi
part of a bigger picture that requires com-
munication with a higher authority.
Such communication could be one-to-
one (master/slave) or networked amongst
a number of others (multimaster/multi-
slave). Your smart sensor design allows
you to monitor and control a device at a
level that removes all of the underlying
complications involved in getting the job
done. In a way, this is distributed control
at its most basic level.
ORGANIZATION
On the design side, there are numerous
variables in the mix. Because Figure 1
shows a rather simplistic view of a
design, it fails to illustrate the multi-
tude of different bus communication
mediums, the plethora of potential
microcontrollers, and the breadth of
potential sensor and actuator choices.
A change in any area will affect the
design. Not only would a change alter
the physical design, it would modify the
code that pulls it all together. This
could be as simple as using a thermo-
couple with a different temperature
coefficient table or as radical as using
different sensor technology that requires
a signal conditioner redesign. A change
in bus protocol may even require a
totally different microcontroller.
Since the mid-1990s, the transducer
community has been batting these prob-
lems around in workshops on smart trans-
ducer interface standards (IEEE 1451). The
main goal for 1451 has been to develop
independent network and transducer
interfaces. This allows transducers to be
replaced (or moved) with minimum effort,
and it eliminates error-prone, manual sys-
Designing smart sensors can be tricky. Back in the mid-1990s, members of the transducer
community believed that the IEEE 1451 standard would make things easier. Has it? Take
note of Jeff’s opinion before starting your next smart sensor design.
Figure 1—
A smart sensor interfaces to the real world
through sensors and actuators to some higher authori-
ty located at the end of a communications channel.
Microcontroller
Signal
conditioning
Sensor
or
actuator
Real
world
Bus
Property
Bits
Allowable range
Manufacturer ID
14
17–16381
Model number
15
0–32767
Version letter
5
A–Z (data type Chr5)
Version number 6
0–63
Serial number
24
0–16777215
Table 1—
The first item found in the Transducer
Electronic Data Sheet structure is the basic TEDS, a
64-bit string documenting the manufacturing informa-
tion on the sensor/actuator.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
69
The TEDS, which allows the NCAP
to figure out how to deal with the
transducer, is made up of two required
machine-readable data blocks and up
to six additional optional blocks (most
of which you can read). Each TEDS
structure contains a length byte and
checksum (for error protection) not
shown in Figure 3.
The basic TEDS, which is the first
required data block, describes the STIM
and contains items like manufacturer
ID, version, and serial number data (see
Table 1). The second required TEDS data
block, standard TEDS, begins with the
template ID, which defines the format
for this type of transducer (see Table 2).
Each template can have slightly dif-
ferent parameters based on a case num-
ber following the ID (see Table 3). All
functional data is defined here for this
particular transducer. If this STIM has
multiple transducer channels, a stan-
dard TEDS is included for each channel.
DOT 3
IEEE 1451.3 defines a multidrop local
bus interface allowing many transducers
to be attached and identified through a
network communications channel by the
transducer bus controller (TBC). After
it is identified and configured, a TBIM
communication channel (of higher band-
width) would be used to pass data and
trigger or synchronize functions in a
tier 1 setup. Additional optional com-
munication paths would increase band-
width by creating an other communica-
tion channel for data (tier 2),
synchronization (tier 3),
and triggers (tier 4).
Each TBIM has an 80-bit
universal unique identifier
(UUID) that distinguishes
it from all others. The
TBC uses the network
communication channel to
search for TBIMs on its
bus. The TBC can then use
this UUID to interrogate
a single TBIM and read
the TEDS for that unit.
DOT 4
IEEE 1451.4 creates a
way in which older sen-
sors can be retrofitted
with a TEDS. Analog
transducers can continue to be useful if
a digital storage device is added so they
can be identified automatically. This
substandard identifies the ways in
which a TEDS can be added to various
analog sensors either via the same ana-
log connections (class 1) or through an
additional digital interface (class 2).
The digital portion of the specification
is based on Maxim’s 1-Wire devices.
These low-cost devices allow manu-
facturers to add a TEDS to the trans-
ducer with a minimum cost.
DOT 5
Wireless transducers are the newest
DOT 1
Substandard 1451.1
could be described as a
black box because there is
nothing in the standard
that prevents an all-in-one
configuration (see Figure 1).
However, substandard
1451.1 describes a network
connection to a module
known as a network-capa-
ble application processor
(NCAP). The NCAP is
responsible for interfacing
a network to a transducer
independent interface (TII).
On the network side, the
NCAP contains an object
module mapped into a
network communications
stack, thereby keeping the network
interface hardware independent and not
part of the standard. At the other end of
the NCAP, the TII is a digital 10-signal
interface containing power and ground
that’s based on synchronous serial com-
munications. The TII interface separates
the NCAP from the smart transducer
interface module (STIM). The only hard
interface defined in the NCAP is the
TII. The IEEE 1451 standard deals with
what happens between the two and not
how you choose to implement it.
DOT 2
The TII is the heart of the 1451 stan-
dard. In theory, this interface is where
any sensor or actuator can be attached
without regard for configuration. The
key to 1451.2 is the predefined TII and
the TEDS. The TII is used to transfer
sensor/actuator data between the
NCAP and the STIM by allowing the
NCAP to read a digital datasheet defin-
ing the specifics of the transducer from
the transducer itself.
Network-
capable
application
processor
(NCAP)
Smart
transducer
interface
module
(STIM)
TEDS
Digital
transducer
Network-
capable
application
processor
(NCAP)
Transducer
bus
controller
(TBC)
1451.5
Wireless
Transducer bus
interface module (TBIM)
Channel TEDS
Transducer bus
interface module (TBIM)
Channel TEDS
Digital
transducer
Analog
transducer
1451.4
1451.1
1451.2
1451.3
Bus
Bus
Basic TEDS
(64 bits)
Standard TEDS
Template ID = 25 to 39
Basic TEDS
(64 bits)
Standard TEDS
Template ID = 25 to 39
Calibration TEDS
Template ID = 40 to 42
Optional TEDS
Figure 3a—
A TEDS must at least consist of a basic
and standard TEDS block.
b—
It may have additional
blocks in support of the standard TEDS as well as
optional TEDS information blocks.
Figure 2—
The 1451 substandards define how a transducer plays well with others and
allows older technology to coexist with new transducers designed specifically to take
advantage of the 1451 standard.
a)
b)
ID Number Name of template
25
Accelerometer and force
26
Charge amplifier (w/ attached accelerometer)
27
Microphone with built-in preamp
28
Microphone preamplifiers
(w/ attached microphone)
29
Microphones capacitive
31
Current loop output sensors
32
Resistance sensors
33
Bridge sensors
34
LVDT and RVDT sensors
35
Strain gauge
36
Thermocouple
37
RTDs
38
Thermistor
39
Potentiometric voltage dvider
40
Calibration table
41
Calibration curve (polynomial)
42
Frequency response table
Table 2—
This list contains template ID numbers and
their associated descriptions. The template ID number
is the first 8 bits of a standard TEDS. This identifies the
transducer type and determines what specific informa-
tion follows in the standard TEDS. IDs 25 through 39
are transducer templates, and 40 through 42 are cali-
bration templates.
70
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
additions to this standard (IEEE 1451.5).
The idea is to accommodate various
existing wireless technologies and ease
the burden for users, transducer manu-
facturers, and system integrators.
STATE OF THINGS
Have we gone overboard in our effort to
make everyone happy? Should we write a
standard around what we’ve done in the
past? If you look back through history,
you’ll find that this has been done over
and over again. Most digital cell phones
also handle analog. Most color TVs also
receive black and white (and HDTV will
accommodate its predecessors.)
From what I can see of IEEE 1451, a
simple idea has turned into a nightmare
of specialized interfaces. Every addition
to the standard requires changes to the
NCAP. Unless you want to wait for
finalization, the NCAP you design today
using 1451.1 and 1451.2 will not work
with the later substandards. It’s been
approximately five years since 1451.1
and 1451.2 were accepted, and it looks
like the remaining substandards will
be in committee for some time.
Refer to the IEEE web site (www.ieee.
org) for more about 1451. You can pur-
chase the 1451 standards there too. At
this time, it appears that only 1451.1
and 1451.2 are available. They cost
approximately $100 each.
I
———“IEEE P1451.3, A Proposed
Standard for a Smart Transducer
Interface for Sensors and Actuators—
Digital Communication Protocols and
Transducer Electronic Data Sheet
(TEDS) Formats for Distributed
Multidrop Systems.”
———“IEEE P1451.4, A Proposed
Standard for a Smart Transducer
Interface for Sensors and Actuators—
Mixed-Mode Communication
Protocols and Transducer Electronic
Data Sheet (TEDS) Format.”
———“IEEE P1451.5, A Proposed
Standard for a Smart Transducer
Interface for Sensors and Actuators—
Wireless Communication Protocols
and Transducer Electronic Data Sheet
(TEDS) Format.”
Microchip Technology, Inc., “The
PICmicro MCU as an IEEE 1451.2
Compatible Smart Transducer Interface
Module (STIM),” DS00214A, 2000.
Author’s note: A few manufacturers
have products that adhere to the
IEEE 1451 standard. Endevco carries
an accelerometer (www.endevco.com).
Bruel & Kjaer has a microphone and
acceleromete (www.bksv.com).
Honeywell Sensotec carries pressure,
load cell, accelerometer, torque, and
LVDT (www.sensotec.com).
RESOURCES
IEEE 1451 over IP (and other implemen-
tations), sourceforge.net/projects/
open1451.
IEEE, Inc., “IEEE 1451.1-1999, Standard
for a Smart Transducer Interface for
Sensors and Actuators—Network
Capable Application Processor
(NCAP) Information Model,” 2000.
———“IEEE 1451.2-1997, Standard
for a Smart Transducer Interface for
Sensors and Actuators—Transducer to
Microprocessor Communication
Protocols and Transducer Electronic
Data Sheet (TEDS) Formats,” 1997.
Table 3—
The makeup of the standard TEDS is determined by the template ID. Not only does each template ID have its own standard TEDS format, but as you can see from
this example of a high-voltage output transducer, individual case selects within the standard TEDS further define individual properties within each.
Select
Property
Description Access
Bits
Data
type
and
range
Units
–
Template
Template
ID –
8
Integer
(ID
=
30)
–
–
%ElecSigType
Electrical
signal
type
ID
–
Assign
=
0,
“Voltage
Sensor”
–
Select
case:
Selects
type
of
physical
measurement
(units)
6
Select
case
–
Case
0–45
%MinPhysVal
Minimum
physical
value
CAL
32
Single
precision
FP
Various
%MaxPhysVal
Maximum
physical
value
CAL
32
Single
precision
FP
Various
Select
case:
Selects
full-scale
electrical
value
precision
2
Select
case
–
Case
0
%MinElecVal
Minimum
voltage
output
CAL
–
Assign
=
0.0
Volts
%MaxElecVal
Maximum
voltage
output
CAL
–
Assign
=
10.0 Volts
Case
1
%MinElecVal
Minimum
voltage
output
CAL
–
Assign
=
–10.0
Volts
%MaxElecVal
Maximum
voltage
output
CAL
–
Assign
=
10.0 Volts
Case 2
%MinElecVal
Minimum voltage output
CAL
11
Constant resolution (–20.5 to 20.4, step 0.02)
Volts
%MaxElecVal
Maximum voltage output
CAL
11
Constant resolution (–20.5 to 20.4, step 0.02)
Volts
Case
3
%MinElecVal
Minimum
voltage
output
CAL
32
Single
precision
FP
Volts
%MaxElecVal
Maximum
voltage
output
CAL
32
Single
precision
FP
Volts
–
%MapMeth
Mapping
method
ID
–
Assign=0,
“Linear”
–
–
%ACDCCoupling
AC
or
DC
coupling ID
1
DC
or
AC
–
–
%SensorImped
Sensor output impedance
ID
12
Constant relative resolution (1 to 1.1M, ±17%)
Ohms
–
%RespTime
Response
time
ID
6
Constant
relative
resolution
(1E-6
to
7.9,
±15%) Seconds
Select
case:
Selects
inclusion
of
excitation/power
requirements
1
Select
case
–
Case
0
(none) –
No
excitation/power
source
–
–
–
–
Case 1
%ExciteAmplNom
Power supply level, nominal
ID
9
Constant resolution (0.1–51.1, step 0.1)
Volts
(specify supply)
%ExciteAmplMin
Power supply level, minimum
ID
9
Constant resolution (0.1–51.1, step 0.1)
Volts
%ExciteAmplMax
Power supply level, maximum
ID
9
Constant resolution (0.1 to 51.1, step 0.1)
Volts
%ExciteType
Power
supply
level,
type
ID
2
DC,
polarized
DC,
or
AC
–
%ExciteCurrentDraw
Maximum current at nominal power
ID
6
Constant relative resolution (1E-6 to 1.6, ±13%)
Amps
–
%CalDate
Calibration
date
CAL
16
Date
–
–
%CalInitials
Calibration
initials
CAL
15
Three
5-bit
characters
–
–
%CalPeriod
Calibration
period
CAL
12
Unsigned
integer
Days
–
%MeasID
Measurement
location
ID USR
11
Unsigned
integer
–
Jeff Bachiochi (pronounced BAH-key-
AH-key) has been writing for
Circuit
Cellar since 1988. His background
includes product design and manufac-
turing. He may be reached at
jeff.bachiochi@circuitcellar.com.
all the peripherals you would ever need.
Some of the more common ones, which
are available as part of the tools, include:
a UART, timer, parallel I/O (PIO), serial
peripheral interface (SPI), direct memory
access (DMA), memory interfaces,
Ethernet port, and interface to user logic.
The other more sophisticated devices are
available as licensed cores. Devices such
as encryption and FFT transforms can be
included inside the device.
And last but not least, you can choose
from several families of FPGA devices
to meet your speed, cost, and packaging
requirements. Refer to the Resources
section at the end of this article for
links to information about a wide range
of development systems.
72
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
E
xchanging gifts during the holiday
season is common in many parts of the
world. Did you receive any gifts last win-
ter? Were any of them exactly what you
wanted? Well, in any case, I would like to
talk about the perfect microprocessor for
your next project. Altera’s Nios has the
exact number and type of peripherals you
need. It also has all the computing power
you require along with custom instruc-
tions tailored to you and your applica-
tion. Memory? Well, of course it has the
proper amount and type. Speed? Certainly
it’s just as fast as your next application
requires. Whoa! Time to insert the low-
pass marketing filter, you say. All of this
can’t be true. What’s the catch?
Well, I recently completed a design
Designing with the Nios (Part 1)
Is the Nios the next major development in embedded system design? George is sold on its
applicability; so much so, he used it to design a second-order, closed-loop servo control.
using the Nios. What Altera has accom-
plished is to put an ARM CPU into a
FPGA device. The CPU is entirely IP,
which means you can tailor the features
to meet your requirements. The line
between CPU and peripherals has
become transparent because there is a
host of common devices that you can
build into the CPU. In addition, support
is provided for inclusion of your cus-
tom/proprietary modules.
You can select the 16- or 32-bit CPU,
external bus size, hardware or software
multiply, instruction queue size, big or
little endian, internal stack support, and
custom instructions. The memory can
be internal or external to the FPGA.
The Nios peripheral library consists of
FEATURE ARTICLE
by George Martin
Second-Order, Closed-Loop Servo Control
Figure 1—
This is what your design will look like at the top-most level. These pins will become the pins on the gate array.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
73
and encoder. Second, the
control loop should oper-
ate at a minimum of 20
MHz. Third, the system
should be field-reconfig-
urable. Fourth, the sys-
tem should have one seri-
al port and one parallel
for customer interface.
Fifth, the system should
have one serial port
debug interface and a 5-V
power source. Sixth, the
system needs to operate
between 0° and 70°C (an
inside environment but
no A/C). Seventh, the
system might need an
Ethernet interface. (The
market will let you know.) Eighth, the
system should have a 12-bit D/A convert-
er to interface to the servo amp. Ninth,
the system should interface to quadrature
encoder input. And tenth, we have a
show to make in nine months; it must
be done by then or else forget about it.
Does this sound familiar? Scary, isn’t
it? But it’s more like the real world. And
You are wondering
about the software. Well,
the development kits
include the following:
GNU C compiler (GCC)
and GNU C++ compiler
(g++); GNU debugger
(GDB) source and assem-
bly-level debugger; GNU
assembler (GAS); GNU
linker (LD); Insight GUI
for GNU debugger; GNU
software code profiler
(GPROF); and Nios proces-
sor-specific binary utilities.
Well, did I stretch the
truth? Is this the next
major advance in embed-
ded system design, or is it
just the latest twist and turn leading
nowhere? In this two-part series, I’ll
take you through a system design and
let you draw your own conclusions.
SERVO CONTROL
What to design? I wanted to select a
design complicated enough to blow
your socks off. How about a second-
order, closed-loop servo control? I’ll do a
single axis and let you add additional
axes to meet your specific requirements.
Let’s begin with a list of system
requirements. I just had a meeting with
marketing and this is what came out of
that get-together: First, the component
costs $50, including the PCB for the con-
trol portion less the servo amp, motor,
Photo 1—
The features of the CPU are defined from the main control screen, which is used for
configuring your own custom processor.
74
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
this article, so I won’t go into great
detail about the control system. I hope
to provide enough guidance so you can
as a responsible engineer, you’d proba-
bly say yes to this request. The
System-on-a-Chip is the main point of
take what’s presented and run with it.
The development tools basically
consist of QuartusII, SOPC Builder,
Figure 2—
This is one axis of motion control: the classic position register and target register design. You can also see the target register, position register/counter, AQUAB inter-
face, and an error-generation function.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
75
NIOS CPU
Let’s use the SOPC builder to create
a Nios CPU. The SOPC builder is a
graphical interface that lets you select
features for the CPU and peripherals.
When I went to select the Nios
processor, I noticed you could also
pick an 8051, Z80, or 6811. What’s
the world coming to? A word of cau-
tion: these are not free devices; they
require some sort of licensing.
Take a look at Photo 1 to see what
the SPOC builder interface has to
offer. The Systems Contents tab is
selected. Only a few of the compo-
nents are visible in the left window.
In the main window, you can see that
I targeted this design for an ACEX1K
device with a 20-MHz clock frequen-
cy. Also, notice the following mod-
ules: Nios CPU, tri-state bridge,
SRAM interface, UART0, UART1,
and a C++ compiler. Quartus is the
tool (QuartusII V 4.0 is the latest) that
actually converts your design to FPGA
configuration data. SOPC Builder pulls
together the CPU and peripherals that
you select for your system. And the C
compilers and assemblers generate
code that runs on your specific device.
DEVELOPMENT OPTIONS
Altera offers development systems with
a prototyping board and software tools for
$995. Let me also add that Altera has
been extremely aggressive with its pric-
ing. I’ve seen discounts on this system at
seminars. So, ask Altera yourself before
you write this number in your budget.
Altera offers a free student system
and a free ’Net-based QuartusII design
tool. (I haven’t used it so I don’t know
if there is a turnaround time penalty.)
So, it looks like Altera has you covered.
I started in Quartus by creating a
project in which I generated a
schematic called TopLevelPins (see
Figure 1). Don’t you like that name?
Very descriptive. I’ve seen FPGA
designs that actually hide the device
pinouts, so you have to spend hours
looking for them. It’s interesting to
note that Altera does not select page
sizes such as A, B, C, and D. It has
you place symbols and then size for the
printer and paper size available. It’s a
little odd at first, but it saves time over
the life of the project. Also note that
Altera refers to this file as a schematic
or block diagram type. The extension
is bdf. The movement is away from
the detailed gate placement toward
selecting larger blocks from a list. Let
the FPGA compiler edit out what
isn’t used. On this top level, I placed a
title block to identify the document.
Figure 3—
The encoder signals A and B are clocked into the logic and output signals UP-DN and CNT-EN are generated as outputs.
76
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
the position register, zero the
target register, and output
LEDs) to indicate status.
I added a timer module
because there is probably a
real-time requirement in the
design. The timer operation I
selected is for free running.
The software shows how to
derive timers without inter-
rupts from such a module.
I locked the RAM at loca-
tion 0x000000, the peripher-
als above the RAM, and the
flash memory at location 0x00100000.
The system automatically assigns
these locations. The Generate button
at the bottom of the window is the
last step.
I hope you can see how straightfor-
ward it was to generate a custom CPU.
This particular first pass does not meet
all of the requirements. But I wanted to
show you the process and then explain
how easy it is to handle changes. Also,
it’s advisable to get a reading on the
number of logic elements.
MOVING ON
The basic system design I had in
mind included a position register, a tar-
get register, encoder inputs, A/D out-
puts, and some sort of velocity feed-
back. Well, in the time it took to draw
the block diagram I could have designed
the FPGA hardware. This is a hierar-
chal design. The main block for each
axis contains an AQUADB block and
an error-generation block (see Figure 2).
Here is a hint as to what took place.
I designed one axis and then made a
component out of it. I placed that
component in the design once for
every axis I required.
The AQUADB block reads the A and
B encoder inputs and generates an Up
or Down signal along with a Count
Enable signal (see Figure 3). The CPU
sets the target register (32 bits), and
that’s the destination I wanted the
motion system to achieve. The posi-
tion register (32 bits) is a counter that
counts up or down as driven by the
AQUADB block (see Table 1).
The error-generation block (32 bits)
takes the difference between the posi-
tion and the target. I assumed I had a
12-bit A/D converter to drive the ana-
log portion of the design. If the error is
larger than 11 bits (2047) or less than
–11 bits (–2047), you need to limit the
difference to those numbers. So, a dif-
ference of more than 2047 counts will
have an A/D output of 2047 counts.
Timer0, SetPos PIO, SetTgt PIO,
SetCtrl PIO, ReadPOS PIO, ReadStatus
PIO, and flash memory interface.
The More Nios Settings tab lets you
further define the CPU as a 32-bit unit
with a 20-bit external address bus and
16-bit external memory bus. Because I
was building a motion system, I sus-
pected I’d need CPU multiplies on the
fast side. So, I selected hardware support
in the FPGA for multiplies. This used
more gates but executed faster. I select-
ed modules that matched the designs for
the development boards for the SRAM
and flash memory interfaces. I had used
them before, and they worked just fine.
At this point, I ignored the detailed
settings for the interrupt vectors,
restart vector, vector tables, and other
such entries.
The UARTs have a fixed data rate of
38,400 bps and 8N1. You have the
option of making these parameters
fixed (less FPGA resources) or variable
(more resources) from the CPU. Every
time you select an option on the
menu, the number of logic elements
appears at the bottom of that window.
This gives you some idea about the
consequences of your choices.
I decided on three output and two
input PIO ports for the CPU to inter-
face the motion system. The basic axis
design has a 32-bit target register set by
the CPU and a 32-bit position register
controlled by the encoder inputs. These
are both 32-bit registers that can be
set using the PIO outputs from the
CPU. I added a 32-bit input register so
the CPU could read the Position regis-
ter. I then added two 16-bit registers.
One is used for control output and one
for status input. You’ll need inputs (e.g.,
home and limits) and outputs (e.g., zero
Figure 4—
This circuit limits the error signal to the most positive and most negative values that will fix into the DAC.
It’s known as a limiter, or clipper, function.
Counting up
Counting down
S0
S1 S2 S3
S0
S1
S2
S3
0
0
0
0
0
0
0
0
1
0
0
0+
0
0
0
1
–
1
1
0
0
0
0
1
1
1
1
1
0+
1
0
1
1
–
1
1
1
1
1
1
1
1
0
1
1
1+
1
1
0
1
–
0
0
1
1
1
1
0
0
0
0
0
1+
0
1
0
0
–
0
0
0
0
0
0
0
0
Table 1—
The logic equations for quadrature encoding logic generate
four counts per A-B cycle. A leads B implies up direction. B leads A
implies down counting.
generated by the Quartus system tar-
geted for the development boards as
well as peripheral test files that you
can use on your custom CPU. Figure
1 contains the Nios CPU and one axis
of motion control. I compiled this for
the ACEX1K family and it fit as
reported in Table 2.
The maximum clock frequency is
reported as 29.24 MHz, which is sus-
piciously low. When I targeted the
design for the Cyclone family of
devices, I got a maximum clock fre-
quency of 70 MHz. But I used only
3000 to 4000 of the 6000 total ele-
ments. This is overkill. I looked into
what was the longest delay path. It
was in the hardware multiply. So, I
changed that configuration from all
hardware to part hardware and part
software multiply. The design then fit
into EP1K100QC208-3 (the slowest
and least expensive). The maximum
frequency is 36 MHz.
Next month I’ll add velocity feed-
back for a second-order system and
describe the software.
I
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
77
Then, as the position nears the target and
the difference is less the 2047 counts,
the actual difference will be output to
the A/D converter.
The Altera Quartus tools have built-
in macros for common functional
blocks. In Figure 2, I used a D flip-flop
that is 32 bits wide with a synchro-
nous load and clear for the target reg-
ister. I also used a macro for the 32-bit
up/down counter with count enable
and synchronous load and clear.
In Figure 4, I used a macro for the
32-bit difference function and macros
for the limit comparisons. So, if the
error is within
±
11 bits, the error
amount is passed through the mux. If
the error amount is greater than 11 bits,
the mux outputs the 11-bit limit. And
it’s the same with the –11-bit limit.
As you can see, I started out with a
32-bit design. That’s a lot of traveling:
2
31
in either up or down counts. That’s
2,147,483,648 counts, in either direc-
tion. I probably only need 24 bits 2
23
,
or 8,388,608 counts in either direc-
tion. It would be easy to edit the Altera
macros and select 24 bits instead of 32.
Another thing that’s going to happen is
that the output from Figure 2 is 32 bits,
but I’m going to hook up to a 12-bit
A/D converter. So, some bits will go
nowhere. The tools will start ripping
out unused logic. I expect Err[31..0]
will be reduced to Err[11..0], and
Err[31..12] will be removed. If that’s
the case, the mux driving Err[31..12]
also will be reduced, and the process
will continue back till it encounters
gates that are needed.
Another important note: this design
is synchronous. The position counter
counts one count every clock. The
position output to the diff and the diff
to the limit checking and mux must
George Martin began his career in the
aerospace industry in 1969. After five
years at a real job, he set out on his
own and cofounded a design and
manufacturing firm (www.embed-
ded-designer.com). George is a char-
ter member of the Ciarcia Design
Works Team. He’s currently working
on a mobile communications system
for the military. You can reach him at
george.martin@worldnet.att.net.
RESOURCES
Information about development
systems, www.parallax.com/html_
pages/products/altera/smartpacks.asp;
www.altera.com/products/devices/
nios/kits/nio-dev_kits.html; www.jop
design.com/cyclone/index.jsp; www.
cepdinc.com/altera/cas10.htm; and
www.microtronix.com/products/
cycldevkit.html.
SOURCE
take place in one clock cycle. If you
use 20 MHz, it takes 50 ns to get
through all the differencing and limit
logic. This might cause a bottleneck.
If it is, I would add a register to break
up the timing. However, this would
add another 50 ns of delay to the sys-
tem. But let’s wait and see what the
timing produces.
DIRECTORY STRUCTURE
Let’s look at the project’s directory
structure. My drive looks something
like Figure 5, where CircuitCellar is
the customer, Nios2Axix is the proj-
ect, and V00-00 is the version. The
next minor version would be V00-01,
and I would copy all the files under
V00-00 to V00-01. db is Quartus stuff.
NIOS2Axis_sim is the simulation direc-
tory. NIOS_0_sdk is the software devel-
opment directory for the first Nios CPU
in the design. Yes, there could be
more than one. I told you this was
everything you could ever hope for.
The lib directory contains all of the
library files that you would link into
the C code built
specifically for
your CPU. It also
contains a version
of these files built
for debugging.
These files sup-
port functions
such a
sprinf,
getc, and putc.
The source
directory has
some source files
Circuit Cellar
Nios2Axix
V00-00
db
NIOS2Axis_sim
Nios_0_sdk
inc
lib
source
V00--01
db
NIOS2Axis_sim
Nios_0_sdk
inc
lib
source
Figure 5—
The directory structure is simple. Nios2Axis
is the project name. The V00-00 and V00-01 directo-
ries are different versions of the design. Each version
has its own software development kit (SDK) directory.
Description
Result
Flow status
Successful: Tue. Oct. 14 11:16:58 2003
Compiler setting name
TopLevelPins
Top-level entity name
TopLevelPins
Family
ACEX1K
Total logic elements
3603/4992 (72%)
Total pins
78/147 (53%)
Total memory bits
18,304/49,152 (37%)
Total PLLs
0/ 1 (0%)
Device
EP1K100QC208-1
Table 2—
The Quartus compiler summary report provides an overview of how the
design fits into the selected device. More detail is contained in the complete report.
78
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
T
he good news is that wireless
options continue to proliferate at an
amazing pace. After all, every radio
scheme is designed—at least in princi-
ple—to not interfere with, yet tolerate
interference from, others. Thus, the
emergence of ever more wireless stan-
dards is not an unexpected outcome,
nor is it necessarily an unwelcome one.
This more-the-merrier mentality is a
contrast from the wired world, where
legacy connectors and cables keep an
iron (er, copper) grip on their territory,
able to repulse attack from all but the
most innovative and persistent chal-
lengers. Witness the long march to the
pervasive adoption of USB, a standard I
first wrote about in 1996 (“Oh Say Can
You USB?” Circuit Cellar, issue 74,
September 1996). Widespread accept-
ance took many years, despite the fact
that USB was a standard that had every-
thing going for it, including compelling
technical and user advantages, not to
mention full backing from kingmakers
Intel and Microsoft. Now imagine try-
ing to promulgate a new wire and con-
nector standard for something like AC
power or phones—only a marketing
masochist would ever think twice
about trying that.
The bad news about the blizzard of
wireless schemes is that I can barely
keep up with the flurry of products,
proposals, and pitches that crowd my
in-basket. No sooner do I think I can
get my hands around it all than a rash
of new announcements arrives.
Of course, the good news is that there’s
no shortage of topics to cover. As some-
one who writes about new technology, I
always have a bit of foreboding about
sensor networks where it’s typically
the case that the wires are more of a
hassle (or even a showstopper, like
with tire air pressure monitoring) than
the sensor technology itself. The bot-
tom line is that Bluetooth has left a big
gap at the low-end that ZigBee and
other lean-and-mean RF solutions can
and must fill. And don’t get me started
on X10, something I wouldn’t even
trust to do my Christmas tree lights.
Another pivotal decision made by
the ZigBee crew was to sync up with
the IEEE and adopt the now ratified
IEEE 802.15.4 radio standard for the
lower layers (e.g., media access and
physical) of the ZigBee stack. Not
only did this eliminate the need for
the ZigBee folks to define and evangel-
ize yet another new standard, but it
also meant that every 802.15.4 radio
shipped becomes a potential home for
ZigBee-compatible applications. If you
ship it, they will come.
Of course, the other side of the coin is
that an 802.15.4 radio by itself does not a
ZigBee-compliant application make. It’s
possible (indeed likely in my opinion)
that we’ll see more than one higher-layer
protocol riding on 802.15.4 radios. For
instance, 802.15.4 uses direct-sequence
spectrum spreading (DSSS) but also offers
multiple channels (e.g., 16 for the
2.4-GHz version), which would allow
designers to implement frequency hop-
ping with higher layer software.
Enough of the Machiavellian mar-
keting machinations. Silicon is where
the rubber meets the road, and I’m
pleased to report that IEEE 802.15.4
chips are firing up. Gentlechips, start
your engines.
Radio Riot
SILICON UPDATE
by Tom Cantrell
whether there will come a time when
there’s nothing new to write about.
Fortunately, thanks to wireless technolo-
gy (and Moore’s law), it doesn’t seem
like that will happen anytime soon.
ZIGZAG
I first wrote about ZigBee way back
when it was little more than smoking
rubble of the failed HomeRF initiative.
The fact that ZigBee has survived the ini-
tiative and grown is certainly testimony
to the organizers’ skill and persistence,
but there’s more to it than that. Part of
the credit, or discredit as it may be, for
the buzz behind ZigBee has to go to the
Bluetooth crowd. Long-time readers of
my column know that I’m a real show-
me kind of guy. As such, I haven’t been
overly kind (or servile) in the face of the
Bluetooth hype (“Bluetruth, Houston,
We Have a Problem…,” Circuit
Cellar
, issue 134, September 2001).
I’ll admit part of my bias is that I’m
never the first on my block to adopt
the latest-and-greatest PDAs, cell
phones, and the like. But even if I were
a gadget freak, the engineer inside me
can’t help but ask why anyone would
need a 32-bit CPU, half a meg of code,
and a fancy Bluetooth radio to imple-
ment a cordless handset or update
their address book.
Bluetooth may do something well,
but the problem is that the something
it does isn’t what I need done. But I
sure could use something really sim-
ple, low-power, and reliable that would
allow me to control my lawn sprin-
klers without a trip to the garage to do
battle with a kludgy-interface sprinkler
controller. Another huge opportunity is
Wireless this and wireless that. With all the new products and standards floating in a sea of
marketing hype, it’s hard to know what will best fit your design needs. Fortunately, Tom’s got
the scoop on the most appropriate wireless solutions available to you, the designer.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
79
One of the first, and a likely exam-
ple of the growing breed, is the
Chipcon CC2420. Naturally, as it
must be for pervasive applications,
the CC2420 is a highly integrated
antenna-to-bits, 2.4-GHz solution.
Typically paired with a simple
MCU, the ’2420 ues a high-speed (up
to 10 MHz) SPI interface. Although
the interface can easily keep up with
the 250-kbps over-the-air bit rate, the
chip nevertheless includes separate
128-byte receive and transmit FIFOs
to relax MCU timing concerns.
The chip performs a number of tasks
to inform and assist higher layer soft-
ware. The heaviest lifting performed
by the ’2420 in this regard is advanced
encryption standard (AES) encryption
and decryption using 128-bit keys as
required by 802.15.4. Although this
offloads the MCU of a huge burden,
note that a process for establishing
the keys (if they aren’t hard-wired) isn’t
defined by 802.15.4 and must be han-
dled by higher layer software. ZigBee
defines one key exchange mechanism
suitable for low-end hardware, but the
chip isn’t limited to that option.
The security features also can be
used in stand-alone mode (i.e., AES pro-
cessing of cipher or plain text in the
FIFOs without RF communication).
This allows the ’2420 to act as kind of a
security coprocessor in applications
that use additional I/O interfaces or
offline data storage (e.g., flash card).
Other helpful functions performed by
the chip include automatic frame check
sequence generation and checking
(CRC) and monitoring the state of the
RF link with received signal strength
indication, link quality indication, and
clear channel assessment. These sup-
port both basic operation and embellish-
ments for higher-layer software. For
example, clear channel assessment facil-
itates the collision avoidance aspect of
the CSMA/CA protocol. Similarly, sig-
nal strength and link quality indica-
tors allow higher-layer software to
make strategic decisions such as
switching to a less crowded channel or
reducing transmit power (thus limiting
battery drain and interference imposed
on other radios in the vicinity).
Perhaps the single most important
goal, and advantage, of 802.15.4 is low
power, which happens to be a notorious
failing of Bluetooth. The ’2420 draws
less than 20 mA during transmission
and reception, thanks in part to inter-
nal low-voltage operation at 1.8 V.
However, because most MCUs operate
at a somewhat higher voltage, the ’2420
integrates an on-chip voltage regulator
so it can run off a higher voltage (2.1 to
3.6 V) for digital I/O compatibility.
Even 20 mA would cut down the
hope of long battery life. Achieving
that relies on sticking to a relatively
low duty cycle and exploiting the
chip’s trio of low-power modes, which
cut power to 365 µA (oscillator and
voltage regulator enabled), 20 µA (oscil-
lator disabled), and ultimately 1 µA
(oscillator and voltage regulator dis-
abled). Eventually, when the battery
runs dry, an on-chip battery monitor
with 32 programmable threshold lev-
els will give a heads-up.
Put it all together and a ’2420 design-
in is laughably simple, as it should be
for a chip targeting low-cost embed-
ded wireless applications (see Figure 1).
It’s as easy as hooking up a 16-MHz
crystal and adding a few discretes,
depending on the particulars of your
chosen antennas, which can be as triv-
ial as a piece of wire (or PCB trace).
Do make sure to adhere to best prac-
tices when it comes to the layout (e.g.,
four-layer PCB, ground plane, power
supply decoupling, and filtering). And
watch out for interference generated
by your digital add-ons (e.g., MCU).
Chipcon has a development kit that
you can use as a reference example.
(The schematic and Gerber layout
files are available on their web site.)
IS YOU IS, OR IS YOU ISM’T?
Although IEEE 802.15.4 is a big
story, it isn’t the only one. As I men-
tioned earlier—and confirmed by a
glance at my in-basket—there’s noth-
ing to prevent someone from introduc-
ing their own proprietary unlicensed
(e.g., 915 MHz) and industrial, scien-
tific, and medical (ISM – 2.4 GHz)
band radios and protocols.
Cypress’s WirelessUSB chips are a
good example, although the name is
entirely misleading because there’s noth-
ing USB-centric about the radio itself.
Yes, the first version of the chip (the
LS) targeted typical PC applications
such as wireless mice and keyboards.
CC2420
RF
Transceiver
NC
DVDD_RAM
A
V
DD_X0SC16
SO
SI
SCLK
CSn
FIFO
FIFOP
CCA
SFD
DVDD1.8
DVDD3.3
VCO_GUARD
AVDD_VCO
AVDD_PRE
AVDD_RF1
GND
RF_P
TXRX_SWITCH
RF_N
GND
AVDD_SW
NC
NC
AV
D
D
_
C
H
P
A
T
EST1
A
T
EST2
R_BIAS
A
V
DD_IF1
VREG_IN
VREG_OUT
VREG_EN
NC
XOSC16_Q1
XOSC16_Q2
1
2
3
4
5
6
7
8
9
10
11
12
35
36
34
33
32
31
30
29
28
27
26
25
48
47
46
45
44
43
42
41
40
39
38
37
R451
3.3-V
Power supply
C42
C391
C381
XTAL
Folded
dipole
antenna
L61
NC
A
V
DD_RF
2
AV
D
D
_
IF2
NC
AV
D
D
_
A
DC
DV
D
D_ADC
DGND
_GU
A
R
D
DGU
A
RD
RESETn
DGND
DSUB_P
AD
S
DSUB_CORE
13
14
15
16
17
18
19
20
21
22
23
24
Digital interf
ace
Figure 1
—
The Chipcon ’2420 beats the rush with one of the first IEEE 802.15.4 ZigBee-compatible chips.
Competitors are as busy as bees, so expect a hive of activity this year because it’s a honey of a market.
80
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
But the recently introduced LR cer-
tainly doesn’t because the LR stands
for “long range” and would only make
sense for a really farsighted PC user.
Other than its notable 50-m range,
the LR is like the aforementioned
Chipcon part and other lightweight
radios. Operating in the 2.4-GHz band
using DSSS, the chip achieves up to
62.5 kbps over the air. Reflecting its
embedded aspirations, the LR can be
configured to trade-off speed (half and
quarter speed options) for additional
noise immunity by using a longer
spreading code, oversampling or dual-
channels. MCU connection is via the
ubiquitous SPI interface (up to 2 MHz).
One difference with Chipcon is that
the Cypress chips don’t have FIFOs.
They’re just single-buffered like a
UART, so your MCU will need to keep
up byte-by-byte (i.e., roughly 125 µs
between bytes) to avoid overflow and
underflow. In addition, the entire chip
(not just the digital I/O) runs at a
higher voltage (2.7 to 3.6 V), no doubt
the major factor in the LR’s somewhat
higher power consumption (roughly
70 mA transmit, 60 mA receive).
On the other hand, hardware design
is equally trivial with just the addi-
tion of a crystal (in this case 13 MHz)
and antennas while development tools
and code examples for the proprietary
protocol ease the way (see Photo 1).
One particularly interesting feature is
Photo 1
—
Cypress WirelessUSB evaluation kits come with a listener program that allows for easy experimentation
with chip functions and monitoring RF traffic.
82
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
that each chip contains a unique 32-bit
code, which can serve as the address for
identifying nodes in a network.
Other companies offer application-
specific solutions that target a particu-
lar class of applications with opti-
mized radio and protocol. In the case
of Zensys, the name is Z-Wave, and
the game is home automation. Think
along the lines of an RF version of X10,
although unlike that aging standard, Z-
Wave offers two-way communication
as a basis for improved reliability.
To keep it simple, Z-Wave dismisses
with many popular RF frills in favor of
an approach that narrowly targets the
low-end, arguably even below
802.15.4. With 9.6-kbps throughput,
I’m talking about something suitable
for switches, lights, drapes, security,
and that’s about it.
For example, Z-Wave doesn’t use
spread-spectrum techniques even
though it operates in the 915-MHz
band, where the FCC strictly limits
interference (e.g., transmit power and
duty cycle), which means narrowband
transmit power, and thus range, is
limited. The payback is that the sim-
plicity of the RF section means the
entire radio can be integrated on an
8051 MCU (see Figure 2).
Reflecting the limitations (i.e., range)
and characteristics of the application at
hand, Z-Wave ues a mesh topology and
protocol in which any node can act as a
repeater. The only range limit that
matters is the distance to the nearest
node, and, like the Internet, the physi-
cal size of the entire
network can scale up by
sending messages along
multiple short hops.
The routing can adapt
(i.e., bypass) obstacles,
whether it’s an RF
blocker (like the refrig-
erator in Figure 3) or
a node with a dead
battery.
The proprietary Z-
Wave protocol resides
in a portion of the ’51’s
flash memory, leaving
the rest available for
the typically simple
user application and
making for a truly sin-
gle chip solution. Given the volumes
of hoped-for designs (e.g., light switch-
es), Zensys says they ultimately plan
to offer a ROM version of the part for
as little as $1.
SHOCKING STICKER
I’ve miles and miles of files
Pretty files of your forefather’s fruit
And now to suit our great computer
You’re magnetic ink.
—
The Moody Blues, “In the
Beginning,” On the Threshold of a
Dream,
Deram Records, 1969.
Another hot topic is simmering and
ready to boil: RF ID. Whether it’s
homeland security (i.e., tracking the
contents of shipping containers), sup-
ply-chain management, or automated
checkout at your local grocery store,
the major players are clamoring for
next-generation, beyond-bar-code solu-
tions. Much of the activity centers on
the electronic product
code (EPC) initiative driv-
en by a consortium of
academic and business
heavyweights.
Initiatives, consor-
tiums, and standards are
all well and good, but
when Wal-Mart talks the
supply chain listens. Last
November, the retailing
giant summoned its top
100 suppliers to head-
quarters for a little chat.
They were asked to start
shipping palettes with EPC RF ID tags
starting in 2005. By 2006, every single
Wal-Mart supplier is supposed to fol-
low suit.
[1]
The vision is an “Internet of things,”
where the URL is replaced with the
96-bit EPC comprised of various fields
(see Figure 4). The header defines a ver-
sion number allowing for future expan-
sion. The EPC Manager field is typically
a corporate identification (e.g., Coca-
Cola Company), and the Object Class
defines the product (e.g., 12-oz. Diet
Coke) much like the stock-keeping unit
(SKU) found on today’s bar codes. The
serial number identifies each individual
unit, the 36-bit code able to accommo-
date 68 billion items (in each class),
ostensibly enough to cover worldwide
production for years to come.
Let’s look in the crystal ball.
Someday, perhaps in the not-so-dis-
tant future, you’ll pick up a soda at a
store or vending machine. Naturally,
you won’t have to hunt for spare
change; the RFID credit card in your
pocket (or implanted in your hand?)
will pick up the tab.
Your purchase of a single can of
soda will instantaneously ripple back
from the point of purchase via the I-
way all the way to the factory where
it will feed into the automated pro-
duction and shipping system.
Essentially, the smart supply chain
will automatically spit out a new soda
moments after you take one.
Technical challenges remain,
including getting the tag price way
down. Presently, $0.05 is being bandied
about as a suitable target (see Photo 2).
Ironically, the problem isn’t making the
tag chips smaller; rather, they are too
Hallway
Living room
Sensor I
Lamp H
Lamp G
Lamp F
Lamp B+C
Kitchen
Lamp K
Lamp L
Dining
Room
Garage
Lamp M
Garage door
opener N
Lamp A
Outdoor lamp J
Remote
control
Figure 3
—
Mesh networking schemes like Z-Wave’s are able to route
around obstacles and adapt to changing circumstances.
Flash memory
Z-Wave SW API
Application SW
128 bytes
of SRAM
2 KB
of SRAM
Power-
saving Ctrl
8051
SFR
Triac
Ctrl
Watchdog
Interrupt
Ctrl
SPI
Ctrl
8051
CPU
Including
standard 8051:
UART0, Timer0,
and Timer1
System
clock
Timer2
and
Timer3
Real-
time
clock
Real
clock
timer
Power-on
reset/
brownout
10-bit
ADC
I/O Interfaces
RF
Transceiver
Digital part
Analog part
Digital part
Analog part
Figure 2
—
The only thing simpler than a two-chip MCU and radio solution is a
single-chip setup that does the same thing. Thanks to the simplicity of the Z-
Wave radio and protocol, there is enough 8051 processing power and code
space left over to handle simple applications on the same chip.
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
83
small to work with. Companies are
experimenting with techniques such
as dicing wafers chemically instead of
using a saw and self-assembly to get the
teeny chips into more manageably sized
carriers. Another promising technique
is using conductive ink to literally
print the tags’ antennas.
Of course, it’s often social and polit-
ical challenges rather than technical
ones that prove most nettlesome. For
instance, Italian clothier Benetton
recently had to backpedal quickly from
their announced plan to use RFID tags
embedded in their clothing labels. The
retreat was no surprise in the face of
criticism and media uproar over the
prospect of Benetton, in the words of
one privacy advocate, “putting tracking
devices in people’s underwear.”
[2]
Yeah, the conspiracy theorists will
have a field day. Don’t you just love
this business? On the other hand, as I
was searching the ’Net for “RFID,” I
couldn’t help but notice that one of
hottest and best-funded new start-ups
in the field is named “Alien
Technology.” Coincidence? You be the
judge, but don’t say I (and the Moody
Blues) didn’t warn you.
GO WIDE, YOUNG MAN
The 802.11 network menu may be
crowded, but make room for a new
special of the day. In
IEEE-speak, it’s called the
IEEE 802.15 WPAN High
Rate Alternative PHY
Task Group 3a (a.k.a.
802.15.3a). That’s a lot of
fancy words that boil
down to two hot topics:
WiMedia and ultrawide-
band (UWB).
Even if you (like me)
don’t understand all of
the technical details, the
term “WiMedia” says it
all. The goal of 802.15.3a
is to come up with some-
thing as commercially
successful as 802.11 Wi-Fi but
targeting multimedia. Put
even simpler, it’s wireless for
couch potatoes.
A glance through the “TG3a
Technical Requirements”
sums up the challenge of elim-
inating the wiring harness for a typical
home theater setup. With high-definition
video and fancy audio, you’re looking
at approximately 30 to 50 MBps, and
that’s before you throw in couch-pota-
to accouterments like ’Net access, a
video phone, and the usual pile of
remotes. To make a long story short,
802.15.3a calls for delivering at least
110 MBps across a living room.
[3]
To make the long story longer, the
need for a high-rate alternate PHY just
happens to coincide with the emer-
gence of UWB technology in the com-
mercial marketplace. Although there
may be other ways of doing it,
802.15.3a and UWB are pretty much
synonymous at this point.
So what the heck is UWB? Suffice
to say the concept (like many com-
mercial hand-me-downs, including the
Internet) owes a lot to Cold War-era
radar and communications research.
The technical hook relies on the
ability to generate and capture extreme-
ly narrow subnanosecond pulses with
precise timing. Rather than using a car-
rier wave like other radio schemes,
UWB is zero-carrier. The time, not fre-
quency, domain characteristics of the
pulses encode the data using, for exam-
ple, pulse position modulation (PPM)
as you can see in Figure 5. Indeed, to a
casual RF observer (i.e., one not looking
for, or even able to see, the narrow
pulses), UWB transmissions come
across as a little bit of background hiss
(wideband noise) because of the rela-
tively low (less than 1%) duty cycle
(thus average power) of the signal.
Low noise and low power are at the
heart of 802.15.3a. The spec calls for,
as it must, peaceful coexistence with
everything else clogging the airways
including 802.11 (a,b, and g), Blue-
tooth, and 802.15.4/ZigBee, not to
mention cordless phones and that RF
nemesis, the microwave oven.
Given the military background of
UWB, perhaps it’s no surprise that the
U.S. Defense Department has given its
two cents on the matter to the FCC. As
best I can tell, after a lot of hemming
and hawing (deciding how to decide
things), the regulatory authorities have
at least given their blessing to the IEEE
to try to come up with a standard that
doesn’t end up jamming GPS systems or
your neighbor’s satellite TV.
What would a proposed IEEE standard
be without a good old-fashioned stan-
dards battle? In the case of 802.15.3, the
Hatfields (Motorola) and
the McCoys (Intel and
TI) are at loggerheads
over seemingly arcane
details related to the
modulation scheme. At
this point the situation
seems more or less dead-
locked in trench warfare
with neither side able to
muster a mortal blow
(75% standards commit-
tee vote) against the
other. Most recently,
there have been propos-
als that would allow the
two schemes to coexist,
Figure 5
—
The secret of ultrawideband (UWB) is that the pulses are ultra narrow (picoseconds)
so the spectral response is ultra-wide. With transmitter and receiver in perfect lockstep, a slight
shift in pulse position is one way to encode the data.
[4]
ELECTRONIC PRODUCT CODE TYEP 1
Header
8 bits
EPC Manager
28 bits
Object Class
24 bits
Serial Number
36 bits
Figure 4
—
The Electronic Product Code will create an “Internet of
Things.” Is an Electronic People Code next?
Photo 2
—
With standards and demand driven by the likes
of Wal-Mart, expect RFID tags to become smaller, cheaper,
and pervasive. These samples from TI are just the start.
84
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
it took more than a press release and a
prayer to promote a new communica-
tion standard. But the old days always
look better in hindsight. Frankly, I look
forward to a world beyond wires, not
just to clear the rat’s nest, but also to
enable new products that traditionally
have been hamstrung by wiring hassles.
Whether it’s sensor networks, toys,
home automation, or entertainment
centers, it’s time to throw off the
wires that bind. As water allows com-
munities to grow so too will radio
but because they still can’t interoper-
ate, no one seems really gung-ho
about that scenario.
Perhaps one side will break through.
Or perhaps they’ll battle it out in the
marketplace (like with 802.11a versus
802.11g). If worst comes to worst,
there’s always the dual-band way out: if
in doubt, just make your box do both.
BRING IT ON
All the action might inspire nostal-
gia for the days when wires ruled and
SOURCES
RFID Tags
Alien Technology Corp.
(408) 782-3900
www.alientechnology.com
CC2420 IEEE 802.15.4 Radio chip
Chipcon
www.chipcon.com
WirelessUSB LR Radio chip
Cypress Semiconductor
(408) 943-2600
www.cypress.com
Electronic Product Code (EPC)
EPCglobal, Inc.
www.epcglobalinc.org
RFID Tags
Texas Instruments, Inc.
www.ti.com
Z-Wave Radio chip
Zensys
www.zen-sys.com
REFERENCES
[1] RFID Journal, “Wal-Mart Details
RFID Requirement”, November 6,
2003, www.rfidjournal.com/article/
articleview/642/1/1/.
[2] L. Rosencrance, “Update: Benetton
details decision on ID clothing tags,”
Computerworld, 2003, www.com-
puterworld.com/securitytopics/
security/privacy/story/0,10801,801
26,00.html.
[3] J. Ellis, et al, “TG3a Technical
[4] P. Withington, “Ultra-wideband RF-
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.
nourish exciting applications. When
it comes to the RF spectrum, it’s like
the water baron William Mulholland
once said, “There it is: take it.”
I
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
85
IDEA BOX
THE
DIRECTORY
OF
PRODUCTS AND
SERVICES
AD FORMAT
: Advertisers must furnish digital submission sheet and digital files that meet the specifications on the digital submission sheet.
ALL TEXT AND OTHER ELEMENTS MUST FIT WITHIN A 2
″″ ××
3
″″
FORMAT
. Call for current rate and deadline information. Send your disk and digital submis-
sion sheet to: IDEA BOX, Circuit Cellar, 4 Park Street, Vernon, CT 06066 or e-mail kc@circuitcellar.com. For more information call Sean Donnelly at (860) 872-3064.
The Suppliers Directory at www.circuitcellar.com/suppliers_dir/
is your guide to a variety of engineering products and services.
turn serial data into video text
Insert-ready Single Board Computer modules in sub-miniature
dimensions (as small as 47x55 mm) populated by:
applicable controller signals extend to standard pin header (2.54
mm) or high-density Molex (0.625 mm) connectors, enabling SBC
to be plugged like a big chip into OEM targets
achieved via GND circuitry, multi-layer PCB, by-
pass capacitor grid and short signal traces achieved via small
footprint and use of 0402 SMD passive components
32 KB to 64 MB external SRAM and Flash (controller-dependent)
CAN, Ethernet, RS-232 and RS-485 interfaces; ADC, DAC
(controller-dependent); freely-available /CS and I/O lines
AC adapter, serial cable and SPECTRUM CD with eval software
tools, electronic documentation and demos
: insert-ready PHYTEC SBC modules accompany you
from evaluation through protyping to end production...
accelerating your design cycle and reducing your time-to-market
86
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
Interface Keypads, Switches, or RS-232 to your PC Keyboard Input
Up to 12 x 12 matrix Programmable RS-232 Port Macro Capability
The KE24 is the ultimate in flexibility. Inputs or serial data can
emulate any of the 101 keys from a standard keyboard.
Up to 9 x 9 matrix 2.5" x 3.0" Size PC Keyboard Port PCXT, AT Compatible
The KE18 combines a multitude of features with small size at an
economical price. Custom units available.
Phone: 607-533-4441 Fax: 607-533-4443
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
87
88
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
89
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
91
92
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
www.circuitcellar.com
CIRCUIT CELLAR
®
Issue 167 June 2004
93
Full-Field Color Video Frame Grabber
Waveform Capture and Display: Three Controllers Make a Waveform Monitor
Graphics LCD Library for the Z8 Encore!
Adaptable Multimedia Thermometer
Designing with the Nios (Part 2): System Enhancement
APPLIED PCs
Uncomplicated dsPIC Implementation
FROM THE BENCH
Lose the Crystal: Linear LTC6903/4 Programmable Oscillator
SILICON UPDATE
Motoring
94
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
90
Abacom Technologies
89
ActiveWire, Inc.
85
All Electronics Corp.
93
Amazon Electronics
58
AP Circuits
88
Ash Ware
7
Atmel
19
AVR 2004 Contest
91
Bagotronix, Inc.
58
Bellin Dynamic Systems, Inc.
74
Belsoft
39
CadSoft Computer, Inc.
87
Carl’s Electronics
88
CCS-Custom Computer Services
92
Conitec
85
Cyberpak Co.
1
Cypress MicroSystems
65
CWAV
91
DataRescue
85
Decade Engineering
85
DLP Design
9
Earth Computer Technologies
87
EE Tools
(Electronic Engineering Tools)
52
EMAC, Inc.
59
Entrelogic Corporation
The Index of Advertisers with links to their web sites is located at www.circuitcellar.com under the current issue.
Page
14
ExpressPCB
85
FDI-Future Designs, Inc.
92
Front Panel Express
86
Hagstrom Electronics
50
HI-TECH Software, LLC
31
Holmate Semiconductor
8
ICOP Technology, Inc.
89
IMAGEcraft
42
Imagine Tools
90
Intec Automation, Inc
93
Integrated Knowledge Systems
90
Intrepid Control Systems
90
Intronics, Inc.
63
Jameco
64, 86
JK microsystems, Inc.
91
JPA Consulting
46
JR Kerr Automation & Engineering
46
LabJack Corp.
46
Lakeview Research
13
Lemos International
2
Link Instruments
84
Linx Technologies
47
MaxStream
90
MCC (Micro Computer Control)
9
Microchip
92
MicroControls
93
Micro Digital
92
microEngineering Labs, Inc.
88
MJS Consulting
91
Mosaic Industries, Inc.
41
Mouser Electronics
66
MVS
86
Mylydia, Inc.
C2
NetBurner
88
OKW Electronics, Inc.
92
Ontrak Control Systems
71
PCBPRO
73
PCBexpress
87
PCB Fab Express
C4, 64 Parallax, Inc.
85
Phytec America LLC
87
Phyton, Inc.
90
Picofab, Inc.
93
Pulsar, Inc.
88
Quality Kits & Devices
86
Quantum Composers, Inc.
81
R4 Systems, Inc.
55
Rabbit Semiconductor
73
Remote Processing
89
RLC Enterprises, Inc.
Page
Page
Page
93
Rogue Robotics Corp.
53
Saelig Co., Inc.
3
Scott Edwards Electronics, Inc.
88
Sealevel Systems
93
Senix Corp.
5
Sierra Proto Express
89
Signum Systems
17
Silicon Laboratories, Inc.
91
Softools
58
Systronix
89
TAL Technologies
C3
Tech Tools
26, 27
Technologic Systems
87
Technological Arts
90
Tern, Inc.
86
Trace Systems, Inc.
91
Triangle Research Int’l, Inc.
52
Trilogy Design
25
Velocity Semiconductor
93
Weeder Technologies
91
Zanthic Technologies, Inc.
86
Zexus Technologies Ltd.
95
Zilog, Inc.
89
Z-World
August Issue 169
Deadlines
Space Close: June 10
Material Due Date: June 18
Theme:
Embedded Programming
Bonus Distribution:
Hot Chips
A
TTENTION
A
DVERTISERS
e-mail: sean@circuitcellar.com
INDEX OF ADVERTISERS
Preview of July Issue 168
Theme: Graphics & Video
C
ircuit Cellar has an international audience, so some of you will have to bear with me if you live in a country that hasnt gone crazy over com-
mercial TV digital video recording (a.k.a. TiVo, or in some places its competitor ReplayTV).
Remember about five years ago when you wanted to record a TV program? Provided you were one of the people who actually read directions,
you had to go through the arduous task of setting the VCR. If you were like me, you just said, Dear, did you remember to set the VCR before we
leave?, giving the task to the fairer sex. You could record more than one program, too, as long as the total time didnt exceed 6 h and you didnt have
a power glitch any time before the last second of recording, otherwise the whole process was trashed. Needless to say, recording wasnt easy.
A few years ago, digital recorders came on the scene. I appreciated the technology, of course, but I had a privacy issue with them that kept me on
the outside for many years. For those of you still in the dark, TiVo is a digital video recorder. The box is connected to your cable line or satellite dish.
And, depending upon the size of the internal hard drive, it records between 35 and 280 h of programming. TiVo connects to your telephone line or the
Internet and downloads a special TiVo program guide that allows you to simply click on the programs you want to view or record (even two at a time).
The bad news about TiVo is that it is like your worst nightmare about Internet cookies. The TiVo box downloads the program guide, and then
uploads everything it has done since the last time it was polled. So, every program you surfed, every commercial you watched or skippedbasi-
cally your complete viewing habitsare now available to some marketing guy on a mission. But, then again, our digital world is full of personal-info
paranoia, so whats new? I finally succumbed when my wife said, So, what would you watch that you couldnt tell people? My realization was noth-
ing, and I went out the same day and bought an 80-h Sony TiVo that connected to my DirectTV satellite dish.
Because I already had a substantial monthly subscription plan with DirectTV, the usual $10-per-month TiVo subscription was added for free. I
also added an equipment replacement policy for $60 per year. This was extremely fortuitous because the Sony TiVo crapped out four weeks after I
bought it. Rather than wait three months to get it replaced by Sony, I sent it to DirectTV and received a new Hughes TiVo via UPS the next day.
The bad news was that it turned out to be a 35-h unit instead of the 80-h unit I had purchased. This one worked for two months before it joined the
other one in the DirectTV trashcan. Then, DirectTV sent me a Philips unit as a replacement. This one has run OK for the past three months (knock
on wood).
Of course, DirectTV has sent new remotes, documentation, and hook-up cables each time the unit has been replaced, but spares are good. What
you have to watch out for are hidden settings in replacement units. All TiVos have a progressive setup procedure designed specifically for direction-
challenged people like me. This is how you tell the machine to automatically fill your entire hard drive with Simpson reruns or just leave the driving
to you. Complacency should be avoided, however, even if you have already gone through the entire setup procedure with three other machines in
the past five months. When I neglected to examine the telephone number to which the TiVo unit periodically calls for programming (a 1 to 3 h initial
setup download), I found a $28 long-distance charge on my phone bill! Apparently the latest TiVo preferred to call Indiana rather than the local
Hartford number for programming. That got changed immediately.
So, after almost a year of use, like most people with TiVo, I love it. For the Microsoft bashers out there, youll be glad to know that TiVo runs on
Linux, which seems to be an unending source of amusement for people who want to add enhancements (i.e., hack the box). Because it uses an
open-source operating system, there is less interference from commercial interests (like a Microsoft). Therefore, modifications like increasing the
size of the hard drive and adding a DVD recorder abound. In fact, I found one unofficial site (www.tivocommunity.com) that has 164,000 threads with
1,800,000 posts talking about TiVo. Yes, opening the box will void the warranty, but it looks like it isnt discouraged. Apparently promoting the cult
following has more benefits for TiVo in the long run.
So, TiVo has succeeded in becoming the better mousetrap. More importantly, it is a real computer. And just like video games, there is a lot of
horsepower under the hood. Im sure even some of the more esoteric potential enhancements would be of interest to Circuit Cellar readers. The on-
line forum prominently posts, NOTE...No talk of any type of service theft or video extraction is allowed. This also includes hacks that remove ads
from TiVo software. Provided you understand that we also have this same rule, Circuit Cellar would love to see (and potentially publish) the great
things youve done with your TiVo.
To TiVo or Not to TiVo
steve.ciarcia@circuitcellar.com
96
Issue 167 June 2004
CIRCUIT CELLAR
®
www.circuitcellar.com
by Steve Ciarcia, Founder and Editorial Director
PRIORITY INTERRUPT
Wyszukiwarka
Podobne podstrony:
circuit cellar1995 06
circuit cellar2001 06
circuit cellar1996 06
circuit cellar2002 06
circuit cellar1993 06
circuit cellar1994 06
circuit cellar1991 06,07
circuit cellar1992 06,07
circuit cellar1997 06
circuit cellar2003 06
circuit cellar1990 06,07
circuit cellar1995 06
circuit cellar2001 06
circuit cellar1991 06,07
circuit cellar1993 06
circuit cellar1996 06
więcej podobnych podstron