FINAL YEAR PROJECT REPORT ON

Practical Implementation of Wireless Integrated Network Sensors (WINS):

A Novel Approach to sensing over the FM band and across the web.

Submitted in Partial fulfillment for the Requirement of

Degree of Bachelor of Engineering in Electronics & Communication Engineering

By:

SAMEER MEHTA 2K1/EC/678

AMIT GOEL 2K1/EC/606

Under the guidance of

Prof. Asok Bhattacharyya & Ms. S.Indu

Department of Electronics and Communication Engineering

Delhi College of Engineering

DEPARTMENT OF ELECTRONICS AND COMMUNICATION ENGINEERING

DELHI COLLEGE OF ENGINEERING

UNIVERSITY OF DELHI, DELHI - 110042

2001-05

Certificate

This is to certify that the dissertation entitled “A Practical Implementation of Wireless Integrated
Network Sensors (WINS): A Novel Approach to sensing over the FM band and across the web.”
being submitted by Sameer Mehta and Amit Goel towards the partial fulfillment of the requirement
for the award of the degree of Bachelor of Engineering in the Department of Electronics and
Communication Engineering at the Delhi College of Engineering, Delhi is a bona fide record of
their work carried out under my supervision.

Further it is also certified that the matter and results in this dissertation are original and have not
been submitted for any degree or diploma in any other college to the best of my knowledge.

Dated: May 30, 2005

Prof. Asok Bhattacharyya

Head & Professor

Department of Electronics & Comm. Engineering

Delhi College of Engineering

Ms. S. Indu

Lecturer

Department of Electronics & Comm. Engineering

Delhi College of Engineering

Acknowledgement

We wish to express our hearty and sincere gratitude and ineptness to Ms. S Indu, Department of
Electronics & Communication Engineering, Delhi College of Engineering, Delhi for her invaluable
guidance and wholehearted cooperation. She has been a major source of inspiration throughout
the project as she has not only guided us through the project but also encouraged us to solve the
problems that arose during this project.

We would also like to thank Prof. Asok Bhattacharyya for his able guidance, valuable
suggestions, constant encouragement and untiring efforts at every stage of our project, without
which it would have been impossible to bring this work to completion.

The conclusion of our project with combined achievements & failures was a great moment of
pleasure for us. This project is a result of the contribution of many people. They have enriched
our knowledge & made suggestions based on their experience. We would like to thank the entire
faculty of Electronics & Communication Engineering Department for their co-operation and
tremendous help rendered in numerous ways for the successful completion of this work.

Most importantly, I would like to thank my parents, friends and colleagues for invaluable
suggestions and critical review of our project.

Sameer Mehta
2K1/EC/678

Amit Goel
2K1/EC/606

Contents
1. Abstract / Scope of the Project 4

2. Wireless Integrated Network Sensor (WINS) System Architecture 6

3. WINS Node Architecture 6

4. WINS Sensors 7

5. WINS Sensor Interface Circuits 7

6. WINS Digital Signal Processing 7

7. Practical Architecture of the system developed 8

8. Block Diagram Representation of the overall system 9

9. The Modules – in Detail

9.1. The ADC unit 11

9.2. Data Processing and Controller Unit: 17

9.3. DTMF generator IC triggering unit: 22

9.4. DTMF tone generation unit 25

9.5. FM transmitter 26

9.6. FM receiver 31

9.7. Tone Decoding Unit 31

9.8. The Circuit-to-PC interface 34

9.9. RTProggy & RTParser 37

9.10.ASP Script 40

10. Sample WINS Implementation & Calculation of rate of transfer of information 42

11. Scope for the Future 44

12. References 45

Appendix A 46

Appendix B 52

Appendix C 57

Appendix D 62
Appendix E 65

1. Abstract / Scope of the Project

Wireless integrated Network Sensors (WINS) now provide a new monitoring and control
capability for transportation, manufacturing, health care, environmental monitoring, and safety
and security. WINS combine sensing, signal processing, decision capability, and wireless
networking capability in a compact, low power system. WINS systems combine sensor
technology with low power sensor interface, signal processing, and RF communication circuits.
This project describes low power sensors, data converter, digital signal processing systems, and
RF circuits. This project presents an implementation for small scale WINS vis-à-vis FM band
sensor / control modules planted in a small area within SOHO environment. The sensing, Control
modules work with 12-16 discrete levels of frequency each signifying a unique nibble. The entire
hardware for the same has been developed as a prototype.

Wireless integrated network sensors (WINS) combine sensing, signal processing, decision
capability, and wireless networking capability in a compact, low power system. Low cost allows
WINS to be embedded and distributed at a small fraction of the cost of conventional wireline
sensor and actuator systems. For example, on a global scale, WINS will permit monitoring of
land, water, and air resources for environmental monitoring. On a national scale, transportation
systems, and borders will be monitored for efficiency, safety, and security. On a local, wide-area
scale, battlefield situational awareness will provide personnel health monitoring and enhance
security and efficiency. Also, on a metropolitan scale, new traffic, security, emergency, and
disaster recovery services will be enabled by WINS. On a local, enterprise scale, WINS will
create a manufacturing information service for cost and quality control. WINS for biomedicine will
connect patients in the clinic, ambulatory outpatient services, and medical professionals to
sensing, monitoring, and control. On a local machine scale, WINS condition based maintenance
devices will equip power plants, appliances, vehicles, and energy systems for enhancements in
reliability, reductions in energy usage, and improvements in quality of service.
Here, we limit ourselves to sensing application designed to detect and identify activities within
some geographic region and reports the decisions concerning the presence and nature of such
events to a remote observer via the local network and across the web. In the context of this appli-
cation, we discuss how to embed WINS nodes in a Wireless local network, and describe a
prototype platform enabling these functions, including remote control and analysis of sensor-
network operation.

2. Wireless Integrated Network Sensor (WINS) System Architecture

The primary limitation on WINS node cost and volume arises from power requirements and the
need for battery energy sources. However, wireless communication energy requirements present
additional severe demands. Conventional wireless networks are supported by complex protocols
that are developed for voice and data transmission for handhelds and mobile terminals. These
networks are also developed to support communication over long range (up to 1km or more) with
link bit rate over 100kbps.

In contrast to conventional wireless networks, the WINS network must support large numbers of
sensors in a local area with short range and low average bit rate communication (less than
1kbps). The network design must consider the requirement to service dense sensor distributions
with an emphasis on recovering environment information.

3. WINS Node Architecture

The WINS node architecture (see Figure 1) is developed to enable continuous sensing, event
detection, and event identification at low power. Since the event detection process must occur
continuously, the sensor, data converter, data buffer, and data processor (microcontroller) must
all operate at micro power levels. In the event that an event is detected, the data processor
output may trigger the transmission through RF circuit. The microcontroller may then issue
commands for additional signal processing operations for identification of the event signal.

Primary LWIM applications require sensor nodes powered by compact battery cells. Total
average system supply currents must be less than 30µA to provide long operating life from typical
compact Li coin cells. Low power, reliable, and efficient network operation is obtained with
intelligent sensor nodes that include sensor signal processing, control, and a wireless network
interface. Distributed network sensor devices must continuously monitor multiple sensor systems,
process sensor signals, and adapt to changing environments and user requirements, while
completing decisions on measured signals. Clearly, for low power operation, network protocols
must minimize the operation duty cycle of the high power RF communication system.
Figure 1: WINS architecture includes sensor, data converter, signal processing and control
functions. Microwave RF communication provides bidirectional very low bit rate, short range
communication. The micropower components operate continuously for event recognition whereas
the network interface operates at a low duty cycle.

4. WINS Sensors

The sensors can be different for monitoring different parameters or we can have distributed
sensors of the same type for more precise and accurate information. Many important WINS
applications require the detection of signal sources in the presence of environmental noise.
Source signals all decay in amplitude rapidly with radial distance from the source. To maximize
detection range, sensor sensitivity must be optimized. In addition, due to the fundamental limits of
background noise, a maximum detection range exists for any sensor. Thus, it is critical to obtain
the greatest sensitivity and to develop compact sensors that may be widely distributed.

5. WINS Sensor Interface Circuits

The WINS sensor systems must be monitored continuously by the CMOS analog-to-digital
converter (ADC). The ADC needs to be chosen carefully keeping in mind the bandwidth of the
output signal of the sensor and nyquist criteria (for example the infrared micro sensor bandwidth
is 50Hz, thus limiting required sample rate to 100 Hz). Another parameter is the precision of
digital data i.e. the bit equivalent of sampled data. High bit output ADC should be used for more
precision.

6. WINS Digital Signal Processing

The WINS architecture relies on a low power processor to process all ADC output data to identify
an event in the physical input signal time series. This data is processed using a microcontroller
pre-programmed for the specific task. And when the input reaches the levels stored in a look up
table then the microcontroller triggers the appropriate action for sending the required information
wirelessly across the wireless network interface.

7. Practical Architecture of the system developed

The complete unit comprises of 9 modules. Each module does a specific task by transforming
information from one form into another.

I. The ADC unit: This unit transforms the basic information i.e. the voltage status into
discrete levels, which can be directly interfaced with other part of the circuit.

II. Data Processing and Controller Unit: This unit contains the 8051 microcontroller,
which is interfaced to the ADC and controls the rest of the circuit corresponding to the value
obtained from the ADC.

III. DTMF generator IC triggering unit: Makes use of the classic Opto-coupler-Darlington
combination to drive relays and shorting the IC pins for tone generation.

IV. DTMF tone generation unit: This unit generates a specific tone for a given battery
condition thus making the information ready to be transmitted through the RF band.

V. FM transmitter: This unit modulates the tone in the audio range into the FM range
carrier frequency at around 100 MHz.

VI. FM receiver: This unit is the counterpart of the transmitter section and demodulates
the carrier frequency to get back the status defining audible DTMF tone.

VII. Tone Decoding Unit: The tone decoding unit takes in the DTMF tone and gives out a
BCD nibble corresponding to each tone. This is the part where the information is transformed into
something, which is purely digital which a uC can interpret.

VIII. The Circuit-to-PC interface using uC: The microcontroller (ATMEL 89C52) unit makes
use of the info in digital form available to one of its ports and sends it serially to the server PC
through a MAX 232 interface.

IX. RTProggy & RTParser: Software for server to monitor the status at first into a text file
and then parsing the same into a database.

X. ASP Script: Server Side Script running to give a user interface to see the status of
attached devices whose status is being monitored.

8. Block Diagram Representation of the overall system

Figure 2: Block Diagram for tone generation and transmission

Figure 3: Block Diagram of decoding unit (central RX)

Figure 4: Block Diagram for WWW integration. (Parsing data to database)

9. The Modules – in Detail

9.1 - The ADC unit

We used 2 kinds of ADC units:

* LM3914 based
* ADC0804 based

LM3914:
This unit was required to convert the analog voltages to discrete levels to identify the status of the
battery. To accomplish this task we used a Bar graph/ LED driver IC. The LM3914 IC. This IC
which internally contains a series of comparators is capable of resolving voltage levels which can
be determined by setting the upper and lower reference voltage limits. Corresponding to this
range the IC is capable of setting one of the ten outputs high. Like this if we keep the lower
voltage level 5V and higher 7V then we can resolve the incoming signal to a level of (7- 5)/10 =
0.2V. Thus corresponding to the input voltage one of the ten output line goes low (high by
default).

The IC thus proved to be the right type of ADC suiting our all needs. The IC was low cost, robust
and very versatile. But the problem with this IC was that the output voltage levels were 3.5V for
HIGH and 2.7V for LOW which were certainly not TTL compatible and rendered the IC
incompatible with the following stages of the circuit. To make it TTL compatible we employed the
popular LM339 Quad Comparator IC which needs unipolar reference voltage supply.

The comparators inside LM339 solved our problems as we fixed a reference voltage of 3 V at one
terminal of every comparator and thus the +3.5 and +2.7 could be converted to +5V and 0V
respectively .The Bar Graph LED driver IC was operated in the dot mode to make high one pin at
a time. Also a protection was provided at input side (high input impedance buffer) to ensure that
the unit itself does not consume too much power thus depleting the UPS battery itself.

IC description:
LM3914: Dot/Bar Display Driver

The LM3914 is a monolithic integrated circuit that senses analog voltage levels and drives 10
LEDs, providing a linear analog display. A single pin changes the display from a moving dot to a
bar graph. Current drive to the LEDs is regulated and programmable, eliminating the need for
resistors. This feature is one that allows operation of the whole system from less than 3V. The
circuit contains its own adjustable reference and accurate 10-step voltage divider. The low-bias-
current input buffer accepts signals down to ground, or V - , yet needs no protection against
inputs of 35V above or below ground. The buffer drives 10 individual comparators referenced to
the precision divider. Indication non-linearity can thus be held typically to 1 /2%, even over a wide
temperature range.

Versatility was designed into the LM3914 so that controller, visual alarm, and expanded scale
functions are easily added on to the display system. The circuit can drive LEDs of many colors, or
low-current incandescent lamps. Many LM3914s can be “chained” to form displays of 20 to over
100 segments. Both ends of the voltage divider are externally avail-able so that 2 drivers can be
made into a zero-center meter. The LM3914 is very easy to apply as an analog meter circuit. A
1.2V full-scale meter requires only 1 resistor and a single 3V to 15V supply in addition to the 10
display LEDs. If the 1 resistor is a pot, it becomes the LED brightness control. The simplified
block diagram illustrates this extremely simple external circuitry. When in the dot mode, there is a
small amount of overlap or “fade” (about 1 mV) between segments. This assures that at no time
will all LEDs be “OFF”, and thus any ambiguous display is avoided. Various novel displays are
possible. Much of the display flexibility derives from the fact that all outputs are individual, DC
regulated currents. Various effects can be achieved by modulating these currents. The individual
outputs can drive a transistor as well as a LED at the same time, so controller functions including
“staging” control can be performed. The LM3914 can also act as a programmer, or sequencer.
The LM3914 is rated for operation from 0°C to +70°C. The LM3914N-1 is available in an 18-lead
molded (N) package. The following typical application illustrates adjusting of the reference to a
desired value, and proper grounding for accurate operation, and avoiding oscillations.
Features

* Drives LEDs, LCDs or vacuum fluorescents

* Bar or dot display mode externally selectable by user
* Expandable to displays of 100 steps
* Internal voltage reference from 1.2V to 12V
* Operates with single supply of less than 3V
* Inputs operate down to ground
* Output current programmable from 2 mA to 30 mA
* No multiplex switching or interaction between outputs
* Input withstands ±35V without damage or false outputs
* LED driver outputs are current regulated open-collectors
* The internal 10-step divider is floating and can be referenced to a wide range of voltages.
Figure 5: LM3914 schematic

LM339

Low Power Quad Operational Amplifier

Advantages

* Eliminates need for dual supplies

* Four internally compensated op amps in a single package
* Allows directly sensing near GND and Vout also goes to GND
* Compatible with all forms of logic
* Power drain suitable for battery operation

Features

* Internally frequency compensated for unity gain

* Large DC voltage gain 100 dB
* Wide bandwidth (unity gain) 1 MHz (temperature compensated)
* Wide power supply range: Single supply 3V to 32V or dual supplies ±1.5V to ±16V
* Very low supply current drain (700 µA)—essentially independent of supply voltage
* Low input biasing current 45 nA (temperature compensated)
* Low input offset voltage 2 mV and offset current: 5 nA
* Input common-mode voltage range includes ground
* Differential input voltage range equal to the power supply voltage
* Large output voltage swing 0V to V+ − 1.5V

Figure 6: LM339 internal diagram

Figure 7: ORCAD schematic of LM3914 and LM339 combination

AD0804 based

Figure 8: Pin Diagram for ADC0804

Features:

* Compatible with 8080 μP derivatives—no interfacing logic needed - access time -

135 ns
* Easy interface to all microprocessors, or operates “stand alone”
* Differential analog voltage inputs
* Logic inputs and outputs meet both MOS and TTL voltage level specifications
* Works with 2.5V (LM336) voltage reference
* On-chip clock generator
* 0V to 5V analog input voltage range with single 5V supply
* No zero adjust required
* 0.3" standard width 20-pin DIP package
* 20-pin molded chip carrier or small outline package
* Operates ratiometrically or with 5 VDC, 2.5 VDC, or analog span adjusted voltage
reference

* Resolution 8 bits
* Total error ±1⁄4 LSB, ±1⁄2 LSB and ±1 LSB
* Conversion time 100 μs

Figure 9: ADC 0804 is used in Free Running mode.

For operation in the free-running mode an initializing pulse should be used, following
power-up, to ensure circuit operation. In the above application, the CS input is
grounded and the WR input is tied to the INTR output. This WR and INTR node should
be momentarily forced to logic low following a power-up cycle to guarantee
operation.
9.2 - Data Processing and Controller Unit

This stage contains the 8051 microcontroller, which is interfaced to the ADC, and
controls all the other modules attached after this stage.

Microcontrollers are used to add intelligence to the circuit. Appendix A gives a

detailed account of microcontrollers (Intel 8051).

Figure 9: Block Diagram showing 8051 interfaced with ADC

Figure 10: Circuitry for ADC interfacing

The firmware code for the microcontroller is given below:

#include<8051.h>

#define tone1 P3_3

#define tone0 P3_5

#define on 0

#define off 1

#define tone_on_time 200

#define tone_off_time 200

#define token_0 P1_0

#define token_1 P1_1

#define token_2 P1_2

#define token_3 P1_3

#define token_4 P1_4

#define token_5 P1_5

#define token_6 P1_6

#define token_7 P1_7

#define adc P2

#define token P1

bit flag=0;

unsigned char i;

void msec_wait(unsigned char Time)

{
 ACC = Time;

_asm

mov r2, a

00003$:

mov r1, #0x05

00002$:

mov r0, #0x64

00001$:

djnz r0, 00001$

djnz r1, 00002$

djnz r2, 00003$

_endasm;

return;

void sec_wait(unsigned char Time)

ACC = Time;

_asm

mov r3, a

00004$:

mov r2, #0x14

00003$:

mov r1, #0x64

00002$:

mov r0, #0xFA

00001$:

djnz r0, 00001$

djnz r1, 00002$

djnz r2, 00003$

djnz r3, 00004$

_endasm;

return;

void transmit0()

tone0=on;

msec_wait(tone_on_time);

tone0=off;

msec_wait(tone_off_time);

}
void transmit1()

tone1=on;

msec_wait(tone_on_time);

tone1=off;

msec_wait(tone_off_time);

void send_id()

transmit1();

transmit0();

transmit1();

transmit0();

void transmit()

send_id();

if(token_0==0)

transmit0();

else transmit1();

if(token_1==0)

transmit0();

else transmit1();
 if(token_2==0)

transmit0();

else transmit1();

if(token_3==0)

transmit0();

else transmit1();

if(token_4==0)

transmit0();

else transmit1();

if(token_5==0)

transmit0();

else transmit1();

if(token_6==0)

transmit0();

else transmit1();

if(token_7==0)

transmit0();

else transmit1();

void main()

while(1){
 sec_wait(2);

if(token!=adc)

{flag=1;}

while(flag)

token=adc;

flag=0;

transmit();

}
9.3 - DTMF generator IC triggering unit

The DTMF encoder needs that for tone generation one of its row pins and one of its
column pins must be physically shorted. For this our first attempt was with the use of
MOSFET as a switch for shorting but on analysis we realized that the ON resistance of
the MOSFET was too high (nearly 600 ohms) to be used for the IC. So we had to look
at Relays.

Relays brought in a whole new set of problems while interfacing (due to high current
requirements and the fact that they load the IC itself). To get around this we used the
classical Opto-Coupler (MCT2E)-Darlington (TIP122) combination to drive the relays at
their required current levels.

Here the low output of the LM339 is fed through a 330E resistor to the cathode of the
photo diode of the MCT2E and the anode is at +5V so when the terminal goes low the
diode lights up and optically triggers the base of the transistor and pushed it into
saturation and the current flows between the collector and the emitter, this output is
used to excite the TIP122 (darlington paired transistors for max amplification and
then this is used to drive the Relay.

Another approach could be to use a simple buffer but as a commercial solution it is

not recommended as our experience told us that they dont last too long and suffer
from over heating problem.

MCT2E

The MCT2XXX series optoisolators consist of a

gallium arsenide infrared emitting diode driving a

silicon phototransistor in a 6-pin dual in-line package.

Figure 11: MCT2E Schematic

TIP122

The TIP120, TIP121 and TIP122 are silicon

epitaxial-base NPN power transistors in monolithic

Darlington configuration Jedec TO-220 plastic

Package, intended for use in power linear and switching

applications.

Figure 12: TIP 122 (Darlington Pair)

Figure 13: ORCAD Schematic for relays interfaced with controller.

Figure 14: ORCAD Schematic for modules I, II and III

9.4 - DTMF tone generation unit

The next module to build was the DTMF generator block. This employed the
UM91214B IC pulled out of any standard telephone at your home. The IC is used very
simply again, the only special care to be taken is that one of pins cannot take a
voltage greater than 3.3 V which we maintained by using a zener diode regulated
supply.

The tones are generated by shorting 2 terminals physically (done by relays)

and the tone is generated on pin no. 7. Initially MOSFET switches were tried, but
owing to their large ON resistance (700 ohms) they had to be discarded.

For tone generation we use a 4X4 matrix with each row and column representing a
unique frequency and it gives a unique output to every row and column combination
selected by simple superimposing the corresponding frequencies.

Frequency Table

ROW #

fr (x) (Hz)

R1: ROW 0

697

R2: ROW 1

770

R3: ROW 2

852

R4: ROW 3
941

COL #

fc (y) (Hz)

C1: COL 0

1209

C2: COL 1

1336

C3: COL 2

1477

C4: COL 3

1633

Table 1: Frequency alias for rows and columns

Thus the output frequency has 2 frequency components. (Shown in figure 15).

fo= fr (x) + fc (y)

fo = Output frequency

fr (x) = Frequency of row x

fc (y) = Frequency of column y

Figure 15: Output Frequency

9.5 - FM transmitter

We have built 3 types of transmitters for different application needs. Two of these are
transistor (discrete components) based and 1 is based on a commercial grade VCO
(MAX 2606).

The basic structure of each of the transmitters is an oscillator followed by 1 or 2

stages of RF tuned amplifiers and finally a power amplifier stage to be interfaced with
an antenna.

Figure 16: FM TX Block Diagram

· MAX 2606 based FM Transmitter [2]

The output is between 88MHz and 108MHz, and allows transmitting audio signals to FM radios
for remote listening. A schematic is provided with all component values to complete the project.
Output power is ~ -21dBm, and the IC operates on 3V.

Figure 17: Schematic for MAX 2606 based FM Transmitter [2]

IC1 is a voltage-controlled oscillator with integrated varactor. Its nominal frequency of oscillation
is set by inductor L1, and a 390nH value places that frequency at 100MHz. Potentiometer R1
then lets you select a channel by tuning over the FM band of 88MHz to 108MHz. Output power is
about -21dBm into 50 (most countries accept emissions below 10dBm in the FM band).

The audio unit's left and right audio signals are summed by R3 and R4, and attenuated by the
(optional) potentiometer R2. R2's wiper signal serves as a volume control by modulating the RF
frequency. Signals above 60mV introduce distortion, so the pot attenuates down from that level.

In the absence of a standard FM radio antenna, 75cm (30 inches) of wire will suffice as a
transmitting antenna. For best reception, it should be mounted parallel with the receiving antenna.
The IC operates on a single supply voltage in the range 3V to 5V, but one must regulate the
applied voltage to minimize frequency drift and noise.

· Transistor VCO based (long range version)

§ No. of stages: 4
§ Frequency of operation: About 100MHz

§ Antenna type: Folded 300 ohms dipole.

§ Range obtained in free space: Up to 4km with dipole antenna 30 feet above ground level.
More range with yagi antenna.

The transmitter is built on a Printed Circuit Board. The section built around Q1 is the oscillator
section. Oscillation frequency is determined by L1, C4 & C5 which forms the tank. Actually C5 is
the feedback capacitor. This is required to sustain oscillation. This also influences the operation
of tank formed by L1 & C4. Modulation is directly applied to the base of Q1 via C2. A microphone
is connected here to serve this purpose. You can alternately feed direct audio (the output of the
FM receiver in this case) here after disconnecting the microphone biasing resistor R1. Q2, Q3 &
Q4 gradually raises the output power up to the desired level. There is practically very little
frequency drift provided you use a highly regulated and ripple free power supply.

Figure 17: Schematic for discrete components based FM Transmitter

§ Antenna Construction

In this circuit the antenna can be a simple 22 Gauge Copper wire (that is used in transformer
windings of about lambda / 16 length), however one important thing to be kept in mind is to
remove the coating from the end while joining the antenna to the circuit.

Another solution could be a telescopic antenna, however the best way out is a BALUN.

RF output from the transmitter is taken from the junction of C11 & C12. This is unbalanced output
of around 75 ohms impedance. But a folded dipole is a balanced type antenna of around 300
ohms impedance. So we need to use a 'BALanced to UNbalanced transformer' or 'BALUN'. A 1:4
type BALUN is employed here for this purpose. Antenna connection is taken from this BALUN via
a 300 ohms flat parallel feeder cable commonly used in television to receive terrestrial broadcast.
No coaxial is used to feed antenna. This saves cost. Also a parallel feeder cable provides much
less signal loss compared to a coaxial. However in our circuit we have just connected a
telescopic antenna for this purpose and the connection of ‘BALUN’ has been skipped.

§ Design of BALUN

BALUN

Figure 18: BALUN

The BALUN is made using a two-hole binocular ferrite bead as shown above. You need to use
parallel insulated twin wire to construct this. This wire is commonly used to wind TV BALUN
transformer. If you want to get rid of this, then buy a ready-made TV BALUN that is generally
used at the back of your television set for interfacing with feeder wire.
BALUN circuit

Figure 19: BALUN circuit diagram

However since the range required was small therefore we used a simple telescopic antenna in
place of the ‘BALUN’.

§ Detailed Parts List:

Resistors

R1 - 22K

R2 - 100K

R3, R7, R9 - 1K

R4, R8 - 100E

R5 - 390E

R6 - 330E

R10 - 50E

R11 - 10K

Capacitors

C1, C10 - 1n

C3 – 22pF

C2 - 100n

C8, C9 - 47pF

C4 – variable 25pF

C11 - 10pF

C5 – 4.7 pF

C6 - 100uF/25V Electrolytic

C7 - 330pF

C12 - 47pF
Transistors

Q1, Q2, Q3 – 3904

Q4 - PN2369 (Plastic casing) or 2N2369 (Metal casing)

Misc.

L1, L2, L3 – 5-7 turns, 22SWG wire, 3mm ID, Close wound, Air core.

Two hole binocular BALUN core, BALUN wire, 300 ohms TV feeder wire,

· Transistor VCO based (short range version)

This is another transistor based FM Tx without any RF Tuned Amplifiers. This though gives lesser
range but is much simpler and cheaper to build.

9.6 – FM Receiver

Instead of making a FM receiver ourselves we used a ready made 3-V AA battery driven
FM receiver in our receiver module. The demodulated tone comes out from the audio out jack of
the FM receiver and is fed to the 8870 decoder IC ;( the next module).

9.7 - Tone Decoding Unit

The tone decoding unit uses the 8870 DTMF tone decoder IC. The decoder also uses a 3.57
MHz xtal for generating the reference frequency. It takes in the tone and generates a
corresponding BCD nibble at the 11,12,13 and 14 pins.

Figure 20a: CM8870 Circuit

The CAMD CM8870/70C provides full DTMF receiver capability by integrating both the band-split
filter and digital decoder functions into a single 18-pin DIP, SOIC, or 20-pin PLCC package. The
CM8870/70C is manufactured using state-of-the-art CMOS process technology for low power
consumption (35mW, MAX) and precise data handling. The filter section uses a switched
capacitor technique for both high and low group filters and dial tone rejection. The CM8870/70C
decoder uses digital counting techniques for the detection and decoding of all 16 DTMF tone
pairs into a 4-bit code. This DTMF receiver minimizes external component count by providing an
on-chip differential input amplifier, clock generator, and a latched three-state interface bus. The
on-chip clock generator requires only a low cost TV crystal or ceramic resonator as an external
component.

Table 2: CM8870 Pin Functions

Table 3: Functional Decode Table

9.8 - The Circuit-to-PC interface using uC

This part of the device deals with the task of sending the decoded BCD nibble from the decoder
output to the server. For this we used an ATMEL 89C52 microcontroller capable of serially
transmitting data. The uC monitored the decoded data at its port 2 and transmitted it when asked
from the server side. MAX232 IC was used for converting TTL voltage levels (0V,5V) to the
RS232 voltage levels (8V, -8V) for (low, high) respectively. More details about serial
communication using the AT89C51 can be taken from Appendix B.

In this module, the decoded value is read by an AT89c51 chip from the CM8870 output terminals
and this value is indicated to the PC by transferring it serially to RTProggy across the serial port.

Given below is a sample program for the same, this program reads the decoded value and
transmits a unique character for certain predefined decoded values.

#include<8051.h>

volatile unsigned char ucDecoded_val;

volatile unsigned char rsbuff[4];

volatile unsigned char rsbuff_index = 0;

void msec_wait(unsigned char Time)

ACC = Time;

_asm

mov r2, a

00003$:
 mov r1, #0x05

00002$:

mov r0, #0x64

00001$:

djnz r0, 00001$

djnz r1, 00002$

djnz r2, 00003$

_endasm;

return;

void serial(void) interrupt 4

if (TI) {

TI = 0;

P1_0 = 0;

if (RI) {

RI = 0;

P1_1 = 0;

rsbuff[rsbuff_index] = SBUF;

rsbuff_index++;
 }

void main(void)

TMOD=0X21;

PCON=PCON|0X80;

SM0=0;

SM1=1;

SM2=0;

REN=1;

EA=1;

ES=1;

TH1=0XFD; //serial comm at 19200 baud rate

TR1=1;

while(1) {

ucDecoded_val = P2;

ucDecoded_val = (ucDecoded_val & 0X0F);

P1_2=0;

switch (ucDecoded_val) {

case 0X01:

SBUF = 'a';

break;

case 0X02:

SBUF = 'b';

break;
 case 0X04:

SBUF = 'c';

break;

case 0X08:

SBUF = 'd';

break;

case 0X0F:

SBUF = 'e';

break;

default:

SBUF = 'x';

break;

msec_wait(200);

rsbuff_index = 0;

9.9 – RTProggy and RTParser

RTProggy and RTParser are softwares developed for complete integration of the module with a
server. RTProggy (short for Receiver Transmitter Program) is a GUI for serial communication via
the COM port on a windows based server. RTParser is a tool which parses the contents of the log
file obtained from RTProggy and stores them sequentially in a database which enables this data
to be accessed across the web once put on a web server.

Figure 21: Block Diagram of the server side application

RTProggy is similar in functionality to HyperTerminal or MCOMM. It is basically a GUI based tool

to communicate with external hardware across the COM port.

Given below are some of the snapshots for the program.

Figure 22: Snapshot I (RTProggy)

The Green Light on the top right indicates that the COM port is open. The settings for which
(19200,n,8,1) are displayed on the status bar. The number on the bottom right indicates time
since the port is open.

Figure 23: Snapshot II (RTProggy)

The above snapshot shows the user defined settings tab of RTProggy. RTProggy gives the user
complete control of all the settings for communication.

The complete executable of RTProggy is given in the accompanying CD.

RTParser is a small tool developed in VB 6.0 to parse the log file output of RTProggy into an
access database and thereby it does the work of indexing the data received from the RF receiver.

Figure 24: Block Diagram for RTParser

Figure 25: Snapshot I (RTParser)

The input to the program is a text file, this text file has to be stored into the access database after
being parsed. The parsing mechanism is of using a delimiter character, Eg. If input is 111*24*suf

This would be stored in the table of the database as ‘111’ in the first column, ‘24’ in the second
and ‘suf’ in the third.

The complete executable of RTParser is given in the accompanying CD.

9.10 - ASP Script

This script is used for giving an interface to the user across the web.

<html>

<head>

<title>RTProggy Web Interface</title>

<script language="JavaScript1.2">

<!--

function refresh()

window.location.reload( false );

//-->

</script>

</head>

<body>

<font face=verdana size=1px>

<script language="JavaScript">

<!--

document.write('<b>' + (new Date).toLocaleString() + '</b>');

//-->

</script>

<form method="GET" action="2.asp">

<p><input type="button" onclick="refresh()" value="Refresh Page!" name="button1"></p>

</form>

</body>

</html>

<%

Dim Conn

Dim SQLTemp

Set Conn = Server.CreateObject("ADODB.Connection")

Conn.connectionstring ="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" &

Server.MapPath("\Testdata.mdb")& ";"

Conn.Open

SQLTemp = "SELECT * FROM DataValues"

set rstemp=Conn.execute(SQLTemp)

Do While Not rstemp.EOF

%>

<table>

<tr>

<td bgcolor=eee5de><font face=verdana size=1><%= rstemp.Fields("KeyValue").Value %> </td>

<td bgcolor=eee5de><font face=verdana size=1><%= rstemp.Fields("Value1").Value %> </td>

<td bgcolor=eee5de><font face=verdana size=1><%= rstemp.Fields("Value2").Value %> </td>

</tr>

<br>

<%

rstemp.MoveNext

Loop

Conn.Close

Set Conn = Nothing

%>
10. Sample WINS Implementation & Calculation of rate of transfer of information

Sample WINS Implementation

A system can be developed for sensing the temperature, voltage level of battery, time from an
RTC, obstruction in path of IR monitored path, serial data from PC. All these sensors are spread
in an area with physical obstruction in between. The architectural setup for evaluation can be set
up as per the following specifications:

No. of sensing units: 5

Area of operation: 100 mtr radius

Inter-node distance: approx 60 mtr

Frequency of sensors: once in 60 seconds

Path obstruction: 6 inches concrete wall

Operating frequency: 101.2 MHz

RF Transmitter: VCO based FM TX

RF Receiver: Conventional receiver tuned to desired Frequency

Microntroller Used: ATMEL89C52 (Intel 8051 architecture)

Figure 26: The physical overview of the architecture

Sample Protocol for Information Exchange

The sensors make use of the listen before speak methodology for identifying the channel
availability. Each sensor device gets a random back off time (Contention Window), for which the
device observes the channel for traffic and if found free the device tries communicating its data.
In case of collision or interference the ACK is not received by the sensor and hence the CW is
doubled so the back off time is doubled. The device would initially transmit a four tone code to
give its identification and waits for the acknowledgement. Out of the 16 available tones, 4 are
reserved for Start, Stop, ACK and one for future up gradation. This leaves 12 unique tones for
other purposes giving a total of 124 = 207366 IDs. After receiving the acknowledgement the
device transmits its data in the form of tones and at the end sends a stop sequence to reset the
central device receiving the data. At present no error checking mechanism has been introduced
to reduce the complexity of the system However, if accuracy in data is desired then any of the
standard error detecting algorithms can be incorporated.

Calculations

Total time used up during generation of tone excluding the switching periods.

Key-in tone duration: 23 msec

Minimum tone duration time: 94 msec

Minimum tone inter digit pause: 96 msec

Total time used up during decoding of the tone:

Maximum Tone Present detection time: 14 msec

Maximum Inter Digit pause: 40 msec

Total time is (SITS) 267 msec.

This gives a maximum data transfer rate of

(4 / (267 x 10-3)) = approx 15 bps*

Hence the above technique is suitable only for sensing and control and not for any data transfer.

*The calculations below do not include the switching speed of the relays
11. Scope for the Future

The system proves to be a major step towards WINS and stepping stone to pervasive computing
however, inherent in the system, are delays due to operation speed of encoder and decoders.
These issues along with the parasitic effects of interconnects can be minimized by developing an
integrated circuit incorporating all the blocks of a sensor node. The range of operation, scalability
and power requirements can be further improved by adopting the multi hop communication
architecture (see Appendix E for details). The current system has only been tested for single hop
communication. The power requirement of the system has to be further scaled down to enable
deeply embedded WINS operating over a long period of time with battery support. If these
devices can be made to operate by scavenging energy from the environment (through photocells)
then they can be exploited on a large scale for monitoring. The development of system on chip
(SOC) is an absolute necessity to make it integrated with the environment. The communication
channel needs to be scrutinized carefully for effects of noise on the transmission. The system at
present posses’ threat due to absence of integrated security measures for data encryption and
authentication. With these enhancements we can exploit the physical limits of these (densely
distributed networks of embedded sensors, controls and processors) for pervasive computing
performance.
12. References

[1] G. Asada, M. Dong, T. S. Lin, F. Newberg, G. Pottie, W. J. Kaiser, H. O. Marcy “Wireless

Integrated Network Sensors: Low Power Systems on a Chip”.

[2] November 6, 2000 issue of Electronic Design magazine.

[3] Lin, T.-H., Sanchez, H., Rofougaran, R., and Kaiser, W. CMOS front-end components for
micropower RF wireless systems. In Proceedings of the 1998 International Symposium on Low-
Power Electronics and Design (Monterey, Calif., Aug. 10–12). IEEE, New York, 1998, 11–15.
Appendix A

Basics of 8051 Microcontroller

Basic Glossary:

Word or Word size: It is smallest group of bits upon which normal arithmetic operations are
carried out(although there are instructions operating on individual bits). Memory units store bits in
groups called words. A word moves in and out of memory as a unit. A memory address is the
location of a word of the memory. Word size is usually a multiple of 8 bits.

Arithmetic and Logic Unit: This unit performs basic arithmetic and logic functions like add,
subtract and AND, OR etc, on operands stored in memory or registers.

Register: A register is a collection of flip-flops, used to store limited amount of data( a flip-flop
stores one bit) such as status information, pointers etc.

Program and Data Memory: Program memory is that part of the memory where code written by
the user is stored. It also stores constants. This memory is usually the ROM and has to be
programmed using special hardware (although it can also be programmed in system). It also
stores a program called the “bootstrap loader”, which gets the microcontroller started when power
is first turned on. Some popular types of ROM are EPROM, EEPROM and more recently Flash.
Data memory is that part of the memory hierarchy which is used to store variables defined by the
user and values generated during program execution. This memory is the RAM.

Program Counter: As mentioned previously the user’s code is stored in the ROM. While executing
the program a special register called the Program Counter keeps track of the next instruction in
the program to be fetched. At the start of a program’s execution the Program Counter stores the
address of the first instruction of the program and as each instruction is executed, it is
incremented. This helps the microcontroller in knowing what location to fetch the next instruction
from. The Program Counter is not always incremented. For example when a “ jump to location A”
kind of instruction is encountered, the Program Counter stores the address of “location A”.

Stack Pointer: In simple words a stack is a method of storing data in a particular manner. The
data element that is first to go into a stack is the last to come out of it. The “top” of the stack is the
only place in a stack where addition or deletion can take place. In most microcontrollers the stack
is stored starting from a special location in the memory. One of the uses of the stack is to store
the contents of the Program Counter when a subroutine is encountered. The Stack Pointer is a
register containing the address of the “top” of the stack.

Addressing Modes: Most of the instructions in a program will mention its operands and their
location i.e. addresses in memory or register space. An address may not always be specified in
absolute terms, i.e. the address may not be the address of the operand. In such cases the mode
of addressing used in the instruction tells the microcontroller how to interpret the address and
calculate the operand’s address. This is done to provide the user flexibility, to shorten the
instruction size( not having to specify the whole address, but only a part of it) etc. For example
the indirect addressing mode is used to specify a memory location where not the operand but its
address is stored.

Interrupts: An interrupt is a way of asking the microcontroller to stop what it is doing and attend to
the source of the interrupt. An example is that of I/O systems in microcontrollers. These I/O
systems issue an interrupt when they receive some data or have completed transmitting some
data. This helps in saving processing time as the microcontroller doesn’t have to keep checking
the I/O systems for an arrival of data or completion of transfer of data. There can be many other
sources of interrupts.

Ports: They are basically gateways through which I/O transfers of a microcontroller take place.
Usually a port has several pins of the microcontroller dedicated to it. In memory terms a port
occupies several bits, usually multiples of 8. There are port registers through which data is
transferred in and out of ports. Ports might be bi-directional or unidirectional.

Oscillator: The microcontroller needs various clocking signals to operate its registers and other
peripherals like the UART. The main clocking signal is provided with the help of an oscillator and
associated circuitry.
Salient features of the 8051

These are some of the main features of the 8051.

· 8 bit word

· 128 byte internal + 128 byte external RAM

· 4Kbyte ROM (Flash)(Program Memory)

· In-built oscillator circuitry

· 4 Ports of 1byte each, bi-directional, bit addressable (each bit of a port can be referred to
and manipulated in addition to being able to refer to the whole port as a unit)

· Two 16-bit Timers/Counters

· 5 interrupt sources

· UART

· Low Power modes

The first step to understanding the 8051’s functioning is to understand its pin diagram. The pin-
out diagram of the 8051 is shown below(PDIP).

How to get the microcontroller ready to run

Text Box: RSTVcc Pin number 40 is used for the supply to the microcontroller. A de-coupling
capacitor is also connected as shown.
Text Box: Pin 40

Text Box: 10 KText Box: C1 = 10 uFText Box: C 1Text Box: +5 V

Figure A1: Pin 40 and Reset Pin (Pin 9)

Reset(RST) This is pin 9, used to reset the device by keeping it high for 2 machine cycles.
The microcontroller should be reset at the time of starting. This is achieved through the following
reset circuitry.

Text Box: XTAL1 Pin 19Text Box: XTAL2 Pin 18Text Box: C 1

C1, C2 = 22pF

Figure A2: Crystal at Pin 18,19

Oscillator Pins XTAL1 and XTAL2 are used for connecting a quartz crystal for the internal
oscillator. The connection diagram is as shown below.

Text Box: Crystal frequency = 11.059 kHzText Box: C 2Text Box: CrystalIf the user wants to drive
the microcontroller from an external clock source, XTAL2 should be left unconnected. XTAL1 has
to be connected to the external clock signal.

The microcontroller is now ready to be programmed and ready to run.

Ports Gateways to the outside world. All the ports are bit-addressable and 8 bits wide. Note that

these ports are stronger sinks for currents than sources.

Port 0 (P0) It is a bi-directional, open drain port. When 1’s are written to its pins they can be
used as high impedance inputs. Since Port 0 has an open drain, when 1’s are written to it , its
outputs float. Therefore external pull-ups are required for the pins of P0. The difference between
an open collector output and one with internal pull-up is shown in the preceding figures. In an
open collector circuit, when the transistor is switched off, the output floats, i.e. the output
becomes indeterminate. In order to avoid this situation, the output is “pulled” up, using an external
pull-up resistor.

· P0 can sink 8 TTL inputs.

· It is also used as an address/data bus during external program and data memory
accesses.

· It plays a part in programming the Flash memory.

Figure A3: Figure Showing difference between P0 and other ports

Port 1 (P1) and Port 2 (P2) differ in some important respects from Port 0. They have internal pull-
ups. As a result they source current when pulled low externally. They can source/sink only 4 TTL
inputs. Port 1 & 2 are bi-directional, open drain ports. When 1’s are written to its pins they can be
used as high impedance inputs.

Port 3 (P3) too has internal pull-ups. It can sink /source 4 TTL inputs. It has some special
functions, which can be looked up in the and also the pin-out diagram.

Figure A4: 8051 Pinout

Getting The Microcontroller to work

Step 1 Write the code/program: The code instructing the microcontroller to carry out various
operations can either be written in assembly language or C. Assembly language is a level lower
than C, meaning that we can deal with registers, insert accurate time delays etc. When a C
program is compiled, each instruction is converted to its assembly language equivalent. But C is
much more convenient to use, mainly because of the lesser amount code that needs to be
written. The job accomplished by a single C statement may take multiple lines of assembly code.
Each microcontroller or a particular series has its own assembly level instruction set. On the other
hand a C code remains basically the same across the whole range of microcontrollers, only,
different C compilers are required. We will be using a C compiler called SDCC( Small Devices C
Compiler) for Linux. As we will get to know, we can use a lot of names used in the manual as it is
while writing code in SDCC. For example P0 for port 0, P1_3 for the third pin of port 1 and so on.
This code is also known as firmware.

Step 2 Compile and link the program to get its “ihx” (Hex) file. Its nothing but the machine level
equivalent of our code in hexadecimal format, i.e. in bytes.

Step 3 Burn the code into the microcontroller’s Flash memory. This is done through a special
device called a Programmer. This downloads the .ihx file into the microcontroller’s Flash.

To run the microcontroller the supply, reset and crystal circuits are connected. Verification of its
working could be through the oscilloscope or maybe some LED’s.

*Programmer for programming the 8051 chip used has also been developed. Details of which are
given in Appendix D.

Appendix B

Small Devices C Compiler (SDCC)

What is SDCC?

SDCC stands for Small Devices C Compiler & as the name itself speaks out, it’s a C compiler
used for small devices such as 8 bit microprocessors. SDCC is a freeware, re-targetable,
optimizing ANSI-C compiler developed by Sandeep Dutta. It can be used for Intel MCS51 based
Microprocessors (8051, 8052, 8055, etc.), Zilog Z80 based MCUs and the Dallas DS80C390
variant. It can be re-targeted for other microprocessors as well, although support for PIC, AVR
and 186 is currently not available. The entire source code for the compiler is distributed under
GPL. SDCC uses ASXXXX & ASLINK, a Freeware, re-targetable assembler & linker. SDCC has
extensive language extensions suitable for utilizing various microcontrollers and underlying
hardware effectively.

Although, SDCC has been designed for the Linux environment, but by using any pre-compiled
binary package such as CygWin, it can be employed in Windows environment as well. SDCC is a
highly valuable tool for developing microcontroller-based designs & applications & is the primary
cause for C language replacing Assembly very fastly, as the preferred programming platform.

But why SDCC, why not GCC or any other compiler ?

It’s very simple. Unlike other compilers like GCC, Borland, etc., which compile & link C programs
to generate executable files to be run on PC platform, SDCC has been designed to compile & link
C programs into assembly files & to further generate binary files in Intel Hex Format (*.ihx), which
can be directly ‘burned’ onto the program memory of a microcontroller to make it carry out
whatever operations the program asks it to do. In this way, the major difference between SDCC &
other C compiler may be specified as :

· SDCC generates files of ASM (assembly) & IHX format, rather than EXE or OUT format.

· SDCC can carry out microprocessor specific optimizations by itself, such as allocate
registers for the various variables used in the program.

· It doesn’t support variables of double data type but allows usage of bit data type variables.

Barring these basic differences, the C platform used in SDCC is largely same as the platform to
which you must have got used to. And it is because of this, that SDCC becomes such an
indispensable tool towards developing Microcontroller based applications.

Features of SDCC

* Global sub expression elimination.

* Loop optimizations (loop invariant, strength reduction of induction variables and loop
reversing).
* Constant folding & propagation.
* Dead code elimination.
* Jump tables for switch statements.
* A peep hole optimizer using an MCU independent rule based substitution mechanism.
* Supported data-types are char (8b), short and int (16b), long (32b) & float (32b IEEE).
* Allows inline assembler code to be embedded anywhere in a function & calling of routines
developed in assembly.
 * Allows –cyclomatic option to report the relative complexity of a function.
* Has companion source level debugger SDCDB, which uses ucSim for the simulation for 8051
and other micro-controllers.

Besides this, all the packages used in the compiler system are opensource and freeware, so that
not only does it cost nothing, but also allows you to modify the package as per your requirements.
SDCC consists of the following components :

* SDCC - C compiler
* SDCPP - C preprocessor
* ASX8051 - Assembler for 8051 type processors
* ASLINK -Linker for 8051 type processors
* s51 - ucSim 8051 Simulator
* SDCDB - Source Debugger
* PACKIHX - A tool to pack Intel hex files
* Include files
* Sources of the runtime library
* Documentation

Drawbacks in SDCC

Despite all of its advantages, SDCC has still various loopholes left in it. Some of these stem from
the various optimizations that SDCC carries out at the time of compiling, such as unwanted
allocations of data registers to temporary variables which necessitates declaring variables as
volatile in programs using interrupt facilities.

Besides this, there are some desirable features that are currently unavailable in SDCC :

(a) Ability to use header files not present in the current directory by specifying the base
name or a directory:

sdcc -c –model-<pathname> -o <pathname> _atoi.c

(b) Ability of specifying the starting memory location for subroutines :

char KernelFunction3(char p) at 0x340;

Files Created By SDCC

SDCC creates a number of files for the purpose of compiling & linking. Assuming that the C
program was created with the name of myprog.c, which uses function defined in myprog.h, then
SDCC will further create the following files :

· myprog.asm - Assembler source file created by the compiler.

· myprog.lst - Assembler listing file created by the Assembler.

· myprog.rst - Assembler listing file updated with linkedit information, created by linkage
editor.

· myprog.sym - Symbol listing for the sourcefile, created by the assembler.

· myprog.rel - Object file created by the assembler, input to Linkage editor.

· myprog.map - The memory map for the load module, created by the Linker.

· myprog.ihx - The load module in Intel hex format (you can select the Motorola S19 format
with –out-fmt-s19).

· myprog.lnk – Linker file linking files, libraries & REL files used.

· myprog.cdb - An optional file (with --debug option) containing debug information, to be

required by SDCDB.

Stages of Compilation

Compilation of your SDCC file actually takes place in three stages as shown below :

Assembler Stage: The source code written in C is converted into assembly, by the assembler.
The compilation can be stopped at this stage, by giving –c option during compilation

sdcc –c myprog.c This command instructs the SDCC to only compile the source code & not
link it. As a result, only assembler files are created.

Linker Stage: The linker now links all the required files (header files, libraries, etc.), so that SDCC
has all the necessary info required to generate the hex file. During this stage, some of the files
created during the compilation stage, are also updated, for ex. RST file is nothing but just an
updated version of the LST file.

Porting Stage: Finally, it’s in this stage that the IHX & the MAP files are generated. This particular
stage is specific for each & every processor, since this stage involves the conversion of the
assembly files into binary files, to be later loaded onto the microprocessor program memory. The
conversion depends upon the binary op-codes chosen for the instruction set for any given
microprocessor.

Using SDCC for larger projects

SDCC can be used for both simple as well as complex projects. Projects having only one source
file can be simply compiled & linked by issuing the following command from within a UNIX shell
sdcc myprog.c but in case of projects containing multiple source files, a different procedure has
to be adopted, since SDCC can compile only one file at any given time.
In case of multiple source files, firstly the C files NOT having the main function, are compiled with
a –c option so that SDCC doesn’t try to link them. Then, to compile the source file containing the
main function, the command used is

sdcc myprog.c abc.rel ghi.rel

where myprog.c contains the main function & calls functions defined in abc.c & ghi.c. For the
subsequent compilations, you may use the following sequence :

sdcc –c myprog.c sdcc myprog.rel abc.rel ghi.rel

In cases where you may want to use a compiled library file , the alternative procedure is
explained with the help of an example where there exist source code files (*.c) & header files (*.h)
in the folders add, main, xyz of the same name as that of the folders in which they exist. Only the
main.c file in the main folder has a main function in it while the remaining folders contain only
certain functions which are being called by the main.c. Besides this, there exists one more folder
by the name library, which is currently empty. All these folders are presumed to exist in the
project folder. First of all we need to compile the *.c files in the folders add & xyz but since these
don’t have a main function in them, they can’t be linked. Also to facilitate debugging using
SDCDB in the end, the commands used would be :

(a) cd add Move to add folder

(b) sdcc –c --debug add.c Only compile add.c

(c) cd ../xyz Move to xyz folder

(d) sdcc –c --debug xyz.c Only compile xyz.c

(e) cd ../main Move to main folder

(f) sdcc –c --debug main.c –I ../add –I ../xyz Only compile main.c by including the
files in the add & xyz folder

(g) cd ../library Move to library folder

(h) cp ../add/* ./ Copy all the file from add,

(i) cp ../xyz/* ./ xyz &

(j) cp ../main/* ./ main folder to the library folder

(k) sdcc --debug main.c mylib.lib –L ./ ./ Link main.c using the library file given

Here the lib file used in step (k) contains the name of all the folders used (add, main & xyz) on
separate lines & the pathname of the lib file is given after the –L option. At the end of this
procedure, the required IHX & MAP files would be generated in the library folder.

To simplify the whole task, all the above commands can be written down in a shell executable
script file & the name of this file can be given at the command window, whenever the compilation
process has to be carried out.

Sample Program (Square Wave Generation)

/* The following sample program generates a square wave at Port 1, Pin 0.

It uses one volatile variable of type bit to generate the 1’s & 0’s. */

# include <8051.h> // include header file for 8051 series

bit pinLevel=1; // bit variable declaration

void main() // main function starts

while(1) // infinite loop

P1_0=pinLevel; // assign port 1, pin 0 value of the bit

pinLevel=~pinLevel; // toggle the value of the bit

} // end of main function

// End Of Program !

Appendix C
Serial Communication using AT89C51

Serial Communication simply means communicating by transmitting data bits serially (may be by
using the serial ports). This means that instead of sending the whole data chunk simultaneously
through parallel transfer, the data bits are transmitted sequentially one by one. This mode of
communication can be used to send a signal from a microcontrolled circuit to a PC through its
serial port (using RS 232).

Why at all Serial Communication ?

Although the serial mode of communication is the slower mode, it can be used for comparatively
longer distances (parallel data transfers are effectively restricted to 1m at most) & its
implementation requires less H/W & thus is much simpler. As a result, serial communication is
quite popular for devices such as mouse, modem & various other small devices (generally
microcontrolled type of circuits).

Tools required for Serial Communication

Except for a chip-to-chip communication, as in the case of interconnection of any two

microcontrollers, in all other cases, some additional tools are required to achieve serial
communication. They may be broadly classified as:

Hardware

Serial Port Connector (9 or 25 pins) To serially communicate with any device through its serial
port, first of all you would require a serial port connector which would fit into the serial port
provided in the device (PC or printer or just another microcontroller). All the standardized serial
connectors come with nine or 25 pins such as the PC 9, PC 25, Printer (Serial) Connector, Amiga
1000, MSX, etc. Out of these ONLY TWO pins (RX & TX) are used for data transfer, while rest all
are used for the generation of control signals, such as Carrier Detect, Line Busy, Line Ring, etc.

Serial Cable A serial cable allows you to extend the region in which you can place your circuit,
away from the device to which its serially connected. A serial cable for most of the connectors
contains only five separate cables with two meant for the two data pins while the rest going into
the control pins.
MAX 232 In case of a microcontroller-to-PC communication, since, the data being sent by
the microcontrolled circuit is not always (in fact, never is) compatible with the serial port standards
& employs different voltage levels, a separate circuit is required to carry out this transition in the
voltage levels & to convert the incoming signal into TTL so as to be easily accepted by PC & vice
versa. Such a circuit has been integrated into a chip called MAX 232, named so because it’s
compatible to the RS 232 standard for PC based serial communication.

Figure C1: Schematic for TTL to RS232 interconnection

The above figure shows how the MAX232 is used to interface TTL (microcontroller) and RS232
lines (serial port). This particular scheme draws power from the serial port, for MAX232, and uses
a voltage regulator to convert RS232 levels to TTL levels. A word of caution – the serial port may
not be able to supply the required current to drive the voltage regulator. Using the USB port to
supply power to MAX232 can solve this problem. USB levels are compatible with TTL levels and
hence no voltage regulation is required, i.e. the 7805 can be removed from the circuit and the
USB port can be used to directly supply power to MAX232.

Software for Serial Communication on the PC side

RTProggy (Windows based) - Developed by us using MS Visual Basic 6.0. It uses the MSComm
component to achieve communication with the serial port. The only special system requirements
are VB6 runtime files (& in some case a downloadable patch VB6CLI.EXE to solve a licensing
bug).

Relevant Pins and Registers on the AT89C51

Serial I/O Port In 8051 series, the Pins 0 & 1 of Port 3 serve the extra function of the serial I/O
ports. While Pin 0 (RXD) is meant for serial input, Pin 1 (TXD) is meant for serial output. It is
through these pins that data will be transferred serially between any two serially connected
systems. Both pins will always carry information in one fixed & opposite directions.

Serial Data Buffer (SBUF) To facilitate serial communication in 8051 series, a serial buffer
register SBUF is provided. Actually SBUF consists of two separate buffers being referred by the
same name. When any data is moved to SBUF, it goes to the transmit buffer where it is held for
serial transmission. In fact, moving a byte to SBUF is what initiates the transmission. And when
the data is moved from SBUF, it comes from the receive buffer which contains the data received
serially.
Control Registers The two control registers used in serial communication are

* Serial Control Register (SCON) It holds the various settings for the serial
communication & interrupts. This register is bit addressable. The 4 bits in the SCON that are
commonly used are SM0, SM1 & SM2 which specify the serial port mode (8/9 bit shift
register/UART) & RI & TI which are the flags set by H/W to indicate a serial interrupt.

* Power Control Register (PCON) This register is mostly used for configuring power
settings, but the MSB of PCON, SMOD enables/disables for double baud rate. This bit has to be
set/cleared as per the baud rate requirements of your program & the circuit.

Timer Registers To further select a baud rate of the required specification, timers are also
required to be configured. As a result, you will have to use TMOD & TCON registers as well.

Interrupt Register To enable the serial interrupt enable bits ES (serial interrupt enable) & EA
(global interrupt enable) need to be set.

Serial Interrupt A serial interrupt may occurs on two occasions:

* On the completion of the transmission of the byte currently stored in SBUF. This interrupt is
indicated by setting the TI flag in SCON by the H/W. TI must be cleared by S/W (the user has to
include such an instruction in his program).
* On having received one complete data byte from the serially connected system into the
SBUF. Indicated by the setting of RI flag in SCON by the H/W. RI must be cleared by S/W.

Both these interrupts must be handled in the interrupt handler routine in your code for a bi-
directional i.e. two ways communication.

Sample Program

#include <8051.h> // include 8051 header file

void serial_handler() interrupt 4 // serial interrupt handler

TH1=0xFD; // Sets Baud Rate = 19,200bps for 11.0952 MHz clock

if(RI) // receive code

{
 P1=SBUF; // read SBUF into Port 1

SBUF=P1+8; // send new value to SBUF

RI=0; // clear RI flag

msec_delay(500); // wait 500 ms

if(TI) // transmit code

TI=0; // clear TI flag

void main()

TMOD=0x21; // 16 bit timer mode

PCON=PCON | 0x80; // SMOD=1 for double baud rate

// select Mode 1 (8 bit UART) of variable baud rate

SM0=0;

SM1=1;

SM2=0; // single processor communication

REN=1; // enable reception

ES=1; // enable serial interrupt

EA=1; // enable serial interrupt

TH1=0xFD; // Baud Rate = 19,200 for 11.0952 MHz

TR1=1; // start timer 1

// this line to be present only in the transmitter module

 SBUF=0xA6; // send some initial data

while(1); // loop infinitely waiting only for serial interrupts

//End Of Program !
Appendix D

8051 Serial Programmer

Programmer

It consists of 2 parts:

* Software
* Hardware

Hardware contains a master microcontroller and a MAX232 circuit mainly. This circuit helps in
transferring the machine code coming from the computer’s serial port into the program memory of
the target MCU.

Figure D1: Schematic Diagram for Proggy.

Software is the GUI of the programmer on the computer side, this software loads the HEX file and
transfers it to the MCU serially.

It auto detects serial port settings.

Figure D2: Auto detect mode

Figure D3: Manual Settings

Other Features of Programmer Software:

Figure D4: Features (Delete, Program, Verify, Lock)

Delete – Deletes the Flash Memory of the target MCU

Program – Programs the target MCU

Verify – Verifies if the code has been transferred properly

Lock – Locks the target MCU

The complete executable of Proggy is given in the accompanying CD.

Appendix E

Use of Multi hop Design

The WINS architecture can exploit the small separation between WINS nodes to provide multihop
communication. Multihop communication (see Figure E1) yields large power and scalability
advantages for WINS networks. First, RF communication path loss has been a primary limitation
for wireless networking, with received power, decaying as transmission range, R, as PREC a R-b
(where b varies from 3 – 5 in typical indoor and outdoor environments). However, in a dense
WINS network, multihop architectures may permit N communication link hops between N+1
nodes. In the limit where communication system power dissipation (receiver and transceiver
power) exceeds that of other systems within the WINS node, the introduction of N co-linear equal
range hops between any node pair reduces power by a factor of Nb-1 in comparison to a single
hop system. Multihop communication, therefore, provides an immediate advance in capability for
the WINS narrow bandwidth devices. Clearly, multihop communication raises system complexity.
However, WINS multihop communication networks permit large power reduction and the
implementation of dense node distribution. Also it increases the range of the system by putting
the sensors collinearly in a row.

Figure E1: WINS nodes (shown as disks) are distributed at high density in an environment to be

monitored. Multihop communication permits low power operation of dense WINS sensor
networks. WINS node data is transferred over the asymmetric wireless link to an end user or to a

conventional wireline or wireless (IP) network service through a WINS network bridge.

NOTES