• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
North Carolina Su

North Carolina Su



North Carolina Su

North Carolina Su



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds


Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    North Carolina Su North Carolina Su Document Transcript

    • 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
    • NEAT Final Report North Carolina State University 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 Final Report North Carolina State University 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
    • NEAT Final Report North Carolina State University 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
    • NEAT Final Report North Carolina State University 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
    • NEAT Final Report North Carolina State University 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
    • NEAT Final Report North Carolina State University 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 abstraction to lower level software and hardware components (Figure 7). 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 Provides physical functionality for all software components. Figure 7. NetworkNode hardware/software components and interactions. 8 of 18
    • NEAT Final Report North Carolina State University 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 abstraction to lower level software and hardware components (Figure 9). Software Level Interfaces with components to provide Radio capabilities. The MsgToRfm, SerialPort, and LED components interface directly with the hardware level. Hardware Level Provides physical functionality for all software components. 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
    • NEAT Final Report North Carolina State University 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 Final Report North Carolina State University 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
    • NEAT Final Report North Carolina State University 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
    • NEAT Final Report North Carolina State University 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
    • NEAT Final Report North Carolina State University 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
    • NEAT Final Report North Carolina State University 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
    • NEAT Final Report North Carolina State University 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="trackpoint" latitude="35.786268" longitude="-78.664056" type="trackpoint" latitude="35.786448" longitude="-78.663045" type="trackpoint" latitude="35.784558" longitude="-78.664667" type="trackpoint" latitude="35.783066" longitude="-78.665899" type="trackpoint" latitude="35.781795" longitude="-78.667085" type="trackpoint" latitude="35.782563" longitude="-78.668213" type="trackpoint" latitude="35.782033" longitude="-78.670858" type="trackpoint" latitude="35.781591" longitude="-78.669963" type="trackpoint" latitude="35.781977" longitude="-78.668003" type="trackpoint" latitude="35.782163" longitude="-78.669731" type="trackpoint" latitude="35.784388" longitude="-78.670306" type="trackpoint" latitude="35.786098" longitude="-78.668911" 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
    • NEAT Final Report North Carolina State University 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
    • NEAT Final Report North Carolina State University 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