Complete report on DATA ACQUISITION SCHEME IN WIRELESS SENSOR NETWORK

1 | P a g e

CHAPTER 1 LITERARURE SURVEY

1.1 INTRODUCTION

A Wireless Sensor Network is a network of sensors which are deployed at various locations in

surrounding to monitor physical or environmental conditions such as temperature, sound,

pressure, humidity. The data which is sensed by the sensors is then forwarded to the base station.

The sensed data can then be further used for visualisation or can be represented in the form of

graph. The development of wireless sensor networks was motivated by military applications such

as battlefield surveillance; today such networks are used in many industrial and consumer

applications, such as industrial process monitoring and control, machine health monitoring, and

so on.

The WSN is built of “nodes”- which are integral part of it. Each sensor network node has

typically several parts; a radio transceiver with an internal antenna or connection to an external

antenna a microcontroller, an electronic circuit for interfacing with the sensors and energy

source. The size and the cost of nodes are variable as it is totally dependent on the functionality,

range and complexity of different nodes. The topology of the WSNs can vary from a simple star

network to an advanced multi-hop wireless mesh network. The propagation technique between

the hops of the network can be routing or flooding.

There has been tremendous increase in the use of wireless sensor network as it is exploring each

and every field. WSN has widely contributed to “Internet of Things”- this mainly deals with

synchronizing the sensed data to cloud. There are endless applications of Wireless Sensor

Networks in each and every field and this can be seen form point of view of current scenario.

The information gathering is of utmost concern in WSN. As for each and every application in

WSN data aggregation (collection) is very important because all the aspects of WSN are

dependent on it. Also in large scale network reliability and efficiency should be focused because

reliability of data is very important in WSN. However, on small scale project reliability can be

handled by using various protocols.

The concept of wireless sensor networks is based on a simple equation:

Sensing + CPU + Radio = Thousands of potential applications

http://en.wikipedia.org/wiki/Star_network

http://en.wikipedia.org/wiki/Star_network

http://en.wikipedia.org/wiki/Mesh_networking

http://en.wikipedia.org/wiki/Wireless_mesh_network

http://en.wikipedia.org/wiki/Routing

http://en.wikipedia.org/wiki/Flooding_algorithm

2 | P a g e

1.2 WHAT IS WSN?

In today’s environment the evolution of technology leads to the growth of different kind of low

cost sensor technologies that are utilized in various sectors. The supporting technology turned

out to be the WIRELESS SENSOR TECHNOLOGY which is implemented with the help of

wireless sensors (hardware) deployed at various destinations anywhere in the geographical

network. These networks have the capacity to determine both the physical and ecological

features.

These deployed sensors distribute the particular data sustaining both physical as well as

ecological environments and transfer the information regardless of wires. As the main feature of

wireless technology includes its skilful nature in mechanisms like data transmitting and data

forwarding, these sensors are independent in nature and they tune to the variables such as

temperature, vibration, velocity, sound, motion etc. These networks can easily sense them and

detect them as well. These sensors are composed of four main devices viz. Sensor, Unit, Energy

source, Transceivers. It also consists of other add-ons like energy producer, position changer,

localization unit etc. This wireless node resembles the shape of coins since these are smaller in

size, this can be minimized with the technology of “micro-electro-mechanical systems”.

Fig A: Ubi-Coin: Ultra low power and coin size sensor platform based on MSP430 (CPU) and

CC2420 (RF) [Referred URL: http://uns.ajou.ac.kr/~scs/]

http://uns.ajou.ac.kr/~scs/

3 | P a g e

1.3 GENERAL FACTS ABOUT WIRELESS SENSORS

One common question arises about the range of our wireless sensors, which is really the topic of

concern. So, the ZIGBEE (described later) technology takes care of it. Its sensor range falls

between 0 km – 50 km according to its power, cost and bandwidth. So we here in our project can

obviously control the range of our sensors and hence can control the power consumption and

cost too. Due to varying features as discussed above, the processing capability can also vary

from low to high according to the parameters like bandwidth and energy transformation.

The next question asks us about the platform or the operating systems we are going to use for

proper functioning of the system. The wireless sensor network varies in a very high degree as the

functions defined for the operating system contains millions of code lines unlike wireless

networks as it can handle limited lines of code. WSN can be operated by various operating

systems like TINY OS (described later), MANTIS, SOS, NANO-RK, CONTIKI, BTNUT etc.,

but as our project deals with small scale sensing (using Jennic JN5139 micro-controller), we will

be working on Run-Time Environment, whereas with TinyOS for high performances. The

platform used will be Windows and various software applications include Jennic CodeBlocks,

Jennic Flash Programmer, Tera Term (hyperterminal).

1.4 GENERAL ARCHITECTURE OF NETWORK

The following architecture (fig A given below) depicts how the sensor nodes interact with each

other. There interaction can differ based on per hop behavior viz. Single Hop and Multi Hop. All

the leaf nodes are connected to the common intermediate nodes, so the network formed can be

either a Star or a Mesh network (topology). The data sensing is done at the remote sensors

whereas the processing is done at intermediate nodes – Clustering Nodes, if required. Finally, the

processed data is sent to the base station – Final Processing Node, where it can be visualized

using graphs, tables. The Sink (server) is alternatively known as “Remote data processing

center”. The data reporting strategy includes two methods viz. Hop-By-Hop and End-To-End

data transmission (refer Glossary) and here in our project we have adapted both of them very

effectively.

4 | P a g e

Fig B: Typical sensor network arrangements.

Ref: WIRELESS SENSOR NETWORKS Technology, Protocols,

And Applications by KAZEM SOHRABY, DANIEL MINOLI, TAIEB ZNATI

1.5 RECENT STUDY ON MAKING WSN MORE RELIABLE

1.5.1 Event-to-Sink Reliable Transport in WSNs by Özgür B. Akan, Ian F. Akyildiz

Consider a WSN where sink decides on the event features every ‘T’ time units. That means ‘T’ is

the decision interval where sink makes an informed decision based on the reports received from

the sensor nodes during that interval. Also, we assume that sink derives a reliability indicator ri at

the end of decision interval.

1. The observed reliability, ri is the number of received data packets in decision interval ‘i’ at the

sink.

2. The desired event reliability, R is the number of data packets required for reliable event

detection.

Based on the comparison of values of ri and R, appropriate actions are taken to achieve the

reliability. The reporting rate of the sensor node is defined as the number of packets sent out per

unit time by that node. The transport problem in WSN is to configure the data reporting rate f of

the sensor nodes so s to achieve the required event detection reliability, R at the sink with

minimum resource utilization.

The five characteristic regions: (η: normalized measure of reliability = r/R)

5 | P a g e

1. (NC, LR) : f < fmax and η < 1-ϵ (No Congestion, Low Reliability)

2. (NC, HR) : f ≤ fmax and η > 1+ϵ (No Congestion, High Reliability)

3. (C, HR) : f > fmax and η > 1 (Congestion, High Reliability)

4. (C, LR) : f > fmax and η ≤ 1 (Congestion, Low Reliability)

5. OOR : f < fmax and 1-ϵ ≤ η ≤ 1+ϵ (Optimal Operating Region)

The primary motive of ESRT [3] is to achieve and maintain operation in state OOR. Hence, the

aim is to configure the reporting frequency ‘f’ to achieve the desired event detection accuracy

with minimum energy expenditure. To help accomplish this, ESRT uses a congestion control

mechanism that serves the dual purpose of reliable detection and energy conservation.

In general, the network can reside in any one of the 5 states Si ϵ {(NC, LR), (NC, HR) (C, HR)

(C, LR), OOR}. Depending on the current state Si, ESRT calculates an updated reporting

frequency fi+1 which is then broadcasted to source nodes.

The algorithms of ESRT mainly run on the sink, with minimal functionality at the source nodes.

More precisely, sensor nodes only need the following two additional functionalities viz.

1. Sensor nodes must listen to the sink broadcast at the end of each decision interval and update

their reporting rates

2. Sensor nodes must deploy a simple and overhead-free local congestion detection support

mechanism

Such a graceful transfer of complexity from sensor nodes to the sink node reduces management

costs and saves on valuable sensor resources.

ESRT identifies the current state Si from

1. Reliability indicator ηi computed by the sink for decision interval i

2. A congestion detection mechanism

The detailed description of ESRT algorithm is given in Annexures at the last of report.

6 | P a g e

1.5.1 Rate-constrained Uniform Data Collection in WSNs by H. Deng , B. Zhang , J. Zheng

In a Wireless Sensor Network, it is not every time a node would report the readings to the data

processing center due to limited network resources or some other reasons. So, two different data

reporting strategies are composed viz. prediction-based reporting and temporal-based reporting.

Prediction Based Reporting:

This effective technique for data reporting has a basic ideology that if the sensor itself can

predict the reading at the sink node, then it is not mandatory to report the data at the server. An

online scheme is proposed based on compression and prediction for construction of approximate

time series which would guarantee less energy consumption. An adaptive as well a lightweight

prediction model selection scheme is proposed for sensor node to automatically determine a

statistically good performance model amongst many.

Temporal Based Reporting:

It is another efficient data reporting strategy after prediction-based reporting where a sensor node

does not report to the sink if it does not deviate from the last reported readings beyond an error

bound as well going with an assumption that all unreported readings remain unchanged. Two

different strategies are composed on behalf of this reporting strategies viz. one aims to improve

network performance i.e. the lifetime of a network with lowest possible requirement on data

quality whereas other is a vice-versa i.e. improving data quality subject to bandwidth.

Our objective is to find the rationale behind this equi-interval strategy; we have to consider one-

hop transmission for data reporting so that the server node is the neighbor of each and every

sensor node.

Here, we introduce the concept of Adaptive rate control algorithm from previous studies [4].

Data reporting is the vital part in WSN of which care should be taken. High reporting rate leads

to network congestion whereas low rate results in low bandwidth utilization. So, these both cases

should be avoided to play safe

The detailed description of Centralized Rate Adaption algorithm is given in Annexures at the last

of report.

7 | P a g e

CHAPTER 2 PROBLEM DEFINATION

2.1 PROBLEM STATEMENT

Data Acquisition Scheme in Wireless Sensor Network

2.2 CONTRIBUTION

Our role in project is to form a network of over a range of 05 km – 50 km and where the

wireless sensor nodes will be acting as leaf nodes, whereas the Remote data processing center

will be acting as a root node. Our vital need is to implement data aggregation so as to minimize

the delay occurred during acquisition of the data from the leaf nodes by omitting the processing

at each level. Our future scope includes the data storage in Cloud and data retrieval through

smartphones. The data is finally processed at sink and then displayed on UI designed using

HTML/CSS through graphs.

2.3 FEATURES OF THE PROJECT

Deploying the sensors in the environment for sensing the temperature.

Sending the sensed temperature to base station.

Topology used while sending the data:

a) End-to-End.

b) Hop-by-Hop.

On base station visualizing the data.

Storing the data to database.

Plotting graphs/calculating the average of temperature.

Extra functionality sending the sensed data directly to cloud.

CHAPTER 3 PLATFORMS &TECHNOLOGY

3.1 ZIGBEE

ZigBee is a low power spin off of Wi-Fi. It is a specification for small, low power radios based

on IEEE 802.15.4 – 2003 Wireless Personal Area Networks standard. The specification was

accepted and ratified by the “ZigBee alliance” (group of more than 300 companies including

industry majors like Philips, Mitsubishi Electric, Epson, Atmel, Texas Instruments etc.) in

December 2004.

8 | P a g e

It is ideally suited for applications requiring infrequent smaller data transfers where battery life is

an important issue. However, location estimation based on narrow band DSSS (Direct Sequence

Spread Spectrum) can achieve accuracy only in the order of several meters.

3.2 ZIGBEE vs. BLUETOOTH

When Bluetooth technology was introduced, it was thought that Bluetooth would make Wi-Fi

redundant. But the two coexist quite well today, so do many other Wireless standards like

Wireless HART and ISA100.11a. Then why would we need another WPAN standard like

ZigBee? The answer is, the application focus of ZigBee Alliance - low cost and low power for

energy efficient and cost effective intelligent devices. Moreover, ZigBee and Bluetooth have

different application focus. Despite of all their similarities, and despite the fact that both are

based on the IEEE 802.15 standards, the two are different in technology as well as scope.

Bluetooth is made with mobile phones as its center of universe enabling media transfer at rates in

excess of 1 Mbps while ZigBee is built with emphasis on low data rate control system sensors

featuring slower data of just 250 kbps.

Fig C: Basic Architecture of ZigBee (IEEE standard- 802.15.4)

9 | P a g e

CHAPTER 4 SOFTWARE REQUIREMENT SPECIFICATIONS

4. 1 REVISION HISTORY

Date Revision Description Team

15/1/15 1.0 Initial Version Rutvik Pensionwar

Pranav Tambat

Nilesh Thite

Onkar Tummanpalli

30/1/15 1.1 Version 1 Rutvik Pensionwar

Pranav Tambat

Nilesh Thite

Onkar Tummanpalli

20/2/15 2.0 Final Version Rutvik Pensionwar

Pranav Tambat

Nilesh Thite

Onkar Tummanpalli

Contents

1. Introduction

1.1. Purpose

1.2. Scope

1.3. Assumptions

1.4. Dependencies

2. System Context

2.1. Feasibility study

3. General Requirements

3.1. General Functional Requirements

3.2. Non Functional Requirements

4. System Management and Monitoring

5. Disaster Contingency Solution

6. Effect of the solution

10 | P a g e

1. INTRODUCTION

This document contains the Software Requirement Specification (SRS) of Data acquisition

scheme in Wireless Sensor Networks.

1.1 PURPOSE

The SRS contains complete description of the software requirements for Data acquisition

scheme in WSN. It provides an insight to the design information needed for software

support.

1.2 SCOPE

The data acquisition scheme in WSN mainly aims in achieving reliability in data

transmission. The number of packets dropped is reduced and the packets dropped can be

recovered. Thus, we can get accurate readings at the base station.

Some critical applications require that all the sensed data must be sent at the base station

accurately, without losing a single data packet. Loss of a single packet might hamper the

results produced at the base station and in turn affect the outcome of the experiment.

In this project, packet loss is reduced significantly, which gives accurate results at the

base station.

1.3 ASSUMPTIONS

User is able to understand the User Interface correctly.

1.4 DEPENDENCIES

Each of the sensor nodes depends upon a battery to function

2. SYSTEM CONTEXT

Science has developed by leaps and bounds in the past few decades. Introduction of

computers has aided this development. Almost everything has become computer

dependent these days. This has led to a drastic change in the lifestyles of the people.

Computers have made automation possible. Whatever you want is just a click away.

Automation has happened in almost every field.

11 | P a g e

Thus, creating something that does your work automatically is of paramount importance

in today’s world. This project primarily focuses on collecting information (temperature)

from different geographical areas and displaying this information on a computer.

When we are considering the manual process of collecting information (temperature)

from different geographical areas, the major problem is the inconvenience to go from one

part to the other. Also a lot of time is wasted in this process. In short, we can say that the

manual process is slow.

Therefore, using automation will reduce the time taken in the whole process.

In case where data is needed on a frequent basis, for example, after every two hours, then

the manual process becomes cumbersome. Also, there might be frequent changes in the

temperature of particular areas, which must be recorded too. Considering these factors,

automation is the best solution to all these problems. This type of automation is achieved

from our project.

2.1 FEASIBILITY STUDY

Feasibility study is the measure of how beneficial or practical this project will be to an

organization. The feasibility analysis is a cross life cycle activity and should

continuously be performed throughout the system life cycle.

OPERATIONAL FEASIBILITY:

Following techniques (topologies) are used to send the data packets from a source node to

the base station:

1. End-to-end: Data is sent directly from the source node to the base station.

2. Hop-by-hop: Data is not sent directly from the source node to the base station, instead

it is sent via intermediate nodes to the base station.

Depending upon the application and the inter node distance; any of the above topologies

can be selected.

12 | P a g e

TECHINICAL FEASIBILITY:

For the design and development of the system, following would be used:

Coding – C

Interface design – C#

Technology – ZigBee

Microcontroller – Jennic J5139

Platform – Windows

Operating System – Run-Time Environment (TinyOS for better performances)

The project is technically feasible using the above technologies.

3. GENERAL REQUIREMENTS

3.1. GENERAL FUNCTIONAL REQUIREMENTS

General Functional

Requirements

Description

Accuracy The sensed data must be accurate.

Processor Processor used carries out the desired operations

accurately.

Deployment Sensor nodes must be deployed at a distance from

one another to cover entire area under observation.

Reliability No data packets must be dropped while

transmitting the packets from one node to the

other.

Table A: General Functional Requirements

13 | P a g e

3.2. NON FUNCTIONAL REQUIREMENTS

Non Functional

Requirements

Description

Simple Interface The interface at the end system must be simple

and easily understood by a new user.

Accuracy of information displayed The collected information must be accurately

displayed.

Battery

Battery life must be large.

Maintenance The nodes must be designed such that they

require minimum or no maintenance.

Operability The Sensor node must operate in all sorts of

environments.

Range of communication To cover a large area, the range of

communication of the nodes must be large.

Table B: Non Functional Requirements

4. SYSTEM MANAGEMENT AND MONITORING

The system needs to be updated constantly according to the necessities of the users.

System should be made available 24/7 to the user.

5. DISASTER CONTIGENCY SOLUTION

Dropped packets can be recovered successfully by proper buffer management done at

the node level.

6. EFFECT OF THE SOLUTION

In case if some packets are dropped, they can be easily recovered by resending the

dropped packets. This will help in achieving high reliability.

Temperature monitoring will become convenient, as all the readings reach the base

station.

14 | P a g e

CHAPTER 5 SOFTWARE PROJECT PLAN

5.1 SOFTWARE FACE OF PROJECT

Sensors typically have five basic software subsystems:

1. OPERATING SYSTEM (OS) MICROCODE:

Also called “Middleware”, is the board common microcode that is used by all high-level node-

resident software modules to support various functions. As is generally the case, the purpose of

an operating system is to shield the software from the machine-level functionality of the

microprocessor/microcontroller. It is desirable to have open-source operating systems designed

specifically for WSNs; these OSs typically utilize an architecture that enables rapid

implementation while minimizing code size.

TinyOS:

TinyOS is a highly modular software environment tailored to the requirements of Network

Sensors, stressing efficiency, modularity and concurrency.

o Capable of fine grained concurrency (event-driven architecture)

o Small physical size

o Fewer context switches (FIFO/non-pre-emptible scheduling)

o Efficient Resource Utilization

o Highly Modular

FEATURES:

1. Event-driven architecture

1.1. Lower layer sends events to higher layer

1.2. Low overhead– No busy -wait cycles

2. Interrupt driven (two kinds of interrupt)

2.1. Clock

2.2. Radio

3. Component driven programming model

3.1. Size - 400 bytes

15 | P a g e

3.2. Extremely flexible component graph

3.3. Single Single-shared stack shared stack

4. Network management - Active Messaging

5. No kernel, process management, virtual memory

6. File management - Matchbox

7. 2-level FIFO scheduler– events and tasks

8. Complete integration with hardware

2. SENSOR DRIVERS:

These are the software modules that manage basic functions of the sensor transceivers; sensors

may possibly be of the modular/plug-in type, and depending on the type and sophistication, the

appropriate configuration and settings must be uploaded into the sensor (drivers shield the

application software from the machine-level functionality of the sensor or other peripheral).

3. COMMUNICATION PROCESSORS:

This code manages the communication functions, including routing, packet buffering and

forwarding, topology maintenance, medium access control (e.g., contention mechanisms, direct-

sequence spread-spectrum mechanisms), encryption, and FEC, to list a few (e.g., see Figure

below).

4. COMMUNICATION DRIVERS:

These functions at encoding and the physical layer whereas the software modules manage the

minutia of the radio channel transmission link, including clocking and synchronization, signal

encoding, bit recovery, bit counting, signal levels, and modulation.

5. DATA PROCESSING MINI-APPS:

These are numerical, data-processing, signal value storage and manipulations, or other basic

applications that are supported at the node level for in-network processing.

16 | P a g e

Fig D: Software components of WNs

5.2 PROCESS MODEL

The process model used for the project is the waterfall model. We use the so‐called V‐model:

Fig E: Process Model

17 | P a g e

The project is divided in five phases, which may slightly overlap. These phases are:

1. UR (user requirements) phase

2. SR (software requirements) phase

3. AD (architectural design) phase

4. DD (detailed design) phase

5. TR (transfer) phase

The UR phase involves creating the management documents (SPMP, SCMP, SVVP and SQAP)

and the URD. Further, the CM phase has to make sure all necessary hardware and software is

available. The DD phase involves creating the source code and the unit, integration and system

tests. Acceptance tests are performed during the TR phase.

5.3 RISK MANAGEMENT

A number of issues exist in WSN and need to be analyzed in detail in order to design appropriate

mechanisms and overcome problems that arise in the sensor environment. However, these are

constrained by the capabilities of the sensor nodes. Although their limited size makes them

attractable for use in a number of situations, at the same time their size affects resources such as

the energy, computational power, and storage available.

PROJECT RISK:

1. STORAGE RESTRICTIONS:

In our project, we are going to store data sensed by sensors in the secondary storage like memory

card. So, storage restriction plays an important role here. We need to monitor continuously

available count of storage. Because if we have important incoming data and there is no place to

store it, then we will lost it. And it may cost very much. We need to make sure that there is space

for incoming data so that we can avoid critical data loss.

2. RANDOM TOPOLOGY:

Most of the time, deploying a sensor network in a hostile environment is done by random

distribution; therefore, it is difficult to know the topology of sensor networks and to control

18 | P a g e

it. So, we must try to decrease the complexity and make sure that we understand the topology

very well.

PERFORMANCE RISK:

1. POWER RESTRICTIONS

The power restrictions of sensor nodes are raised due to their small physical size. Sensor nodes

are typically battery-driven. However, because often WSN are deployed in remote or hostile

environments, it is difficult to replace or recharge batteries. The power is used for various

operations in each node, such as running the sensors, processing the information gathered and

data communication. Communication between sensor nodes consumes most of the available

power, much more than sensing and computation. Power limitations greatly affect security.

2. LIMITED COMPUTATIONAL POWER

In the case of computational power, computations are linked with the available amount of power.

Since there is a limited amount of power, computations are constrained also. More power is used

for communication than computations. So, we need to use available power carefully to fulfill

requirements.

CHAPTER 6 HIGH LEVEL DESIGNS

6.1 ARCHITECTURE AND FEATURES OF JN5139 MICRO-CONTROLLER

Fig F: Architecture of JN5139 Microcontroller

19 | P a g e

The JN513x are a family of low power, low cost wireless microcontrollers suitable for

IEEE802.15.4 and ZigBee applications. Each device integrates a 32-bit RISC processor, with a

fully compliant 2.4GHzIEEE802.15.4 transceiver, 192kB of ROM, a selection of RAM sizes

from 8kB to 96kB, and a rich mixture of analogue and digital peripherals.

FEATURES: MICROCONTROLLER

• 32-bit RISC processor sustains 32 MIPS with low power

• 192kB ROM stores system code, including protocol stack

• 8kB, 16kB, 32kB or 96kB RAM stores system data and optionally boot-loaded program code

• 48-byte OTP eFuse, stores MACID on-chip, offers AES based code encryption feature

• 4-input 12-bit ADC, 2 11-bit DACs, 2 comparators

• 2 Application timer/counters, 3 system timers

• 2 UARTs (one for debug)

• SPI port with 5 selects

• 2-wire serial interface

• Up to 21 GPIO

FEATURES: TRANSCEIVER

• 2.4GHz IEEE802.15.4 compliant

• 128-bit AES security processor

• MAC accelerator with packet formatting, CRCs, address check, auto-acks, timers

• Integrated power management and sleep oscillator for low power

• On-chip power regulation for 2.2V to 3.6V battery operation

• Deep sleep current 0.2μA

• Sleep current with active sleep timer 1.3μA

• Rx current 34mA

• Tx current 34mA

• Receiver sensitivity -97dBm

• Transmit power +3dBm

20 | P a g e

6.2 USE CASE DIAGRAM

Fig G: Use Case Diagram (Functionalities)

21 | P a g e

Fig H: Use Case Diagram (System Working)

A use case diagram at its simplest is a representation of a user's interaction with the system that

shows the relationship between the user and the different use cases in which the user is involved.

A use case diagram can identify the different types of users of a system and the different use

cases and will often be accompanied by other types of diagrams as well.

22 | P a g e

6.3 ACTIVITY DIAGRAM

Fig I: Activity Diagram

Activity diagrams are graphical representations of workflows of stepwise activities and actions

with support for choice, iteration and concurrency. In the Unified Modeling Language, activity

diagrams are intended to model both computational and organizational processes (i.e.

workflows). Activity diagrams show the overall flow of control.

23 | P a g e

6.4 CLASS DIAGRAM

Fig J: Class Diagram

In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of

static structure diagram that describes the structure of a system by showing the system's classes,

their attributes, operations (or methods), and the relationships among objects.

The class diagram is the main building block of object oriented modeling. It is used both for

general conceptual modeling of the systematics of the application, and for detailed modeling

translating the models into programming code. Class diagrams can also be used for data

modeling. The classes in a class diagram represent both the main objects, interactions in the

application and the classes to be programmed.

24 | P a g e

6.5 SEQUENCE DIAGRAM

Fig K: Sequence Diagram

A Sequence diagram is an interaction diagram that shows how processes operate with one

another and what is their order. It is a construct of a Message Sequence Chart. A sequence

diagram shows object interactions arranged in time sequence. It depicts the objects and classes

involved in the scenario and the sequence of messages exchanged between the objects needed to

carry out the functionality of the scenario. Sequence diagrams are typically associated with use

case realizations in the Logical View of the system under development. Sequence diagrams are

sometimes called event diagrams or event scenarios.

25 | P a g e

CHAPTER 7 IMPLEMENTATION

7.1 INSTALLATION AND CONFIGURATION

7.1.1 SDK INSTALLERS

The SDK is supplied as two independent installers, available on the evaluation kit CD or from

the Support area of the Jennic web site (www.jennic.com/support):

o SDK Libraries Installer (JN-SW-4030): This installs the Jennic software libraries that

will help streamline your application development. These libraries include Application

Programming Interfaces (APIs) for the Jenie, ZigBee and IEEE 802.15.4 protocols, as

well as a parser for the AT-Jenie command set.

o SDK Toolchain Installer (JN-SW-4031): This installs the Jennic software tools that you

will use to prepare your wireless network applications. These utilities include

development, compiler and Flash programming tools.

7.1.2 SDK LIBRARIES INSTALLER

The SDK Libraries are provided in the .exe file JN-SW-4030-SDK-Libraries-vX.Y. This

includes a number of APIs containing C functions, as well as other software components:

o AT-Jenie Command Parser

o Jenie API

o JenNet networking layer

o ZigBee (2004) networking layer and API

o IEEE 802.15.4 networking layer and API

o Integrated Peripherals API

o Board API

o Application Queue API

7.1.3 SDK TOOLCHAIN INSTALLER

The SDK Toolchain is provided in the .exe file JN-SW-4031-SDK-Toolchain-vX.Y. This

includes the following development tools:

26 | P a g e

o Cygwin CLI (Command Line Interface)

o Code::Blocks IDE (Integrated Development Environment)

o JN51xx Compiler Tools

o JN51xx Flash Programmer

7.1.4 SOFTWARE REQUIREMENTS

Before installing the SDK, make sure you have the following:

o A machine with the following specification:

• Windows Vista, XP or 2000 operating system

• At least 240 MB of hard disk space available

o Administrator rights on the machine

o The following SDK installers from the evaluation kit CD or the Jennic web site:

• JN-SW-4030-SDK-Libraries-vX.Y.exe

• JN-SW-4031-SDK-Toolchain-vX.Y.exe

7.1.5 HARDWARE REQUIREMENTS

The chosen protocol implementation for your wireless network determines the type of Jennic

evaluation kit that you will need. The table below summarizes the kits that support each protocol

combination.

Protocols Jennic Evaluation Kits

IEEE 802.15.4 JN5139-EK000 , JN5139-EK010

ZigBee (2004) JN5139-EK010

Jenie JN5139-EK000 , JN5139-EK010

AT-Jenie JN5139-EK000 , JN5139-EK010

Table C: Hardware Requirements

27 | P a g e

7.2 SDK TOOLCHAIN INSTALLATION

To install the SDK Toolchain on your machine:

Step 1: Remove any previous Jennic SDK installation from your machine via Add or Remove

Programs in Control Panel.

Step 2: Start the SDK Toolchain installer as follows, according to your installation source:

o If you are installing from the evaluation kit CD, insert the CD into your machine and

follow the on-screen instructions (if connected to the internet, the Jennic web site will

first be checked for a more recent installer). Be sure to select the “SDK Toolchain”

installer.

o If you have downloaded the file JN-SW-4031-SDK-Toolchain-vX.Y.exe from the Jennic

web site yourself, save it to your machine and run the installer.

Step 3: Follow the on-screen instructions of the set-up wizard until you reach the ‘Choose

Components’ screen:

By default, all the components are selected. De-select any component(s) that you do not wish to

install. In particular, you should:

28 | P a g e

o de-select Cygwin if you already have a Cygwin installation that you wish to preserve (see

Caution at the beginning of this section), otherwise leave it selected

o de-select Code::Blocks if you do not wish to develop your applications in the

Code::Blocks IDE

A Cygwin installation is required on your machine even if you wish to develop your applications

using Code::Blocks. Refer to Section 2.1 for further information on the components.

Click Next to continue.

Step 4: In the next screen, choose the location where you want to install the tools:

The set-up wizard will automatically insert the installation directory. By default, this is

C:\Jennic. If required, you can specify another drive but must keep the Jennic directory (e.g.

D:\Jennic).


Step 5: In the next screen, specify the folder in which you want the Jennic tools to appear in the

Windows Start menu. By default, this is set to Jennic.

29 | P a g e

Click Install.

Step 6: Wait for the installation to complete (this may take several minutes) and then click Next

followed by Finish.

Step 7: Re-start your computer when prompted to do so.

7.3 LIBRARIES INSTALLATION PROCEDURE

To install the SDK Libraries on your machine:

Step 1: Ensure that you have installed the SDK Toolchain, as described in Chapter 2.

Step 2: Start the SDK Libraries installer as follows, according to your installation source:

o If you are installing from the evaluation kit CD, insert the CD into your machine and

follow the on-screen instructions (if connected to the internet, the Jennic web site will

first be checked for a more recent installer). Be sure to select the “SDK Libraries”

installer.

o If you have downloaded the file JN-SW-4030-SDK-Libraries-vX.Y.exe from the Jennic

web site yourself, save it to your machine and run the installer.

Step 3: Follow the on-screen instructions of the set-up wizard. When you reach the Choose

Components screen, you will not be able to select individual components, since the wizard

always installs all components.


30 | P a g e

Step 4: In the next screen, choose the location where you want to install the libraries:

The set-up wizard will automatically insert the installation directory. By default, this is

C:\Jennic\cygwin\jennic. If required, you can specify another drive but must keep the

Jennic\cygwin\jennic path (e.g. D:\ Jennic\cygwin\jennic).


Step 5: In the next screen, specify the folder in which you want the Jennic libraries to appear in

the Windows Start menu. By default, this set to Jennic.

31 | P a g e

Click Install.

Step 6: Wait for the installation to complete and then click Next followed by Finish.

NOTE: THE OUTPUT CAN BE SHOWN ON TWO DIFFERENT PLATFORMS EITHER

1. TERA TERM

2. TESTBED APPLICATION (TERMINAL) - coded in C#

We will see installation and implementation of each of them.

7.4 INSTALLING TERA TERM

1. Point your web browser to:

http://www.cise.ufl.edu/~dts/downloads/TeraTermPro23.exe

It should ask if you want to save the file. Choose an appropriate directory and save it. NOTE: be

sure that the file name ends with a .exe extension--some browsers have a bug that strips it off).

The file is large (about 950KB).

2. Go to the directory in which you saved TeraTermPro23.exe and double click on its icon.

3. A dialogue window will popup--click on the unzip button on the top right.

4. A directory will be created named Ttp_temp--double click on its icon to go to that

directory.

5. Double click on the icon labeled setup (or setup.exe)

6. Dialogue windows will popup--English should be highlighted. Click the Continue button

7. Another dialogue will popup; click the Continue button.

8. Specify the path where you want the Tera Term Pro files to be installed (something like

C:\TeraTerm), and click the Continue button.

9. A window will pop up with a couple icons and a Tera Term Pro folder will be added to

the programs section of your START button menu.

http://www.cise.ufl.edu/~dts/downloads/TeraTermPro23.exe

32 | P a g e

10. Delete the Ttp_temp directory (you don't need it any more).

11. Click on the Tera Term Pro icon.

12. A dialogue window will popup: it should be set to log you into grove (if you want to

connect to a different system, specify it in the hosts section). Click the OK button.

7.5 INSTALLING THE TESTBED APPLICATION

You don’t need to install the Testbed Application since it’s just application software coded

completely on C# platform with an integrated GUI (Graphical User Interface). So you just have

to run the program (Visual C# Project File).

7.6 CONFIGURING THE HARDWARE AND WORKING OF PROJECT

Steps for Compiling and running the program In JN5139

1. Install Jennic SDK-Tollchain software.

2. Copy the project to particular path in the Jennic folder.

3. Build the project.

4. After building the project .bin file will be created in Project folder/JN5139_Build/Release.

5. Now once the bin file is created we need to download that file to Jennic hardware.

6. So open the Jennic Flash Programmer and browse the bin file location.

7. Before downloading the bin file into hardware first reset the hardware and put the hardware in

programming mode.

8. To put hardware in programming mode:

o First press reset button

o Then press and hold program, reset button then release reset button first and then

program button.

9. After downloading the program Finally Press the reset button.

33 | P a g e

10. To see the real time data transmission and reception Open HyperTerminal for each hardware

device connected on specific port to computer.

11. Send the file to master on Hyperterminal (Tera Term) and the end device will respond with

particular data for the file.

12. An alternative method to note down the results is to use the C# coded Testbed Application

wherein we can configure the hardware and send the soft commands to the end devices and in

return receive the data (status of end device, core temperature of end device and other

information like source/destination addresses, link quality, message, etc.). The main advantage of

using this Testbed Application is that it will decrease our overhead of using the Jennic Flash

Programmer (for configuration) and Hyper Terminal (for displaying results).

7.7 SCREENSHOTS OF APPLICATIONS USED

1. JENNIC CODEBLOCKS

Fig L: Jennic Codeblocks

34 | P a g e

2. JENNIC FLASH PROGRAMMER

Fig M: Jennic Flash Programmer

35 | P a g e

3. HYPERTERMINAL (TERA TERM)

Fig N: Tera Term (Hyperterminal)

36 | P a g e

4. TESTBED APPLICATION (GUI)

Fig O: GUI (TestBed Application)

37 | P a g e

CHAPTER 8 VALIDATION OF SOFTWARE / VALIDATION OF DESIGN

8.1 INTRODUCTION

Testing is the process of evaluating a system or its components with the intent to find whether it

satisfies the specified requirements or not. Testing is executing a system in order to identify any

gaps, errors, or missing requirements in contrary to the actual requirements. Test Cases are built

around specifications and requirements, i.e., what the application is supposed to do. Test cases

are generally derived from external descriptions of the software, including specifications,

requirements and design parameters. Although the tests used are primarily functional in

nature, non-functional tests may also be used. The test designer selects both valid and invalid

inputs and determines the correct output without any knowledge of the test object's internal

structure.

Testing of various test cases for the project performed is:

8.1.1 TEST PLAN

Table D: Test Plan

8.2 SELECTION OF PROJECT TESTING TOOL

8.2.1 TEST TOOL SELECTION

This will include various test tools we are using:

38 | P a g e

1. TeraTerm

o TeraTerm is a HyperTerminal used to show the data transmission and reception.

o For each device we need to start a separate terminal to show the data.

o Shows the data sand and received efficiently with minimum delay.

2. Jennic Flash Programmer

o It is software to download the compiled program into the Jennic JN5139 hardware.

3. GUI

o In GUI all the testing conditions are displayed by using various buttons

o Each button has a different functionality for ex. Ping, Get Temperature.

o In GUI all the modules data can be shown in one place.

8.2.2 WHICH IS THE EFFICIENT ONE AND MOST PROMISING

From above listed GUI and TeraTerm:-

o GUI has an advantage of showing all the functions used in one place

o While in TeraTerm we need to send a file to get particular data.

o In GUI the delay between data transmission and reception is more.

o But in TeraTerm the delay in data transmission and reception is less.

8.3 RESULTING CHARTS / GRAPHS

Before managing buffer, the packets used to drop as the number would approach the size of

buffer. The reason was the insufficient time for the buffer manager to clear up the queue and

hence the packet arriving after the count of size of buffer used to drop. We performed a practical

demonstration on JN-5139 devices and managed the buffer in a way that minimized the chances

of packet drop. The average packet drop was minimized by about 85 %. When there should have

been a complete drop of about packets, the model seen about 85-90 % increase in packet

delivery.

39 | P a g e

Fig P: The size of group of packets at each interval is 100 and fig shows no. of packets

received for continuous time interval.

Also, we have plotted the simulation results (demonstration on JN-5139) regarding data frame

transfer time and acknowledgement time (in milliseconds) with respect to packet number (only 5

readings included).

Fig Q: Data Transfer Time and Acknowledge Time versus Packet Number

40 | P a g e

CHAPTER 9 RESULTS AND ANALYSIS

9.1 SAMPLE CODE (IMPORTANT MODULES)

DEMOMAIN.C

#include <jendefs.h>

#include <AppHardwareApi.h>

#include <AppQueueApi.h>

#include <mac_sap.h>

#include <mac_pib.h>

#include <string.h>

#include <AppApi.h>

#include <stdlib.h>

#include "gdb.h"

#include "source\common\IOMAP.h"

#include "source\common\wuart.h"

#include "Source\Common\Comm_code.h"

#include "source\common\serialq.h"

#include "source\common\uart.h"

#include "Source\Common\lcd_drv.h"

#include "Source\Common\SMBus.h"

#define ED_ADDR 0x0015U

PRIVATE void LCD_SCR1(void);

PUBLIC void set_Tick_Timer();

PUBLIC void vTicker();

PUBLIC void vdata_received();

PUBLIC void temp();

PUBLIC void printdata(uint16 buffdata[15],uint8 j);

PUBLIC void dispdata(uint16 datas,uint8 pos,uint8 value_resolution);

uint8 count1=0;

__MAC_TrasmitOption_e_e;

uint8 *calender[]={0x00,0x00,0x00,0x10,0x10,0x10,0x10,0x10,0x10,};

PUBLIC void AppColdStart(void)

{

uint8 mydata[]="Hello world";

HAL_GDB_INIT();

HAL_BREAKPOINT();

MyAdd = ED_ADDR;

vPerpheral_Init();

vRx_TxLED2(on);

mydelay(1);

vRx_TxLED2(off);

vButtonInitRfd();

init_lcd();

vSerialQ_AddString(TX_QUEUE," MyAddress :");

vSerialQ_AddHex(TX_QUEUE,MyAdd,4);

41 | P a g e

vSerialQ_AddString(TX_QUEUE,"\n\r");

vUART_StartTx();

vAHI_ApConfigure(E_AHI_AP_REGULATOR_ENABLE,E_AHI_AP_INT_DISABLE,E_AHI_

AP_SAMPLE_4,E_AHI_AP_CLOCKDIV_500KHZ,E_AHI_AP_INTREF);

while(!bAHI_APRegulatorEnabled());

vstart_radio();

LCD_SCR0();

LCD_SCR1();

vUART_StartTx();

vAHI_SysCtrlRegisterCallback(vdata_received);

while(1)

{

vProcessEventQueues();

}

}

PRIVATE void LCD_SCR1(void)

{

char initMsg[40];

strcpy(&initMsg[0],"Demo Sample Code");

write_message(&initMsg[0],16,line1);

disp_digit(MyAdd,4,line1,16);

strcpy(&initMsg[0],"Press U1 to transmit");


strcpy(&initMsg[0]," ");


strcpy(&initMsg[0]," ");


}

PUBLIC void dispdata(uint16 datas,uint8 pos,uint8 value_resolution)

{

uint16 m;

uint8 b1, b2, b3, b4, b5;

m=datas/10; //1234

b1=datas%10; // 5

b2=m%10; // 4

m=m/10; // 123

b3=m%10; // 3

m=m/10; // 12

b4=m%10; // 2

m=m/10; // 1

b5=m;

b1 = b1 | 0x30;

b2 = b2 | 0x30;

b3 = b3 | 0x30;

b4 = b4 | 0x30;

b5 = b5 | 0x30;

42 | P a g e

vSerialQ_AddItem(TX_QUEUE,b4);


vSerialQ_AddString(TX_QUEUE,".");



}

PUBLIC void disp_lcd_dec(uint16 datas,uint8 value_resolution,uint8

ln,uint8 pos)

{

uint16 m;

uint8 b1,b2,b3,b4,b5;

set_ln_pos(ln,pos);

m=datas/10; //1234

b1=datas%10; // 5

b2=m%10; // 4

m=m/10; // 123

b3=m%10; // 3

m=m/10; // 12

b4=m%10; // 2

m=m/10; // 1

b5=m;

b1 = b1 | 0x30;

b2 = b2 | 0x30;

b3 = b3 | 0x30;

b4 = b4 | 0x30;

b5 = b5 | 0x30;

lcd_delay(1);

wait_lcd();

w_lcd(b5,1);

lcd_delay(1);

wait_lcd();

w_lcd(b4,1);

lcd_delay(1);

wait_lcd();

w_lcd(b3,1);

lcd_delay(1);

wait_lcd();

w_lcd(b2,1);

lcd_delay(1);

wait_lcd();

w_lcd(b1,1);

}

PUBLIC void vdata_received()

{


43 | P a g e

}

PUBLIC void temp()

{

uint16 adcdata;

uint16 buffdata[20];

uint8 i;

for(i=0;i<10;i++)

{

vAHI_AdcEnable(E_AHI_ADC_SINGLE_SHOT,E_AHI_AP_INPUT_RANGE_1,E_AHI

_ADC_SRC_TEMP);

vAHI_AdcStartSample();

while(bAHI_AdcPoll());

adcdata= u16AHI_AdcRead();


vSerialQ_AddString(TX_QUEUE,"\n\rTemperature=");

dispdata(adcdata,1,1);

buffdata[i]=adcdata;

vSerialQ_AddString(TX_QUEUE,"Deg.C");

vAHI_AdcEnable(E_AHI_ADC_SINGLE_SHOT,E_AHI_AP_INPUT_RANGE_2,E_AHI_ADC_

SRC_VOLT);





vSerialQ_AddString(TX_QUEUE,"\n\rBatt.Power=");

dispdata(adcdata,1,1);




vUART_StartTx();

}

}

PUBLIC void printdata(uint16 buffdata[15],uint8 j)

{

uint8 i;

uint16 avg=0,sum=0;

vSerialQ_AddString(TX_QUEUE,"\n\rThe temprature readings are:");


for(i=0;i<j;i++)

{

dispdata(buffdata[i],1,1);


sum=sum+buffdata[i];

}

avg=sum/j;

44 | P a g e

vSerialQ_AddString(TX_QUEUE,"\n\rThe average of temprature

readings is:");

dispdata(avg,1,1);


}

UART.C






#include <string.h>

#include <AppApi.h>

#include <stdlib.h>

#include "gdb.h"







#if UART == E_AHI_UART_0

#define UART_START_ADR 0x30000000UL

#else

#define UART_START_ADR 0x40000000UL

#endif

#define UART_DLM_OFFSET 0x04 /**< Offset of UART's DLM register */

#define UART_LCR_OFFSET 0x0C /**< Offset of UART's LCR register */

#define UART_MCR_OFFSET 0x10 /**< Offset of UART's MCR register */

#define UART_EFR_OFFSET 0x20 /**< Offset of UART's EFR register */

PRIVATE bool_t bRxEnable; /**< UART receive enabled */

PRIVATE bool_t bTxEnable; /**< UART transmit enabled */

PRIVATE bool_t bModemInt;

PRIVATE bool_t bTxIntServiced;

PUBLIC uint8 char_no=0;

PUBLIC uint8 uartdata[50];

PRIVATE void vUART_SetBaudRate(uint32 u32BaudRate);

PRIVATE void vUART_SetRts(bool_t);

PRIVATE void vUART_SetAutoFlow(bool_t);

PRIVATE void vUART_HandleUartInterrupt(uint32 u32Device, uint32

u32ItemBitmap);

PUBLIC void vUART_Init(void)

{

bRxEnable = TRUE;

bTxEnable = TRUE;

45 | P a g e

#if UART_AUTOFLOW

bModemInt = FALSE;

#else

bModemInt = TRUE;

#endif

bTxIntServiced = FALSE;

vAHI_UartEnable(UART);

vAHI_UartReset(UART, TRUE, TRUE);

vAHI_UartReset(UART, FALSE, FALSE);

#if UART == E_AHI_UART_0

vAHI_Uart0RegisterCallback(vUART_HandleUartInterrupt);

#else

vAHI_Uart1RegisterCallback(vUART_HandleUartInterrupt);

#endif

vAHI_UartSetRTSCTS(UART, TRUE);

vUART_SetAutoFlow(UART_AUTOFLOW);

vUART_SetBaudRate(UART_BAUD_RATE);

vAHI_UartSetControl(UART, FALSE, FALSE, E_AHI_UART_WORD_LEN_8,

TRUE, FALSE);

vUART_SetRts(bRxEnable);

if (u8AHI_UartReadModemStatus(UART) & 0x10)

{

/* Disable transmit */

vUART_SetTxEnable(FALSE);

}

{

vUART_SetTxEnable(TRUE);

}

vAHI_UartSetInterrupt(UART, bModemInt, FALSE, TRUE, bRxEnable,

E_AHI_UART_FIFO_LEVEL_1);

}

PUBLIC void vUART_StartTx(void)

{

if (bTxIntServiced == FALSE)

{

if (u8AHI_UartReadLineStatus(UART) & E_AHI_UART_LS_THRE)

{

if(!bSerialQ_Empty(TX_QUEUE) && bTxEnable)

{

vAHI_UartWriteData(UART, u8SerialQ_RemoveItem(TX_QUEUE));

}

}

}

}

PUBLIC void vUART_TxCharISR(void)

{

if(!bSerialQ_Empty(TX_QUEUE) && bTxEnable)

{

vAHI_UartWriteData(UART, u8SerialQ_RemoveItem(TX_QUEUE));

bTxIntServiced = TRUE;

}

else

46 | P a g e

{

bTxIntServiced = FALSE;

}

}

PUBLIC void vUART_RxCharISR(uint8 u8RxChar) /**< Received character */

{

uint8 j,i;

uint16 addrs;

if(u8RxChar=='$')

{char_no=0;}

uartdata[char_no]=u8RxChar;

char_no++;

vSerialQ_AddItem(RX_QUEUE, u8RxChar);

vSerialQ_AddItem(TX_QUEUE,u8RxChar);

vUART_StartTx();

if(u8RxChar=='#')

{ switch(uartdata[7])

{ case ('0'): {addrs=0xffffU; break;} //break

case ('1'): {addrs=0x0013U; break;} //slave 1


case ('3'): {addrs=0x0015U; break;} //master



default:{addrs=0xffffU; break;}

}

}

}

PUBLIC void vUART_SetRxEnable(bool_t bEnable)

{

if (bRxEnable != bEnable)

{

bRxEnable = bEnable;

vAHI_UartSetInterrupt(UART, bModemInt, FALSE, TRUE,

bRxEnable, E_AHI_UART_FIFO_LEVEL_1);

#if ! UART_AUTOFLOW

vUART_SetRts(bRxEnable);

#endif

}

}

PUBLIC void vUART_SetTxEnable(bool_t bEnable)

{

if (bTxEnable != bEnable)

{

bTxEnable = bEnable;

}

}

PUBLIC bool_t bUART_GetTxEnable(void)

{

return bTxEnable;

}

PRIVATE void vUART_SetBaudRate(uint32 u32BaudRate)/**< Baud rate */

47 | P a g e

{

uint8 *pu8Reg;

uint8 u8TempLcr;

uint16 u16Divisor;

uint32 u32Remainder;

pu8Reg = (uint8 *)(UART_START_ADR + UART_LCR_OFFSET);

u8TempLcr = *pu8Reg;

*pu8Reg = u8TempLcr | 0x80;

u16Divisor = (uint16)(16000000UL / (16UL * u32BaudRate));

u32Remainder = (uint32)(16000000UL % (16UL * u32BaudRate));

if (u32Remainder >= ((16UL * u32BaudRate) / 2))

{

u16Divisor += 1;

}

pu8Reg = (uint8 *)UART_START_ADR;

*pu8Reg = (uint8)(u16Divisor & 0xFF);

pu8Reg = (uint8 *)(UART_START_ADR + UART_DLM_OFFSET);

*pu8Reg = (uint8)(u16Divisor >> 8);

pu8Reg = (uint8 *)(UART_START_ADR + UART_LCR_OFFSET);

u8TempLcr = *pu8Reg;

*pu8Reg = u8TempLcr & 0x7F;

}

PRIVATE void vUART_SetRts(bool_t bEnable) /**< RTS status */

{

uint8 *pu8Reg;

uint8 u8Val;

pu8Reg = (uint8 *)(UART_START_ADR + UART_MCR_OFFSET);

u8Val = *pu8Reg;

if (bEnable)

{

u8Val &= 0xFD;

}

else

{

u8Val |= 0x02;

}

*pu8Reg = u8Val;

}

PRIVATE void vUART_SetAutoFlow(bool_t bEnable)

{

uint8 *pu8Reg;

uint8 u8Val;

pu8Reg = (uint8 *)(UART_START_ADR + UART_EFR_OFFSET);

u8Val = *pu8Reg;

if (bEnable)

{

u8Val |= 0x10;

}

else

48 | P a g e

{

u8Val &= 0xEF;

}

*pu8Reg = u8Val;

}

PRIVATE void vUART_HandleUartInterrupt(uint32 u32Device,uint32

u32ItemBitmap)

{

uint8 u8LineStatus;

uint8 u8ModemStatus;

if (u32Device == UART_DEVICE)

{

u8LineStatus = u8AHI_UartReadLineStatus(UART);

if ((u32ItemBitmap & 0x000000FF) == E_AHI_UART_INT_RXDATA)

{

vUART_RxCharISR(u8AHI_UartReadData(UART));

}

#if ! UART_AUTOFLOW

else if (u32ItemBitmap == E_AHI_UART_INT_MODEM)

{

u8ModemStatus = u8AHI_UartReadModemStatus(UART);

if (u8ModemStatus & E_AHI_UART_MS_DCTS)

{

if (u8ModemStatus & 0x10)

{

vUART_SetTxEnable(FALSE);

}

else

{

vUART_SetTxEnable(TRUE);

if (u8LineStatus & E_AHI_UART_LS_THRE)

vUART_TxCharISR();

}

}

}

#endif

else if (u32ItemBitmap == E_AHI_UART_INT_TX)

{

vUART_TxCharISR();

}

}

}

SERIALQ.C



#include "gdb.h"

#include "wuart.h"

49 | P a g e

#include "uart.h"

#include "serialq.h"

#include "lcd_drv.h"

#define SERIALQ_MASK 0x03FFU

#define SERIALQ_SIZE SERIALQ_MASK+1

#define SERIALQ_COUNT 2

#define SERIALQ_FREE_LOW 64

#define SERIALQ_FREE_HIGH 128

typedef struct

{

uint16 u16Head; /**< Position in queue to add to */

uint16 u16Tail; /**< Position in queue to remove from */

uint16 u16In; /**< Input character counter */

uint16 u16Out; /**< Output character counter */

uint8 u8Buff[SERIALQ_SIZE]; /**< Queue buffer */

} tsCircBuff;

PRIVATE tsCircBuff sRxQueue;

PRIVATE tsCircBuff sTxQueue;

PRIVATE const tsCircBuff *apsQueueList[SERIALQ_COUNT] = { &sRxQueue,

&sTxQueue };

PRIVATE void vSerialQ_Flush(teQueueRef eQueue);

PUBLIC void vSerialQ_Init(void)

{

vSerialQ_Flush(RX_QUEUE);

vSerialQ_Flush(TX_QUEUE);

}

PUBLIC void vSerialQ_AddString(teQueueRef eQueue, char *psString)

{

while (! bSerialQ_Full(eQueue) && *psString != '\0')

{

vSerialQ_AddItem(eQueue, (uint8) *psString);

psString++;

}

}

PUBLIC void vSerialQ_AddHex(teQueueRef eQueue,uint16 u16Value,uint8

u8Digits)

{

uint8 u8Pos;

char sHex[5];

char sChar[17] = "0123456789ABCDEF";

if (u8Digits > 4) u8Digits = 4;

for (u8Pos = 0; u8Pos < u8Digits; u8Pos++)

{

sHex[u8Pos]=sChar[(u16Value>>((u8Digits-u8Pos-1)*4)) &0xF];

sHex[u8Pos+1] = '\0';

}

vSerialQ_AddString(eQueue, sHex);

50 | P a g e

}

PUBLIC vdispdata(uint16 datas,uint8 pos,uint8 value_resolution)

{

uint16 m;


m=datas/10; //1234

b1=datas%10; // 5

b2=m%10; // 4

m=m/10; // 123

b3=m%10; // 3

m=m/10; // 12

b4=m%10; // 2

m=m/10; // 1

b5=m;

b1 = b1 | 0x30;

b2 = b2 | 0x30;

b3 = b3 | 0x30;

b4 = b4 | 0x30;

b5 = b5 | 0x30;





}

PUBLIC void vSerialQ_AddItem(teQueueRef eQueue, uint8 u8Item)

{

tsCircBuff *psQueue;

uint16 u16NextLocation;

uint16 u16Tail;

uint16 u16Free;

psQueue = (tsCircBuff *)apsQueueList[eQueue];

u16Tail = psQueue->u16Tail;

u16NextLocation = (psQueue->u16Head + 1) & SERIALQ_MASK;

if (u16NextLocation != u16Tail)

{

psQueue->u8Buff[psQueue->u16Head] = u8Item;

psQueue->u16Head = u16NextLocation;

psQueue->u16In++;

if (eQueue == RX_QUEUE)

{

if (u16Tail > psQueue->u16Head)

u16Free = u16Tail - psQueue->u16Head;

else

u16Free = SERIALQ_SIZE + u16Tail - psQueue->u16Head;

if (u16Free == SERIALQ_FREE_LOW)

{

if (bUART_GetRxEnable())

vUART_SetRxEnable(FALSE);

51 | P a g e

}

}

}

}

PUBLIC uint8 u8SerialQ_RemoveItem(teQueueRef eQueue)

{

uint8 u8Item = 0;


uint16 u16Head;

uint16 u16Free;


u16Head = psQueue->u16Head;

if (psQueue->u16Tail != u16Head)

{

u8Item = psQueue->u8Buff[psQueue->u16Tail];

psQueue->u16Tail = (psQueue->u16Tail + 1) & SERIALQ_MASK;

psQueue->u16Out++;

if (eQueue == RX_QUEUE)

{

if (psQueue->u16Tail > u16Head)

u16Free = psQueue->u16Tail - u16Head;

else

u16Free = SERIALQ_SIZE + psQueue->u16Tail - u16Head;

if (u16Free == SERIALQ_FREE_HIGH)

{

if (! bUART_GetRxEnable())

vUART_SetRxEnable(TRUE);

}

}

}

return(u8Item);

}

PUBLIC bool_t bSerialQ_Empty(teQueueRef eQueue)

{

bool_t bResult = FALSE;



if (psQueue->u16Tail == psQueue->u16Head)

{

bResult = TRUE;

}

return(bResult);

}

PUBLIC bool_t bSerialQ_Full(teQueueRef eQueue)

{

bool_t bResult = FALSE;


uint16 u16NextLocation;


52 | P a g e

u16NextLocation = (psQueue->u16Head + 1) & SERIALQ_MASK;

if (u16NextLocation == psQueue->u16Tail)

{

bResult = TRUE;

}

return(bResult);

}

PUBLIC uint16 u16SerialQ_Count(teQueueRef eQueue)

{

uint16 u16Head;

uint16 u16Tail;

tsCircBuff *psQueue = (tsCircBuff *)apsQueueList[eQueue];

u16Tail = psQueue->u16Tail;


if (u16Head >= u16Tail)

u16Head -= u16Tail;

else

u16Head = SERIALQ_SIZE + u16Head - u16Tail;

return(u16Head);

PUBLIC uint16 u16SerialQ_Free(teQueueRef eQueue)

{

uint16 u16Head;

uint16 u16Free;


u16Free = psQueue->u16Tail;


if (u16Free > u16Head) u16Free -= u16Head;

else

u16Free = SERIALQ_SIZE + u16Free - u16Head;

return(u16Free); /** \return Amount of free space in queue */

}

PUBLIC uint16 u16SerialQ_GetInCount(teQueueRef eQueue)

{


return(psQueue->u16In);

}

PUBLIC uint16 u16SerialQ_GetOutCount(teQueueRef eQueue)

{


return(psQueue->u16Out);

}

PRIVATE void vSerialQ_Flush(teQueueRef eQueue)

{



53 | P a g e

psQueue->u16Head = 0;

psQueue->u16Tail = 0;

psQueue->u16In = 0;

psQueue->u16Out = 0;

}

COMM_CODE.C






#include <string.h>

#include <AppApi.h>

#include <stdlib.h>

#include "gdb.h"







PUBLIC void printdata(uint16 buffdata[15],uint8 j);

PUBLIC void dispdata(uint16 datas,uint8 pos,uint8 value_resolution);

PUBLIC int store(int j);

PUBLIC int retransmit(int j);

PUBLIC void conclusion(int j);

PUBLIC bool_t f;

PUBLIC uint8 timeout=0;

uint8 timecount=0;

PUBLIC uint8 counter=0;

PUBLIC uint8 noofpackets=0;

PUBLIC void ShowReceivePacket1(MAC_RxFrameData_s*);

PUBLIC void transmitt_packet(uint16 DSTADD,uint8 *mydata,uint8 count)

{

static uint8 p_num;

vRx_TxLED2(on);

uint8 i,j;

uint16 DestAdd = DSTADD;

write_message(" ",20,line2);

write_message("transmitt",9,line2);

vdisp_lcd_dec(p_num,3,line2,11);

vSerialQ_AddString(TX_QUEUE,"Transmitting to ");

vSerialQ_AddHex(TX_QUEUE,DestAdd,4);

vSerialQ_AddString(TX_QUEUE,", p_num ");

vSerialQ_AddHex(TX_QUEUE,p_num,2);


54 | P a g e

vUART_StartTx();

vTransmitPacket(mydata,count,MyAdd,DestAdd,p_num);

p_num++;

vRx_TxLED2(off);

}

PUBLIC void vPerpheral_Init(void)

{

PRIVATE void *pvMac;

PRIVATE MAC_Pib_s *psPib;

(void)u32AHI_Init();

vLedInitRfd();

(void)u32AppQApiInit(NULL, NULL, NULL);

pvMac = pvAppApiGetMacHandle();

psPib = MAC_psPibGetHandle(pvMac);

MAC_vPibSetMaxCsmaBackoffs(psPib,3);

MAC_vPibSetMinBe(psPib,3);

MAC_vPibSetPanId(pvMac, PAN_ID);

MAC_vPibSetShortAddr(pvMac, MyAdd);

vSerialQ_Init();

vUART_Init();

}

PUBLIC void vstart_radio(void)

{

PRIVATE void *pvMac;

pvMac = pvAppApiGetMacHandle();

MAC_vPibSetRxOnWhenIdle(pvMac, 1, FALSE);

}

PUBLIC void vProcessEventQueues(void)

{

MAC_McpsDcfmInd_s *psMcpsInd;

MAC_RxFrameData_s *psRxFrame;

uint8 PID;

psMcpsInd = psAppQApiReadMcpsInd();

if (psMcpsInd != NULL) //MAC_MCPS_REQ_DATA = 0,

{

vRx_TxLED2(on);

if (psMcpsInd->u8Type == MAC_MCPS_IND_DATA)

{

psRxFrame = &psMcpsInd->uParam.sIndData.sFrame;

vSerialQ_AddString(TX_QUEUE,"Received\n\r");

vUART_StartTx();

ShowReceivePacket(psRxFrame);

}

if(psMcpsInd->u8Type == MAC_MCPS_DCFM_DATA)

{

if(psMcpsInd->uParam.sDcfmData.u8Status == MAC_ENUM_SUCCESS)

{

vSerialQ_AddString(TX_QUEUE,"Transmitt successfull\n\r");

vUART_StartTx();

}

55 | P a g e

}

if(psMcpsInd->uParam.sDcfmData.u8Status == MAC_ENUM_NO_ACK)

{

vSerialQ_AddString(TX_QUEUE," Packet could not be sent\n\r");

vUART_StartTx();

}

}

vAppQApiReturnMcpsIndBuffer(psMcpsInd);

vRx_TxLED2(off);

}

PUBLIC void vTransmitPacket(uint8 *tr_str,uint8 tr_count,uint16

MyAdd,uint16 DestAdd,uint8 p_num)

{

MAC_McpsReqRsp_s sMcpsReqRsp;

MAC_McpsSyncCfm_s sMcpsSyncCfm;

uint8 j,i;

uint8 *pu8Payload;

static uint8 PID;

sMcpsReqRsp.u8Type = MAC_MCPS_REQ_DATA;

sMcpsReqRsp.u8ParamLength = sizeof(MAC_McpsReqData_s);

sMcpsReqRsp.uParam.sReqData.u8Handle = PID;

PID++;

sMcpsReqRsp.uParam.sReqData.sFrame.sSrcAddr.u8AddrMode = 2;

sMcpsReqRsp.uParam.sReqData.sFrame.sSrcAddr.u16PanId = PAN_ID;

sMcpsReqRsp.uParam.sReqData.sFrame.sSrcAddr.uAddr.u16Short =

MyAdd;

sMcpsReqRsp.uParam.sReqData.sFrame.sDstAddr.u8AddrMode = 2;

sMcpsReqRsp.uParam.sReqData.sFrame.sDstAddr.u16PanId = PAN_ID;

sMcpsReqRsp.uParam.sReqData.sFrame.sDstAddr.uAddr.u16Short =

DestAdd ;

sMcpsReqRsp.uParam.sReqData.sFrame.u8TxOptions =

MAC_TX_OPTION_ACK;

pu8Payload = sMcpsReqRsp.uParam.sReqData.sFrame.au8Sdu;

pu8Payload [0] = p_num;

i =0;

for (j = 1; j < tr_count; j++)

{

pu8Payload[j] = tr_str[i];

i++;

}

sMcpsReqRsp.uParam.sReqData.sFrame.u8SduLength = tr_count;

vAppApiMcpsRequest(&sMcpsReqRsp, &sMcpsSyncCfm);


vUART_StartTx();*/

}

PUBLIC uint8 u8ButtonRead(void)

{

uint32 u32DioPins;

uint8 u8RetVal = 0;

56 | P a g e

u32DioPins = (u32AHI_DioReadInput() & BUTTON_ALL_MASK_RFD_PIN) ^

BUTTON_ALL_MASK_RFD_PIN;

if(u32DioPins & BUTTON_0_PIN) u8RetVal |= BUTTON_0_MASK;

if(u32DioPins & BUTTON_1_PIN) u8RetVal |= BUTTON_1_MASK;

return(u8RetVal);

}

PUBLIC void ShowReceivePacket(MAC_RxFrameData_s *psFrame)

{

char re_str[100],buffer[50];

static pos;

uint8 count1;

uint16 adcdata;

uint16 buff_temp[50];

uint16 SrcAdd,DstAdd;

uint8 LQI,PID,i,j,count;

for(i=0;i<10;i++)

buffer[i] = 0;

DstAdd = psFrame->sDstAddr.uAddr.u16Short;

SrcAdd = psFrame->sSrcAddr.uAddr.u16Short;

LQI = psFrame->u8LinkQuality;

count = psFrame->u8SduLength;

PID = psFrame->au8Sdu[0];

j =0;

for(i=1;i<count;i++)

{

re_str[j] = psFrame->au8Sdu[i];

j++;

}

re_str[j] = '\0';

vSerialQ_AddString(TX_QUEUE,"From:");

vSerialQ_AddHex(TX_QUEUE,SrcAdd,4);

vSerialQ_AddItem(TX_QUEUE,',');

vSerialQ_AddHex(TX_QUEUE,DstAdd,4);


vSerialQ_AddString(TX_QUEUE,"p_num:");

vSerialQ_AddHex(TX_QUEUE,PID,2);


vSerialQ_AddString(TX_QUEUE,"LQI:");

vSerialQ_AddHex(TX_QUEUE,LQI,2);


vSerialQ_AddString(TX_QUEUE,"Packet Data:");

vSerialQ_AddString(TX_QUEUE,re_str);


vUART_StartTx();

if(re_str[0]=='$')

{

switch(re_str[2])

{

case ('0') :{

57 | P a g e

uint8 data1[]=" Exp Started";

transmitt_packet(SrcAdd,&data1[0],14);

break;}

case ('1'):{

uint8 data1[]=" Device Configured";


break;}

case ('2'):

{

uint8 data1[]=" I Am alive";


break;}

case ('3'):

{

uint8 data1[]=" Hello.....";


break;}

case ('4'):

{

uint8 data1[]="Sending n packets";

j=re_str[4];

j= j & 0x0f;

j=j*10;

i=re_str[5];

i= i & 0x0f;

j=j+i;

for(i=0;i<j;i++)

{transmitt_packet(SrcAdd,&data1[0],20);}

break;}

case ('5'):

{

uint16 m;

uint8 temp2[6];


j=re_str[4];

j= j & 0x0f;

j=j*10;

i=re_str[5];

i= i & 0x0f;

j=j+i;

for(i=0;i<j;i++)

{


SRC_TEMP);







buff_temp[i]=adcdata;

m=adcdata/10; //1234

58 | P a g e

b1=adcdata%10; // 5

b2=m%10; // 4

m=m/10; // 123

b3=m%10; // 3

m=m/10; // 12

b4=m%10; // 2

m=m/10; // 1

b5=m;

b1 = b1 | 0x30;

b2 = b2 | 0x30;

b3 = b3 | 0x30;

b4 = b4 | 0x30;

b5 = b5 | 0x30;

temp2[0]=b4;

temp2[1]=b3;

temp2[2]='.';

temp2[3]=b2;

temp2[4]=b1;

transmitt_packet(SrcAdd,&temp2[0],6);

vUART_StartTx();

}

printdata(buff_temp,j);

break;

}

case ('6'):

{

uint16 m;

uint8 temp2[6];


j=re_str[4];

j= j & 0x0f;

j=j*10;

i=re_str[5];

i= i & 0x0f;

j=j+i;

re_str[2]='7';

for(i=0;i<j;i++)

{


SRC_TEMP);







buff_temp[i]=adcdata;

m=adcdata/10; //1234

b1=adcdata%10; // 5

59 | P a g e

b2=m%10; // 4

m=m/10; // 123

b3=m%10; // 3

m=m/10; // 12

b4=m%10; // 2

m=m/10; // 1

b5=m;

b1 = b1 | 0x30;

b2 = b2 | 0x30;

b3 = b3 | 0x30;

b4 = b4 | 0x30;

b5 = b5 | 0x30;

re_str[10]=b4;

re_str[11]=b3;

re_str[12]='.';

re_str[13]=b2;

re_str[14]=b1;

transmitt_packet(SrcAdd,&re_str[0],16);

vUART_StartTx();}

break;}

}

}

}

PUBLIC uint8 read_key(void)

{

uint8 key;

key = 0;

key = u8ButtonRead();

if(key !=0)

{

do

{

mydelay(1);

}while(u8ButtonRead()!=0);

}

return key;

}

PUBLIC void LCD_SCR0(void)

{

char initMsg[40];

strcpy(&initMsg[0],"Line 1 message ");

write_message(&initMsg[0],20,1);

}

PUBLIC void mydelay(unsigned int del)

{

uint32 x;

do{

for(x=0;x<0xffff;x++);

60 | P a g e

del--;

}while(del != 0);

}

PUBLIC void set_timer0_repeat(uint8 times)

{

vAHI_TimerEnable(E_AHI_TIMER_0,20,FALSE,TRUE,FALSE);

vAHI_TimerClockSelect(E_AHI_TIMER_0,FALSE,FALSE);

vAHI_Timer0RegisterCallback(vTimer0ISR);

vAHI_TimerStartRepeat(E_AHI_TIMER_0,0xffff,0xffff);

u32AHI_Init();

}

PUBLIC uint8 vTimer0ISR()

{ timecount++;

vSerialQ_AddHex(TX_QUEUE,timecount,2);

vUART_StartTx();

f=~f;

vRx_TxLED2(f);

if(timecount==05)

{

vUART_StartTx();

vAHI_TimerStop(E_AHI_TIMER_0);

vRx_TxLED2(on);

vSerialQ_AddString(TX_QUEUE,"\n\rMissing Packets= ");

vdispdata((timeout)-(counter),4,4);

vSerialQ_AddString(TX_QUEUE,"\n\rTotal Requested=");

vdispdata((timeout),4,4);

vSerialQ_AddString(TX_QUEUE,"\n\rTotal Recevd=");

vdispdata((counter),4,4);

vUART_StartTx();

counter=0;

timecount=0;

}

}

APPQUEUEAPI.C

#include "jendefs.h"

#include "mac_sap.h"

#include "AppHardwareApi.h"

#include "AppQueueApi.h"

#include "AppApi.h"

#define APP_MAX_MLME_IND 5

#define APP_MAX_MCPS_IND 5

#define APP_MAX_HW_IND 5

typedef struct

{

void **ppvReadPtr;

61 | P a g e

void **ppvWritePtr;

void **ppvQueueStart;

void **ppvQueueEnd;

} tsSFqueue;

PRIVATE MAC_DcfmIndHdr_s* psAppQApiGetMlmeBuffer(void *pvParam);

PRIVATE MAC_DcfmIndHdr_s* psAppQApiGetMcpsBuffer(void *pvParam);

PRIVATE void vAppQApiPostMlme(void *pvParam, MAC_DcfmIndHdr_s

*psDcfmIndHdr);

PRIVATE void vAppQApiPostMcps(void *pvParam, MAC_DcfmIndHdr_s

*psDcfmIndHdr);

PRIVATE void vFifoInit(tsSFqueue *psQueue, void **ppvDataStart, uint8

u8Entries);

PRIVATE void *pvFifoPull(tsSFqueue *psQueue);

PRIVATE bool_t bFifoPush(tsSFqueue *psQueue, void *pvData);

MAC_MlmeDcfmInd_s asMlmeIndBuffer[APP_MAX_MLME_IND];

MAC_McpsDcfmInd_s asMcpsIndBuffer[APP_MAX_MCPS_IND];

AppQApiHwInd_s asHwIndBuffer[APP_MAX_HW_IND];

tsSFqueue sMlmeIndBufferQueue;

tsSFqueue sMcpsIndBufferQueue;

tsSFqueue sHwIndBufferQueue;

void *apvMlmeIndBufferData[APP_MAX_MLME_IND + 1];

void *apvMcpsIndBufferData[APP_MAX_MCPS_IND + 1];

void *apvHwIndBufferData[APP_MAX_HW_IND + 1];

tsSFqueue sMlmeIndQueue;

tsSFqueue sMcpsIndQueue;

tsSFqueue sHwIndQueue;

void *apvMlmeIndData[APP_MAX_MLME_IND + 1];

void *apvMcpsIndData[APP_MAX_MCPS_IND + 1];

void *apvHwIndData[APP_MAX_HW_IND + 1];

PR_QIND_CALLBACK prAppMlmeCallback;

PR_QIND_CALLBACK prAppMcpsCallback;

PR_HWQINT_CALLBACK prAppHwCallback;

PUBLIC uint32 u32AppQApiInit(PR_QIND_CALLBACK prMlmeCallback,

PR_QIND_CALLBACK prMcpsCallback,

PR_HWQINT_CALLBACK prHwCallback)

{

int i;

vFifoInit(&sMlmeIndBufferQueue, apvMlmeIndBufferData,

APP_MAX_MLME_IND);

for (i = 0; i < APP_MAX_MLME_IND; i++)

{

bFifoPush(&sMlmeIndBufferQueue, (void *)&asMlmeIndBuffer[i]);

}

vFifoInit(&sMcpsIndBufferQueue, apvMcpsIndBufferData,

APP_MAX_MCPS_IND);

for (i = 0; i < APP_MAX_MCPS_IND; i++)

{

bFifoPush(&sMcpsIndBufferQueue, (void *)&asMcpsIndBuffer[i]);

}

62 | P a g e

vFifoInit(&sHwIndBufferQueue, apvHwIndBufferData, APP_MAX_HW_IND);

for (i = 0; i < APP_MAX_HW_IND; i++)

{

bFifoPush(&sHwIndBufferQueue, (void *)&asHwIndBuffer[i]);

}

vFifoInit(&sMlmeIndQueue, apvMlmeIndData, APP_MAX_MLME_IND);

vFifoInit(&sMcpsIndQueue, apvMcpsIndData, APP_MAX_MCPS_IND);

vFifoInit(&sHwIndQueue, apvHwIndData, APP_MAX_HW_IND);

prAppMlmeCallback = prMlmeCallback;

prAppMcpsCallback = prMcpsCallback;

prAppHwCallback = prHwCallback;

vAHI_SysCtrlRegisterCallback(vAppQApiPostHwInt);

vAHI_APRegisterCallback(vAppQApiPostHwInt);

#ifndef GDB

vAHI_Uart0RegisterCallback(vAppQApiPostHwInt);

#endif

vAHI_Uart1RegisterCallback(vAppQApiPostHwInt);

vAHI_TickTimerInit(vAppQApiPostHwInt);

vAHI_SpiRegisterCallback(vAppQApiPostHwInt);

vAHI_SiRegisterCallback(vAppQApiPostHwInt);

vAHI_Timer0RegisterCallback(vAppQApiPostHwInt);

vAHI_Timer1RegisterCallback(vAppQApiPostHwInt);

return u32AppApiInit(psAppQApiGetMlmeBuffer, vAppQApiPostMlme, NULL,

psAppQApiGetMcpsBuffer, vAppQApiPostMcps, NULL);

}

PUBLIC MAC_MlmeDcfmInd_s *psAppQApiReadMlmeInd(void)

{

return (MAC_MlmeDcfmInd_s *)pvFifoPull(&sMlmeIndQueue);

}

PUBLIC MAC_McpsDcfmInd_s *psAppQApiReadMcpsInd(void)

{

return (MAC_McpsDcfmInd_s *)pvFifoPull(&sMcpsIndQueue);

}

PUBLIC AppQApiHwInd_s *psAppQApiReadHwInd(void)

{

return (AppQApiHwInd_s *)pvFifoPull(&sHwIndQueue);

}

PUBLIC void vAppQApiReturnMlmeIndBuffer(MAC_MlmeDcfmInd_s *psBuffer)

{

bFifoPush(&sMlmeIndBufferQueue, (void *)psBuffer);

}

PUBLIC void vAppQApiReturnMcpsIndBuffer(MAC_McpsDcfmInd_s *psBuffer)

{

bFifoPush(&sMcpsIndBufferQueue, (void *)psBuffer);

}

PUBLIC void vAppQApiReturnHwIndBuffer(AppQApiHwInd_s *psBuffer)

63 | P a g e

{

bFifoPush(&sHwIndBufferQueue, (void *)psBuffer);

}

PUBLIC void vAppQApiPostHwInt(uint32 u32Device, uint32 u32ItemBitmap)

{

AppQApiHwInd_s *psBuffer;

if ((u32Device == E_AHI_DEVICE_UART0) || (u32Device ==

E_AHI_DEVICE_UART1))

{

if ((u32ItemBitmap == E_AHI_UART_INT_RXDATA)

|| (u32ItemBitmap == E_AHI_UART_INT_TIMEOUT))

{

uint8 u8ActiveUart;

if (u32Device == E_AHI_DEVICE_UART0)

{

u8ActiveUart = E_AHI_UART_0;

}

else

{

u8ActiveUart = E_AHI_UART_1;

}

u32ItemBitmap |=

(((uint32)u8AHI_UartReadData(u8ActiveUart)) << 8);

}

}

psBuffer = (AppQApiHwInd_s *)pvFifoPull(&sHwIndBufferQueue);

if (psBuffer != NULL)

{

psBuffer->u32DeviceId = u32Device;

psBuffer->u32ItemBitmap = u32ItemBitmap;

bFifoPush(&sHwIndQueue, (void *)psBuffer);

}

if (prAppHwCallback != NULL)

{

prAppHwCallback();

}

}

PRIVATE MAC_DcfmIndHdr_s* psAppQApiGetMlmeBuffer(void *pvParam)

{

return (MAC_DcfmIndHdr_s *)pvFifoPull(&sMlmeIndBufferQueue);

}

PRIVATE MAC_DcfmIndHdr_s* psAppQApiGetMcpsBuffer(void *pvParam)

{

return (MAC_DcfmIndHdr_s *)pvFifoPull(&sMcpsIndBufferQueue);

}

PRIVATE void vAppQApiPostMlme(void *pvParam, MAC_DcfmIndHdr_s

*psDcfmIndHdr)

64 | P a g e

{

bFifoPush(&sMlmeIndQueue, (void *)psDcfmIndHdr);

if (prAppMlmeCallback != NULL)

{

prAppMlmeCallback();

}

}

PRIVATE void vAppQApiPostMcps(void *pvParam, MAC_DcfmIndHdr_s

*psDcfmIndHdr)

{

bFifoPush(&sMcpsIndQueue, (void *)psDcfmIndHdr);

if (prAppMcpsCallback != NULL)

{

prAppMcpsCallback();

}

}

PUBLIC void vFifoInit(tsSFqueue *psQueue, void **ppvDataStart, uint8

u8Entries)

{

psQueue->ppvReadPtr = &ppvDataStart[0];

psQueue->ppvWritePtr = &ppvDataStart[0];

psQueue->ppvQueueStart = &ppvDataStart[0];

psQueue->ppvQueueEnd = &ppvDataStart[u8Entries];

}

PUBLIC void *pvFifoPull(tsSFqueue *psQueue)

{

void *pvRetVal;

if (psQueue->ppvReadPtr == psQueue->ppvWritePtr)

{

return (void *)NULL;

}

pvRetVal = *(psQueue->ppvReadPtr);

if (psQueue->ppvReadPtr == psQueue->ppvQueueEnd)

{

psQueue->ppvReadPtr = psQueue->ppvQueueStart;

}

else

{

psQueue->ppvReadPtr++;

}

return pvRetVal;

}

PUBLIC bool_t bFifoPush(tsSFqueue *psQueue, void *pvData)

{

if (psQueue->ppvWritePtr == psQueue->ppvQueueEnd)

{

if (psQueue->ppvReadPtr == psQueue->ppvQueueStart)

{

65 | P a g e

return FALSE;

}

}

else

{

if (psQueue->ppvReadPtr == (psQueue->ppvWritePtr + 1))

{

return FALSE;

}

}

if (psQueue->ppvWritePtr == psQueue->ppvQueueEnd)

{

psQueue->ppvWritePtr = psQueue->ppvQueueStart;

}

else

{

psQueue->ppvWritePtr++;

}

return TRUE;

}

9.2 SCREEN SHOTS

Fig R. Configuring the Hardware

66 | P a g e

Fig S. Pinging all the End Devices

Fig T. Get temperatures of all the End Devices

67 | P a g e

Fig U. Sending n packets to the End Devices

Fig V. Hop by Hop Data Transmission

68 | P a g e

Fig W. Displaying the retrieved data on Tera Term along with GUI

CHAPTER 10 CONCLUSION AND FUTURE SCOPE

The main focus of our project is to sense the core temperature of the end devices and report it

to the sink. We can also attach the parameters like humidity, link quality, battery power,

source and destination addresses as a part of payload. The ease of hardware configuration

and data acquisition is maximized with the help of a Graphical User Interface which acts as a

Testbed Application. We can retrieve the data by using soft commands and display it on

terminal. Hence the overhead of using applications like Jennic Flash Programmer and

TeraTerm is minimized. The future enhancement to our project is to store the sensed data

directly on cloud.

69 | P a g e

ANNEXURE A: PROJECT ANALYSIS OF ALGORITHM DESIGN

1. FEASIBILITY ASSESSMENT AND SWOT ANALYSIS

Problem statement feasibility assessment using NP-hard and NP-complete

A. FEASIBILITY STUDY

Feasibility is the determination of whether or not a project is worth doing. The process

followed in making this determination is called Feasibility Study. This type of study is to

determine if the project can and should be taken. In the conduct of the feasibility study, the

analyst usually considers seven distinct, but inter-related types of feasibility.

The feasibility study can be performed in three ways such as Operational Feasibility,

Technical feasibility and Economical Feasibility.

1. OPERATIONAL FEASIBILITY

1.1 Algorithm 1: ESRT (Event-to-Sink Reliable Transport) Protocol

k = 1;

ESRT()

If (CONGESTION)

If (η < 1) /* State=(C, LR) */

f = f η/k; /* Decrease Reporting Frequency Aggressively */

k = k + 1;

else if (η > 1) /* State=(C, HR) */

k = 1;

f = f / η ; /* Decrease Reporting Frequency to Relieve Congestion */

end; /*No Compromise on Reliability */

else if (NO CONGESTION)

k = 1;

If (η < 1 - ϵ ) /* State=(NC,LR) */

f = f / η ; /* Increase Reporting Frequency Aggressively */

else if (η > 1 + ϵ ) /* State=(NC,HR) */

f = f/2 (1 + (1/ η)); /* Decrease Reporting Frequency Cautiously */

end;

else if (1-ϵ ≤ η ≤ 1+ ϵ) /* Optimal Operating Region */

f = f; /* Hold Reporting Frequency */

end;

end;

70 | P a g e

1.2 Description

Using the decision boundaries previously defined. Depending on the current state Si, and the

values of fi (reporting frequency for decision interval i) and ηi (Reliability indicator ηi

computed by the sink for decision interval i), ESRT then calculates the updated reporting

frequency fi+1 to be broadcast to the source nodes. At the end of the next decision interval,

the sink derives a new reliability indicator ηi+1 corresponding to the updated reporting

frequency fi+1 of source nodes. In conjunction with any congestion reports, ESRT then

determines the new network state Si+1. This process is repeated until the optimal operating

region is reached.

1.3 Algorithm 2: Centralized Rate Adaption

Input:

{Pdrop}: packet drop rate vector

{Qbuf}: buffer occupancy vector

Output:

ƛ: updated reporting rate

1. for each update each period Tupd do

2. calculate avg({Pdrop}) and ({Qbuf});

3. if avg({Pdrop}) ≥ Pmax then

4. ƛ = ƛ / (1 + avg({Qbuf}) / Lbuf)2;

5. broadcast updated ƛ;

6. else if avg({Pdrop}) < Pmin holds for 3Tupd then

7. ƛ = ƛ + ∂;

8. broadcast updated ƛ;

9. end if

10. end for

1.4 Description

In the above algorithm, each sensor node calculates its average buffer occupancy Qbuf over a

certain period and encapsulates this value into each outgoing packet. Qbuf is calculated as

follows: Qbuf = (1 - ω)Qbuf + ω q, where ω is a weight coefficient and q is the instantaneous

buffer occupancy. The sink only catches the value of the latest received Qbuf for each sensor.

It can calculate the packet drop rate Pdrop for each sensor node based on the number of

packets received from that node and the number of packets expected to be received from that

node during the last period Tupd, based on the reporting rate that it allocated last time and the

71 | P a g e

value of Tupd. At the end of each update period Tupd, the sink performs this algorithm to

adjust the reporting rate ƛ of each sensor node. In above algorithm, Lbuf is the buffer size and

∂ is the step-size of rate increment.

2. TECHNICAL FEASIBILITY

We can strongly say that it is technically feasible, since there will not be much difficulty in

getting required resources for the development and maintaining the system as well. All the

resources needed for the development of the software as well as the maintenance of the same

is available in the organization here we are utilizing the resources which are available

already.

Technical Feasibility is considered with specifying equipment and software that will

successful satisfy the user requirement the technical needs of the system may vary

considerably but might include

o The facility to produce outputs in a given time.

o Response time under certain conditions.

o Ability to process a certain column of transaction at a particular speed.

o

Programming Language used: C (Front end), C# (Back end)

Hardware : Jennic JN5139

Technology : ZigBee

OS : Working on Run-Time Environment

Platform : Windows

3. ECONOMICAL FEASIBILITY

Development of this application is highly economically feasible .The organization needed not

spend much m money for the development of the system already available. The only thing is to

be done is making an environment for the development with an effective supervision. If we are

doing so, we can attain the maximum usability of the corresponding resources .Even after the

development, the organization will not be in a condition to invest more in the organization.

Therefore, the system is economically feasible.

72 | P a g e

B. SWOT ANALYSIS

STRENGTHS

o Easy to operate

o No need of specialized or technical manpower

o The working of the instruments not sensitive to weather conditions

o Ruggedness level is high

o No interference from external electromagnetic signals

o Readily available technology

o Stable technology

WEAKNESS

o Higher power consumption

o Transmission channel factors

o Limited location coverage

o Higher cost

o Increase in traffic decreases network lifetime

o Restricted energy resource

OPPORTUNITY

o Automation in data collection and processing

o Data analysis can be made available to the end users with its precautionary

features.

o A low power consumption solution

o To design a low cost solution

o Solution providing maximum coverage area

THREATS

o A low frequency data might lead to wrong results and conclusions

o Limited area coverage of measurements may give us an incorrect temperature

reading.

73 | P a g e

ANNEXURE B: PROJECT QUALITY AND RELIABLITY TESTING OF

PROJECT DESIGN

Test Cases:

1. Get Temperature of particular node

Here, the master request for temperature data from particular node.

2. Get Temperature of group of nodes

Here, each and every device sends the temperature data to the master device.

3. Pinging a specific node

Here, the master pings the specific device to check whether it is alive or not.

4. Pinging a group of nodes

The master pings all devices to check whether they are alive or not.

5. Broadcast a message

This message broadcasts the message to all the devices.

6. Sending a message by

a. End-to-End method

Here, the end device sends the data directly to master device.

b. Hop-by-Hop method

Here, the end device sends the data to master device through router.

74 | P a g e

ANNEXURE C: PROJECT PLANNER AND PROGRESS REPORT

1. PROJECT PLANNER

Table E: Project Planner

75 | P a g e

2. INDIVIDUAL CONTRIBUTION

No

NAME OF

MODULE

MODULE Description in brief Responsible

Student Name for

module

Duration

of

completion

1.

2.

GUI Design

(Configuring

Module,

Instructing

using soft-

commands,

Displaying

results on

Terminal)

a)Sensing

Temperature

b)Checking

Battery

consumption

c)End to End

data transfer

d)Hop by

Hop Data

transfer

e)Handling

Process event

queue

Configuring Module includes

setting Port Number, Baud Rate,

Parity and Stop Bits. As well as

soft commands include 1.Get

Temperature of particular node

2. Get Temperature of group of

nodes

3. Pinging a specific node

4. Pinging a group of nodes

5. Broadcast a message

6. Sending a message by

a. End-to-End method

b. Hop-by-Hop method

This module contains function

which will sense the core

temperature and display the result

on UI.

The function of this module is to

continuously monitor the battery

consumption and report it to the

master device.

This function is used to send the

data from end device to master

device directly.

The main goal of this function is

send the data from end device to

router and then router will forward

that data to master device. This

function is used to manage the

packet loss if the end device is at

longer distance from master

service.

In this function each and every

data packet reported to the master

is displayed on the UI by

efficiently handling the process

1)Rutvik

Pensionwar

2)Pranav

Tambat

1)Nilesh Thite

2)Onkar

Tummanpalli

15 Jan’15

To

15 Mar’15

15 Jan’15

To

15 Mar’15

76 | P a g e

3.

Paper

Presentation

and

Submission

event queue.

Analyzing the simulation results

on the basis of work done and

presenting an efficient way for

achieving reliability. Crafting all

these things in a single paper,

presenting and submitting it to an

International Journal.

1)Rutvik

Pensionwar

2)Pranav

Tambat

15 Mar’15

To

25 Mar’15

Table F: Individual Contribution

11. REFERENCES (Papers, Documents, Online Links)

[1]ECODA: Enhanced Congestion Detection and Avoidance for Multiple Class of Traffic in

Sensor Networks by Li Qiang Tao, Feng Qi Yu

[2]CODA: Congestion Detection & Avoidance in Sensor Networks by Chieh-Yih Wan, Shane B.

Eisenman, Andrew T. Camp

[3]Event-to-Sink Reliable Transport in WSNs by Özgür B. Akan, Ian F. Akyildiz

[4]Rate-constrained uniform data collection in wireless sensor networks by H. Deng, B. Zhang,

J. Zheng

[5]Priority Enabled Transport Layer Protocol for Wireless Sensor Network by Atif Sharif,

Vidyasagar Potdar, A.J.D.Rathnayaka.

[6] JN-RN-0010-SDK-Toolchain-1v1 [http://www.jennic.com/files/support_documentation/JN-

RN-0010-SDK-Toolchain-1v1.pdf]

[7] JN-RN-0011-SDK-Libraries-1v5 [http://www.jennic.com/files/support_documentation/JN-

RN-0011-SDK-Libraries-1v5.pdf]

[8] JN-UG-3007-Flash-Programmer [http://www.nxp.com/documents/user_manual/JN-UG-

3007.pdf]

[9] JN-UG-3028-CodeBlocks-1v8 [http://www.jennic.com/files/support_files/JN-UG-3028-

CodeBlocks-1v8.pdf]

[10] JN-RM-2025-App-Queue-API-1v0 [http://www.jennic.com/files/support_files/JN-RM-

2025-App-Queue-API-1v0.pdf]

77 | P a g e

12. GLOSSARY

1. WSN (Wireless Sensor Network): These are spatially distributed autonomous sensors to

monitor physical or environmental conditions, such as temperature, sound, pressure, etc. and to

cooperatively pass their data through the network to the main location.

2. QoS (Quality of Service): It is overall performance of a telephony or computer network,

particularly the performance seen by the users of the network.

3. H-B-H (Hop-By-Hop): This transport type is the principle of controlling the flow of data in a

network. With hop-by-hop transport, chunks of data are forwarded from node to node in a store-

and-forward manner.

4. E-T-E (End-To-End): This principle is a classic principle in computer networking which states

that application specific functions ought to reside in the end hosts of a network rather than in

intermediary nodes, provided that they can be implemented “completely and correctly” in the

end hosts.

5. NS (Network Simulator): It is a technique where a program models the behavior of the

network either by calculating the interaction between the different network entities using

mathematical formulas or observations from production network.

Complete report on DATA ACQUISITION SCHEME IN WIRELESS SENSOR NETWORK

Engineering

Transcript of Complete report on DATA ACQUISITION SCHEME IN WIRELESS SENSOR NETWORK