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

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

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:Jenniccygwinjennic. If required, you can specify another drive but must keep the
Jenniccygwinjennic path (e.g. D: Jenniccygwinjennic).
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.

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 "sourcecommonIOMAP.h"
#include "sourcecommonwuart.h"
#include "SourceCommonComm_code.h"
#include "sourcecommonserialq.h"
#include "sourcecommonuart.h"
#include "SourceCommonlcd_drv.h"
#include "SourceCommonSMBus.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,"nr");
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,"nrTemperature=");
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,"nrBatt.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,"nrThe 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,"nrThe 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,"Receivednr");
vUART_StartTx();
ShowReceivePacket(psRxFrame);
}
if(psMcpsInd->u8Type == MAC_MCPS_DCFM_DATA)
{
if(psMcpsInd->uParam.sDcfmData.u8Status == MAC_ENUM_SUCCESS)
{
vSerialQ_AddString(TX_QUEUE,"Transmitt successfullnr");
vUART_StartTx();
}

55 | P a g e
}
if(psMcpsInd->uParam.sDcfmData.u8Status == MAC_ENUM_NO_ACK)
{
vSerialQ_AddString(TX_QUEUE," Packet could not be sentnr");
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,"nrMissing Packets= ");
vdispdata((timeout)-(counter),4,4);
vSerialQ_AddString(TX_QUEUE,"nrTotal Requested=");
vdispdata((timeout),4,4);
vSerialQ_AddString(TX_QUEUE,"nrTotal 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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (7)

Ähnlich wie Complete report on DATA ACQUISITION SCHEME IN WIRELESS SENSOR NETWORK

Ähnlich wie Complete report on DATA ACQUISITION SCHEME IN WIRELESS SENSOR NETWORK (20)

Mehr von Rutvik Pensionwar

Mehr von Rutvik Pensionwar (7)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Complete report on DATA ACQUISITION SCHEME IN WIRELESS SENSOR NETWORK