ECE4007 Final Paper

Final Report
HEAT SENSING WIRELESS NETWORK
ECE4007 Senior Design Project
Section L02, Heat Sensor Team
Gautam Ankala
Jessica Curry
Joseph Roberson
Submitted
9 December 2008
Heat Sensor Group (ECE 4007 L02)

TABLE OF CONTENTS
Executive Summary..........................................................................................................iii
1. Introduction..................................................................................................................1
1.1 Objective .........................................................................................................1
1.2 Motivation .......................................................................................................2
1.3 Background .....................................................................................................2
2. Project Description and Goals ...................................................................................3
3. Technical Specification................................................................................................5
4. Design Approach and Details
4.1 Design Approach ............................................................................................8
4.2 Codes and Standards......................................................................................10
4.3 Constraints, Alternatives, and Tradeoffs .......................................................11
5. Schedule, Tasks, and Milestones...............................................................................11
6. Project Demonstration...............................................................................................12
7. Marketing and Cost Analysis....................................................................................15
7.1 Marketing Analysis.........................................................................................15
7.2 Cost Analysis .................................................................................................15
8. Summary.....................................................................................................................17
9. References...................................................................................................................18
Appendix A......................................................................................................................19
Appendix B......................................................................................................................22
Appendix C......................................................................................................................24
Appendix D......................................................................................................................30
Heat Sensor Group (ECE 4007 L02) ii

EXECUTIVE SUMMARY
Wireless sensor networks contain small devices equipped with components for
sensing, calculating, and wireless transfer. The Heat Sensor team designed a wireless
sensor network that could be used to detect hazardous thermal activity in buildings and
specifically, environmental areas such as forests. The design was implemented using the
TinyOS operating system. A java based software call Moteview was used to display the
temperature readings on a computer and the sensors were programmed using the nesC
language. The dimensions of each MICAz mote were 56 mm on the x-axis, 18 mm on
the z-axis, and 36 mm on the y-axis.
The sensors were programmed with an algorithm that enabled the design to
implement an energy proficient network. Crossbow’s MICAz wireless sensors were used
to take data readings and the data was transferred to a computer by use of its wireless
capabilities. A prototype network was designed to show that wireless sensors could
detect hazardous temperatures, based on the varying applications, and wirelessly transfer
the data to the user of the product.
The prototype network consisted of four MICAz sensors for temperature
measurements and a personal computer to display the readings. The heat sensor system
can be provided for a total cost of $2500.00. Since each sensor has an outdoor range of
75 to 100 meters, each unit was capable of monitoring an area up to 10,000 square
meters. The heat sensing network provided reliable detection of fires and real-time
communication at a low cost to the consumer.
Heat Sensor Group (ECE 4007 L02) iii

Heat Sensing Wireless Network
1. INTRODUCTION
Wireless sensor networks are designed for minimal power consumption, low cost,
and small volume. The sensors are small devices equipped with components for sensing,
calculating, and wireless transfer [1]. Used in devices such as thermometers, motion
detectors, and vehicle tracking systems, sensors have become a rapidly developing area in
both research and application. The team used Crossbow’s MICAz wireless sensors to
take temperature readings and transfer the data to a computer by use of its wireless
capabilities. The prototype network consisted of four MICAz sensors for temperature
measurements and a personal computer to display the readings. The design was
implemented using the TinyOS operating system. A java based software call Moteview
was used to display the temperature readings on a computer and the sensors were
programmed using the nesC language. The dimensions of each MICAz mote were 56
mm on the x-axis, 18 mm on the z-axis, and 36 mm on the y-axis.
1.1 Objective
The Heat Sensor team designed a wireless sensor network that could be used to
detect hazardous thermal activity in buildings and environmental areas up to 10,000
square meters. The MICAz motes were adapted with heat sensors and programmed with
an energy efficient algorithm to monitor for possible fires. Sensor data was wirelessly
transmitted through the network and received at personal computer acting as a base
station. The design was a resource for wildlife services and forest agencies as well as
owners of large estates of lands who want to protect their land from possible fires.
Heat Sensor Group (ECE 4007 L02) 1

1.2 Motivation
Advances in technology have decreased the size of wireless sensors, allowing
sensor networks to function in constrained and smaller environments. Parallel to the
advancement in technology is the limit in power and computational capacity of wireless
sensor networks. Reduction of power consumption by individual sensors in the network
is essential for a network to sustain itself for longer periods of time. Incorporating an
energy efficient algorithm in the design reduced power consumption and reduced
maintenance costs due to unwanted shorter network lifetimes [2]. The design team used
an algorithm that enabled the wireless sensors to implement an energy proficient
network, allowing the network to efficiently broadcast information collected by
individual sensors and route the ciphered data to the base station.
1.3 Background
Energy aware routing algorithms are used to increase the energy efficiency of
wireless sensor networks. Today, two common kinds of energy aware routing algorithms
are being researched and implemented in wireless networks. The first type is known as
Low-Energy Adaptive Clustering Hierarchy (LEACH), which aggregates the network
into clusters and randomly rotates the base station inside the cluster to evenly distribute
the workload. LEACH elongates the lifetime of a wireless network twice as long as the
one without an energy aware routing algorithm [2].
The second type is the S-MAC, which is a routing protocol that focuses on saving
energy in the network but does not respond very well to the adaptation of network traffic
[1]. This protocol adjusts the operation cycle of sensors based on the amount of action in
the network. When a sensor is in an idle state, the protocol places the sensor in a sleep

mode that saves energy. A common problem of this algorithm is when the operation
cycle is low and the transfer rate is high, the entire network is restricted [1].
Another common routing protocol is Geographic Routing with Environmental
Energy Supply (GREES). This routing algorithm takes into account the realistic wireless
channel condition, such as random noise and fading, in addition to residual energy and
energy supply conditions of the individual nodes in the network [2]. Since the design
team’s network based its routing decision on heat sensing conditions of the individual
nodes, the algorithm used in the group’s wireless network was similar to the LEACH
algorithm.
2. PROJECT DESCRIPTION AND GOALS
The Heat Sensor team designed a prototype of a thermal detecting wireless sensor
network. The wireless sensors were programmed with an energy efficient routing
algorithm for data transmission and proper detection of high temperatures based on the
application. The wireless network consisted of three intermediate nodes, each equipped
with light sensors, and one transceiver node. The intermediate and transceiver nodes can
be visualized by the four sensors shown in Figure 1. A computer was used as the base
station for the wireless network, in which all data measurements were displayed for the
user. Each intermediate node in the network had the following functionality:
• Routed data to the transceiver node/sensor
• Determined heating conditions using light intensity
• Flashed LED light when forwarding data

The transceiver node/sensor kept record of data received by the intermediate nodes.
Furthermore, the transmitter had the following additional functions:
• Received light conditions from intermediate nodes
• Determined routing path based on received data
• Determined heating conditions using light intensity
• Forwarded all data measurements to the base station
• Determined which sensors have detected hazardous temperatures in its
surroundings and send an alert message.
All communication between the base station and the wireless sensors in the
network were conducted through the transceiver node. The transceiver sensor,
represented by Sensor 4 in Figure 1, received the measurements and requests from the
intermediate sensors and base station, respectively. This sensor also transmitted all
measurements to the base station and communicated with the other wireless sensors. The
base station periodically requested that each node in the network take a reading using the
on board light sensors via the transceiver node. Once each node had taken the reading
and routed the measurements back to the transceiver node, the data was wirelessly sent to
the base station for proper analysis. The block diagram in Figure 1 shows the complete
wireless network communication between each sensor and the base station. If any sensor
had detected an activity higher than a specific threshold, determined by the application of
the network, the base station was alerted of the interruption and the sensor that detected
the value. The goal of the Heat Sensor team was to create a wireless network able to
detect thermal activity using an energy efficient algorithm and wireless devices equipped

with light sensors. The network was cost efficient to the customer and safe to use in
varying environmental conditions.
Figure 1. Block diagram of thermal wireless sensor network.
3. TECHNICAL SPECIFICATIONS
The prototype presented in this project involved a cluster head which was a
transceiver node, and three intermediate nodes equipped with light sensors. The overall
performance of the network greatly depended on the technical features of these
components. Crossbow MICAz, a wireless measurement system, was installed at each of

the four nodes as the central processing unit. The technical specifications for the MICAz
are shown in Table 1 [2]. The MICAz's radio frequency (RF) transceiver offered a high
transmit data rate of 250 kbps in addition to a frequency band that was a globally
compatible industrial, scientific, and medical (ISM) band.
The three intermediate nodes are constructed by connecting each MICAz with a
light sensor. Crossbow's MTS400CB is an environmental sensor board that contains an
accelerometer, a barometric pressure sensor, and an ambient light sensor. The
specifications for this board are given in Table 2 [2].

The MICAz at the transceiver node contained a light sensor and was connected to
Crossbow's MIB520 USB interface board. This board allowed the MICAz to
communicate with a base station, permitting data transfer from the MICAz to a computer.
The specifications for the MIB520 board are displayed in Table 3 [2]. This board
provided a USB connection cable and a 51-pin connector, allowing the computer and the
MICAz mote to communicate with each other.

4. DESIGN APPROACH AND DETAILS
4.1 Design Approach
The design of the heat sensing wireless network was formed into a cluster group.
The transceiver sensor acted as a cluster head and the three intermediate nodes acted as
members of the cluster. TinyOS was the operating system used for the project. The
transceiver node, or cluster head, was connected to a computer or a base station having a
set of codes programmed in TinyOS. The wireless sensors were programmed with an
energy efficient routing algorithm for data transmission and proper detection of high
temperatures. All communication between the base station and the wireless sensors in
the network were conducted through the transceiver node.
Transceiver
The most important feature of the transceiver or the cluster head was the routing
algorithm. The wireless sensors were programmed with an energy efficient routing
algorithm for data transmission and proper detection of high temperatures based on the
application. This algorithm was based on the information packets regarding heat intensity
that are sent every few seconds from the three intermediate nodes. Its decision only
depended on the most recent information packet received by the cluster head. However,
for demonstration purposes, all the received information packets were recorded and
stored in the computer connected to the transceiver node. The information packet
broadcasted from the intermediate nodes included a specific node identification number
in order to specify which node was sending the packet and whether the sensor at that
node was detecting heat. An example of how an information packet was structured is
shown in Figure 2 [2]. The adequate bit length of the node ID was determined according

to the size of the network. Using the information packet, the cluster head sorted the
information received from all the intermediate nodes and transmitted the data to the base
station. The hardware components of the transmitter node include a personal computer
serving as a base station, which records and stores the transmitted data, a MICAz that
serves as a cluster head, and a MIB520 board that allows the computer to communicate
with the MICAz. In addition, a set of code will be written and uploaded onto the MICAz
through the MIB520 board.
Intermediate Nodes
The intermediate nodes each required a MICAz and a light sensor. The code for
these three nodes were uploaded onto the MICAz through the MIB520 board, but once
uploaded, the MIB520 board was removed. As a result, the three intermediate nodes were
incapable of storing large amounts of data. Consequently, the only function of these
nodes was to transmit information packets regarding heat intensity to the cluster head. In
addition, these nodes were programmed to turn on a LED light whenever data was
transmitted through them, which allowed a clear display of the routing path. The
MTS400CB, a basic weather sensor board, was used to represent a heat sensor in this
design. It was connected to the MICAz at each intermediate node. The MICAz stored the
measurements of heat intensity observed by the MTS400CB as numerical data. If this
value was above a certain threshold, then the node was considered to have detected fire

and was ready for data transmission. If the value was below threshold, then the node has
not detected fire, and data was not transmitted. The result is then combined with the node
ID to form a single information packet. This packet is then sent to the cluster head. New
information was obtained every few seconds, and a packet was sent constantly with
newly acquired information. Values for threshold and time period between sequential
information packets had to be decided through actual experiments.
4.2 Codes and Standards
Crossbow MICAz was compliant with the IEEE 802.15.4 and ZigBee standards.
The IEEE 802.15.4 standard was for low data rate networks within a relatively small
area. The main feature of this standard was low power consumption to simulate an energy
efficient network. ZigBee was also a standard designed for low data rate and low power
consumption wireless networks. However, ZigBee set standards for the network and
application layer while IEEE 802.15.4 dealt primarily with the physical layer. The
MICAz operated with an open source operating system called TinyOS which used nesC
as the programming language. The nesC language was designed especially for wireless
embedded sensor networks and featured component based architecture to minimize code
size. TinyOS also had many component libraries containing codes that could be used.
The MIB520, which was also manufactured by Crossbow, was used to upload codes for a
routing algorithm and node transmission onto the MICAz. The MIB520 connected to a
computer through an USB port [2].

4.3 Constraints, Alternatives, and Tradeoffs
Simplicity was the key factor of this project that allowed additional features to be
implemented and options for customizations. MICAz was a simple wireless unit without
any sensors that ran on two AA batteries. Unlike the MICAz, the Heliomote, which was
developed by the research group at University of California, Los Angeles, has built-in
sensors as well as the capability to acquire energy from the environment [2]. Such a
capability was called energy harvesting and was highly effective when incorporated in a
wireless network to increase energy efficiency. However, the Heliomotes have built-in
functionalities that are difficult or even impossible to modify. Also, the MICAz had more
documentations and experimental data on its application and was half the price of the
Heliomote. In order to keep the network as simple as possible and be easily adapted to
specific needs, the MICAz was a better choice for this project. One constraint associated
with the MICAz is that it ran on TinyOS, which was an open source operating system
that required engineers to learn the nesC programming language to be able to control the
MICAz. Nevertheless, TinyOS had many libraries including routing algorithm codes
that engineers can utilize as the basis for their projects and modify them accordingly
rather than starting from scratch.
5. SCHEDULE, TASKS, AND MILESTONES
The Gantt charts for both the proposed and actual schedule of this project can be
found in Appendix A. Table 4 shows that the project was divided into the following
categories: Planning, Design, Development, and Testing. The italicized tasks at the
bottom of the table were considered milestones and were crucial to the project’s

successful completion. Task difficulty was based upon the expected complexity of
design and the amount of research necessary. Weekly status meetings were held to
ensure that all members completed tasks as scheduled. The project was completed later
than the expected deadline due to unexpected difficulties that resulted from learning
TinyOS and coding errors.
Table 4. Lists of Tasks, Corresponding Difficulties, and Lead Engineer.
Task Name Difficulty Lead Engineer

Planning
Define Project low Gautam, Roberson, Curry
Divide Project Into Components low Gautam, Roberson, Curry
Meeting with Faculty low Gautam, Roberson, Curry
Design
Identify sensor types low Gautam
Determine requirements medium Roberson
Identify sensor specifications low Curry
Identify market low Curry
Identify design rules medium Roberson
Research parts low Gautam, Roberson, Curry
Borrow Parts low Gautam
Proposal medium Gautam, Roberson, Curry
Development
Configure sensor layout medium Curry
mount sensors and MIB420 on MICAz low Roberson
Determine routing algorithm high Gautam
Understand TinyOS high Gautam, Roberson, Curry
Interface 1 sensor with PC medium Gautam, Roberson, Curry
Interface 2 sensors with PC high Gautam, Roberson, Curry
Interface 4 sensors with PC high Gautam, Roberson, Curry
Program PC medium Gautam, Roberson, Curry
Testing
Verify data transfer from sensors to computer high Roberson
Verify heat applied to sensors sends correct node
location/temp high Gautam
Verify original requirements met high Curry
6. PROJECT DEMONSTRATION
For the demonstration, a wireless sensor network consisting of a PC and four
MICAz sensors were prototyped to represent a heat detecting wireless network. Three

MICAz sensors served as intermediate sensors and the other served as the cluster head of
the network. A personal computer functioned as the base station. Each heat sensor was
mounted on a MICAz board. The sensors were spaced equidistant from the cluster head.
Data was transmitted through the sensor that had the heat source applied. Once the heat
source was applied, the LED at that sensor flashed to verify data passing through the
node. Data reached the cluster head, Node D in Figure 4, and transferred the node
location and heat intensity to the PC.
Figure 4. Data Routing from Node A.
The following situations and corresponding results were performed in the demonstration
(reference Figure 4 above):
• Node A detects heat; data was routed from node A to D.
• Node B detects heat; the data was routed from node B to D.

• Both node A and B detect heat; the data was routed through node D.
• No node detects the heat source; the receiver did not specify any location.
Moteview, a software tool that provides graphical interface and client application
between a user and a deployed network of wireless sensors motes, was used to display the
network topology. Figure 5 shows the network topology of the sensor network with three
sensors showing their corresponding temperature readings.
Figure 5. Network Topology in Mote-View.
The temperature readings were also demonstrated using a tabular form as shown in
Figure 6. An alert window was generated when the temperature of any sensor reached a
threshold of 40 degrees Celsius.

Figure 6. Sensor readings in a tabulated form.
7. MARKETING AND COST ANALYSIS
7.1 Marketing Analysis
Currently, wildfire detection units exist on the market. The one closest to the goal
of using wireless sensors is the FireBug system, which is still in development [5]. The
FireBug system uses TinyOS to program the sensors, but there is no GPS device on
board. The sensor nodes will already have a predetermined location and in the event of a
fire, the node temperature and its corresponding location will be known. The FireBug
system uses the Crossbow MTS420CA board while the group’s project will use the
MTS400CB board. The only difference between the two boards is the GPS capability
between the boards [6]. Consumers will request varying numbers of sensors depending
upon the area necessary to be monitored. For simplicity, one unit will consist of three
sensor nodes and one transceiver node. Since each sensor has an outdoor range of 75m to
100m, each unit will be able to monitor an area up to 10 000 square meters [7].
7.2 Cost Analysis
A prototype of the heat sensor system can be provided for a total cost of
$14517.00. The equipment can be purchased for $1392.00 and total cost of labor is
$13125.00, which is shown in Table 5 and Table 6. Since TinyOS is an open source
component-based operating system, downloading the program is free [2].

Table 5. Prototype Design Equipment Cost.
Unit Total
Component Quantity Cost Cost
TinyOS 2.0 3 $0.00 $0.00
MICAz 2.4 GHZ 4 $99.00 $396.00
MIB520 2 $75.00 $150.00
MTS400CB 4 $210.00 $840.00
Pack of 8 AA Batteries 1 $6.00 $6.00
Total Equipment Cost $1,392.00
The three engineers working on this project each receive pay at a rate of $35.00 per hour.
Work hours for each engineer include lectures, reports, meetings, and design and testing.
Table 6. Labor Cost.
Labor
Project Component Labor Hours Cost
Lectures 75 $2,625.00
Reports 90 $3,150.00
Meetings 60 $2,100.00
Design and Testing 150 $5,250.00
Total Labor 375 $13,125.00
The analysis for the development cost is shown in Table 7. Total development costs will
include parts, labor, fringe benefits, and overhead.
Table 7. Development Cost.
Development Cost (Non-recurring Cost)

Parts $1,392.00
Labor $13,125.00
Fringe Benefits, 20% of Labor $2,625.00
Subtotal $17,142.00
Overhead, 40% of Material, Labor, & Fringe $6,856.80
Total $23,998.80

Table 8 shows the analysis of selling 400 units over a five year time period. Total
revenues for selling 400 units is expected to be $1,000,000.00 with profits of 10.44% that
totals $104,325.00 in profit overall.
Table 8. Selling Price and Profits for 400 units.
Price Factor Cost

Parts Cost $1,392.00
Assembly Labor $12.00
Testing Labor $12.00
Total Labor $24.00
Fringe Benefits, 20% of Labor $4.80
Subtotal $1,420.80
Overhead, 40% of Material, Labor, & Fringe $568.32
Subtotal, Input Costs $1,989.12
Sales Expense $250.00
Subtotal, All Costs $2,239.12
Selling Price per unit $2,500.00
Profit per unit $260.88
Total Revenue $1,000,000.00

Total Profit $104,352.00
% Profit 10.44%
8. SUMMARY
The group has successfully completed its project demo with its advisor. Three
temperature sensors, four MICAz boards, and two MIB520 devices have been used.
These three main components met all the specification stated in our proposal. All our
sensors were programmed in TinyOS using nesC as our language. Cygwin was initially
used to test these sensors output the temperature readings. The group then used Mote-
View, a software tool that provides graphical interface and client application between a
user and a deployed network of wireless sensors motes to display the network topology.
Programming in nesC was the primary time commitment of the development process for
our design.

REFERENCES
[1] W. Liao and H. Wang, “An asynchronous MAC protocol for wireless sensor
networks,” J. Netw. Comput. Applicat., vol. 31, no. 4, pp. 807-820, Nov. 2008.
[2] T. To, M. Au, T. Nguyen, and M. Shinotsuka, “Light Sensing Wireless Network,”
Dept. Elect. Eng., Georgia Tech, Georgia, Proposal, Feb. 4, 2008.
[3] R. Rugin, G. Mazzini, “A simple and efficient MAC-routing integrated algorithm

for sensor network”, IEEE International Conference on Communications, vol. 6,
pp. 3499 - 3503, 20- 24 June 2004.
[4] V. Rajendran, K. Obraczka, J.J. Garcia-Luna-Aceves, “Energy Efficient,

Collision-Free Medium Access Control for Wireless Sensor Networks”, Proc.
ACM SenSys 03, pp.181 - 192, Los Angeles, California, 5-7 November 2003.
[5] FireBug Wildland Fire Monitoring System, “Design and Construction of a

Wildfire Instrumentation System Using Networked Sensors,” [Organization
Website], [cited 1 Sep. 2008], Available HTTP:
http://firebug.sourceforget.net/
[6] Crossbow, "Environmental sensor board," MTS420/400 datasheet, Dec. 2003

[Revised Aug. 2007].
[7] Crossbow, "Wireless measurement system," MICAz datasheet, Aug. 2004

[Revised Apr. 2007].
[8] Crossbow, “Crossbow Technology: MICAz 2.4GHz,” [Company Website], [cited

10 Sep. 2008], Available HTTP:
http://www.xbow.com/Products/SelectCountry.aspx?sid=164
[9] Crossbow, “Crossbow Technology: MIB520-USB Gateway,” [Company

Website], [cited 10 Sep. 2008], Available HTTP:
http://www.xbow.com/Products/productdetails.aspx?sid=227
[10] Crossbow, “Crossbow Technology: MTS Sensor Boards,” [Company Website],

[cited 10 Sep. 2008], Available HTTP:
http://www.xbow.com/Products/productdetails.aspx?sid=177

Appendix A: Gantt Chart

Figure A1. Gantt Chart of Proposed Schedule.

Figure A2. Gantt Chart of Actual Schedule.

Appendix B: Instructions for TinyOS Setup and Compiling

Setting up the TinyOS environment
TinyOS is an open source operating system, and the installer can be downloaded from the
official website, located at <http://www.tinyos.net/>. In this project, TinyOS 1.1.11 was
installed first; then, it was upgraded to 1.1.15 because TinyOS 1.1.11 does not support
MICAz. CVS tree is updated to download an entire source library provided by
crossbow, the hardware manufacturer of MICAz and MTS400 sensor.
TinyOS 1.1.15 Upgrade

Download rpm file from following url and place it in the tinyos home directory.
(<tos>/home/<user>/)
http://webs.cs.berkeley.edu/tos/dist-1.1.0/tinyos/windows/tinyos-
1.1.15Dec2005cvs1.c gwin.noarch.rpm
Type following command on cygwin. The upgrade will start automatically, and it may
take up to an hour.
rpm --force --ignoreos -Uvh tinyos-1.1.15Dec2005cvs-1.cygwin.noarch.rpm
CVS Tree Update

Type following commands on cygwin. The update will start automatically, and it may
take up to an hour.
cd /opt/ ; mv tinyos-1.x tinyos-1.x-old

cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co -P
tinyos-1.x
Check for Errors

To check if the installation completed without any error, type toscheck on cygwin.
Warning about graphiz version can be ignored.
Program MICAz
To upload a program to MICAz, codes first need to be compiled. To do so, open cygwin
and move to the directory that contains a file to be compiled. Then type make micaz to
compile a file to be uploaded for MICAz motes. Last line of writing TOS image
signifies that a file compiled successfully.
Since TinyOS 1.1.15 does not support MIB520 programming board, command for
MIB510 will be used to upload a code. Once a file is compiled successfully, type
following command:
make micaz reinstall.<nodeID> mib510./dev/ttyS<#-1>
where <nodeID> is optional node ID that can be assigned to MICAz and <#-1> is larger
port number assigned to MIB520 minus 1.

Appendix C: TOSBase

*********************************************************************************
/* TOSBaseM
- captures all the packets that it can hear and report it back to
the UART
- forward all incoming UART messages out to the radio
*/
***********************************************************************
module TOSBaseM {
provides interface StdControl;
uses {
interface StdControl as UARTControl;
interface BareSendMsg as UARTSend;
interface ReceiveMsg as UARTReceive;
interface TokenReceiveMsg as UARTTokenReceive;
interface StdControl as RadioControl;

interface BareSendMsg as RadioSend;
interface ReceiveMsg as RadioReceive;
interface Leds;
}
}
implementation
{
enum {
QUEUE_SIZE = 5
};
enum {
TXFLAG_BUSY = 0x1,
TXFLAG_TOKEN = 0x2
};
TOS_Msg gRxBufPool[QUEUE_SIZE];
TOS_MsgPtr gRxBufPoolTbl[QUEUE_SIZE];
uint8_t gRxHeadIndex,gRxTailIndex;
TOS_Msg gTxBuf;
TOS_MsgPtr gpTxMsg;
uint8_t gTxPendingToken;
uint8_t gfTxFlags;
task void RadioRcvdTask() {

TOS_MsgPtr pMsg;
result_t Result;
dbg (DBG_USR1, "TOSBase forwarding Radio packet to UART\n");

atomic {
pMsg = gRxBufPoolTbl[gRxTailIndex];
gRxTailIndex++; gRxTailIndex %= QUEUE_SIZE;
}
Result = call UARTSend.send(pMsg);
if (Result != SUCCESS) {
pMsg->length = 0;

}
else {
call Leds.greenToggle();
}
}
task void UARTRcvdTask() {

result_t Result;
dbg (DBG_USR1, "TOSBase forwarding UART packet to Radio\n");

gpTxMsg->group = TOS_AM_GROUP;
Result = call RadioSend.send(gpTxMsg);
if (Result != SUCCESS) {
atomic gfTxFlags = 0;
}
else {
call Leds.redToggle();
}
}
task void SendAckTask() {

call UARTTokenReceive.ReflectToken(gTxPendingToken);
call Leds.yellowToggle();
atomic {
gpTxMsg->length = 0;
gfTxFlags = 0;
}
}
command result_t StdControl.init() {

result_t ok1, ok2, ok3;
uint8_t i;
for (i = 0; i < QUEUE_SIZE; i++) {

gRxBufPool[i].length = 0;
gRxBufPoolTbl[i] = &gRxBufPool[i];
}
gRxHeadIndex = 0;
gRxTailIndex = 0;
gTxBuf.length = 0;
gpTxMsg = &gTxBuf;
gfTxFlags = 0;
ok1 = call UARTControl.init();

ok2 = call RadioControl.init();
ok3 = call Leds.init();
dbg(DBG_BOOT, "TOSBase initialized\n");
return rcombine3(ok1, ok2, ok3);

}
command result_t StdControl.start() {

result_t ok1, ok2;

ok1 = call UARTControl.start();
ok2 = call RadioControl.start();
return rcombine(ok1, ok2);

}
command result_t StdControl.stop() {

result_t ok1, ok2;
ok1 = call UARTControl.stop();

ok2 = call RadioControl.stop();
return rcombine(ok1, ok2);

}
event TOS_MsgPtr RadioReceive.receive(TOS_MsgPtr Msg) {

TOS_MsgPtr pBuf;
dbg(DBG_USR1, "TOSBase received radio packet.\n");
if (Msg->crc) {
/* Filter out messages by group id */

if (Msg->group != TOS_AM_GROUP)
return Msg;
atomic {
pBuf = gRxBufPoolTbl[gRxHeadIndex];
if (pBuf->length == 0) {
gRxBufPoolTbl[gRxHeadIndex] = Msg;
gRxHeadIndex++; gRxHeadIndex %= QUEUE_SIZE;
}
else {
pBuf = NULL;
}
}
if (pBuf) {
post RadioRcvdTask();
}
else {
pBuf = Msg;
}
}
else {
pBuf = Msg;
}
return pBuf;
}
event TOS_MsgPtr UARTReceive.receive(TOS_MsgPtr Msg) {

TOS_MsgPtr pBuf;
dbg(DBG_USR1, "TOSBase received UART packet.\n");
atomic {

if (gfTxFlags & TXFLAG_BUSY) {
pBuf = NULL;
}
else {
pBuf = gpTxMsg;
gfTxFlags |= (TXFLAG_BUSY);
gpTxMsg = Msg;
}
}
if (pBuf == NULL) {
pBuf = Msg;
}
else {
post UARTRcvdTask();
}
return pBuf;
event TOS_MsgPtr UARTTokenReceive.receive(TOS_MsgPtr Msg, uint8_t

Token) {
TOS_MsgPtr pBuf;
dbg(DBG_USR1, "TOSBase received UART token packet.\n");
atomic {
if (gfTxFlags & TXFLAG_BUSY) {
pBuf = NULL;
}
else {
pBuf = gpTxMsg;
gfTxFlags |= (TXFLAG_BUSY | TXFLAG_TOKEN);
gpTxMsg = Msg;
gTxPendingToken = Token;
}
}
if (pBuf == NULL) {
pBuf = Msg;
}
else {
post UARTRcvdTask();
}
return pBuf;
}
event result_t UARTSend.sendDone(TOS_MsgPtr Msg, result_t success) {

Msg->length = 0;
return SUCCESS;
}
event result_t RadioSend.sendDone(TOS_MsgPtr Msg, result_t success) {

if ((gfTxFlags & TXFLAG_TOKEN)) {
if (success == SUCCESS) {
post SendAckTask();
}
}
else {
atomic {
gpTxMsg->length = 0;
gfTxFlags = 0;
}
}
return SUCCESS;
}
}

Appendix D: TestMTS400

/**********************************************************************
* TestMTS400M.nc Measures MTS400/420 weatherboard sensors & gps and
converts to engineering units. Shows no temperature value until
threshold is reached
***********************************************************************
includes gps;
#include "appFeatures.h"
module TestMTS400M {
provides interface StdControl;
uses {
//communication
interface StdControl as CommControl;
interface SendMsg as Send;
interface ReceiveMsg as Receive;
#ifdef MTS420
//gps
// interface I2CSwitchCmds as GpsCmd;
interface GpsCmd;
interface StdControl as GpsControl;
// interface BareSendMsg as GpsSend;
interface ReceiveMsg as GpsReceive;
#endif
// Battery
interface ADC as ADCBATT;
interface StdControl as BattControl;
//Accels
interface StdControl as AccelControl;
interface I2CSwitchCmds as AccelCmd;
interface ADC as AccelX;
interface ADC as AccelY;
//Intersema
interface SplitControl as PressureControl;
//interface StdControl as PressureControl;
interface ADC as IntersemaTemp;
interface ADC as IntersemaPressure;
interface Calibration as IntersemaCal;
//Sensirion
interface SplitControl as TempHumControl;
interface ADC as Humidity;
interface ADC as Temperature;
interface ADCError as HumidityError;
interface ADCError as TemperatureError;
//Taos
interface SplitControl as TaosControl;
interface ADC as TaosCh0;
interface ADC as TaosCh1;
interface Timer;
interface Leds;
}

}
implementation
{
enum {START, BUSY, GPS_BUSY,BATT_DONE, HUMIDITY_DONE, PRESSURE_DONE,

LIGHT_DONE, ACCEL_DONE, GPS_DONE};
enum {SENSOR_NONE = 0,
SENSOR_BATT_START = 10,
SENSOR_HUMIDITY_START = 20,
SENSOR_HUMIDITY_GETHUMDATA = 21,
SENSOR_HUMIDITY_GETTEMPDATA = 22,
SENSOR_HUMIDITY_STOP = 23,
SENSOR_PRESSURE_START = 30,
SENSOR_PRESSURE_GETCAL = 31,
SENSOR_PRESSURE_GETPRESSDATA = 32,
SENSOR_PRESSURE_GETTEMPDATA = 33,
SENSOR_PRESSURE_STOP = 34,
SENSOR_LIGHT_START = 40,
SENSOR_LIGHT_GETCH0DATA = 41,
SENSOR_LIGHT_GETCH1DATA = 42,
SENSOR_LIGHT_STOP = 43,
SENSOR_ACCEL_START = 50,
SENSOR_ACCEL_GETXDATA = 51,
SENSOR_ACCEL_GETYDATA = 52,
SENSOR_ACCEL_STOP = 53
};
#define TIMER_PERIOD 1000 // timer period in msec

#define GPS_MAX_WAIT 20 // max wait time for gps packet =
GPS_MAX_WAIT*TIMER_PERIOD
char count;
uint16_t calibration[4]; //intersema calibration words

norace uint8_t state; //
uint8_t sensor_state; //debug only
uint8_t gps_wait_cnt; //cnts wait periods for gps pkt to

arrive
bool gps_pwr_on; //true if gps power on
TOS_Msg msg_buf;
TOS_MsgPtr msg_ptr;
bool sending_packet, WaitingForSend, IsUART;
XDataMsg *pack;
norace uint8_t iNextPacketID;

char gga_fields[GGA_FIELDS][GPS_CHAR_PER_FIELD]; // = {{0}};
/
***********************************************************************
*****
* Task to send uart and rf message
**********************************************************************
******/
task void send_msg(){
if (sending_packet) return;
atomic sending_packet = TRUE;
pack->xSensorHeader.board_id = SENSOR_BOARD_ID;
pack->xSensorHeader.packet_id = iNextPacketID;
pack->xSensorHeader.node_id = TOS_LOCAL_ADDRESS;
// pack->xSensorHeader.rsvd = 0;
call Leds.yellowOn();
if (IsUART) {
if(call Send.send(TOS_UART_ADDR,sizeof(XDataMsg)-
1,msg_ptr)!=SUCCESS)
{
atomic sending_packet = FALSE;
}
}
else {
if(call Send.send(TOS_BCAST_ADDR,sizeof(XDataMsg)-
1,msg_ptr)!=SUCCESS)
{
atomic sending_packet = FALSE;
}
}
return;
}
task void stopPressureControl() {

atomic sensor_state = SENSOR_PRESSURE_STOP;
call PressureControl.stop();
return;
}
task void stopTempHumControl() {

atomic sensor_state = SENSOR_HUMIDITY_STOP;
call TempHumControl.stop();
return;
}
task void stopTaosControl(){

atomic sensor_state = SENSOR_LIGHT_STOP;
call TaosControl.stop();
return;

}
task void powerOffAccel(){

atomic sensor_state = SENSOR_ACCEL_STOP;
call AccelCmd.PowerSwitch(0); //power
off
return;
}
command result_t StdControl.init() {
atomic {
msg_ptr = &msg_buf;
gps_pwr_on = FALSE;
sending_packet = FALSE;
WaitingForSend = FALSE;
}
pack = (XDataMsg *)msg_ptr->data;
// usart1 is also connected to external serial flash

// set usart1 lines to correct state
TOSH_MAKE_FLASH_OUT_OUTPUT(); //tx output
TOSH_MAKE_FLASH_CLK_OUTPUT(); //usart clk
call BattControl.init();
call CommControl.init();
call Leds.init();
call Leds.greenOn();
#ifdef MTS420
call GpsControl.init();
#endif
call TaosControl.init();
call AccelControl.init(); //initialize accelerometer
call TempHumControl.init(); //init Sensirion
call PressureControl.init(); // init Intersema
return SUCCESS;
}
command result_t StdControl.start() {

call HumidityError.enable(); //in case Sensirion
doesn't respond
call TemperatureError.enable(); // same as above
call CommControl.start();
call BattControl.start();
#ifdef MTS420
call GpsControl.start();
#endif
atomic state = START;

atomic sensor_state= SENSOR_NONE;
atomic gps_wait_cnt = 0;
IsUART = TRUE;

call Timer.start(TIMER_REPEAT, TIMER_PERIOD); //start up
sensor measurements
return SUCCESS;
}
command result_t StdControl.stop() {

call BattControl.stop();
#ifdef MTS420
call GpsControl.stop();
call GpsCmd.TxRxSwitch(0);
#endif
call Timer.stop();
call CommControl.stop();
return SUCCESS;
}
/
***********************************************************************
*******
* Timer fired, test GPS, humidity/temp
* async for test only
* If gps_wait_cnt > 0 then gps is active, waiting for a packet
**********************************************************************
*******/
event result_t Timer.fired() {
uint8_t l_state;
call Leds.redToggle();
#ifdef MTS420
if (!gps_pwr_on){
//turn on GPS power, stays on for entire test
return call GpsCmd.PowerSwitch(1);
return SUCCESS;
}
#endif
atomic l_state = state;

if (sending_packet || (l_state == BUSY))
return SUCCESS ; //don't overrun buffers
if (WaitingForSend){
/*
* The GPS modules DC-DC booster can interfere with radio
communication.
* If the GPS module must be continually powered and monitored during
radio
* communication, then 3.3-3.6 volt lithium batteries are recommended
to
* power the mote. Normal alkaline batteries are not recommended unless
* the GPS module is powered down during radio communication.
*
* If GPS module is to be powered down during radio communication,
* uncomment following GpsCmd.PowerSwitch(0) line

* If the GPS module must be continually powered and monitored during
radio
* communication, comment following GpsCmd.PowerSwitch(0) line
*/
#ifdef MTS420
// if (gps_pwr_on)call GpsCmd.PowerSwitch(0);
#endif
post send_msg();
return SUCCESS;
}
switch(l_state) {
case START:
#if FEATURE_GPS_ONLY
call Leds.greenOff();
#ifdef MTS420
atomic state = GPS_BUSY;
return call GpsCmd.TxRxSwitch(1); //enable gps tx/rx
#else
return SUCCESS;
#endif
#else
atomic{
state = BUSY;
sensor_state = SENSOR_BATT_START;
}
return call ADCBATT.getData(); //get vref data;
#endif
break;
case BATT_DONE:
atomic{
state = BUSY;
sensor_state = SENSOR_HUMIDITY_START;
}
return call TempHumControl.start();
case HUMIDITY_DONE:
atomic {
state = BUSY;
sensor_state = SENSOR_PRESSURE_START;
}
return call PressureControl.start();
case PRESSURE_DONE:
atomic {
state = BUSY;
sensor_state = SENSOR_LIGHT_START;
}
return call TaosControl.start();
case LIGHT_DONE:
atomic {

state = BUSY;
sensor_state = SENSOR_ACCEL_START;
}
return call AccelCmd.PowerSwitch(1); //power on
case ACCEL_DONE:
call Leds.greenOff();
#ifdef MTS420
atomic state = GPS_BUSY;
return call GpsCmd.TxRxSwitch(1); //enable gps tx/rx
#else
return SUCCESS;
#endif
break;
#ifdef MTS420
case GPS_BUSY:
if (gps_wait_cnt >= GPS_MAX_WAIT)
{ // gps rcvd pkt before time out?
call GpsCmd.TxRxSwitch(0); // no,disable gps tx/rx
switches
return SUCCESS;
}
else {
gps_wait_cnt++; //keep waiting for gps pkt
return SUCCESS;
}
break;
case GPS_DONE:
return SUCCESS;
break;
#endif
}
return SUCCESS;
}
#ifdef MTS420
event TOS_MsgPtr GpsReceive.receive(TOS_MsgPtr data) {
uint8_t i,j,m,length,NS,EW;
uint16_t k;
uint32_t temp;
bool end_of_field;
char *packet_format;
char *pdata;
float dec_secs,dec_min;
//change to GPS packet!!

GPS_MsgPtr gps_data = (GPS_MsgPtr)data;
// if gps have been scaned then stop receiving gps uart packet
if (state == GPS_DONE) return data;

// check for NMEA format, gga_fields[0]
packet_format = gps_data->data;
//
if ( !((packet_format[3] == 'G') && (packet_format[4] == 'G') &&
(packet_format[5] == 'A'))) {
//SODbg(DBG_USR2, "No NEMA format, gps packet parese
failed!! \n");
return data;
}
// parse comma delimited fields to gga_filed[][]

end_of_field = FALSE;
i=0;
k=0;
length = gps_data->length;
while (i < GGA_FIELDS) {
// assemble gga_fields array
end_of_field = FALSE;
j = 0;
while ((!end_of_field) & (k < length)) {
if (gps_data->data[k] == GPS_DELIMITER) {
end_of_field = TRUE;
}
else {
gga_fields[i][j] = gps_data->data[k];
}
j++;
k++;
}
// two commas (,,) indicate empty field
// if field is empty, set it equal to 0
if (j <= 1) {
for (m=0; m<10; m++) gga_fields[i][m] = '0';
}
i++;
}
// uint8_t
pack->xData.dataGps.fixed=(uint8_t)(gga_fields[6][0]-'0'); //
invalid
// gga_msg.hours = call extract_hours(gga_fields[1]);

pdata=gga_fields[1];
pack->xData.dataGps.hour=10*(pdata[0]-'0') + (pdata[1]-'0');
// gga_msg.minutes = call extract_minutes(gga_fields[1]);

pack->xData.dataGps.minute=10*(pdata[2]-'0') + (pdata[3]-'0');
// uint32_t
// gga_msg.dec_sec = call extract_dec_sec(gga_fields[1]);
dec_secs = 10*(pdata[4]-'0') + (pdata[5]-'0') +
0.1*(pdata[7]-'0')
+ 0.01*(pdata[8]-'0')
+ 0.001*(pdata[9]-'0');
temp = (uint32_t)(dec_secs * 1000);
pack->xData.dataGps.dec_sec = temp;

// gga_msg.Lat_deg = call extract_Lat_deg(gga_fields[2]);
pdata=gga_fields[2];
pack->xData.dataGps.lat_deg= (uint16_t)(10*(pdata[0]-'0') +
(pdata[1]-'0'));
// gga_msg.Lat_dec_min = call extract_Lat_dec_min(gga_fields[2]);

dec_min = 10*(pdata[2]-'0') + (pdata[3]-'0') +
0.1*(pdata[5]-'0')
+ 0.01*(pdata[6]-'0') + 0.001*(pdata[7]-'0') +
0.0001*(pdata[8]-'0');
temp = (uint32_t)(dec_min * 10000);
pack->xData.dataGps.lat_dec_min = temp;
// gga_msg.Long_deg = call extract_Long_deg(gga_fields[4]);

pdata = gga_fields[4];
pack->xData.dataGps.long_deg =
(100*(pdata[0]-'0') + 10*(pdata[1]-'0') + (pdata[2]-'0'));
// gga_msg.Long_dec_min = call
extract_Long_dec_min(gga_fields[4]);
dec_min = 10*(pdata[3]-'0') + (pdata[4]-'0') +
0.1*(pdata[6]-'0')
+ 0.01*(pdata[7]-'0') + 0.001*(pdata[8]-'0') +
0.0001*(pdata[9]-'0');
temp = (uint32_t)(dec_min * 10000);
pack->xData.dataGps.long_dec_min= temp;
NS = (gga_fields[3][0] == 'N') ? 1 : 0;
EW = (gga_fields[5][0] == 'W') ? 1 : 0;
pack->xData.dataGps.nsewind= EW | (NS<<4); // eg. Status=
000N000E = 00010000
if (gps_pwr_on)call GpsCmd.TxRxSwitch(0); // stop receive from

gpsuart
atomic state = GPS_DONE;
iNextPacketID = 2; // issue gga packet xmit
WaitingForSend = TRUE;
return data;
}
event result_t GpsCmd.PowerSet(uint8_t PowerState){

if(PowerState) atomic gps_pwr_on = TRUE;
else atomic gps_pwr_on = FALSE;
return SUCCESS;
}
event result_t GpsCmd.TxRxSet(uint8_t rtstate) {

// gps tx/rx switches set to on or off
if (rtstate){ //reinit gps uart since its shared with pressure
sensor
call GpsControl.start();
//start counting time intervals, waiting for gps pkt
atomic gps_wait_cnt = 0;
}
return SUCCESS;

}
#endif
/
***********************************************************************
*****
* Battery Ref or thermistor data ready
**********************************************************************
******/
async event result_t ADCBATT.dataReady(uint16_t data) {
pack->xData.data1.vref = data ;
atomic state = BATT_DONE;
return SUCCESS;
}
/*********************************************************************
********
* Intersema MS5534A barometric pressure/temperature sensor
* - 6 cal coefficients (C1..C6) are extracted from 4,16 bit,words
from sensor
* - Temperature measurement:
* UT1=8*C5+20224
* dT=data-UT1
* Temp=(degC x10)=200+dT(C6+50)/1024
* - Pressure measurement:
* OFF=C2*4 + ((C4-512)*dT)/1024
* SENS=C1+(C3*dT)/1024 + 24576
* X=(SENS*(PressureData-7168))/16384 - OFF
* Press(mbar)= X/32+250
**********************************************************************
******/
async event result_t IntersemaPressure.dataReady(uint16_t data) {
pack->xData.data1.pressure = data ;
atomic atomic sensor_state = SENSOR_PRESSURE_GETTEMPDATA;
return call IntersemaTemp.getData();
}
async event result_t IntersemaTemp.dataReady(uint16_t data) {
if (data > 2000) {

pack->xData.data1.intersematemp = data ;
post stopPressureControl();
return SUCCESS;
}
else {
post stopPressureControl();
return SUCCESS;
}
}
event result_t IntersemaCal.dataReady(char word, uint16_t value) {

// make sure we get all the calibration bytes
count++;
calibration[word-1] = value;

if (count == 4) {
pack->xData.data1.cal_wrod1 = calibration[0];
atomic sensor_state = SENSOR_PRESSURE_GETPRESSDATA;

call IntersemaPressure.getData();
}
return SUCCESS;
}
event result_t PressureControl.initDone() {

return SUCCESS;
}
event result_t PressureControl.stopDone() {

atomic state = PRESSURE_DONE;
return SUCCESS;
}
event result_t PressureControl.startDone() {

count = 0;
atomic sensor_state = SENSOR_PRESSURE_GETCAL;
call IntersemaCal.getData();
return SUCCESS;
}
/
***********************************************************************
*******
* Sensirion SHT11 humidity/temperature sensor
* - Humidity data is 12 bit:
* Linear calc (no temp correction)
* fRH = -4.0 + 0.0405 * data -0.0000028 * data^2 'RH linear
* With temperature correction:
* fRH = (fTemp - 25) * (0.01 + 0.00008 * data) + fRH 'RH
true
* - Temperature data is 14 bit
* Temp(degC) = -38.4 + 0.0098 * data
**********************************************************************
*******/
async event result_t Temperature.dataReady(uint16_t data) {
if (data < 6980) {

pack->xData.data1.temperature = 3918; //data ;
post stopTempHumControl();
return SUCCESS;
}// if-statement
else {
pack->xData.data1.temperature = data ;
post stopTempHumControl();
return SUCCESS;
}
}//async

async event result_t Humidity.dataReady(uint16_t data) {
pack->xData.data1.humidity = data ;
atomic sensor_state = SENSOR_HUMIDITY_GETTEMPDATA;
return call Temperature.getData();
}
event result_t TempHumControl.startDone() {

atomic sensor_state = SENSOR_HUMIDITY_GETHUMDATA;
call Humidity.getData();
return SUCCESS;
}
event result_t TempHumControl.initDone() {

return SUCCESS;
}
event result_t TempHumControl.stopDone() {

atomic state = HUMIDITY_DONE;
return SUCCESS;
}
event result_t HumidityError.error(uint8_t token) {

call Temperature.getData();
return SUCCESS;
}
event result_t TemperatureError.error(uint8_t token) {

call TempHumControl.stop();
atomic state = HUMIDITY_DONE;
return SUCCESS;
}
/
***********************************************************************
*******
* Taos- tsl2250 light sensor
* Two ADC channels:
* ADC Count Value (ACNTx) = INT(16.5*[CV-1]) +S*CV
* where CV = 2^^C
* C = (data & 0x7) >> 4
* S = data & 0xF
* Light level (lux) = ACNT0*0.46*(e^^-3.13*R)
* R = ACNT1/ACNT0
**********************************************************************
*******/
async event result_t TaosCh1.dataReady(uint16_t data) {
pack->xData.data1.taoch1 = data & 0x00ff;

post stopTaosControl();
return SUCCESS;
}
async event result_t TaosCh0.dataReady(uint16_t data) {
pack->xData.data1.taoch0 = data & 0x00ff;

atomic sensor_state = SENSOR_LIGHT_GETCH1DATA;
return call TaosCh1.getData();
}
event result_t TaosControl.startDone(){

atomic sensor_state = SENSOR_LIGHT_GETCH0DATA;
return call TaosCh0.getData();
}
event result_t TaosControl.initDone() {

return SUCCESS;
}
event result_t TaosControl.stopDone() {

atomic state = LIGHT_DONE;
return SUCCESS;
}
async event result_t AccelY.dataReady(uint16_t data){
pack->xData.data1.accel_y = data & 0xff;

pack->xSensorHeader.rsvd = data >> 8;
post powerOffAccel();
return SUCCESS;
}
/***************************************************/
async event result_t AccelX.dataReady(uint16_t data) {
pack->xData.data1.accel_x = data;
atomic sensor_state = SENSOR_ACCEL_GETYDATA;
call AccelY.getData();
return SUCCESS;
}
/***************************************************/
event result_t AccelCmd.SwitchesSet(uint8_t PowerState) {
// power on/off
if (PowerState){
call AccelX.getData(); //start measuring X accel
axis
atomic sensor_state = SENSOR_ACCEL_GETXDATA;
}
else{
atomic state = ACCEL_DONE;
iNextPacketID = 1; // issue 1st sensors packet xmit
atomic WaitingForSend = TRUE;
}
return SUCCESS;
}
event result_t Send.sendDone(TOS_MsgPtr msg, result_t success) {
call Leds.yellowOff();
if(IsUART){
msg_ptr = msg;

IsUART = !IsUART; // change to radio send
WaitingForSend = TRUE; // uart sent, issue radio send
}
else
{
IsUART = !IsUART; // change to uart send
atomic {
WaitingForSend = FALSE; // both uart and radio sent,
done for current msg
}
}
return SUCCESS;
}
event TOS_MsgPtr Receive.receive(TOS_MsgPtr data) {

return data;
}

ECE4007 Final Paper

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ECE4007 Final Paper

Încărcat de

Drepturi de autor:

Formate disponibile

Final Report

HEAT SENSING WIRELESS NETWORK

ECE4007 Senior Design Project

Section L02, Heat Sensor Team

Heat Sensor Group (ECE 4007 L02)

1.1 Objective .........................................................................................................1

1.2 Motivation .......................................................................................................2

1.3 Background .....................................................................................................2

2. Project Description and Goals ...................................................................................3

4. Design Approach and Details

4.1 Design Approach ............................................................................................8

4.2 Codes and Standards......................................................................................10

4.3 Constraints, Alternatives, and Tradeoffs .......................................................11

5. Schedule, Tasks, and Milestones...............................................................................11

7. Marketing and Cost Analysis....................................................................................15

7.1 Marketing Analysis.........................................................................................15

7.2 Cost Analysis .................................................................................................15

Heat Sensor Group (ECE 4007 L02) ii

language. The dimensions of each MICAz mote were 56 mm on the x-axis, 18 mm on

the z-axis, and 36 mm on the y-axis.

the data to the user of the product.

The prototype network consisted of four MICAz sensors for temperature

communication at a low cost to the consumer.

Heat Sensor Group (ECE 4007 L02) iii

mm on the x-axis, 18 mm on the z-axis, and 36 mm on the y-axis.

detect hazardous thermal activity in buildings and environmental areas up to 10,000

Heat Sensor Group (ECE 4007 L02) 1

Advances in technology have decreased the size of wireless sensors, allowing

sensor networks to function in constrained and smaller environments. Parallel to the

advancement in technology is the limit in power and computational capacity of wireless

sensor networks. Reduction of power consumption by individual sensors in the network

an algorithm that enabled the wireless sensors to implement an energy proficient

network, allowing the network to efficiently broadcast information collected by

Low-Energy Adaptive Clustering Hierarchy (LEACH), which aggregates the network

one without an energy aware routing algorithm [2].

Heat Sensor Group (ECE 4007 L02) 2

Another common routing protocol is Geographic Routing with Environmental

2. PROJECT DESCRIPTION AND GOALS

• Routed data to the transceiver node/sensor

• Determined heating conditions using light intensity

• Flashed LED light when forwarding data

Heat Sensor Group (ECE 4007 L02) 3

Furthermore, the transmitter had the following additional functions:

• Received light conditions from intermediate nodes

• Determined routing path based on received data

• Determined heating conditions using light intensity

• Forwarded all data measurements to the base station

• Determined which sensors have detected hazardous temperatures in its

surroundings and send an alert message.

Heat Sensor Group (ECE 4007 L02) 4

varying environmental conditions.

Figure 1. Block diagram of thermal wireless sensor network.

performance of the network greatly depended on the technical features of these

components. Crossbow MICAz, a wireless measurement system, was installed at each of

Heat Sensor Group (ECE 4007 L02) 5

compatible industrial, scientific, and medical (ISM) band.

light sensor. Crossbow's MTS400CB is an environmental sensor board that contains an

accelerometer, a barometric pressure sensor, and an ambient light sensor. The

specifications for this board are given in Table 2 [2].

Heat Sensor Group (ECE 4007 L02) 6

MICAz mote to communicate with each other.

Heat Sensor Group (ECE 4007 L02) 7