Final Report wireless sensor nettwork

8/9/2019 Final Report wireless sensor nettwork

1/44

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 likesecurity, 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


2/44

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


3/44

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


4/44

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


5/44

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


6/44

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


7/44

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 enablingwireless communication, data packet formation, data packet decoding, data forwarding and

7


8/44

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


9/44

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


10/44

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


11/44

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


12/44

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 containsFIFO_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


13/44

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


14/44

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

14


15/44

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


16/44

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 Channels7 Differential Channels in TQFP Package Only

16


17/44

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 0C to 70C. The MAX232I is characterized for operation from 40C to

85C.

17


18/44

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/44

19


20/44

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


21/44

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


22/44

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


23/44

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 totransfer the 0b00110010 (0x32) data to the master. By activating the CS (chip select) pin on

23


24/44

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


25/44

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 projectwe 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


26/44

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


27/44


28/44

28


29/44

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


30/44

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-rangehuman 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


31/44

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


32/44

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


33/44

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


34/44

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


35/44

APPENDIX A: PCB LAYOUTS

Base Station

PCB Layout for Base Station

Sensor Node

PCB Layout for Sensor Node

35


36/44

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


37/44

APPENDIX B: SOFTWARE SCREENSHOTS

SmartRF Studio

Screenshot of Texas Instruments SmartRF Studio software

Screenshot of Texas Instruments SmartRF Studio software

37


38/44

HyperTerminal

Screenshot of HyperTerminal for serial communication with computer terminal

Setting up connection between HyperTerminal and computer terminal

38


39/44

Configuring HyperTerminal for serial communication with computer terminal

39


40/44

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


41/44

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


42/44

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


43/44

}

char SPI_SlaveReceive(void)

{

/* Wait for reception complete */

while(!(SPSR & (1


44/44

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 obligationto our profession, its members, and the communities we serve, do hereby commitourselves 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, andpotential 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 ofpertinent limitations;

7. To seek, accept and offer honest criticism of technical work, to acknowledge andcorrect 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

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

Date post:	30-May-2018
Category:	Documents
Upload:	rupam-vaghasiya
View:	218 times
Download:	0 times

Final Report wireless sensor nettwork

Documents