Diseño Algoritmos RF
Diseño Algoritmos RF
Designers Guide
Updated 2002.08.07
Drawings
Figure 1.2.1 Radio System Model
Figure 1.2.2 Receiver Signal Processing
Figure 1.2.3.1 Noise Amplitude Probability Distribution
Figure 1.2.3.2 Signal Reception with No Noise
Figure 1.2.3.3 Signal Reception with Moderate Noise
Figure 1.2.3.4 Signal Reception with Heavy Noise
Figure 1.2.3.5 Reception with Heavy Noise (expanded scale)
Figure 2.2.1 Noise Reception with No Signal and No Threshold
Figure 2.2.2 Signal Reception with No Signal and Moderate Threshold
Figure 2.4.1 ASH Receiver Application Circuit Keyloq Configuration
Figure 3.2.1 Typical IC1000 Application
Figure 4.1 ASH Transceiver Application Circuit Low Data Rate OOK
Figure 4.2 Radio Board Modification Detail
Figure 4.3 Jumper Pin Detail
Figure 4.4 Packet and Byte Structure Details
3
1 Introduction
1.1 Why Cant I Just Use a UART?
Why cant I just use a UART and a couple of transistors to invert the TX and RX data
signals to and from your ASH transceiver and get my application on the air? Well, you
can if you dont need maximum performance and you make the necessary provisions in
your software for the characteristics of radio communications. But, you are going to leave
a lot of performance on the table. A radio link is a type of communication channel, and it
has specific properties and characteristics, just as an ordinary phone line is another type
of communication channel with its own properties and characteristics. To get usable data
communications over your phone line, you place a modem between your PCs UART and
the phone line. And to get good performance from your ASH radio link, you are going to
need to put something more than a couple of transistors between the UART and the trans-
ceiver.
1.2 The Radio Channel Magic and Imperfect
Radio is magic. It allows commands, data, messages, voice, pictures and other informa-
tion to be conveyed with no physical or visible connection. A radio wave can penetrate
most materials, and it can get around most barriers it cannot directly penetrate. It is argu-
ably the most useful electronic communication channel so far discovered.
But from a software developers point of view, a radio channel has some aggravating
properties and characteristics. The good news is there are strategies for dealing with
them.
1.2.1 Modeling a radio system
Figure 1.2.1 is a block diagram of a radio system. The antenna on the transmitter
launches energy into the RF channel, and the antenna on the receiver retrieves some of
the energy and amplifies it back to a useful level. No big deal, right? Well its no small
deal either.
4
the low-pass filter so less noise gets through. You can then successfully recover data
from a weaker received signal.
Lets go back and look at Figure 1.2.2 again. The job of the data slicer is to convert the
signal that comes through the low-pass filter and coupling capacitor back into a data
stream. And when everything is set up properly, the data slicer will output almost perfect
data from an input signal distorted with so much noise that it is hard to tell there is a sig-
nal there at all. For the time being, assume the threshold voltage to the data slicer is zero.
In this case, anytime the signal applied to the data slicer is zero volts or less, the data
slicer will output a logic 0. Anytime the signal is greater than zero volts, the data slicer
will output a logic 1. Through software techniques, you can assure that the signal reach-
ing the data slicer swings symmetrically about 0 volts. Noise spikes, either positive or
negative, that are slightly less than one half of the peak-to-peak voltage of the desired sig-
nal will not appear as spikes in the data output. The ability to recover almost perfect data
from a signal with a lot of added noise is one of the main reasons that digital has over-
taken analog as the primary format for transmitting information.
In the way of a preview, look at Figures 1.2.3.2, 1.2.3.3, 1.2.3.4 and 1.2.3.5, which are
simulations of a radio system with various amounts of noise added to the signal. The top
trace in Figure 1.2.3.2 is the signal seen at the input to the data slicer.
The horizontal line through this signal is the slicing level. Notice that the signal droops
down as it starts from left to right, so that is swinging symmetrically around the slicing
level by about the fifth vertical grid line. This is the transient response of the base-band
coupling capacitor, and its associated circuitry, as it starts blocking the DC component of
the received signal. The steady 1-0-1-0 bit pattern seen to the left of the fifth grid line
is a training preamble. It sets up the slicing symmetry. To the right of the fifth grid line
there is a 12 bit start symbol and then the encoded message bits, etc. You will notice that
7
Studies on indoor propagation show that you will find only a few spots in a room that
have really bad reception, and these severe dead spots tend to occupy a very small
space. Mild dead spots are far more common, and you will also find some places where
reception is especially good. As a rule of thumb, you need 100 times more transmitted
power indoors than in free space to get adequate reception at comparable distances. This
is called a 20 dB fading margin, and it provides about 99% coverage indoors. If you are
in a severe dead spot at UHF frequencies, moving just an inch or two gets you out of it.
When you look at a professional wireless microphone, you will notice that the base unit is
equipped with a rabbit ear antenna. Actually, there are two separate antennas and two
separate receivers in the wireless microphone base unit, with the antennas at right angles
to each other. This arrangement provides diversity reception, which greatly mitigates the
dead spot problem indoors. Since the paths between the two base station antennas and the
microphone are different, it is unlikely that the microphone will hit a dead spot for both
antennas at the same time. Mobile phone base stations also use diversity reception as do
many other radio systems, including a number of ASH transceiver systems.
1.2.5 Regulatory considerations
Systems based on ASH transceiver technology operate under various low power, unli-
censed UHF radio regulations. From a software point of view, the main differences in
these regulations are the maximum power you are allowed to transmit, and the allowed
transmitter duty cycle. European regulations (ETSI) allow the most transmitted power,
American regulations are in the middle, and Japan allows the least transmitted power. At
lower power levels, you have to transmit at a low data rate to get a useful amount of
range. At higher power levels you have more flexibility.
Duty cycle refers to the percentage of time each transmitter in your system can be on.
Some regulations, such as FCC 15.249 place no restrictions on duty cycle. Some bands in
Europe also have no current duty cycle limit - for example, the 433.92 MHz band. Other
bands in Europe do have a duty cycle limit. At 868.35 MHz, the duty cycle limit is 36
seconds in any 60 minute interval. Duty cycle requirements influence the choice of band
to operate in, and the design of your software. RFMs web site has links to many radio
regulatory sites. Be sure to thoroughly familiarize yourself with the regulations in each
geographical market for your product. We have seen cases where a customer had to redo
a well-engineered system to accommodate a regulatory subtlety.
2 Key Software Design Issues
There are at least four key issues to consider in designing ASH transceiver software. You
may identify others depending on the specifics of your products application. It is worth
giving it some thought before you start designing your code.
13
N
o
i
s
e
R
e
c
e
p
t
i
o
n
w
i
t
h
N
o
S
i
g
n
a
I
a
n
d
N
o
T
h
r
e
s
h
o
I
d
C
o
m
p
a
r
a
t
o
r
I
n
p
u
t
R
e
c
e
i
v
e
r
D
a
t
a
O
u
t
p
u
t
S
o
f
t
w
a
r
e
R
e
c
o
v
e
r
e
d
N
o
i
s
e
F
i
g
u
r
e
2
.
2
.
1
N
o
i
s
e
R
e
c
e
p
t
i
o
n
w
i
t
h
N
o
S
i
g
n
a
I
a
n
d
M
o
d
e
r
a
t
e
T
h
r
e
s
h
o
I
d
C
o
m
p
a
r
a
t
o
r
I
n
p
u
t
R
e
c
e
i
v
e
r
D
a
t
a
O
u
t
p
u
t
S
o
f
t
w
a
r
e
R
e
c
o
v
e
r
e
d
N
o
i
s
e
F
i
g
u
r
e
2
.
2
.
2
comparator. The preamble is followed by a specific pattern of bits that will not occur any-
where else in the message. This pattern is often called a sync vector, and makes it pos-
sible to distinguish data from noise with high reliability (the sync vector is 12 bits in this
example). The balance of the message consists of encoded data and error detection bits.
The purpose of encoding your data is to maintain good slicing symmetry at the input to
the comparator. This is called DC-balanced encoding. Look at Figure 1.2.3.2 again. There
are five bit periods between each vertical grid line. Notice that you will not find more
than three 1 or 0 bits in a row in the data shown, and that there are always six ones and
six zeros in any sequence of 12 bits. This is because each message byte has been encoded
as 12 bits, always with six ones and six zeros, and with no more than four bits of the
same type in a row for any combination of adjacent encoded characters. This is one type
of coding that maintains good dynamic DC balance, and is similar to techniques used in
fiber-optic data transmissions. Another popular encoding scheme is Manchester encod-
ing, which encodes each 1 bit in the message as a 1-0 bit sequence, and each 0 bit in the
message as a 0-1 bit sequence. Both 12-bit encoding and Manchester encoding work
well. Manchester encoding has a maximum of two bits of the same type in a row, but re-
quires 16 bits to encode a byte. 12-bit encoding can have up to 4 bits of the same type in
a row, and requires, of course, 12 bits to encode a byte. By the way, your start vector
should also be dynamically DC balanced in most cases.
The data rate and the encoding scheme you use affects two adjustments on the ASH
transceiver (or vice versa). The most narrow pulse or gap in your encoded data sets the
low-pass filter bandwidth. For the two encoding schemes we have discussed, this is one
encoded bit period. Once you know the bit period, Section 2.5 in the ASH Transceiver
Designers Guide explains how to set the low-pass filter bandwidth. The widest pulse or
gap in your encoded data sets the value of the coupling capacitor. Once you know the
maximum number of 1 bits or 0 bits that can occur in a row, you know the width of the
maximum pulse or gap that can occur in your encoded data. Section 2.6 in the ASH
Transceiver Designers Guide explains how to determine the coupling capacitor value
and the required training preamble length from the maximum pulse or gap width.
Trying to send data without encoding is generally a disaster. Without a threshold, any
long sequence of 1s or 0s in your data will charge or discharge the coupling capacitor,
unbalancing the symmetry of the signal into the data slicer and ruining the noise rejection
performance.
When you use one of the data encoding schemes discussed above with no slicer thresh-
old, the coupling-capacitor transient response automatically adjusts the slicing symmetry
as variations occur in received signal strength. This greatly improves system robustness
to signal flutter. You usually want to make the coupling-capacitor value no larger than
needed, so that fast signal fluctuations can be followed.
Lets now consider message encoding schemes and ASH transceiver adjustments when a
threshold is used. Again, a threshold trades-off sensitivity and flutter robustness for less
noise in the no-signal condition. If you are using a strong threshold, you may decide you
17
do not need a training preamble or start vector (this depends on the way you design your
code). But if you are using AGC and/or data slicer DS2 in your ASH transceiver, you will
need at least one 1-0-1-0 preamble byte for training these hardware functions. The
threshold in DS1 has a built-in hysteresis. When the input voltage to the data slicer ex-
ceeds the threshold level, DS1 will output a logic 1, and it will continue to output a logic
1 until the input voltage swings below zero. The DC-balanced data encoding methods al-
ready discussed work satisfactorily with the DS1 hysteresis. Again, once you know the
bit period of your encoded data, Section 2.5 in the ASH Transceiver Designers Guide
explains how to set the low-pass filter bandwidth. Note that a larger bandwidth is recom-
mended for the same bit period when a threshold is used. Using the coupling capacitor
value as determined in Section 2.6 of the ASH Transceiver Designers Guide is a good
default choice. When you use a threshold, 1 bits tend to drop out of weak and/or flutter-
ing signals at the data slicer. Message patterns that contain a few less 1 bits than 0 bits
work somewhat better with a strong threshold than classical DC-balanced codes. In some
cases you may work with encoder and decoder chips designed to send command codes.
Some of these chips send code messages with short preambles and relatively large gaps
between the messages. These chips often work better if you use a moderate threshold and
a relatively large coupling capacitor, so it is worth doing some experimenting.
2.3 Clock and Data Recovery
The clock and data recovery techniques used at the receiver are critical to overall system
performance. Even at moderate signal-to-noise ratios, the output of the data slicer will ex-
hibit some jitter in the position of the logic transitions. At lower signal-to-noise ratios, the
jitter will become more severe and spikes of noise will start to appear at the data slicer
output, as shown in Figure1.2.3.5. The better your clock and data recovery techniques can
handle edge jitter and occasional noise spikes, the more robust your radio link will be.
There is some good news about edge jitter due to Gaussian noise. The average position of
the logic transitions are in the same place as the noise-free case. This allows you to use a
phase-locked loop (PLL) that hones in on the average position of the data edges for clock
recovery. Once your clock recovery PLL is lined up, you can use the logic state at the
middle of each bit period, or the dominant logic state across each bit period as your re-
covered bit value. Testing mid-bit works best when the low-pass filter is well-matched to
the data rate. On the other hand, determining the dominant logic state across a bit period
can improve performance when the low-pass filter is not so well matched. The dominant
logic state is often determined using an integrate and dump algorithm, which is a type
of averaging filter itself.
It is possible to use simple data recovery techniques for less demanding applications
(close operating range so the signal-to-noise ratio is high). The standard protocol soft-
ware that comes in the DR1200-DK, DR1201-DK and DR1300-DK Virtual Wire De-
velopment Kits uses a simplified data recovery technique to achieve air transmission rates
of 22.5 kbps with a modest microcontroller. And yes, ordinary UARTs are being used
successfully in non-demanding applications. But a word of caution. It appears the UARTs
built into some microcontroller chips really dont like even moderate edge jitter. If you
18
are considering using a built-in UART on the radio side, do some testing before you com-
mit your design to that direction.
About now you may be wondering if anybody builds an RF UART, which is designed
for low signal-to-noise ratio applications. The IC1000 discussed below is one example of
this concept.
2.4 Communication Protocols
So far, we have discussed message encoding techniques for robust RF data transmission,
and clock and data recovery techniques that can work with some noise-induced edge jitter
and occasional noise spikes. Even so, transmission errors and drop outs will occur. The
main job of your communication protocol is to achieve near-perfect communications over
an imperfect RF communication channel, or to alarm you when a communication prob-
lem occurs. And channel sharing is often another requirement.
A protocol is a set of standard structures and procedures for communicating digital infor-
mation. A complete protocol is often visualized as a stack of structures and procedures
that are very specific to the communication hardware and channel characteristics at the
bottom, and more general-purpose and/or application oriented at the top.
Packet-based protocols are widely used for digital RF communications (and for sending
data on many other types of communications channels.) Even simple command transmis-
sions usually employ a packet-style data structure.
2.4.1 Digital command transmissions
In addition to ASH transceivers, RFMs second-generation ASH radio product line in-
cludes transmitter and receiver derivatives for one-way RF communications. Most
one-way command applications are actually two-way; RF in one direction and audible or
visual in the other direction. For example, you press the open button until you see the
garage door or gate start moving. The data encoding and data recovery techniques dis-
cussed above can be used to build a robust one-way RF communications system. But of-
ten, off-the-shelf command encoder and decoder ICs are used. Among the most popular
are the Microchip KeeLoq
TM
ICs. Figure 2.4.1 shows RFMs suggested application cir-
cuit for second-generation ASH receivers driving KeeLoq
TM
decoders. You can usually
derive enough information from the data sheets of other encoder and decoder ICs to cal-
culate the component values to use with second-generation ASH receivers. The calcula-
tions are the same as discussed in the ASH Transceiver Designers Guide.
There is a growing trend to replace one-way RF communication links with two-way links
for added system integrity. This is especially true for one-way RF communication links
that are not activated by the user. Wireless home security systems are one example.
19
Data Output
TOP VIEW
GND
3
CNT
RL0
CNT
RL1
P
W DTH
P
RATE
THLD
1
THLD
2
RREF
GND2
NC
RX
DATA
LPF
ADJ
CMP
N
BB
OUT
PK
DET
AGC
CAP
VCC
1
VCC
2
RF O
GND1
+ 3
VDC
ASH Recei ver AppI i cati on Ci rcui t
KeeLoq Confi gurati on
1
20
2 3 4 5 6 7 8 9
1 0
1 1
1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9
+ 3
VDC
270 K 330 K
4. 7 K
1 00 K
330 K
0. 1 F
1 0 F
L
AT
L
ESD
1 00 pF
+
R/S
Figure 2.4.1
Standard details the generation of this error detection code, and it is used in the protocol
code example below.
It is time to bring up the real challenge in designing and writing protocol software. Events
can happen in any sequence, and data coming into the protocol software can be corrupted
in any bit or in every bit (remember, short packets work best on a low signal-to-noise ra-
dio channel). It is worth doing a careful what if study relevant to your protocol and
your application before doing the detailed design and coding of your software. Consider
how you can force unlikely sequences of events in your testing. Thorough front end plan-
ning can avoid a lot of downstream problems.
3 IC1000 Radio UART
RFM has introduced the IC1000 to support fast-track product development cycles using
ASH radio technology. The IC1000 implements the clock and data recovery tasks that of-
ten constitute a lot of the learning curve in your first RF protocol project. The IC1000 is
designed to operate with no threshold, which is the key to good system sensitivity.
3.1 IC1000 Description
The IC1000 is implemented in an industrial temperature range PIC12LC508A-04I\SN
microcontroller using internal clocking. Nominal operating current is 450 A, consistent
with the low operating current emphasis of the second-generation ASH radio product
line. The IC1000 is provided in a miniature eight-pin SMT package.
3.2 IC1000 Application
A typical IC1000 application is shown in Figure 3.2.1. The data (slicer) output from the
second-generation ASH transceiver is buffered by an inverting buffer and is applied to
Pin 3 of the IC1000 and the Data In pin of the host microprocessor. When the IC1000 de-
tects the presence of a specific start-of-data pulse sequence, it outputs a Start Detect pulse
on Pin 2. This pulse is applied to an interrupt pin on the host processor. The IC1000 gen-
erates data clocking (data valid) pulses in the middle of each following bit period using
an oversampled clock extraction method. The IC1000 is designed to tolerate continuous
input noise while searching for a start-of-data pulse sequence.
The IC1000 supports four data rates - 2400, 4800, 9600, and 19200 bits per second (bps).
The data rate is selected by setting the logic input levels to Pin 6 (Speed 1) and Pin 7
(Speed 0). Please refer to the IC1000 data sheet for additional information.
4 Example Data Link Layer Protocol
The data link protocol discussed below is tuned for high-sensitivity, low data rate require-
ments. The protocol code is designed to run on the ATMEL AT89C2051 microcontroller
used in the DR1200-DK/DR1200A-DK Series Virtual Wire Development Kits. The
A version kits (DR1200A-DK, etc.) ship with this software and require no hardware
21
modifications. It is necessary to replace the radio boards used in the standard kits with
A version radio boards before using this code, or to modify the standard radio boards as
detailed below. Figure 4.1 shows the circuit modification used between the ASH trans-
ceiver base-band output, Pin 5, and the comparator (data-slicer) input, Pin 6. Figure 4.2
shows how these components are installed and their values. This modification reduces the
22
470K
47K
MMBT2222
3 5
2
6
7
8. 2K
TR-Seri es
ASH
Transcei ver
I C1 000
RX Data
RX Cl ock
SOP Detect
TX Modul ati on
Speed 0
Speed 1
Host
P
RQ
Data Strobe
Data n
Data Out
Typi caI I C1 000 AppI i cati on
TXMOD
RXDATA
Figure 3.2.1
Modul ati on nput
Data Output
TOP VIEW
GND
3
CNT
RL0
CNT
RL1
P
W DTH
P
RATE
THLD
1
THLD
2
RREF
GND2
TX
MOD
RX
DATA
LPF
ADJ
CMP
N
BB
OUT
PK
DET
AGC
CAP
VCC
1
VCC
2
RF O
GND1
+ 3
VDC
ASH Transcei ver AppI i cati on Ci rcui t
Low Data Rate OOK
1
20
2 3 4 5 6 7 8 9
1 0
1 1
1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9
+ 3
VDC
R
PW
R
PR
R
TH1
R
REF
R
LPF
R
TXM
C
BBO
C
RFB2
C
DCB
L
AT
L
ESD
C
RFB1
L
RFB
+
T/R
C
LPF
R
BBO
Figure 4.1
noise bandwidth of the receiver. In addition, R9 on the DR1200, DR1201 and DR1300
radio boards should be changed to a zero-ohm jumper (no DS1 threshold). R12 should be
changed to 330 K on all three radio boards. Note that the DR1200A, DR1201A and
DR1300A already incorporate these modifications.
4.1 Link Layer Protocol Source Code
The link layer protocol is implemented in 8051 assembly language and the source,
DK200A.ASM (RFM P/N SW0012.V01), is compatible with the popular TASM 3.01
shareware assembler. You can get TASM 3.01 at www.rehn.org/YAM51/files.shtml.
By the way, this A link layer protocol uses the programming pins differently than the
protocol supplied in the standard development kits. See Picture 4.3. Placing a jumper next
to the dot end (ID0) enables the AutoSend mode (do this on one protocol board only).
Placing a jumper at the far end (ID3) strips the packet framing and header characters off
23
R
BBO
= 1 2K
C
LPF
= 0. 0068 F
C
BBO
= 0. 1
+ 0. 05 F
Figure 4.2
ID3
ID0
Figure 4.3
received packets. This can be handy for driving small serial printers, etc. You do not use
jumpers to set the FROM address with this protocol.
Details of the packet and byte structures used by the protocol are shown in Figure 4.4.
The host-protocol packet structure begins and ends with a 0C0H framing character
(FEND) that cannot be used elsewhere in the packet. For example, you cannot use 0C0H
in the TO/FROM address byte. This will otherwise not be a problem using seven-bit
ASCII message characters. Eight-bit data can be sent using seven-bit ASCII characters to
represent numerical values, or a framing character substitution scheme like the one used
in the Internet SLIP protocol can be employed. The framing character helps deal with the
non real time nature of serial ports on your typical PC. The host-protocol packet struc-
ture within the frame includes the TO/FROM address byte, with the high nibble the TO
address and the low nibble the FROM address. The ID byte indicates which packet this
is. Each packet can hold up to 24 additional message bytes. As mentioned, short packets
should be used on radio channels.
Framing characters are not needed in the transmitted packet structure as the protocol is
real time on the radio side. The transmitted packet structure beings with a 1-0-1-0 pre-
amble which establishes good signal slicing symmetry at the input to the radio compara-
tor and then trains the clock and data recovery processes in the software. The preamble is
followed by a 12-bit start symbol that provides good discrimination to random noise pat-
terns. The number of bytes in the packet (beyond the start symbol), the TO/FROM ad-
dress, packet ID, message bytes and FCS then follow. The start symbol and all bytes
following are 12-bit encoded for good dynamic DC balance.
24
effect similar to adding extra noise-induced jitter can occur as different branches are
taken through the code.
In addition to supporting data reception and transmission, the tick subroutine runs
several timer functions. One timer provides a time-out for partial messages arriving from
the host. The AutoSend timer and the transmit retry timer are also part of the tick sub-
routine.
The other interrupt service routine used by the protocol software is s_isr, which sup-
ports serial port interrupts by calling srio. The function of srio is to provide priority
reception of messages from the host. An acknowledgment back to the host confirms the
serial interrupt was enabled and the protocol received the hosts message.
As mentioned, the code starts running in the main loop. A number of subroutines can be
called from this loop, depending on the state of their associated control flags. Here are
these subroutines and what they do:
The do_as subroutine automatically transmits a Hello test message paced by a timer
in tick. This AutoSend function is activated by a call from setup if a jumper is de-
tected across the pins near the dot end on the protocol board, as discussed above.
The do_rt subroutine retransmits a message if an ACK has not been received.
Retransmissions are paced by a timer in tick. The timer is randomly loaded with one of
eight different delays, which helps reduce the possibility of repeated collisions between
two nodes trying to transmit a message at the same time. The protocol will attempt to
transmit a message up to eight times. The do_rt subroutine manages attempts two
through eight as needed.
The aksnd subroutine sends an ACK/NAK message back to the protocols host to indi-
cate the outcome of attempting to transmit a message. When called directly from the
main subroutine, it sends a NAK message. When called from do_rx, it sends an ACK.
The rxsop subroutine detects the message start symbol (SOP) by comparing the bit pat-
tern in the 12-bit correlation buffer updated by pll to the start symbol pattern. When
the SOP pattern is detected, rxsop modifies flag states and clears buffers in preparation
for receiving the encoded message. As mentioned, this protocol uses 12-bit encoding to
achieve dynamic DC balance. The start symbol is not one of the 12-bit symbols used in
the encoding table, but it is also DC balanced.
The do_rx subroutine receives and decodes the incoming message, tests the FCS for
message accuracy, returns an ACK to the sender if it has received an error-free data mes-
sage for this node, sends an ACK message to the host if it has received an ACK message
for this node, and sends an error-free data message to the host if the message is for this
node. These tasks are done by calling subroutines from do_rx. Here are these subrou-
tines and what they do:
26
The rxmsg subroutine receives each six-bit half symbol from pll and converts it to a
decoded nibble using the smbl table near the end of the listing. Decoded nibbles are as-
sembled into bytes and added to the received message buffer. When all the message is re-
ceived, control is returned to do_rx. If a message length overflow occurs, rxmsg fakes
a short message that will fail the FCS test.
The rxfcs subroutine tests the message for errors by recalculating the FCS with the
transmitted FCS bits included in the calculation. If there are no errors, the received FCS
calculation will equal 0F0B8H. The rxfcs subroutine uses calls to b_rfcs and
a_rfcs to do the FCS calculation and to test the results.
The acktx subroutine determines if the received message is an ACK for a packet (ID)
being transmitted from this node. If so, acktx idles transmission attempts and signals
rxmsg to send an ACK message to the host by setting flag states.
When called from rxsmg, aksnd sends an ACK message to the host. Notice that when
aksnd is called from main, it sends a NAK message.
The ackrx subroutine transmits an ACK message back to the sending node when it re-
ceives a valid data message from the sending node addressed to it. The subroutines used
by ackrx are borrowed from the transmit side of the protocol and will be discussed
later.
The rxsnd subroutine sends a received data message to the host, provided the message
is for its node and has passed the FCS test.
The rxrst subroutine resets flags and initializes buffers in preparation for receiving the
next packet.
The first byte of a packet sent from the host triggers the serial interrupt service routine
t_isr which calls subroutine srio. The serial interrupt is disabled and the do_tx sub-
routine is called. This subroutine takes in the message from the host, computes the FCS,
turns the transmitter on, sends the preamble and start symbol, encodes and sends the mes-
sage, and turns the transmitter off. The do_tx subroutine accomplishes these actions by
calling other subroutines. Here are these transmit subroutines and what they do:
The txget subroutine receives the message from the host and loads it into the transmit
message buffer. Provisions are made in txget to exit on a null message (just two
FENDs), time-out on partial messages, or send the first part of an incoming message that
is overflowing in length. Since the serial interrupt service routine is disabled from
time-to-time, a short packet transfer acknowledgment message (PAC) is sent back to the
host to confirm the protocol has the message and is attempting to transmit it. No PAC is
sent on a null message or a time-out as there is nothing to send.
27
The txfcs subroutine calculates the FCS that will be used for error detection at the re-
ceive end. It uses calls to b_tfcs and a_tfcs to do the FCS calculation and to add the
results to the message.
The txpre subroutine turns on the transmitter and after a short delay sends the preamble
and start symbol using the data in the tstrt table near the end of the listing. Note that
txpre is supported by tick to provide sample-by-sample bit transmission.
The txmsg subroutine encodes the message bytes as 12-bit symbols and transmits them
in cooperation with tick. This subroutine uses the smbl table to encode each nibble in
each message byte into six bits.
The txrst subroutine can either reset to send the same message again or can reset to re-
ceive a new message from the host, based on flag states.
The do_tx subroutine receives a message from the host and attempts to transmit it once.
Additional transmit attempts are done by do_rt, which is called from main as needed.
The do_rt subroutine uses most of the same subroutines as do_tx. The do_as sub-
routine can also be called from main to provide the AutoSend test transmission and it
also uses many of the same subroutines as do_tx. And as mentioned earlier, ackrx
uses several of these subroutines to transmit an ACK back for a received message.
4.2 Terminal Program Source
V110T30C.FRM is the Visual Basic source code for the companion terminal program to
DK200A.ASM. After initializing flags, variables, etc., the form window is shown and the
program starts making periodic calls to the Timer1_Timer heartbeat subroutine. The
Xfer subroutine provides time-outs for PAC, ACK or NAK messages expected back
from the protocol. Xfer is also handy for reminding you to turn on the power switch or
put fresh batteries in the protocol board. The PCs serial input buffer is set up for polling
(no interrupts) and is serviced by calling RxPtk from Timer1_Timer. The terminal
program also has an AutoSend subroutine, ASPkt, that is called from Timer1_Timer
when AutoSend is active. (No, you are not supposed to use the AutoSend feature in the
protocol and the host program at the same time.) Here is a listing of the terminal program
subroutines and what they do:
RxPkt is called from Timer1_Timer when bytes are found in the serial port input
buffer. RxPkt calls two other subroutines, InCom and ShowPkt.
InCom collects bytes from the serial port input buffer for a period of time set by the
InDel! variable. These bytes are added to the end of the RPkt$ string variable, which
acts as byte FIFO.
28
ShowPkt is then called to display or otherwise process the bytes in RPkt$. The outer
Do, Loop Until (J = 0) structure takes advantage of the framing characters to
separate individual packets in RPkt$. This avoids the need for reading the PCs serial
port input buffer at precise times which you probably cant do anyway. As each packet is
removed from the left side of RPkt$, it is checked to see if it is a one-character PAC
(0FFH character), a two-character ACK or NAK, or a data message of three or more
characters. Flags TFlag, ANFlag, NAFlag and TNFlag are reset by ShowPkt as ap-
propriate and are used by the Xfer monitoring subroutine to confirm messages are flow-
ing back from the protocol in a timely manner. The NAFlag enables the next AutoSend
transmission. The ShwACK flag selects either to display inbound messages (and PID
Skips) only, or inbound messages plus PAC, ACK/NAK, TO/FROM and ID information.
Text1_KeyPress is used to build messages for transmission. Editing is limited to
backspacing, and the message is sent by pressing the Enter key or entering the 240
th
char-
acter.
SndPkt breaks the message into packets, adds the framing characters, the TO/FROM
address and the ID number to each packet and sends them out. SndPkt sets the TFlag
and ANFlag flags and clears the value of several variables. NxtPkt is a small subroutine
used by SndPkt that picks a new ID number for each packet.
Xfer monitors the elapsed time from when a packet is sent out (to the protocol) and a
PAC is received back, and the elapsed time from when a packet is sent out and an ACK
or NAK is received back. Xfer will display error messages and reset control flags and
other variables through ReSetTX if these elapsed times get too long.
ASPkt automatically sends test packets using the NxtPkt and SndPkt subroutines. It
is paced by the state of the NAFlag.
GetPkt is a small subroutine that supplies ASPkt with a message. Until the first mes-
sage is typed in, GetPkt provides a default message. It otherwise provides the last mes-
sage typed in.
LenTrap clears a text window when 32,000 bytes of text have accumulated in it.
The remaining subroutines in the terminal program are classical event procedures related
to mouse clicks on the terminal program window. Most of these relate to the Menu bar.
The three top level choices on the Menu bar are File, Edit and View. Under File you can
choose to Exit the terminal program. Under Edit, the next level of choices are the To Ad-
dress and the From Address. Under the To Address you can choose Nodes 1, 2, 3, or 4,
with Node 2 the default. Under the From Address you can choose Nodes 1, 2, 3, or 4,
again with Node 2 the default.
29
Under View you can choose Clear (screen), Show RX Dups, Show ACK/NAK, and
AutoSend, as discussed earlier. The status bar and its embedded progress bar at the bot-
tom of the form monitors outbound packets even when Show ACK/NAK is not enabled.
4.3 Variations and Options
In most real world applications, s_isr, srio, txget, rxsnd and aksnd would be
replaced with resident application subroutines. Your real-world application is left as a
homework assignment. Test, test, test!
Another pair of programs are provided for your experimentation. DK110K.ASM is a sim-
plified shell protocol that transmits a message received from the host (once) and sends
any message received with a valid FCS to the host. PAC/ACK/NAK handshaking be-
tween the host and the protocol and between protocol nodes is not implemented. Also, no
TO/FROM address filtering is provided at the protocol level. This gives you the flexibil-
ity to add these types of features either to the protocol or the terminal program yourself.
Terminal Program V110T05B.FRM works with DK110K.ASM and provides a simple
implementation of ACK/NAK handshaking at the host level. Of course, DK110K.ASM is
not intended to work with V110T30C.FRM and DK200A.ASM is not intended to work
with V110T05B.FRM.
4.4 Test Results
Laboratory tests show that a 916.5 MHz ASH radio system using the example software
achieves a bit-error-rate between 10
-4
and 10
-3
at a received signal level of -101 dBm us-
ing pulse modulation (or -107 dBm using 100% amplitude modulation). Open-field range
tests using commercial half-wave dipole antennas (Astron Antenna Model AXH9NSMS)
demonstrate good performance chest-high at distances of one-eighth mile or more.
30
_Version = 393216
End
Begin VB.TextBox Text2
Height = 2323
Left = 148
Locked = -1 True
MultiLine = -1 True
ScrollBars = 2 Vertical
TabIndex = 1
Top = 0
Width = 7460
End
Begin VB.Timer Timer1
Left = 720
Top = 4320
End
Begin MSCommLib.MSComm MSComm1
Left = 1200
Top = 4320
_ExtentX = 794
_ExtentY = 794
_Version = 393216
DTREnable = -1 True
End
Begin VB.TextBox Text1
Height = 2323
Left = 120
MultiLine = -1 True
ScrollBars = 2 Vertical
TabIndex = 0
Top = 2513
Width = 7460
End
Begin VB.Menu mnuFile
Caption = &File
Begin VB.Menu mnuExit
Caption = E&xit
End
End
Begin VB.Menu mnuEdit
Caption = &Edit
Begin VB.Menu mnuToAdr
Caption = To Address
Begin VB.Menu mnuTN1
Caption = Node 1"
End
Begin VB.Menu mnuTN2
Caption = Node 2"
Checked = -1 True
End
Begin VB.Menu mnuTN3
Caption = Node 3"
End
Begin VB.Menu mnuTN4
Caption = Node 4"
End
End
Begin VB.Menu mnuFrmAdr
Caption = From Address
Begin VB.Menu mnuFN1
Caption = Node 1"
End
Begin VB.Menu mnuFN2
Caption = Node 2"
Checked = -1 True
End
Begin VB.Menu mnuFN3
Caption = Node 3"
End
Begin VB.Menu mnuFN4
Caption = Node 4"
End
End
End
Begin VB.Menu mnuView
Caption = &View
Begin VB.Menu mnuClear
Caption = &Clear
End
44
End If
Call NxtPkt bump packet ID number
SPkt$ = FEND$ & PktHdr$ & Chr$(P) & SPkt$ & FEND$ build packet
MSComm1.Output = SPkt$ send packet
TFlag = 1 set transfer flag
ANFlag = 1 set ACK/NAK flag
TCnt = 0 clear TX timeout counter
XCnt = 0 clear TX transfer retry counter
Else
TXFlag = 0 clear TX flag when all bytes sent
StatusBar1.Panels(4).Text = Keyboard Active show keyboard active
End If
End If
End If
End Sub
Public Sub Xfer()
TCnt = TCnt + 1 increment TX timeout counter
If TCnt > 4 Then if trying for more than 1 second
If TFlag = 1 Then and transfer flag still set
TCnt = 0 reset TCnt
XCnt = XCnt + 1 increment transfer retry counter
If XCnt < 17 Then if XCnt not greater than 16
MSComm1.Output = SPkt$ resend packet
TCnt = 0 reset TX timeout counter
Else
Call ReSetTX else reset TX after eight tries
Call LenTrap manage textbox memory
Text1.SelStart = Len(Text1.Text) put cursor to end of text
Text1.SelText = <xfer fault> & vbCrLf show transfer fault message
End If
End If
End If
If TCnt > 64 Then if more than 16 seconds
If ANFlag = 1 Then and if ACK/NAK flag still set
Call ReSetTX reset TX
Call LenTrap manage textbox memory
Text1.SelStart = Len(Text1.Text) put cursor to end of text
Text1.SelText = <ACK/NAK fault> _
& vbCrLf show ACK/NAK fault message
End If
End If
End Sub
Public Sub ReSetTX()
TFlag = 0 reset transfer flag
TXFlag = 0 reset TX message flag
TNFlag = 0 reset next TX packet flag
ANFlag = 0 reset ACK/NAK flag
NAFlag = 0 reset next AutoSend flag
TCnt = 0 reset TCnt
XCnt = 0 reset XCnt
TXPkt$ = clear TX message string
SPkt$ = clear send packet string
ProgressBar1.Value = 0 clear progress bar
StatusBar1.Panels(4).Text = Keyboard Active show keyboard active
End Sub
Public Sub ASPkt()
If NAFlag = 0 Then if next AutoSend flag reset
Call GetPkt get next message packet(s)
Temp$ = TPkt$ use Temp$ for local display
Call LenTrap manage textbox memory
Text1.SelStart = Len(Text1.Text) put cursor at end of text
Text1.SelText = Temp$ add text to textbox
TXFlag = 1 set TX message flag
TNFlag = 1 set next TX packet flag
StatusBar1.Panels(4).Text = Keyboard Locked show keyboard locked
Call SndPkt send via SndPkt
NAFlag = 1 set next AutoSend flag
End If
End Sub
Public Sub GetPkt()
TPkt$ = ASStr$ message string for AutoSend
End Sub
Public Sub NxtPkt()
P = P + 1 increment packet number
50
; constants:
ITMOD .EQU 022H ; set timers 0 and 1 to mode 2
ITICK .EQU 141 ; set timer T0 for 62.40 us tick
ISMOD .EQU 080H ; SMOD = 1 in PCON
IBAUD .EQU 0FAH ; 19.2 kbps @ 22.1184 MHz, SMOD = 1
ISCON .EQU 050H ; UART mode 1
RMPT .EQU 159 ; PLL ramp top value (modulo 0 to 159)
RMPW .EQU 159 ; PLL ramp reset (wrap) value
RMPS .EQU 80 ; PLL ramp switch value
RMPI .EQU 20 ; PLL ramp increment value
RMPA .EQU 29 ; PLL 5% advance increment value (20 + 9)
RMPR .EQU 11 ; PLL 5% retard increment value (20 - 9)
TXMB .EQU 044H ; TX message buffer start address
RXMB .EQU 062H ; RX message buffer start address
FEND .EQU 0C0H ; FEND framing character (192)
SOPL .EQU 08AH ; SOP low correlator pattern
SOPH .EQU 0B3H ; SOP high correlator pattern
TXRO .EQU 020H ; TX retry timer count
FCSS .EQU 0FFH ; FCS seed
FCSH .EQU 084H ; FCS high XOR mask
FCSL .EQU 08H ; FCS low XOR mask
FCVH .EQU 0F0H ; FCS valid high byte pattern
FCVL .EQU 0B8H ; FCS valid low byte pattern
; stack: 08H - 021H (26 bytes)
; bit labels:
WBFLG .EQU 010H ; warm boot flag (future use)
PLLON .EQU 011H ; RX PLL control flag
RXISM .EQU 012H ; RX inverted input sample
RXSMP .EQU 013H ; RX input sample
LRXSM .EQU 014H ; last RX input sample
RXBIT .EQU 015H ; RX input bit
RXBFLG .EQU 016H ; RX input bit flag
SOPFLG .EQU 017H ; SOP detect flag
RXSFLG .EQU 018H ; RX symbol flag
RM .EQU 019H ; RX FCS message bit
OKFLG .EQU 01AH ; RX FCS OK flag
SIFLG .EQU 01BH ; serial in active flag
TSFLG .EQU 01CH ; output TX sample flag
TXSMP .EQU 01DH ; TX output sample
TXBIT .EQU 01EH ; TX message bit
TM .EQU 01FH ; TX FCS message bit
TXFLG .EQU 020H ; TX active flag
TMFLG .EQU 021H ; TX message flag
TOFLG .EQU 022H ; get message time out flag
AMFLG .EQU 023H ; AutoSend message flag
ASFLG .EQU 024H ; AutoSend active flag
SFLG0 .EQU 025H ; spare flag 0
SFLG1 .EQU 026H ; spare flag 1
SFLG2 .EQU 027H ; spare flag 2
SFLG3 .EQU 028H ; spare flag 3
SFLG4 .EQU 029H ; spare flag 4
SFLG5 .EQU 02AH ; spare flag 5
SFLG6 .EQU 02BH ; spare flag 6
SFLG7 .EQU 02CH ; spare flag 7
SFLG8 .EQU 02DH ; spare flag 8
SFLG9 .EQU 02EH ; spare flag 9
SFLGA .EQU 02FH ; spare flag A
; register usage:
; R0 RX data pointer
; R1 TX data pointer
; R2 PLL ramp buffer
; R3 RX FCS buffer A
; R4 not used
; R5 TX FCS buffer A
; R6 TX FCS buffer B
; R7 RX FCS buffer B
53
; byte labels:
BOOT .EQU 022H ; 1st byte of flags
RXID .EQU 026H ; RX integrate & dump buffer
RXBL .EQU 027H ; RX low buffer, SOP correlator etc.
RXBH .EQU 028H ; RX high buffer, SOP correlator etc.
RXBB .EQU 029H ; RX symbol decode byte buffer
RMDC .EQU 02AH ; RX symbol decode loop counter
RMBIC .EQU 02BH ; RX symbol decode index pointer
RMBYC .EQU 02CH ; RX message byte counter
RMFCS .EQU 02DH ; RX FCS byte buffer
RMSBC .EQU 02EH ; RX symbol bit counter
RMLPC .EQU 02FH ; RX message loop counter
RMFCC .EQU 030H ; RX message FCS counter, etc.
TMFCC .EQU 031H ; TX timer & loop counter
TXSMC .EQU 032H ; TX output sample counter
TMBIC .EQU 033H ; TX message bit counter
TMBYT .EQU 034H ; TX message byte buffer
TMBYC .EQU 035H ; TX message byte counter
TXSL .EQU 036H ; TX message symbol low buffer
TXSH .EQU 037H ; TX message symbol high buffer
TMFCS .EQU 038H ; TX FCS byte buffer
TXTL .EQU 039H ; TX timer low byte
TXTH .EQU 03AH ; TX timer high byte
BUF0 .EQU 03BH ; spare buffer 0
BUF1 .EQU 03CH ; spare buffer 1
BUF2 .EQU 03DH ; spare buffer 2
BUF3 .EQU 03EH ; spare buffer 3
BUF4 .EQU 03FH ; spare buffer 4
BUF5 .EQU 040H ; spare buffer 5
BUF6 .EQU 041H ; spare buffer 6
BUF7 .EQU 042H ; spare buffer 7
BUF8 .EQU 043H ; spare buffer 8
; I/O pins:
MAX .EQU P1.6 ; Maxim 218 power (on = 1)
RXPIN .EQU P3.2 ; RX input pin (inverted data)
TXPIN .EQU P3.3 ; TX output pin (on = 1)
PTT .EQU P1.7 ; transmit enable (TX = 0)
PCRCV .EQU P3.7 ; PC (host) input LED (on = 0)
RFRCV .EQU P3.5 ; RX FCS OK LED (on = 0)
RXI .EQU P3.4 ; RX activity LED (on = 0)
ID0 .EQU P1.2 ; jumper input bit 0 (dot end)
ID1 .EQU P1.3 ; jumper input bit 1
ID2 .EQU P1.4 ; jumper input bit 2
ID3 .EQU P1.5 ; jumper input bit 3
; start of code:
.ORG 00H ; hardware reset
SETB WBFLG ; set warm boot flag
reset: AJMP start ; jump to start
.ORG 0BH ; timer 0 interrupt vector
t_isr: ACALL tick ; sampling tick subroutine
RETI ; interrupt done
.ORG 023H ; serial interrupt vector
s_isr: ACALL srio ; serial I/O subroutine
CLR TI ; clear TI (byte sent) flag
CLR RI ; clear RI (byte received) flag
RETI ; interrupt done
.ORG 040H ; above interrupt code space
start: ACALL setup ; initialization code
main: JNB AMFLG,mn0 ; skip if AutoSend idle
CLR PCRCV ; else turn PCRCV LED on
ACALL do_as ; do AutoSend
SETB PCRCV ; turn PCRCV LED off
mn0: ACALL rxsop ; do RX SOP detect
JNB SOPFLG,main ; if not SOP loop to main
ACALL do_rx ; else do RX message
54
Strikethrough = 0 False
EndProperty
LinkTopic = Form1"
MaxButton = 0 False
ScaleHeight = 4335
ScaleWidth = 6375
StartUpPosition = 3 Windows Default
Begin MSComDlg.CommonDialog CommonDialog1
Left = 240
Top = 3600
_ExtentX = 688
_ExtentY = 688
_Version = 393216
End
Begin VB.TextBox Text2
BeginProperty Font
Name = System
Size = 9.75
Charset = 0
Weight = 700
Underline = 0 False
Italic = 0 False
Strikethrough = 0 False
EndProperty
Height = 2052
Left = 120
Locked = -1 True
MultiLine = -1 True
ScrollBars = 2 Vertical
TabIndex = 1
Top = 0
Width = 6135
End
Begin VB.Timer Timer1
Left = 720
Top = 3600
End
Begin MSCommLib.MSComm MSComm1
Left = 1200
Top = 3600
_ExtentX = 794
_ExtentY = 794
_Version = 393216
DTREnable = -1 True
End
Begin VB.TextBox Text1
BeginProperty Font
Name = System
Size = 9.75
Charset = 0
Weight = 700
Underline = 0 False
Italic = 0 False
Strikethrough = 0 False
EndProperty
Height = 2052
Left = 120
MultiLine = -1 True
ScrollBars = 2 Vertical
TabIndex = 0
Top = 2160
Width = 6135
End
Begin VB.Menu mnuFile
Caption = &File
Begin VB.Menu mnuClear
Caption = &Clear
End
Begin VB.Menu mnuAutoSnd
Caption = &AutoSend
End
Begin VB.Menu mnuExit
Caption = E&xit
End
End
End
Attribute VB_Name = Form1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
63
Pkt$ = FEND$ & Pkt$ & FEND$ add packet framing characters
N = 0 reset N
TXFlag = 1 set TX flag
TXCnt = 0 clear TX try counter
TXTO = 0 clear TX timeout counter
End If
Call LenTrap manage textbox memory
Else
KeyAscii = 0 else dont echo to the screen
End If
End Sub
Public Sub DoTX()
If TXTO = 0 Then if TX timeout zero
TXCnt = TXCnt + 1 increment TX try counter
If TXCnt = 1 Then if TX try count 1
Call SndPkt send packet
TXTO = 4 set 0.8 second timeout
ElseIf (TXCnt > 1) And (TXCnt < 7) Then for try counts 2 through 6
Call SndPkt send packet
TXTO = 4 + Int(8 * Rnd) load random TX timeout count
ElseIf TXCnt >= 7 Then else if past 6th try
Call LenTrap manage textbox memory
Text1.SelStart = Len(Text1.Text) put cursor at end of text
Text1.SelText = <NAK> & vbCrLf show NAK
TXFlag = 0 reset TX flag
TCnt = 0 clear TX counter
TXTO = 0 clear TX timeout counter
Pkt$ = clear TX packet string
R2Pkt$ = clear RPkt$
End If
Else else if TX timeout counter not 0
TXTO = TXTO - 1 decrement it one count
End If
End Sub
Public Sub SndPkt()
If Pkt$ <> Then if Pkt$ not null
MSComm1.Output = Pkt$ send packet
End If
End Sub
Public Sub ASPkt()
If TXFlag = 0 Then if TXFlag not set
Temp$ = ASMsg$ use Temp$ for local display
Call LenTrap manage textbox memory
Text1.SelStart = Len(Text1.Text) put cursor at end of text
Text1.SelText = Temp$ add message to textbox
Pkt$ = FEND$ & ASMsg$ & FEND$ add packet framing to message
TXFlag = 1 set ACK flag
TXCnt = 0 clear TX try counter
TXTO = 0 clear TX timeout counter
End If
End Sub
Public Sub SndACK()
MSComm1.Output = FEND$ & ACK & FEND$ send ACK back
End Sub
Public Sub LenTrap()
If Len(Text1.Text) > 16000 Then manage textbox memory
Text1.Text = clear TX textbox
Text1.SelStart = Len(Text1.Text) put cursor at end of text
End If
If Len(Text2.Text) > 16000 Then manage textbox memory
Text2.Text = clear RX textbox
Text2.SelStart = Len(Text2.Text) put cursor at end of text
End If
End Sub
Private Sub Form_Unload(Cancel As Integer)
MSComm1.PortOpen = False close com port
End done!
End Sub
Private Sub mnuAutoSnd_Click()
ASFlag = ASFlag Xor 1 toggle AutoSend flag
If ASFlag = 0 Then if flag reset
mnuAutoSnd.Checked = False uncheck AutoSend
Text1.ForeColor = QBColor(15) white characters
66
Else else
mnuAutoSnd.Checked = True check AutoSend
Text1.ForeColor = QBColor(10) green characters
End If
End Sub
Private Sub mnuClear_Click()
Text1.Text = clear TX textbox
Text1.SelStart = Len(Text1.Text) put cursor at end of text
Text2.Text = clear RX textbox
Text2.SelStart = Len(Text2.Text) put cursor at end of text
End Sub
Private Sub mnuExit_Click()
MSComm1.PortOpen = False close com port
End done!
End Sub
6 Revisions and Disclaimers
There are several improvements in the example software in this revision. The RF data
rate in both link layer protocol examples has been increased from 1200 to 2000 bps, and
the packet retry back off interval in DK200A.ASM has been better randomized. The
V110T30C host terminal program now supports multi-packet messages and both host ter-
minal programs provide better Windows efficiency. Component values in Figure 4.2 have
been adjusted to match the higher RF data rate.
The information in this design guide is for tutorial purposes only. Any software devel-
oped using the information provided in this guide should be thoroughly tested before use.
No representation is made that the software techniques and example code documented in
this guide will work in any specific application. Please refer to the Virtual Wire Devel-
opment Kit Software License and Warranty for additional information.
RFM and Virtual Wire are registered trademarks of RF Monolithics, Inc. MS-DOS, QuickBASIC, Visual
Basic and Windows are registered trademarks of Microsoft Corporation. Keyloq is a trademark of Micro-
chip, Inc.
67