Chapter 1

INTRODUCTION

1.1. Overview of Wireless Sensor Networks

Sensor networks become 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
working collaboratively to achieve a common objective. A WSN has one or more sinks [1]
(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,

1
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,
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.

2
 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).
• 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.

A five layer WSN model [2] 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.

Fig. 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
organization can be provided using a base station (sink) that serves as a center of a polar

3
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.

4
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 on an LCD as well as a computer
terminal. There may be one or more different sensors for various measureable physical

5
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 designed hardware must be meant for general purposes so that implementations of
TinyOS, LEACH protocol and SO-TDMA protocol may be tested on the hardware. For this
purpose the components are required to be universally accepted as standard and should
provide flexibility in terms of their use. Manipulation of their parameters should ease the
design of any application without substantial changes in the fabricated hardware.

6
 Chapter 2
HARDWARE DESCRIPTION

2.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.

2.2. Block Diagrams

2.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

7
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 CC2500 RF IC using SPI. The microcontroller is also
interfaced with a computer terminal using the USB

Fig. 2.1. Block Diagram for Base Station

and RS232 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.

2.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
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

8
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. Various protocols exist for such decision making, e.g.
LEACH.

Fig. 2.2. Block diagram for 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.

2.3. Hardware Components

2.3.1. CC2500 Transceiver Module

PO-FTR127B is a CC2500 based FSK/MSK Transceiver module. It provide extensive

hardware support for packet handling, data buffering, burst transmissions, clear channel
assessment, link quality indication and wake on radio. Its data stream can be Manchester
coded by the modulator and decoded by the demodulator. It has a high performance and
easily to design a product. It can be used in 2400-2483.5MHz ISM/SRD band systems,
Consumer Electronics, Wireless game controllers, Wireless audio wireless KB/Mouse and
others wireless systems.

9
 Fig. 2.3. Snapshot of the CC2500 transceiver module

It supports data transmission at 2.4GHz using one of these modulation techniques: Frequency
Shift Keying/Minimum Shift Keying/Amplitude Shift Keying/On-Off Keying. Following is
the internal block diagram of the CC2500 package.

Fig. 2.4. Internal block diagram of CC2500

The following notable features drive the choice of CC2500 over other transceiver modules:
RF Performance
• High sensitivity (–104 dBm at 2.4 kBaud, 1% packet error rate)
• Low current consumption (13.3 mA in RX, 250 kBaud, input well above sensitivity limit)
10
• Programmable output power up to +1 dBm
• Excellent receiver selectivity and blocking performance
• Programmable data rate from 1.2 to 500 kBaud
• Frequency range: 2400 – 2483.5 MHz

Analog Features
• OOK, 2-FSK, GFSK, and MSK supported
• Suitable for frequency hopping and multichannel systems due to a fast settling frequency
synthesizer with 90 us settling time
• Automatic Frequency Compensation (AFC) can be used to align the frequency
synthesizer to the received centre frequency
• Integrated analog temperature sensor

Digital Features
• Flexible support for packet oriented systems: On-chip support for sync word detection,
address check, flexible packet length, and automatic CRC handling
• Efficient SPI interface: All registers can be programmed with one “burst” transfer
• Digital RSSI output
• Programmable channel filter bandwidth
• Programmable Carrier Sense (CS) indicator
• Programmable Preamble Quality Indicator (PQI) for improved protection against false
sync word detection in random noise
• Support for automatic Clear Channel Assessment (CCA) before transmitting (for listen-
before-talk systems)
• Support for per-package Link Quality Indication (LQI)
• Optional automatic whitening and de-whitening of data

Low-Power Features
• 400 nA SLEEP mode current consumption
• Fast startup time: 240 us from SLEEP to RX or TX mode (measured on EM design)
• Wake-on-radio functionality for automatic low-power RX polling
• Separate 64-byte RX and TX data FIFOs (enables burst mode data transmission)

11
Popular Applications
• 2400-2483.5MHz ISM/SRD band systems
• Consumer electronics
• Wireless game controllers
• Wireless audio
• Wireless keyboard and mouse

Interfacing CC2500
When the header byte, data byte or, command strobe is sent on the SPI interface, the chip
status byte is sent by the CC2500 on the SO pin. The status byte contains key status signals,
useful for the MCU. The first bit, s7, is the CHIP_RDYn signal; this signal must go low
before the first positive edge of SCLK. The CHIP_RDYn signal indicates that the crystal is
running. Bits 6, 5, and 4 comprise the STATE value. This value reflects the state of the chip.
The XOSC and power to the digital core is on in the IDLE state, but all other modules are in
power down. The frequency and channel configuration should only be updated when the chip
is in this state. The RX state will be active when the chip is in the receive mode. Likewise,
TX is active when the chip is transmitting. The last four bits (3:0) in the status byte contains
FIFO_BYTES_AVAILABLE. For read operations (the R/W bit in the header byte is set to
1), the FIFO_BYTES_AVAILABLE field contains the number of bytes available for reading
from the RX FIFO. For write operations (the R/W bit in the header byte is set to 0), the
FIFO_BYTES_AVAILABLE field contains the number of bytes that can be written to the
TX FIFO. When FIFO_BYTES_AVAILABLE=15, 15 or more bytes are available/free.

Writing into Registers

The configuration registers of the CC2500 are located on SPI addresses from 0x00 to 0x2E. It
is highly recommended to use SmartRF Studio to generate optimum register settings. All
configuration registers can be both written to and read. The R/W bit controls if the register
should be written to or read.
When writing to registers, the status byte is sent on the SO pin each time a header byte or
data byte is transmitted on the SI pin. When reading from registers, the status byte is sent on
the SO pin each time a header byte is transmitted on the SI pin. Registers with consecutive
addresses can be accessed in an efficient way by setting the burst bit (B) in the header byte.

12
The address bits (A5 – A0) set the start address in an internal address counter. This counter is
incremented by one each new byte (every 8 clock pulses). The burst access is either a read or
a write access and must be terminated by setting CSn high. For register addresses in the range
0x30-0x3D, the burst bit is used to select between status registers, burst bit is one, and
command strobes, burst bit is zero. Because of this, burst access is not available for status
registers and they must be accessed one at a time. The status registers can only be read.

Reading from Registers

When reading register fields over the SPI interface while the register fields are updated by the
radio hardware (e.g. MARCSTATE or TXBYTES), there is a small, but finite, probability
that a single read from the register is being corrupt. As an example, the probability of any
single read from TXBYTES being corrupt, assuming the maximum data rate is used, is
approximately 80 ppm.
The following pages provide references for optimal configuration of the CC2500 module.
Various register values have been listed.

SPI Address Space

Table 2.1. SPI Address Space

13
Table 2.2. Register values for configuration of CC2500 in various modes

14
2.3.2. ATmega16L Microcontroller

The ATmega16L 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
designer 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.

Fig. 2.5. Block Diagram of ATmega16L microcontroller

15
The following features drive the choice of ATmega16L over other available microcontrollers:
• High-performance, Low-power AVR 8-bit Microcontroller
• Advanced RISC Architecture
 131 Powerful Instructions – Most Single-clock Cycle Execution
 32 x 8 General Purpose Working Registers
 Fully Static Operation
 Up to 16 MIPS Throughput at 16 MHz
 On-chip 2-cycle Multiplier
• Non-volatile Program and Data Memories
 16K Bytes of In-System Self-Programmable Flash
Endurance: 10,000 Write/Erase Cycles
 Optional Boot Code Section with Independent Lock Bits
In-System Programming by On-chip Boot Program
True Read-While-Write Operation
 512 Bytes EEPROM
Endurance: 100,000 Write/Erase Cycles
 1K Byte Internal SRAM
 Programming Lock for Software Security
• JTAG (IEEE std. 1149.1 Compliant) Interface
 Boundary-scan Capabilities According to the JTAG Standard
 Extensive On-chip Debug Support
 Programming of Flash, EEPROM, Fuses, and Lock Bits through the JTAG
Interface
• Peripheral Features
 Two 8-bit Timer/Counters with Separate Prescalers and Compare Modes
 One 16-bit Timer/Counter with Separate Prescaler, Compare Mode and Capture
Mode
 Real Time Counter with Separate Oscillator
 Four PWM Channels
 8-channel, 10-bit ADC
8 Single-ended Channels
7 Differential Channels in TQFP Package Only

16
 2 Differential Channels with Programmable Gain at 1x, 10x, or 200x
 Byte-oriented Two-wire Serial Interface
 Programmable Serial USART
 Master/Slave SPI Serial Interface
 Programmable Watchdog Timer with Separate On-chip Oscillator
 On-chip Analog Comparator
• Special Microcontroller Features
 Power-on Reset and Programmable Brown-out Detection
 Internal Calibrated RC Oscillator
 External and Internal Interrupt Sources
 Six Sleep Modes: Idle, ADC Noise Reduction, Power-save, Power-down, Standby
and Extended Standby
• I/O and Packages
 32 Programmable I/O Lines
 40-pin PDIP, 44-lead TQFP, and 44-pad MLF
• Operating Voltages
 2.7 - 5.5V for ATmega16L
 4.5 - 5.5V for ATmega16
• Speed Grades
 0 - 8 MHz for ATmega16L
 0 - 16 MHz for ATmega16

2.3.3. MAX 232 IC

The MAX232 device is a dual driver/receiver that includes a capacitive voltage generator to
supply EIA-232 voltage levels from a single 5 V supply. Each receiver converts EIA-32
inputs to 5 V TTL/CMOS levels. These receivers have a typical threshold of 1.3 V and a
typical hysteresis of 0.5 V, and can accept + 30 V inputs. Each driver converts TTL/CMOS
input levels into EIA-232 levels. The driver, receiver, and voltage-generator functions are
available as cells in the Texas Instruments LinASIC library. The MAX232 is characterized
for operation from 0°C to 70°C. The MAX232I is characterized for operation from –40°C to
85°C.

17
 Fig. 2.6. MAX232 package: Top view and Logical layout

The following features drive the choice of MAX232:

• Operates With Single 5 V Power Supply
• LinBiCMOSE Process Technology
• Two Drivers and Two Receivers
• + 30 V Input Levels
• Low Supply Current – 8 mA Typical
• Meets or Exceeds TIA/EIA-232-F and ITU Recommendation V.28
• Designed to be Interchangeable With Maxim MAX232
• Applications
 TIA/EIA-232-F
 Battery-Powered Systems
 Terminals
 Modems
 Computers
• ESD Protection Exceeds 2000 V per MIL-STD-883, Method 3015.
• Package Options Include Plastic Small-Outline (D, DW) Packages and Standard Plastic
(N) DIPs.

18
19
 Chapter 3
SOFTWARE DESCRIPTION

3.1. Serial Communication and SPI Interface

Two main types of on-board communication occur in the project. Serial communication over
the RS232 standard is required to interface the Base Station with a computer terminal. The
other is the Serial Peripheral Interface (SPI) which is required to configure and operate the
CC2500 module. SPI is required at the Base Station as well as the Sensor Node.

3.1.1. Serial Data Communication

In telecommunications, RS-232 (Recommended Standard 232) is a standard for serial binary

data signals connecting between a Data Terminal Equipment (DTE) and a Data Circuit-
terminating Equipment (DCE). It is commonly used in computer serial ports. A similar ITU-
T standard is V.24.
In RS-232, user data is sent as a time-series of bits. Both synchronous and asynchronous
transmissions are supported by the standard. In addition to the data circuits, the standard
defines a number of control circuits used to manage the connection between the DTE and
DCE. Each data or control circuit only operates in one direction i.e. signaling from a DTE to
the attached DCE or the reverse. Since transmit data and receive data are separate circuits, the
interface can operate in a full duplex manner, supporting concurrent data flow in both
directions. The standard does not define character framing within the data stream, or
character encoding.

Signals used in RS232 Serial Communication

Commonly-used signals are:
 Transmitted Data (TxD)
Data sent from DTE to DCE.
 Received Data (RxD)
Data sent from DCE to DTE.
 Request To Send (RTS)

20
 Asserted (set to logic 0, positive voltage) by DTE to prepare DCE to receive data.
This may require action on the part of the DCE, e.g. transmitting a carrier or reversing
the direction of a half-duplex channel.
 Ready To Receive (RTR)
Asserted by DTE to indicate to DCE that DTE is ready to receive data. If in use, this
signal appears on the pin that would otherwise be used for Request To Send, and the
DCE assumes that RTS is always asserted; see RTS/CTS handshaking for details.
 Clear To Send (CTS)
Asserted by DCE to acknowledge RTS and allow DTE to transmit. This signaling was
originally used with half-duplex modems and by slave terminals on multidrop lines:
The DTE would raise RTS to indicate that it had data to send, and the modem would
raise CTS to indicate that transmission was possible.
 Data Terminal Ready (DTR)
Asserted by DTE to indicate that it is ready to be connected. If the DCE is a modem,
this may "wake up" the modem, bringing it out of a power saving mode. This
behaviour is seen quite often in modern PSTN and GSM modems. When this signal is
de-asserted, the modem may return to its standby mode, immediately hanging up any
calls in progress.
 Data Set Ready (DSR)
Asserted by DCE to indicate the DCE is powered on and is ready to receive
commands or data for transmission from the DTE. For example, if the DCE is a
modem, DSR is asserted as soon as the modem is ready to receive dialling or other
commands; DSR is not dependent on the connection to the remote DCE (see Data
Carrier Detect for that function). If the DCE is not a modem (e.g. a null modem cable
or other equipment), this signal should be permanently asserted (set to 0), possibly by
a jumper to another signal.
 Data Carrier Detect (DCD)
Asserted by DCE when a connection has been established with remote equipment.
 Ring Indicator (RI)
Asserted by DCE when it detects a ring signal from the telephone line.

21
3.1.2. Serial Peripheral Interface (SPI)

The Serial Peripheral Interface Bus or SPI bus is a synchronous serial data link standard
named by Motorola that operates in full duplex mode. Devices communicate in master/slave
mode where the master device initiates the data frame. Multiple slave devices are allowed
with individual slave select (chip select) lines. Sometimes SPI is called a "four wire" serial
bus, contrasting with three, two, and one wire serial buses.

Features of SPI that render it superior to other standards:

 Full-duplex
 Synchronous
 Three wire
 Up to 16Mhz clock
 LSB First or MSB First Data Transfer
 Seven Programmable Bit Rates
 End of Transmission Interrupt Flag
 Write Collision Flag Protection
 Wake-up from Idle Mode
 Double Speed (CK/2) Master SPI Mode
 Four interface pins:
 SS_N slave select (PB0)
 SCK serial clock (PB1)
 MOSI master out slave in (PB2)
 MISO master in slave out (PB3)
 Three registers:
 SPCR control register
 SPSR status register
 SPDR data register

The standard Serial Peripheral Interface use minimum three line ports for communicating
with the SPI devices, the chip select pin (CS) is always connected to the ground (enable). If

22
more the one SPI devices connected to the same bus, then we need four ports and use the
fourth port (SS pin on the ATMega16L microcontroller) to select the target SPI device before
start to communicate with it.

Fig. 3.1. SPI Master and SPI Slave Device connection

Fig. 3.2. SPI Master and Slave Interconnection

From the SPI master and slave interconnection diagram above you can see that the SPI
peripheral use the shift register to transfer and receive the data, for example the master want
to transfer 0b10001101 (0x8E) to the slave and at the same time the slave device also want to
transfer the 0b00110010 (0x32) data to the master. By activating the CS (chip select) pin on

23
the slave device, now the slave is ready to receive the data. On the first clock cycle both
master and slave shift register will shift their register content one bit to the left; the SPI slave
will receive the first bit from the master on its LSB register while at the same time the SPI
master will receive its first data from slave on its LSB register.

Fig. 3.3. SPI Master and Slave Data Transfer Diagram

AVR Serial Peripheral Interface

The principal operation of the SPI is simple but rather than to create our own bit-bang
algorithm to send the data, the built-in SPI peripheral inside the Atmel AVR ATMega16L
microcontroller make the SPI programming easier. All that is required is to pass on the data
to the SPI data register (SPDR) and let the AVR ATMega16L SPI peripheral do the job of
sending the data to and reading the data from the SPI slave device. To initialize the SPI
peripheral inside the ATMega16L microcontroller we must enable this device as the SPI
master and set the master clock frequency using the SPI Control Register (SPCR) and SPI

24
Status Register (SPST). More detailed information can be found in the AVR ATMega16L
datasheet.

Fig. 3.4. ATmega SPCR and SPSR Registers

The first thing to do before using the SPI peripheral is to configure the SPI port for SPI
master operation i.e. configure MOSI (PB3) and SCK (PB5) as output ports and MISO (PB4)
as the input port, while SS (PB2) can be any port for SPI master operation but in this project
we have used PB2 to select the SPI slave device. The C code used to configure this SPI port
has been provided in the Appendix C.

3.2. Compiler and Simulation Software

The WinAVR software tool was used for writing, compiling, debugging and dumping the C
codes for Base Station and Sensor Node. Optimum values for the CC2500 registers for

25
different configurations were obtained from the SmartRF Studio software developed by
Texas Instruments.

3.2.1. WinAVR

WinAVR is a suite of executable, open source software development tools for the Atmel
AVR series of RISC microcontrollers hosted on the Windows platform. It includes the GNU
GCC compiler for C and C++.
WinAVR contains all the tools for developing on the AVR. This includes avr-gcc (compiler),
avrdude (programmer), avr-gdb (debugger) etc. WinAVR comes with Programmers Notepad
UI by default. It is very powerful editor, but if you want more robust UI with better project
management abilities you can try Java based Eclipse IDE. It is universal open source IDE
which supports almost any compiler by using plugins. Eclipse has some nice features that
make it attractive, like Subversion integration, code completion in editor.

3.2.2. SmartRF Studio

SmartRF Studio is a Windows application that can be used to evaluate and configure Low
Power RF ICs from Texas Instruments. It is a very useful tool for exploring and gaining
knowledge of the RF-IC products. This software helps the designers of RF systems to easily
evaluate the RF-ICs at an early stage in the design process. It is especially useful for
generation of configuration registers, for practical testing of the RF system and for finding
optimized external component values.

Although various compilers are available for the development of codes for ATmega series
microcontrollers, WinAVR has the following features that render it superior:
• Link tests. Send and Receive packets between nodes.
• Packet Error Rate (PER) tests.
• Communication with evaluation boards through USB port or the parallel port.
• Up to eight USB devices are supported on a single computer.
• Support for Windows 98, Windows 2000 and Windows XP.
• Normal view with preferred register settings.
• Register view with possibilities to read and write each individual register. Each
register given with detailed information.
26
 • Save/Open configuration data from file.
• Save/Load register settings from file.
• Export/Import register values from text file.
• Exports register settings into a C compatible software structure.
3.3. Protocols: LEACH

Heinzelman, Chardrakasan, and Balakrishnan proposed Low-Energy Adaptive Clustering

Hierarchy (LEACH) [6], which is an energy-efficient communication protocol for wireless
micro-sensor networks. The application scenario is,

• The base station is fixed and located far from the sensors.
• All nodes in the network are homogeneous and energy-constrained.

LEACH is a dynamic clustering method. In this method, time is partitioned into fixed
intervals with equal length. At the beginning of each interval, each sensor becomes a cluster
head with some predefined probability. The cluster heads then broadcast messages to their
neighbours. Other sensors receive messages and join a cluster by choosing the cluster head
with the strongest signal. During the interval, cluster members send information to their
cluster head. The cluster heads aggregate the information, compress the information, and
route the information to the remote access point. Once the interval ends the whole clustering
process restarts. Hence, the clusters and cluster heads are not fixed. Since the cluster heads
consume more energy than cluster members in radio transmission, the rotation of cluster
heads makes energy consumption more evenly across all sensors in the network. Therefore,
the sensor network can last longer. Heinzelman et al. compare LEACH with direct
transmission, minimum energy transmission, and static clustering. The simulation results
show that the LEACH can extend the sensor network life up to eight times longer than its
closest competitors.

27
28
 Chapter 4
APPLICATIONS
4.1. Applications

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

1. 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.
- Embedded Network Sensing (ENS) [2] will provide field data at sufficient densities to
develop predictive models of structure, foundation, soil response.

2. 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.

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

29
• 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.

4. Context Aware Home

The goal of research on context-aware buildings [5] 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.
• Complete security systems including emergency call out alarms for burglars, fire, or
injury with a complete awareness of the home owners wherever they are.

30
 Fig. 4.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.

31
 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 95% of the time. Out of an approximate 50 times that the hardware was
switched on for operation, it functioned as per requirement on 45 occasions. On the 5
instances that the hardware did not function, it was found that there was due to
inappropriate operation rather than a design flaw.

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:

Mode Current Consumption

Transmit 21.5 mA
Receive 19.6 mA
Sleep 160 µA
Table 4.1. Current consumption in various modes

Range
During testing a range of 20 m to 50 m was achieved. This is less compared to the ideal
range of 200 m to 400 m that should be available. 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.

32
 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 more
sophisticated fabrication of the hardware this design may be used to implement 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.

33
 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] Nirupama Bulusu, Sanjay Jha, “Wireless Sensor Networks: A Systems Perspective”,
Artech House, 2005.
[4] Nitaigour P. Mahalik, “Sensor Networks and Configuration”, Springer Science Media,
2007.
[5] Sven Meyer, Andry Rakotonirainy, “A Survey of Research on Context-Aware Homes”.
[6] Dezhen Song, “Probabilistic Modeling of Leach Protocol and Computing Sensor Energy
Consumption Rate in Sensor Networks”, February 22, 2005.
[7] Raja Jurdak, “Wireless Ad Hoc and Sensor Networks”, Springer 2007.
[8] C. S. Raghavendra, Krishna M. Sivalingam, Taieb Znati, “Wireless Sensor Networks”,
Kluwer Academic Publishers, 2004.
[9] Xiangyang Li, “Wireless Ad Hoc and Sensor Networks”, Cambridge University Press,
2008.
[10] Anna Hac, “Wireless Sensor Network Designs”, Wiley Publications, 2003.
[11] Kazem Sohraby, Daniel Minoli, Taieb Znati, “Wireless Sensor Networks Technology,
Protocols, and Applications”, Wiley Publications, 2007.
[12] Anurag Kumar, D. Manjunath, Joy Kuri, “Wireless Networking”, Morgan Kaufmann
Publishers, 2008.
[13] Roberto Verdone, Davide Dardari, Gianluca Mazzini, Andrea Conti, “Wireless Sensor
and Actuator Networks”.
[14] Shashi Phoha, Thomas LaPorta, Christopher Griffin, “Sensor Network Operations”,
IEEE Press, 2006.
[15] Sotiris Nikoletseas, José D.P. Rolim, “Algorithmic Aspects of Wireless Sensor
Networks”, Springer Publication, July 16, 2004.
[16] DorotheaWagner, RogerWattenhofer, “Algorithms for Sensor and Ad Hoc
Networks”, Springer Publication, 2007.

34
 APPENDIX A: PCB LAYOUTS
Base Station

PCB Layout for Base Station

Sensor Node

PCB Layout for Sensor Node

35
Final proposed design – Layer1

PCB Layout for final proposed design with ATmega128L – Layer 1

Final proposed design – Layer2

PCB Layout for final proposed design with ATmega128L – Layer 2

36
 APPENDIX B: SOFTWARE SCREENSHOTS
SmartRF Studio

Screenshot of Texas Instruments SmartRF Studio software

Screenshot of Texas Instruments SmartRF Studio software

37
HyperTerminal

Screenshot of HyperTerminal for serial communication with computer terminal

Setting up connection between HyperTerminal and computer terminal

38
Configuring HyperTerminal for serial communication with computer terminal

39
 APPENDIX C: C CODES
Code for Register Import from CC2500 using SmartRF

/* Product = CC2500 */
/* Chip version = E */
/* Crystal accuracy = 10 ppm */
/* X-tal frequency = 26 MHz */
/* RF output power = 0 dBm */
/* RX filterbandwidth = 541.666667 kHz */
/* Phase = 1 */
/* Datarate = 249.938965 kbps */
/* Modulation = (7) MSK */
/* Manchester enable = (0) Manchester disabled */
/* RF Frequency = 2432.999908 MHz */
/* Channel spacing = 199.951172 kHz */
/* Channel number = 0 */
/* Optimization = Sensitivity */
/* Sync mode = (3) 30/32 sync word bits detected */
/* Format of RX/TX data = (0) Normal mode, use FIFOs for RX and TX */
/* CRC operation = (1) CRC calculation in TX and CRC check in RX enabled */
/* Forward Error Correction = (0) FEC disabled */
/* Length configuration = (1) Variable length packets, packet length configured by the first
received byte after sync word. */
/* Packetlength = 255 */
/* Preamble count = (2) 4 bytes */
/* Append status = 1 */
/* Address check = (0) No address check */
/* FIFO autoflush = 0 */
/* Device address = 0 */
/* GDO0 signal selection = ( 6) Asserts when sync word has been sent / received, and de-
asserts at the end of the packet */
/* GDO2 signal selection = (11) Serial Clock */

40
void Smart_RfConfig(unsigned int rfPaTable)
{
SPI_Write(CC2500_FSCTRL1, 0x09/*fsctrl1*/); // Frequency synthesizer control.
SPI_Write(CC2500_FSCTRL0, 0x00/*fsctrl0*/); // Frequency synthesizer control.
SPI_Write(CC2500_FREQ2, 0x5D/*freq2*/); // Frequency control word, high byte.
SPI_Write(CC2500_FREQ1, 0x93/*freq1*/); // Frequency control word, middle byte.
SPI_Write(CC2500_FREQ0, 0xB1/*freq0*/); // Frequency control word, low byte.
SPI_Write(CC2500_MDMCFG4, 0x2D/*mdmcfg4*/); // Modem configuration.
SPI_Write(CC2500_MDMCFG3, 0x3B/*mdmcfg3*/); // Modem configuration.
SPI_Write(CC2500_MDMCFG2, 0x73/*mdmcfg2*/); // Modem configuration.
SPI_Write(CC2500_MDMCFG1, 0x22/*mdmcfg1*/); // Modem configuration.
SPI_Write(CC2500_MDMCFG0, 0xF8/*>mdmcfg0*/); // Modem configuration.
SPI_Write(CC2500_CHANNR, 0x00/*channr*/); // Channel number.
SPI_Write(CC2500_DEVIATN, 0x01/*deviatn*/); // Modem deviation setting (when
FSK modulation is enabled).
SPI_Write(CC2500_FREND1, 0xB6/*frend1*/); // Front end RX configuration.
SPI_Write(CC2500_FREND0, 0x10/*frend0*/); // Front end RX configuration.
SPI_Write(CC2500_MCSM0, 0x18/*mcsm0*/); // Main Radio Control State Machine
configuration.
SPI_Write(CC2500_FOCCFG, 0x1D/*foccfg*/); // Frequency Offset Compensation
Configuration.
SPI_Write(CC2500_BSCFG, 0x1C/*bscfg*/); // Bit synchronization Configuration.
SPI_Write(CC2500_AGCCTRL2, 0xC7/*agcctrl2*/); // AGC control.
SPI_Write(CC2500_AGCCTRL1, 0x00/*agcctrl1*/); // AGC control.
SPI_Write(CC2500_AGCCTRL0, 0xB2/*agcctrl0*/); // AGC control.
SPI_Write(CC2500_FSCAL3, 0xEA/*fscal3*/); // Frequency synthesizer calibration.
SPI_Write(CC2500_FSCAL2, 0x0A/*fscal2*/); // Frequency synthesizer calibration.
SPI_Write(CC2500_FSCAL1, 0x00/*fscal1*/); // Frequency synthesizer calibration.
SPI_Write(CC2500_FSCAL0, 0x11/*fscal0*/); // Frequency synthesizer calibration.
SPI_Write(CC2500_FSTEST, 0x59/*fstest*/); // Frequency synthesizer calibration.
SPI_Write(CC2500_TEST2, 0x88/*test2*/); // Various test settings.
SPI_Write(CC2500_TEST1, 0x31/*test1*/); // Various test settings.
SPI_Write(CC2500_TEST0, 0x0B/*test0*/); // Various test settings.
SPI_Write(CC2500_IOCFG2, 0x0B/*iocfg2*/); // GDO2 output pin configuration.
41
 SPI_Write(CC2500_IOCFG0, 0x06/*iocfg0*/); // GDO0 output pin configuration.
SPI_Write(CC2500_PKTCTRL1, 0x04/*pktctrl1*/); // Packet automation control.
SPI_Write(CC2500_PKTCTRL0, 0x05/*pktctrl0*/); // Packet automation control.
SPI_Write(CC2500_ADDR, 0x00/*addr*/); // Device address.
SPI_Write(CC2500_PKTLEN, 0xFF/*pktlen*/); // Packet length.

SPI_Write(CC2500_PATABLE | CC2500_WRITE_BURST, rfPaTable);

}

Codes for Serial Peripheral Interface

SPI Master Device
void SPI_MasterInit(void)
{
/* Set MOSI and SCK output, all others input */
DDR_SPI = (1<<DD_MOSI)|(1<<DD_SCK);
/* Enable SPI, Master, set clock rate fck/16 */
SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR0);
}
void SPI_MasterTransmit(char cData)
{
/* Start transmission */
SPDR = cData;
/* Wait for transmission complete */
while(!(SPSR & (1<<SPIF)));
}

SPI Slave Device

void SPI_SlaveInit(void)
{
/* Set MISO output, all others input */
DDR_SPI = (1<<DD_MISO);
/* Enable SPI */
SPCR = (1<<SPE);

42
}
char SPI_SlaveReceive(void)
{
/* Wait for reception complete */
while(!(SPSR & (1<<SPIF)));
/* Return data register */
return SPDR;
}

43
 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.

44