Elektor EPROM User manual

MICROPROCESSOR
12 Elektor Electronics 11/2002
An EPROM emulator is a useful if not indis-
pensable tool if you are into developing soft-
ware for a system employing an EPROM for
storage of executable code or fixed data. Such
a ‘programmable imitation EPROM’ obviates
the need to erase an EPROM after any pro-
gramming cycle, before the new (and hope-
fully improved) program may be loaded into
the chip. Erasing an EPROM with
the aid of UV light usually takes
about 20 minutes, which, many of
you will agree, is an annoyingly long
time. If you want to test a new ver-
sion of the software during those 20
(long) minutes, a second EPROM
may be useful, but the entire opera-
tion is still cumbersome and tedious.
Over time, many different EPROM
emulators have appeared on the
market. Elektor Electronics, too, has
published a fair number of designs.
In most, if not all, cases, these emu-
lators are connected to the target cir-
cuit (sometimes also called host cir-
cuit) by way of a length of flatcable
terminated in a DIP-style plug that
can be inserted in an EPROM socket.
The length of the ‘umbilical cord’ is
limited to prevent a too high capaci-
tive load on the data and address
bus of the target system, or timing
problems caused by pulse reflection
on the cable. In practice, the con-
nection between the EPROM emula-
tor and the target circuit is often a
source of headaches.
A second, often neglected, disad-
vantage of the traditional EPROM
emulator is that it can not be pro-
grammed using a normal EPROM
programmer. Usually, programming
such units requires a special pro-
gram contained in the emulator soft-
ware (and hopefully supplied with
the kit).
The emulator presented in this
article goes off the beaten track and
is not hindered by any of the above
disadvantages. It can be pro-
grammed in any old EPROM pro-
grammer, and the complete unit may
be plugged into the EPROM socket
in the target circuit without any
problems.
EPROM Emulator
a perfect imitation-EPROM
Design by P. Goossens
As opposed to most other EPROM emulators, the design discussed in this
article provides a virtually perfect imitation of a ‘real-life’ 27C256 device,
which may be programmed in any programmer as well as inserted into
the target system.

MICROPROCESSOR
1311/2002 Elektor Electronics
select) input of the chip allows the signals
applied to the datalines to be programmed at
the location (address) pointed to by the
address bus. A Low input level applied to the
OE (output enable) input enables the con-
tents of the current address to be read out.
This is usually done immediately after pro-
gramming a byte, to make sure the program-
The EPROM
An EPROM is normally programmed
in a general-purpose EPROM pro-
grammer. Most of these units first
run a blank check on the chip you’ve
inserted. This is done by reading all
bytes in the EPROM to see if they
are at FF. If one or more bytes are
found with a different value, the
EPROM is not empty and a suitable
error report is produced. In many
cases, no further action is possible
until the entire chip is blank. Some
programmers are capable of detect-
ing the EPROM brand and type
inserted into the programming
socket. Once this information is
(automatically) established, the rel-
evant programming voltage(s) and
programming algorithm are set up.
Device recognition (if supported by
the chip manufacturer) is effected by
applying +12 V to the A9 pin and
then reading certain addresses from
the EPROM.
Once the programmer has estab-
lished that the EPROM is empty, the
actual programming sequence is
allowed to begin. First, the EPROM
is switched to programming mode
by applying a relatively high voltage
to the Vpp pin on the device. The
level of the programming voltage
depends on the EPROM type used,
and lies between 12.5 V and 21 V.
At the same time, the EPROM sup-
ply voltage (at the Vcc pin) is raised
from +5 V to +6 V. If you are curi-
ous to know how that is done in
practice, look ahead at the top part
of Figure 4.
With the EPROM in programming
mode, a logic Low at the CS(chip
62256
IC3
A10
A11
A12
RAM
A13
A14
10
A0
A1
A2
A3
A4
A5
A6
A7 25
A8 24
A9 21
23
1422
OE
20 CS
28
11 D0
12 D1
13 D2
15 D3
16 D4
17 D5
18 D6
19 D7
27
WR
26
9
8
7
6
5
4
3
2
1
74HCT245
IC5
3EN2
3EN1
11
12
13
14
15
16
17
18
19 G3
2
3
4
7
8
9
5
6
1
1
2
8x 10k1
23456789
R9
+5V +5V
A0
A1
A2
A3
A4
A5
A6
A7
A8
A9
A10
A11
A12
A13
A14
A0
A1
A2
A3
A4
A5
A6
A7
A8
A10
A11
A12
A13
A14
16V8
IC4
GAL
19
20
10
I0
I1
I2
I3
I4
I5
I6
I7
I8
F7
11 I9
12
F0 13
F1 14
F2 15
F3 16
F4 17
F5 18
F6
1
2
3
6
7
8
4
5
9
+5V
C3
100n
S1
R6
10k
S2
R5
10k
+5V
D2
4V7
R4
100
½
A9
D5 D4
R8
1k2
R7
1k2
+5V
D3
4V7
R3
33
½
D1
7V5
R1
10k
R2
10k
T1
BS170
+5V
K1 C1
100n
C2
100n
78L05
IC1
+5V
IC5
20
10
C4
100n
+5V
024066 - 11
RAMWRL
RAMOEL
RAMCSL
LED2L
LED1L
BUDIR
BUGATEL
EPOEL
EPCSL
EPVPPL
EPSV
HEADER
27256
EPROM
IC2
A10
A11
A12
VPP
A13
A14
10 A0
A1
A2
A3
A4
A5
A6
A7
25 A8
24 A9
21
23
1422
OE
20
CS
28
11
D0 12
D1 13
D2 15
D3 16
D4 17
D5 18
D6 19
D7
26
27
9
8
7
6
5
4
3
2
1
+9VDC
Figure 1. The circuit diagram of the EPROM emulator — exquisite simplicity.
Features
–Emulates 27C256 EPROM
–Suitable for programming with any pro-
grammer supporting the 27C256
–Electrical protection against reading of
DEVICE-ID
– Easy to erase
–Compact
– Easy to use

ming operation was successful. If the verify
returns ‘ok’ the next byte is programmed.
The length of the programming pulse
depends on the programming algorithm
applied. The same goes for repetition of the
programming cycle if the relevant byte was
not successfully programmed.
During normal use of the EPROM (Vpp and
Vcc at 5 V), the device will respond ‘nor-
mally’ to signals applied to the CSand OE
pins. Only with both inputs activated (i.e., at
logic Low) will the EPROM supply the data
belonging with the address placed on the
address bus.
Practical Circuit
The circuit diagram shown in Figure 1 com-
prises relatively few components — three
ICs, a voltage regulator, one FET and two
indicator LEDs do the job. IC2 is not an inte-
grated circuit but an assembly of two 14-way
pinheaders that form the connections of the
EPROM being emulated by the circuit.
IC3, a RAM type 62C256, forms the heart
of the circuit. Although a 70-ns version is
specified in the parts list, a faster chip is, of
course, also allowed. Slower versions, how-
ever, are not recommended for use in this cir-
cuit.
IC4 is a GAL type 16V8 which has been
programmed to supply a fair amount of (invis-
ible) logic circuitry that ‘translates’ external
signals to the ones required by IC3. This
translation process requires the GAL to be
connected to the EPROM socket via a few
logic links, as well as to be provided with
information as to the presence of an external
voltage at the Vcc pin, and a voltage greater
than 12 V at the Vpp pin.
The combination R3-D3 affords protection
of the GAL against higher voltages at the
EPROM Vcc pin. That is necessary because
this voltage is usually raised to +6 V during
programming. The circuit around transistor
T1 detects the programming voltage at the
Vpp connection of the EPROM socket. Zener
diode D1 starts to conduct if the program-
ming voltage is present. The voltage at the
gate of T1 is then high enough for the FET to
be switched on. In combination with resistor
R1, zener diode D1 lowers the voltage to
about 7.5 V, thus ensuring that the FET
remains securely switched off at a voltage of
5Vat the Vpp terminal.
IC5, then, acts as a buffer device between the
MICROPROCESSOR
14 Elektor Electronics 11/2002
*IDENTIFICATION
024066;
*TYPE
GAL16V8;
*PINS
% Pin-assignment for input signals %
EPVP = 8, % Detection of 5V supply %
/EPVPP = 3, % Low active detection of VPP > 12V %
/EPOE = 1, % Input for /OE from EPROM-socket %
/EPCS = 2, % Input for /CS form EPROM-socket %
/SW1 = 9, % Input for switch S1 %
/SW2 = 11, % Input for switch S2 %
% Pin-assignment for output signals %
/RAMCS.t = 15, % output for /CS of RAM IC3 %
/RAMOE.t = 14, % output for /OE of RAM IC3 %
/RAMWR.t = 13, % output for /WR of RAM IC3 %
/BLANK.t = 16, % BLANK-state output for LED D5 %
/PROGRAM.t = 17, % PROGRAM-detect output for LED D4 %
/BUGATE.t = 19, % output for /G of buffer IC 5 %
BUDIR.t = 18; % output for DIR of buffer IC 5 %
*BOOLEAN-EQUATIONS
RAMCS.e = VCC; % These lines make sure that all used %
RAMOE.e = VCC; % output-lines of the GAL are %
RAMWR.e = VCC; % constantly driven %
BLANK.e = VCC;
PROGRAM.e = VCC;
BUGATE.e = VCC;
BUDIR.e = VCC;
% Switch to BLANK-state is S1 is pressed and hold this state %
% Until the EPROM programmer wishes to program the EPROM %
% OR the user wishes to switch to normal operation by pressing %
% S2 %
% This signal also drives LED D5 to indicate the BLANK-mode %
BLANK = BLANK*/PROGRAM*/SW2+SW1 ;
% Detection of a programming pulse to drive LED D4 %
PROGRAM = EPVPP*EPCS*/EPOE;
% CS for the RAM : Continuous during programming, else equal %
% to CS on the ROM %
% Only active during presence of external power to save the %
% battery %
RAMCS= EPVPP*EPVP+/EPVPP*EPCS*EPVP;
% OE for the RAM : During programming if OE on the ROM is %
% active AND Cs of the ROM is inactive %
RAMOE= EPVPP*EPOE*/EPCS + /EPVPP*EPOE*/BLANK;
% WR for the RAM : During programming if ROM-OE is inactive %
% AND ROM-CS is inactive, else if in BLANK-mode AND ROM-OE %
% is active. This means that reading while in blank-mode %
% causes the RAM to be written. Pull-ups make sure that the %
% code 0xFF will be written %
RAMWR= EPVPP*EPCS*/EPOE + /EPVPP*BLANK*EPOE;
% The DIR-signal for the 74HCT245. When this pin is active, %
% Data is transferred from the socket to the RAM-IC %
% Otherwise, the datapath is FROM the RAM to the socket %
BUDIR = EPVPP*/EPOE;
% The GATE-signal for the 74HCT245. If it is active (low) %
% the drivers are active, otherwise the A and B pins are %
% in High-Z state %
% It has to be active even in the BLANK-mode, so it wil force%
% 0xFF on the external databus during blank-check! %
% BUGATE is only active when external power is supplied to %
% save power from the battery whenever the device is not %
% required to be active %
BUGATE=EPVP*EPVPP*EPOE + EPVP*EPVPP*EPCS + EPVP*/EPVPP*EPOE;
*END
Figure 2. JEDEC file listing of the GAL contents.

Blank mode
This mode actually has two functions: mimic
an empty (blank) EPROM and clearing the
RAM IC. The signals used during Blank mode
are shown in Figure 3. Most EPROM pro-
grammers will check if the device is empty
before programming it. The conclusion that
the entire EPROM is empty is also employed
to speed up the programming process.
Because the programmer ‘knows’ that every
address reads FF, it may safely skip all
addresses that have to contain FF. This cuts
down on programming time, although it does
require the EPROM emulator to be ‘empty’
before it is programmed.
The normal procedure to check if an
EPROM is empty is to read all addresses and
compare the resultant data against the value
FF. To do so, your programmer will generate
all possible addresses and generate a read
pulse at each of them. These pulses may be
used to clear the EPROM emulator memory.
Each address is programmed by converting
the read pulse from the programmer into a
write pulse for the RAM IC. All datalines
being pulled to +5 V via resistor array R9,
IC3 is then filled with the value FF at all
memory locations.
At this point, the programmer has issued
a read command and expects device data
(preferably FF) to be placed on to the data-
bus. This is arranged by buffer IC5. The DIR
inputs remain Low, so the A signals are con-
figured as outputs and the B signals, as
inputs. The B signals, too, are connected to
+5 V via resistor array R9, so the buffer IC
will faithfully place the desired data (FF) on
to the databus.
Program mode
The GAL monitors the signal EPVpp to detect
the presence of a programming voltage
(≥12.5 mming mode. An EPROM being pro-
grammed responds differently to the signals
at CSand OE. Actually, in this state, these
signals may be renamed to WR and RD. Also,
there is no longer an additional signal avail-
able to enable the EPROM to be selected. For-
tunately, that is not necessary during pro-
gramming, because there is no need for the
EPROM to share the data bus and address
bus with other memory devices. In this state,
therefore, it appears as if the EPROM is per-
manently selected — see also Figure 4.
During a programming pulse, the buffer IC
has to transfer the data from the programmer
to the RAM (IC3). This is achieved by pulling
the DIR signal logic High. During a read pulse
(OE activated), the HC245 device has to
buffer the data in the opposite direction. This
EPROM and the databus. This IC is
necessary while the emulator is in
‘Blank’ mode when it is exptected to
supply the value FF at all times dur-
ing a read command. The GAL
arranges for the driver to be acti-
vated in the direction BA and the
EPROM is not read (actually, a write
command is given to the RAM IC,
more about this further on). Because
of the pull-up resistors inside R9, IC5
sees only logic Ones at the B inputs,
and faithfully copies these to the
external databus.
Some EPROM programmers are
equipped with pull-down resistors.
That is why IC5 is included in the
circuit, since without it the resis-
tance value of R9, depending on the
programmer, would have to be
selected low enough to prevent the
emulator acting as a significant (but
unwanted) voltage source in the tar-
get circuit.
Switch S1 allows you to switch
the EPROM emulator into Blank
mode, while S2 needs to be actuated
to manually leave this mode.
Finally, there are the components
around voltage regulator IC1. This is
a standard 5-volt regulator that steps
down the 9-V input voltage to 5
volts required by the logic circuitry.
The GAL
Apart from IC3, the most important
part of the circuit is the GAL chip.
As already mentioned, it contains all
logic circuitry we need to translate
and format external signals so that
they can be understood by the RAM
chip.
The JEDEC source file listing for
the GAL is shown in Figure 2.
Although an uncomplicated and
modest bit of programming, the
equivalent logic function of the GAL
is the same as that offered by a
rather more than a handful of ICs…
which if used would make the pro-
ject unwieldy.
The GAL will operate in one of
three modes: Blank, Normal and Pro-
gram. Each of these modes requires
the GAL to work in a different man-
ner. The Blank and Normal modes
may be selected manually by the
user. By pressing S1 once, the GAL
is configured for Blank mode. The
contents of the emulator may then
be erased by means of a blank check
run by the programmer. This state is
held until the user presses S2, or the
programmer starts to program the
emulator.
Normal mode is selected by
pressing S2 once. The emulator unit
will hen behave like an ordinary
27C256 EPROM.
Program mode is automatically
selected as soon as the programmer
starts to program the emulator (Vpp
raised to >12.5 volts). Once the pro-
gramming is finished (Vpp dropped
to +5 V), the emulator automatically
returns to Normal mode.
MICROPROCESSOR
1511/2002 Elektor Electronics
EPROM
CS
OE
RAM
BUFFER
CS
RD
WR
024066- 13
DIR
G
024066- 14
EPROM
CS
OE
RAM
BUFFER
CS
RD
WR
DIR
G
Figure 3. Signals in Blank mode.
Figure 4. Signals in Program mode.

is arranged by the GAL pulling the DIR input
logic Low.
Normal mode
The major signals with the circuit in Normal
mode are shown in Figure 5. From the dia-
gram it is clear that in this mode the GAL
does not have to perform particularly difficult
functions.
The GAL is also responsible for automatic
power reduction when the emulator is not in
use. By means of R3 and D3, IC4 is able to
detect the presence of an external supply
voltage. If no external supply voltage is
detected, IC5 and IC3 may be switched off.
IC4 prevents the signals G and CSfrom being
activated, effectively reducing the current
consumption of the RAM and the buffer when
the circuit is not used. A very useful feature
indeed because our EPROM emulator is bat-
tery-powered!
MICROPROCESSOR
16 Elektor Electronics 11/2002
CS
VPP
OE
Data Data outunknown
WR
CS
RD
G
DIR
EPROM
RAM
BUFFER
Data in unknown
024066- 15
Figure 5. Signals in Normal mode.
(C) ELEKTOR
024066-1
C1
C2
C3
C4
D1
D2
D3
D4 D5
IC1
IC2 IC3
IC4IC5
K1
R1
R2
R3
R4
R5
R6 R7
R8
R9
S1 S2
T1
0
+
024066-1
(C) ELEKTOR
024066-1
Figure 6 The unit is compact thanks to IC3 being mounted above IC4 and IC5.
COMPONENTS LIST
Resistors:
R1,R2,R5,R6 = 10kΩ
R3 = 33Ω
R4 = 100Ω
R7,R8 = 1kΩ2
R9 = 8-way SIL array 10kΩ
Capacitors:
C1-C4 = 100nF
Semiconductors:
D1 = zener diode 7.5V
D2,D3 = zener diode 4.7V
D4 = LED, high-efficiency, yellow
D5 = LED, high-efficiency, red
T1 = BS170 or BS107
IC1 = 78L05
IC3 = 62256-70CP
IC4 = GAL 16V89, programmed, order
code 024066-31 (see Readers Services
page)
IC5 = 74HCT245
Miscellaneous:
IC2 = 2 ? 14-way pinheader
S1,S2 = pushbutton
K1 = 9V battery clip with leads
PCB, order code 024066-1 (see Readers
Services page)
Disk, GAL JEDEC listing, order code
024066-11
PCB design and GAL listing also available as
files from Free Downloads at
www.elektor-electronics.co.uk

on the programmer’s ZIF socket. In practice,
however, we found that the lever had to be
lifted ever so slightly to enable the circuit to
be inserted into the socket. The above tip,
may, therefore, not be applicable in all cases.
Finally…
With the board fully stuffed and the battery
connected, the emulator is, in principle, ready
for use. First, however, we recommend run-
ning a few function tests.
The operation of the GAL may be checked
by pressing S1. LED D5 should light and go
out again when S2 is pressed once more.
Now insert the EPOM emulator into the IF
socket of your programmer and then press S1.
Run a Blank Check on the programmer. If
everything works as it should, the program-
mer should report an empty (blank) EPROM.
Now press S2 to force the emulator into Nor-
mal mode. Next, run another Blank Check on
your programmer. This test should also be
completed without problems, proving that
each and every mem-
ory location in the
emulator RAM (IC3)
contains the value FF.
As a final test, we
can check the pro-
gramming. Choose an
arbitrary programming
file on the programmer
and ‘burn’ it into (emu-
lated) EPROM. LED D4
should light. Next, run
a Verify operation to
see if the program-
ming operation was
successful.
If a problem is
encountered, carefully
inspect the construc-
tion of your emulator.
Check the orientation
of the ICs, diodes, etc.,
as well as the value of
all components. Also
inspect the solder
joints for short-circuits
and/or dry joints.
One more tip: temporarily install a ZIF
socket in the EPROM socket of the target cir-
cuit. This allows the emulator unit to be
inserted and removed as many times as nec-
essary without the risk of bad contacts
between target circuit and emulator. The
cheaper brands of IC sockets which prolifer-
ate in the hobby circuit these days are prone
to developing contact problems when used
more than two or three times.
(024066-1)
Power supply
The complete circuit is powered by
a 9-volt battery. Purposely no provi-
sion is made for the circuit to be
powered from the +5-V supply pin of
the EPROM. After all, the voltage at
this pin may become +6 V during
programming, which is not a healthy
level for the ICs in the emulator. If
you do want to employ this voltage,
measures should be taken for it to be
stabilised at +5 V. A DC-DC con-
verter could be used for this pur-
pose, but the disadvantages will
always outweigh the benefits,
mainly because the circuit becomes
bulky and difficult to work with in
practice. The battery can be elimi-
nated anyway because the circuit is
not permanently connected to an
external power supply which would
guarantee that the RAM contents
are not lost or corrupted the instant
the emulator is removed from the
programmer and taken to the
EPROM socket of the target system.
Construction
The artwork of the printed circuit
board designed for the EPROM emu-
lator is shown in Figure 6. The
board allows the unit to be compact
and easy to handle. Construction is
easy by almost any standard. As
customary, it is best to start with the
lower profile components (in this
case, the horizontally mounted resis-
tors). Then follow the other discrete
parts, the integrated circuits and the
pushbuttons. Two points are worth
noting. The first concerns the emu-
lator connections marked ‘IC2’.
These consist of two rows of 14-way
pinheaders whose pins have to pro-
trude downwards, requiring the
headers themselves to be soldered
at the underside of the PCB, too.
This is best done with the ICs
already mounted. A further pint to
note is that IC3 is mounted above
IC4 and IC5. The latter two have to
be soldered on to the board first,
while IC3 is fitted with a raised
socket. This is conveniently made
from two 14-way pinheaders. As a
matter of course, IC4 and IC5 are
mounted without sockets, else IC3
would require a second socket! By
the way, note the position of IC3:
viewed from above, it should be at
the right-hand side of connectors for
‘IC2’.
Here are some more practical
details. The holder for the 9-V bat-
tery may be secured to IC3 using
two-sided sticky tape to make the
unit sturdy and compact. It may also
be a good idea to file a away a small
piece of PCB material to the left of
diode D1 to make room for the lever
MICROPROCESSOR
1711/2002 Elektor Electronics

GENERALINTEREST
18 Elektor Electronics 11/2002
(which is still used in modern
microwave ovens).
The first practical application of
this system was for Radio Detection
And Ranging, better known as its
acronym RADAR. The operation of
radar is based on the transmission of
a series of SHF waves at regular
intervals. When these waves hit an
object of sufficient mass then part of
them will be reflected back to the
transmitter, where an aerial can
detect them.
In the original systems the start of
the horizontal sweep in the cathode-
ray tube was synchronised with the
transmission of the signal burst and
the return signal received by the aer-
ial was fed to the vertical deflection
amplifier. When the aerial received a
return signal (the waves reflected
back by an object) a spike could be
seen further to the right of the tube,
the position depending on the dis-
tance of the object (see Figure 1).
This system could not only be
used to detect the presence of every
object (aeroplane) that was in its
field of ‘view’, but it could also deter-
mine the distance accurately
between the aerial and the object,
since the propagation speed of the
waves and the rate of horizontal
deflection (time base) were known.
This is how R.A.D.A.R. came about,
an acronym that soon turned into an
everyday word.
Subsequently the radar was
improved to cover all of the sur-
rounding area rather than just a
small section directly in front of the
aerial. This was done by mounting
Everything you always wanted to know about
Speed Cameras
but were afraid to ask…
By: B. Bouchez
Feared by many motorists (let those who have never driven too fast cast
the first stone), the speed camera, usually containing a radar, is an
electronic device whose workings are still a mystery to most electronics
hobbyists. In this article we take the covers of these curious devices and
describe their operation in detail, also considering a few ideas to guard
against their actions.
A little bit of history
Many, many years ago, the investigations car-
ried out on electromagnetic radiation in the
thirties revealed that RF waves appeared to
be reflected back from some objects. This
property became more discernible as the fre-
quency was increased (above 100 MHz). It
wasn’t until the end of the thirties that SHF (f
>1GHz) waves could be generated easily,
thanks to the introduction of the magnetron
(Source: Applied Concepts, Inc. / Stalker Radar)

GENERALINTEREST
1911/2002 Elektor Electronics
sure the speed of vehicles, we’ll take a look
at the commercial applications that are found
at the side of the road.
The basis of every speed camera (let’s call
it a radar) is a SHF generator, which can
transmit a beam in a specific direction. From
the previous section we have learnt that the
sensitivity of the device is directly propor-
tional to the frequency of the beam. The exact
frequency used depends on the manufacturer,
but is generally between 2 GHz and 15 GHz.
The device can either have a SHF oscillator
based on a Gunn diode and a resonant cav-
ity, or a transistor oscillator followed by a
power amplifier. The power of these oscilla-
tors is not very high (usually less than 10
mW), but the effective power output is
increased through the use of a directional aer-
ial.
The receiver for the reflected signal is
often based on a Schottky diode, situated at
the focal point of the aerial (usually the same
aerial is used for transmission and reception),
which functions as a mixer of the transmitted
and reflected signals.
The output signal of the receiver is ampli-
fied, conditioned by an analogue circuit and
then passed on to the measurement section,
which is nothing more than a frequency
counter.
the aerial assembly on top of a
turntable (the cathode-ray tubes
were now given deflections in two
directions).
Introducing the Doppler
effect
The device just described is not
capable of determining the speed of
the detected object; this was limited
to measuring the movement of the
echo on the screen, which gave a
rather inaccurate result.
As an example, consider a car
that makes a sound with a fixed fre-
quency (a car that is driven with
fixed revs for example). When you
are in the car you won’t notice any
variation in the frequency of the
engine sound.
If however you stand at the side
of the road and listen to the car
when it drives past under identical
conditions you will notice that the
frequency of the engine sound
increases as the car comes nearer
and then decreases as the car trav-
els past you. (This effect is also
noticeable in F1 Grand Prix races
when the cars roar past the camera.)
This phenomenon works the other
way round as well: when you drive
your car past somebody who is
shouting on the pavement, you
should notice that the frequency of
the shouting increases as you go
towards the person, and then
decreases as you move away.
When the distance between the
sound source and the receiver
remains constant then the frequency
of the received signal won’t vary
either.
The Doppler effect (named after
the physicist who discovered it) is
nothing more than that described by
the formula in Figure 2:
fM= 2 vf
Ecos (α/c)
where
fMis the frequency of the received
signal.
v is the speed of the vehicle.
fEis the frequency of the transmitted
signal.
αis the angle between the transmit-
ter and the path along which the
vehicle travels.
cis the propagation speed of the sig-
nal in air (300,000 km/s for radio
waves, 340 m/s for sound
waves).
From this we can deduce that
sending a fixed frequency signal
towards the car and then measuring
the frequency of the returning signal
will give you the speed of a car.
This is the principle used for
radars in speed cameras, although
they have little in common with the
systems described in the first part of
this article.
It should be mentioned that the
sensitivity of the radar increases as
the angle between the beam and the
path of the vehicle decreases. For
this reason the aerials of speed cam-
eras are positioned parallel to the
roads rather than across them! This
is also the reason why few types of
radar can work along bends, since
the angle between the beam and the
vehicle continually changes, creating
errors in the measurements.
From theory to practice!
Now that we’ve seen how the
Doppler effect can be used to mea-
frequency
generator
controlled
SHF
oscillator
synchronised
sawtooth
generator
switch
TX/RX antenna
transmitted
burst
received
burst
020165 - 11
return
signal
amplifier
horizontal
amplifier
vertical
amplifier
Figure 1: Principle of operation of first generation radars (1940).
Figure 2: The Doppler effect.
020165 - 12
V
fE
fM
direction of vehicle M
Speed check
TX/RX
M
α

The signal from the frequency counter
goes to a microprocessor that calculates the
speed and sends it to a display. It also checks
if the measured speed exceeds a preset value
and warns the police officers who are nearby
that an offender has just passed, or it acti-
vates a camera and flashgun.
In short, the basic principles behind a high
frequency speed detector (Figure 3) are not
very complex. (Note that we’re talking about
the principles, a practical implementation is
something else altogether, especially the high
frequency section.)
How well does it work?
Now that we know how it all works we may
wonder how reliable the measurements made
by these devices are. Let’s keep one thing
clear: we have no intention of encouraging
any of our readers to break the speed limit or
behave irresponsibly. We just want to look at
the problem from a technical viewpoint to dis-
cover what the limits are of SHF speed cam-
eras. In this way we can distinguish between
proven facts and ‘rumours’ that are doing the
rounds, made by people with little knowledge
of electronics. Instead of straying into difficult
technical considerations we’ll just answer the
most common questions.
Operation during rain or mist: in contrast to
widespread opinion, radar works perfectly
well during rain or mist (after all, radar is
used extensively to help with the landing of
aeroplanes in bad weather!). In general,
when it rains it comes down vertically (at
least it does here!), which is at right angles
to the radar beam, bringing about a Doppler
effect of zero (cos 90° = 0, so fM= 0). Heavy
rain that comes down at an angle due to
strong gusts of wind can affect the signal-to-
noise ratio of the receiver and prevent its cor-
rect operation. In this case the processor will
simply reject the measurements.
Since mist doesn’t move with respect to
the radar beam (or only very slowly) it will be
practically invisible to the receiver and the
measurements are completely unaffected.
Measurement range: the distance from which
a radar can measure the speed of a vehicle
depends on two factors: the power of the SHF
oscillator and the sensitivity of the detector.
We already knew that the oscillator power is
generally low and that the use of a directional
aerial increased the transmitted power. The
biggest problem for the detector is the signal-
to-noise ratio, which doesn’t get any better
with Schottky diodes. In this section the sen-
sitivity can also be improved through the use
of aerials. Whilst the first radars could only
take measurements up to twenty
meters, the newer models with their
ultra-sensitive detectors are capable
of taking measurements over several
hundred meters, so well before they
can be seen from the car!
Reaction time: just as with any other
equipment that use frequency coun-
ters, these speed cameras also
require a certain time to take a mea-
surement. Furthermore, most
devices now take several measure-
ments rapidly, making it possible to
reject any possibly erroneous mea-
surements. Older models required
about half a second to take a reliable
measurement. Current models react
within a tenth of a second, so any
motorist who ignores the speed limit
will have very little chance of avoid-
ing a fine after noticing a speed
camera. Sometimes the radar equip-
ment also contains a DSP (Digital
Signal Processor), which uses a spe-
cial algorithm with a very short pull-
in time, making extremely fast read-
ings possible.
Continuous transmission: in contrast
to what you may have thought after
reading the theoretical part of this
article, a radar does not need to have
its oscillator functioning continu-
ously. It only needs to be active long
enough to stabilise and take a mea-
surement. Actual radar equipment
works on a random basis or is acti-
vated only when a vehicle comes
nearby.
Discrimination: when several vehi-
cles travelling at different speeds
encounter a radar beam, the result-
ing Doppler signal contains a mix-
ture of signals at different frequen-
cies. The majority of current devices
can’t separate these components
and reject the measurement as
faulty. There are however newer sys-
tems that contain a DSP (the author
has worked on one of these sys-
tems), which can measure the speed
of several cars simultaneously. So
now only those cars that happen to
be in the ‘shadow’ of others can
escape the speed cameras.
The long and short of it is that
speed cameras have become so
accurate and reliable (which can be
confirmed by drivers who don’t keep
to the speed limit), that it has
become extremely difficult to evade
them!
On the wrong side
of the law
Mankind, and especially homo auto-
mobilis, behaves in such a way that
when he comes across an obstacle
he will try everything to get round
GENERALINTEREST
20 Elektor Electronics 11/2002

cult by the fact that very narrow beams are
used, making for a small ‘detection area’.
Some users of radar detectors have noticed
that the beam can also be detected when it
is reflected off other cars ahead and have
gladly made use of this property.
And now for the final problem: most radar
equipment can take measurements of
approaching (from the front) or receding (from
the rear) vehicles. But the sensitivity of most
detectors is limited to just one direction. To
be prepared for any eventuality the vehicle
should therefore have a detector at both the
front and rear!
And finally...
As the saying goes, if you play with fire you
may get burned. As we have seen in this arti-
cle, speed cameras have become reliable
instruments that are difficult to locate or
interfere with.
Knowing how to detect a SHF beam is one
thing; to disrupt a speed measurement is
another story. In short, although most in-car
radar detectors sold at the moment do work
and show the presence of speed cameras,
they are of little use because the speed cam-
era is likely to be triggered before the driver
can slow down.
Even though speed cameras are some-
times situated in places where they aren’t
justified (which has given rise to the name
‘euro-pump` on the continent), in our opin-
ion it shows more sense to respect the speed
limits (also out of respect for other road
users), rather than attempt to get round the
law at all costs.
(020165-1)
it. Speed cameras are no exception
to this, and numerous boffins
(whether competent or not) have
contributed to the development of
counter measures.
Before we continue we would like
to make one thing perfectly clear: in
the majority of European countries
the possession, and even more so,
the use of equipment intended to
disrupt the operation of speed cam-
eras is illegal. Indifference in this
area is not recommended, since the
consequences can be dire (handing
in of the driver’s licence, confiscation
of the vehicle, prosecutions, etc.).
In spite of this, some drivers think
it is worth the risk and don’t shrink
back from using these devices.
Loosely speaking, there are two
types of ‘anti-radars`: jamming
devices and detectors.
The jamming devices are simply
small SHF oscillators, which are
used to send a ‘fake’ signal back to
the speed camera, causing the mea-
surement to fail and preventing the
logical analysis of the frequency.
Besides the fact that these devices
are relatively ineffective (in most
radars the circuits are less sensitive
to interference signals: the frequency
of the jamming signal therefore has
to be as close as possible to that of
the speed camera, and every device
has its own frequency), the elec-
tronic circuits in the radar can detect
such jamming signals and notify the
police. A jamming device is therefore
a sure-fire way to get caught!
A detector on the other hand con-
sists of a simple SHF receiver, and
by definition these can’t be
detected. In the USA (where their
use is permitted) they are sold in
large quantities. On the Internet
they are readily available and in
some European countries they are
also freely available (their sale is
permitted but their use isn’t!). These
are usually relatively simple circuits
containing a microwave detector
and a comparator that drives an
alarm. In short, simplicity itself
(although their price seems to sug-
gest the opposite is true!).
It isn’t difficult to design a broad-
band detector that reacts to fre-
quencies between 2 and 10 GHz,
which is the range where most mod-
ern devices operate. However, if the
oscillator of a speed camera is set to
a frequency that is outside the range
covered by the detector, or it uses an
optical laser, then you’re bound to
get caught.
The second problem is that in
order to detect something, there first
has to be something to detect (obvi-
ous, isn’t it?). Older radar equipment
transmitted continuously, which
made the task simpler, but newer
models only transmit intermittently,
either randomly or in short bursts,
reducing the chance of detecting
these devices. Some models (such as
the Mesta 208 sold in France where
the author lives) are even more cun-
ning and only come into action when
a car comes within their range.
These ‘green bullets’, as they are
known because of their shape and
colour, have an optical detector on
top that literally sees the vehicles
coming.
As soon as there is some move-
ment in front of the device it springs
into action.
This brings us to the third prob-
lem: a radar detector will sense the
beam at that instant. But at the
same time the speed camera is
already doing its work. From this it
follows that in the time taken by the
driver (a typical reaction time for
people is about half a second) to
take appropriate action (to brake or
disrupt the measurement), the radar
will already have taken four or five
measurements.
The detection is made more diffi-
GENERALINTEREST
2111/2002 Elektor Electronics
020165 - 13
SHF
oscillator
(2 – 10 GHz)
command
processor amplifier/
shaper analyser
display
TX/RX
parabolic antenna
Receiver/mixer
Figure 3: Basic principle of a high-frequency speed camera.

TEST&MEASUREMENT
24 Elektor Electronics 11/2002
We can thank an EU direc-
tive dating from 1998 for
the introduction and stan-
dardisation of the OBD-2
vehicle diagnostic connec-
tor. The connector is stan-
dard on all spark-ignition
engined vehicles from
2000 and should be fitted
to diesel engined variants
by 2003. The communica-
tion protocols used can
come in three different
varieties. In Europe the
most common protocol is
the ISO standard. All of
these protocols rely on
serial data transfer
but the
Vehicle Diagnostics
Adapter
Interface between an OBD-2 vehicle diagnostic
connector and a serial PC port
Design by G. Müller
In last month’s article we took a look at the background and specification
of the OBD-2 diagnostic connector fitted to new cars. Now, as promised
we present an interface adapter that allows your car to confess its
innermost secrets to your computer.

TEST&MEASUREMENT
2511/2002 Elektor Electronics
XT1 (Pin 2) and XT2 (Pin 3)
Connect a 3.579545 MHz crystal (NTSC TV
colour burst) between these two pins. A
capacitor (typically 27 pF) is fitted to each of
these pins down to Vss.
LFmode (Pin 4)
This input selects the default linefeed mode
after a reset or at power-up. A high-level on
this pin will mean that each line sent by the
ELM323 will be terminated by a carriage
return (CR) and line feed (LF) character. A
Low level on this input will mean that each
line sent will be terminated by a carriage
return only. The mode can also be changed in
software by issuing the ATL0 or ATL1 com-
mand from the AT command set.
RS232Rx (Pin 5)
The RS232 transmit signal can be connected
directly to this pin providing that a current
limiting resistor (typically about 47 kΩ)is con-
nected in series. On-chip diodes ensure that
signal levels and message format are
not compatible with the serial com-
munications port of a Personal Com-
puter.
The interface adapter described
here contains a pre-programmed
microcontroller produced by the
company Elm Electronics of Canada.
This controller together with a few
external components allows the OBD
vehicle connector to communicate
with the serial port of a PC, laptop or
PDA running a terminal emulation
program. Alternatively a more
sophisticated program can be devel-
oped for the PC to provide a better
user-interface and allow interpreta-
tion and resetting of failure codes,
together with real-time display of
actual sensor information. In a fol-
low-up article we will look at the
development of just such a program
and describe in detail the steps nec-
essary to produce the finished pro-
gram. The source code for this pro-
gram is written in C and can be
ported to any of the common operat-
ing systems such as Linux, BeOS, or
QNX using the freely available gcc
compiler program. The source code
together with a version of the pro-
gram compiled to run under Win-
dows will be available to download.
The interpreter chip
The ELM323 was specifically
designed as a low-cost solution for
interfacing a PC or PDA to a vehicle
diagnostics connector. To keep things
simple it communicates at a fixed
baud rate of 9600 baud and does not
offer a handshaking option for the
RS232 interface. In addition it is only
able to communicate using the
10.4 kHz ISO 9141 Protocol. This stan-
dard is the most common used by the
majority of European and Asian man-
ufacturers. Vehicles built in the US
use VPW and PWM protocols and
suitable interpreter chips are also
available from Elm Electronics.
The most important technical
specifications of the ELM323chip are
listed under the heading ‘Technical
Data’ The pinouts are shown in Fig-
ure 1 and the internal block diagram
is in Figure 2. The pin descriptions
now follow:
VDD (Pin 1)
This pin is the positive supply pin
and should be the most positive
point in the circuit (see the technical
specifications). An internal power-on
reset is derived from this pin to ini-
tialise the microcontroller.
Figure 1. The ELM323 pin-outs.
ELM323 Technical Data
Absolute maximum ratings:
Storage temperature –65 °C to +150 °C
Ambient temperature with power applied –40 °C to +85 °C
Voltage on VDD with respect to VSS 0 to +7.0 V
Voltage on any other pin with respect to VSS –0.6 V to (VDD + 0.6 V)
Electrical characteristics
All values assume operation at 25 °C and 5 V supply unless otherwise stated. For further details refer to note 1 below.
Characteristic Minimum Typical Maximum Units Conditions
Operating voltage VDD 4.5 5.0 5.5 V
VDD rate of rise 0.05 V/ms See note 2
Average supply current IDD 1.0 2.4 mA See note 3
Input low voltage VSS 0.15 VDD V
Input high voltage 0.85 VDD VDD V
Output low voltage 0.6 V Current (Sink) = 8.7 mA
Output high voltage VDD – 0.7 V Current (source) = 5.4 mA
RS232Rx Pin input current 0.5 0.5 mA See note 4
RS232 Baud rate 9600 Baud See note 5
Notes:
1) This chip has a PIC16C505 from Microchip Technology as a core embedded micro-
controller.
2) This spec must be met to ensure that a correct power-on-reset occurs. If the supply
rises too slowly problems with the internal reset occur.
3) Device only. Without any load current.
4) This value represents the current flowing through the input protection diodes when
applying large voltages to the RS232Rx input (pin 5) through a current limiting resistor.
Values given are the maximum that should be allowed to flow continuously.
5) Nominal data transfer rate when the recommended 3.579 MHz crystal is used as the
frequency reference. Data is transferred to and from the ELM323 with 8 data bits, no
parity and 1 stop bit (8 N 1).

inputs to the ELM323 are protected against
overvoltage while Schmitt triggers reduce the
effects of noise on the inputs.
RS232Tx (Pin 6)
The ELM323 transmits data from this output.
The signal level is compatible with most
interface driver IC’s and there is even enough
current to use a single PNP transistor as a
line driver.
LED Drive outputs (Pin 7, 8, 9 and 10)
These four pins are low when the ELM323 is
transmitting or receiving RS232 or OBD data.
Providing that a suitable series current limit-
ing resistor is fitted, the outputs can source
or sink sufficient current to directly drive an
LED.
OBDIn (Pin 11)
The serial OBD-Data is input on this pin. A
logic high represents the active state of the
OBD K line. There is no Schmitt trigger fitted
to this input so an external input buffer
should be employed to reduce the input sig-
nal transition times.
OBDL (Pin 12) and OBDK (Pin 13)
These active-high output signals are used to
drive the OBD bus using external NPN driver
transistors. Data transfer normally occurs
over the K line but the standards specify that
the driver for the L line be implemented also
to ensure the bus is properly initialised. More
on this later.
VSS (Pin 14)
The common ground pin. (The most negative
point in the circuit).
The Interface circuit
The SAE Standard J1962 stipulates
that all OBD compliant vehicles must
provide a standard connector close
to the driver’s seat. The shape and
pinouts of the 16-pin connector has
already been described in the previ-
ous article (Card Diagnosis Systems,
Elektor Electronics October 2002).
The circuit described here plugs
directly into this connector without
any changes necessary to the vehi-
cle.
The male J1962 connector (Figure
3) needed to plug into the vehicles
connector may be difficult to obtain
(see parts list) and you may be
tempted to improvise by connecting
to the back of the vehicle’s OBD con-
nector. If you attempt this, it should
be stressed that you should do noth-
ing to compromise the integrity of
the vehicle’s OBD network. The use
of any type of connector that could
easily short out pins (e.g., the RJ11
type phone connector) is not recom-
mended.
The circuit of the OBD/RS232
interface with the ELM323 is shown
in Figure 4. Power is derived from
the vehicle battery (nominally
14.4 V) via pin 16 of the OBD con-
nector (K1) while the vehicle earth is
at pin 5. Voltage regulator IC2 pro-
vides 5 V for the circuit and its built-
in current limit offers some protec-
tion for the circuit. Diode D7 gives
reverse polarity protection. LED D8
‘power’ indicates that the 5 V supply
is available.
TEST&MEASUREMENT
26 Elektor Electronics 11/2002
Block Diagram
2 3
XT1 XT2
0200138 - 12
5
6
Timing and
Control
Interpreter
OBD
Interface
OBDK
11
13
OBDIn
4
OBDL
12
RS232Tx
RS232Rx
LFmode
7
RSRx OBDTx
10
OBDRx
9
RSTx 8
3.58MHz
RS232
Interface
18
020138 - 2 - 13
OBD
916
Figure 2. Block diagram for the OBD-2/RS232 converter.
Figure 3. The 16-pin connector for the vehicle
diagnostic connector.

of data flowing at both the OBD and RS232
interface. The two groups of LEDs share a
common current limiting resistor because
data will only be flowing in one direction at
any one time on either of the two interfaces
(the ELM323 is not capable of true multitask-
ing). The OBD bus may also be in its initiali-
sation phase when RS232 data is sent to it so
these limiting resistors are separate for the
OBD and RS232 interface.
A crystal is fitted between pins 2 and 3 of
IC1 along with two 27 pF loading capacitors.
The capacitor values shown are typical but
these may need to be changed depending on
the crystal specification. The frequency cho-
sen is that of the NTSC standard TV colour
burst crystal and should be relatively cheap
and widely available.
Construction and test
The layout for the circuit can be seen in Fig-
ure 4. Although the PCB is single-sided it
does not need any wire links to be fitted. Con-
nector K2 is a 9-way sub-D socket (do not
make the mistake of fitting a plug).
As for the RS232 cable make sure that it is
The remaining two connections to
the vehicle (OBD Pin 7 and 15) are
the data lines described in the ISO
9141 and ISO 14230 standards. In
accordance to the standards pin 7 of
the connector is the K output while
pin 15 is the L output. We will refer
to these as the K line and L line of
the OBD system. To comply with the
specification, the ELM323 controls
these two lines using NPN transis-
tors with 510 Ωpull-up resistors.
The adapter circuit receives diag-
nostic data from the K line (pin 7 on
the OBD connector). The data is
inverted by transistor T3 before it is
read by IC1 (pin 11). This transistor
stage raises the threshold voltage to
around 4 V instead of the standard
2.5 V for a CMOS input. The effect of
this is to improve noise immunity on
the input and the stage gain speeds
up signal transition times.
For the interface to a computer
there is a very simple RS232 imple-
mentation using just RxD (Pin 2) and
TxD (Pin3) of the 9-pin sub-D con-
nector. Most RS232 interface circuits
require a voltage converter to pro-
duce a negative supply to allow the
correct signal swing for RS232 sig-
nals. This design however, stores
negative charge from the TxD line
onto capacitor C3 to ensure that data
output from the ELM323 will swing
negative when T4 switches off.
Resistor R12 limits the input current
from the computer. R13 ensures that
the RS232 input (IC1, pin 5) will be
pulled low when the connector at K2
is disconnected. Transistor T4 drives
RS232 data to the PC. The signal
voltage will swing between +5 V
(high) when T4 is conducting to
–5.1 V (low) from the negative
charge stored on C3 when T4 is off.
Despite the simplicity of this RS232
interface it works very well.
Pin 4 of IC1 is tied high to force
the microcontroller to send a line
feed (LF) character after each car-
riage return (CR) character.
The four LEDs connected to pins
7, 8, 9 and 10 give a visual indication
TEST&MEASUREMENT
2711/2002 Elektor Electronics
+5V
X1
3.579545MHz
C1
27p
C2
27p
K2
DB9
1
2
3
4
5
6
7
8
9
D4 D5D3 D2
R8
330Ω
R9
330Ω
C6
100n
C4
100n
C5
100n
C3
100n
R10
10k
R12
47k
R2
2k2
R4
2k2
R6
10k
R1
510Ω
R3
510Ω
R5
10k
R7
4k7
R11
4k7
R13
100k
T3
BC557B
T4
BC557B
T1
BC547B
T2
D6
1N4148
D1
1N4148
RS232Rx
RS232Tx
ELM323
LFmode
OBDIn
OBDRx
OBDTx
IC1 RSRx
RSTx
OBDL
OBDK
XT2XT1
11
14
10
12
13
23
1
5
4
6
7
8
9
78L05
IC2
D8
R14
680Ω
POWER
+5VD7
1N4001
K1
10
1112
1314
1516
12
34
56
78
9
2x
020138 - 11
OBD
(ISO)
RS232
5V
– 5V1
– 0V5
– 9V3
– 8V9
Figure 4. The OBD-2 to RS232 adapter circuit diagram.

a standard extension cable with the pins
wired 1:1; not a null modem cable where the
wires are connected quite differently.
Refer to the parts list for suppliers of the
special components used in this design.
(ELM323 and OBD plug). Hopefully a UK sup-
plier emerges following publication of this
article.
Once everything has been soldered in
place check closely that all the components
are correctly fitted and that there are no sol-
der bridges on the track side. Now the circuit
is complete you are probably anxious
to try it out, but resist the temptation
to plug it into the vehicle connector
without first making some prelimi-
nary tests. Power up the circuit on
the bench using either a 12 V mains
supply or a 9 V battery together with
a computer with a serial interface.
Connect the power supply positive
to pin 16 (+ 12 V) and the negative
to pin 5 (ground). If everything is in
order the green LED will come on to
indicate that the circuit has power),
The red LEDs will then briefly light.
The 5 V supply can now be checked.
When everything is in order the
next step is to connect the vehicle
adapter to the serial port of a PC. It
is now possible to check voltages
around the circuit and compare them
with the typical values given on the
circuit diagram. The +5 V and –0.5 V
shown on pins 6 and 5 of IC1 should
be fairly close to these values but the
voltage on pin 3 of connector K3 is
derived from the PC and depends
largely on the type of interface chip
used in the external computer. It can
be anything from about - 3 V to
- 12 V. The voltage on capacitor C3 is
dependent on the level of this volt-
age and should be about one diode
drop (0.4 to 0.6 V) higher than the
voltage measured at the TxD pin. In
the circuit diagram TxD is assumed
as –9.3 V which then gives -8.9 V
after the voltage drop across D6.
Should you find that the voltage
levels are substantially lower than
the values shown on the diagram
then it is important to find the prob-
lem before we can proceed any fur-
ther. A short circuit on the RS232
interface will usually not result in
damage to the PC because the sig-
nals are current-limited.
For a functional test of the serial
interface we obviously need some
software to run on the PC to send
and receive serial data. The win-
dows program accompanying this
project (to be described in a follow-
up article) would be a suitable tool
for this job but if you are anxious to
TEST&MEASUREMENT
28 Elektor Electronics 11/2002
(C) ELEKTOR
020138-1
C1
C2
C3
C4
C5
C6
D1
D2 D3 D4 D5
D6
D7
D8
H1 H2
H3H4
IC1
IC2
K1 K2
R1 R2 R3 R4
R5 R6 R7
R8 R9
R10
R11
R12
R13
R14
T1 T2
T3
T4
X1
020138-1
(C) ELEKTOR
020138-1
Figure 5. The PCB layout (board available ready-made).
COMPONENTS LIST
Resistors:
R1,R3 = 510Ω
R2,R4 = 2kΩ2
R5,R6,R10 = 10kΩ
R7,R11 = 4kΩ7
R8,R9 = 330Ω
R12 = 47kΩ
R13 = 100kΩ
R14 = 680Ω
Capacitors:
C1,C2 = 27pF
C3-C6 = 100nF
Semiconductors:
D1,D6 = 1N4148
D2-D5 = LED, red
D8 = LED, green
D7 = 1N4001
T1,T2 = BC547B
T3,T4 = BC557B
IC1 = ELM323 *
IC2 = 78L05
Miscellaneous:
K1 = 16-way boxheader
K2 = 9-way sub-D socket (female), angled
pins, PCB mounting
X1 = 3.579545MHz quartz crystal (NTSC),
32pF parallel resonance
16-way OBD-2 plug *
PCB, order code 020138-1 (see Readers
Services page)
*Suggested source for ELM323 and OBD
plug kit:
Küster Datensysteme (KDS)
Geibelstrasse 14
D-30173 Hannover
Germany
Tel. [phone]
Fax [phone]
E-Mail: [e-mail]
*OBD connector parts also available from
www.scantool.net
www.autoxray.com

should be able to unravel all of your vehicles
secrets. We have gathered together some
information to help you in this quest and all
of this is available to download from the Elek-
tor Electronics website under the following
headings:
–Communication between the PC and the
ELM323.
–AT commands.
–OBD bus initialisation.
–OBD commands.
–Diagnostic test modes.
–Read out and evaluation of fail codes.
–Clearing fail codes.
–ELM232 fail codes.
This detailed information should be of inter-
est not only to anyone building this project
but also to those of you thinking of develop-
ing an application based around the OBD sys-
tem. In a forthcoming article we concentrate
on the software for this project and include
tips and code examples along with the other
programs already mentioned above.
(020138-2)
Note:
Much of the material in this article is taken from a
data sheet from Elm Electronics, Canada. The
original can be downloaded from:
www.elmelectronics.com/dsheets.html
test the interface then a terminal
emulator program such as HyperTer-
minal will do. With any luck it should
already be loaded on your Windows
system, usually in ‘Program Files’
under ‘Accessories’. If not then the
program can be downloaded free of
charge from: www.hilgraeve.com
HyperTerminal should be initialised
with the following communication
parameters: Data rate 9600 Baud, 8
Data bits, no Parity bit, 1 Stop bit
and no handshake (no hardware
handshake and no XOn/Xoff hand-
shake). This is abbreviated to:
9600,8N1.
Assuming that the interface is
correctly connected you should see
the four red LEDs light up and the
following message will appear on
the screen:
ELM323 v1.0
>
This gives the version number of the
microcontroller software and also
indicates that the IC is working cor-
rectly, and that the communication
baud rate and receive path (the Rx
input to the PC) is in order. The ‘>’
character is a prompt issued by the
ELM323 indicating that it is ready to
accept data from the RS232 port.
Messages from the PC can be
intended for the internal use by the
ELM323 or for the vehicles diagnostic
system. The ELM323 handles all the
communication and determines the
message destination by analysing
its character strings. Commands for
the ELM323 are always prefixed
with ‘AT’ commands just like the
command set for Hayes compatible
modems, while instructions for the
OBD are ASCII coded hexadecimal
numbers (0 to 9 and A to F). As a
test, enter the command ATE1 (turn
echo on) followed by the enter key, if
there is no ‘OK’ response check the
earth connection (Pin 5) and check
the settings in the terminal emulator
program to ensure that ‘No hand-
shake’ is selected.
now for the car clinic
It is undoubtedly easier to communi-
cate with the OBD system by using
the Windows based program that
we referred to earlier. This program
will be featured in the next article on
this project. If you can’t wait, then
the terminal emulator can meet out
needs again; armed with a copy of
the OBD-2 interface documentation
and the ELM323 command set you
TEST&MEASUREMENT
2911/2002 Elektor Electronics
Figure 6.The fully populated PCB. The red LEDs indicate transmitting and receiving data through the ports.

MICROCONTROLLER
30 Elektor Electronics 11/2002
In the Windows Device Manager, you will see
all currently connected USB devices listed
under ‘USB Controller’. Figure 1 shows the
entries for a USB device using the Cypress IC
with no EEPROM and a USB data spy for Bin-
Ter m.
Writing your own complete driver ‘from
the ground up’ is almost impossible for nor-
mal mortals. Fortunately, Cypress provides
the EZUSB driver not only as an installable
version, but also in the form of source
code.
A device driver is divided into two parts,
consisting of an INF file containing setup
information and a SYS file, which is the actual
device driver. The INF file can be edited using
a simple text editor. A C++ compiler is
necessary for generating the SYS file.
If you do not already know how to pro-
gram in C, that’s not such a big hurdle. You
will need Microsoft Visual Studio 6 with the
DDK (Driver Development Kit) addition for
Windows 2000, and naturally you will also
need the device driver source code from
Cypress.
Be sure to install Visual Studio and related
packages without modifying the installation
paths. For the device driver, you will need the
EZ-USB Development Kit, which you have
USB Driver
Programming (2)
writing your own device driver
By M. Müller and C. Ehmer
In the previous issue of Elektor Electronics, we described how device drivers
are used. Now it’s time to modify a Cypress device driver. You only need a
couple of programs for this, even if you have never worked with Microsoft
Visual Studios. All of the
necessary steps are
described in minute detail.
Figure 1. The Windows Device Manager list with a user-generated driver.
Required items
System requirements:
Windows 2000 or Windows XP
Internet access
Programs and tools:
MmVisual BinTerm, version 2.2.2421 or later
Borland Delphi 6 or Microsoft Visual Basic
Cypress Semiconductor EZ-USB Development Kit
Microsoft Visual C++ 6
Microsoft DDK2000 Driver Development Kit for Windows 2000
Hardware
A working Cypress AN2131SC IC (with EEPROM) connected to the USB, or a BinTerm
adapter connected to the USB. The latter circuit will be described in a coming issue of
Elektor Electronics. A BinTerm adapter connected to the USB is highly suitable for
experimental projects, since it avoids the need to store program code in EEPROM. All
programs are transferred to the device by BinTerm at runtime.

MICROCONTROLLER
3111/2002 Elektor Electronics
with your own driver. The items to be modi-
fied are shown in bold in Listing 1.
Before starting to edit the INF file, save it
with a new name, and then enter the new
name in the [xxx.Files.Inf] section. Next,
change the company name (‘Cypress’) to your
own name. The descriptors that Windows
displays in the Device Manager window are
entered in the [Strings] section. The device
driver that you produce should also have a
new SYS file. Give the existing SYS file a new
name, such as ‘MYSYS.SYS’, and correspon-
dingly change all ‘EZUSB’ identifiers to
‘MYSYS’. Ensure that the file name of the
device driver does not contain any non-stan-
dard characters or spaces — in other words,
use only letters and numerals, with at most
eight characters!
The most important items are the VID and
PID numbers. They may lie in the range of 1
to 65534, and they are given in hexadecimal
form. A VID number can be rented (for a fee)
from the USB Organisation (www.usb.org) by
anyone who wants to do so. If the VID is regi-
stered, the product is allowed to carry a USB
symbol and the number is guaranteed to be
unique. However, the fee is not exactly cheap.
The solution proposed here is to use freely
already installed and used in Part 1
of this series.
Setup information
Windows always needs an INF file
for installing a device driver. Such a
file contains the data specifying
what should be installed, where it
should be installed and how it
should be installed. This file should
be modified to meet your particular
needs, since you don’t want the
Cypress device driver to conflict
R2
4k7
R3 8
VCC
VCC
GND
1
2
3
7
E0
E1
E2
WC
020109 - 12
4
5
6
SDA
SCL
SDA
SCL
35
36
4k7
IC3a
24C64
IC1c
AN2131SC
EEPROM connection
Figure 2. Circuit diagram of the EEPROM extension.
Table 1
[Version]
provider=%Cypress%
[Manufacturer]
%Cypress%=Cypress
[Cypress]
%USB\VID_0547&PID_2131.DeviceDesc%=EZUSB.Dev, USB\VID_0547&PID_2131
[DestinationDirs]
EZUSB.Files.Ext = 10,System32\Drivers
EZUSB.Files.Inf = 10,INF
[EZUSB.Dev]
CopyFiles=EZUSB.Files.Ext, EZUSB.Files.Inf
AddReg=EZUSB.AddReg
[EZUSB.Dev.NT]
CopyFiles=EZUSB.Files.Ext, EZUSB.Files.Inf
AddReg=EZUSB.AddReg
[EZUSB.Dev.NT.Services]
Addservice = EZUSB, 0x00000002, EZUSB.AddService
[EZUSB.AddService]
DisplayName = %EZUSB.SvcDesc%
ServiceBinary = %10%\System32\Drivers\ezusb.sys
[EZUSB.AddReg]
HKR,,NTMPDriver,,ezusb.sys
[EZUSB.Files.Ext]
ezusb.sys
[EZUSB.Files.Inf]
ezusbw2k.Inf
[Strings]
Cypress=”Cypress Semiconductor”
USB\VID_0547&PID_2131.DeviceDesc=”Cypress EZ-USB (2131Q/2131S/2135S) - EEPROM missing”

selected VID and PID numbers. This means
that conflicts can arise with devices from
other manufacturers. We suggest changing
the VID number to ‘8B16’ and the PID number
to ‘A001’.
The VID (vendor ID), PID (product ID) and
DID (device ID) form a set of three 16-bit data
words that the Cypress IC reports to the ope-
rating system. The VID and PID numbers are
used to search for, install and load
the device driver.
In order to be able to use your
VID and PID with the Cypress IC,
you will need an EEPROM. Figure 2
shows how an 8-KB EEPROM can be
added to the circuit used in Part 1 of
this article series. Program the follo-
wing sequence of numbers into the
EEPROM, starting at address 0:
B0h start byte
copy IDs
16h, 8Bh VID = 8B16h
01h, A0h PID = A001h
01h, 00h DID = 0001h
The next time the USB device is
plugged in, the Cypress IC will
report this new identifier to the ope-
rating system, allowing Windows to
install a suitable driver.
Using C++ to modify the
SYS device driver
Start Visual C++ Studio, select
‘Open Working Area’ from the ‘File’
menu and open the file named
MICROCONTROLLER
32 Elektor Electronics 11/2002
Figure 3. Testing the device driver in BinTerm.
Table 2
NTSTATUS DriverEntry( IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath)
{ NTSTATUS ntStatus = STATUS_SUCCESS;
PDEVICE_OBJECT deviceObject = NULL;
: :
DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = Ezusb_ProcessIOCTL;
: :
DriverObject->DriverExtension->AddDevice = Ezusb_PnPAddDevice;
: :
}
Table 3
NTSTATUS Ezusb_CreateDeviceObject(IN PDRIVER_OBJECT DriverObject,
IN PDEVICE_OBJECT *DeviceObject, LONG Instance)
{ NTSTATUS ntStatus;
WCHAR deviceLinkBuffer[] = L”\\DosDevices\\Ezusb-0”;
UNICODE_STRING deviceLinkUnicodeString;
WCHAR deviceNameBuffer[] = L”\\Device\\Ezusb-0”;
::
deviceLinkBuffer[18] = (USHORT) (‘0’ + Instance);
deviceNameBuffer[14] = (USHORT) (‘0’ + Instance);
Table 4
NTSTATUS Ezusb_ProcessIOCTL(IN PDEVICE_OBJECT fdo, IN PIRP Irp)
{ : :
switch (ioControlCode)
{
case IOCTL_Ezusb_VENDOR_REQUEST: // = $00222014
length = Ezusb_VendorRequest (fdo, (PVENDOR_REQUEST_IN) ioBuffer);
if (length)
{ Irp->IoStatus.Information = length;
Irp->IoStatus.Status = STATUS_SUCCESS;
} else
{ Irp->IoStatus.Status = STATUS_SUCCESS;
}
break;