DESIGN AND DEVELOPMENT OF

WIRELESS SENSOR NETWORK

A Major Project
Submitted in Partial Fulfillment of the Requirements
For the Degree of

Bachelor OF TECHNOLOGY
IN
ELECTRONICS & COMMUNICATION
ENGINEERING
By
Rupam Patel and Akash Patel
[06BEC109] [06BEC063]

Under the Guidance of

Prof. Mehul R. Naik

Department of Electrical Engineering

Electronics & Communication Engineering Program
Institute of Technology, NIRMA UNIVERSITY
AHMEDABAD 382 481
May 2010
 Institute of Technology
Department of Electrical Engineering
Electronics and Communication Branch

CERTIFICATE

This is to certify that the Major Project Report entitled “Wireless Sensor
Network” submitted by Rupam Patel (Roll No. 06BEC109) & Akash Patel
(Roll No. 06BEC063) as the partial fulfillment of the requirements for the
award of the degree of Bachelor of Technology in Electronics &
Communication Engineering, Institute of Technology, Nirma University is the
record of work carried out by them under my supervision and guidance. The
work submitted in our opinion has reached a level required for being accepted
for the examination.

Date:

Prof. Mehul R. Naik Prof. A. S. Ranade

(Project Guide) Head of Department
Assistant Professor Electrical Engineering
Electronics and Communication Institute of Technology
Institute of Technology Nirma University
Nirma University

II
 ACKNOWLEDGEMENTS
We thank the Electronics and Communication Department, Institute of Technology, Nirma
University for giving us an opportunity to carry out this project work.

Apart from our efforts, the success of this project depends largely on the encouragement and
guidance of several other important individuals. We take this opportunity to express my
gratitude towards these people who have been instrumental in the successful completion of
this project.

We would like to convey our heart-felt gratitude to our project guide, Prof. Mehul R. Naik.
Sir, we thank you for allowing us to work on this project under your guidance. Your valuable
time, your technical expertise and most importantly, constant encouragement and motivation
in all the stages of the project was something for which we cannot thank you enough.

Our sincere thanks are also to Prof. A. S. Ranade, Head of the Department of EC
Engineering, Institute Of Technology, Nirma University, Ahmedabad for his co-operation
and motivation during our study.

We are highly indebted to God and to our family members by whose blessings, we are able to
complete our report. And also very thankful to all our friends for their help at all different
stages and whom we shared very intimate relationship.

THANK YOU.

III
 ABSTRACT

Networks of wireless sensor devices are being deployed to collectively monitor and
disseminate information about a variety of phenomena of interest. Wireless networks have
changed the way we look at computing. Unlike the concept of reactive computing, these
networks usher in proactive computing by using intelligent sensors called ‘motes’ or ‘nodes’.
Unlike standard networking gear, wireless sensors can reorganize themselves to form a
network and convey meaningful data. These motes have the capability to reorganize
themselves into a network and transmit data that can range from measuring light,
temperature, humidity or even motion. Communication of signals is carried out using radio
frequency (RF) waves. The main advantages of wireless systems over wired systems is the
considerable reduction in the cost and power consumption. One can envisage a future where
we would be living in a world surrounded by embedded computers that anticipate human
need and act proactively.

Wireless Sensor Network is a subject still under research across all over the world. Now-a-
days there has been advancements in this field with smaller size and portability. We have
attempted to use the newly derived ZigBee protocol for the development of our project.
ZigBee provides low power wireless support with reasonable range of around 400 m. The
main part of the project is the base station which is equipped with the USB support for
communication with PC to access the data sent or received by the ZigBee module. The end
device is also equipped with same ZigBee module to accommodate the data transfer. The
form of data communicating between the devices is Analog as well as Digital. The power
consumption in the ZigBee module is so less that the device can run for months without
changing the batteries. This makes the application more versatile to use in harsh conditions
and in rural places. The PCBs are made with utmost accuracy and optimization of the
component placing. Due to the complexity of the circuits, the PCBs are made in industries
with PTH (Plated Through Hole) technology and SMD (Surface Mounting Device)
components, which ensure the reliability and optimization.

The main purpose of the project is the optimization of power as well as design parameters

IV
Contents
LIST OF FIGURES .............................................................................................................. III
LIST OF TABLES ................................................................................................................ IV

1 INTRODUCTION ............................................................................................................. 2
1.1 OVERVIEW OF WIRELESS SENSOR NETWORKS .............................................................. 3
1.2 MODELLING OF WIRELESS SENSOR NETWORKS ............................................................ 4
1.3 CHALLENGES ................................................................................................................. 6
1.4 OBJECTIVE OF THE PROJECT .......................................................................................... 7
2 PRIOR STUDIES .............................................................................................................. 9
2.1 CROSS-BOW SENSOR NETWORK KIT ............................................................................. 10
2.1.1 Robust Mesh Network .......................................................................................... 11
2.2 ARDUINO [5] ................................................................................................................. 11
2.2.1 Features ............................................................................................................... 12
2.2.2 Software ............................................................................................................... 12
2.2.3 Overview of the hardware used for study ............................................................ 13
2.2.4 Bootloader [6] ....................................................................................................... 14
3 HARDWARE DESCRIPTION ...................................................................................... 15
3.1 HARDWARE REQUIREMENTS ....................................................................................... 17
3.2 BLOCK DIAGRAM ........................................................................................................ 17
3.2.1 Base Station ......................................................................................................... 17
3.2.2 Remote Sensor Node ............................................................................................ 18
3.3 HARDWARE COMPONENTS .......................................................................................... 20
3.3.1 XBee RF Module [7].............................................................................................. 20
3.3.2 Atmega168 Microcontroller [8] ............................................................................ 25
3.3.3 FT232R USB - UART Bridge Converter IC [9] .................................................... 27
3.4 MISCELLANEOUS HARDWARE PARTS: ......................................................................... 29
3.5 PROTOCOLS ................................................................................................................. 29
3.5.1 ZigBee (IEEE 802.15.4) ....................................................................................... 29
3.5.2 USB [13] Protocol ................................................................................................. 32
4 PRINTED CIRCUIT BOARD DESIGN ....................................................................... 33
4.1 INTRODUCTION TO PCB DESIGN USING EAGLE 5.7.0 ................................................... 34
4.2 FEATURES OF EAGLE 5.7.0 .......................................................................................... 34
4.3 INITIAL DESIGN OF WIRELESS NODE ........................................................................... 35
4.4 GENERATING GERBER FILES........................................................................................ 37
5 COMMUNICATION INTERFACE ............................................................................. 38
5.1 SERIAL COMMUNICATION AND USB INTERFACE USING FT232R ................................ 39
5.2 CONFIGURING FT232R ................................................................................................ 41
5.2.1 Driver Installation ............................................................................................... 41
5.2.2 FTDI Configuration ............................................................................................. 44
5.3 WIRELESS COMMUNICATION USING IEEE 802.15.4 XBEE MODULE ........................... 45
5.3.1 Configuring XBEE ............................................................................................... 45
5.4 UNIVERSAL ASYNCHRONOUS RECEIVER TRANSMITTER (UART) INTERFACE ............. 47
5.4.1 Transmitting and receiving serial data ................................................................ 48

V
 5.4.2 Asynchronous receiving and transmitting ........................................................... 49
6 SOFTWARE INTERFACE ........................................................................................... 52
6.1 COMPILER AND SIMULATION SOFTWARE ..................................................................... 53
6.1.1 NetBeans IDE 6.8: [10] ......................................................................................... 53
6.2 INTERFACING HARDWARE VIA NETBEANS .................................................................. 55
7 APPLICATIONS............................................................................................................. 58
7.1 APPLICATIONS ............................................................................................................. 59
8 RESULTS AND CONCLUSION ................................................................................... 63

REFERENCES....................................................................................................................... 63
APPENDIX A ......................................................................................................................... 67
APPENDIX B ....................................................................................................................... 630
APPENDIX C ......................................................................................................................... 75
APPENDIX D ......................................................................................................................... 76
APPENDIX E ......................................................................................................................... 77

LIST OF FIGURES

VI
FIGURE 1-1 MODEL FOR DEPLOYMENT OF SENSORS IN A WIRELESS SENSOR NETWORK ............ 5
FIGURE 3-1 WIRELESS SENSOR NODE COMPONENT LAYOUT .................................................. 16
FIGURE 3-2 BLOCK DIAGRAM FOR BASE STATION................................................................... 18
FIGURE 3-3 BLOCK DIAGRAM OF AD HOC WIRELESS SENSOR NODE ........................................ 19
FIGURE 3-4 XBEE MODULE .................................................................................................... 20
FIGURE 3-5 ATMEGA168 ARCHITECTURE ................................................................................ 25
FIGURE 3-6 DIAGRAM OF FT232R IC ...................................................................................... 27
FIGURE 3-7 PROTOCOL STACK OF ZIGBEE ............................................................................... 30
FIGURE 4-1 INITIAL DESIGN OF NODE....................................................................................... 35
FIGURE 4-2 INITIAL DESIGN-2 .................................................................................................. 35
FIGURE 4-3 DESIGN AFTER ROUTING SIGNALS .......................................................................... 35
FIGURE 4-4 NEW CIRCULAR DESIGN ......................................................................................... 35
FIGURE 4-5 AFTER ROUTING SIGNALS ...................................................................................... 36
FIGURE 4-6 FINAL OPTIMIZED LAYOUT DSIGN ......................................................................... 36
FIGURE 4-7 GENERATING GERBER FILES USING CAM PROCESSOR IN EAGLE 5.7.0 .................. 37
FIGURE 5-1 BASIC CONNECTIONS OF FTDI TO CONTROLLER ................................................... 39
FIGURE 5-2 POP-UP WINDOW IN WINDOWS .............................................................................. 42
FIGURE 5-3 INSTALLING FTDI DRIVERS ................................................................................... 42
FIGURE 5-4 DRIVER INSTALLATION FINISHED, NEW VIRTUAL COM PORT CREATED ................ 43
FIGURE 5-5 DEVICE MANAGER ................................................................................................. 43
FIGURE 5-6 CONFIGURING FT232R USING FT PROG SOFTWARE ............................................. 44
FIGURE 5-7 IEEE 802.15.4 XBEE 1MW WIRE ANTENNA IC .................................................... 45
FIGURE 5-8 GUI OF X-CTU APPLICATION ............................................................................... 46
FIGURE 5-9 MODEM CONFIGURATION USING X-CTU APPLICATION......................................... 46
FIGURE 6-1 WSN 1.0 GUI FOR ACCESSING HARDWARE .......................................................... 56
FIGURE 6-2 FLAG (~~~~~) IS USED FOR ERROR FREE TRANSMISSION OF THE FILE .................... 56
FIGURE 6-3 FILE SELECTION ..................................................................................................... 57
FIGURE 6-4 TRANSMITTING DATA ............................................................................................ 57
FIGURE 7-1 CONTEXT AWARE HOME ....................................................................................... 62
FIGURE 8-1 TOP COPPER LAYER COMPONENT SIDE ................................................................... 67
FIGURE 8-2 BOTTOM COPPER LAYER SOLDER SIDE ................................................................... 67
FIGURE 8-3 TOP LAYER SILK SCREEN ....................................................................................... 68
FIGURE 8-4 TOP LAYER MASK .................................................................................................. 68
FIGURE 8-5 BOTTOM LAYER MASK ........................................................................................... 68
FIGURE 8-6 DRILL DATA… ...................................................................................................... 68
FIGURE 8-7 TEST PCB ............................................................................................................. 69

VII
 LIST OF TABLES

TABLE 1 SUMMARY OF ARDUINO HARDWARE .......................................................................... 13

TABLE 2 OBSERVATION OF CURRENT CONSUMPTION ............................................................... 64
1 INTRODUCTION

2
1.1 Overview of Wireless Sensor Networks

Sensor networks are becoming more and more popular as cost of sensor gets cheaper and
cheaper. The sensor network is a wireless network formed by a group of sensors deployed in
same region, which can be used to measure air pressure, temperature, acceleration, etc.
Sensors transmit signals via radio signal. Since sensors are now small and cheap, they can be
deployed on a large scale. They become more and more important for applications like
security, traffic monitoring, agriculture, battlefield, etc. Most of those sensors are powered by
batteries. The lifespan of an energy-constrained sensor is determined by how fast the sensor
consumes energy. Sensors use energy to run circuitry and send radio signals. The later is
usually a function of distance and takes a large portion of the energy. Researchers are now
developing new routing mechanisms for sensor networks to save energy and prolong the
sensor lifespan. Four primary routing mechanisms are direct transmission, minimum energy
transmission, static clustering, and dynamic clustering. Sensor lifespan is an important
performance index for comparison of different routing mechanisms. So far, the comparison
between routing mechanisms is based on simulation results. Very few analytical results are
available.

A wireless sensor device is a battery-operated device, capable of sensing physical quantities.

In addition to sensing, it is capable of wireless communication, data storage, and a limited
amount of computation and signal processing. Advances in integrated circuit design are
continually shrinking the size, weight and cost of sensor devices, while simultaneously
improving their resolution and accuracy. At the same time, modern wireless networking
technologies enable the coordination and networking of a large number of such devices. A
Wireless Sensor Network (WSN) consists of a large number of wireless sensor devices
[1]
working collaboratively to achieve a common objective. A WSN has one or more sinks (or
Base Stations) which collect data from all sensor devices. These sinks are the interface
through which the WSN interacts with the outside world. The basic premise of a WSN is to
perform networked sensing using a large number of relatively unsophisticated sensors,
instead of the conventional approach of deploying a few expensive and sophisticated sensing
modules. The potential advantage of networked sensing over the conventional approach can
be summarized as greater coverage, accuracy and reliability at a possibly lower cost. The
range of potential applications that WSNs are envisaged to support, is tremendous,

3
encompassing military, civilian, environmental and commercial areas. Some examples
include networked sensors for military surveillance, smart sensors to monitor and control
manufacturing facilities, biosensors for health applications, sensor networks to monitor
habitat or weather, and smart sensor environments for home electronics. Designing,
manufacturing and networking wireless sensor devices to support such a wide variety of
applications are a complex and challenging endeavour. As a result, there has been a lot of
research activity in the area of WSNs over the past five years or so.

WSNs can also facilitate controlling of physical environments from remote locations with
better accuracy. Sensor nodes have various energy and computational constraints because of
their inexpensive nature and ad-hoc method of deployment. Considerable research has been
focused at overcoming these deficiencies through more energy efficient routing, localization
algorithms and system design.

Research in the area of WSNs has been active at several levels, starting from the component
level, the system level, and all the way up to the application level. The component level
research focuses on improving the sensing, communication and computation capabilities of
an individual sensor device. Research at the system level is concerned with the mechanism of
networking and coordinating several sensor devices in an energy-efficient and scalable
fashion. Research at the application level is concerned with the processing of the data
produced by sensors, depending on the application objectives. Examples of such problems
include localization of a target being tracked by using measurements from several sensors,
computing the spatial profile of a signal of interest using all the sensor readings, and so on.

1.2 Modelling of Wireless Sensor Networks

• The most generic model for a WSN is based on the data gathering and communication
capabilities of sensors. If each sensor has a unique address, then some available
layered models such as OS can be used, with some modifications, to model the WSN.
However, uniqueness of addresses may not be feasible or even required. In that case,
a model can be developed based on the following assumptions:
• Initially, all the sensors have identical capabilities.
• The sensors are anonymous: they lack unique identifier (e.g. addresses).

4
 • Several sensors can create a region (group): anonymity of a sensor in a sensor
network dictates the creation of regions.
• Each sensor belongs to exactly one region: the identity of this region is the only
identifier available to the sensor.
• A region has an address (coordinates) that uniquely identifies the region; no two
regions can have the same address.
• Communication among regions is based on addresses.
• Sensor synchronization is short-lived and group-based, where a group is loosely
defined as the collection of sensors that collaborate to achieve a given task.

[2]
A five layer WSN model is proposed based on these assumptions. The figure below shows
a generic WSN deployment and how individual layers of the model map to the underlying
WSN components.

Figure 1-1 Model for deployment of sensors in a Wireless Sensor Network

The sensors are deployed uniformly at random over the area of interest; once deployed, they
self-organize into a network that is expected to work unattended. The network is divided into
addressable regions. Each region contains a set of sensor nodes. An example of such an

5
organization can be provided using a base station (sink) that serves as a center of a polar
coordinate system. The distance between a sensor and the sink is determined based on the
(quantified) base-station signal level, as measured by the sensor node. The (quantified) angle
between a sensor and the sink (relative to a reference direction) is determined by directional
transmission from the sink. As a result, the area covered with sensors is divided into regions.
Each region is uniquely identified by its distance from the sink (an integer) and its angle (an
integer). All sensors within the region have the same values for distance and angle. The
mission determines the overall functioning of the WSN. It describes a high-level goal of the
WSN, i.e. what data is of interest and what types of services are needed. A set of services is
provided in support of a given mission. A service includes data collection and processing
from large areas of the WSN. Since individual sensors are identified only by their region,
service-related activities within a region are considered to be atomic. The service can be
decomposed into a set of services, each limited to a single region and involving all the active
sensors in the region. The sender, requesting such service, may be in the same region or
outside the region. Requesting, performing and replying to the service necessitate
communication among sensors. Each sensor has a set of sensory/control capabilities,
described by attributes with a specified range of values and a specified resolution.
Importantly, a given mission only requires a subset of capabilities, referred to as the sensor
configuration. Thus, the configuration of individual sensors is determined by the mission of
the WSN. A change in the mission often requires a change in the sensor configuration.

1.3 Challenges

Previously, sensor networks consisted of small number of sensor nodes that were wired to a
central processing station. However, nowadays, the focus is more on wireless, distributed,
sensing nodes. But, why distributed, wireless sensing? When the exact location of a particular
phenomenon is unknown, distributed sensing allows for closer placement to the phenomenon
than a single sensor would permit. Also, in many cases, multiple sensor nodes are required to
overcome environmental obstacles like obstructions, line of sight constraints etc. In most
cases, the environment to be monitored does not have an existing infrastructure for either
energy or communication. It becomes imperative for sensor nodes to survive on small, finite
sources of energy and communicate through a wireless communication channel.
The information gathering capabilities of distributed sensor networks are poised to
revolutionize the way the information infrastructure interacts with our physical environment.

6
Projecting IC cost curves into the future leads us to conclude that wireless sensing systems on
a chip will soon become so low-cost that that wireless capabilities will be built into
everything, from your home garden to stuffed animals to library books.

If wireless sensors are to become pervasive in businesses and homes, researchers must
provide inexpensive ICs. Due to the large densities of nodes, networks must be zero-
configuration, and zero-maintenance. In addition, the very long life required for autonomous
operation dictates that these devices must be extremely energy efficient for their energy
sources to last for the full life of the product to which they are attached.
In the majority of applications, locating sensors is also critical. An alarm from a sensor may
be meaningless unless the source is identified and located. If devices are to be dropped into
place or moved periodically users should not be required to input each device ID and its
coordinates, nor should the user interface identify devices by number. In fact, a device's
location can become its ID. Location of a device will be relative to its neighbours, which it
will cooperatively calculate based on peer-to-peer range measurements. Furthermore, sensor
data fusion and processing algorithms will reduce and make decisions based on the relative
location of input data.

Another requirement for sensor networks would be distributed processing capability. This is
necessary since communication is a major consumer of energy. A centralized system would
mean that some of the sensors would need to communicate over long distances that lead to
even more energy depletion. Hence, it would be a good idea to process locally as much
information as possible in order to minimize the total amount of information to be
transmitted.

1.4 Objective of the Project

The scope of the project involves the design and fabrication of a Base Station board and a
Remote Sensor Node board. The key objective is to establish a wireless link between the
Base Station and the Remote Sensor Node. Over the wireless link data from the sensors
housed on the Remote Sensor Node is to be transmitted to the Base Station. Received data at
the Base Station must then be processed and displayed the computer terminal. The computer
terminal is equipped with the software designed exclusively for the project using c#. c# is the
programming language from the package Visual Studio, it works in very similar way as of

7
usual c or c++. For the interfacing of the device with PC terminal, we have used USB ports,
which is a revolutionary step towards data communication with Atmel Microcontrollers
especially without USB interfacing facilities. There may be one or more different sensors for
various measureable physical quantities. Under this project, temperature sensing is the prime
focus. Wireless communication is required to occur at 2.4 GHz which is an industrial
standard and is extensively used in Bluetooth, ZigBee and similar wireless communication
technologies. This would facilitate easy transition into commercial applications.

As far as the data communication is concerned, the packet transfer between the Base Station
and the Remote Sensor Node should be efficient. Unnecessary overheads must be eliminated
while all the required data must be transmitted and received without errors. Packets generated
for transmission should include identity of the Remote Sensor Node, data to be recorded and
provision for error control.

The chief aim of the project is to achieve reduction in power consumption at the Remote
Sensor Node and if possible the Base Station too. This should be achieved without loss in
reliability and sensitivity. Components should be chosen to suit this objective. The circuits
have been designed with accurately manipulated components, most of which have SMD
(Surface Mounting Device) packages. The PCBs are also made as small as possible to reduce
power consumption and increase reliability. They also posses the specialities in terms of PTH
(Plated Through Hole) technology. The optimization of the circuit is the main purpose of the
design.

8
2 PRIOR STUDIES

9
2.1 Cross-bow sensor network kit
Cross-bow has developed a specialized study kit for domestic purpose to study and simulate
the sensor network. It shows the practical demonstration of a network with several sensors
like temperature, light, and voice. The study of this kit helps understanding the sensor
[4]
network. The design also inspires to make the actual hardware related to the project.
The applications for Wireless Sensor Networks are almost limitless with industries and
deployments having specific technology requirements such as reliability, battery-life, range,
frequencies, topologies, size of the network, sampling rate and sensor use.

To address the unique requirements of individual applications, Crossbow provides a broad

portfolio of wireless sensor network products that allow you to choose the optimal solution
for your industry, application and geographical requirements.

Development Kits

They provide users with a pre-configured set of hardware to get started with Crossbow’s Mote
hardware. Whether you are just getting started with Crossbow’s hardware, or looking to create
your own OEM hardware, or need a packaged system for outdoor deployments – there is a kit
for you.

Wireless Modules

These are available in many different forms. Depending on the radio frequency and platform
requirements you may have for your application, there is a variety of wireless modules to
choose from whether it is our popular IRIS or TelosBMote to our high-power Imote2 device.

Sensor Boards

They set Crossbow apart from other wireless sensor network platform providers. Our large
offering ranges from light, temp and humidity to GPS, magnetometers and barometric
pressure. Coupled with our versatile data acquisition boards that allow users to interface their
own sensors, it is easy to see why Crossbow is the chosen company for any wireless sensor
application.

Gateways

10
They provide users with real-time access to their data. Simple USB and serial interface boards
are available as well as the Stargaze Net bridge which is a full-fledged embedded sensor
network gateway.

2.1.1 Robust Mesh Network

Traditional wireless RS485 often uses fixed routing, therefore any radio path is a critical path.
The proprietary Xmesh radio protocol is a self-forming / self-healing wireless mesh network
with ad-hoc multi-hopping capabilities. Therefore if any path becomes unreliable, the
network will automatically find a new, better path to stay in reliable multi-point
communications. MEMSIC/Crossbow-Japan, being a pioneer in wireless mesh networks, has
proven the robustness of Xmesh through deployments of wireless energy systems in energy,
storage, factory maintenance, and other various applications, of which over 30,000 nodes are
steadily working today. The WS-Z5000A uses IEEE802.15.4 standard, 2.4GHz radio.

The WS-Z5000A has numerous intuitive features that facilitate the ease in installation.
- RS485 line connection is easy to install by simply inserting lines into the push-in terminals.
- Packet communications to/from the equipment and to/from another node are indicated by
LEDs.
- Node ID, Group ID, and radio channel are selectable by switch, enabling these parameters.
- Mounting can be done by screws, hooks, or magnets.

2.2 Arduino [5]

Arduino is an open hardware concept, developed by the students of university of Italy.
Arduino is an open-source physical computing platform based on a simple I/O board and a
development environment that implements the Processing/Wiring language. Arduino can be
used to develop stand-alone interactive objects or can be connected to software on your
computer (e.g. Flash, Processing, and MaxMSP). The boards can be assembled by hand or
purchased preassembled; the open-source
IDE can be downloaded for free.

11
2.2.1 Features
An Arduino is a single-board microcontroller and a software suite for programming it. The
hardware consists of a simple open hardware design for the controller with an Atmel
AVR processor and on-board I/O support. The software consists of a standard programming
language and the boot loader that runs on the board

Hardware
An Arduino board consists of an 8-bit Atmel AVR microcontroller with complementary
components to facilitate programming and incorporation into other circuits. An important
aspect of the Arduino is the standard way that connectors are exposed allowing the CPU
board to be connected to a variety of interchangeable add-on modules (known as shields).
Official Arduinos have used the megaAVR series of chips, specifically the ATmega8. At a
conceptual level, when using the Arduino software stack all boards are programmed over
an RS-232 serial connection, but the way this is implemented in hardware varies by version.
Serial Arduino boards contain a simple inverter circuit to convert between RS-232-level
and TTL-level signals. Current Arduino boards are programmed via USB, implemented using
USB-to-serial adapter chips such as the FTDI FT232.

2.2.2 Software

The Arduino IDE is a cross-platform application written in Java which is derived from the
IDE made for the Processing programming language and the Wiring project. It includes a
code editor with features such as syntax highlighting, brace matching, and automatic
indentation, and is also capable of compiling and uploading programs to the board with a
single click. There is typically no need to edit Make files or run programs on the command.

The Arduino IDE comes with a C/C++ library called "Wiring" (from the project of the same
name), which makes many common input/output operations much easier. Arduino programs
are written in C/C++, although users only need to define two functions in order to make a
runnable program:

y setup() – a function run once at the start of a program which can be used for
initializing settings, and
y loop() – a function called repeatedly until the board is powered off.

12
2.2.3 Overview of the hardware used for study

The Arduino Duemilanove ("2009") is a microcontroller board based on the ATmega168. It

has 14 digital input/output pins (of which 6 can be used as PWM outputs), 6 analog inputs, a
16 MHz crystal oscillator, a USB connection, a power jack, an ICSP header, and a reset
button. It contains everything needed to support the microcontroller; simply connect it to a
computer with a USB cable or power it with a AC-to-DC adapter or battery to get started.

"Duemilanove" means 2009 in Italian and is named after the year of its release. The
Duemilanove is the latest in a series of USB Arduino boards; for a comparison with previous
versions, see the index of Arduino boards.

Table 1 Summary of Arduino hardware

Microcontroller ATmega168
Input Voltage 6-20V
Digital I/O Pins 14 (of which 6 provide PWM output)
Analog Input Pins 6
Flash Memory 16 KB (ATmega168) of which 2 KB used by bootloader
SRAM 1 KB (ATmega168)
EEPROM 512 bytes (ATmega168)
Clock Speed 16 MHz

Software

The open-source Arduino environment makes it easy to write code and upload it to the i/o
board. It runs on Windows, Mac OS X, and Linux. The environment is written in Java and
based on Processing, avr-gcc, and other open source software.

Programming using Processing language

Processing is an open source "programming language and integrated development

environment (IDE) built for the electronic arts and visual design communities" with the
purpose of teaching the basics of computer programming in a visual context, and to serve as
the foundation for electronic sketchbooks. The project was initiated in 2001 by Casey

13
Reas and Ben Fry, both formerly of the Aesthetics and Computation Group at the MIT Media
Lab.

2.2.4 Bootloader [6]

A boot sequence is the initial set of operations that the computer performs when power is
switched on. The bootloader typically loads the main operating system for the computer.

A computer's central processor can only execute program code found in Read-Only Memory
(ROM) and Random Access Memory (RAM). Modern operating systems and application
program code and data are stored on non-volatile data storage devices, such as hard disk
drives, CD, DVD, USB flash drive, and floppy disk. When a computer is first powered on, it
does not have an operating system in ROM or RAM. The computer must initially execute a
small program stored in ROM along with the bare minimum of data needed to access the non-
volatile devices from which the operating system programs and data are loaded into RAM.

The small program that starts this sequence of loading into RAM, is known as a bootstrap
loader, bootstrap or boot loader. This small boot loader program's only job is to load other
data and programs which are then executed from RAM. Often, multiple-stage boot loaders
are used, during which several programs of increasing complexity sequentially load one after
the other in a process of chain loading.

When you upload a sketch, you're using the Arduino bootloader, a small program that has
been loaded on to the microcontroller on your board. It allows you to upload code without
using any additional hardware. The bootloader is active for a few seconds when the board
resets; then it starts whichever sketch was most recently uploaded to the microcontroller.

14
3 HARDWARE DESCRIPTION

15
Multipurpose Wireless Transceiver Node

Figure 3-1 Wireless Sensor Node Component Layout

Power Supply: Jumper Settings:

Via USB As a Base Station:
POW JMP connector Remove TXD, RXD Jumper
Insert DIN – DOUT Left side
Status LEDs:
TX – Transmit Status As a Stand Alone Node:
RX – Receive Status Insert TXD, RXD Jumper
L1 – Power ON Insert DIN – DOUT Right Side
L2 – XBEE Status
L4 – Reset

16
3.1 Hardware Requirements

The basic requirement of the various components used in the circuits involved in the project
is that they must operate at low power levels. Especially, the microcontroller and the Radio
Frequency (RF) communication ICs should be chosen with great care as these components
contribute most to power consumption and dissipation.

Further it is necessary that the Printed Circuit Boards (PCBs) that are to house various circuit
components should be designed meticulously taking into consideration the main aim of the
project. Placement of components, routing of tracks for connecting the components, thickness
of the routing tracks etc. should be paid careful attention to so that dissipation of power may
be reduced to the greatest extent.

Since the chosen frequency of operation is 2.4 GHz, the design of the RF section on the PCB
must be carried out with appropriate considerations for noise reduction and optimum
coupling of power.

The main area of application of the project is in Wireless Sensor Networks. In such wireless
networks, size of sensor nodes is required to be minimal so as to facilitate deployment in any
possible environment. This necessitates that the PCBs be designed as small as possible
without compromising on performance, capability and functions.

3.2 Block Diagram

3.2.1 Base Station

The Base Station (BS) is responsible for receiving data from the sensor nodes and processing
it as required. The microcontroller forms the heart of the BS and is responsible for enabling
wireless communication, data packet formation, data packet decoding, data forwarding and
displaying the received values on the on-board LCD. The microcontroller is connected to the
RF communication unit which consists of the RF integrated circuit and antenna. The
microcontroller is interfaced with the XBee module using SPI.

17
 Figure 3-2 Block Diagram for Base Station

The microcontroller is also interfaced with a computer terminal using the USB interfaces.
This is meant to forward the received data to the computer terminal for displaying it on a GUI
and further processing, decision making etc. as may be necessary. All the components in the
BS are powered by a Power Unit. It consists of a battery or power supply (whichever is
available) and voltage regulators which limit the voltage to certain values in order to protect
the components and to reduce unnecessary power consumption.

3.2.2 Remote Sensor Node

The design of the Remote Sensor Node (SN) is a very crucial part of the project. In
construction it is similar to the BS. The SN consists of a microcontroller which collects

18
sensor values from the on-board or remote sensors in the vicinity. These values are then
incorporated into data packets and sent over the wireless link to another SN or to the BS
depending on the location of the SN and algorithm applied. While the RF communication
section is the same as that in the BS, the SN differs in the power unit and the microcontroller
code. The power unit can have only miniature batteries and cells as power sources. The code
loaded into the microcontroller at the SN is much more complex compared to that at the BS.
The SN is required to queue and store data packets and make routing decisions as to which
SN the packet is to be forwarded to.

Figure 3-3 Block diagram of Ad Hoc wireless sensor Node

The main concern in designing the SN is to reduce the power consumption to extremely low
levels. This is important since the source of power at a SN is a small battery/cell and
replacing it is very difficult given the environments where these WSNs are deployed. Hence,
it is prudent to elongate the lifetime of the battery/cell by reducing power consumption.

19
3.3 Hardware Components

3.3.1 XBee RF Module [7]

Figure 3-4 XBEE Module

The XBee and XBee-PRO OEM RF Modules were engineered to meet IEEE 802.15.4
standards and support the unique needs of low-cost, low-power wireless sensor networks. The
modules require minimal power and provide reliable delivery of data between devices. The
modules operate within the ISM 2.4 GHz frequency band and are pin-for-pin compatible with
each other.

XBee multipoint RF modules are ideal for applications requiring low latency and predictable
communication timing. Providing quick, robust communication in point-to-point, peer-to-
peer, and multipoint/star configurations, XBee multipoint products enable robust end-point
connectivity with ease. Whether deployed as a pure cable replacement for simple serial
communication, or as part of a more complex hub-and-spoke network of sensors, XBee
multipoint RF modules maximize wireless performance and ease of development.

20
Key Features

Long Range Data Integrity

y Indoor/Urban: up to 100’ (30 m)
y Outdoor line-of-sight: up to 300’ (100 m)
y Transmit Power: 1 mW (0 dBm)
y Receiver Sensitivity: -92 dBm

Low Power
y TX Current: 45 mA (@3.3 V)
y RX Current: 50 mA (@3.3 V)
y Power-down Current: < 10 μA

Miscellaneous Features
y 802.15.4/Multipoint network topologies
y 2.4 GHz for worldwide deployment
y 900 MHz for long-range deployment
y Fully interoperable Digi Drop-in Networking products, including gateways & device
y Common XBee footprint for a variety of RF modules
y Low-power sleep modes
y Multiple antenna options
y Industrial temperature rating (-40º C to 85º C)
y Low power and long range variants available

Usability
y A/D Conversion
y Digital I/O lines
y DSSS Support
y No configuration necessary for out-of box RF communications
y Free X-CTU Software
y Extensive command set
y Point-to-point, point-to-multipoint and peer-to-peer topologies supported
y World Wide Acceptance
y ISM (Industrial, Scientific & Medical) 2.4 GHz frequency band

21
RF Module Operation (Serial Communications)

UART Data Flow

Serial Data Devices that have a UART interface can connect directly to the pins of the RF
module. System Data Flow Diagram in a UART‐interfaced environment (Low‐asserted
signals distinguished with horizontal line over signal name.) The XBee OEM RF Modules
interface to a host device through a logic-level asynchronous serial port. Through its serial
port, the module can communicate with any logic and voltage compatible UART; or through
a level translator to any serial device (For example: Through a Max- Stream proprietary RS-
232 or USB interface board).

Figure 3.5 Voltage Level for UART

API Operation
API (Application Programming Interface) Operation is an alternative to the default
Transparent Operation. The frame-based API extends the level to which a host application
can interact with the networking capabilities of the module. When in API mode, all data
entering and leaving the module is contained in frames that define operations or events within
the module.

Transmit Data Frames (received through the DI pin (pin 3)) include:
y RF Transmit Data Frame
y Command Frame (equivalent to AT commands)

Receive Data Frames (sent out the DO pin (pin 2)) include:
y RF-received data frame
y Command response

22
 y Event notifications such as reset, associate, disassociate, etc.

The API provides alternative means of configuring modules and routing data at the host
application layer. A host application can send data frames to the module that contain address
and payload information instead of using command mode to modify addresses. The module
will send data frames to the application containing status packets; as well as source, RSSI and
payload information from received data packets.

DI (Data In) Buffer

When serial data enters the RF module through the DI pin (pin 3), the data is stored in the DI
Buffer until it can be processed. Hardware Flow Control (CTS). When the DI buffer is 17
bytes away from being full; by default, the module de-asserts CTS (high) to signal to the host
device to stop sending data [refer to D7 (DIO7 Configuration) parameter]. CTS is re-asserted
after the DI Buffer has 34 bytes of memory available.

DO (Data Out) Buffer

When RF data is received, the data enters the DO buffer and is sent out the serial port to a
host device. Once the DO Buffer reaches capacity, any additional incoming RF data is lost.
Hardware Flow Control (RTS). If RTS is enabled for flow control (D6 (DIO6 Configuration)
Parameter = 1), data will not be sent out the DO Buffer as long as RTS (pin 16) is de-
asserted.

XBee Addressing Modes

Every RF data packet sent over-the-air contains a Source Address and Destination Address
field in its header. The RF module conforms to the 802.15.4 specification and supports both
short 16-bit addresses and long 64-bit addresses, To send a packet to a specific module using
64-bit addressing: Set Destination Address (DL + DH) to match the Source Address (SL +
SH) of the intended destination module. To send a packet to a specific module using 16-bit
addressing: Set DL (Destination Address Low) parameter to equal the MY parameter and set
the DH (Destination Address High) parameter to ‘0’.

23
Unicast Mode
By default, the RF module operates in unicast Mode. Unicast Mode is the only mode that
supports retries. While in this mode, receiving modules send an ACK (acknowledgement) of
RF packet reception to the transmitter. If the transmitting module does not receive the ACK,
it will re-send the packet up to three times or until the ACK is received.
Short 16-bit addresses. The module can be configured to use short 16-bit addresses as the
Source Address by setting (MY < 0xFFFE). Setting the DH parameter (DH = 0) will
configure the Destination Address to be a short 16-bit address (if DL < 0xFFFE). For two
modules to communicate using short addressing, the Destination Address of the transmitter
module must match the MY parameter of the receiver.
Long 64-bit addresses. The RF module’s serial number (SL parameter concatenated to the
SH parameter) can be used as a 64-bit source address when the MY (16-bit Source Address)
parameter is disabled. When the MY parameter is disabled (set MY = 0xFFFF or 0xFFFE),
the module’s source address is set to the 64-bit IEEE address stored in the SH and SL
parameters.

Broadcast Mode
Any RF module within range will accept a packet that contains a broadcast address. When
configured to operate in Broadcast Mode, receiving modules do not send ACKs
(Acknowledgements) and transmitting modules do not automatically re-send packets as is the
case in Unicast Mode. To send a broadcast packet to all modules regardless of 16-bit or 64-
bit addressing, set the desti-nation addresses of all the modules as shown below.
y DL (Destination Low Address) = 0x0000FFFF
y DH (Destination High Address) = 0x00000000 (default value)

24
3.3.2 Atmega168 Microcontroller [8]

Figure 3-5 ATmega168 architecture

TheAtmega168 is a low-power CMOS 8-bit microcontroller based on the AVR enhanced

RISC architecture. By executing powerful instructions in a single clock cycle, the
ATmega16L achieves throughputs approaching 1 MIPS per MHz allowing the system
designed to optimize power consumption versus processing speed. The ATmega16L AVR is
supported with a full suite of program and system development tools including: C compilers,
macro assemblers, program debugger/simulators, in-circuit emulators, and evaluation kits.

25
The following features drive the choice of Atmega168 over other available microcontrollers:
• High-performance, Low-power AVR 8-bit Microcontroller

• Advanced RISC Architecture

o 131 Powerful Instructions – Most Single Clock Cycle Execution
o 32 x 8 General Purpose Working Registers
o Fully Static Operation
o Up to 20 MIPS Throughput at 20 MHz
o On-chip 2-cycle Multiplier

• High Endurance Non-volatile Memory Segments

o 16K Bytes of In-System Self-Programmable Flash program memory
o 512 Bytes EEPROM
o 1K Bytes Internal SRAM
o Write/Erase Cycles: 10,000 Flash/100,000 EEPROM

y Peripheral Features
o Two 8-bit Timer/Counters with Separate Prescaler and Compare Mode
o One 16-bit Timer/Counter with Separate Prescaler, Compare & Capture Mode
o Real Time Counter with Separate Oscillator
o Six PWM Channels
o 8-channel 10-bit ADC in TQFP and QFN/MLF package
o Temperature Measurement
o 6-channel 10-bit ADC in PDIP Package
o Programmable Serial USART
o Master/Slave SPI Serial Interface
y Special Microcontroller Features
o Power-on Reset and Programmable Brown-out Detection
o Internal Calibrated Oscillator
o External and Internal Interrupt Sources
o Six Sleep Modes: Idle, ADC Noise Reduction, Power-save, Power-down, Standby
and Extended Standby
o 23 Programmable I/O Lines

26
 o Operating Voltage: 1.8 - 5.5V
o Speed Grade: 0 - 20 MHz @ 1.8 - 5.5V
o Low Power Consumption at 1
– Active Mode: 0.2 mA
– Power-down Mode: 0.1 μA
– Power-save Mode: 0.75 μA (Including 32 kHz RTC)

3.3.3 FT232R USB - UART Bridge Converter IC [9]

Figure 3-6 Diagram of FT232R IC

The FT232R is a USB to serial UART interface with the following advanced features

y Single chip USB to asynchronous serial data transfer interface.

y Entire USB protocol handled on the chip. No USB specific firmware programming
required.

27
 y Fully integrated 1024 bit EEPROM storing device descriptors and CBUS I/O
configuration.
y Fully integrated USB termination resistors.
y Fully integrated clock generation with no external crystal required plus optional clock
output selection enabling a glue-less interface to external MCU or FPGA.
y Data transfer rates from 300 baud to 3 M baud (RS422, RS485 and RS232) at TTL
levels.
y 256 byte receive buffer and 128 byte transmit buffer utilising buffer smoothing
technology to allow for high data throughput.
y Configurable CBUS I/O pins.
y Transmit and receive LED drive signals. FIFO receive and transmit buffers for high
data throughput.
y Synchronous and asynchronous bit bang interface options
y Low USB bandwidth consumption.
y USB 2.0 Full Speed compatible.

Low Power Consumption

y +3.3V to +5.25V Single Supply Operation.
y Integrated +3.3V level converter for USB I/O.
y Integrated level converter on UART and CBUS for interfacing to between +1.8V and
+5V logic.
y True 5V/3.3V/2.8V/1.8V CMOS drive output and TTL input. Low operating and
USB suspend current.

Typical Applications
y USB to RS232/RS422/RS485 Converters
y Upgrading Legacy Peripherals to USB
y Cellular and Cordless Phone USB data transfer cables and interfaces
y Interfacing MCU/PLD/FPGA based designs to USB
y USB Audio and Low Bandwidth Video data transfer
y PDA to USB data transfer
y USB Smart Card Readers
y USB Instrumentation
y USB Industrial Control

28
 y USB MP3 Player Interface
y USB FLASH Card Reader and Writers
y Set Top Box PC - USB interface
y USB Digital Camera Interface
y USB Hardware Modems
y USB Wireless Modems
y USB Bar Code Readers
y USB Software

3.4 Miscellaneous Hardware Parts:

The hardware design is optimized for the components placement and power consumption.
For that purpose, the best choice of components is to use SMD (Surface Mounting Device)
components. Here is the list of the components used in the project circuit.

y IC-XXXX - SOT223 Packaged SMD Voltage Regulator

y Mini USB-B – SMD USB connector
y c1206 – SMD Capacitors
y r1206 – SMD Resistors
y SMD LEDs (Red, Green)
y Crystal Oscillator
y Push Button switch for Reset
y Male connectors for external connections to other devices such as sensors.

3.5 Protocols

3.5.1 ZigBee (IEEE 802.15.4)

ZigBee is a specification for a suite of high level communication protocols using small, low-
power digital radios based on the IEEE 802.15.4-2003standard for wireless personal area
networks (WPANs), such as wireless headphones connecting with cell phones via short-range
radio. The technology defined by the ZigBee specification is intended to be simpler and less
expensive than other WPANs, such as Bluetooth. ZigBee is targeted at radio-frequency (RF)
applications that require a low data rate, long battery life, and secure networking.

29
ZigBee is a low-cost, low-power, wireless mesh networking proprietary standard. The low
cost allows the technology to be widely deployed in wireless control and monitoring
applications, the low power-usage allows longer life with smaller batteries.

Figure 3-7 Protocol Stack of ZigBee

Protocols:

The protocols build on recent algorithmic research (Ad-hoc On-demand Distance

Vector, neuRFon) to automatically construct a low-speed ad-hoc network of nodes. In most
large network instances, the network will be a cluster of clusters. It can also form a mesh or a
single cluster. The current profiles derived from the ZigBee protocols support beacon and
non-beacon enabled networks.

In non-beacon-enabled networks, an unslotted CSMA/CA channel access mechanism is used.

In this type of network, ZigBee Routers typically have their receivers continuously active,
requiring a more robust power supply. However, this allows for heterogeneous networks in
which some devices receive continuously, while others only transmit when an external
stimulus is detected. The typical example of a heterogeneous network is a wireless light

30
switch: The ZigBee node at the lamp may receive constantly, since it is connected to the
mains supply, while a battery-powered light switch would remain asleep until the switch is
thrown. The switch then wakes up, sends a command to the lamp, receives an
acknowledgment, and returns to sleep. In such a network the lamp node will be at least a
ZigBee Router, if not the ZigBee Coordinator; the switch node is typically a ZigBee End
Device.

In beacon-enabled networks, the special network nodes called ZigBee Routers transmit
periodic beacons to confirm their presence to other network nodes. Nodes may sleep between
beacons, thus lowering their duty cycle and extending their battery life. Beacon intervals may
range from 15.36 milliseconds to 15.36 ms * 214 = 251.65824 seconds at 250 Kbit/s, from 24
milliseconds to 24 ms * 214 = 393.216 seconds at 40 Kbit/s and from 48 milliseconds to 48
ms * 214 = 786.432 seconds at 20 Kbit/s. However, low duty cycle operation with long
beacon intervals requires precise timing, which can conflict with the need for low product
cost.

Device Types:
[12]
There are three different types of ZigBee devices:

y ZigBee coordinator (ZC): The most capable device, the coordinator forms the root of
the network tree and might bridge to other networks. There is exactly one ZigBee
coordinator in each network since it is the device that started the network originally.
y ZigBee Router (ZR): As well as running an application function, a router can act as an
intermediate router, passing on data from other devices.
y ZigBee End Device (ZED): Contains just enough functionality to talk to the parent
node (either the coordinator or a router); it cannot relay data from other devices. This
relationship allows the node to be asleep a significant amount of the time thereby
giving long battery life.

Typical Applications

y Home Entertainment and Control — Smart lighting, advanced temperature control,

safety and security, movies and music

31
y Home Awareness — Water sensors, power sensors, energy monitoring, smoke and fire
detectors, smart appliances and access sensors
y Mobile Services — m-payment, m-monitoring and control, m-security and access
control, m-healthcare and tele-assist
y Commercial Building — Energy monitoring, HVAC, lighting, access control
y Industrial Plant — Process control, asset management, environmental management,
energy management, industrial device control

3.5.2 USB [13] Protocol

USB (Universal Serial Bus) is a specification to establish communication between devices
and a host controller (usually personal computers), developed and invented by Intel. USB is
intended to replace many varieties of serial and parallel ports.

A USB system has an asymmetric design, consisting of a host, a multitude of downstream

USB ports, and multiple peripheral devices connected in a tiered-star topology.
Additional USB hubs may be included in the tiers, allowing branching into a tree structure
with up to five tier levels. A USB host may have multiple host controllers and each host
controller may provide one or more USB ports. Up to 127 devices, including hub devices if
present, may be connected to a single host controller

32
4 PRINTED CIRCUIT BOARD DESIGN

33
4.1 Introduction to PCB Design using Eagle 5.7.0

Eagle Layout Editor is a tool for designing PCB layout. Apart from designing, it also
provides various built-in features for design verification and manufacturing processing.
OrCAD capture provides a component information system that allows one to identify, utilize
and design with preferred parts. In the following subsection, a detailed description of the
features provided by OrCAD capture and OrCAD layout are discussed.

4.2 Features of Eagle 5.7.0

The EAGLE Layout Editor is an easy to use, yet powerful tool for designing printed circuit
boards (PCBs). The name EAGLE is an acronym, which stands for
Easily Applicable Graphical Layout Editor

• Maximum drawing area 1.6 x 1.6m (64 x 64 inch)

• Resolution 1/10,000mm (0.1 micron)
• Up to 16 signal layers
• Conventional and SMT parts
• Comes with a full set of part libraries
• Easy to create own parts with the fully integrated library editor
• Undo/redo function for ANY editing command, to any depth
• Script files for batch command execution
• Copper pouring
• Cut and paste function for copying entire sections of a drawing
• Design rule check
• Interactive Follow-me Router (requires the Autorouter module)

34
4.3 Initial Design of Wireless Node

Figure 4-1 Initial Design of node Figure 4-2 Initial design-2

Figure 4-3 Design after routing signals Figure 4-4 New circular design

35
Figure 4-5 After routing signals Figure 4-6 Final Optimized Layout dsign

Rules check done for the following errors in the layout design

• Placement spacing violations

• Route spacing violations
• Net rule violations
• Copper continuity violations
• Via location violations
• Off – grid vias
• Pad exit violations
• Test point violations
• Check copper pour

After completing the design rules check and fixing all the errors the design was cleaned up
using the Erc option in the menu. It eliminates the acute angles in the routing, optimizes
vertices, shared tracks, shared Vias and pad exits. It also eliminates the unused nets,
padstacks and footprints from the database.

36
4.4 Generating Gerber Files

The format of layout design is ‘.brd’ thus before sending it to fabrication house it
needs to be converted in to standard format. All the fabrication houses accept standard gerber
files. We converted files in to GERBER_RS274X format. Under this format, files for each
layer will be generated.
• .cmp – component side
• .sol – solder side
• .plc – silk screen component side
• .stc – solder stop mask component side
• .sts – solder stop mask solder side
• .drd – generate drill data (Select Excellon job)

Figure 4-7 Generating Gerber files using CAM processor in Eagle 5.7.0

37
5 COMMUNICATION INTERFACE

38
5.1 Serial Communication and USB Interface using FT232R

Two main types of on-board communication occur in the project. Serial communication over
via USB is achieved by the use of FT232R IC. FT232R works as USB to Serial bridge
converter. Communication between XBEE and microcontroller is done via UART. As well
as UART is used to made communication between User terminal and wireless node.

The FT232R is a USB to serial UART bridge interface device which simplifies USB to serial
designs and reduces external component count by fully integrating an external EEPROM,
USB termination resistors and an integrated clock circuit which requires no external crystal,
into the device. It has been designed to operate efficiently with a USB host controller by
using as little as possible of the total USB bandwidth available.

Figure 5-1 Basic Connections of FTDI to controller

39
Signals Used in FT232R
• TXDEN# - transmit enable for RS485 designs.
• PWREN# - Power control for high power, bus powered designs.
• TXLED# - for pulsing an LED upon transmission of data.
• RXLED# - for pulsing an LED upon receiving data.
• TX&RXLED# - which will pulse an LED upon transmission OR reception of data.
• SLEEP# - indicates that the device going into USB suspend mode.
• CLK48 / CLK24 / CLK12 / CLK6 - 48MHz, 24MHz, 12MHz, and 6MHz clock
output signal options.

Internal EEPROM
The internal EEPROM in the FT232R is used to store USB Vendor ID (VID), Product ID
(PID), device serial number, product description string and various other USB configuration
descriptors. The internal EEPROM is also used to configure the CBUS pin functions.

USB Transceiver
The USB Transceiver Cell provides the USB 1.1 / USB 2.0 full-speed physical interface to
the USB cable. The output drivers provide +3.3V level slew rate control signalling, whilst a
differential input receiver and two single ended input receivers provide USB data in.

USB DPLL
The USB DPLL cell locks on to the incoming NRZI USB data and generates recovered clock
and data signals for the Serial Interface Engine (SIE) block.

Internal 12MHz Oscillator

The Internal 12MHz Oscillator cell generates a 12MHz reference clock. This provides an
input to the x4 Clock Multiplier function. The 12MHz Oscillator is also used as the reference
clock for the SIE, USB Protocol Engine and UART FIFO controller blocks.

Serial Interface Engine (SIE)

The Serial Interface Engine (SIE) block performs the parallel to serial and serial to parallel
conversion of the USB data. In accordance with the USB 2.0 specification, it performs bit
stuffing/un-stuffing. It checks CRC (Cyclic redundancy check) on the USB data-stream.

40
USB Protocol Engine
The USB Protocol Engine manages the data stream from the device USB control endpoint. It
handles the low level USB protocol requests generated by the USB host controller and the
commands for controlling the functional parameters of the UART in accordance with the
USB 2.0 specification.

FIFO TX Buffer (128 bytes)

Data from the USB data OUT endpoint is stored in the FIFO TX buffer and removed from
the buffer to the UART transmit register under control of the UART FIFO controller.

FIFO RX Buffer (256 bytes)

Data from the UART receive register is stored in the FIFO RX buffer prior to being removed
by the SIE on a USB data request from the device data IN endpoint.

UART FIFO Controller

The UART FIFO controller handles the transfer of data between the FIFO RX and TX
buffers and the UART transmit and receive registers.

5.2 Configuring FT232R

5.2.1 Driver Installation

To access FT232R on PC, FTDI USB drivers must be installed on PC. Once drivers
get installed, It can be detect using FT_PROG software (www.ftdichip.com).
When you plug in the node, you may hear a sound from the computer and a little popup
bubble in the bottom right corner of the screen that says ‘Found New Hardware FT232R
USB UART’

41
 Figure 5-2 Pop-up window in Windows

At the next screen, select Install from a list or specific location

Figure 5-3 Installing FTDI drivers

Browse location from PC and scan for device drivers. Once installation gets finished a new
window pops up to install USB serial port on PC. Then device is ready to use.

42
 Figure 5-4 Driver Installation finished, New virtual COM port created

Almost immediately, another window will pop up, this time it will say USB Serial Port. As
before, click Install from a list or specific location. And it should complete successfully!

Figure 5-5 Device manager

43
When the computer is done rebooting, make sure the node is plugged in (and the red light is
lit). Go to the Device Manager (From the Start Menu, select Settings->Control Panel.
Double click on System and select the Hardware tab. Then click on the Device
Manager button)

Look for an entry under Ports (COM & LPT) that says USB Serial Port (COM) the COM
number may vary but it should be something like COM3 orCOM4. The COM stands for
"communication", and each one has a unique number, known as the COM Port number. In
this case the COM Port number is COM3.

5.2.2 FTDI Configuration

After finishing driver installation, Run FTDI FT Prog software. Internal EPROM and Flash
ROM of FT232R can be accessed using FT Prog software now. By pressing ‘Scan and Parse’
option from Device menu, FT232 can be detected and accessed on FT_PROG software. It
indicates that FT232R is working.

Figure 5-6 Configuring FT232R using FT Prog Software

44
5.3 Wireless Communication using IEEE 802.15.4 XBEE module

Figure 5-7 IEEE 802.15.4 XBEE 1mW wire antenna IC

XBEE is a IEEE 802.15.4 zigbee transceiver IC with inbuilt RF section and antenna. XBEE
supports UART communication mode for data transfer with other devices. It can be easily
accessed with microcontroller and PC via UART.

5.3.1Configuring XBEE

X-CTU is a Windows-based application provided by Digi. This program was

designed to interact with the firmware files found on Digi’s RF products and to provide a
simple-to-use graphical user interface to them.

45
 Figure 5-8 GUI of
o X-CTU application
a

Figurre 5-9 Modeem Configu

uration using X-CTU ap
pplication

46
PC Settings
Allows user to select the desired COM port and configure that port to fit the radios settings.

Range Test
Allows user to perform a range test between two radios.

Terminal
Allows access to the computer’s COM port with a terminal emulation program. This tab also
allows the ability to access the radios’ firmware using AT commands.

Modem Configuration
Allows user to program the radios’ firmware settings via a graphical user interface. This tab
also allows customers the ability to change firmware version also. This operation is
performed via AT commands. Using AT commands following parameters can set..
• Channel ID
• Device ID
• Power mode
• Sleep mode settings
• Data rate
• TX – RX power level
• Parity check
• Security (Encryption key)
• I/O settings
• Firmware update

5.4 Universal Asynchronous Receiver Transmitter (UART) Interface

A Universal Asynchronous Receiver/Transmitter a computer hardware that translates data

between parallel and serial forms. UARTs are commonly used in conjunction with other
communication standards.
A UART is usually an individual (or part of an) integrated circuit used for serial
communications over a computer or peripheral device serial port. UARTs are now commonly
included in microcontrollers. Many modern ICs now come with a UART that can also

47
communicate synchronously (e.g. FT232R); these devices are called USARTs (universal
synchronous/asynchronous receiver/transmitter).

A UART usually contains the following components:

y A clock generator, usually a multiple of the bit rate to allow sampling in the middle of a
bit period.
y Input and output shift registers
y Transmit/receive control
y Read/write control logic
y Transmit/receive buffers (optional)
y Parallel data bus buffer (optional)
y First-in, first-out (FIFO) buffer memory (optional)

5.4.1 Transmitting and receiving serial data

The Universal Asynchronous Receiver/Transmitter (UART) controller is the key component
of the serial communications subsystem of a computer. The UART takes bytes of data and
transmits the individual bits in a sequential fashion. At the destination, a second UART re-
assembles the bits into complete bytes. Serial transmission of digital information (bits)
through a single wire or other medium is much more cost effective than parallel transmission
through multiple wires. A UART is used to convert the transmitted information between its
sequential and parallel form at each end of the link. Each UART contains a shift
register which is the fundamental method of conversion between serial and parallel forms.

The UART usually does not directly generate or receive the external signals used between
different items of equipment. Typically, separate interface devices are used to convert the
logic level signals of the UART to and from the external signaling levels.
As of 2008, UARTs are commonly used with RS-232 for embedded systems
communications. It is useful to communicate between microcontrollers and also with PCs.
Many chips provide UART functionality in silicon, and low-cost chips exist to convert logic
level signals (such as TTL voltages) to RS-232 level signals (for example, FT232R, used in
the project)

48
5.4.2 Asynchronous receiving and transmitting
In asynchronous transmitting, teletype-style UARTs send a "start" bit, five to eight data bits,
least-significant-bit first, an optional "parity" bit, and then one, one and a half, or two "stop"
bits. The start bit is the opposite polarity of the data-line's idle state. The stop bit is the data-
line's idle state, and provides a delay before the next character can start. (This is called
asynchronous transmission). In mechanical teletypes, the "stop" bit was often stretched to two
bit times to give the mechanism more time to finish printing a character. A stretched "stop"
bit also helps resynchronization

Asynchronous transmission allows data to be transmitted without the sender having to send a
clock signal to the receiver. Instead, the sender and receiver must agree on timing parameters
in advance and special bits are added to each word which is used to synchronize the sending
and receiving units.

When a word is given to the UART for Asynchronous transmissions, a bit called the "Start
Bit" is added to the beginning of each word that is to be transmitted. The Start Bit is used to
alert the receiver that a word of data is about to be sent, and to force the clock in the receiver
into synchronization with the clock in the transmitter. These two clocks must be accurate
enough to not have the frequency drift by more than 10% during the transmission of the
remaining bits in the word.

After the Start Bit, the individual bits of the word of data are sent, with the Least Significant
Bit (LSB) being sent first. Each bit in the transmission is transmitted for exactly the same
amount of time as all of the other bits, and the receiver “looks” at the wire at approximately
halfway through the period assigned to each bit to determine if the bit is a 1 or a 0. For
example, if it takes two seconds to send each bit, the receiver will examine the signal to
determine if it is a 1 or a 0 after one second has passed, then it will wait two seconds and then
examine the value of the next bit, and so on.

Start Data 0 Data 1 Data 2 Data 3 Data 4 Data 5 Data 6 Data 7 END

Table Data Stream in Serial Communication

49
When the entire data word has been sent, the transmitter may add a Parity Bit that the
transmitter generates. The Parity Bit may be used by the receiver to perform simple error
checking. Then at least one Stop Bit is sent by the transmitter.
All operations of the UART hardware are controlled by a clock signal which runs at a
multiple (say, 16) of the data rate - each data bit is as long as 16 clock pulses. The receiver
tests the state of the incoming signal on each clock pulse, looking for the beginning of the
start bit. If the apparent start bit lasts at least one-half of the bit time, it is valid and signals the
start of a new character. If not, the spurious pulse is ignored. After waiting a further bit time,
the state of the line is again sampled and the resulting level clocked into a shift register. After
the required number of bit periods for the character length (5 to 8 bits, typically) have
elapsed, the contents of the shift register is made available (in parallel fashion) to the
receiving system. The UART will set a flag indicating new data is available, and may also
generate a processor interrupt to request that the host processor transfers the received data. In
some common types of UART, a small first-in, first-out (FIFO) buffer memory is inserted
between the receiver shift register and the host system interface. This allows the host
processor more time to handle an interrupt from the UART and prevents loss of received data
at high rates.

Transmitting and receiving UARTs must be set for the same bit speed, character length,
parity, and stop bits for proper operation. The receiving UART may detect some mismatched
settings and set a "framing error" flag bit for the host system; in exceptional cases the
receiving UART will produce an erratic stream of mutilated characters and transfer them to
the host system.

Typical serial ports used with personal computers connected to modems use eight data bits,
no parity, and one stop bit; for this configuration the number of ASCII character per seconds
equals the bit rate divided by 10

5.4.3 Special Receiver Condition

Overrun Error

An "overrun error" occurs when the USART receiver cannot process the character that just
came in before the next one arrives. Various USART devices have different amounts of
buffer space to hold received characters. The CPU must service the USART in order to

50
remove characters from the input buffer. If the CPU does not service the USART quickly
enough and the buffer becomes full, an Overrun Error will occur.

Under-run Error

An "under-run error" occurs when the UART transmitter has completed sending a character
and the transmit buffer is empty. In asynchronous modes this is treated as an indication that
no data remains to be transmitted, rather than an error, since additional stop bits can be
appended. This error indication is commonly found in USARTs, since an under-run is more
serious in synchronous systems.

Framing Error

A "framing error" occurs when the designated "start" and "stop" bits are not valid. As the
"start" bit is used to identify the beginning of an incoming character, it acts as a reference for
the remaining bits. If the data line is not in the expected idle state when the "stop" bit is
expected, a Framing Error will occur.

Parity Error

A "parity error" occurs when the number of "active" bits does not agree with the specified
parity configuration of the USART, producing a Parity Error. Because the "parity" bit is
optional, this error will not occur if parity has been disabled. Parity error is set when the
parity of an incoming data character does not match the expected value.

Break Condition

A "break condition" occurs when the receiver input is at the "space" level for longer than
some duration of time, typically, for more than a character time. This is not necessarily an
error, but appears to the receiver as a character of all zero bits with a framing error.

Some equipment will deliberately transmit the "break" level for longer than a character as an
out-of-band signal. When signalling rates are mismatched, no meaningful characters can be
sent, but a long "break" signal can be a useful way to get the attention of a mismatched
receiver to do something (such as resetting itself). Unix-like systems can use the long "break"
level as a request to change the signalling rate, to support dial-in access at multiple signalling
rates.

51
6 SOFTWARE INTERFACE

52
6.1 Compiler and Simulation Software

The Writing, compiling & debugging of the programming code is done by the use of
NetBeans. NetBeans refers to both a platform framework for Java desktop applications, and
an Integrated Development Environment (IDE) for developing with JAVA, C, C++,
Python and many other programming languages.

6.1.1 NetBeans IDE 6.8: [10]

The NetBeans IDE is an open source IDE, written in Java and runs everywhere where a JVM
(Java Virtual Machine) is installed, including Windows, Mac OS & Linux. A JDK (Java
Development Kit) is required for Java development functionality, but is not required for
development in other programming languages.

The NetBeans Platform allows applications to be developed from a set of modular software
components called modules. Applications based on the NetBeans platform (including the
NetBeans IDE) can be extended by us.

The platform offers reusable services common to desktop applications, allowing developers
to focus on the logic specific to their application. Among the features of the platform are:

y User interface management (e.g. menus and toolbars)

y User settings management
y Storage management (saving and loading any kind of data)
y Window management
y Wizard framework (supports step-by-step dialogs)
y NetBeans Visual Library

NetBeans Features:
These modules are part of the NetBeans IDE.
NetBeans Profiler

The NetBeans Profile is a tool for the monitoring of Java applications: It helps you find
memory leaks and optimize speed. Formerly downloaded separately, it is integrated into the
core IDE since version 6.0.

53
The Profiler is based on a Sun Laboratories research project that was named JFluid. That
research uncovered specific techniques that can be used to lower the overhead of profiling a
Java application. One of those techniques is dynamic byte code instrumentation, which is
particularly useful for profiling large Java applications. Using dynamic byte code
instrumentation and additional algorithms, the NetBeans Profiler is able to obtain runtime
information on applications that are too large or complex for other profilers.

GUI design tool

Formerly known as project Matisse, the GUI design-tool enables developers to prototype and
design Swing GUIs by dragging and positioning GUI components.

The GUI builder also has built-in support for JSR 296 (Swing Application Framework), and
JSR 295 (Beans Binding technology).

NetBeans JavaScript Editor

NetBeans JavaScript Editor provides extended support for JavaScript, Ajax, and CSS.

JavaScript editor features comprise syntax highlighting, refactoring, code completion for
native objects and functions, generation of JavaScript class skeletons, generation of Ajax call-
backs from a template; and automatic browser compatibility checks.

NetBeans IDE Complete Bundle

Sun Microsystems also released a version of NetBeans that includes all of the features
mentioned below:

y NetBeans Base IDE

y Java SE, JavaFX
y Web & Java EE
y Java ME
y Ruby
y C/C++
y PHP (Version 6.5 and later)

54
 y Glassfish
y Apache Tomcat

6.2 WSN 1.0 GUI

WSN 1.0 is general purpose GUI software made in NetBeans which enables interfacing of
PC with wireless node via USB port. It uses rxtxSerial.dll file which has inbuilt functions to
communicate with USB port. Data in serial form is sent and received through USB COM port
can be accessed using WSN 1.0
Features of WSN 1.0:
• COM port selection
• Data rate selection
• File/Text data transmission option
• Preserves file format as it is
• Large text area to view received data
• GUI can be easily modified
*Refer APPENDIX B for source code.

6.2.1 WSN 1.0 GUI development in NetBeans

WSM 1.0 uses serial communication library files to access USB port of the PC. It has
powerful built in functions to communicate with serial port.

SerialPortEventListener: This function is responsible for communication with serial port of

the PC. All the configuration of COM port as well as data rate settings are accomplished in
this function

CommPortIdentifier: It identifies COM port at where wireless node is connected

SerialPortEvent: All the events that occurs is to be written in this function

55
 Figure 6-1 WSN 1.0 GUI for accessing Hardware

6.2.2 File transfer using WSN 1.0

Figure 6-2 Flag (~~~~~) is used for error free transmission of the file

56
 Figure 6-3 File selection

Figure 6-4 Transmitting data

57
7 APPLICATIONS

58
7.1 Applications

Some fields where wireless sensor networks find widespread applications are listed below.

These applications are feasible using ZigBee, which allows data rate of 250kbps. For that
specialized speech coding is required to compress the data. Types of streaming are as
follows:

y Unicast protocols send a separate copy of the media stream from the server to each
recipient. Unicast is the norm for most Internet connections, but does not scale well
when many users want to view the same program concurrently.
y Multicast protocols were developed to reduce the data replication (and consequent
server/network loads) that occurs when many recipients receive Unicast content
streams independently. These protocols send a single

1. File Transfer

File transfer is a generic term for the act of transmitting files over a computer network or
the Internet. There are numerous ways and protocols to transfer files over a network.
Computers which provide a file transfer service are often called file servers. Depending on
the client's perspective the data transfer is called uploading or downloading.

There are 2 types of file transfers:

y Pull-based file transfers where the receiver initiates a file transmission request.
y Push-based file transfers where the sender initiates a file transmission request.

Here the data transfer is initiated by the sender so it is called Push-based. The protocol used
from the large pool of protocols is ZigBee, which allows 250kbps with very low power
consumption. File of any format (Text, Audio etc.) can be transferred over air from one
computer terminal to the other using the application. A dedicated GUI (Graphical User
Interface) is designed such that it allows the direct text chatting and an additional option to
select the desired file to transferred is also provided.

59
2. Live Media streaming

y The verb 'to stream' is also derived from this term, meaning to deliver media in this
manner. Streaming media are multimedia that are constantly received by, and
normally presented to, an end-user while being delivered by a streaming provider.
Live streaming of audio is stream from the source to a group of recipients. Depending
on the network infrastructure and type, multicast transmission may be feasible.
y Peer-to-peer (P2P) protocols arrange for prerecorded streams to be sent between
computers. This prevents the server and its network connections from becoming a
bottleneck. However, it raises technical, performance, quality, and business issues.

3. Seismic Structure Response

• Science
- Understand response of buildings and underlying soil to ground shaking.
- Develop models to predict structure response for earthquake scenarios.
• Techniques and Applications
- Identification of seismic events that cause significant structure shaking.
- Local, at-node processing of waveforms.
[2]
- Embedded Network Sensing (ENS) will provide field data at sufficient densities to
develop predictive models of structure, foundation, soil response.

4. Contaminant Transport
• Science
- Understand inter-media contaminant transport and fate in real systems.
- Identify risky situations before they become exposures. Subterranean deployment.
• Techniques
- Environmental Micro-Sensors.
- Sensors capable of recognizing phases in air/water/soil mixtures.
- Sensors that withstand physically and chemically harsh conditions.
- Signal Processing: Nodes capable of real-time analysis of signals.
- Collaborative signal processing to expend energy only where there is risk.

60
5. Ecosystem Monitoring
• Science
- Understand response of wild populations to habitats over time.
- Develop in situ observation of species and ecosystem dynamics.

• Techniques
- Data acquisition of physical and chemical properties, at various spatial and temporal
scales, appropriate to the ecosystem, species and habitat.
- Automatic identification of organisms (current techniques involve close-range
human observation).
- Measurements over long period of time, taken in-situ. Harsh environments with
extremes in temperature, moisture, obstructions etc.

6. Context Aware Home

[3]
The goal of research on context-aware buildings is to offer an unobtrusive and appealing
environment embedded with pervasive devices that help its occupants to achieve their tasks at
hand; technology that interacts closely with its occupants in the most natural ways to the
point where such interaction becomes implicit. A multitude of futuristic scenarios have been
prophesied in magazines, movies and research papers. Researchers and technologists are
often very cautious in predicting the future shape of our technological landscape but the
following simple scenarios are among the recurring visions:
• Lights, chairs and tables automatically adjust as soon as the family gathers in the living
room to watch TV.
• Phones only ring in rooms where the addressee is actually present, preventing other
people being disturbed by useless ringing.
• The music being played in a room adapts automatically to the people within and the
pictures in the frames on the desk change depending on which person is working there.
• Interactive play spaces are created for children where images, music, narration, light and
sound effects are used to transform a normal child's bedroom into a fantasy land.
• In-house context-aware communication systems allow family members to speak to each
other as if they were in the same room, even when they are in different rooms.
• Elderly people will be supported in their daily life by context-aware homes, allowing
them to age in their own home or familiar environment.

61
• Complete security systems including emergency call out alarms for burglars, fire, or
injury with a complete awareness of the home owners wherever they are.

Figure 7-1 Context Aware Home

• In assisted living complexes, context-aware systems monitor the state of the elderly
occupants, freeing the nursing staff from the task of constantly supervising them, thus
giving them more time to care about those who actually need their support most.

62
8 RESULTS AND CONCLUSION

63
 RESULTS

The designed hardware was fabricated and tested several times for various parameters to
determine the range, reliability, sensitivity and amount of power reduction achieved. The
results were highly encouraging and have been summarized below.

Reliability
The hardware designed is highly reliable. The hardware delivered satisfactory
performance for almost 100% of the time. Out of an approximate 50 times that the
hardware was switched on for operation, it functioned 49 times perfectly as it should be
working.

Power Consumption
The results obtained are comparable to industrial and commercial standards. The
electrical current consumption in various modes has been summarized in the following
table:

Table 2 Observation of Current Consumption

Mode Current Consumption
Transmit 11.5 mA
Receive 10.6 mA
Sleep 160 µA

Range
During testing a range of 100m (LOS) was achieved. It worked indoor range of 10m as
desired. However, keeping in mind that power transmitted has been limited to the
minimum since numerous such low power sensors will be deployed in the same area, it is
safe to assume that the range available is satisfactory.

64
 CONCLUSION

The designed hardware conforms to the requirements detailed in the previous chapters
and performs with high reliability. The results obtained on testing the hardware are
satisfactory and the design is ready to be scaled for a full fledged Wireless Sensor
Network. The objective of power reduction in the nodes has been realized. With the use
of more sophisticated fabrication of the hardware this design is ideal to be used for
implementation of various commercial and industrial applications.

With regard to WSNs we may conclude that they have the potential to transform
communications. Integrating WSNs with existing services is also a possibility which
promises to usher in a revolution in communication technology. Unlike other networks,
WSNs are designed for specific applications. Applications include, but are not limited to,
environmental monitoring, surveillance systems, military target tracking and context
aware homes. In the future, WSNs are expected to become integral parts of our lives
through various such applications. Each application differs in features and requirements.
To support this diversity of applications, the development of new communication
protocols, algorithms, designs, and services are needed.

65
 REFERENCES

[1] Yingshu Li, My T. Thai, Weili Wu, “Wireless Sensor Networks and Applications”,
Springer Science Media, LLC, 2008.
[2] Mohammad Ilyas, Imad Mahgoub, “Handbook of Sensor Networks: Compact Wireless
and Wired Sensing Systems”, CRC Press, 2005.
[3] Sven Meyer, Andry Rakotonirainy, “A Survey of Research on Context-Aware Homes”.
[4] XBow Technologies: http://www.xbow.com/Products/wproductsoverview.aspx
[5] Arduino: An open hardware: http://www.arduino.cc/
[6] Bootloader (Wikipedia): http://en.wikipedia.org/wiki/Booting
[7] Xbee: http://www.digi.com/products/wireless/zigbee-mesh/xbee-zb-module.jsp#overview
[8]Atmega168Datasheet: http://www.atmel.com/dyn/resources/prod_documents/doc2545.pdf
[9]FT232R Datasheet: http://www.ftdichip.com/Documents/DataSheets/DS_FT232R.pdf
[10] NetBeans: www.netbeans.org/
[11] X-CTU: http://x-ctu.software.informer.com/
[12] ZigBee Protocol: http://en.wikipedia.org/wiki/ZigBee
[13] USB Protocol: http://en.wikipedia.org/wiki/Universal_Serial_Bus

66
 APPENDIX A:
PCB LAYOUTS

Figure 8-1 Top copper layer component side

Figure 8-2 Bottom copper layer solder side

67
Figure 8-3 Top layer silk screen Figure 8-4 Top layer mask

Figure 8-5 Bottom layer mask Figure 8-6 Drill data

68
Figure 8-7 Test PCB

69
 APPENDIX B:
JAVA Interfacing Code

/* This Code uses SerialTXRX Library to access USB port of the PC. It creates Virtual COM
port on USB. Data available on USB port is serial data */

package wireless;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import gnu.io.CommPortIdentifier;
import gnu.io.SerialPort;
import gnu.io.SerialPortEvent;
import gnu.io.SerialPortEventListener;
import java.io.File;
import java.io.FileOutputStream;
import java.util.Enumeration;
import java.util.logging.Level;
import java.util.logging.Logger;

public class SerialTest implements SerialPortEventListener {

SerialPort serialPort;
int fileFlag;

File outfile;
FileOutputStream outputFile;
/** The port we're normally going to use. */
private static final String PORT_NAMES[] = {
"COM5", // Windows
"COM4",
"COM3",
"COM1"
};

70
private static String portName;
/** Buffered input stream from the port */
private InputStream input;
/** The output stream to the port */
private OutputStream output;
/** Milliseconds to block while waiting for port open */
private static int TIME_OUT = 2000;
/** Default bits per second for COM port. */
private static int DATA_RATE = 9600;

public String initialize(String portname,int datRate) {

String initializeresult="";
portName=portname;
DATA_RATE=datRate;
CommPortIdentifier portId = null;
Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();

// iterate through, looking for the port

while (portEnum.hasMoreElements()) {
CommPortIdentifier currPortId = (CommPortIdentifier)
portEnum.nextElement();
//for (String portName : PORT_NAMES) {
if (currPortId.getName().equals(portName)) {
portId = currPortId;
initializeresult="Port"+portname+" Detected\n";
break;
}
//}
}

if (portId == null) {
initializeresult="Could not find " +portName+" port.";
return initializeresult;
}

71
 try {
// open serial port, and use class name for the appName.
serialPort = (SerialPort) portId.open(this.getClass().getName(),
TIME_OUT);

// set port parameters

serialPort.setSerialPortParams(DATA_RATE,
SerialPort.DATABITS_8,
SerialPort.STOPBITS_1,
SerialPort.PARITY_NONE);

// open the streams

input = serialPort.getInputStream();
output = serialPort.getOutputStream();

// add event listeners

serialPort.addEventListener(this);
serialPort.notifyOnDataAvailable(true);

} catch (Exception e) {
initializeresult+=e.toString()+"\n";
}
return initializeresult;
}
public void transmit(byte [] msg){
try {
output.write(msg);

} catch (IOException ex) {

Logger.getLogger(SerialTest.class.getName()).log(Level.SEVERE, null, ex);
}
}

72
public synchronized void close() {
if (serialPort != null) {
serialPort.removeEventListener();
serialPort.close();
}
}

/*
* Handle an event on the serial port. Read the data and print it.
*/
public synchronized void serialEvent(SerialPortEvent oEvent) {
if (oEvent.getEventType() == SerialPortEvent.DATA_AVAILABLE)
{
try {
int available = input.available();
System.out.println("avaliable data:\t"+available);
byte chunk[] = new byte[available];
input.read(chunk, 0, available);
String msg=new String(chunk);
System.out.println(msg);
if(msg.compareTo("~~~~~")==0 && fileFlag==0){
System.out.println("File Transfer");
// Thread.sleep(1000);
fileFlag=1;
}
else if(fileFlag==1 && msg.compareTo("~~~~~")!=0){
System.out.println("File Name:\t"+msg);
outfile=new File(msg);
outputFile=new FileOutputStream(outfile);
fileFlag=2;
}
else if(fileFlag==2){
if(msg.compareTo("~~~~~")==0){

73
 System.out.println("File Transfer Completes");
outputFile.close();
fileFlag=0;
}
else{
outputFile.write(chunk);
}
//System.out.println(msg);
}
else{
new MyMain().getMsg(chunk);
}
} catch (Exception e) {
System.err.println(e.toString());
}
}

if(oEvent.getEventType()==SerialPortEvent.OUTPUT_BUFFER_EMPTY){
System.out.println("rpam");
}
// Ignore all the other eventTypes, but you should consider the other
ones.
}

74
 APPENDIX C:
BILL OF MATERIALS

Name Quantity Price

1. Printed circuit Board 4 1390 INR
2. XBEE 2 3233 INR
3. FT232R 2 700 INR
4. ATmega168 2 700 INR
5. LM2937 2 70 INR
6. Arduino Board 1 1400 INR
7. USB Cable 2 120 INR
8. Prototype PCB 2 300 INR
9. 1k Resistor SMD – 1206 16 16 INR
10. 20 MHz XTAL 2 40 INR
11. Male Header 3 48 INR
12. Push Switch 2 10 INR
13. LED SMD – 1206 12 36 INR
14. Capacitor SMD – 100n -
10 10 INR
1206
15. Capacitor – 0.1uF 4 8 INR
16. Miscellaneous - 200 INR
17. Jumper 12 24 INR
18. 5V Battery 1 200 INR
Total 8512 INR

75
 APPENDIX D:
RESOURCES

Resources Used:
• In System Programmer (For Programming of ATmega168)
• 2 Computer Terminals
• Soldering Iron
• Solder
• Flux
• Pliers
• Multimeter

Software Tools Used:

• WinAVR - For Microcontroller Programming
• JAVA – JRE and JDK - For GUI Development
• NetBeans IDE 6.8 - For GUI Development
• FTDI USB Drivers (www.ftdichip.com) - FT232R IC Drivers
• FT_PROG v1.3.1 (www.ftdichip.com) - Testing FT232R IC
• X-CTU (www.digi.com) - Testing XBEE Modules
• Arduino_Software_V_0018 (www.arduino.cc) – For Programming
Microcontroller
• Eagle-5.7.0 - For PCB Layout Design
• Eagle3D - 3D Simulated view of PCB
• POVray - 3D PCB diagram generator
• AVRdude - To burn Microcontroller

76
 APPENDIX E:
STEPS TO RUN HARDWARE
• Connect Node to PC using USB cable
• Install FTDI USB Drivers
• Select Jumper settings for XBEE Configuration. XBEE status LED is blinking.
• Run X-CTU Software and select appropriate Baud Rate and other settings
• Now select Jumper settings for Controller programming, Using USB programmer
program the controller as per the application requirement.
• Run GUI – WSN 1.0
• Click on INITIALIZE the hardware. It will scan the device and will automatically
update COM port.
• Transmit and Receive data…..

77
 IEEE CODE OF ETHICS

We, the members of the IEEE, in recognition of the importance of our technologies in
affecting the quality of life throughout the world, and in accepting a personal obligation
to our profession, its members, and the communities we serve, do hereby commit
ourselves to the highest ethical and professional conduct and agree:

1. To accept responsibility in making decisions consistent with the safety, health and
welfare of the public, and to disclose promptly factors that might endanger the public
of the environment;
2. To avoid real or perceived conflicts of interest whenever possible, and to disclose
them to affected parties when they do exist;
3. To be honest and realistic in stating claims or estimates based on available data;
4. To reject bribery in all its forms;
5. To improve on the understanding of technology, its appropriate application, and
potential consequences;
6. To maintain and improve our technical competencies and to undertake technological
tasks for others only if qualified by training or experience, or after full disclosure of
pertinent limitations;
7. To seek, accept and offer honest criticism of technical work, to acknowledge and
correct errors, and to credit properly the contributions of others;
8. To treat fairly all persons regardless of such factors as race, religion, gender,
disability, age, or national origin;
9. To avoid injuring others, their property, reputation, or employment by false or
malicious action;
10. To assist colleagues and co-workers in their professional development and to support
them in following this code of ethics.

The IEEE code of ethics applies in multiple ways to our Minor Project experience. First,
being honest and realistic in stating claims or estimates was extremely important to our
project’s scope. Since our research will serve as background knowledge for other
researchers in this area, we strived not to exaggerate our findings. Being conservative in
estimates is a practice that every engineer should adopt, not just IEEE members.

Furthermore, as we often presented the progress of our project work to faculty members
of Nirma University, we were put in positions to give and receive constructive criticisms.
It was important for us that these criticisms be received in a professional manner.

Finally, our project focused on improving the understanding of technology and its
appropriate applications. By writing this detailed report, we are furthering the
understanding of the technology we have researched and making it easier for other
engineers to understand our project.

78