North Carolina Su

Computer Society International Design Competition 2005
Final Report

Country United States of America
District Raleigh, North Carolina
Mentor Dr. Robert Fornaro
fornaro@csc.ncsu.edu

Team Members

David Coblentz Jonathan Lewis
dscoblen@ncsu.edu jdlewis@ncsu.edu
Computer Science Computer Science

Dakota Hawkins Ben Noffsinger
dwhawkin@ncsu.edu blnoffsi@ncsu.edu
Computer Science Fisheries and Wildlife

NEAT Final Report North Carolina State University

Abstract
Tracking and monitoring wildlife is an important activity in attempts to draw an appropriate
balance between needs of human and animal populations on our planet. Every major species
plays an important role in its local ecosystem by ensuring balance between predator and prey.
Predator and prey species often keep one another in equilibrium, ensuring that one population
does not grow beyond its means to exist without encroaching on another population's territory.
Current tracking systems that are designed to monitor various types of wildlife are costly to
employ and, in some cases, inaccurate or difficult to access. The application described in this
paper, Networks for Endangered Animal Tracking (NEAT) promises to be less expensive than
current systems used for tracking while providing more reliable data. NEAT combines GPS
technology with wireless sensor networks to produce a potential product for wildlife officials and
agencies.
NEAT utilizes battery-powered, ad hoc, wireless sensor systems to collect, store, and forward
GPS-based location data that can be used to track animal movements. The NEAT design uses
three architectural components: SensorNodes, NetworkNodes, and a BaseStation. SensorNodes
are fitted on animal collars and are designed to periodically obtain GPS location information.
Each SensorNode must store the data it collects locally until it moves within range of a
NetworkNode. NetworkNodes are stationary elements of NEAT that use radio frequency
modules to retrieve GPS location data and store it locally until retrieved by a BaseStation. A
BaseStation is designed to retrieve information from a NetworkNode and forward it to a personal
computer for permanent storage and analysis.
NEAT is innovative in that it allows experimental testing of specific design tradeoffs pertaining
to wireless ad hoc sensor networks and wildlife tracking systems. This analysis will help to
determine whether NEAT is a viable alternative to the tracking methods currently in use. It will
also determine whether NEAT could potentially represent a superior design for the tracking and
analysis of certain types of animals.
NEAT has been extensively tested to ensure its reliability and to test performance issues such as
battery endurance, GPS accuracy, and network reliability. Prototype tests have been performed
using NEAT team-members instead of animals, but will soon move to field trials that use live
animals and environments similar to those that NEAT will need to function in as a finished
product. Design and implementation of NEAT was accomplished with an iterative methodology.
Individual components were developed and tested separately before being combined and tested
together as a system. NEAT's multidisciplinary team is comprised of four undergraduates at
North Carolina State University. Ben Noffsinger is a sophomore in fisheries and wildlife, David
Coblentz is a senior in computer, Dakota Hawkins is a senior in computer science, and Jonathan
Lewis, NEAT’s team leader, is a senior in computer science.

2 of 18


1. System Overview
Background. The conservation of endangered species provides numerous benefits to both the
ecosystem and human society. Balance is required to protect the planet's biodiversity while
simultaneously permitting human population growth. Recent global scenarios demonstrate this
need. In Cameroon Africa, efforts are underway to attain balance between the endangered
elephant population and the expanding human population [6]. Closer to home, US Navy plans to
establish a practice landing field in eastern North Carolina were recently halted pending a "full
and fair environmental review [3].” Every species plays an important and distinct part in its
local ecosystem. Predator animals help in this balance by naturally controlling the populations
of their prey, while the availability of prey naturally controls the populations of their predators.
The Endangered Species Act mandates that recovery plans be enacted for any endangered
species to help that species withdraw from the brink of extinction. The red wolf (Canis rufus)
originally ranged freely from the Atlantic Ocean to the Mississippi River [7]. Today there are
only slightly more than one-hundred red wolves existing in the wild in North America, with
around one-hundred and fifty existing in captivity [7]. In order to maintain ecological balance, it
is necessary to establish healthy human/wildlife boundaries. Wildlife researchers help us
understand how to set these boundaries and achieve this balance.
To optimize the chance of success in the recovery of any endangered species, it is vital that
populations existing in the wild be carefully tracked and monitored. Tracking animals provides
insight into their natural habitats, habits, and behaviors that can help wildlife researchers
determine the best way to advance recovery efforts of endangered species. Traditional tracking
methods employ radio telemetry; radio beacons are broadcast and received at different locations,
an analysis of signal strengths and vectors with directional antennas can then help determine the
approximate position of the source [1]. In an operation using radio telemetry, researchers must
enter the field of study each time they wish to gather data. They typically do this on foot, in a
ground vehicle, or by aircraft equipped with special antennas to estimate positions of
broadcasting sources. More recently, battery-powered, wireless, ad hoc sensor networks provide
the technology base for gathering location information via GPS. This technology is in early
research stages [9, 12, 13], but its low cost, flexibility, and power-managed architecture can
potentially provide superior wildlife tracking system solutions [6].
Objectives. Networks for Endangered Animal Tracking (NEAT) is a system to aid wildlife
researchers in the study of endangered species. NEAT uses a battery-powered ad hoc wireless
sensor network to acquire, store, and relay GPS-based location data. The main goal of this
system is to allow GPS information to be collected by wireless sensors attached to mobile
subjects (animals) via a customized collar. When collared animals are in range of NEAT's
stationary network, their tracking units will upload stored tracking data for later collection and
analysis by wildlife researchers.
Innovative Concepts. Battery-powered, ad hoc, wireless sensor systems that utilize GPS in
wildlife tracking are the subject of active research. There is no current "best alternative
architecture" because the design space is quite broad [11], even for such a specific application as
wildlife tracking. Possible interactions of complex sub-systems such as GPS receivers, radio
transceivers, and persistent data storage systems present significant design challenges. Problem
domain requirements, such as frequency of sampling, ad hoc storage and forward protocols, and
power management algorithms complicate tradeoff evaluation. The innovation provided by the

3 of 18


NEAT system lies in the prototype test bed that has been created. The NEAT prototype allows
certain tradeoffs to be experimentally evaluated. In particular, regarding the wildlife tracking
application, it will be possible to determine whether or not a design based on mobile sensing
units (animals collared with GPS receivers and radio transmitters) and fixed network elements
combine to form a suitable data collection and relay mechanism for species of interest (dogs,
deer, wolves, etc.).
System Requirements. The requirements of the NEAT system are as follows:
• GPS data must be collected at prescribed intervals (ranging from several minutes to
several hours).
• Collected data must include latitude, longitude, date and time, and a measure of fix
confidence.
• Collected data must be relayed via a wireless radio transceiver to a permanent database in
a format suitable for analysis.
• The system must guarantee that no data is lost during any stage of transfer or storage.
• The system must operate via battery power for at least six months.
• The system must provide sufficient mobile storage capacity to accommodate data
collected over a period of at least six months.
• The system must be mountable onto a collar suitable for an animal and weigh
approximately 400 grams.
Design Methodology. NEAT was designed using top-down methodology, working from the
general aspects of system operation to the specific inner workings of system protocols. NEAT
design and implementation took place over the course of 14 weeks in four major iterations:
• Simple Networking and Satellite Functionality. MICA2 to MICA2 communication as
specified by an early design of network protocol was accomplished and tested alongside
development of the SensorNodes ability to acquire GPS satellite information.
• Network Protocol. The Network Protocol design underwent a refinement process and
communication was extended across entire system (SensorNode to NetworkNode to
BaseStation).
• Ad hoc Routing and User Interface. Research was conducted into the feasibility of
implementing on-demand ad hoc routing between NetworkNodes alongside the
development of a more refined and functional user interface.
• System Testing and Code Review. NEAT underwent extensive system testing to
assure a functional prototype was completed before submission of the final report. Code
freeze and review also completed to guarantee smooth transition of NEAT to future
developers.
Our multidisciplinary team comprises four NCSU students. Ben Noffsinger is a sophomore
majoring in fisheries and wildlife, and is in charge of research involving endangered animal
tracking, advising the team in biological and ecological concerns, and participating in the design
and development of an animal collar suitable for NEAT. David Coblentz is a senior in computer
science and has been assigned to the development of GPS interfacing and data storage. Dakota
Hawkins is a senior in computer science and is assigned to the development of network
protocols. Jonathan Lewis is NEAT’s team leader and a senior in computer science. Besides
being assigned to the development of database and user interface components, he is responsible
for scheduling team meetings and ensuring that team members communicate efficiently.

4 of 18


2. Implementation and Engineering Considerations
Hardware: The MICA2 Mote. The hardware device on which all fundamental NE AT
components run is the MICA2 Mote (Figure 1). The MICA2 processor subsystem, developed by
Crossbow Technologies, Inc., is a small wireless sensor device that is well-suited to NE AT 's
specific requirements. MICA2s have enough processing speed and storage capabilities to
employ a range of data collection routines. MICA2s provide wireless collection and
communication of information, with the potential to expand sensor capabilities via a selection of
specialized additional add-on sensor boards. Compared to current animal tracking hardware, the
MICA2 is an inexpensive alternative.
Cost (per unit) $150 US (~115 EUR)
Dimensions 58mm x 32mm x 7mm
Weight 18 grams
Power Source 2 AA batteries
Maximum Life Approx. 1 year
Processor Atmel ATmega128L
RAM 4K
Program Memory 128 K
EEPROM Memory 512 K
Radio 38.4 kilobaud
Maximum Range 152.4 meters
Native Output 3 LEDS
Expansion 51 pin connector
Figure 1. The MICA2 Mote.

The MICA2's LEDS provide rudimentary debugging information and output; each can be turned
on or off individually. For complex testing a simulator and JTAG interface are also available.
The MICA2 mote may be connected through the 51 pin connector to the MTS420CA sensor
board which enables the collection of additional sensory information, including the GPS satellite
data required by NEAT's specifications. The same 51 pin connector allows the MICA2 to be
mounted on a programming board, enabling two-way communication with a personal computer
over a serial cable.
The MTS420CA is equipped with several different onboard sensors, including the Leadtek 9546
GPS processor and antenna (Figure 2). The MTS420CA is capable of aquiring standard GPS
information and forwarding that data through its 51 pin connector to a MICA2 in ASCII format.
Cost (per unit) $375 US (~285 EUR)
GPS Processor Leadtek 9546
Accuracy Avg. within 10 meters
Output NMEA Standard
Input NMEA SIRF II
Additional Accelerometer
Capabilities Barometer
Light sensor
Humidity sensor
Temperature sensor
Figure 2. Capabilities and picture of the MTS420CA.

5 of 18


Software: TinyOS and NesC. The MICA2 operates under TinyOS, a customizable open-source
operating system. TinyOS is well-suited for NE AT because it was designed specifically for
wireless embedded sensor networks. T i n y OS a p p l i c at io n s are written in a programming
language called NesC, which is a component based C variant. Like TinyOS, NesC is open-
source.
In NesC, components can be included by a programming technique referred to as "wiring."
Wiring is comparable to object oriented programming in that a NesC application inherits some of
its functionality from common library components. NesC is based, in part, around its ability to
handle and respond to the commands and events that drive TinyOS.
TinyOS and NesC aid the development of wireless sensor applications by allowing code size and
resource requirements to remain small. Functionality is added as required and unnecessary
capabilities may be removed to optimize use of resources. This is especially important when
working with event driven systems like NEAT wherein the timely execution of tasks is necessary
to basic functionality.
Architecture of the NEAT System. NEAT is divided into three separate components, the
SensorNode, the NetworkNode, and the BaseStation. The SensorNode is a MICA2 together with
a MTS420CA GPS Sensor designed to fit on an animal's collar and programmed to periodically
acquire GPS information, store that information (See Figure 3a), and use radio communication to
listen for and respond to NetworkNodes. NetworkNodes are MICA2s that are programmed to
send radio polling messages that trigger data transfers from any SensorNode(s) within range.
The NetworkNode must store the data it receives (Figure 3b) and additionally use its radio to
listen for and respond to a BaseStation. The BaseStation is a MICA2 programmed to send its
radio polling messages that trigger data transfers from NetworkNodes within range. The
BaseStation must then forward the data it receives to a personal computer for permanent storage,
interpretation, and analysis (Figure 3c).

3a 3b 3c
Figure 3 (a-c). Architecture overview of the NEAT system.

The SensorNode. The SensorNode is a MICA2 designed to fit on an animal's collar and
programmed to periodically gather and store GPS tracking information using a connected
MTS420CA sensor board. The SensorNode must also listen for messages broadcast from one of
several stationary NetworkNodes and subsequently engage in a wireless "conversation" resulting
in the transfer of any data possessed by the SensorNode to the NetworkNode.

6 of 18


The SensorNode is dependant upon a timer that switches back and forth between its two distinct
states: 1) attempting to obtain a GPS position fix and 2) listening for communication from
stationary NetworkNodes. Separate states are necessary in the SensorNode both because of
interference between the GPS antenna and the radio antenna, and because AA batteries cannot
supply enough power to operate both the radio and GPS systems simultaneously.
When a SensorNode is activated, it begins in the GPS state and spends up to five minutes
attempting to obtain a satellite fix (Figure 4). Every time the MTS420CA receives a message
from satellites, an event is triggered within the SensorNode application (about once a second).
Each time a message is received, it is examined to determine whether or not the information
contains a positional fix. If a fix has been received, the data is parsed and compressed, then
stored to the SensorNode's EEPROM memory. Afterwards, or if the timer determines that 5
minutes have passed without a successful positional fix, SensorNode control switches to its radio
communication state.
While in its radio state, a SensorNode is listening for radio communication from one of several
stationary NetworkNodes. If within range, the SensorNode will enter into a conversation with a
NetworkNode and upload all data contained in EEPROM storage.

SensorNode State Diagram.
Starts by looking for a position fix
from the GPS sensor board. If one
is received, stores data to
EEPROM memory and switches to
radio. If poll (or ack) is received
read next piece of data and then
send it. When either the GPS or
Radio states time out, switch to
opposite.

Figure 4. SensorNode state diagram.

The SensorNode is comprised of four major components, each of which acts as a level of
abstraction to lower level software and hardware components (Figure 5).

Software Level
Interfaces with components to
provide GPS, Radio, and Logging
capabilities. These components and
the LED component interfaces
directly with the hardware level.

Hardware Level
Provides physical functionality for all
software components.
Figure 5. SensorNode hardware/software components and interactions.

7 of 18


The NetworkNode. NetworkNode MICA2s are designed to form a stationary data collection
grid. Each NetworkNode is designed to broadcast a radio poll in an attempt to establish
communication with a SensorNode. If communication is established, the NetworkNode and the
SensorNode engage in a conversation whereby the SensorNode's data is transferred to and stored
on the NetworkNode. Data will be stored at the NetworkNode until offloaded by a BaseStation.
When a NetworkNode is activated, it begins broadcasting poll messages; a message is sent once
every two seconds (Figure 6). Broadcast messages can be received by any MICA2 operating on
the same radio frequency as the polling MICA2. In NE AT , a polling message is used to initiate
a conversation between two MICA2's (either between a SensorNode and a NetworkNode or
between a NetworkNode and a BaseStation).
Between sending polls for SensorNodes, the NetworkNode listens for polling messages sent
from a BaseStation. If one such poll is heard, the NetworkNode stops its timer (effectively
stopping its polling process) and transmits all its stored data to the BaseStation that polled it.
When empty, or when the sending of messages is stopped due to timeout (possibly if the
BaseStation goes out of range of the NetworkNode), the timer is restarted and the NetworkNode
resumes polling for SensorNodes.

NetworkNode State Diagram
Starts by listening for messages
from a SensorNode. If data is
received, writes it to EEPROM and
continues listening for messages.
If a poll (or ack) is received, reads
next piece of data and then sends
it.

Figure 6. NetworkNode state diagram.

The NetworkNode is comprised of three major components, each of which acts as a level of
Software Level
Interfaces with components to
provide Radio and Logging
capabilities. These components and
the LED component interfaces
directly with the hardware level.

Hardware Level
Figure 7. NetworkNode hardware/software components and interactions.

8 of 18


The BaseStation. The BaseStation is a MICA2 system designed to collect data from individual
NetworkNodes in much the same way that a NetworkNode collects information from
SensorNodes. A BaseStation consists of a MICA2 mounted on a programming board and
attached to the serial port of a laptop or computer. Polling and communication methods are
functionally equivalent to those present in the NetworkNode scheme except instead of storing
information via writing to EEPROM memory the data is forwarded to the serial port as it is
received (Figure 8).

BaseStation State Diagram
Starts by listening for data from
NetworkNode. If received, sends to
UART and continues listening.
Figure 8. BaseStation state diagram.

The BaseStation is comprised of three major components, each of which acts as a level of
Software Level
Interfaces with components to provide
Radio capabilities. The MsgToRfm,
SerialPort, and LED components
interface directly with the hardware
level.

Hardware Level
Figure 9. BaseStation hardware/software components and interactions.

Network Protocol. NEAT's components, the SensorNode, NetworkNode and BaseStation, each
require a common abstract protocol for communication. The NEAT networking protocol was
developed and implemented in the early stages of NEAT to address this need. Since the major
focus of NE AT is to relay information, the protocol was designed so that actual data is protected
and delivered error-free to the user at all cost. NE AT 's network protocol is based on an
acknowledgement scheme that requires three major message classes which dictate the behavior
of wireless communication between MICA2s (Figure 10).

9 of 18


Class Method Type Route
0x01 BaseStation to NetworkNode Dividing the three classes of messages into six
Poll Bcast explicit message types enables NEAT to
0x02 NetworkNode to SensorNode
0x03 BaseStation to NetworkNode guarantee that conversations will only take place
Ack Ucast between a SensorNode and a NetworkNode or
0x04 NetworkNode to SensorNode
0x05 NetworkNode to BaseStation between a NetworkNode and a BaseStation.
Data Ucast
0x06 SensorNode to NetworkNode
Figure 10. NEAT message types and definitions.

A poll message is broadcast by a MICA2 indicating a desire to establish a conversation with
another MICA2 (Figure 11). A poll can be received by any MICA2 within range and operating
on the same radio frequency. Messages can also be unicast, meaning they specify destination
identification, and can only be received by the given target MICA2.
If a MICA2 receives a poll message and has data to send, it reads and sends its first piece of data.
The sending unit will not move on to the next piece of data until it receives an acknowledgement,
signifying its last message was successfully received. This ensures that data is protected. Using
this protocol, a duplicate message may be stored if an acknowledgement message is dropped, but
it is certain that all data originally present is transferred entirely or not at all. Should
communication be interrupted prematurely, the receiving component will time out and send
another polling message, essentially restarting the process and picking up where the transmission
left off.

Figure 11. NEAT network protocol "conversation."

10 of 18


NEAT Data Structures. The information that is collected and transferred throughout the
NE AT system consists mostly of GPS positional information necessary for pinpointing and
analyzing specific coordinates. Information is encapsulated into packets, each of which contains
an entire set of relevant information taken and stored at one time. GPS information, along with
information specific to a MICA2's unique ID, must be gathered and stored together for proper
transmission and interpretation.
The MTS420CA's GPS sensor is capable of providing several different readings in NMEA [10]
form, each is called a "sentence" and each contains slightly different information [2]. The
information required by NE AT is gathered from two separate NMEA sentences. GPS position
information, i.e. latitude and longitude, is gathered from a "GPGGA" sentence (Figure 12).
Since the GPGGA does not contain the date necessary for sequentially ordering several different
position fixes, a "GPRMC" message is analyzed and the current date and time are extracted from
it.

$GPGGA,092204.999,4250.5589,S,14718.5084,E,1,04,24.4,19.7,M,,,,0000*1F
Field Example Comments
Sentence ID $GPGGA
UTC Time 092204.999 hhmmss.sss
Latitude 4250.5589 ddmm.mmmm
N/S Indicator S N = North, S = South
Longitude 14718.5084 dddmm.mmmm
E/W Indicator E E = East, W = West
Position Fix 1 0 = Invalid, 1 = Valid
Satellites 04 Satellites being used
HDOP 24.4 Horiz. dilution of precision
Altitude 19.7 Altitude in meters
Units M M = Meters
Separation Geoid separation in meters
Units M = Meters
DGPS Age Age of data in seconds
Station ID 0000
Checksum *1F
Figure 12: GPGGA Example sentence and breakdown.

Since it may take several minutes to get a GPS positional fix, and a fix is only attempted once an
hour, it is important to value quantity of fixes obtained over quality. The GPGGA sentence
provides a horizontal dilution of position (HDOP) reading that is essentially a confidence
indicator corresponding to that sentence's positional fix. Every fix is stored in a packet with its
HDOP so that later, upon collection and analysis, quality can be assessed or restricted on a point
by point basis if desired.
After all the information belonging to a single packet is collected by a SensorNode, it must be
stored in that MICA2's EEPROM memory. This space is divided into 32,768 16 byte lines,
though the raw information belonging to each packet is more than 30 bytes in length. This
observation necessitates considerable compression, since allowing a single packet to occupy two
lines would cut the MICA2's already limited storage capacity in half.

11 of 18


Compression and Storage. The MICA2 is capable of sending and receiving messages of up to
128 bytes in length, but is bottlenecked at its EEPROM storage capabilities. Interfaces to the
MICA2's EEPROM are divided into 16 byte segments. Each message received from the GPS
sensor on a SensorNode is typically 70 bytes or more, 30 of which are pieces of information with
which NEAT is concerned.
In order to store NEAT's information about a single fix in one 16 byte line of EEPROM, a
custom compression algorithm had to be developed specifically for NEAT. The GPS sentences
received from the MTS420 consist mostly of decimal numbers represented in ASCII character
format, essentially one character of information occupying 1 byte. During compression, these
numerical values are shifted and stored 2 per byte (Figure 13).

for (i = 0; i < 32; i++) {
if (uncompressed[i] == '.') {
uncompressed[i] = 10;
}
else {
uncompressed[i] = uncompressed[i] - 0x30;
}
}
for (i = 0; i < 16; i++) {
compressed[i] = uncompressed[2*i];

packet[i] = packet[i] << 4;
packet[i] = packet[i] | uncompressed[2*i+1];
}
Figure 13. Compression code and diagram.

The positional hemisphere information, which is represented in its original form with two
characters (either N or S and either W or E) is compressed by assigning each possible quadrant
of the globe a designation 1-4 (Figure 14), and storing that value in 4 bits.
uint8_t direction = 0;

if (NorthSouth != 'N') {
direction += 2;
}
if (EastWest == 'E') {
direction += 1;
}
else {
direction += 2;
}

Figure 14. Direction compression code and diagram.

Design Tradeoffs: Networking Considerations. During the design process for NEAT's
network protocol, several important tradeoffs had to be analyzed and directional decisions based
on those tradeoffs had to be made that would eventually have an effect on the entire NEAT
system.

12 of 18


When designing the interactions between the SensorNode and NetworkNode, a tradeoff
concerning MICA2 power consumption presented itself. Data transfer could occur between the
SensorNode and NetworkNode using the same algorithm regardless of which unit initiates a
conversation, however, the unit initiating the poll has to do so nearly constantly and therefore
battery life is shortened [8]. It was decided that since the NetworkNode is a stationary MICA2,
it would be easier to change or recharge batteries, or supply the NetworkNode with a larger,
longer-lasting power source. This observation led to the decision to minimize the amount of
work required of the mobile SensorNode in favor of the easy access NEAT provides for the
NetworkNode unit.
In designing the conversation based network protocol, it is necessary for a unit to timeout should
a conversation be interrupted or halted prematurely - just as it is necessary for a unit to timeout
and continue normal functionality when a conversation is over. The amount of time required
before a timeout occurs on a MICA2 unit constitutes another important NEAT design tradeoff
relating to network traffic. Were the timeout as quick as possible, network congestion would be
at a maximum should several units need to communicate with a single unit at the same time. A
quick timeout in a receiving MICA2 would mean increased interruption of conversations due to
timeouts quickly giving way to polls from previously unanswered units. Though a quick timeout
would result in an overall increase in speed for transfers, it would "shuffle" information from
multiple sources and produce more duplicate messages in situations where a timeout occurs
before an ack can be heard [4]. For these reasons NEAT was designed so that timeouts give the
best possible chance of complete, uninterrupted conversations, allowing different units to
communicate one at a time, and allowing individual conversations to finish faster when many
different units are attempting to communicate simultaneously.
The last significant and tradeoff concerning networking protocol concerns ad hoc routing
between NetworkNodes. Originally, the NEAT design included an on demand ad hoc routing
algorithm. It was decided, however, that for this implementation of NEAT a more practical
concern would be that all data collected should be transferred reliably. Ad hoc routing capability
has been put off in favor of a reliable prototype.

Hardware Considerations. Since the EEPROM memory of a MICA2 is logically divided into
16 byte lines, it is both desirable and convenient to store information in 16 byte segments. There
were several tradeoffs to consider relating to this observation, all concerning the amount and
type of data NEAT must store and the best way in which to store it. If a single piece of data
were allowed to occupy two 16 byte lines, NEAT might be able to store more diverse and
accurate information, with a probable few bytes of wasted space on the second line of each two-
line segment. If the convention of ordering the EEPROM memory into lines were ignored, a
new convention would have to be devised and put into place - making management of both free
and occupied space overly complicated. The decision was made to restrict storage of individual
data points to one 16 byte line – resulting in the implementation of the previously explained
compression algorithm.

13 of 18


Additional Utilities: Monitoring Software. The NEAT necessitates the existence of an
interface through which a user operating a personal computer may capture and interpret the data
NEAT is designed to collect and transfer. In the very early stages of NEAT, HyperTerminal and
the java program, ListenRaw (included with TinyOS), were sufficient for this purpose as they
simply relayed raw information coming from a BaseStation through a serial port to a console
window (either in ASCII or hexadecimal). As NEAT’s data became more complex, and
obscured by compression, it became necessary to develop NEAT-specific applications to relay
data from the serial port, uncompress it, format it appropriately, and display it in a convenient
format for a user, and export it to a more usable format.
ListenProject. The first application developed for NEAT is called ListenProject. ListenProject
is a java program designed to run in a terminal window, which reads data from a specified serial
port, decompresses it according to NEAT’s specifications, and displays it in tabular form. When
the user is finished collecting data, exiting ListenProject triggers a dump of the information
received to a text file. The data is written in a form interpretable by the open-source program,
Viking, which may then automatically download satellite images and overlay the collected GPS
coordinate information for simple, visual verification and analysis by the user.
NEAT BEAST. The second data interpretation application, NEAT Basic Extraction and Storage
Terminal (BEAST), developed for NEAT was designed to take the place of ListenProject in
relaying GPS information from a BaseStation to a personal computer. The application has a
graphical user interface (Figure 15), and uses an SQL database for storing and retrieving
information. The prototype interface was written in Visual Basic to promote a friendly look and
feel and to speed the development of a usable application. Rather than relying on Viking to
interpret GPS data, the user may export data from NEAT’s database into a format that is usable
by ArcView, an industry standard GIS software package.

The panel shown represents the
primary NEAT BEAST interface.

• "Listen" begins reception of data from
a specified serial port
• "Export" outputs selected SensorNode
data to a GIS readable file
• "Settings" enables the user to change
the default serial port
• "Add" lets a user manually add a new
SensorNode ID to NEAT's database
• "Edit" lets a user associate an optional
name and description with a
SensorNode ID
• "Delete" lets a user manually remove
a SensorNode ID from NEAT's
database

Figure 15: NEAT BEAST interface and description.

14 of 18


Verification and Testing: Incremental Unit Testing. During all stages of NEAT's
development, each component and system was tested thoroughly. The first component tests
involved the passing of automatically generated data between a mock-SensorNode (a
SensorNode without an attached GPS sensor) and one or more NetworkNode. Verification of
message transmission, reception, and storage was determined through careful use of the
MICA2's onboard LEDs by specifically setting them to represent different states in the execution
of an application. As the first tests of NEAT's general network protocol, emphasis was placed on
NEAT's ability to transfer messages completely, without loss, and without excessive
conversation interruption.
Similar tests were performed involving the passing of automatically generated data between
NetworkNodes and a BaseStation; this time verifying the data received by using HyperTerminal
to monitor the serial port to which the BaseStation was connected. After several successful tests
of this model, the test was extended to include the passage of information from mock-
SensorNodes to NetworkNodes, and then on to a BaseStation. As the first test of NEAT's
complete prototype network infrastructure, these tests were conducted many times with a variety
of configurations.
Once the network protocol was satisfactorily validated, the SensorNode was attached to an
MTS420CA sensor board and real GPS data replaced automatically generated messages. This
involved laboratory tests of NEAT's compression and storage scheme, and uncovered design
tradeoffs involving conflicts between the GPS sensor and a variety of MICA2 onboard systems
including the EEPROM and the radio. Once these conflicts were resolved by more judicious
operation of all components on the SensorNode, the system was ready to undergo complete
prototype testing.
System Testing. Several complete prototype tests have been performed to date, involving
varying numbers of NetworkNodes or SensorNodes, both in a laboratory environment with a
fixed SensorNode and in an outdoor setting with a mobile SensorNodes. These system tests are
helpful in examining the functionality of certain aspects of NEAT under different conditions, but
they are most helpful for analyzing efficiency and timing characteristics of the MICA2 and of the
NEAT system as a whole.
Recently, a whole-system test took place involving one mobile (hand-held) SensorNode,
stationary NetworkNodes, and one BaseStation connected to a Windows laptop equipped with
and running ListenProject. The two NetworkNodes were located in an outdoor courtyard
positioned 200 meters apart, and activated for the duration of the test. Prior to mobilizing the
SensorNode, a position was gathered and immediately transmitted to the first NetworkNode. A
NEAT team member then walked with the SensorNode in a relatively circular path around a
large area of the North Carolina State University campus over a time-period of approximately 30
minutes. The SensorNode was set to attempt a GPS satellite fix once every 5 minutes. Upon re-
entering range of the NetworkNodes, the SensorNode transmitted its information to the second of
the NetworkNodes. The BaseStation was then activated, downloading the data from both
NetworkNodes. A test-status message was received indicating that of 13 attempted fixes by the
SensorNode, 13 positions were obtained – a 100% success rate (Figures 16 and 17).

15 of 18


The invocation of ListenProject specifies
the serial port through which data will be
received.

A status message, programmed for testing
purposes to be sent as data from a
SensorNode following a poll, indicates the
SensorNode ID and the number of GPS
fixes obtained over the number of GPS
fixes attempted and, in brackets, the total
number of data points contained in
EEPROM.

Each message is displayed containing
number of messages received by the
BaseStation, which NetworkNode it came
from, which SensorNode it came from,
Latitude, Longitude, number of satellites
used in the fix, quality of the fix, message
number, and message position relative to a
SensorNode's stored data.

Figure 16. ListenProject's test output and explanation.

type="track" name="Wolf 9"
type="trackpoint" latitude="35.786666" longitude="-78.668181"
type="trackend"

The plotted track consists of a series
of connected vertices, and as such is
not a good representation of minute
changes in course. The points are
located at track corners and are each
within approximately 10 meters of the
actual path traversed.

Figure 17. Generated Viking track file, overlay and description.

16 of 18


The Next Step. Ben Noffsinger, NEAT's fisheries and wildlife team member, has helped to
construct a leather dog collar capable of protecting and carrying a SensorNode for use in NEAT's
first animal tests. This test will be conducted similarly to NEAT's latest whole-system test, with
an expanded time frame to allow for more data connection and tests of the physical design of
NEAT's collar. If these tests are successful NEAT will soon be tested on other suitable animals
in increasingly unpredictable environments.

3. Summary
Conclusions. NEAT currently exists as a complete, working prototype of an animal tracking
system. GPS position information can be collected, stored, transmitted, and displayed in
accordance with specified requirements, in particular:
• SensorNodes collect and store compressed GPS position information on configurable
timed intervals.
• NetworkNodes establish wireless communication sessions with SensorNodes, and
download and store any available GPS data.
• A BaseStation establishes wireless communication sessions with NetworkNodes,
downloads any available GPS data, and forwards that data to a PC for permanent
archiving.
• Two PC utility programs, ListenProject and NEAT BEAST, display decompressed GPS
data and store it in a permanent archive.
Scientists are currently tracking animals using expensive and labor intensive VHF techniques.
Battery powered, ad hoc, sensor networks provide possible alternative solutions for wildlife
tracking. The NEAT prototype explores this new design space. It potentially can provide higher
quality data at a lower cost when compared to current practice in the field.
The team is in the final stages of building a prototype collar that will enable the existing NEAT
implementation to be used in field trials on a dog. Testing so far has been conducted by tracking
people; using a domesticated animal for testing will provide additional input regarding the
robustness of a collar equipped with NEAT.
Future Work. NEAT is complete as a prototype system; some optimization or expansion of
NEAT, however, is both recommended and possible. Battery life could be increased as a result
of implementing one of several available MICA2 power-saving modes. Features of the
MTS420CA could be further utilized to provide additional information related to animal
movement and behavior (e.g. average velocity, temperature during active or inactive periods).
On demand, ad hoc routing could be implemented in NetworkNodes, allowing collected data to
funnel back to a single point. Presuming domesticated animal field trials are successful, testing
NEAT on populations of deer and eventually, red wolves, would represent the ultimate success
of this prototype.
Such an approach to wildlife tracking will help refine natural boundaries for animals and
potentially define new boundaries so that humans and wildlife can comfortably share the planet.

17 of 18


4. References

[1] Barber, Shannon M., and Mech, David L. A Critique of Wildlife Radio-tracking and its use in
National Parks: A Report to the U.S. National Park Service. St. Paul, MN: University of
Minnesota, 2002.

[2] DePriest, Dale. NMEA Data. <http://www.gpsinformation.org/dale/nmea.htm>.

[3] Eisley, Matthew, and Rawlins, Wade. "Judge Halts Landing Field." The News & Observer 19
Feb. 2005: A1.

[4] Hać, Anna. Wireless Sensor Network Designs. West Sussex, England: John Wiley & Sons,
Ltd., 2003.

[5] Hemingway, B. Brunette, W. Anderl, T. Borriello, G. “The Flock: Mote Sensors Sing in
Undergraduate Curriculum.” Computer vol. 37 iss. 8 Aug. 2004: 72 –78.

[6] North Carolina Zoological Society. "Elephants of Cameroon." Field Trip Earth. 2005. North
Carolina. 23 Apr. 2005 <http://fieldtripearth.org/div_index.xml?id=3>.

[7] North Carolina Zoological Society. "Red Wolves of Alligator River." Field Trip Earth. 2005.
North Carolina. 23 Apr. 2005 <http://fieldtripearth.org/div_index.xml?id=3>

[8] Ordonez, F. Krishnamachari, B. “Optimal Information Extraction in Energy – Limited
Wireless Sensor Networks.” IEEE Journal on Selected Areas in Communication vol. 22
iss. 6 Aug. 2004: 1121 – 1129.

[9] Patnode, D. Dunne, J. Malinowski, A. Schertz, D. “WISENET – TinyOS Based Wireless
Network of Sensors.” Indusial Electronics Society, 2003. IECON ’03. The 29th Annual
Conference of the IEEE vol. 3 Nov. 2003 2363 – 2368.

[10] Publications and Standards. NMEA Publications and Standards, National Marine
Electronics Association, <http://www.nmea.org/pub/Index>.

[11] Romer, K. Matern, F. “The Design Space of Wireless Sensor Networks.” Wireless
Communications, IEEE vol. 11 iss. 6 Dec. 2004: 54 – 61.

[12] Ulema, M. “Wireless Sensor Networks: Architectures, Protocols, and Management.”
Network Operations and Management Smposium, 2004.IEEE/IFIP Apr. 2004 931.

[13] Zhang, Pei, et al. "Hardware Design Experiences in ZebraNet." SenSys '04 (2004).

18 of 18

North Carolina Su

Recomendados

Recomendados

Más contenido relacionado

Similar a North Carolina Su

Similar a North Carolina Su (20)

Más de Ashar Ahmed

Más de Ashar Ahmed (17)

Último

Último (20)

North Carolina Su