CRAWDAD princeton/zebranet

Dataset of animal movement traces collected from real-world ZebraNet deployments.

The data contained in this data set are movement traces collected from two real-world ZebraNet deployments at Sweetwaters Game Reserve near Nanyuki, Kenya. The first deployment was in January 2004 and the second deployment was during summer of 2005.  The data offer detailed animal position information using UTM format.

date/time of meaurement start: 2004-01-12

date/time of meaurement end: 2005-06-27

collection environment: The Princeton ZebraNet Project is an inter-disciplinary effort with thrusts in both Biology and Computer Systems.  On the computer systems side, ZebraNet is studying power-aware, position-aware computing/communication systems. Namely, the goals are to develop, evaluate, implement, and test systems that integrate computing, wireless communication, and non-volatile storage along with global positioning systems (GPS) and other sensors.  On the biology side, the goal is to use systems to perform novel studies of animal migrations and inter-species interactions.

network configuration: The ZebraNet project has gone through two deployments. The sensor nodes we used in the deployments were based on the ZebraNet Test nodes. The node is built around a MSP430 processor and included a GPS module, a radio module, and a flash module. More details on the ZebraNet hardware experiences can be found in [zhang-hardwaqre-zebranet].

data collection methodology: The first deployment occurred at January of 2004 and consisted of 7 sensor nodes on seven different zebras. Due to power and packaging issues and severe weather, they lasted less than a week. Results were published in [liu-impala-zebranet, zhang-hardware-zebranet, wang- opportunistic].

The second deployment occurred during June/July of 2005.  Four zebras were fitted with an improved version of the sensor nodes.  The sensor nodes had improved hardware, software, and data collection algorithms. The approximate running time of the network was 10 days.  Zebras selected for collaring were picked by the biologists for their different behavioral patterns. Collar 6 was placed on a bachelor male, which had a tendency to move around searching for a mate. Collar 8 was a female but had trouble with the collar position, causing it to acquire fewer GPS fixes. Collar 10 is a female, which leads the group. Collar 14 is also a female but her group had a characteristic of a very small home range.

Traceset

princeton/zebranet/movement

Traceset of animal movement traces collected from real-world ZebraNet deployments.

• file: ZebraNet.tar.gz
• description: The data contained in this trace set are movement traces collected from two real-world ZebraNet deployments at Sweetwaters Game Reserve near Nanyuki, Kenya. The first deployment was in January 2004 and the second deployment was during summer of 2005.  The data offer detailed animal position information using UTM format.
• measurement purpose: User Mobility Characterization
• methodology: A ZebraNet hardware node includes global positioning system (GPS), a simple  microcontroller CPU, a wireless transceiver, and non-volatile storage to hold logged data. ZebraNet does not rely on constant communication access to a base station or other nodes. Instead, it uses periodic node discovery and node-to-node communication to propagate data towards the base station in a store-and-forward manner.

1 Hardware Overview

The ZebraNet hardware is composed of energy-efficient components ideal for use in mobile sensor networks. The major functional components on the board are the microcontroller, GPS, external FLASH, radio, and battery with solar chargers.

To control the hardware, we selected the Texas Instruments Ultra-Low-Power MSP430F149 16-bit microcontroller. This chip has 2KB of RAM, 60KB of internal FLASH memory, and two serial interfaces. It runs off an uninterruptible power supply as we expect it to run continuously. The microcontroller operates in a dual-clock configuration. It uses an 8MHz clock when accessing sensing, storage, or communication peripherals and a 32KHz clock at all other times. The 32KHz clock consumes half as much power as the 8MHz clock and can be used instead of putting theprocessor to sleep.

To log the node's position, we selected the u(micro)-blox GPS-MS1E chip for its small size and its ability to quickly acquire locks. It has a typical hot start acquisition time of two to six seconds, although our experience has been that good GPS fixes take 10-20 seconds to acquire. The GPS communicates with the microcontroller through an asynchronous serial connection at a rate of 38,400 baud (the maximum rate for this chip) over a port which it shares with the external FLASH. It runs off its own 3.3V power supply which can be turned on and off by the software to conserve power. 

To store data, we selected the ATMEL 4Mbit AT45DB- 041B DataFlash chip.  In our system, the node has enough memory capacity to store 26 days of its own positional data and 52 collar-days of positional data received from other nodes. The chip communicates with the microcontroller synchronously at a baud rate of 667Kbaud. Sharing the serial port with the GPS allows for the FLASH and the radio to operate simultaneously. The FLASH is powered by the same uninterruptible source as the microcontroller.

To transmit data between nodes, we selected the Max-Stream 9XStream radio. It operates at 900MHz and is specified to broadcast data up to 5 miles. In our configuration, however, reliable ranges of 0.5-1 mile are more likely. To transmit, the radio only requires around 1W of power. This is possible because as a receiver, it has a sensitivity of -107dBm. The radio communicates with the microcontroller through the second asynchronous serial connection at a rate of 38,400 baud (chosen to match that of the GPS) and with other nodes at an over-the-air rate of 19,200bps. It runs off its own 5V power supply which, like the supply for the GPS, can be turned on and off by the software to conserve power.

To power the node, we use the Panasonic CGR18650A 2A hour Lithium ion battery. Based on the specifications of this battery, we consider it fully charged at 4.2V and dead at 3.1V. We chose 3.4V as the lower bound of its functional range because at this voltage the radio and GPS units rapidly drain the battery and, consequentially, cannot function properly. The battery is recharged using solar cells strategically placed around the collar.  

As energy-efficiency is critical in mobile sensor networks, the ZebraNet hardware features low-power components and efficient power supplies. We measured the power consumption of the system during a cycle in which it performed all possible operations. 

2. Hardware-Imposed Constraints on System Software Programming

The limitations of the hardware system have posed significant constraints on system software programming. Many of them are representative of the challenges in other sensor systems as well.

- Data and Program memory constraint The data memory in the microcontroller is only 2KB. This affects the program behavior in many aspects, especially in data buffering. As are used to keep system states and to handle large flows of network data, data buffers often consume large amount of memory, and therefore must be carefully allocated. Additionally, the program memory is only 60KB. This requires software programs to be concise.

- Energy constraint The energy budget is tight as we use a solar-array to recharge the battery and to provide the energy essential to achieve the sensing and communication tasks. As is estimated, we are able to fully charge the battery in 50 hours of daylight. This number can vary in either direction, however, depending

on the orientation of the solar cells in relation to the sun. Therefore, efforts must be made to maximally save energy, and resorts must be provided to preserve the system when the energy level is severely low.

- Device access constraint Device accesses must be carefully scheduled to avoid conflicts which are likely to happen due to hardware limitations. For example, due to voltage regulation challenges, the GPS and the radio should not be turned on at the same time for interference-avoidance purposes. Additionally, the GPS and the FLASH share the same serial connection to the microcontroller, and therefore, cannot be accessed simultaneously.

-  Radio packet size constraint The physical packet size of our radio hardware is only 64 bytes, an order of magnitude smaller than the Ethernet packet size, for example. This means the multi-level packet header in the traditional TCP/IP model will cost a significant communication overhead. Therefore, we need a special

network protocol that requires a low overhead to accomplish the essential network communication services.

- FLASH data storage constraint For the FLASH memory, new data cannot be written to an address before the data currently at that address is erased, and the smallest erasable unit is a 264-byte page. This means writing data to one location will affect data at other locations. Therefore, a global FLASH organization is required to achieve efficient data storage.

- GPS sensing time constraint The time for the GPS unit to acquire an accurate position lock is typically 10 to 20 seconds. This considerable delay in data acquisitionimplies an asynchronous access and control model is preferred to a synchronous model for operating this sensing device.

movement/baseout Traces

• baseoutUTM1: 2004 trace of animal movement traces collected from real-world ZebraNet deployments.
• configuration: The first deployment occurred at January of 2004 and consisted of 7 sensor nodes on seven different zebras. Due to power and packaging issues and severe weather, they lasted less than a week. Results were published in [liu-impala-zebranet, zhang-hardware-zebranet, wang-opportunistic].
• format:  1. Directories and files

The directory structure is listed as follows:

- ZebraNet

  - README.txt          (this file)

  - baseoutUTM1.txt     (version 1 trace)

  - trace2ns.py         (a sample Python program to translate the 1st trace to ns-2 readable format)

  - baseoutUTM2.txt     (version 2 trace)

2. File format of baseoutUTM1.txt

The file named baseoutUTM1.txt includes the data collected from the first deployment, in space separated ASCII format.  Each location data entry is represented by one line in the file with an interval of 8 minutes between each location reading. Each line consists of 11 space separated fields as follows:

Fields 1-9: "node ID" "month" "day" "year" "hour" "minute" "second" "latitude" "longitude"

Fields 10-11: movement data stored in UTM format 

(see http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_sy...)

A sample program (trace2ns.py) illustrates how UTM we transform the UTM

data to (x,y) coordinates used in traditional simulators, such as the ns-2.

• baseoutUTM2: 2005 trace of animal movement traces collected from real-world ZebraNet deployments.
• configuration: The second deployment occurred during June/July of 2005.  Four zebras were fitted with an improved version of the sensor nodes. The sensor nodes had improved hardware, software, and data collection algorithms. The approximate running time of the network was 10 days.  Zebras selected for collaring were picked by the biologists for their different behavioral patterns. Collar 6 was placed on a bachelor male, which had a tendency to move around searching for a mate. Collar 8 was a female but had trouble with the collar position, causing it to acquire fewer GPS fixes. Collar 10 is a female, which leads the group. Collar 14 is also a female but her group had a characteristic of a very small home range.
• format: 1. Directories and files

The directory structure is listed as follows:

- ZebraNet

  - README.txt          (this file)

  - baseoutUTM1.txt     (version 1 trace)

  - trace2ns.py         (a sample Python program to translate the 1st

                         trace to ns-2 readable format)

  - baseoutUTM2.txt     (version 2 trace)

2. File format of baseoutUTM2.txt

The file named baseoutUTM2.txt includes the data collected in space-separated ASCII format with location information stored in UTM format.  Each location entry is represented by one line in the file. The word "BASESTATION" is an indication of the file's origin and should be the same for all entries.  The number that follows the word "node" is the node number.  There are 4 nodes included in this file, node 6, 8, 10, and 14. After the node number is the date and time. They are organized in "year month day" and "hour minute" respectively. The time information is in GMT and Kenyan time is GMT+3. The location information is in UTM format located after the date and time. They are labeled easting and northing. After the location information is the volt. Volt is just a rough estimate of the voltage and only serves as an indicator of node's energy status. Hdop is horizontal delusion of precision obtained from the GPS module, rounded down. In every lock, we wait until this number is below 7 to register a lock for improved accuracy. Nsat is the number of satellites available for the particular GPS lock. A number 7 indicates the lock was obtained with information from 7 satellites or more.