Finland Location Aware Mobile Services The Techniques For The Application Developer 1/31 Timo Karppinen 2.2. 2010

HAMK
University of Applied Sciences

Finland
Location Aware Mobile Services
The techniques for the application developer 1/31
Timo Karppinen 2.2. 2010
2. The techniques for the application developer
2.1 Development tasks
First of all we have to make a difference between the techniques used by different
persons in development process of location aware services and products. There are
persons engaged in development of:
• Hardware products
• Software or firmware for the location aware hardware products
• Software for communication purposes in distributed location aware systems
• Techniques used in developing and programming location based services. These
techniques included the location API’s for different operating systems (
Windows, Symbian, etc.), hardware platforms ( PC, Mobile phone S60 –platform
) and programming languages ( Java, C#, C++, etc ).
• Development of Location Based Services as interactive web-applications and as
database applications ( Javascript, ASP.NET, PHP, etc )
• Developing the location based services from the user point of view or as business.
The main tasks for the hardware and software in the products for the location based
services are:
• Determine the coordinate position of the receiver
• Read and interpret the coordinate information into the software in different
platforms like mobile phones, PDA’s, laptop PCs
• Make coordinate information available for other software products locally in the
platform or available for other mobile devices or for the servers in the network
• Provide location aware functionality in the software
• Provide user interfaces for different user groups
2.2 The techniques for defining the position of the mobile device
The position of the mobile device can be achieved with a number of methods
Satellite positioning: GPS, GALILEO, GLONAS
GPS:
Global positioning System has been developed by Department of Defence, USA. It has
been in full operation since 1995. It is the only fully operational satellite based navigation
system at the moment (2007).
Timo Karppinen timo.karppinen@hamk.fi

• Information for the civilian use is provided by the USA Coast Guard Navigation
Center http://www.navcen.uscg.gov
• Based on the GPS Standard Positioning Service the civilian users are permitted to
determine their three dimensional position, velocity ( = speed and direction ) and
time.
• The accuracy is 13 meters horizontally and 22 meters vertically ( 95 % of time in
95 % of earth surface ).
• Fix interval can be 1 – 20 times per second. Although it takes as long as 12,5
minutes for the receiver to receive the complete navigation message. The
complete message is needed in “cold start” of the receiver.
• The determination of the position is based on complicated signal processing in the
receiver. The amplification of the satellite signals is based on mathematical
methods. Signals with signal level far below the background noise can be
received.
• The accuracy is affected by the signals passing through the charged particles in
the Ionosphere ( altitude 50 km – 200 km ) and by the weather conditions in the
Troposphere ( altitude 0 -50 km ). The position determination for two receivers in
the same area is affected by the same conditions in the Ionosphere and
Troposphere. We can assume that both receivers will determine the location with
the same error. This means their relative position to each other is far more
accurate than their absolute coordinate position.
• The velocity of the moving receiver can be determined with a good accuracy. This
is based on the fact that the disturbances in Ionosphere and in Troposphere will
remain constant for a period of time.
• The accuracy is affected by the satellite constellation as well. The accuracy of the
position calculation is better if the satellites seen by the receiver are distributed
over the whole sky. The error gets bigger if all satellites are at the same segment
of the sky.
• Applications for GPS:
o Positioning; where I am
o Navigation; finding the route from point A to point B
o Tracking; monitoring the movement of people, vehicles and other things
o Mapping; creating maps
o Geographic Information Systems; Thematic information connected to
coordinate position
o Timing; timing of signaling in telecommunication systems, clock
reference for scientific applications
• GPS can not necessarily be used as the only source of position information in
safety critical applications ( aircraft landing on an airport, railway traffic control
etc.). GPS system has no integrity. It does not provide reference information about
the accuracy and availability of the service.
• The performance of the GPS positioning can be improved by using WAAS Wide
area Augmentation system ( USA wide ), EGNOS European wide satellite based
augmentation system for GPS, DGPS Differential GPS. WAAS and EGNOS
include integrity information and accuracy improvement. DGPS improves the
accuracy only.
timo.karppinen@hamk.fi
• The size of the receiver is nowadays about 20 mm x 20 mm x 3 mm or smaller.

The power consumption is about 0,1 W ( in the year 2007 ). The mean power
consumption can be far less if the fix is taken not every second but for example
once in half hour. GPS receivers can be found integrated in devices like mobile
phones ( Benefon, Motorola, Nokia, etc.) in functional watches ( Suunto, etc ) and
in sports accessories ( Suunto, Garmin, etc ).
GALILEO:
• GALILEO is a joint initiative by the European Union and the European Space
Agency. EU is responsible for setting the objectives for the GALILEO. European
Space Agency is responsible for technical definition, development and the
validation of GALILEO.
• After the deployment of the 4 initial satellites of the in-orbit validation phase in
2008, the GPS/EGNOS/Galileo combined services will be progressively provided.
News on the operational status is provided on the official EU European
Commission Departmen of Transport web page
http://ec.europa.eu/transport/galileo/index_en.htm .
• GALILEO will provide five different services:
o Open Service (OS): positioning and timing, free of charge
o Safety of Life (SoL): functions found in OS and in addition warnings to
the user when the system fails to meet certain margins of accuracy ( =
integrity)
o Public Regulated Service (PRS): for specific government authorized users
with encrypted codes
o Commercial Service (CS): improved accuracy. Additional signals are
encrypted and will be opened in the user device using access protection
keys.
o Search and Rescue Service: Galileo satellites will be able to pick up
signals from emergency beacons carried on ships, planes or persons and
ultimately send these back to national rescue centers. ( functionality
comparable to the COSPAS-SARSAT system) At least one GALILEO
satellite will be in view of any point on Earth. Near real time distress alert
is possible anywhere on Earth. GALILEO will be able to send feedback
signal back to the safety beacon. (This function is not available in other
global systems.)
• Accuracy objectives in definition phase were for Open Service 10 meters
horizontal and for the restricted services 4 meters horizontal. Availability in Open
Service is to be 70 % and in safety related services 99%. The vertical accuracy is
within range 2 to 5 meters.
• The system is capable to send uplink data from ground stations to satellites and
downlink data from satellites to receivers. The downlink data can be used for
safety applications ( Integrity Messages, Search and Rescue co-ordination
messages, storm and flood warnings, temporary map changes such as traffic jams,
map updates, etc. )
• Positioning is based on similar calculations as in GPS. Although there are more

signals and transmission bands and the codes are longer. The aim is to be able to
locate receivers in city centers and even inside buildings. The problem in these
cases is multipath propagation. To overcome the problems caused by multipath
propagation the mathematical algorithms are more complicated and the receivers
need even more calculation power than GPS-receivers.
• The chip sets for the GALILEO –receivers were already in design and
preproduction in 2007 and were expected to be available in commercial market in
2008. Test and evaluation products exist at the beginning of 2009.
GLONAS
Global’naya Navigatsionnaya Sputnikovaya Sistema = Global Navigation Satellite
System consists of three segments like the other satellite navigation systems: The
Ground-based Control Complex = ground segment, Constellation = space segment and
user receivers = user segment. The first satellites were launched in 1982. The Russian
Federation Government Resolution offered GLONAS service for civilian use in 1995.
There have been problems with the availability of the service due the low number of
satellites. Commercial interest in developing GLONASS receivers has declined since
1990’s.
There are plans to enchange the performance and availability of the service.
Navigation based on cellular network cell-ID and propagation delays in cellular

mobile phone networks.
For finding a location there are several techniques based on the mobile phone
infrastructure. Some of these techniques are based on the properties of the standard 2G or
3G networks. Some techniques need special equipment and software in base stations,
base station controllers or somewhere in the network.
The information on the location of the terminal equipment ( mobile phone ) is in a form
or other always available in the network. The working principle of the cellular network is
based on the fact that the location of the terminal equipment is known.
The method using the CELL-ID for calculating the location is in principle available in
every mobile phone network.
• Many network operators offer this service for authorities and for public use.
• The accuracy depends on the cell size. In best case the location of the terminal
equipment can be given with an accuracy of 50 m, in worst case with an accuracy
of 35 km.
AF-LT , Advanced Forward Link Triangulation, is one of the methods using the
propagation delays between base stations and terminal equipment.
• It can be used in CDMA networks
• An accuracy of 50 m to 200 m can be achieved
Enhanced Observed Time Difference, EOTD, is the method in European networks.

• EOTD is based in determining the location by observing the propagation delays
between terminal equipment and base stations.
These methods based on time differences may sound like simple and reliable methods.
The problem in environments like city centres is the multipath propagation. The same
signal is received reflected from various objects. When the terminal equipment is moving
the reflections are changing all the time as well. The accuracies may be expected to be in
a scale of 50 m to 200 m.
OTDOA-IPDL, Observed Time Difference Of Arrival – Idle Period Down Link, is

defined to be the locating method in the UMTS, Universal Mobile Telecommunications
System, networks.
• The idle period of one base station helps the terminal equipment to observe the
time difference from weaker base stations.
Network operators typically do not publish any detailed information on the technical
solutions used in their network. There is no data available on the performance of the
network based positioning methods in different kinds of city areas or rural surroundings.
It is also important to remember that 3rd generation mobile phone networks are typically
available in densely populated areas only. 2nd generation network are widely available but
it is as well not available everywhere.
Navigation based on Wi-Fi, WLAN, networks IP –addresses.
The IP addresses and geographic locations of the public WLAN networks can be stored
in a database. The information on the data base can be made available for public.
With a simple application software in the handheld device it is easy to read the IP
addresses of the visible WLAN networks and compare the address information with the
addresses in the database.
On the other hand it is easy for the web based service to provide you localized
information based on your IP address.
The latest news on this subject you can find simply by typing “IP address location” in a
search engine in your favourite web browser.
2.3 Navigation chip sets and navigation devices
The navigation data is a numeric value of latitude ( north / south –coordinate ) and
longitude ( east / west ) coordinate and altitude ( elevation compared to sea level).
Additional information like direction of movement and velocity can be given, too.
The coordinates are normally presented in degrees, minutes and thousands of minutes:
60° 10,230’ N 24° 56,650’ E. This is a coordinate position just outside main railway
station in Helsinki. If the same position is given in degrees, minutes and second it would
be 60° 10’14’’ N 24° 56’39’’ E.
There are differences between the coordinate projections used traditionally for making
maps. The GPS –receiver is initially producing coordinate values in WGS-84 projection.
The WGS-84 is as well common in latest printed maps.
GPS –receiver chips are delivering the coordinate values and other information normally
in two modes; either in binary data or as 8-bit ASCII character strings. Typically an
application program is reading the ASCII strings.
fig. 1. GPS receiver chip / www.trible.com
In the market there is a number of positioning chip set manufacturers. The consumer
market and professional navigation receiver manufacturers use the chip sets in their
product.
The navigation receiver can be a handheld device.
Figure 2. Handheld GPS –receiver for outdoor activities/ www.magellangps.com
GPS receiver can be integrated into car radios for providing routing, location based
information, traffic announcements etc.
Figure 3. Routing navigator integrated in car audio /data sheet ms 4400 www.vdodayton com
The GPS receiver can be an external device. In this case it is sending the ASCII strings
over serial communication to the mobile device. The serial interface is typically either a
traditional point to point serial line or wireless communication:
• A GPS receiver connected to a standard RS 232 serial port sends the position
information as standard NMEA 0183 messages.
Fig 4. GPS receiver and a serial port cable.
• Sports watch communicates with a GPS receiver with radio frequency point to
point communication link
Fig 5 The GPS pod communicates with the wrist top computer over a point to point radio
frequency link. / image www.suunto.com
• Bluetooth enabled mobile phones communicate with GPS receiver over a virtual
serial port provided by Bluetooth communication profile. The virtual serial port
receives standard NMEA 0183 messages.
The content of the NMEA 0183 messages are explained in appendix A.
Integrated GPS receiver can be found in mobile phones, wrist top computers, sport
watches and in other devices which benefit from accurate position, velocity or time
information.
2.4 Getting navigation data into a pc-computer
Traditionally a GPS receiver has been connected to the standard RS-232 serial port in a
personal computer. The standard format for receiving data into application program from
the serial port has been ASCII-symbol strings. In a string each character is a 8-bit symbol.
The format of the GPS data has been standardized years ago by NMEA. The format is
referred for example as NMEA-183 2.0. There are some variations of the format. Some
examples of the sentences are given below.
$GPGGA, 063901, 6010.78,N, 02415.60,E, 0/1/2, 08, 02.7, 0044,M, -049,M, X,X,
XXXX*47
063901: UTC time of position

6010.78,N: latitude, N/S
02415.60,E: longitude, E/W
1/2/3: GPS quality indicator

08: number of satellites in use
02.7: horizontal dilution of precision
0044,M: antenna altitude above/below sea level
-049,M: geoidal separation
X,X: age of differential correction, DGPS, data
XXXX: differential reference station ID
$GPVTG, 134,T, 137,M, 004.1,N, 007.6,K *66
134,T: course degrees true

137,M: course degrees magnetic
004,1,N: speed, knots (nautic miles/hour = 1.852 km/h)
007,6;K: speed, km/h
Modern pc’s and especially laptop computers do not any more have a serial port. In this
case the GPS receiver can be connected with an USB cable or over a Bluetooth link. But
in both of these cases the navigation program will see the GPS receiver as a device
connected to serial port and delivering the same NMEA 183 2.0 data over a serial port. In
defining the Bluetooth settings we set the GPS device to be visible as a virtual serial port.
With GPS receiver connected to USB port it is the same procedure.
There are plenty of possibilities when selecting the software development tools for the
normal personal computer. In this case we take two examples where the program is done
in C# in the Microsoft Visual Studio 2005. To run the programs the .NET framework 2.0
must be installed on the computer. .NET framework 1.0 does not support the serial port.
The same software projects seem to compile with no problems in Microsoft Visual Studio
2008 as well. The current version of the .NET environment is .NET 3.5.
.NET framework provides a convenient method for connecting to the serial port. The
virtual serial ports for the USB or Bluetooth devices are between ports COM 5 and COM
15. The programmer does not need to know any special buffer addresses or any
complicated technical details. The only technical information needed is the baud rate of
the GPS device and the data format. The baud rate is in older devices 9600 bits/second
and in the latest for example 38400 bits/second.
The first example was published in autumn 2005 in the web pages for software
developers using Microsoft tools, http://msdn.microsoft.com/coding4fun/ The second
example was published in spring 2006 in the web pages for Finnish software developers
using Microsoft tools, www.codezone.fi. The author for the first example is Scott
Hanselmann and the author for the second example is Jarmo Hämäläinen.
Reading the serial port is done with the class “serialPort” found in the namespace
“System.IO.Ports”.
private void connectButton_Click(object sender, System.EventArgs e)

{
connectButton.Enabled = false;
disconnectButton.Enabled = true;
COMlistBox.Enabled = false;
port.PortName = COMlistBox.SelectedItem as string;
port.Parity = Parity.None;
port.BaudRate = 4800;
port.StopBits = StopBits.One;
port.DataBits = 8;
port.Open();
timer1.Enabled = true;
}
Private void disconnectButton_Click(object sender, System.EventArgs e)

{
disconnectButton.Enabled = false;
connectButton.Enabled = true;
COMlistBox.Enabled = true;
timer1.Enabled=false;
try
{
port.Close();
}
catch(Exception ex)
{
System.Diagnostics.Trace.WriteLine("Trouble closing the
SerialPort! " + ex.ToString());
}
}
Example 1.1. Defining the serial port and opening and closing it. The code is part of the
code for the main user interface form. / Scott Hanselmann
private void timer1_Tick(object sender, System.EventArgs e)

{
ReadData();
}
private void ReadData()

{
byte[] bData = new byte[256];
try
{
port.Read(bData, 0, 256);
protocol.ParseBuffer(bData);
}
catch(Exception e)
{
System.Diagnostics.Debug.WriteLine(e.ToString());
//swallow it.
}
DisplayNMEARawData(bData);
DisplayGeneralInfo();
DisplaySatellites();
}
Example 1.2. Reading the serial port. Reading is initiated by a timer. The ParseBuffer
class is used for arranging data into GPS messages and finding information out of the
messages. The data will be displayed with three different kinds of display methods. /
program code by Scott Hanselmann
using System;
using System.Collections.Generic;
using System.Text;
using System.IO.Ports;
using System.Collections;
using System.Threading;
namespace PathFinder
{
/// <summary>
/// Com portin luku. Portin data luetaan jonoon, josta sitä voidaan
/// tarvittaessa lukea. Rivejä voidaan puskuroida.
/// </summary>
class ComPort
{
/// <summary>
/// Jonot datalle
/// </summary>
private Queue nmeaQueue = new Queue();
private Queue nmeaSyncQueue = null;
/// <summary>
/// Ollaanko lukutilassa.
/// </summary>
private bool isReading = false;
/// <summary>
/// Viimeisin virhe.
/// </summary>
private String error = "";
/// <summary>
/// Portin luonti
/// </summary>
private SerialPort serialPort = new SerialPort();
/// <summary>
/// Komennot joita seurataan # merkeillä erotettuina.
/// Jos tyhjä, niin seurataan kaikkia.
/// </summary>
private String commands = "";
/// <summary>
/// Luonti
/// </summary>
public ComPort()
{
}
/// <summary>
/// Avataan portti ja luodaan jono datalle.
/// </summary>
/// <param name="port"></param>
/// <param name="speed"></param>
public void Open(String port, int speed, String commands)
{
try
{
// Otetaan talteen seurattavat komennot
this.commands = commands;
// Luodaan synkronoitu jono luettuja paikkatietoja varten.
// Tietoja voidaan lukea toisesta threadista synkronoidusti.
this.nmeaSyncQueue = Queue.Synchronized(nmeaQueue);
// Portin asetus
this.serialPort.PortName = port;
// Nopeuden asetus
this.serialPort.BaudRate = speed;
// Avataan portti
this.serialPort.Open();
// Timeout lukemiselle millisekunteina
this.serialPort.ReadTimeout = 5000;
// Mahdollistetaan lukeminen
this.isReading = true;
}
catch (Exception exception)
{
this.error = exception.Message;
}
}
/// <summary>
/// Suljetaan portti
/// </summary>
public void Close()
{
// Lopetetaan lukeminen
this.isReading = false;
}
/// <summary>
/// Jäädään luuppin lukemaan dataa. Tämä luku pitää käynnistää
/// omassa theradissä.
/// </summary>
public void Read()
{
try
{
while (this.isReading == true)
{
String line = this.serialPort.ReadLine();
if (this.commands.Length > 0)
{
String start = line.Substring(1, 5);
if (this.commands.IndexOf("#" + start + "#") != -1)
{
// Seurataan vain valittuja
this.nmeaSyncQueue.Enqueue(line.Trim());
}
}
else
{
// Seurataan kaikkia
this.nmeaSyncQueue.Enqueue(line.Trim());
}
}
}
catch (System.TimeoutException)
{
this.error = "Portilta " + this.serialPort.PortName + " ei tule
dataa tai portin nopeus " + this.serialPort.BaudRate + " on
väärin!";
}
catch (Exception exception)
{
this.error = exception.Message;
}
// Suljetaan portti jos se on auki.

if (this.serialPort.IsOpen == true)
{
this.serialPort.Close();
}
// Tyhjennetään datat
this.nmeaSyncQueue.Clear();
}
/// <summary>
/// Palautetaan vanhin luettu rivi.
/// </summary>
/// <returns></returns>
public String GetNext()
{
if (this.nmeaSyncQueue.Count > 0 && this.isReading == true)
{
return (String)this.nmeaSyncQueue.Dequeue();
}
else
{
return "";
}
}
/// <summary>
/// Palautetaan viimeisin virhe
/// </summary>
/// <returns></returns>
public String GetLastError()
{
return this.error;
}
}
}
Code example 2.1. Reading the serial port in PathFinder program / Jarmo Hämäläinen,
www.codezone.fi
To be able to display location data or to be able to make the location data available for
other application programs the GPS NMEA messages must be opened. Opening the
messages is basically very simple. The Message header must be found from the ASCII
string first. Meaning of the ASCII symbols following the header are standardized.
In example 1 the main program called a method for reading the serial port. The serial port
reading method called a method for displaying general information. This method calls a
method for opening the NMEA protocol. Source code can be seen below in code example
1.3.
private void DisplayGeneralInfo()

{
labelLatitude.Text = protocol.GPGGA.Latitude.ToString();
labelLongitude.Text = protocol.GPGGA.Longitude.ToString();
labelAltitude.Text = protocol.GPGGA.Altitude.ToString();
DateTime utc = DateTime.MinValue;

if (protocol.GPRMC.Month != 0 && protocol.GPRMC.Year != 0 &&
protocol.GPRMC.Day != 0)
{
utc = new DateTime(protocol.GPRMC.Year + 2000,
protocol.GPRMC.Month, protocol.GPRMC.Day,
protocol.GPGGA.Hour, protocol.GPGGA.Minute,
protocol.GPGGA.Second, DateTimeKind.Utc);
labelDate.Text = utc.ToShortDateString();
labelTimeLocal.Text = utc.ToLocalTime().ToString();
labelTime.Text = utc.ToShortTimeString();
}
listGPSQuality.SelectedIndex =(int)protocol.GPGGA.GPSQuality;
labelFixMode.Text = protocol.GPGSA.Mode == 'A' ? "Automatic" :

"Manual";
labelPDOP.Text = protocol.GPGSA.PDOP.ToString();
labelVDOP.Text = protocol.GPGSA.VDOP.ToString();
labelHDOP.Text = protocol.GPGSA.HDOP.ToString();
labelDataValid.Text = protocol.GPRMC.DataValid == 'A' ? "Data

Valid" : "Navigation Receive Warning";
}
Code example 1.3 Method DisplayGeneralInfo calls a method for opening the protocol /
Scott Hanselmann
In code example 1 the NMEA protocol is opened in a method shown below.
public void ProcessCommand(string sCmd, byte[] bData)

{
string data = EncodeToString(bData);
switch(sCmd)
{
case "GPGGA":
ProcessGPGGA(data);
break;
case "GPGSA":
ProcessGPGSA(data);
break;
case "GPGSV":
ProcessGPGSV(data);
break;
case "GPRMC":
ProcessGPRMC(data);
break;
case "GPRMB":
//ProcessGPRMB(pData);
break;
case "GPZDA":
//ProcessGPZDA(pData);
break;
default:
break;
}
CommandCount = CommandCount + 1;
}
Code example 1.4 It is tested which one of the messages is in the string / Scott
Hanselmann
If the code above finds for example a string GPGPA the following piece of code is
executed.
public void ProcessGPGGA(string data)

{
try
{
string[] fields = Regex.Split(data,",");
//Time: Hour, Minute, Second

//Time is Zulu
GPGGA.Hour = Convert.ToInt32( fields[0].Substring(0,2));
GPGGA.Minute = Convert.ToInt32(fields[0].Substring(2,2));
GPGGA.Second = Convert.ToInt32(fields[0].Substring(4,2));
//Latitude
GPGGA.Latitude = Convert.ToDouble(fields[1])/100;
if(fields[2]=="S")
GPGGA.LatitudeHemisphere = Cardinal.South;
else
GPGGA.LatitudeHemisphere = Cardinal.North;
//Longitude
GPGGA.Longitude = Convert.ToDouble(fields[3])/100;
if(fields[4]=="E")
GPGGA.LatitudeHemisphere = Cardinal.East;
else
GPGGA.LatitudeHemisphere = Cardinal.West;
//GPS Signal Quality

GPGGA.GPSQuality = (GPSQuality)Convert.ToUInt32(fields[5]);
//Satellites
GPGGA.NumberOfSatellitesInUse = Convert.ToInt32(fields[6]);
//HDOP
GPGGA.HDOP = Convert.ToDouble( fields[7] );
//Altitude
GPGGA.Altitude = Convert.ToDouble(fields[8]);
//increase message count

GPGGA.Count ++;
}
catch(Exception e)
{
System.Diagnostics.Trace.WriteLine("Chaos in ProcessGPGGA! " +

e.ToString());
}
}
__________________________________________________________________
Code example 1.5 NMEA message GPGGA is opened and the ASCII strings are
converted to integer variables
MS Visual Studio 2008 software development environment includes a serial port tool. In
an exercise for this course we will insert a serial port on a form and interpret the
information on an NMEA 0183 string coming from a GPS receiver. The location
information will be used for opening a map page in Google Maps or the Finnish
Kansalaisen Karttapaikka.
Fig 2.6 The serial port GPS data is used in a Windows Forms application. The application
is developed by the author of this text. A Google Maps, a Bing Maps or Kansalaisen
Karttapaikka – Finnish Topografic map is opened in the actual position.
2.5 Getting navigation data into a mobile phone
2.5.1 Options for mobile application development
Applications for mobile phones can be developed using a number of different techniques.
Techniques can be listed from the most demanding to the easier ones:
C++ development for Symbian operating system
Java development for any mobile device operating system
FlashLite development for Symbian based mobile phones
Web Runtime, Widget development for Nokia mobile phones
Development with well known browser application development tools: html, CSS,
Javascript, etc.
2.5.2 Reading the navigation data into a Symbian Series 60 mobile device in a
software project written in c++
In the early phase of software development for mobile phone the Symbian operating
system organization defined a number of classes for user interaction and other tasks in the
phone. A developer needs to familiarize with these classes before he/she will be really
able to start developing any application.
For the development with Symbian C++ a free Interactive Development Environment,
IDE, is published by Nokia: Carbide.c++. Nokia as well published Software
Development Kits, SDKs, for different generations of mobile phones.
For more information please open www.forum.nokia.com and navigate to Technology

Topics, Development Platforms, Symbian C++.
For Location Based Services there are a number of APIs available:
The Location Acquisition API (supported from S60 2nd Edition, Feature Pack 2
onwards, available about 2005 ) provides easy access for Symbian native
applications to determine a user's current location, independent of the positioning
technology being used. This API can read the position from internal GPS, external
Bluetooth GPS or from network based positioning.
The Landmarks API, the Landmarks Search API, and the Landmarks Database
Management API can be used for getting information about interesting locations.
The Landmarks UI Add/Edit API provides an user interface when details on a

landmark needs to be added.
Fore more information you can browse to www.forum.nokia.com and navigate to

Technology Topics, …, Location Based Services.
Code examples can be viewed on the document

S60_Platform_Location_Acquisition_API_Specification_v9_0_en.pdf , which can be
downloaded from the above mentioned web page.
2.5.3 Reading the navigation data into a mobile device running the Java
application programs
The mobile and embedded Java platform (Java ME) was formerly known as Java 2
Platform, Micro Edition (J2ME). Java ME can be used for developing applications for
most mobile devises regardless if those are based on operating system Symbian,
Windows Mobile, etc..
The Java Location API for Java ME is intended to run on small client devices such as
mobile phones. It integrates generic positioning and orientation data with storage of point
of interest (POI) objects known as "Landmarks."
The location API for Java ME is intended to work both with the positioning information
generated locally in a mobile device and with position information transferred from a
server.
In the first case a GPS receiver can be connected to a mobile device over a Bluetooth
link. The application developer does not need to bother with the details on setting up the
connection or decoding the GPS data. The API is taking care of this technical task. The
API provides the mobile device application programmer the necessary location
information.
In the second case a server application in the network is collecting location data from the
mobile devices moving in the network area. The location information can be based on
Cell-ID or some other network based method. The location API is a client application
reading the location data from the server. The API is taking care of this server client
communication. The API provides the mobile device application programmer the
necessary location information.
The following segment of code demonstrates how to obtain the present location of the
device synchronously:
// Set criteria for selecting a location provider:

// accurate to 500 meters horizontally
Criteria cr= new Criteria();
cr.setHorizontalAccuracy(500);
// Get an instance of the provider

LocationProvider lp= LocationProvider.getInstance(cr);
// Request the location, setting a one-minute timeout

Location l = lp.getLocation(60);
Coordinates c = l.getQualifiedCoordinates();
if(c != null ) {
// Use coordinate information
double lat = c.getLatitude();
double lon = c.getLongitude();
}
Code example 2.1 The coordinate values can be read with JSR 179 API. / Oracle SUN
Developer network, Article: J2ME and Location-Based Services,
http://developers.sun.com
The Java ME Location API object model consists of 11 classes and two listener
interfaces. Many of the properties of these objects may be unavailable depending on the
location finding method an on services provided by the location server.
More information on Java ME can be found at SUN Developer Network

http://developers.sun.com. Please browse to Products, Java ME, Technology.
More information on the loction API can be found at http://developers.sun.com. by

browsing to Products, Java ME, Reference, Technical Articles and Tips or by searching
for “JSR 179”.
An example on reading location data from Bluetooth GPS receiver is published at the
Technical Articles and Tips in Article Working with Bluetooth and GPS: Part 1 - Reading
Wireless Serial Port Data
http://developers.sun.com/mobility/apis/articles/bluetooth_gps/part1/
2.5.4 Development of location based services with Web Runtime Widgets.
Web Runtime (WRT) extends the Web Browser for S60 to enable widgets — those small,
focused web applications that are so popular on PCs. Web Runtimes are often called
widgets. There is a support for Web Runtimes starting from S60 3rd Edition Feature Pack
2 ( E52, N97, etc. ).
Web Runtimes have access to location data of the device starting from the operating
system version S60 5th edition which was published with new devices in 2009 ( Touch
screen devices like N97, 5800 XpressMusic). Location based services automatically
updating the information on devices coordinate position can be developed with widgets
for the very latest phones. For the earlier models the user needs to give the location
information.
The control of the camera or access to location data is programmed using the Platform
Services API. The Platform Services API includes a feature called Location Servoce. The
Location Service allows widgets to retrieve information about the geographic location of
the device and to perform location-based calculations.
The code is actually quite typical html- and Javascript code. The Widget consists of the
main .html file and one or two .js function files. In addition the widget needs an Info.plist
file. The code example below shows the functions needed for reading the location from
the device.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
<script type="text/javascript" src="js/common.js"></script>
<script type="text/javascript" src="js/location-sample.js"></script>
</head>
<body id='docBody' bgcolor="#ddeeff" onload="setup()"
style=width:100%;height:100%;>
<form name="frm">
<h3>Location API Sample Widget</h3>
<input type="button" onclick="getLocation('img1')" value="GetLocation"><img

id="img1" src="pic/blank.png" width="25" height="25" align="center"><br>
Code example 2.2. The beginning of the main html code calling functions “setup()” and
“getLocation(‘img1’)” / Forum Nokia: Web Developers Library 1.8, Developing widgets
// Called from onload()

function setup()
{
try
{
so = device.getServiceObject("Service.Location", "ILocation");
console.info("setup: so: %s", so);
}
catch (e)
{
alert('<setup> ' +e);
}
}
// Get Location
function getLocation(imgId)
{
// This specifies update option used while retrieving location estimation.

var updateoptions = new Object();
// Setting PartialUpdates to 'FALSE' ensures that user get atleast
// BasicLocationInformation (Longitude, Lattitude, and Altitude.)
updateoptions.PartialUpdates = false;
var criteria = new Object();

criteria.LocationInformationClass = "GenericLocationInfo";
criteria.Updateoptions = updateoptions;
try
{
var result = so.ILocation.GetLocation(criteria);
if(!checkError("ILocation::getLocation",result,DIV_ID,imgId))
{
document.getElementById(DIV_ID).innerHTML = showObject(result.ReturnValue);
}
}
catch (e)
{
showIMG(imgId,"no");
alert ("getLocation: " + e);
}
}
Code example 2.3 The functions “setup()” and “getLocation(imgId)”. Function

getLocation(imgId) uses the Platform Service API 2.0 service Location and the method
.GetLocation / Forum Nokia: Web Developers Library 1.8, Developing widgets
Web Runtime development Plug Ins are offered for example for Aptana Studio, Adobe
Dreamweaver, and Microsoft Visual Studio. The Express edition of Visual Studio is not
compatible, a Standard or Professional version is needed. Visual Studio 2008 Standard
edition can be downloaded free as a 90 days trial version. The code is actually quite
typical html- and Javascript code.
Fig. 2._ Simulation of the device seen on the Nokia Web Runtime Plug-in for Aptana
Studio / Forum Nokia: Web Developers Library 1.8.
More information on Web Runtimes can be found at Forum.nokia.com, Technology

Topics, Web Technologies.
2.5.5 Development of location based services with Flash Lite
The advantage on developing with Flash Lite is that it is supported on all Nokia Mobile
Phone Platforms; S40, S60 and on other vendors phones as well. Flash Lite is a light
weight subset of Adobe Flash Player. Flash Lite has been introduced in 2003 in Japan.
More information on Flash Lite can be found on the web pages of Adobe Systems at
www.adobe.com. Browse to Products, Mobile Products, Related Producs – Flash Lite.
http://www.adobe.com/products/flashlite/
Flash Lite applications can be developed as stand alone applications. In these applications
both the Flash code and the media content is stored in the mobile device. The device is
more or less running a video in a Flash Lite Player. We will get a Location Based Service
if we run a certain video at a certain geographic location!
In on-line Flash Lite applications the Flash Lite content or actually its file name is
defined on an html web page. The file is downloaded automatically and played on the
device. The html web page can include javascript for a Web Runtime. Combining these
technologies we will be able to create very impressive LBS-applications.
On-line Flash Lite applications are supported on Nokia S60 3rd edition feature pack 1
devices and S60 5th edition devices and later versions.
The developer needs the Adobe Flash Creative Suite 4 to be installed on his/her PC or
MAC computer. For the Flash Lite development there are no completely free
development environments available.
Detailed information on how to develop for Nokia mobile phones with Flash Lite can be
found at forum.nokia.com and browsing to Technology Topics, Web Technologies, Flash
Lite.
3, Transferring the navigation data between application programs and navigation

devices
3.1 GPX file format
Extension Markup Language, XML, was developed to ease the data transfer between
applications. It is used in changing data on weather observations, business applications
etc. XML is an markup language were tags the define the meaning of the component of
data. Extension means that it is expandable, new tags can be created by the users.
The following text file is an example of simple XML data.
<?xml version= “1. 0” standalone= “yes”

encoding = “UTF-8” ?>
<letter>
<greeting> Hello John! </greeting>
<signature>
<message>
The weather has been quite gold. Luckily we have snow.
</message>
<name>
Timo
</name>
</signature>
</letter>
Code example 3.1 XML document
The rules for XML are simple: Tags must be unique. Tag must in pairs of opening and
closing tags.
If the XML document would be used for data exchange the tags and the meaning of the
content in each tag is defined in Document Type Definition, DTD.
<!ELEMENT letter ( greeting, signature)>

<!ELEMENT greeting ( #CDATA)
<!ELEMENT signature (message, name)>
<!ELEMENT message (#PCDATA)>
<!ELEMENT name (#CDATA)>
Code example 3.2 DTD file. Parsed character data, “PCDATA, and character data,
#CDATA, datatypes can be seen.
DTD file would be published in a web URI so that each user could have the same
definition.
XML schemas are even more precise definiotions than DTDs. XML schemas define a
strict hierarchy and datatypes. XML schemas are published in a web URL as well.
Some examples of the primitive XML datatypes :
Table 3.1 Datatypes
Datatype Example
string Hello John!
boolean {true, false}
decimal 7.08
float 12.56E3
time 2009-06-21T20:11:03Z
The XML files can be used for transferring location information between applications
and between devices. For this purpose there is a schema definition – GPX schema. That
defines a GPX document.
GPX is a standard XML format for exchanging GPD data. GPX defines a common set of
data tags and data hierarchy. Because it is based on XML it inherits all the benefits of
XML. The users can add their own data types and data hierarchies.
GPX data types and hierarchy is defined in the GPX schema. The schema is published at
the Topografix web site www.topografix.com under subtitle Documentation.
Table 3.2 GPX data hierarchy and datatypes, a few examples
Waypoint <wpt lat="42.439227" lon="-71.119689"> Point of interest

<ele>57.607200</ele> or a feature on a
<time>2001-06-02T03:26:55Z</time> map
<name>5067</name>
<desc>
<![CDATA[ 5067
]]>
</desc>
<sym>Dot</sym>
<type>
<![CDATA[ Intersection
]]>
</type>
</wpt>
Routepoin Turning points
<rtept lat="42.434980" lon="-71.109942"> for a route
<ele>45.307495</ele>
<time>2001-11-07T23:53:41Z</time>
<name>PANTHRCAVE</name>
<desc>
<![CDATA[ Panther Cave, worth visiting
]]>
</desc>
<sym>Tunnel</sym>
<type>
<![CDATA[ Tunnel
]]>
</type>
</rtept>
Route <rte> A route leading
<name>BELLEVUE</name> to a destination
<desc>
<![CDATA[ Bike Loop Bellevue
]]>
</desc>
<number>1</number>
<rtept lat = .......
</rtept>
</rte>
Appendix A
The NMEA 0183 messages:
Each message can contain a number of sentences. The format of the sentences is
defined in the standard.
Each sentence starts with character $. It is followed by a talker ID:

GP Global Positioning System receiver
LC Loran-C receiver
OM Omega Navigation receiver
II Integrated Instrumentation
After talker id comes the data fields separated by a comma. If there is no
information in one of the fields the limiting commas are sent anyway.
Standard NMEA 0183 Sentences sent by a navigation device:
A talker typically sends a group of sentences at intervals

determined by the unit's update rate, but generally not more
often than once per second.
Characters following the "*" are a checksum. Checksums are

optional for most sentences, according to the standard.
APB - Autopilot format B

APB,A,A,0.10,R,N,V,V,011,M,DEST,011,M,011,M
A Loran-C blink/SNR warning
A Loran-C cycle warning
0.10 cross-track error distance
R steer Right to correct (or L for Left)
N cross-track error units - nautical miles
V arrival alarm - circle
V arrival alarm - perpendicular
011,M magnetic bearing, origin to destination
DEST destination waypoint ID
011,M magnetic bearing, present position to destination
011,M magnetic heading to steer
(bearings could be given in True as 033,T)
(note: some pilots, Roberston in particular, misinterpret "bearing
from origin to destination" as "bearing from present position to
destination". This apparently results in poor performance if the
boat is sufficiently off-course that the two bearings are
different.)
BOD - Bearing - origin to destination waypoint

BOD,045.,T,023.,M,DEST,START
045.,T bearing 045 True from "START" to "DEST"
023.,M breaing 023 Magnetic from "START" to "DEST"
DEST destination waypoint ID
START origin waypoint ID
BWC - Bearing and distance to waypoint - great circle

BWC,225444,4917.24,N,12309.57,W,051.9,T,031.6,M,001.3,N,004*29
225444 UTC time of fix 22:54:44
4917.24,N Latitude of waypoint
12309.57,W Longitude of waypoint
051.9,T Bearing to waypoint, degrees true
031.6,M Bearing to waypoint, degrees magnetic
001.3,N Distance to waypoint, Nautical miles
004 Waypoint ID
BWR - Bearing and distance to waypoint - rhumb line

(format same as BWC)
DBT - Depth below transducer

DBT,0017.6,f,0005.4,M
0017.6,f 17.6 feet
0005.4,M 5.4 Metres
GGA - Global Positioning System Fix Data

GGA,123519,4807.038,N,01131.324,E,1,08,0.9,545.4,M,46.9,M, , *42
123519 Fix taken at 12:35:19 UTC
4807.038,N Latitude 48 deg 07.038' N
01131.324,E Longitude 11 deg 31.324' E
1 Fix quality: 0 = invalid
1 = GPS fix
2 = DGPS fix
08 Number of satellites being tracked
0.9 Horizontal dilution of position
545.4,M Altitude, Metres, above mean sea level
46.9,M Height of geoid (mean sea level) above WGS84
ellipsoid
(empty field) time in seconds since last DGPS update
(empty field) DGPS station ID number
GLL - Geographic position, Latitude and Longitude

GLL,4916.45,N,12311.12,W,225444,A
4916.46,N Latitude 49 deg. 16.45 min. North
12311.12,W Longitude 123 deg. 11.12 min. West
225444 Fix taken at 22:54:44 UTC
A Data valid
(Garmin 65 does not include time and status)
GSA - GPS DOP and active satellites

GSA,A,3,04,05,,09,12,,,24,,,,,2.5,1.3,2.1*39
A Auto selection of 2D or 3D fix (M = manual)
3 3D fix
04,05... PRNs of satellites used for fix (space for 12)
2.5 PDOP (dilution of precision)
1.3 Horizontal dilution of precision (HDOP)
2.1 Vertical dilution of precision (VDOP)
DOP is an indication of the effect of satellite geometry on
the accuracy of the fix.
GSV - Satellites in view

GSV,2,1,08,01,40,083,46,02,17,308,41,12,07,344,39,14,22,228,45*75
2 Number of sentences for full data
1 sentence 1 of 2
08 Number of satellites in view
01 Satellite PRN number
40 Elevation, degrees
083 Azimuth, degrees
46 Signal strength - higher is better
<repeat for up to 4 satellites per sentence>
There my be up to three GSV sentences in a data packet
HDM - Heading, Magnetic

HDM,235.,M
HDM Heading, Magnetic
235.,M Heading 235 deg. Magnetic
(HDG, which includes deviation and variation, is recommended
instead)
HSC - Command heading to steer

HSC,258.,T,236.,M
258.,T 258 deg. True
236.,M 136 deg. Magnetic
MTW - Water temperature, Celcius

MTW,11.,C
11.,C 11 deg. C
R00 - List of waypoint IDs in currently active route
R00,MINST,CHATN,CHAT1,CHATW,CHATM,CHATE,003,004,005,006,007,,,*05
(This sentence is produced by a Garmin 65, but is not listed
in Version 2.0 of the standard. The standard lists RTE for

this purpose.)
RMB - Recommended minimum navigation information (sent by nav.

receiver when a destination waypoint is active)
RMB,A,0.66,L,003,004,4917.24,N,12309.57,W,001.3,052.5,000.5,V*0B
A Data status A = OK, V = warning
0.66,L Cross-track error (nautical miles, 9.9 max.),
steer Left to correct (or R = right)
003 Origin waypoint ID
004 Destination waypoint ID
4917.24,N Destination waypoint latitude 49 deg. 17.24 min. N
12309.57,W Destination waypoint longitude 123 deg. 09.57 min. W
001.3 Range to destination, nautical miles
052.5 True bearing to destination
000.5 Velocity towards destination, knots
V Arrival alarm A = arrived, V = not arrived
*0B mandatory checksum
RMC - Recommended minimum specific GPS/Transit data

RMC,225446,A,4916.45,N,12311.12,W,000.5,054.7,191194,020.3,E*68
225446 Time of fix 22:54:46 UTC
A Navigation receiver warning A = OK, V = warning
4916.45,N Latitude 49 deg. 16.45 min North
12311.12,W Longitude 123 deg. 11.12 min West
000.5 Speed over ground, Knots
054.7 Course Made Good, True
191194 Date of fix 19 November 1994
020.3,E Magnetic variation 20.3 deg East
*68 mandatory checksum
RTE - Waypoints in active route

RTE,2,1,c,0,W3IWI,DRIVWY,32CEDR,32-29,32BKLD,32-I95,32-US1,BW-
32,BW-198*69
2 two sentences for full data
1 this is sentence 1 of 2
c c = complete list of waypoints in this route
w = first listed waypoint is start of current leg
0 Route identifier
W3IWI... Waypoint identifiers
VHW - Water speed and heading

VHW,259.,T,237.,M,05.00,N,09.26,K
259.,T Heading 259 deg. True
237.,M Heading 237 deg. Magnetic
05.00,N Speed 5 knots through the water
09.26,K Speed 9.26 KPH
VWR - Relative wind direction and speed

VWR,148.,L,02.4,N,01.2,M,04.4,K
148.,L Wind from 148 deg Left of bow
02.4,N Speed 2.4 Knots
01.2,M 1.2 Metres/Sec
04.4,K Speed 4.4 Kilometers/Hr
VTG - Track made good and ground speed

VTG,054.7,T,034.4,M,005.5,N,010.2,K
054.7,T True track made good
034.4,M Magnetic track made good
005.5,N Ground speed, knots
010.2,K Ground speed, Kilometers per hour
WCV - Waypoint Closure Velocity

WDC - Distance to Waypoint
WDR - Waypoint Distance, Rhumb Line
WPL - waypoint location

WPL,4917.16,N,12310.64,W,003*65
4917.16,N Latitude of waypoint
12310.64,W Longitude of waypoint
003 Waypoint ID
When a route is active, this sentence is sent once for each
waypoint in the route, in sequence. When all waypoints have
been reported, GPR00 is sent in the next data set. In any
group of sentences, only one WPL sentence, or an R00
sentence, will be sent.
XTE - Cross track error, measured

XTE,A,A,0.67,L,N
A General warning flag V = warning
(Loran-C Blink or SNR warning)
A Not used for GPS (Loran-C cycle lock flag)
0.67 cross track error distance
L Steer left to correct error (or R for right)
N Distance units - Nautical miles
XTR - Cross-Track Error - Dead Reckoning

XTR,0.67,L,N
0.67 cross track error distance
L Steer left to correct error (or R for right)
N Distance units - Nautical miles

Finland Location Aware Mobile Services The Techniques For The Application Developer 1/31 Timo Karppinen 2.2. 2010

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Finland Location Aware Mobile Services The Techniques For The Application Developer 1/31 Timo Karppinen 2.2. 2010

Enviado por

Direitos autorais:

Formatos disponíveis

HAMK

University of Applied Sciences

2. The techniques for the application developer

2.1 Development tasks

Satellite positioning: GPS, GALILEO, GLONAS

Timo Karppinen timo.karppinen@hamk.fi

• The size of the receiver is nowadays about 20 mm x 20 mm x 3 mm or smaller.

• Positioning is based on similar calculations as in GPS. Although there are more

Navigation based on cellular network cell-ID and propagation delays in cellular

Enhanced Observed Time Difference, EOTD, is the method in European networks.

OTDOA-IPDL, Observed Time Difference Of Arrival – Idle Period Down Link, is

Navigation based on Wi-Fi, WLAN, networks IP –addresses.

2.3 Navigation chip sets and navigation devices

fig. 1. GPS receiver chip / www.trible.com

The navigation receiver can be a handheld device.

Figure 2. Handheld GPS –receiver for outdoor activities/ www.magellangps.com

Fig 4. GPS receiver and a serial port cable.

The content of the NMEA 0183 messages are explained in appendix A.

2.4 Getting navigation data into a pc-computer

063901: UTC time of position

1/2/3: GPS quality indicator

$GPVTG, 134,T, 137,M, 004.1,N, 007.6,K *66

134,T: course degrees true

private void connectButton_Click(object sender, System.EventArgs e)

Private void disconnectButton_Click(object sender, System.EventArgs e)

private void timer1_Tick(object sender, System.EventArgs e)

private void ReadData()

// Suljetaan portti jos se on auki.

private void DisplayGeneralInfo()

DateTime utc = DateTime.MinValue;

labelFixMode.Text = protocol.GPGSA.Mode == 'A' ? "Automatic" :

labelDataValid.Text = protocol.GPRMC.DataValid == 'A' ? "Data

In code example 1 the NMEA protocol is opened in a method shown below.

public void ProcessCommand(string sCmd, byte[] bData)

public void ProcessGPGGA(string data)

//Time: Hour, Minute, Second

//GPS Signal Quality

//increase message count

System.Diagnostics.Trace.WriteLine("Chaos in ProcessGPGGA! " +

2.5 Getting navigation data into a mobile phone

2.5.1 Options for mobile application development

C++ development for Symbian operating system

Java development for any mobile device operating system

FlashLite development for Symbian based mobile phones

Web Runtime, Widget development for Nokia mobile phones

For more information please open www.forum.nokia.com and navigate to Technology

For Location Based Services there are a number of APIs available:

The Landmarks UI Add/Edit API provides an user interface when details on a

Fore more information you can browse to www.forum.nokia.com and navigate to

Code examples can be viewed on the document

// Set criteria for selecting a location provider:

// Get an instance of the provider

// Request the location, setting a one-minute timeout

More information on Java ME can be found at SUN Developer Network

More information on the loction API can be found at http://developers.sun.com. by

2.5.4 Development of location based services with Web Runtime Widgets.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<input type="button" onclick="getLocation('img1')" value="GetLocation"><img

// Called from onload()

// This specifies update option used while retrieving location estimation.

var criteria = new Object();

Code example 2.3 The functions “setup()” and “getLocation(imgId)”. Function