Location Aware Programming Framework

Location Aware Programming Framework
CSE237B Course Project, Fall 2004 by Apurva Sharma
Introduction
Time as a variable has been integrated into programming for quite some time. Most
languages provide support for Time either as a language feature or through run-time
libraries. The same is not true for Location. Anyone wishing to develop an application
that takes into account the current position of the device on which it is running is required
to develop the necessary framework himself. This hasn’t traditionally been that much of
an issue because mobile devices weren’t that common, and location sensors like GPS
weren’t available on mobile devices – thus making accurate location discover hard. This
situation is to change soon. There are an increasing number of mobile devices shipping
across the world with build in GPS receivers and it is also easy to attach a small external
GPS receiver which is readily available, through USB/Serial/Bluetooth interface. Being
interested in developing an application for mobile devices using Bluetooth interface I was
motivated into this project to develop a generic framework that provides support for
using Location as a variable in any application without being concerned about what
interface is used to obtain the Location data, how to program that interface etc.
Motivating applications
Navigation system is probably the most common example that revolves around Location
and it holds good for mobile devices too. Another application is associating the current
Location information with snapshots taken with a mobile device’s built-in digital camera
for integration into Weblogs. Some other useful applications are Location based device
customization (e.g. switch to silent mode in meeting rooms/hospitals/movie theatres);
Location based alerts; Location based communities (e.g. I want to chat with all
Superman fans in my current Location) etc.
Project Goals
The framework that we develop should have the following characteristics:
• Ability to connect to a GPS device and read GPS data from it. Although we are
implementing for a Bluetooth GPS interface, the framework should be extensible
such that it can be used with any other interface – so if in the future we need to
run the framework on a device with built-in GPS support we don’t need to modify
the framework or our application extensively.
• Ability to associate user-friendly names (e.g. “House”, “Hospital”, “Office” etc.)
to Location objects and to access Location objects by their assigned names as well
as geographical coordinates.
• Provide operations on Location objects such as computing distance, testing
whether two Location definitions overlap etc.
•
•
Ability to associate application defined listener to Location events.
Allow the application to control the rate at which location is updated. This might
be important for application that wishes to conserve power for example.
Related Work
Upon researching for similar work I found similar packages for Java mobile platform
(J2ME). JSR82 specifies an extension to J2ME that standardizes how J2ME applications
can communicate using Bluetooth interface and JSR179 defines a framework for
Location aware programming in Java. If we have both of these then our work is done and
I don’t need to do anything for this project. The challenge here is both JSR82 and JSR179
are extensions and not part of standard J2ME and thus not supported for most mobile
devices. Since I had already committed myself to this project I decided to implement a
framework for once such device – Microsoft Windows Smartphone 2003 powered mobile
phone. Even though my device had a Bluetooth interface and J2ME support it did not
support J2ME extensions for Location or Bluetooth. Even the .NET Compact framework
that comes with the phone doesn’t have API to access the Bluetooth interface. The final
option left was to program natively using embedded Visual C++ and develop my own
framework to access the Bluetooth interface, get GPS data and provide for Location
aware programming.
Hardware and Software Summary
•
•
•
I tested my software using a Microsoft Windows Smartphone 2003 powered
mobile phone and a Belkin F82951 Bluetooth GPS Receiver.
Programming was done in Microsoft embedded Visual C++ 4.0 sp4
The application reads GPS data in National Marine Electronics Association’s
NMEA-0183 interface standard that is commonly supported by GPS devices.
GPS NMEA Sentences
The National Marine Electronics Association (NMEA) has developed a specification that
defines the interface between various pieces of marine electronic equipment. The
standard permits marine electronics to send information to computers and to other marine
equipment. GPS receiver communication is defined within this specification. Most
computer programs that provide real time position information understand and expect
data to be in NMEA format. This data includes the complete PVT (position, velocity,
time) solution computed by the GPS receiver. The idea of NMEA is to send a line of data
called a sentence that is totally self contained and independent from other sentences.
There are standard sentences for each device category and there is also the ability to
define proprietary sentences for use by the individual company. The most important
NMEA sentences include the GGA which provides the current Fix data, the RMC which
provides the minimum GPS sentences information, and the GSA which provides the
Satellite status data. For the framework I only use RMC and GGA sentences which are
discussed below:
$GPRMC Sentence (Position and time)
Example (signal not acquired):
$GPRMC,235947.000,V,0000.0000,N,00000.0000,E,,,041299,,*1D
Example (signal acquired):
$GPRMC,092204.999,A,4250.5589,S,14718.5084,E,0.00,89.68,211200,,*25
Field
Sentence ID
Example
$GPRMC
Comments
UTC Time
092204.999 hhmmss.sss
Status
A
Latitude
4250.5589 ddmm.mmmm
N/S Indicator
S
Longitude
14718.5084 dddmm.mmmm
E/W Indicator
E
A = Valid, V = Invalid
N = North, S = South
E = East, W = West
Speed over ground 0.00
Knots
Course over ground 0.00
Degrees
UTC Date
DDMMYY
211200
Magnetic variation
Degrees
Magnetic variation
E = East, W = West
Checksum
*25
Terminator
CR/LF
$GPGGA Sentence (Fix data)
Example (signal not acquired):
$GPGGA,235947.000,0000.0000,N,00000.0000,E,0,00,0.0,0.0,M,,,,0000*00
Example (signal acquired):
$GPGGA,092204.999,4250.5589,S,14718.5084,E,1,04,24.4,19.7,M,,,,0000*1F
Field
Sentence ID
Example
$GPGGA
Comments
UTC Time
092204.999 hhmmss.sss
Latitude
4250.5589 ddmm.mmmm
N/S Indicator
S
Longitude
14718.5084 dddmm.mmmm
E/W Indicator
E
E = East, W = West
Position Fix
1
0 = Invalid, 1 = Valid SPS, 2 = Valid DGPS, 3 = Valid
PPS
Satellites Used
04
Satellites being used (0-12)
N = North, S = South
HDOP
Altitude
24.4
19.7
Horizontal dilution of precision
Altitude in meters according to WGS-84 ellipsoid
Altitude Units
M
M = Meters
Geoid
Separation
Geoid separation in meters according to WGS-84 ellipsoid
Separation Units
M = Meters
DGPS Age
Age of DGPS data in seconds
DGPS Station
ID
0000
Checksum
*1F
Terminator
CR/LF
Framework Design
Figure 1
Figure1 shows a typical application using the framework. The application is required to
provide a concrete implementation of the interface LocationListener which is drawn as
“MyLocationListener” above. The framework interface “IOConnector” describes a
generic connector and the concrete class “BTConnector” included with the framework
implements the facilities of connecting and communicating with a Bluetooth device.
NMEAParser is a library used by the framework to parse NMEA sentences read from the
GPS receiver. The class Location in the framework stores all Location specific
information – coordinates, name, type (placeholder for pointer application specific data
structure) etc. and its only purpose is as a aggregating the Location specific data. All
operations over the Location objects are performed through the LocationProvider class
which is the center of the framework. During the course of the design I made the
following design decisions to make the framework generic and useful across a wide range
of applications:
•
•
•
•
Use of interfaces IOConnector and LocationListener to abstract out the
connection and Location Event Listener parts from the framework which are
either dependent on the connection type or are specific to the application.
Since the application might have its own requirements on when and how
frequently should the location be updated (e.g. to conserve power), assuming a
fixed interval of update, or even assuming a periodic update might have been
limiting. So LocationProvider provides a single function “RefreshLocation” that
the application is expected to call when an update is desired.
Defining what constitutes a Location was the most challenging decision. I looked
at the kind of scenarios where I would be using the framework. I might want to
define a room as a location, or a building or a campus. From this I concluded that
maybe cuboids would best represent a Location (region). But then the problem
was what default size to choose. Should the application assume a default size and
let the user correct whenever it makes a bad guess. But then the Location object
would keep changing which might not be desirable. Also the overhead required
for this generic model both in terms of computational complexity, storage
required as well as user interaction was too high. I thus formed a simpler model. I
decided to represent a location as cylinder whose base is specified by a center
(latitude, longitude, altitude) and radius (horizontal tolerance) and height (vertical
tolerance). I also decided to get user input for all parameters at Location creation,
thus avoiding runtime complexity. This model also simplifies the implementation
of operations for Location objects.
Overlapping locations: It is possible for a user to define two locations that share a
region of space. It could be the user’s intention or this could be the result of
overestimating one of the tolerance parameters. I decided to permit the creation of
such objects while providing a function to determine if two location objects
overlap. If the application decides to disallow such objects all it need to do is use
the check overlap function at construction time.
Description of classes constituting the framework:
• Location: Provides storage for location specific information (name, coordinates,
horizontal tolerance, vertical tolerance etc.). Also permits a “type” parameter
which can be used to store application-specific information.
• LocationProvider: Provides all kinds of operations for Location, maintains the
current location information and is responsible for invoking the listener callback
functions when location events happen.
• IOConnector: Interface for a generic connector. Has a method for Read/Write,
checking the connection status.
• BTConnector: An implementation of IOConnector interface for Bluetooth.
Provides extra methods for device discovery.
• LocationListener: Interface for a generic listener. Has event callback for
LocationEntry, LocationExit, and LocationUpdate.
• NMEAParser: Provides parsing for GPS NMEA sentences and is used by
LocationProvider.
Sample Application
This being my first experience working the Smartphone platform I wanted to choose an
application that was simple enough to implement within the time frame of the project, yet
would demonstrate how to use the framework and its features.
The application that I developed allows creating Location objects, and provides support
for setting up warnings (simulated by vibrating the device for 0.5 sec for each warning)
for both location entry and location exit events. It also provides a display with the current
location name, and positioning and time information obtained from GPRMC sentence.
The implementation is divided into a main program (ProjectL.cpp) that performs all
initialization, implements the UI and invokes the LocationProvider to update the location
information through a Timer and MyLocationProvider.cpp which provides a
LocationListener specific to this application – making the phone vibrate in response to
entry/exit events and updating an edit control in response to update event with current
location data. The user is allowed to choose a GPS device from a list of discovered
Bluetooth devices and specify a time interval for polling the GPS device. I wasn’t able to
obtain valid values for Altitude during my testing (probably something to do with what it
receives from the satellite and not a bug since the GGA spec says that altitude might be
wrong) and hence this application ignores the vertical tolerance fields. My GPS device
always returns incorrect value for the Date field, but I have verified that Time, Latitude
and Longitude fields are correct. The following images demonstrate the application
interface (going from left to right and top to bottom):
1. Initial Display
2. First Step Configure Connection
3. Select Bluetooth GPS device and
polling interval.
5. Creating a new Location
4. Displays the current location
information. If the Location is not
assigned a name, “Unknown” is
displayed in place of name.
6. The New Location Dialog
7. Example New Location entry
8. Updated display with the new location
Windows Smartphone 2003 platform
The following software was required for development:
• Microsoft embedded Visual C++ 4.0 sp4
• Microsoft Windows Smartphone 2003 SDK
• Microsoft ActiveSync 3.7.1
All software is available for free download from Microsoft. The sample code for
Bluetooth was available only through Windows CE .NET 4.2 evaluation kit. This
platform also has issues with deployment. If the vendor wishes he can configure the
device to only allow deployment of signed applications. For that one needs to purchase a
license for signing application and submit his application to get them signed. Fortunately
the device I tested with permitted installing unsigned applications. My application
produces only one executable so deployment is straightforward, but when several files
are part of the application the deployment can be done through a CAB file. Unfortunately
the default settings in embedded Visual C++ are for Pocket PC platform CAB file and the
process for Smartphone platform is manual. A reference is included for this.
Conclusions
I have successfully implemented a Location aware programming framework for the target
platform and demonstrated its use using a sample application – location based reminder
service. The framework is generic enough to allow extension for different interfaces and
support applications with diverse requirements.
Future Work
One feature that I see missing from my current implementation is the ability to save
created locations to permanent store and load it at subsequent application invocations.
This could further be extended to allow synchronization of locations with another device
as is available for Contacts, Notes and Mails already. The other direction I see is building
a more complex and useful application using the framework.
Reference:
•
•
•
•
•
•
•
•
http://www.commlinx.com.au/NMEA_sentences.htm for a description of
common NMEA sentences
http://www.visualgps.net for a free C++ GPS NMEA parser used by my
implementation.
http://msdn.microsoft.com/mobility Microsoft website for reference information
about developing for Microsoft OS powered mobile devices.
http://www.microsoft.com/windowsmobile/ Software and downloads for
windows mobile
http://www.psiloc.com/?id=169 An application for Nokia Smartphone that uses
network cell id to provide location aware services.
http://www.akuaku.org/archives/2004/10/bluetooth_gps_m.shtml An article about
using GPS Bluetooth to get Location data on a mobile device to link with photos
to store on a Weblog.
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnsmtphn2k3/html/sp_2003_app_deploy_demyst.asp Smartphone application
deployment guide.
Microsoft Windows Smartphone 2003 SDK.