[Dataset] mannheim/compass (v. 2008-04-11)

top

Two tracesets mannheim/compass/802.11 and mannheim/compass/fingerprint have been added.

The changed components are as follows:

@MISC{mannheim-compass-2008-04-11,
  author = {Thomas King and Stephan Kopf and Thomas Haenselmann and Christian Lubberger and Wolfgang Effelsberg},
  title = {{CRAWDAD} data set mannheim/compass (v. 2008-04-11)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/mannheim/compass},
  month = apr,  
  year = 2008
}
					

COMPASS is a positioning system based on 802.11 and digital compasses. We 
apply an two-stage fingerprinting approach: In the training phase, we sample 
the signal strength of neighboring access points for selected orientations at 
each reference point and store the data in a database. During the positioning 
phase, the orientation of the user is utilized to preselect a subset of the 
training data and based on this data compute her position.

Positioning systems are one of the key elements required by
location-based services. We design and implement a positioning system 
called COMPASS which is based on 802.11-compliant network infrastructure 
and digital compasses. On the mobile device, COMPASS samples the signal 
strength values of different access points in its communication range 
and utilizes the orientation of the user to preselect a subset of 
the training data. The remaining training data is used by a probabilistic 
positioning algorithm to determine the position of the user.

While prior systems show limited accuracy due to blocking effects
caused by the human body, we apply digital compasses to detect
the orientations of the users so that they can deal with these blocking
effects. After a short period of training the COMPASS system achieves 
an average error distance of less than 1.65 meters in the experimental 
environment of 312 square meters.

The test environment is equipped with five Linksys / Cisco WRT54GS and 
four Lancom L-54g access points. All access points support 802.11b and 
802.11g. One Lancom and all Linksys access points are located on the same 
floor as our testing area whereas three Lancom access point are located 
in other places inside the building. The exact position of the access points 
located inside the testing area is marked by squares in the floor plan 
(see the download link below).

We deployed our positioning system in the hallway of an office
building on the campus of the University of Mannheim. The operation
area is nearly 15 meters in width and 36 meters in length,
covering an area of approximately 312 square meters. The floor
plan of the testing area is shown in the floor plan figure 
(see the download link below).  The large hallway in the left part of 
the map is connected by two narrow hallways that are separated by rooms 
such as archives and a kitchen.

We marked the floor plan (see the download link below) with markers 
depicting the grid of the reference points (light-colored dots) and 
the online measurement points (dark dots). The access points are 
marked by squares.

As a client, we used a Lucent Orinco Silver PCMCIA network
card supporting 802.11b. We collected the signal strength samples
on an IBMThinkpad R51 running Linux kernel 2.6.13 and Wireless
Tools 28pre.

To obtain the orientation of the user we used the Silicon Laboratories
C8051F350 Digital Compass Reference Design Board. This device provides 
a USB-to-Serial bridge to access the data and is powered by the USB 
electricity supply. We calibrated the compass in the middle of the operation 
area. In a closer area around the calibration point we measured a variation of 
1 degree. However, variations up to 23 degree were rarely detected at a few 
points of the testing area. These measurement errors occured always close 
to electromagnetic objects such as high-voltage power lines and electronic devices.

[Traceset] mannheim/compass/signalstrength (v. 2006-09-13)

top

the initial version

@MISC{mannheim-compass-signalstrength-2006-09-13,
  author = {Thomas King and Stephan Kopf and Thomas Haenselmann and Christian Lubberger and Wolfgang Effelsberg},
  title = {{CRAWDAD} trace set mannheim/compass/signalstrength (v. 2006-09-13)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/mannheim/compass/signalstrength},
  month = sep,  
  year = 2006
}
					

A traceset of signal strength collected from 802.11 APs 
for the location estimation used by the COMPASS positioning system

The grid of reference points applied to the operation area includes
166 points with a spacing of 1 meter (see the light-colored
dots in the floorplan figure). 

During the offline phase, the signal strength was measured at reference points 
for different orientations.  We then randomly selected 60 coordinates and 
orientations for the online phase.

[Traceset] mannheim/compass/802.11 (v. 2008-04-11)

top

the initial version

@MISC{mannheim-compass-802.11-2008-04-11,
  author = {Thomas King and Stephan Kopf and Thomas Haenselmann and Christian Lubberger and Wolfgang Effelsberg},
  title = {{CRAWDAD} trace set mannheim/compass/802.11 (v. 2008-04-11)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/mannheim/compass/802.11},
  month = apr,  
  year = 2008
}
					

[Traceset] mannheim/compass/fingerprint (v. 2008-04-11)

top

the initial version

@MISC{mannheim-compass-fingerprint-2008-04-11,
  author = {Thomas King and Stephan Kopf and Thomas Haenselmann and Christian Lubberger and Wolfgang Effelsberg},
  title = {{CRAWDAD} trace set mannheim/compass/fingerprint (v. 2008-04-11)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/mannheim/compass/fingerprint},
  month = apr,  
  year = 2008
}
					

[Trace] mannheim/compass/signalstrength/offline (v. 2006-09-13)

top

the initial version

@MISC{mannheim-compass-signalstrength-offline-2006-09-13,
  author = {Thomas King and Stephan Kopf and Thomas Haenselmann and Christian Lubberger and Wolfgang Effelsberg},
  title = {{CRAWDAD} trace mannheim/compass/signalstrength/offline (v. 2006-09-13)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/mannheim/compass/signalstrength/offline},
  month = sep,  
  year = 2006
}
					

A trace of signal strength values from 802.11 APs measured 
at reference points for different orientations for the offline phase of the COMPASS 
positioning system.

During the offline phase, the signal strength was measured at reference points 
for different orientations. We collected 110 signal strength measurements 
at each reference point and for each orientation. This leads to 146,080 
measurements for the offline phase. We spent over 10 hours to collect all the data.

t="Timestamp"; id="MACofScanDevice"; pos="RealPosition"; degree="orientation"; "MACofResponse1"="SignalStrengthValue","Frequency","Mode"; ... "MACofResponseN"="SignalStrengthValue","Frequency","Mode"
t: timestamp in milliseconds since midnight, January 1, 1970 UTC
id: MAC address of the scanning device
pos: the physical coordinate of the scanning device
degree: orientation of the user carrying the scanning device in degrees
MAC: MAC address of a responding peer (e.g. an access point or a device in adhoc mode) 
with the corresponding values for signal strength in dBm, the channel frequency and 
its mode (access point = 3, device in adhoc mode = 1)

[Trace] mannheim/compass/signalstrength/online (v. 2006-09-13)

top

the initial version

@MISC{mannheim-compass-signalstrength-online-2006-09-13,
  author = {Thomas King and Stephan Kopf and Thomas Haenselmann and Christian Lubberger and Wolfgang Effelsberg},
  title = {{CRAWDAD} trace mannheim/compass/signalstrength/online (v. 2006-09-13)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/mannheim/compass/signalstrength/online},
  month = sep,  
  year = 2006
}
					

A trace of signal strength, which is derived from 
mannheim/compass/signalstrength/offline for online phase of the COMPASS 
positioning system.

We randomly selected 60 coordinates and orientations for the
online phase. The only condition to select a point inside the testing
area as an online set point is that it is surrounded by four reference
points. Again, we collected 110 signal strength measurements for
each online set point, leading to 6,600 measurements in total. In
Figure 3 the online set points are marked by dark dots.

t="Timestamp"; id="MACofScanDevice"; pos="RealPosition"; degree="orientation"; "MACofResponse1"="SignalStrengthValue","Frequency","Mode"; ... "MACofResponseN"="SignalStrengthValue","Frequency","Mode"
t: timestamp in milliseconds since midnight, January 1, 1970 UTC
id: MAC address of the scanning device
pos: the physical coordinate of the scanning device
degree: orientation of the user carrying the scanning device in degrees
MAC: MAC address of a responding peer (e.g. an access point or a device in adhoc mode) 
with the corresponding values for signal strength in dBm, the channel frequency and 
its mode (access point = 3, device in adhoc mode = 1)

[Trace] mannheim/compass/802.11/offline (v. 2008-04-11)

top

the initial version

@MISC{mannheim-compass-802.11-offline-2008-04-11,
  author = {Thomas King and Stephan Kopf and Thomas Haenselmann and Christian Lubberger and Wolfgang Effelsberg},
  title = {{CRAWDAD} trace mannheim/compass/802.11/offline (v. 2008-04-11)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/mannheim/compass/802.11/offline},
  month = apr,  
  year = 2008
}
					

t="Timestamp"; id="MACofScanDevice"; pos="RealPosition"; degree="orientation"; "MACofResponse1"="SignalStrengthValue","Frequency","Mode"; ... "MACofResponseN"="SignalStrengthValue","Frequency","Mode"
t: timestamp in milliseconds since midnight, January 1, 1970 UTC
id: MAC address of the scanning device
pos: the physical coordinate of the scanning device
degree: orientation of the user carrying the scanning device in degrees
MAC: MAC address of a responding peer (e.g. an access point or a device in adhoc mode) 
with the corresponding values for signal strength in dBm, the channel frequency and 
its mode (access point = 3, device in adhoc mode = 1)

[Trace] mannheim/compass/802.11/online (v. 2008-04-11)

top

the initial version

@MISC{mannheim-compass-802.11-online-2008-04-11,
  author = {Thomas King and Stephan Kopf and Thomas Haenselmann and Christian Lubberger and Wolfgang Effelsberg},
  title = {{CRAWDAD} trace mannheim/compass/802.11/online (v. 2008-04-11)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/mannheim/compass/802.11/online},
  month = apr,  
  year = 2008
}
					

t="Timestamp"; id="MACofScanDevice"; pos="RealPosition"; degree="orientation"; "MACofResponse1"="SignalStrengthValue","Frequency","Mode"; ... "MACofResponseN"="SignalStrengthValue","Frequency","Mode"
t: timestamp in milliseconds since midnight, January 1, 1970 UTC
id: MAC address of the scanning device
pos: the physical coordinate of the scanning device
degree: orientation of the user carrying the scanning device in degrees
MAC: MAC address of a responding peer (e.g. an access point or a device in adhoc mode) 
with the corresponding values for signal strength in dBm, the channel frequency and 
its mode (access point = 3, device in adhoc mode = 1)

[Trace] mannheim/compass/fingerprint/offline (v. 2008-04-11)

top

the initial version

@MISC{mannheim-compass-fingerprint-offline-2008-04-11,
  author = {Thomas King and Stephan Kopf and Thomas Haenselmann and Christian Lubberger and Wolfgang Effelsberg},
  title = {{CRAWDAD} trace mannheim/compass/fingerprint/offline (v. 2008-04-11)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/mannheim/compass/fingerprint/offline},
  month = apr,  
  year = 2008
}
					

t="Timestamp"; id="MACofScanDevice"; pos="RealPosition"; degree="orientation"; "MACofResponse1"="SignalStrengthValue","Frequency","Mode"; ... "MACofResponseN"="SignalStrengthValue","Frequency","Mode"
t: timestamp in milliseconds since midnight, January 1, 1970 UTC
id: MAC address of the scanning device
pos: the physical coordinate of the scanning device
degree: orientation of the user carrying the scanning device in degrees
MAC: MAC address of a responding peer (e.g. an access point or a device in adhoc mode) 
with the corresponding values for signal strength in dBm, the channel frequency and 
its mode (access point = 3, device in adhoc mode = 1)

[Trace] mannheim/compass/fingerprint/online (v. 2008-04-11)

top

the initial version

@MISC{mannheim-compass-fingerprint-online-2008-04-11,
  author = {Thomas King and Stephan Kopf and Thomas Haenselmann and Christian Lubberger and Wolfgang Effelsberg},
  title = {{CRAWDAD} trace mannheim/compass/fingerprint/online (v. 2008-04-11)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/mannheim/compass/fingerprint/online},
  month = apr,  
  year = 2008
}
					

t="Timestamp"; id="MACofScanDevice"; pos="RealPosition"; degree="orientation"; "MACofResponse1"="SignalStrengthValue","Frequency","Mode"; ... "MACofResponseN"="SignalStrengthValue","Frequency","Mode"
t: timestamp in milliseconds since midnight, January 1, 1970 UTC
id: MAC address of the scanning device
pos: the physical coordinate of the scanning device
degree: orientation of the user carrying the scanning device in degrees
MAC: MAC address of a responding peer (e.g. an access point or a device in adhoc mode) 
with the corresponding values for signal strength in dBm, the channel frequency and 
its mode (access point = 3, device in adhoc mode = 1)

[Tool] tools/analyze/location/locana (v. 2007-09-14)

top

the initial version.

@MISC{tools-analyze-location-locana-2007-09-14,
  author = {Thomas King and Stephan Kopf and  and  and Thomas Haenselmann and Wolfgang Effelsberg},
  title = {{CRAWDAD} tool tools/analyze/location/locana (v. 2007-09-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/tools/analyze/location/locana},
  month = sep,  
  year = 2007
}
					

Locana is a research tool for 802.11-based positioning systems. Locana 
visualizes the results computed by Loctrace and Loceva.

This tool is released under the GNU General Public License.
Please respect our work and abide the license.

See "usage" for details.

See "usage" for details.

1. Overview

Locana visualizes the results computed by Loctrace and Loceva. This helps 
verifying that the data traced by Loctrace is complete and sound. Intermediate 
results of Loceva can also be visualized. This is a great means to verify 
that these algorithms are working as they are supposed to do.

A whole bunch of tools are grouped together in the Locana package. 
Locana contains many small tools that are supposed to perform special jobs. 
Most of these tools verify the output of Loctrace and Loceva, or list a certain 
object of a trace file. For instance, a tool called AccessPointLister prints out 
all the access points and how often they have been heard for a given trace file.

2. RadioMap

However, Locana contains also a powerful tool named RadioMap. RadioMap offers 
two modes of operation: loctrace and loceva. The former mode visualizes trace files 
generated by Loctrace. This feature is mainly used to visually investigate a fingerprint 
database. For each reference point and access point the number of readings, 
the average signal strength and its standard deviation can be displayed. 
The same can be displayed for online points as well. Furthermore, the grid dimension 
and starting point of the grid of reference points can be varied.

As previously mentioned, Loceva is able to optionally generate a file that logs 
intermediate results of positioning algorithms. Such a log file can be displayed 
in loceva mode of RadioMap. This helps to better understand how the selected positioning 
algorithm works, and to verify that the implementation works as it is supposed to.

After downloading and unpacking the jar archive the RadioMap tool can be run with the following command:

java -Xmx512M -cp batik-awt-util.jar:batik-bridge.jar:batik-css.jar:batik-dom.jar:batik-extension.jar:batik-ext.jar:batik-gui-util.jar:batik-gvt.jar:batik-parser.jar:batik-script.jar:batik-svg-dom.jar:batik-svggen.jar:batik-swing.jar:batik-transcoder.jar:batik-util.jar:batik-xml.jar:locana-0.5.1.jar:locutil1-0.5.1.jar:locutil2-0.5.2.jar:xerces_2_5_0.jar:xml-apis.jar org.pi4.locana.radiomap.RadioMap [-offline FILENAME] [-online FILENAME] [-maxgrid DOUBLE]

FILENAME can be a loctrace file (.trace) or a loceva file (.ptrace) to switch 
between loctrace and loceva mode, respectively. One of the parameters 
-offline and -online is required, both are valid. 
The -maxgrid parameter can be used optionally to set the maximum grid spacing. 
The default value is 5.0.

[Tool] tools/analyze/location/loceva (v. 2007-09-14)

top

the initial version.

@MISC{tools-analyze-location-loceva-2007-09-14,
  author = {Thomas King and Stephan Kopf and  and  and Thomas Haenselmann and Wolfgang Effelsberg},
  title = {{CRAWDAD} tool tools/analyze/location/loceva (v. 2007-09-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/tools/analyze/location/loceva},
  month = sep,  
  year = 2007
}
					

Loceva is an evaluation tool for 802.11-based positioning systems.
Loceva uses trace files generated by Loctrace to evaluate different 
kinds of positioning algorithms. A large number of state-of-the-art 
positioning algorithms are supported by Loceva. Loceva contains a lot of 
filters and generators to set up different scenarios and enable emulation.

This tool is released under the GNU General Public License.
Please respect our work and abide the license.

See "usage" for details.

See "usage" for details.

1. Overview

Trace files generated by Loctrace are used by Loceva to evaluate different 
kinds of positioning algorithms. A large number of state-of-the-art positioning 
algorithms are supported by Loceva. Loceva contains a lot of filters and 
generators to set up different scenarios and enable emulation.


2. Management

To make it easy to evaluate and compare algorithms currently under research, 
Loceva contains a management part that enables emulation in general and 
allows to easily select different kinds of scenarios. For this, Loceva utilizes 
trace files created with Loctrace to emulate a specific scenario. 
Such an emulated scenario can then be used for a comparison of different 
positioning algorithms. This makes sure that differences in the results are 
based on the positioning algorithms and not on the environment that changed 
over time in a way beneficially for one particular algorithm.

The creation and management of various scenarios is enabled by so-called filters. 
Filters create different scenarios by disabling or selecting different objects 
of a trace file. For instance, a MAC filter artificially switches off access 
points even if they have been part of the trace file. Another example is 
the position filter that disables different reference points of the fingerprint 
database based on their coordinates.


3. Algorithms

The positioning part contains various positioning algorithms to make it easy 
to compare newly envisioned algorithms with state-of-the-art ones. 
The following list shows the positioning algorithms that are part of Loceva. 
The list is grouped by the research projects that have invented them:

- RADAR: Nearest neighbor(s) in signal space, k nearest neighbors in signal space
- PlaceLab: K nearest neighbors p unknown, Ranking
- Rice: Histogram, Gaussian
- Horus: Horus

Although the main focus of Loceva is on positioning algorithms, it also contains 
a few continuous user tracking algorithms:

- RADAR: Viterbi-like algorithm
- Rice: Tracking
- Horus: Horus


4. Analysis

After selecting a certain scenario and positioning algorithm, Loceva computes 
the position error that would have occurred in this setting. The position error 
is defined as the Euclidean distance between the actual position of the user and 
the position estimate calculated by the algorithm. At the end of each emulation 
the average position error is printed, and a graph showing a cumulative distribution 
function of the position error (as shown in the figure below) is generated. 
Such a graph can be used to compare the position accuracy of different positioning 
algorithms by determining the median, 95th percentile and so on. Additionally, 
Loceva can be enabled to create a file that contains a log of intermediate results 
computed by the selected positioning algorithm. This log can be used with Locana 
to analyze the behavior of the positioning algorithm in question.

Loceva can be controlled by a so-called property file. In Java a property file 
contains key-value-pairs with a equals character as seperator. Most configurable 
values of Loceva are accessible by properties so that the same jar file can be 
used to emulate a wide range of different scenarios.  You can download an example 
property file that can be used to play around with Loceva.

After downloading and unpacking the jar archive Loceva can be run with the following command:

java -cp loceva-0.5.1.jar:locutil1-0.5.1.jar:locutil2-0.5.2.jar org.pi4.loceva.Loceva -offline FILENAME -online FILENAME [-prop PROPERTY]

FILENAME can be a trace file containing offline traces as well as online traces. 
Both parameters -offline and -online are required. The -prop parameter can be used 
optionally to define a property file.

[Tool] tools/collect/location/loclib (v. 2007-09-14)

top

the initial version.

@MISC{tools-collect-location-loclib-2007-09-14,
  author = {Thomas King and Stephan Kopf and  and  and Thomas Haenselmann and Wolfgang Effelsberg},
  title = {{CRAWDAD} tool tools/collect/location/loclib (v. 2007-09-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/tools/collect/location/loclib},
  month = sep,  
  year = 2007
}
					

Loclib is a research tool for 802.11-based positioning systems. Loclib is 
a connector between applications and sensor hardware. Its task is to collect 
data from the sensor hardware and pre-process it for further usage.

This tool is released under the GNU General Public License. 
Please respect our work and abide the license.

See "usage" for details.

See "usage" for details.

1. Overview

Loclib is a connector between applications and sensor hardware. Its task is 
to collect data from the sensor hardware and pre-process it for further usage. 

On the application side it offers two types of front-ends: The well-known 
Location API to access position estimates, and so-called handlers that provide 
access to sensor-specific data (e.g., signal strength values of neighboring access points). 
On the sensor hardware side, it communicates directly with hardware drivers 
to access sensor information that would otherwise be hidden. Loclib focuses 
not only on 802.11, it also contains a GPS part that is able to talk 
to NMEA-0183-enabled GPS devices as well as a digital compass for obtaining 
direction and inclination information.

2. Architecture

As already mentioned in the previous section, Loclib interconnects sensor hardware 
and applications by gathering sensor-specific data and converting it into location 
information if required. Loclib is organized in three layers:

- Sensor-specific data collection layer
- Data conversion layer
- Location application programming interface layer

The sensor-specific data collection layer gathers data from different sensor hardware. 
At the moment, Loclib is able to retrieve data from 802.11 wireless LAN network cards, 
NMEA-enabled GPS receivers, and digital compasses. To collect data, drivers can be 
accessed, or if it is feasible Loclib communicates directly with the sensor in question. 
For instance, digital compasses are directly queried, as well as NMEA-0183 devices. 
In case of 802.11 network cards, the signal strength of access points in communication 
range is retrieved from the driver. The data collected from the sensor-specific data 
collection layer is usually forwarded to the data conversion layer for further processing. 
However, the data can also be directly accessed by using so-called handlers. Handlers 
are pre-defined interfaces to allow applications such as Loctrace to access sensor-specific data.

The data conversion layer is responsible for converting data provided by the sensor-specific 
data collection layer into a position estimate that can be utilized by the Location API. 
To accomplish this, so far, GPS or 802.11-based positioning algorithms can be used. 
The data conversion layer is able to switch between 802.11-based positioning and 
GPS-based positioning if one of the sources fades out and the other is still operational. 
If both positioning services are available, GPS is preferred. Should both sources of 
position information be unable to deliver the required data an error code is returned 
instead of a valid position. 

The location application program interface layer implements the well-known and widely 
used Location API to deliver location estimates to applications.  This is a standardized 
way to hand over location information. Especially on mobile devices, this is a wide-spread 
approach to support location-based services.

3. Documentation & Tests

For software documentation purposes we mostly rely on Javadoc.
Additionally, we use JUnit tests and UML diagrams during our development process 
as documentation tools.

4. Location API

We have implemented the Location API as defined in JSR-179 to provide application 
developers a unified interface to location information. So far, our implementation 
is not completely compliant with the standard because we focused on the features 
we need. In the future, we will add missing parts.

1. NMEA-0183

A library compliant to the NMEA-0183 (Version 2.2) standard is part of Loclib. 
The NMEA library is specifically optimized for GPS receivers based on the SiRF 
II chipset. However, the library may work with other NMEA-0183 compliant devices 
as well.

Invoke Loclib with the following command to display the information provided 
by the GPS receiver:

java -cp loclib-0.7.5.jar:debug-disable-1.1.jar:hexdump-0.1.jar:libdbus-java-2.3.1.jar:unix-0.2.jar:j2meunit.jar:locutil1-0.5.1.jar org.pi4.loclib.nmea0183.test.SerialGpsTestToString

2. Wireless LAN

Our Wireless LAN implementation supports Active and Passive Scanning as well as 
Monitor-Sniffing. Monitor-Sniffing has been proposed by us and is discussed 
in the research paper "Wiretapping the Wireless Interface for 802.11-based 
Positioning Systems". To get Monitor-Sniffing to work, a Wireless LAN network 
card is required that supports monitor mode.

You can start a test program that actively scans for neighboring access points 
by invoking the following command:

java -Djava.library.path=./ -cp loclib-0.7.5.jar:debug-disable-1.1.jar:hexdump-0.1.jar:libdbus-java-2.3.1.jar:unix-0.2.jar:j2meunit.jar:locutil1-0.5.1.jar org.pi4.loclib.wirelesslan.test.ScanTest

Please adjust the java.library.path accordingly.
The test program works only under Linux or *BSD operation systems. It actively 
scans for access points using interface eth0 and prints detail information about 
the presence and signal strength quality of access points in communication range.

3. Bluetooth

A so-called proximity-based Bluetooth location system is part of Loclib. 
This kind of location systems have been proposed by many researchers and 
they work as follows: the position of a mobile device is derived from 
the access points in communication range by averaging their positions.

Our implementation requires the BlueZ Bluetooth stack and a Linux or *BSD operating system.

Replace the MAC addresses and coordinates stored in the bluetoothlocationdata.txt file 
with the values of the Bluetooth access points in your vicinity. 
Modify the loclib.properties, so that "provider=Bluetooth" is set. 
After that, invoke Loclib with the following command:

java -cp loclib-0.7.5.jar:debug-disable-1.1.jar:hexdump-0.1.jar:libdbus-java-2.3.1.jar:unix-0.2.jar:j2meunit.jar:locutil1-0.5.1.jar org.pi4.loclib.test.LocationProviderTest

4. Digital Compass

We have implemented the communication protocol for the F350-Compass-RD 
digital compass manufactured by Silicon Laboratories. The compass provides 
information about azimuth, current temperature and inclination of the compass 
on X- and Y-axis.

The declination angle must be set correctly. You can start a test program 
by invoking the following command:

java -cp loclib-0.7.5.jar:debug-disable-1.1.jar:hexdump-0.1.jar:libdbus-java-2.3.1.jar:unix-0.2.jar:j2meunit.jar:locutil1-0.5.1.jar org.pi4.loclib.f350compassfd.test.CompassTest

The test program continously requests and receives data from the compass 
and prints it to the screen.

As the compass package is not covered by the Location API, we encourage you 
to use the InputOutputHandler class as a front-ending if you want to use 
the compass package along with your own source code. The class that uses 
the InputOutputHandler is then supposed to implement the CompassListener 
interface in order to handle incoming messages. A detailed description is 
also available that discusses how to use the classes and interfaces.

5. Application: FDDD

FDDD (Fingerprint Database Distribution Demonstrator) is a demo application 
that illustrates algorithms for distributing fingerprints for 802.11-based 
positioning systems among mobile devices.

To invoke FDDD execute the following command:

java -cp loclib-0.7.5.jar:debug-disable-1.1.jar:hexdump-0.1.jar:libdbus-java-2.3.1.jar:unix-0.2.jar:j2meunit.jar:locutil1-0.5.1.jar -Djava.library.path=PATH_LOCLIB_JNI -Djava.security.policy=PATH_FDDD/rmi.policy -jar fddd-0.5.jar

The words in upper case are placeholders:

- PATH_LOCLIB_JNI defines the path to the Loclib jni directory
- PATH_FDDD defines the path where the FDDD code is stored

6. Application: SPBM

SPBM (Scalable Position-Based Multicast) is a multicast routing protocol 
for mobile ad-hoc networks. It uses the positions of the nodes in the network 
to forward data packets. Loclib can be used to provide the SPBM kernel module 
with coordinates derived from the current GPS position.

loclib-spbm requires four command line arguments:

Latitude of the origin of the SPBM coordinate system (in degrees)
Longitude of the origin of the SPBM coordinate system (in degrees)
Step width along the x axis of the SPBM coordinate system (in degrees)
Step width along the y axis of the SPBM coordinate system (in degrees)

For example, if you want to use SPBM in the city of Mannheim (Germany), 
you have to run loclib-spbm as follows:

java -jar loclib-spbm-0.1.jar 49.3 8.5 0.0001 0.0001

[Tool] tools/collect/location/loctrace (v. 2007-09-14)

top

the initial version.

@MISC{tools-collect-location-loctrace-2007-09-14,
  author = {Thomas King and Stephan Kopf and  and  and Thomas Haenselmann and Wolfgang Effelsberg},
  title = {{CRAWDAD} tool tools/collect/location/loctrace (v. 2007-09-14)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/tools/collect/location/loctrace},
  month = sep,  
  year = 2007
}
					

Loctrace is a research tool for 802.11-based positioning systems.
Loctrace gathers data offered by Loclib and stores it in a file.

This tool is released under the GNU General Public License.
Please respect our work and abide the license.

See "usage" for details.

See "usage" for details.

1. Overview

Loctrace mainly consists of one application. This application gathers 
data offered by Loclib and stores it in a file.

2. Tracer

Loctrace contains only one application: Tracer. Tracer is used to collect 
the data required to create fingerprint databases. To achieve this goal, 
Tracer is build on top of Loclib and directly retrieves sensor-specific data 
(e.g., the signal strength of access points within communication range in 
an 802.11-based wireless network). It contains a graphical user interface 
(GUI) to make the configuration process easy to handle (e.g., select 
a scanning mode and the scanning device). 

Various parameters such as the number of scans or the delay between 
two consecutive scans are also configurable through the GUI. If the trace 
process is started, a histogram pops up in the bottom part of Tracer showing 
the access points within communication range and their corresponding signal 
strength distributions.

The data collected from Loclib is stored in a human-readable trace file 
and contains lines that adhere to the following format:

t="Timestamp";pos="RealPosition",id="MACofScanDevice";degree="orientation";"MACofResponse1"="SignalStrengthValue","Frequency","Mode","Noise";...;"MACofResponseN"="SignalStrengthValue","Frequency","Mode","Noise"

- t: timestamp in milliseconds since midnight, January 1, 1970 UTC
- pos: the physical coordinate of the scanning network device
- id: MAC address of the network device used for scanning
- degree: direction of the user carrying the scanning device in degrees 
(only set if a digital compass is available)
- MAC: MAC address of a responding peer (e.g. an access point or a device 
in adhoc mode) with the corresponding values for signal strength in dBm, 
the channel frequency, its mode (access point = 3, device in adhoc mode = 1) 
and noise level in dBm.

Trace files generated by Tracer are a major building block for our overall 
research process. These files can be used by Loceva to evaluate and emulate 
different positioning algorithms and scenarios. Furthermore, the traces 
can be displayed for visual inspection by tools of the Locana package. 
Finally, these traces can be used as an offline fingerprint database during 
normal operation of an 802.11-based positioning system.

To start the tracer just invoke

java -Djava.library.path=PATH_LOCLIB_JNI -cp loctrace-0.5.jar:locutil1-0.5.1.jar:loclib-0.7.5.jar:debug-disable-1.1.jar:hexdump-0.1.jar:libdbus-java-2.3.1.jar:unix-0.2.jar org.pi4.loctrace.wirelesslan.Tracer

Please replace the placeholder PATH_LOCLIB_JNI with the path to the loclib 
native library according to your installation.

[Author] Thomas King

top

[Author] Stephan Kopf

top

[Author] Thomas Haenselmann

top

[Author] Christian Lubberger

top

[Author] Wolfgang Effelsberg

top

[Paper] king-802-11

top

Indoor positioning systems based on 802.11 and fingerprints offer reasonably 
low position errors. We study the deployment, calibration, and measurement 
factors for position errors by systematically investigating (1) the number of 
access points, (2) the number of samples in the training phase, (3) the number 
of samples in the position determination phase, and (4) the setup of the grid 
of reference points. Further, we bring out the best of the positioning system 
by selecting advantageous values for these parameters. For our study, we 
utilize a test environment with a size of about 312 square meters that is 
covered with 612 reference points arranged in an equally spaced grid.

[Paper] king-compass

top

Positioning systems are one of the key elements required by location-based 
services. This paper presents the design, implementation and analysis of a 
positioning system called COMPASS which is based on 802.11-compliant network 
infrastructure and digital compasses. On the mobile device, COMPASS samples the 
signal strength values of different access points in its communication range 
and utilizes the orientation of the user to preselect a subset of the training 
data. The remaining training data is used by a probabilistic positioning 
algorithm to determine the position of the user. While prior systems show 
limited accuracy due to blocking effects caused by the human body, we apply 
digital compasses to detect the orientations of the users so that we can deal 
with these blocking effects. After a short period of training our COMPASS 
system achieves an average error distance of less than 1.65 meters in our 
experimental environment of 312 square meters.

[Paper] king-fingerprint

top

Fingerprinting is a popular technology for 802.11-based positioning systems: 
Radio characteristics from different access points are measured at various 
positions and stored in a database. The database is copied to all mobile 
devices, and in case that a position estimate is needed, the device compares 
its currently measured radio characteristics with all the database entries. In 
this paper, we present two on-demand fingerprint selection algorithms to avoid 
the cumbersome and time-consuming approach of manually copying all 
fingerprints. Our algorithms only request those fingerprints from the database 
that are currently required to compute a position. The two algorithms differ in 
the way they shape the region for which fingerprints are requested. On-demand 
selection also allows storage-restricted mobile devices to utilize the 
positioning system. We carefully evaluate our algorithms in a real-world 
experiment. The results show that our algorithms do not harm the position 
accuracy of the positioning system. In addition, we analyze the space 
requirements of our algorithms and show that the typical constraints of mobile 
devices are met.