You are on page 1of 25

WIRELESS DATA LINK

by
Alexander Fishkin
ECE 345
TA: Ajay Patel
August 2, 1999
Project 7

ABSTRACT
The focus of this paper is on the design and implementation of a wireless digital
link between two personal computers. Specifically, a project that involves connecting
two machines by a radio link to allow for text communications between two users is
discussed in great detail. This paper reviews the design procedure, including the overall
development procedures, as well as the design details and verification. Both the software
and the hardware components of the project are examined, and the project cost analysis is
given at the end of this report.

ii

TABLE OF CONTENTS
PAGE
1.

INTRODUCTION .. 1

2.

DESIGN PROCEDURE . 3
2.1
2.2

3.

DESIGN DETAILS 7
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12

4.

Hardware Implementation: General Description .... 3


Software Implementation: General Description ..... 4

Transmitter .. 7
Receiver .. 9
Power Supply 10
Complete Circuit ...10
Overall Software Functionality .12
Initialization . 12
A Possible Interrupt: Data Needs To Be Sent ... 13
A Possible Interrupt: New Data Has Arrived 14
Serial Communications in Win32: Introduction ....
15
Serial Communications in Win32: Opening a Port ...15
Serial Communications in Win32: Reading and Writing ..16
Serial Communications in Win32: Events 16

DESIGN VERIFICATION ... 18


4.1
4.2
4.3

Hardware Testing .. 18
Software Testing ... 19
Final Product Testing 19

5.

COSTS .. 20

6.

CONCLUSIONS .. 21
REFERENCES . 22

iii

1. INTRODUCTION
During the course of this project, a system was created, using which two users could
communicate with each other using personal computers in the absence of a direct cable
connection of any kind between the two stations. The block diagram of the system is
shown in Figure 1.1. Note that each computer is connected to a black box, which
contains a radio transmitter and a radio receiver. Using these devices, information can
be sent back and forth between the two computers via radio.

Figure 1.1. General diagram of the system


Each station runs software, written during the course of this project, called Rtalk.
The name of the software draws a parallel between this product and a well-known
program called ytalk under the UNIX environment, which allows two users on the same
local area network to exchange text messages. Rtalk functions in a very similar manner:
a user at each station is able to type a message at his/her terminal and send it to the
terminal of the other user by clicking on the Send button. However, the key difference
between ytalk and Rtalk is that Rtalk does not require that the two machines be
connected to a network of any kind. As Figure 1.1 illustrates, the two stations are

communicating by means of radio. As a result, there is no need for a cable connection.


The maximum transmission rate is 4.8 kilobytes per second, which is more than enough
for text transmission. The data to/from each computer to/from the corresponding
transceiver is transferred though a serial port. Thus, in order to be able to use this
product, at least one COMM port on each machine needs to be available. The availability
of more than one free port allows one station to communicate with multiple other
stations.
This project was divided into two subprojects in order to design the hardware and
the software aspects independently, thus making debugging easier. The goal at the first
stage was to develop all of the hardware needed for the system and to obtain the desired
performance using the testing equipment available in the laboratory. The second stage
involved writing the software and obtaining the proper functionality with the two
computers connected by a serial cable. Once both subprojects were completed, they were
put together and the final project was complete.

2. DESIGN PROCEDURE
2.1

Hardware Implementation: General Description


Figure 2.1 illustrates the hardware component of the project. Two RF transceiver

pairs -- two transmitters and two receivers -- were purchased from Linx Technologies Inc.
With additional circuitry, these RF modules are used to transfer data via radio between
the two PCs. The two transmitter-receiver pairs operate at different frequencies to
accommodate for two-way traffic. Information traveling one way is encoded into a radio
wave having a frequency of 418 MHz. The information traveling the other way is
encoded into a different radio wave having a frequency of 315 MHz. As a result, there is
no interference between the two waves, and a two-way link is established.

315 M H z T X R

S e r ia l P o r t

4 1 8 M H z R X R

3 1 5 M H z R X R

S e r ia l P o r t

418 M H z T X R

Figure 2.1. Hardware Diagram


As mentioned earlier, a free serial port is needed to transfer the data from the
computer to the transmitter and from the receiver back to the computer. Note that only

one port is needed for both sending and receiving. It is the software that implements
priority selection and synchronization.
2.2

Software Implementation: General Description

Figure 2.2.1. Screenshot of Rtalk


Figure 2.2.1 shows the screenshot of Rtalk, the software written in Microsoft
Visual C++ for this project. Note that Figure 2.2.1 only shows the window for one port,
specifically for port 1. Rtalk accommodates for the use of up to 4 ports. The main goal
of the software was to provide an interface between the user and the system. As Figure

2.2.1 suggests, the software is designed to have two text boxes -- one text box for sending
data and one for receiving data. The upper box stores all of the text that arrives from the
other computer. That text can be completely erased by the user by clicking on the
Clear button. The lower box allows the user to enter text and send it to the other
computer by pressing the Send button.
In figure 2.2.1, note the Configure button, which is just above the upper text
box (the text box that receives data). By pressing that button, the user obtains a
configuration window identical to that in Figure 2.2.2. This window allows the user to
configure various parameters for data transfer -- the baud rate, the parity, the number of
data bits, the number of stop bits, the size of the send buffers, and various events which
will all be discussed later in this paper.

Figure 2.2.2. Configuration window

A few other details about the functionality of Rtalk have to be mentioned. All of
the data that is received is stored in the receiving text box until the user clicks on the
Clear button. If the amount of data exceeds the size of the text box, a vertical scrollbar
appears, and the user can scroll through the text to see all of the information that was
received. In the sending text box, however, only one line of data can be entered at one
time, and it is completely erased from the text box as soon as the sender clicks on the
Send button. Thus, a new line can be typed in immediately after.

3. DESIGN DETAILS
3.1

Transmitter
8
7
6
5

T X M -x x x -L C -R
G N D

G N D

VC C

D A T A IN

G N D

G N D

R F O U T

IA D J /G N D

1
2
3
4

Figure 3.1.1. Linx RF transmitter module


The TXM-xxx-LC-R module shown in Figure 3.1.1 performs the transmission of
digital data. The frequency (in megahertz) of the radio wave that is sent out is denoted by
xxx in the name of the chip. Thus, the TXM-315-LC-R module sends the data one
way, and the TXM-418-LC-R module sends the data the other way. A digital wave (a
square wave with the amplitude from 0 to 5 V with a frequency set by the baud rate) is
fed into the chip through pin 2 (DATA IN). The digital wave is encoded into a radio
wave inside the chip and it is sent out through an antenna, which is connected to pin 5
(RF OUT). The power supply, which will be described in section 3.3, is connected to pin
7 (VCC), and all of the other pins are connected to ground.
Additional circuitry is needed to convert the digital wave that comes out of the
serial port to another digital wave that is understood by the TXM-xxx-LC-R. Both waves
have the same frequency, which is determined by the baud rate that the user selects.
However, the waves have different amplitudes and different offsets. The wave that
comes out of pin 3 of the serial port outputs RS232 voltages -- a voltage of 12 V for a
low state and a voltage of +12 V for a high state. The TXM-xxx-LC-R, however,
operates on the TTL logic in which 0 V is a low state and 5 V is a high state.
Motorolas MC1489 and SN7404 chips are used to solve this problem. The
MC1489 takes an RS232 wave and converts it to a TTL wave with an inverted logic state.

The SN7404 TTL inverter inverts the wave back to its original logic state without
changing the amplitude or the offset. Figure 3.1.2a shows the final circuit that is used to
interface the serial port with the TXM-xxx-LC-R chip, and Figure 3.1.2b shows the
response of the circuit to a possible input wave.

+5V

T o t h e t r a n s m it t e r ( p in 2 )

1
SN 7404

F r o m t h e s e r ia l f o r t ( p in 3 )

M C 1489

Figure 3.1.2a. RS232-to-TTL conversion circuit

+12 V

P o s s ib le w a v e f r o m
t h e s e r ia l p o r t

G N D
-12 V
+ 5 V
G N D

R e s u l t in g w a v e g o in g
in t o t h e t r a n s m it t e r

Figure 3.1.2b. Response to a possible RS232 wave

3.2

Receiver
R X M -x x x -L C

10

V c c 2 .7 -4 .2 V

N C

G N D

N C

N C

G N D

R F IN

N C

V c c 4 .0 -5 .2

D ATA O U T

Figure 3.2.1. Linx RF receiver module


The RXM-xxx-LC module shown in figure 3.2.1 receives the radio waves sent by
the transmitter of the same frequency. The RXM-315-LC receives the waves sent by the
TXM-315-LC-R, and the RXM-418-LC receives the waves sent by the TXM-418-LC.
The wave is received by an antenna which is connected to pin 1 (RF IN), decoded inside
the chip into the original digital wave fed into the transmitter, and outputted on pin 5
(DATA OUT) of the chip. The power supply, which will be discussed in section 3.3, is
connected to pin 6 (Vcc 4.0-5.2). Pin 10 (Vcc 2.7-4.2V) is left unconnected, and the rest
12 V

of the pins are connected to ground.

M C 1488

14

T o t h e s e r ia l p o r t ( p in 2 )

F r o m t h e r e c e iv e r ( p in 5 )

SN 7404

-1 2 V

Figure 3.2.2. TTL-to-RS232 conversion circuit


Once again, additional circuitry is needed to convert the digital wave that comes
out of the RXM-xxx-LC to another digital wave that is understood by the serial port.
That circuit is shown in Figure 3.2.2. Motorolas MC1488 and SN7404 chips are used to
resolve this problem. First, the SN7404 TTL inverter inverts the wave that is outputted
by the RXM-xxx-LC. Then, the MC1488 converts that wave into an RS232 wave and

inverts it back to its original logic state. Note that in this case the inverter must precede
the MC1488 chip. If the inverter follows the MC1488 chip, an RS232 wave will be fed
into a TTL device (the SN7404).
3.3

Power Supply
Three input lines are used for power: a +12 V line, a 12 V line, and a 0 V

(ground) line. Since some of the chips in the circuit require a 5 V power supply, a 7805
voltage regulator is used to create a 5 V line as well. A clean 5 V DC signal is needed as
a power input to the Linx chips. As suggested by the manufacturer, a low-pass RC filter
was added between the 5 V line and the Linx modules to reduce the high frequency noise.
Figure 3.3 shows the circuit used to implement that.

+12V

7805

75 ohms

to Vcc

10 uF

Figure 3.3. Power Supply Circuit


3.4

Complete Circuit
All of the hardware components described above were put together to obtain a

complete circuit shown in Figure 3.4. Note that the circuits are identical at both stations,
except that one station uses the TXM-315-LC-R and the RXM-418-LC modules, whereas
the other station uses the TXM-418-LC-R and the RXM-315-LC modules.

10

AN TEN N A 1

7
6
5

GND

VCC

D A T A IN

GND

GND

RF OUT

1
2

SN 7404

IA D J /G N D

1
M C 1489

5
9
4
8
3
7
2
6
1

75 ohm s

AN TEN N A 2

T XM -x x x -L C -R
GND

7805
2

R S -2 3 2

9
10 uF

8
7
6

V c c 2 .7 -4 .2 V
NC
GND
NC
V c c 4 .0 -5 .2

R F IN
NC
GND
NC
D ATA O U T

1
2
3
4
5

10

+12V

R X M -x x x -L C

14

75 ohm s

M C 1488
SN 7404

10 uF

Figure 3.4. Diagram of the Complete Circuit

11

-1 2 V

3.5

Overall Software Functionality


A multithreaded program was written in Microsoft Visual C++ to control the

process of sending and receiving data. The program contains 3 threads (processes) -- a
main parent thread and two child threads. The block diagram of the overall functionality
is shown in Figure 3.5. As the figure suggests, the receiving thread and the sending
thread are the two child threads. The main thread runs in an infinite loop until it receives
an interruption signal from one of the child threads. Based on the type of the interruption
signal that the main thread receives, it either reads the data that has arrived on the serial
port, or writes the data from the sending text window to the serial port.
Figure 3.5. Overall software functionality
M A IN
THREAD

R E C E IV IN G
THREAD

3.6

S E N D IN G
THREAD

Initialization
Before entering the infinite loop, the main thread needs to initialize. To do this,

the function InitPort() is called on ports 1 through 4. The function InitPort() is a


Boolean function. Thus, besides performing the initialization, it returns TRUE if the port
is found and FALSE if the port is not found. If the port is found, the main thread is now
ready to enter the infinite loop and wait for the interruption signals from the child threads.
However, if the port is not found, the program performs and additional task -- the string
NOT FOUND is entered into the edit window (the send window in Figure 2.2.1), and

12

the edit window is disabled for data input. After that step, the main thread is ready to
enter the infinite loop and wait for the interruption signals from the child threads. Figure
3.6 shows the flow chart of this process.
Figure 3.6. The initialization procedure
START

IN IT IA L IZ E A L L P O R T S

IS P O R T
N O T
FO UN D ?

YES

O U T P U T " N O T F O U N D " IN
T H E C O R R E S P O N D IN G
E D IT W IN D O W A N D
D IS A B L E T H E
C O R R E S P O N D IN G E D IT
W IN D O W

N O

W A IT F O R S IG N A L S F R O M
C H IL D T H R E A D S

3.7

A Possible Interruption Signal: Data Needs to Be Sent


As figure 3.6 illustrates, the final step in the initialization procedure is to enter an

infinite loop that can be stopped by an interruption signal from one of the child threads.
One of such interruption signals is a signal from the sending thread notifying the main
thread that there is some text that needs to be sent. This interruption is triggered when a
user presses the Send button at his/her terminal. In response, the main thread creates a
variable buf[100], a string which is up to 100 characters long. The text that is in the edit
window is then read and put into buf. If buf is not equal to NOT FOUND, then
WriteToPort() function is called, which takes buf and sends it to the serial port.

13

Otherwise, it is assumed that the Send button was pressed on accident. As soon as this is
done, the main thread once again enters an infinite loop and waits for an interruption
signal from one of its child threads. Figure 3.7 shows the flow chart of the described
process.
Figure 3.7. Programs response to the Send button being pressed
3.8

A Possible Interruption Signal: New Data Has Arrived


SEN D BUTT O N
W AS PRESSED

C R E A T E A V A R IA B L E
b u f[1 0 0 ]

S T O R E T H E T E X T IN
T H E E D IT W IN D O W
IN T O b u f

R E A D T H E E D IT
W IN D O W

D O N O T H IN G

IS b u f = " N O T F O U N D "

YES
N O
W r it e T o P o r t ( )

Another possible interruption is triggered when new data arrives on pin 3 of the
serial port. This means that every time there is a change in the logic state of pin 3, the
main thread is notified. Under the default configuration set by the program, after every 9
bits (8 data bits and 1 stop bit), the 8 data bits are put into a variable CR, and CR is sent to

14

the main thread. Note that each text character is 8 bits (1 byte) long. This means that
transmission from the serial port to the screen is done on a character-by-character basis
under the default configuration. Every time the main thread receives CR, it immediately
appends it to the string that is in the static window (the receiving window in Figure
2.2.1.). It is important to keep in mind that the user may change the default configuration
in the configuration window (Figure 2.2.2) to allow for processing of more than one
character at a time. For instance, if the number in the Databits dropdown menu is 16
instead of 8, then 2 characters will be received at a time.
3.9

Serial Communications in Win32: Introduction


Perhaps, the biggest challenge of this project was to write a protocol in Microsoft

Visual C++, which would take care of the serial communications between the computer
and the external hardware, as well as between the serial port and the other hardware
inside the computer. A very brief description of the implementation will be given, since
the level of technical depth does not fit the purpose of this paper. However, interested
readers should consult Marshall Brain [1] for an excellent overview of serial
communications in Win32.
3.10

Serial Communications in Win32: Opening a Port


The CreateFile function takes the port name and opens that port. One thing to

note about port names is that, traditionally, they have been COM1, COM2, COM3, and
COM4. The Win32 API (Application Programming Interface) does not provide any
mechanism for determining what ports exist on the system. Windows NT and Windows
95 keep track of the installed ports differently from one another, so any one method
would not be portable across all Win32 platforms. For this reason, it is best that users

15

have the ability to specify the port they want to use. Rtalk has 4 identical windows
(Figure 2.2.1), and the user can choose which port to communicate on. Once the port has
been chosen, it is easy to determine whether that port is available on the computer.
3.11

Serial Communications in Win32: Reading and Writing


Reading to and writing from the serial port in Win32 is very similar to file

input/output (I/O) . In fact, the functions that accomplish file I/O are the same functions
used for RS232 I/0. ReadFile() and WriteFile() functions are used for reading from and
writing to the serial port respectively. Refer to Brain [1] for more information on how
those two functions are used.
3.12

Serial Communications in Win32: Events


Recall that the main thread in Rtalk runs in an infinite loop until it receives some

sort of an interruption signal. This section discusses how these events are generated and
the notifications that are produced by each event. There are two steps involved in
receiving a notification of the RS232 events. The function SetCommMask sets the
desired events that cause notification, and the function WaitCommEvent issues a status
check. The descriptions of all types of events that are used by Rtalk are summarized in
Table 3.12. Recall that the desired events are set in the configuration window of Rtalk
(Figure 2.2.2)

16

TABLE 3.12. EVENT FLAGS


Event Flag
EV_BREAK
EV_CTS
EV_DSCR
EV_ERR
EV_RING
EV_RLSD
EV_RXCHAR
EV_RXFLAG
EV_TXEMPTY

Description
A break was detected on input
The clear-to-send signal changed state
The data-set-ready signal changed state
A line-status error occurred
A ring indicator was detected
The receive-line-signal-detect signal changed state
A new character was received and placed into the input buffer
The event character was received and place in the input buffer
The last character in the output buffer was sent to the serial port

17

4. DESIGN VERIFICATION
4.1

Hardware Testing
The first thing that needed to be tested was the performance of the Linx RF

modules. With the help of the manufacturers data sheets [2], [3], the transmitter was
powered up and connected to a function generator. The receiver was powered up and
connected to an oscilloscope. The purpose of this test setup was to make sure that the
wave that was outputted from the signal generator was the same as the wave that was fed
into the oscilloscope. The signal generator was configured to output a digital wave
between 0 V and 5 V with a frequency of 200 Hz. As expected, the same wave appeared
on the oscilloscope, signifying that the data that was sent by the transmitter was the same
as that received by the receiver. As the frequency of the wave that was outputted from
the signal generator was gradually increased, the wave on the oscilloscope was changing
accordingly.
The next step was to check the functionality of the hardware with the additional
circuitry mentioned in sections 3.1 through 3.3. The same testing procedures were
adopted as before, except that now the signal generator produced a wave between 12 V
and +12 V. After some circuit debugging, the desired performance was achieved.
Finally, two prototypes of the complete circuit described in section 3.4 were
connected to two computers, and the HyperTerminal program was used to make sure
that text could in fact be transferred through this link. Once communication between the
two machines was stable, it was concluded that the hardware aspect of the project was
completed.

18

4.2

Software Testing
Once the first version of Rtalk was written, an oscilloscope was connected to pin

3 of the serial port of a computer. This setup was used to test whether the computer was
outputting the data that was typed on the screen. A very low baud rate was used to see
each bit that the serial port was outputting. Character by character was sent to make sure
that the oscilloscope was outputting the ASCII equivalent of each character.
Once it was clear that the serial port was outputting the correct information, two
computers running Rtalk were connected to each other by a serial cable to make sure that
the computer could read the received information as well. After a few weeks of
debugging, the desired performance was obtained.
The final step was to make sure that the software worked properly under various
configuration schemes. Rtalk was tested with different values in the configuration
window (Figure 2.2.2). As expected, the program performed correctly.
4.3

Final Product Testing


The last step in testing the product was to make sure that the software and the

hardware aspects did not just work independently, but that they worked together as well.
Two prototypes of the complete circuit (Figure 3.4) were connected to two machines with
Rtalk running on both of them. After some minor debugging, the desired performance
was achieved.

19

5. COSTS
Table 5.1 summarizes the cost of this project. Labor comprised most of the cost
of this, since there was not a lot of hardware required for this project. Note that the
software development tools were not included in the cost analysis, since the cost of using
Microsoft Visual C++ for one project is not well defined.
TABLE 5.1 PROJECT COST SUMMARY
QUANTITY
100 hours
2 parts
2 parts
2 parts
2 parts
2 parts
2 parts

DESCRIPTION
Labor
RF Transmitter
RF Receiver
Line Receiver
Line Driver
Inverter
Regulator

PART NUMBER
TXM-xxx-LC
RXM-xxx-LC
MC1489
MC1488
SN7404
MC7805

UNIT COST TOTAL COST


$30.00*2.5
$7500.00
$5.60
$11.20
$11.80
$23.60
$0.26
$0.52
$0.36
$0.72
$0.25
$0.50
$0.50
$1.00
TOTAL
$7537.54

20

6. CONCLUSIONS
After undergoing its planning, design, implementation, and development stages,
this project was presented in front of the audience consisting of faculty members and
students at the University of Illinois at Urbana-Champaign. It was shown that the
specifications set by the proposal were met, and that the end product was functioning
correctly. Some of the strengths of the product as compared to some of the similar
products that already exist include wireless transmission, an advanced user interface, and
a low production cost. Some drawbacks include slow transmission time and a limitation
on the amount of users allowed (two being the maximum). These would probably be the
next few areas of improvement if anyone were to continue working on this project.

21

REFERENCES
[1] M. Brain, Win32 Systems Services: The Heart of Windows NT. Englewood Cliffs, NJ:
Prentice Hall, 1994.
[2] Linx Technology Technical Staff, LC Series Receiver Module Data Guide for RMX315-LC, RMX-418-LC and RMX-433-LC, Linx Technology Inc. 1997.
[3] Linx Technology Technical Staff, LC Series Transmitter Module Data Guide for
TMX-315-LC, TMX-418-LC and TMX-433-LC, Linx Technology Inc. 1997.

22