Beyond GPS - Neogeograpy Data Collection

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

OpenStreetMap

What’s Next?

Tracking

gsmloc

the packet level (including checksum verification); and logging 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 sensor 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 straightforward 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 software 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-

Imagery

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

Kite Photography

DIYDrones

+ = Pict’Earth

Pict’Earth

OpenAerialMap

Environmental

Urban Atmospheres

PigeonBlog

Fuel Economy T.J. Giuli

BioMapping

Satellites

GeoBliki

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

http://highearthorbit.com	158
http://www.slideshare.net	6
file://	5
http://www.highearthorbit.com	4
http://www.netvibes.com	1
http://64.233.179.104	1

Beyond GPS - Neogeograpy Data Collection

by Andrew Turner on Sep 28, 2007

Accessibility

Categories

Tags

Upload Details

Usage Rights

6 Embeds 175

Statistics

Beyond GPS - Neogeograpy Data Collection — Presentation Transcript