Beyond GPS
Neogeography Data Collection
Andrew Turner - andrew@mapufacture.com

OpenStreetMap

OpenStreetMap

What’s Next?

Tracking

WiFi

gsmloc

nike+

the packet level (including checksum verification); and log-
ging what sensors have been seen and when. See Figure 8.
Logs for multiple serial port traces are interleaved so that
one may see the data exchange or protocol of two devices
(in our case, the iPod and the receiver).
Our tool also provides a graphical interface for: sending and
receiving binary data in hex format over up to two serial
ports; viewing hex and ASCII representation of incoming
packets; and viewing what sensors have been seen and when
new packets for those sensors arrive. Our sensor visualiza-
tion consists of a blue rectangle for each seen sensor with
its UID in hex and the last time it was seen. Each time
the sensor is seen the box for that sensor becomes red and
slowly becomes blue (from top to bottom) over the follow-
ing five seconds. This allows one to get a sense of which
awake sensors are in range and how many of their packets
are arriving uncorrupted.
Optionally, our tool can take a picture whenever a new sen-
sor is discovered using most USB cameras and make that
photo the background of the blue box in the sensor visual-
ization. This application can also serve as a data collection
node in a larger surveillance network. To support this task,
the tool can upload to a SQL server sensor events including
UID, optional photo, timestamp, latitude, and longitude. Figure 9: A Microsoft SPOT Watch receiving
(Latitude and longitude are currently set manually by the Nike+iPod sensor IDs from an iMote2 over wireless
user; one could, however, imagine linking a bluetooth GPS bluetooth.
receiver so that a mobile receiver on a car or bike could do
accurate data collection.)
on his or her watch. See Figure 9.
The tool can also SMS or email sensor information to users.
This tool is implemented in approximately 2000 lines of C# The sensor events logged to file can also be manually up-
and XAML on Microsoft .NET 3.0 for Microsoft Windows loaded to a central server for aggregation with sensor infor-
XP or later. mation from the Serial Communication Tool. A straight-
forward extension to this device would be for the iMote2
to obtain real-time location information from a bluetooth
4.3 Intel Motes
GPS sensor; this would enable an attacker to collect accu-
In addition to our serial communication tool for Windows we
rate sensor location information while the attacker is mo-
have also created an embedded module for logging and track-
bile. Another straightforward extension would be to create
ing Nike+iPod sensors using version 2 of the Intel Motes
a large, distributed surveillance sensor network consisting of
(iMote2). This module consists of an iMote2, an unmodified
multiple iMote2 nodes, and to upload surveillance data in
Nike+iPod receiver, female iPod connector, and an iMote2
real-time to some central SQL server. Rather than imple-
utility daughter board with bluetooth. The assembled pack-
ment this latter capability in our iMote2s, we do so with our
age is 5cm x 3.8cm x 2.5cm, weighs 2.3 ounces, and has a
gumstix in Section 4.4.
storage capacity of 2GB via a Mini Secure Digital card.
4.4 Gumstixs
The iMote2 runs the Linux operating system and our soft-
ware is written in C. The iMote2 communicates with the We have also implemented a cheap Nike+iPod surveillance
receiver using a serial port. On boot, the iMote2 sends ini- device using the Linux-based gumstix computers. This mod-
tialization and link commands to the receiver and begins ule consists of an unmodified $29 Nike+iPod receiver, a $109
nike+
logging sensor events to a file. Optionally, the software can gumstix connex 200xm motherboard, a $79 wifistix, a $27.50
turn on an LED when the iMote2 detects that one or more gumstix breakout board, and a $2.95 female iPod connector.
prespecified sensors are nearby. The set of target sensors is The assembled package is 8cm x 2.1cm x 1.3cm and weighs
specified in a configuration file. One can imagine using the 1.1 ounces; see Figure 10.
LED-based alarm as a discrete mechanism for visually noti-
fying a user when a target victim’s sensor is nearby. There Our gumstix-based module runs the same surveillance soft-
are obvious audio (buzzer) and physical (vibrate) extensions. ware that our iMote2s run, except that (1) the software on
Figure 11: A screenshot of our GoogleMaps-based the gumstix module uses WiFi to wirelessly transmit real-
We have instrumented our iMote2 to communicate the UIDs time surveillance data to a centralized back-end server and
surveillance webof application. SPOT Watch over blue-
sensors in range to a Microsoft (2) our gumstixs do not pair with a Microsoft SPOT Watch.
-based Nike+iPod surveillance tooth. Using our system, an adversary could put the iMote2 The real-time reporting capability allows the gumstix mod-
and receiver in his or her backpack, purse, or pocket, and ule to be part of a larger real-time surveillance system. If an
eless capabilities. still continuously monitor information about nearby sensors adversary does not need this real-time capability, then the
To illustrate the power of aggregating sensor information
from multiple physical locations, we created a GoogleMaps-

RFID

AIS

Imagery

Quakr

Quakr

OpenStreetView
http://icanhascheezburger.com/2007/06/19/o-hai-googlz/

Kite Photography

Kite Photography

DIYDrones

+ =
Pict’Earth

Pict’Earth

OpenAerialMap

Environmental

Urban Atmospheres

AIR

PigeonBlog

Fuel Economy
T.J. Giuli

BioMapping

Satellites

GeoBliki

Links
http://del.icio.us/tags/BeyondGPS
Andrew Turner - andrew@mapufacture.com