Wireless Sensor Network Crossbow Mica2 Motes with GPS Sensor
by
Wesley Wai Ho Leung
Senior Project
Electrical Engineering Department
California Polytechnic State University
San Luis Obispo
June 7, 2005
ii
Table Of Contents
Table Of Contents ............................................................................. ii
List of Tables and Figures .............................................................. iv
Acknowledgement ............................................................................ v
Abstract ............................................................................................ vi
1.0
2.0
Introduction ............................................................................ 1
1.1
Description ............................................................................. 1
1.2
1.3
Scope ...................................................................................... 1
Report Content ....................................................................... 2
Background ............................................................................ 3
2.1
2.2
2.3
3.0
4.0
Global Position System ......................................................... 3
Trilateration ............................................................................ 4
TinyOS .................................................................................... 6
Requirements.......................................................................... 8
3.1
3.2
Test Equipment ...................................................................... 8
Test Setup ............................................................................... 9
3.3
3.4
3.5
3.6
Program a Mica2 Mote with TOSBase application .............. 9
Program a second Mica2 Mote with TestMTS400.............. 10
Setting up PC for Data Collection (Xlisten) ....................... 11
Verification of GPS operation ............................................. 12
Testing and Results .............................................................. 14
4.1
4.2
4.3
4.4
Programming a mote with TOSBase .................................. 14
Programming the second mote with TestMTS400 ............ 15
Run Xlisten on the host computer ..................................... 17
Running GPS Application ................................................... 19
5.0
Conclusion ............................................................................ 23
6.0
Reference .............................................................................. 24
7.0
Appendices ........................................................................... 25
Appendix A - Installing and Setting up TinyOS ............................. 25
Appendix B – Changing default mote settings ............................. 27
Appendix C – NMEA-0183 GGA Data Format ................................ 28
iii
Appendix D – TestMTS400M.nc ...................................................... 29
Appendix F – sensorboardApps.h ................................................. 36
Appendix G – appFeatures.h .......................................................... 38
Appendix H – Xlisten ....................................................................... 39
Appendix I – GPS.m ........................................................................ 40
Appendix J – Analysis of Senior Project Design .......................... 41
iv
List of Tables and Figures
Figures
Figure 1. Graphical Representation of Trilateration……………......5
Figure 2. Crossbow MIB510CA…………………………………………8
Figure 3. Crossbow MRP400……………………………………………8
Figure 4. Crossbow MTS420……………………………………………8
Figure 5. Test Setup………………………………………...……….......9
Figure 6. Smarty’s Position…………………………………………....13
Figure 7. GPS Location produced by Matlab………...…………….21
Figure 8. GPS Location produced by MS Streets and Trips……..21
Figure 9. Control Flow of TestMTS400M.nc…................................29
Tables
Table 1. GPS “Cooked” Data from Xlisten……………………….20
v
Acknowledgement
I would like to thank Professor James Harris for taking the time out
from his busy schedule to advise the Wireless Sensor Network group. Dr.
Harris’ assistance and patience to us is the main reason why three other
undergraduate students and I could finish our senior projects in time. I
would also like to thank the other members of Wireless Sensor Network Rafael Kaliski, Jose Becerra, Aurelio Hafalia, David Orabani and Bryan
Nagaish, for their assistance and keeping me motivated. It has been a
pleasure working with all of you.
The wireless sensor network team appreciates the support of Drs.
Diana Franklin and John Seng for sharing their Crossbow hardware with us,
and the Network Performance Research Laboratory (NetPRL) for
purchasing the additional sensors that were used in the completion of this
project.
vi
Abstract
This senior project is part of an ongoing bigger project. As we are
the first team ever to use the Crossbow Wireless Sensor Network
technology at Cal Poly, SLO, the main goal of our projects will be to
demonstrate the functionality of this new technology, and provide valuable
information to the students who will assume our projects in the future. A
GPS module will be used in this project and it is only one of the many
sensors used in this ongoing project. The idea is to interface the GPS
module to the computer with the help of Crossbow Mica2 Motes, and to use
computer programs such as MS-Excel and Matlab to present the data in a
more organized way. As mentioned before, our team is the pioneer for the
future students of Wireless Sensor Network. What we want to demonstrate
here is a proof of concept; there is a lot of room for further improvement on
this technology.
1
1.0 Introduction
1.1 Description
This project is part of the Wireless Sensor Network being developed at
California Polytechnic State University of San Luis Obispo. A group of
four undergraduate and one graduate Electrical Engineering students
are developing a wireless sensor network using the newly developed
Crossbow
Mica2
data-acquisition
Motes
boards.
and
Each
its
corresponding
undergraduate
sensor
student
and
will
be
responsible for one or more environmental sensors; for example,
temperature, wind speed, humidity and GPS (Global Positioning
System), and will interface each of these sensors with the Mica2 motes
in order for the base station to collect enough information for data
analysis. As the first group of students ever using this new Crossbow
wireless sensor technology, the final goal for this project will be to
demonstrate the functionality and flexibility that this technology could
provide.
1.2 Scope
The MTS420 Environmental Monitoring Sensor Board has six on-board
sensors in addition to the LeadTek 9546 GPS module. Each of these
sensors and the GPS module could be individually programmed
according to the user’s application. This senior project will mainly
consist of the software development of the GPS module; the objective
of the project will be to demonstrate the functionality of the GPS module
by tracking a moving object’s location using longitude and latitude
2
coordinates.
1.3 Report Content
The report provides detailed-procedural descriptions accompanied by
figures to give the reader a better understanding of what was
accomplished in this project. The report begins with an introduction of
the technologies being used and then transitions into the requirement
and design of the project. The results are explained in the Testing and
Results section and followed by the conclusion.
3
2.0 Background
Before proceeding further with the technical aspect of this project, it is
important that the reader have a basic understanding of the GPS
operation. This chapter will be devoted to the discussion of the
technical detail of a GPS sensor and a brief introduction to this
project’s development platform, TinyOS.
2.1 Global Position System
The Global Positioning System was originally developed by the United
States military for government use in 1973. However, due to its
inexpensive cost and its worldwide accessibility, GPS was soon opened
to commercial use by the public.
The GPS system includes 27 satellites (24 of which operate
round-the-clock and the rest of them are used as backups) orbiting the
Earth twice a day at an altitude of approximately 11,000 miles. All of
these satellites are arranged in a pattern such that four of them will be
visible to the open sky at any given time and location.
The GPS receiver (LeakTek 9546) is responsible for locating at least
three of the 27 satellites in order to perform trilateration for position
tracking.
4
2.2 Trilateration
Trilateration is the method of using relative position of the objects
nearby to calculate the exact location of the object of interest. Instead
of using a known distance and an angle measurement as in
triangulation to determine the subject’s location in a 2-D space,
trilateration requires three known distances to the subject to perform
the calculation.
For example (see Figure 1), point B is where the object of interest is
located. The distances to the nearby objects P1 and P2 are known,
from geometry, it can be concluded that only two possible locations, A
and B, can satisfy the criteria. To avoid ambiguity, the distance of the
third nearby object is introduced and now there is only one coordinate,
point B, that could possibly exist. Figure 1 illustrates the above
example.
Applying the concept of 2-D trilateration to a GPS application which
exists in 3-D space, the circles in Figure 1 become spheres. By
knowing the distances and the exact locations of three different GPS
satellites, there will be two different intersection points that exist on the
surface of the planet. While one of them is up in the space, the other
one must be on the ground.
5
Figure 1. Graphical Representation of Trilateration
<http://en.wikipedia.org/wiki/Trilateration>
In order for the GPS receiver to calculate the distance to each GPS
satellite, the satellites and the receivers are equipped with atomic
clocks. At a certain pre-set time, the satellites will begin to transmit a
string of digital pseudo-random data, while the receiver will play the
same string of data in itself. Knowing that radio waves travel at the
speed of light, by determining the delay between the data string playing
within the GPS receiver and the data string received from the satellite,
the distance from the GPS receiver to the satellite can be calculated as
below:
Distance = Delay Between the Data Strings X Speed of Light
See reference 7, 8 and 9 for more detailed information.
6
2.3 TinyOS
The name “TinyOS” might be confused with the conventional
desktop OS (Operating System) like Microsoft Windows or Linux.
TinyOS, however, does not provide resource management or the
function of a virtual machine; rather it is the development platform
for Crossbow or other manufacturer’s Wireless Sensor Network
products. TinyOS’ library includes network protocol, sensor board
drivers and data acquisition applications which allow user to start
programming and building a sensor network in a very short
amount of time (see Reference 5).
The major advantage of TinyOS is the size of its program, which
could easily be fitted into the memory-limited motes; another
advantage is the easiness to program the motes. All of TinyOS’
applications and drivers are written in NesC, a variant of the
popular programming language “C”.
TinyOS has been ported to many platforms and numerous sensor
boards. The TinyOS community is expanding with the increasing
of developers each day.
To learn about TinyOS and NesC language, check out the tutorial
at <http://www.tinyos.net/tinyos-1.x/doc/tutorial> (Reference 5)
7
To read more about projects using TinyOS, visit
<http://www.tinyos.net/related.html> (Reference 6)
8
3.0 Requirements
3.1 Test Equipment
The following test equipments are provided and funded by NetPRL
Group within the Electrical Engineering and Computer Science
Departments of Cal Poly, SLO:
1.
A Linux box or a Windows PC with Cygwin installed
2.
TinyOS 1.1.7 (See appendix for upgrade instruction)
3.
Crossbow MIB510CA Programming and Serial Interface
Board – Figure 2.
4.
Crossbow Mica2 MRP400 Mote (2) – Figure 3.
5.
Crossbow MTS420 Environmental Monitor Sensing Board with
LeadTek 9546 GPS module – Figure 4.
6.
TOSBase (Provided by Xbow)
7.
TestMTS420 Test Application (Modified from Xbow source code,
refer to appendix)
8.
Xlisten Serial Port Listener (Modified from Xbow source code)
 Figure 2. Crossbow MIB510CA
Figure 3. Crossbow MRP400 
 Figure 4. Crossbow MTS420
9
3.2 Test Setup
Running Xlisten
and/or Matlab
MTS420 Sensor
Board with GPS
Mica2 Mote loaded
with TOSBase
Mica2 Mote loaded
with TestMTS420
MIB510
Interface Board
Figure 5. Test Setup
3.3 Program a Mica2 Mote with TOSBase application
Specification:
Compile and download the TOSBbase application to a Crossbow
Mica2 mote. The mote that is programmed with the TOSBase
application will act as the base station for other motes and as the
gateway between the wireless sensor network and the computer.
Procedure:
The Mica2 mote shall be attached to the Crossbow Programming
and Interface board MIB510 and shall interface with the computer
10
using the RS-232 (Serial) connectivity.
The application shall be compiled and stored in flash memory of the
mote using the following command while inside the
/opt/tinyos-1.x/contrib./xbow/apps/TOSBase directory.
“make mica2 install.0 mib510, com#”, where com# is the port that
MIB510 is attached to.
Upon successful compilation of the program, TinyOS will
automatically download the compiled program onto the Crossbow
Mica2 mote. TinyOS shall return a prompt to the user without any
error messages if the mote is successfully programmed.
3.4 Program a second Mica2 Mote with TestMTS400
Specification:
Compile and download the TestMTS400 to a Crossbow Mica2 mote.
The mote that is programmed with TestMTS400 will be used to
collect GPS data. The data will be assembled as data packets and
be transmitted to the base station using the RF link. Reference
Appendix D for source code of TestMTS400 test application.
Procedure:
The Mica2 mote shall be attached to the Crossbow Programming
and Interface board MIB510 and shall interface with the computer
11
using the RS-232 (Serial) connectivity.
The application shall be compiled and stored in flash memory of the
mote using the following command while inside the
/opt/tinyos-1.x/contrib./xbow/apps/XSensorMTS400 directory.
“make mica2 install.1 mib510, com#”, where com# is the port that
MIB510 is attached to.
Upon successful compilation of the program, TinyOS will
automatically download the compiled program onto the Crossbow
Mica2 mote. TinyOS shall return a prompt to the user without any
error messages if the mote is successfully programmed.
3.5 Setting up PC for Data Collection (Xlisten)
Specification:
Xlisten is the application that runs on the PC to obtain the data sent
by the MIB510 board (TOSBase) to the serial port. Xlisten is located
at “/opt/tinyos-1.x/contrib./tools/src/xlisten/”. The Xlisten application
which is used in this project is modified by Jose Becerra in order to
format the incoming data in the format for MS-Excel and Matlab.
12
Procedure:
To run Xlisten, change to the above directory where Xlisten is
located. Compile Xlisten if necessary by entering the command
“make”. The file “xlisten.exe” shall appear if the program is compiled
without any error. Enter the command
“./xlisten.exe –c –s=com#> OUTPUT_FILE.csv”, where # is the port
that MIB510 is attached to. The ‘-c’ option is specified here as a
modification of Xlisten in the function that processes the “cooked”
data, and it has the following output format:
Greenwich Mean Time
hh,mm,ss,latitude,longitude,validity –> 1 = valid; 0 = invalid
3.6 Verification of GPS operation
Specification:
To verify the operation of the GPS, the mote shall be programmed
with the modified version of TestMTS400 application. Because the
GPS module will interfere with the RF link of the mote when it is
powered up, it is important that the GPS module be powered down
before attempting to send a radio packet.
The mote shall be programmed to collect forty data packets for the
first 10 minutes, and repeatedly send out the collected data packet
at the second 10 minutes period. All data packets shall be
temporarily stored in the Random Access Memory of the mote until
13
the desired number of packets are collected. The saved data shall
be transmitted via RF link while the GPS is powered down.
Procedure:
The GPS module attached to the Mica2 mote shall be affixed to a
moving object to simulate the conditions in a real life application.
Forty data packets shall be gathered by the GPS in the span of
approximately 10 minutes. A map or a plot shall be constructed in
terms of latitude and longitude using the data gathered by the GPS,
Figure 6. shows an example map.
Figure 6. Smarty’s Position
14
4.0 Testing and Results
4.1 Programming a mote with TOSBase
Acceptance Criteria:
Program a mote with TOSBase according to section 3.2. No error
shall be reported by TinyOS. A prompt shall be returned to the user
at the end.
Result:
No error was reported, and a prompt was returned after the program
was uploaded to the flash. The output was captured and included
below.
Marble1@marble /opt/tinyos-1.x/contrib/xbow/apps/TOSBase
$ make mica2 install.0 mib510,com1
mkdir -p build/mica2
compiling TOSBase to a mica2 binary
ncc -o build/mica2/main.exe -Os -I%T/../contrib/xbow/tos/platform/mica2
-finlin
e-limit=100000 -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x81 -Wnesc-all -target=mica2 fnesc-cfile=build/mica2/app.c -board=micasb
-DCC1K_DEFAULT_FREQ=RADIO_916BAND_CH
ANNEL_00 -DRADIO_XMIT_POWER=0xFF -DIDENT_PROGRAM_NAME="TOSBase"
-DIDENT_PROGRAM_
NAME_BYTES="84,79,83,66,97,115,101,0" -DIDENT_USER_HASH=0x0054ef2eL
-DIDENT_UNIX
_TIME=0x429d5f0dL TOSBase.nc -lm
G:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/tos/system/RealMain.nc: In function `main'
:
G:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/tos/interfaces/StdControl.nc:63: warning:
`result' might be used uninitialized in this function
compiled TOSBase to build/mica2/main.exe
11544 bytes in ROM
637 bytes in RAM
15
avr-objcopy --output-target=srec build/mica2/main.exe build/mica2/main.srec
set-mote-id build/mica2/main.srec build/mica2/main.srec.out 0
installing mica2 binary using mib510
uisp -dprog=mib510 -dserial=com1 -dpart=ATmega128 --wr_fuse_e=ff
--erase --uplo
ad if=build/mica2/main.srec.out
Firmware Version: 2.1
Atmel AVR ATmega128 is found.
Uploading: flash
Fuse Extended Byte set to 0xff
Marble1@marble /opt/tinyos-1.x/contrib/xbow/apps/TOSBase
$
4.2 Programming the second mote with TestMTS400
Acceptance Criteria:
Program a mote with TestMTS400 according to section 3.4. No error
shall be reported by TinyOS. A prompt shall be returned to the user
at the end.
Result:
No error was reported by TinyOS, and a prompt was returned after
the program was uploaded to the flash. The output was captured
and included below.
Marble1@marble /opt/tinyos-1.x/contrib/xbow/apps/XSensorMTS400
$ make mica2 install.1 mib510,com1
mkdir -p build/mica2
compiling TestMTS400 to a mica2 binary
ncc -o build/mica2/main.exe -Os -I%T/../contrib/xbow/tos/interfaces
trib/xbow/tos/system
-I%T/../con
-I%T/../contrib/xbow/tos/platform/mica2 -I%T/../contrib/xb
ow/tos/AXStack/mica2 -I%T/../contrib/xbow/tos/lib -I%T/../contrib/xbow/tos/senso
16
rboards/mts400 -finline-limit=100000 -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x81 -Wne
sc-all -target=mica2 -fnesc-cfile=build/mica2/app.c -board=mts400 -DCC1K_DEFAULT
_FREQ=RADIO_916BAND_CHANNEL_00 -DRADIO_XMIT_POWER=0xFF
-DIDENT_PROGRAM_NAME="Tes
tMTS40" -DIDENT_PROGRAM_NAME_BYTES="84,101,115,116,77,84,83,52,48,0"
-DIDENT_USE
R_HASH=0x0054ef2eL -DIDENT_UNIX_TIME=0x429d63baL TestMTS400.nc -lm
In file included from G:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/contrib/xbow/tos/sen
sorboards/mts400/GpsPacket.nc:101:
G:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/contrib/xbow/tos/sensorboards/mts400/gps.h
:75: warning: tag GPS_Msg shadows enclosing struct/union/enum
G:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/contrib/xbow/tos/sensorboards/mts400/TaosP
hotoM.nc:207: warning: `I2CPacket.writePacket' called asynchronously from `ADC.g
etData'
G:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/contrib/xbow/tos/sensorboards/mts400/TaosP
hotoM.nc:200: warning: `I2CPacket.writePacket' called asynchronously from `ADC.g
etData'
G:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/contrib/xbow/tos/sensorboards/mts400/Inter
semaPressureM.nc:282: warning: `LowerControl.start' called asynchronously from `
Temperature.getData'
G:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/contrib/xbow/tos/sensorboards/mts400/Inter
semaPressureM.nc:305: warning: `LowerControl.start' called asynchronously from `
Pressure.getData'
G:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/contrib/xbow/tos/sensorboards/mts400/Sensi
rionHumidityM.nc:320: warning: `SwitchI2W.set' called asynchronously from `HumSe
nsor.dataReady'
G:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/contrib/xbow/tos/sensorboards/mts400/Sensi
rionHumidityM.nc:300: warning: `SwitchI2W.set' called asynchronously from `TempS
ensor.dataReady'
G:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/contrib/xbow/tos/sensorboards/mts400/Sensi
rionHumidityM.nc:274: warning: `SwitchI2W.set' called asynchronously from `Tempe
rature.getData'
G:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/contrib/xbow/tos/sensorboards/mts400/Sensi
rionHumidityM.nc:259: warning: `SwitchI2W.set' called asynchronously from `Humid
ity.getData'
G:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/contrib/xbow/tos/sensorboards/mts400/TempH
17
umM.nc:212: warning: `Timer.start' called asynchronously from `processCommand'
G:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/contrib/xbow/tos/sensorboards/mts400/TempH
umM.nc:208: warning: `Timer.start' called asynchronously from `processCommand'
TestMTS400M.nc:188: warning: non-atomic accesses to shared variable `pack':
TestMTS400M.nc:286: warning:
non-atomic write
G:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/tos/system/RealMain.nc: In function `main'
:
G:/PROGRA~1/UCB/cygwin/opt/tinyos-1.x/tos/interfaces/StdControl.nc:63: warning:
`result' might be used uninitialized in this function
compiled TestMTS400 to build/mica2/main.exe
27864 bytes in ROM
2706 bytes in RAM
avr-objcopy --output-target=srec build/mica2/main.exe build/mica2/main.srec
set-mote-id build/mica2/main.srec build/mica2/main.srec.out 1
installing mica2 binary using mib510
uisp -dprog=mib510 -dserial=com1 -dpart=ATmega128 --wr_fuse_e=ff
--erase --uplo
ad if=build/mica2/main.srec.out
Firmware Version: 2.1
Atmel AVR ATmega128 is found.
Uploading: flash
Fuse Extended Byte set to 0xff
Marble1@marble /opt/tinyos-1.x/contrib/xbow/apps/XSensorMTS400
$
The warning messages displayed during compilation of the program
could be safely ignored.
4.3 Run Xlisten on the host computer
Acceptance Criteria:
Compile and run Xlisten according to the procedure in section 3.5. A
file of the name specified in the command shall be created and data
shall be written to the file as data is being sent from the mote with
the GPS module.
18
Result:
Xlisten was compiled without any error. A new CSV (Comma
Separated Values) file was created while Xlisten is being run. Output
from compiling and running the programs are included below.
Marble1@marble /opt/tinyos-1.x/contrib/xbow/tools/src/xlisten
$ make
gcc -O2 -Wall -Wno-format -o xlisten xlisten.c xpacket.c xconvert.c xdb.c xseria
l.c xsocket.c
boards/mts300.c boards/mts400.c boards/mts510.c boards/mts101.c b
oards/mep500.c boards/mep401.c boards/mda500.c boards/mda300.c timestamp/timesta
mp.c -lm -lpq
xlisten.c:15: warning: `g_version' defined but not used
Marble1@marble /opt/tinyos-1.x/contrib/xbow/tools/src/xlisten
$ ./xlisten.exe > output.csv
Marble1@marble /opt/tinyos-1.x/contrib/xbow/tools/src/xlisten
$ ls -l
total 130
-rw-r--r-drwxr-xr-x
-rw-r--r-drwxr-xr-x
1 Marble1
2 Marble1
1 Marble1
2 Marble1
None
None
None
None
820 Aug 26 2004 Makefile
0 May 11 12:38 boards
2951 Jun 1 00:47 output.csv
0 May 11 12:38 timestamp
-rw-r--r--
1 Marble1
None
-rw-r--r--
1 Marble1
None
1552 Aug 11 2004 xconvert.h
-rw-r--r--
1 Marble1
None
3023 Aug 11 2004 xdb.c
-rw-r--r--
1 Marble1
None
-rw-r--r--
1 Marble1
None
-rwxr-xr-x
1 Marble1
None
10119 Aug 11
2004 xconvert.c
601 Aug 9
2004 xdb.h
19241 Jun 1 00:47 xlisten.c
66208 Jun
1 00:47 xlisten.exe
-rw-r--r--
1 Marble1
None
8536 Aug 9
2004 xpacket.c
-rw-r--r--
1 Marble1
None
5678 Aug 26 2004 xsensors.h
-rw-r--r--
1 Marble1
None
5908 May 31 21:01 xserial.c
-rw-r--r--
1 Marble1
None
4128 Aug 22 2004 xsocket.c
19
4.4 Running GPS Application
Acceptance Criteria:
The second Crossbow Mote should be programmed according to
the procedure and criteria specified in section 3.4 and 3.6. Xlisten
should also be executed as specified in section 3.5 to record the
valid packets that are sent by the mote. A map shall be constructed
using Matlab and the “Import Data Wizard” of Microsoft Streets and
Trips.
Result:
The test was conducted in the campus of Cal Poly, SLO.
The mote was programmed to collect 40 packets in a span of 10
minutes (15 seconds apart for each packet). However, due to the
long synchronization time between the GPS module and the GPS
satellites, only 14 packets were valid and recorded by Xlisten. These
14 valid data packets were used to construct maps with Matlab
(Appendix I) and Microsoft Streets and Trips. The collected data and
two maps are included below.
20
23
23
50.086
35.29979
-120.659
1
23
24
19.084
35.29956
-120.659
1
23
24
34.083
35.29961
-120.659
1
23
24
49.082
35.29961
-120.659
1
23
25
33.079
35.29966
-120.659
1
23
25
47.078
35.29977
-120.659
1
23
26
2.077
35.2999
-120.658
1
23
26
17.077
35.29992
-120.658
1
23
26
31.076
35.29974
-120.658
1
23
26
46.075
35.2995
-120.659
1
23
27
0.074
35.29945
-120.659
1
23
27
15.073
35.29947
-120.659
1
23
27
30.072
35.29971
-120.658
1
23
27
44.071
35.29965
-120.659
1
Table 1. GPS “Cooked” Data from Xlisten
21
Figure 7. GPS Location produced by Matlab
Figure 8. GPS Location produced by MS Streets and Trips
22
As one can see, the data points in the two maps spread out very
similarly as they were produced by the same data set. The data
points shown were collected towards the end of the “data collection
phase” as my partner and I were walking down the S. Perimeter
Road toward Building 20.
23
5.0 Conclusion
This project was very interesting but also very time-consuming. As we
had to learn everything from the wireless sensing technology to
TinyOS, a lot of time was spent on reading documentation, browsing
forums, studying spec sheets and codes. My classes in the computer
engineering area proved to be extremely helpful toward the end of the
project.
I had a lot of difficulties starting the project, because there were no
documentation or examples on how to start programming in NesC
with the GPS module. Even after some intense research on the
Internet, it took a while before finally getting a version of the test
application that actually works with the GPS module.
Recommendation:
There is a lot of improvements can be done with the TestMTS400 test
application. Students who will assume this project in the future should
consider adding the ad-hoc networking capability to the motes to
create a much larger sensing area and using the EEPROM as the
storage memory instead of the Random Access Memory in order to
participate in future data sensing intense applications.
24
6.0 Reference
1. Getting Started Guide Rev. B, Doc # 7430-0022-05. Crossbow
Technology, Inc. August 2004
2. MTS/MDA Sensor and Data Acquisition Boards User’s manual Rev.
A, Doc # 7430-0020-03. Crossbow Technology, Inc. April 2004
3. Betke, Klaus. The NMEA 0183 Protocol. August 2001
4. GPS OEM Module. P/N W9000257. Leadtek. 2003
5. TinyOS Tutorial. UC Berkeley. 23 May 2005.
<http://www.tinyos.net/tinyos-1.x/doc/tutorial>.
6. Related. Berkeley WEBS: Wireless Embedded System.
7 June 2005. <http://www.tinyos.net/related.html>
7. Brain, Marshall, and Harris, Tom. How GPS Receiver Work. How
Stuff Works. 23 May 2005.
<http://electronics.howstuffworks.com/gps.htm>.
8. Global Position System. Federal Aviation Administration. 24 May
2005. <http://gps.faa.gov/GPSbasics/index.htm>.
9. Trilateration. Wikipedia, 25 May 2005.
<http://en.wikipedia.org/wiki/Trilateration>
10. Jose Becerra. Cal Poly Wireless Sensor Network Demonstration
Project, M.S. Thesis. Department of Electrical Engineering, Cal
Poly, San Luis Obispo, CA. September 2005.
25
7.0 Appendices
Appendix A - Installing and Setting up TinyOS
TinyOS could be obtained from various sources. This section will
provide a brief instruction on how to download and setup TinyOS in
Windows platform. For instruction on how to setup TinyOS in a Linux
box, visit <http://www.tinyos.net/tinyos-1.x/doc/install.html#linux>.
There are two ways to setup TinyOS 1.1.7:
1.
Setup TinyOS 1.1.0 and upgrade to 1.1.7
 Download the Windows installer from
http://www.tinyos.net/windows-1_1_0.html
 Follow install instructions or screen, install all default
components during the installation.
 Upon successful installation, upgrade to TinyOS 1.1.7
 Download the RPM file from
<http://www.tinyos.net/dist-1.1.0/tinyos/windows/tinyos-1.1.7July
2004cvs-2.cygwin.noarch.rpm>
 Save the file to the folder of your choice. After downloading, run
Cygwin and proceed to where the RPM file is saved.
 Type the following command to begin the upgrading process:
rpm --force --ignoreos -Uvh tinyos-1.1.7July2004cvs-2.cygwin.noarch.rpm
26
2.
Setup TinyOS 1.1.7 directly
 Download and save all files from
<http://www.tinyos.net/dist-1.1.0/tinyos/windows/tinyos-1.1.7
-installer-2/>
 Double Click on “Setup.exe” to begin the installation, install all
default components during the installation.
To verify that TinyOS has been setup correctly, run the script
“toscheck” from “/opt/tinyos-1.x/cygwin/opt/tinyos-1.x/tools/scripts”.
If the last line of the output is “toscheck completed without error”, then
TinyOS is setup correctly.
In order for the XSensor applications to run correctly, a package from
Crossbow is required. To obtain the package, open Cygwin and run
the following commands:
1.
cd /opt
2.
cvs –d:pserver:[email protected]:/cvsroot
/tinyos login
3.
cvs –z3 –d:pserver:[email protected]:/cvsroot
/tinyos co –P tinyos1.x/contrib./xbow
The CVS checkout process might take a while. When it is finished, the
package will be installed under “/opt/tinyos-1.x/contrib/xbow”. Now
the computer is ready to use!
27
Appendix B – Changing default mote settings
The file “MakeXbowlocal” in the “$TOSROOT/contrib./xbow/apps”
directory allows the user to change different default settings of the
motes, for example, group ID, transmission power and frequency.
The group ID can be changed by replacing the hexadecimal values
after the “=” sign in line “DEFAULT_LOCAL_GROUP=0x7D”.
The transmission power and frequency could be changed by
commenting out the lines with the old values, and uncomment
the lines with desired numbers. For example, to change the
frequency from 914.077MHz to 915.998MHz, modify the code as
follow:
#CFLAGS = -DCC1K_DEFAULT_FREQ=CC1K_914_077_MHZ
CFLAGS = -DCC1K_DEFAULT_FREQ=CC1K_915_998_MHZ
The “#” sign comments out a line of code.
28
Appendix C – NMEA-0183 GGA Data Format
The GPS packet shall be in the GGA format under the NMEA-0183
standard. The data shall be represented in ASCII text and is in the
format as below:
1
2
3
4
5 6 7 8 9 10 11 12 13 14 15
$--GGA,hhmmss.ss,llll.ll,a,yyyyy.yy,a,x,xx,x.x,x.x,M,x.x,M,x.x,xxxx*hh
1) Time (UTC)
2) Latitude
3) N or S (North or South)
4) Longitude
5) E or W (East or West)
6) GPS Quality Indicator,
0 - fix not available,
1 - GPS fix,
2 - Differential GPS fix
7) Number of satellites in view, 00 - 12
8) Horizontal Dilution of precision
9) Antenna Altitude above/below mean-sea-level (geoid)
10) Units of antenna altitude, meters
11) Geoidal separation, the difference between the WGS-84 earth
ellipsoid and mean-sea-level (geoid), "-" means mean-sea-level
below
12) Units of geoidal separation, meters
13) Age of differential GPS data, time in seconds since last SC104
type 1 or 9 update, null field when DGPS is not used
14) Differential reference station ID, 0000-1023
15) Checksum
29
Appendix D – TestMTS400M.nc
The TestMTS400 application is originally written by the staff at
Crossbow Technology. There are a several versions of this test
application, and the one being used in this project is v.1.27. It is
intended for testing and verifying the function of the MTS400/420
sensor boards. For the purpose of this senior project, it has been
modified to provide more control to the application. The following
diagram shows the control flow of the modified TestMTS400M.nc.
START
* start of program
START
GPS_BUSY
SEND UART
MSG
GPS_DONE
N
SEND UART
MSG
SEND RF
MSG
Enough
Packets?
Timer1
Fired?
Y
Y
Figure 9. Control Flow of TestMTS400M.nc
N
30
Following is the modifications done to the TestMTS400M application.
1.
Adding new parameters to provide more control
#define COLLECT_PERIOD 22500
// unit in ms,time between each packet colleted,
// recommend minimum of 3 sec
#define SEND_PERIOD 100
#define TIMER1_PERIOD 600000
// unit in ms, time between each packet sent
// TIMER1_PERIOD >> SEND_PERIOD
#define GPS_MAX_WAIT 20
// max wait time for gps packet =
GPS_MAX_WAIT*TIMER_PERIOD
#define ARR_SIZE 40
2.
// # of packets to be collected
Rewrite the send_msg() task
task void send_msg(){
if (sending_packet) return;
atomic sending_packet = TRUE;
pack->xSensorHeader.board_id = SENSOR_BOARD_ID;
pack->xSensorHeader.packet_id = iNextPacketID;
pack->xSensorHeader.node_id
= TOS_LOCAL_ADDRESS;
//pack->xSensorHeader.rsvd
= 0;
call Leds.yellowOn();
if(CollectData)
{
/* Data is collected, to be stored into array */
call GpsCmd.PowerSwitch(1);
//Power On GPS
buf[(sample_cnt++)%ARR_SIZE] = msg_buf;
if(call
Send.send(TOS_UART_ADDR,sizeof(XDataMsg)-1,msg_ptr)!=SUCCESS)
{
atomic sending_packet = FALSE;
31
call Leds.greenToggle();
}
}
else
{
/* ARR_SIZE packets are collected, GPS is off for RF transmission */
call GpsCmd.PowerSwitch(0);
if(IsUART)
//avoid interference to RF link
//alternate between UART and RF msg
{
if(call
Send.send(TOS_UART_ADDR,sizeof(XDataMsg)-1,&buf[sending%sample_cnt])!=SUC
CESS)
{
atomic sending_packet = FALSE;
call Leds.greenToggle();
}
}
else
{
call Leds.greenOn();
if(call
Send.send(TOS_BCAST_ADDR,sizeof(XDataMsg)-1,&buf[sending%sample_cnt])!=
SUCCESS)
{
atomic sending_packet = FALSE;
call Leds.greenToggle();
}
}
}
return;
}
32
3.
Rewrite the sendDone() function
event result_t Send.sendDone(TOS_MsgPtr msg, result_t success) {
call Leds.yellowOff();
if(CollectData)
{
/* enough packets collected, switch to sending mode */
if(sample_cnt != 0 && ((sample_cnt % ARR_SIZE) == 0))
{
CollectData = FALSE;
sending = 0;
call Timer1.start(TIMER_ONE_SHOT, TIMER1_PERIOD);
TIMER_PERIOD = SEND_PERIOD;
call Timer.start(TIMER_REPEAT,TIMER_PERIOD);
}
atomic
{
WaitingForSend = !CollectData;
sending_packet = FALSE;
}
}
else
{
if(IsUART){
IsUART = !IsUART;
// change to radio send
atomic
{
WaitingForSend = TRUE;
// uart sent, issue radio send
sending_packet = FALSE;
}
}
else
{
IsUART = !IsUART; // change to uart send
atomic
33
{
WaitingForSend = !CollectData;
sending_packet = FALSE;
sending++;
}
}
return SUCCESS;
}
}
// both uart and radio sent
34
Appendix E – TestMTS400.nc
This is the configuration file of TestMTS400.
#include "appFeatures.h"
includes sensorboardApp;
configuration TestMTS400 {
// this module does not provide any interface
}
implementation {
components Main, TestMTS400M, SensirionHumidity,
IntersemaPressure,MicaWbSwitch,GenericComm as Comm,
TimerC, Voltage, LedsC, Accel, TaosPhoto,
#ifdef MTS420
UARTGpsPacket,
#endif
ADCC;
Main.StdControl -> TestMTS400M;
Main.StdControl -> TimerC;
TestMTS400M.CommControl -> Comm;
TestMTS400M.Receive -> Comm.ReceiveMsg[AM_XSXMSG];
TestMTS400M.Send -> Comm.SendMsg[AM_XSXMSG];
// Wiring for gps
#ifdef MTS420
TestMTS400M.GpsControl -> UARTGpsPacket;
//TestMTS400M.GpsSend -> UARTGpsPacket;
TestMTS400M.GpsReceive -> UARTGpsPacket;
TestMTS400M.GpsCmd -> UARTGpsPacket.GpsCmd;
//UARTGpsPacket.GpsCmd;
#endif
// Wiring for Battery Ref
35
TestMTS400M.BattControl -> Voltage;
TestMTS400M.ADCBATT -> Voltage;
// Wiring for Taos light sensor
TestMTS400M.TaosControl -> TaosPhoto;
TestMTS400M.TaosCh0 -> TaosPhoto.ADC[0];
TestMTS400M.TaosCh1 -> TaosPhoto.ADC[1];
// Wiring for Accelerometer
TestMTS400M.AccelControl->Accel.StdControl;
TestMTS400M.AccelCmd -> Accel.AccelCmd;
TestMTS400M.AccelX -> Accel.AccelX;
TestMTS400M.AccelY -> Accel.AccelY;
// Wiring for Sensirion humidity/temperature sensor
TestMTS400M.TempHumControl -> SensirionHumidity;
TestMTS400M.Humidity -> SensirionHumidity.Humidity;
TestMTS400M.Temperature -> SensirionHumidity.Temperature;
TestMTS400M.HumidityError -> SensirionHumidity.HumidityError;
TestMTS400M.TemperatureError -> SensirionHumidity.TemperatureError;
// Wiring for Intersema barometric pressure/temperature sensor
TestMTS400M.IntersemaCal -> IntersemaPressure;
TestMTS400M.PressureControl -> IntersemaPressure;
TestMTS400M.IntersemaPressure -> IntersemaPressure.Pressure;
TestMTS400M.IntersemaTemp -> IntersemaPressure.Temperature;
TestMTS400M.Leds -> LedsC;
TestMTS400M.Timer -> TimerC.Timer[unique("Timer")];
TestMTS400M.Timer1 -> TimerC.Timer[unique("Timer")];
}
36
Appendix F – sensorboardApps.h
#define MAKE_GPS_ENA_OUTPUT() sbi(DDRE,6)
#define SET_GPS_ENA() cbi(PORTE,6)
#define CLR_GPS_ENA() sbi(PORTE,6)
#define GPS_MSG_LENGTH 100
#define GPS_CHAR 11
#define GGA_FIELDS 8
#define GPS_CHAR_PER_FIELD 10
#define GPS_DELIMITER ','
#define GPS_END_MSG '*'
typedef struct XSensorHeader{
uint8_t board_id;
uint8_t packet_id; // 3
uint8_t node_id;
uint8_t rsvd;
}__attribute__ ((packed)) XSensorHeader;
typedef struct GGAMsg
{
uint8_t hour;
uint8_t minute;
uint8_t lat_deg;
uint8_t long_deg;
uint32_t dec_sec;
uint32_t lat_dec_min;
uint32_t long_dec_min;
uint8_t nsewind;
uint8_t fixed;
} __attribute__ ((packed)) GGAMsg;
typedef struct XSensorMTS400DataMsg
{
37
uint16_t vref;
uint16_t humidity;
uint16_t temperature;
uint16_t cal_wrod1;
uint16_t cal_wrod2;
uint16_t cal_wrod3;
uint16_t cal_wrod4;
uint16_t intersematemp;
uint16_t pressure;
uint16_t taoch0;
uint16_t taoch1;
uint16_t accel_x;
uint16_t accel_y;
} __attribute__ ((packed)) XSensorMTS400DataMsg;
enum {
AM_XSXMSG = 0,
};
typedef struct XDataMsg {
XSensorHeader xSensorHeader;
union {
XSensorMTS400DataMsg
GGAMsg
data1;
dataGps;
}xData;
} __attribute__ ((packed)) XDataMsg;
38
Appendix G – appFeatures.h
//define MTS420 to enable gps.
// MTS400 will not send gps packets.
// Uncomment the following line if you are using a MTS420 board.
#define MTS420
#ifndef MTS420
#define SENSOR_BOARD_ID 0x85
//MTS400 sensor board id
#else
#define SENSOR_BOARD_ID 0x86
#endif
#define FEATURE_GPS_ONLY 1
#ifndef FEATURE_GPS_ONLY
#define FEATURE_GPS_ONLY 0
#endif
//MTS420 sensor board id
39
Appendix H – Xlisten
Refer to Jose Becerra’s master thesis. (Reference 10)
40
Appendix I – GPS.m
This matlab program imports the data from the .csv file and plots the
data points in a window.
data=csvREAD('C:\tinyos\cygwin\opt\tinyos-1.x\contrib\xbow\tools\src\
xlisten\june2.csv',1,0)
latitude=data(:,4);
%Get column 4 and store it in latitude
longitude=data(:,5);
%Get column 5 and store it in longitude
%***********************************************
Max1=size(longitude);
n=1;
%newplot
xmax=max(longitude)
xmin=min(longitude)
ymax=max(latitude)
ymin=min(latitude)
axis([xmin,xmax,ymin,ymax])
for n =1:Max1,
plot(longitude(n),latitude(n),'o')
hold on
grid
xlabel('Longitude')
ylabel('Latitude')
Title('GPS location')
pause
end
41
Appendix J – Analysis of Senior Project Design
Summary of Functional Requirements
This project demonstrates the basic capabilities of the Crossbow
Wireless Sensor Network hardware. The focus of this project is to use
the GPS module of one of the Crossbow sensor boards to collect
position data, and transmit the data to a base station wirelessly for
data analysis. The base station is connected to a PC through a serial
port; the data received can then be processed with Matlab or
MS-Excel.
Primary Constraints
One of the main difficulties our group had was to learn about the
hardwares, as there are not many information and help provided for
this new technology yet. Another difficulty is the availability of the
resource. Because the motes could only be programmed with the one
programming board in the development kit, when one person is
working with it, the others will have to wait for their turns.
Economic
Original estimate cost of component parts:
$795 – mote-kit
Actual final cost of component parts:
$795 + $375 – mote-kit + GPS sensor board
42
Original estimated development time: six months
Actual development time: six months
Environmental
There is no environmental impact associated with the use of the
Crossbow products.
Sustainability
Main issue when using the GPS module is power usage. The batteries
are drained out quickly when the GPS receiver is powered on. Lithium
batteries of 3.3-3.6V are recommended by Crossbow to power the
mote.
Ethical
There are not any ethical implications relating to the design,
manufacturing, use, or misuse of the project.
Health and Safety
There are not any health and safety concerns associated with design,
manufacturing and use of the project
Social and Political
There are not any social and political concerns associated with design,
manufacturing and use of the project.
43
Development
Throughout the project, I have learned to better manage my time and
to communicate efficiently with my group members. These skills are
very important when working in the industry.