Butterfly effect

 

Contents

 

 

1. Project Description

 

By this project we wish to achieve a complex system that will permit the monitoring of a mobile fleet over a wide area. We also wish to be able to provide relevant data to the mobile agents according to its specific location. Also the possibility of collecting data from the field can be beneficial for effectively managing the fleet.

 

The main functionalities of the system are:

• establishing a poistion
• bi-directional communication
• user interface
• command and controll center

 

1.1. Implementation

 

    1.1.1. Positioning system

 

For the positioning system we chose to use GPS system. The GPS system satisfactory accuracy for our application and its wide availability and equipment cost make it an attractive solution. Further developments, like the European GALILEO initiative prove that this is a viable long-term solution. Later in the paper we will discuss how to improve GPS accuracy.

 

    1.1.2. Bi-directional comunication

 

Bi directional communication can be achieved in a variety of ways: analogue or digital communication, wide or small area, point to point or point to multipoint. For the purpose of our system we established that a digital link wide area connection would be ideal. Unfortunately, deploying a wide area network involves great cost (base stations, TX equipment, frequency licensing) so using an existing network is the obvious second choice. GSM Networks have sufficient coverage in Romania and in Europe. Digital connection equipment is relatively cheap, connection charges are dropping and speed is satisfactory. Also GSM networks offer the possibility of using IP technology for communication, allowing easy interconnection between a variety of systems.

 

    1.1.3. User Interface

 

Depending on desired application, the system provides a user interface for the mobile clients. We have chosen to use a PDA because of the high quality interface provided, high processing power and ease of programming. However, where automatic data communication and collection is achieved, the user interface can be ignored.

 

    1.1.4. Command and Control center

 

The command and control center is a critical part of the system as it accumulates all the information collected from the mobile agents, stores and processes it and also provides the operator the means to visualize and control the fleet. We decided to split the command and control center in two: the storage system and the operator interface. The storage system is built upon a Linux system running a MySQL Server. MySQL provides high speed and scalability, being able to operate in cluster configurations with minimal modifications. The Operator interface is a Windows machine. We chose Windows because of it’s familiarity among users and the ease of graphical programming.

 

 

2. The GPS System

 

    2.1. General Outline

 

The Global Positioning System, usually called GPS, is the currently the only fully-functional satellite navigation system. A constellation of more than two dozen GPS satellites broadcasts precise timing signals by radio to GPS receivers, allowing them to accurately determine their location (longitude, latitude, and altitude) in any weather, day or night, anywhere on Earth.

 

GPS has become a vital global utility, indispensable for modern navigation on land, sea, and air around the world, as well as an important tool for map-making, and land surveying. GPS also provides an extremely precise time reference, required for telecommunications and some scientific research, including the study of earthquakes.

 

United States Department of Defense developed the system, officially named NAVSTAR GPS (Navigation Signal Timing and Ranging GPS), and the satellite constellation is managed by the 50th Space Wing at Schriever Air Force Base. Although the cost of maintaining the system is approximately US$400 million per year, including the replacement of aging satellites, GPS is available for free use in civilian applications as a public good.

 

In late 2005, the first in a series of next-generation GPS satellites was added to the constellation, offering several new capabilities, including a second civilian GPS signal called L2C for enhanced accuracy and reliability. In the coming years, additional next-generation satellites will increase coverage of L2C and add a third and fourth civilian signal to the system, as well as advanced military capabilities.

 

The GPS system uses a satellite constellation of at least 24 active satellites in intermediate circular orbits. The constellation also includes three spare satellites in orbit, in case of any failure. Each satellite circles the Earth exactly twice each day at an altitude of 20,200 kilometers. The orbits are aligned so at least four satellites are always within line of sight from almost any place on Earth. There are four active satellites in each of six orbital planes. Each orbit is inclined 55 degrees from the equatorial plane, and the right ascension of the ascending nodes is separated by sixty degrees.

 

The flight paths of the satellites are measured by five monitor stations around the world (Hawaii, Kwajalein, Ascension Island, Diego Garcia, Colorado Springs). The master control station, at Schriever AFB, processes their combined observations and sends updates to the satellites through the stations at Ascension Island, Diego Garcia, Kwajalein. The updates synchronize the atomic clocks on board each satellite to within one microsecond and also adjust the ephemeris of the satellites’ internal orbital model to match the observations of the satellites from the ground.

 

Each satellite repeatedly re-broadcasts the exact time according to its internal atomic clock along with a digital data packet. The data includes the orbital elements of the satellite’s precise position, satellite status messages, and an almanac of the approximate position of every other active GPS satellite. The almanac lets GPS receivers use data from the strongest satellite signal to locate other satellites.

 

Receivers

 

GPS receivers calculate their current position (latitude, longitude, elevation), and the precise time, using the process of trilateration. This involves measuring the distance to at least four satellites by comparing the satellites’ coded time signal (PRN Code) transmissions. The receiver calculates the orbit of each satellite based on information encoded in their radio signals, and measures the distance to each satellite, called a pseudorange, based on the time delay from when the satellite signals were sent until they were received.

 

In order to measure the delay, the satellite repeatedly sends a 1,023 bit long pseudo random sequence; the receiver calculates an identical sequence from a known seed number, and shifts it until the two sequences match. Each satellite uses a different sequence, which lets them share the same radio frequencies, using Code Division Multiple Access, while still allowing receivers to identify each satellite.

 

Once the location and distance of each satellite is known, the receiver should theoretically be located at the intersection of four imaginary spheres, one around each satellite, with a radius equal to the time delay between the satellite and the receiver multiplied by the speed of the radio signals. In practice, GPS calculations are more complex for several reasons. One complication is that GPS receivers do not have atomic clocks, so the precise time is not known when the signals arrive. Fortunately, even the relatively simple clock within the receiver provides an accurate comparison of the timing of the signals from the different satellites. The receiver is able to determine exactly when the signals were received by adjusting its internal clock (and therefore the spheres’ radii) so that the spheres intersect near one point.

 

One of biggest problems for GPS accuracy is that changing atmospheric conditions change the speed of the GPS signals unpredictably as they pass through the ionosphere. The effect is minimized when the satellite is directly overhead and becomes greater toward the horizon, as the satellite signals must travel through the greater “thickness” of the ionosphere as the angle increases. Once the receiver’s rough location is known, an internal mathematical model can be used to estimate and correct for the error.

 

Because ionospheric delay affects the speed of radio waves differently based on their frequencies, the second frequency band (L2) was used to help eliminate this type of error. Military and some highly expensive survey-grade civilian receivers can [Only military and some highly expensive survey-grade civilian receivers can compare the phase difference between the L1 and L2 frequencies to actually measure the atmospheric effects on the signals and apply precise corrections.]

 

GPS signals can also be affected by multipath reflections of the radio signals off the ground and/or surrounding structures (buildings, canyon walls, etc). For long delay multipath signals, the receiver itself can filter the signals out. A variety of receiver techniques, most notably Narrow Correlator spacing, have been developed to mitigate multipath errors. For shorter delay multipath signals that result from reflections from the ground, special antenna features may be used such as a ground plane, or a choke ring antenna. Shorter multipath signals from ground reflections can often be very close to the direct signals, and can greatly reduce precision.

 

Some GPS receivers can relay position data to a PC or other device using the NMEA 0183 protocol. NMEA 2000 is a newer and less widely adopted protocol. Both are proprietary, and are controlled on a for-profit basis by the US-based National Marine Electronics Association.

 

 

Frequencies

 

Several frequencies make up the GPS electromagnetic spectrum:

 

* L1 (1575.42 MHz):

Carries a publicly usable coarse-acquisition (C/A) code as well as an encrypted precision P(Y) code.

* L2 (1227.60 MHz):

Usually carries only the P(Y) code. The encryption keys required to directly use the P(Y) code are tightly controlled by the U.S. government and are generally provided only for military use. The keys are changed on a daily basis. In spite of not having the P(Y) code encryption key, several high-end GPS receiver manufacturers have developed techniques for utilizing this signal (in a round-about manner) to increase accuracy and remove error caused by the ionosphere. Recognizing the civilian need for increased accuracy, “modernized” IIR-M (IIR-14 (M) and later) satellites carry a civilian signal interleaved with an improved military signal on both the L1 and L2 frequencies.

* L3 (1381.05 MHz):

Carries the signal for the GPS constellation’s alternative role of detecting missile/rocket launches (supplementing Defense Support Program satellites), nuclear detonations, and other high-energy infrared events.

* L4 (1841.40 MHz):

Being studied for additional ionospheric correction.

* L5 (1176.45 MHz):

Proposed for use as a civilian safety-of-life (SoL) signal. This frequency falls into an internationally protected range for aeronautical navigation, promising little or no interference under all circumstances. The first Block IIF satellite that would provide this signal is set to be launched in 2008.

 

2.2. Data decoding

 

Most GPS receivers including the ones we are using, output data in NMEA 0183 format. NMEA is a standard protocol, use by GPS receivers to transmit data. NMEA output is EIA-422A but for most purposes you can consider it RS-232 compatible. Use 4800 bps, 8 data bits, no parity and one stop bit ( 8N1 ). NMEA 0183 sentences are all ASCII. Each sentence begins with a dollar sign ($) and ends with a carriage return linefeed (<CR><LF>). Data is comma delimited. All commas must be included as they act as markers. Some GPS do not send some of the fields. A checksum is optionally added (in a few cases it is mandatory). Following the $ is the address field aaccc. aa is the device id. GP is used to identify GPS data. Transmission of the device ID is usually optional. ccc is the sentence formatter, otherwise known as the sentence name.

The NMEA 0183 data stream consists of a series of “sentences” delimited by a newline character. Each sentence begins with a six character identifier, the first character of which is always “$”. The NMEA 0183 standard defines dozens of sentences, but only a fraction applies directly to GPS devices. The most useful sentences include:

• $GPAAM – Waypoint Arrival Alarm
• $GPBOD – Bearing, Origin to Destination
• $GPBWW – Bearing, Waypoint to Waypoint
• $GPGGA – Global Positioning System Fix Data
• $GPGLL – Geographic Position, Latitude/Longitude
• $GPGSA – GPS DOP and Active Satellites
• $GPGST – GPS Pseudorange Noise Statistics
• $GPGSV – GPS Satellites in View
• $GPHDG – Heading, Deviation & Variation
• $GPHDT – Heading, True
• $GPRMB – Recommended Minimum Navigation Information
• $GPRMC – Recommended Minimum Specific GPS/TRANSIT Data
• $GPRTE – Routes
• $GPVTG – Track Made Good and Ground Speed
• $GPWCV – Waypoint Closure Velocity
• $GPWNC – Distance, Waypoint to Waypoint
• $GPWPL – Waypoint Location
• $GPXTE – Cross-Track Error, Measured
• $GPXTR – Cross-Track Error, Dead Reckoning
• $GPZDA – UTC Date/Time and Local Time Zone Offset
• $GPZFO – UTC and Time from Origin Waypoint
• $GPZTG – UTC and Time to Destination Waypoint

All this sentences are explained in the Appendix.

The most relevant sentence for this project is $GPGGA. Its format is:

 

            Table 2.2.1 NMEA $GPGGA Sentence format

 

Example strings that are received from the GPS receiver are:

Signal not acquired: $GPGGA,235947.000,0000.0000,N,00000.0000,E,0,00,0.0,0.0,M,,,,0000*00

Signal acquired:

$GPGGA,170834.000, 4124.8963,N, 08151.6838,W,1,05,280.2,-34.7,M,,,,0000*1F

The interpretation of the above string is:

 

Table 2.2.2 Interpreting Sample NMEA Data

 

 

2.3. Improving GPS accuracy

 

The GPS signal travels through every layer of the Earth’s atmosphere. Each layer affects the signal differently. The ionosphere, which is the high-altitude, electrically charged part of the atmosphere, introduces a delay, and therefore a range error, into the signal. The delay is frequency dependent, so it can be directly computed if you have data on both the GPS frequencies. There is also a delay due to the troposphere, the lower part of the atmosphere. This delay too can be modeled and removed. There are many other errors associated with the GPS signal such ass multipath reflections.

 

Methods of improving GPS accuracy:

 

 

• The Wide Area Augmentation System (WAAS). This uses a series of ground reference stations to calculate GPS correction messages, which are uploaded to a series of additional satellites in geosynchronous orbit for transmission to GPS receivers, including information on ionospheric delays, individual satellite clock drift, and suchlike. The current WAAS system only works for North America (where the reference stations are located), and due to the satellite location the system is only generally usable in the eastern and western coastal regions.
• A Local Area Augmentation System (LAAS). This is similar to WAAS, in that similar correction data are used. But in this case, the correction data are transmitted from a local source, typically at an airport or another location where accurate positioning is needed. These correction data are typically useful for only about a thirty to fifty kilometer radius around the transmitter.
• Relative Kinematic Positioning (RKP) is another approach for a precise GPS-based positioning system. In this approach, accurate determination of range signal can be resolved to an accuracy of less than 10 centimeters. This is done by resolving the number of cycles in which the signal is transmitted and received by the receiver. This can be accomplished by using a combination of differential GPS (DGPS) correction data, transmitting GPS signal phase information and ambiguity resolution techniques via statistical tests—possibly with processing in real-time (real-time kinematic positioning, RTK).
• Many automobiles that use the GPS combine the GPS unit with a gyroscope and speedometer pickup, allowing the computer to maintain a continuous navigation solution by dead reckoning when buildings, terrain, or tunnels block the satellite signals. This is similar in principle to the combination of GPS and inertial navigation used in ships and aircraft, but less accurate and less expensive because it only fills in for short periods.

 

More precise applications reduce the effect of error sources by a technique referred to as differential GPS (DGPS). By differencing measurements simultaneously collected by the user and a nearby reference receiver, the errors that are common to both receivers (most of them) are removed. The result of DGPS positioning is a position relative to the reference receiver; adding the reference position to the DGPS solution results in the absolute user position. Differential GPS (DGPS) can improve the normal GPS accuracy of 4-10 meters to 1-4 meters.

 

An interesting option for correcting the position in our case is by feeding DGPS correction over the data link. The prerequisites of this method are that the mobile receivers support DGPS correction in RTCM format.

 

 

 

Example

 

A test has been carried out using a static GPS unit. The unit’s position has been established statistically and monitored over a 24h period. Results are presented below:

 

 

Table 2.3.1 GPS position survey, static receiver

 

Conclusion: While taking a stationary reading, it is expected that the reading would fall within 2.5 meters of the correct horizontal position about 50% of the time. The reading would fall within 7 meters of the correct horizontal position about 95% of the time

Although this is accurate enough for most applications we have to take into account that the precision is much lower in case of a moving receiver and in a city scenario.

 

Another test, using DGPS corrections from the BUCU0 ground station in Bucharest yielded the following results:

 

Table 2.3.1 GPS position survey, static receiver with DGPS corrections

 

 

Conclusion: While taking a stationary reading, it is expected that the reading would fall within 1.5 meters of the correct horizontal position about 50% of the time. The reading would fall within 4.1 meters of the correct horizontal position about 95% of the time.

 

It is known that the error grows with the distance of the mobile receiver from the ground station providing DGPS correction. As a conclusion, it is recommended that a DGPS ground station is installed as close as possible to the operating area of the mobile fleet.

3. The GSM/GRPS System

 

3.1. General outline

 

GSM is a cellular network, which means that mobile phones connect to it by searching for cells in the immediate vicinity. GSM networks operate in four different radio frequencies. Most GSM networks operate in the 900 MHz or 1800 MHz bands. Some countries in the Americas (including the USA and Canada) use the 850 MHz and 1900 MHz bands because the 900 and 1800 MHz frequency bands were already allocated.

 

The rarer 400 and 450 MHz frequency bands are assigned in some countries, notably Scandinavia, where these frequencies were previously used for first-generation systems.

 

In the 900 MHz band the uplink frequency band is 890-915 MHz, and the downlink frequency band is 935-960 MHz. This 25 MHz bandwidth is subdivided into 124 carrier frequency channels, each spaced 200 kHz apart. Time division multiplexing is used to allow eight speech channels per radio frequency channel. There are eight radio timeslots (giving eight burst periods) grouped into what is called a TDMA frame. The channel data rate is 270.833 kbit/s, and the frame duration is 4.615 ms.

 

The transmission power in the handset is limited to a maximum of 2 watts in GSM850/900 and 1 watt in GSM1800/1900.

 

GSM uses Linear predictive coding (LPC). The purpose of LPC is to reduce the bit rate. The LPC provides parameters for a filter that mimics the vocal tract. The signal passes through this filter, leaving behind a residual signal. Speech is encoded at 13 kbit/s.

 

The modulation used in GSM is Gaussian minimum shift keying (GMSK), a kind of continuous-phase frequency shift keying. In GMSK, the signal to be modulated onto the carrier is first smoothed with a Gaussian low-pass filter prior to being fed to a frequency modulator, which greatly reduces the interference to neighboring channels (adjacent channel interference).

 

General Packet Radio Service (GPRS) is a mobile data service available to users of GSM mobile phones. It is often described as “2.5G”, that is, a technology between the second (2G) and third (3G) generations of mobile telephony. It provides moderate speed data transfer, by using unused TDMA channels in the GSM network.

 

 

    3.2. Data communication

 

 

GPRS is packet-switched which means that multiple users share the same transmission channel, only transmitting when they have data to send. This means that the total available bandwidth can be immediately dedicated to those users who are actually sending at any given moment, providing higher utilization where users only send or receive data intermittently.

 

Packet-switched data under GPRS is achieved by allocating unused cell bandwidth to transmit data. As dedicated voice (or data) channels are setup by phones, the bandwidth available for packet switched data shrinks. A consequence of this is that packet switched data has a poor bit rate in busy cells. The theoretical limit for packet switched data is approx. 160.0 kbit/s (using 8 time slots and CS-4). A realistic bit rate is 30–80 kbit/s, because it is possible to use max 4 time slots for downlink. A change to the radio part of GPRS called EDGE (sometimes called EGPRS or Enhanced GPRS) allows higher bit rates of between 160 and 236.8 kbit/s. The maximum data rates are achieved only by allocation of more than one time slot in the TDMA frame. Also, the higher the data rate, the lower the error correction capability. Generally, the connection speed drops logarithmically with distance from the base station. This is not an issue in heavily populated areas with high cell density, but may become an issue in sparsely populated/rural areas.

 

Connection latency (when running TCP/IP over GPRS) has been measured around 100ms in ideal conditions and grows to about 1500ms in the most adverse conditions. This latency values are acceptable for our application.

 

Multipoint data transmission

 

In our application we need multipoint data transmission: mobile clients need to have access to a remote server and a remote server needs to be able to notify clients with relevant data.

 

GPRS network connections identify clients in a given network by means of APN (Access Point Number). The common APN defines the network with internet access. However internet access is achieved thru NAT (Network Address Translation) which means that while client to server data transmission is possible, server to client connections can not be initiated. This limitation can be circumvented by configuring clients cu regularly poll the server for relevant data but this solution significantly increases network traffic and server load.

Another solution is registering a special APN with the GSM network operator. This solution resolves all the above problems but increases initial costs.

 

The architecture in case of a private APN is depicted below:

 

 

3.3. Cost

 

Telephone operators have priced GPRS relatively cheaply (compared to older GSM data transfer, CSD and HSCSD) in many areas, such as Finland. Most mobile phone operators don’t offer flat rate access to the Internet (with the notable exceptions of T-Mobile in both United States and Europe, and Cingular in the United States), instead basing their tariffs on data transferred, usually rounded off per 100 kilobyte.

 

Typical rates vary wildly, ranging from EUR €1 per megabyte to over €20 per megabyte. In the U.S., T-Mobile offers US$30 per month unlimited GPRS. In India, BPL Mobile (Bombay) offers unlimited GPRS for Rs.500 (USD 11) per month. AirTel offers nation-wide unlimited GPRS and EDGE for Rs. 600 (USD 13.5). In Pakistan, Mobilink is also offering unlimited GPRS service on its post paid connections for Rs 500 (US$ 8.33). Orange (UK) offers a 1 Gigabyte package for €128 a month, and a £1 per day unlimited use package for pre-paid users. In Poland, Era GSM offers a 2 Gigabyte package of GPRS and UMTS transmission under Blueconnect brand for €30 a month and Plus GSM offers a 1 Gigabyte package for €15 a month. In the Philippines, Globe Telecom offers the service for USD 0.003 per kilobyte.

 

 

Costs in Romania, involving a private APN are:

 

Private APN: 100$/month

Price per MB is 0.13$

 

 

The traffic expected from a month long continuous monitoring of a taxi car is about 5MB (12h/day usage).

 

4. User Interface

 

There are two parts involved in the user interface: the dispatcher user interface and the mobile agents user interface. While the dispatcher can be considered a relatively highly trained employee, capable to adapt to a complex operating environment, the mobile agents user interface has to be designed as simple as possible since it has to be operated by a driver. The mobile user interface has to be as simple as possible to be easy to operate, yet it has to provide all relevant information at any time.

 

The mobile user interface must be able to present at least the following information:

• system status, including:
  • satellite status
  • communication status
• current car status
• current assigment
• upcoming traffic events

 

Supplemental information could be provided:

• current location
• road directions
• available assigments

 

Additionally the driver must be able to interact with the system being able to:

 

• request supplemental information
• accept assignments
• introduce data regarding traffic status

 

 

 

5. Design and implementation of a minimal Geographical Information System

 

5.1. Scope

 

The purpose of the geographical information system is to provide the underlying base for all available data in the system and also to provide a general overview regarding the status of the system.

While there are geographical information systems already implemented, most of them are not freely available or do not meet the requirements of this project [6]. Also, a custom implemented solution will can provide specific application optimizations and will support future enhancements.

 

In order to fulfill the project’s requirements, the geographical information system must be able to store and present the following information:

• accurate geographical data regarding the available roads
• road mesh
• position of the mobile agents
• position of assigments
• detailed data about the roads, including:
  • street name and numbering
  • number of lanes
  • traffic jam status
  • divider type
  • road condition
  • speed condition
• Supplemental data about the roads should be available, including:
  • Historycal average speed
  • Current average speed
  • Possible events (police, accident)
  • Restricted areas

 

 

From the above list, the conclusion can be drawn that the system must store vector data (road mesh), data (position of specific data) as well as raster general data (street names, numbering). In order to obtain this, the geographical information system stores data as several distinct layers.

The geographical information system is the workhorse of the whole system and must be designed properly to be able to interact with the communication module and dispatcher.

An additional functionality of the geographical information system is the data entry module. This module is vital in the start up phase of the system and must be able to receive data from the field and from the operator in order to accumulate the relevant data.

 

 

5.2. Projections

 

A map projection is any method used in cartography (mapmaking) to represent the two-dimensional curved surface of the earth or other body on a plane. The term “projection” here refers to any function defined on the earth’s surface and with values on the plane, and not necessarily a geometric projection.

 

Flat maps could not exist without map projections. Flat maps are more useful than globes in many situations: they are more compact and easier to store; they readily accommodate an enormous range of scales; they are viewed easily on computer displays; they can facilitate measuring properties of the terrain being mapped; they can show larger portions of the earth’s surface at once; and they are cheaper to produce and transport. These useful traits of flat maps motivate the development of map projections.

 

    For our project we needed a projection that could easily accommodate the flat screen display, yet providing relevant data about position and distance an easy conversion of GPS lat/long data in pixel coordinates. For this reason we chose to use UTM (Universal Transverse Mercator) to which we converted the raw GPS lat/lon data that is provided in the WGS-84 system.

 

 

The WGS84 System

 

World Geodetic System 1984 is defined and maintained by the U.S. National Mapping & Imaging Agency (NMIA), formerly known as the Defense Mapping Agency (DMA), as a global geodetic datum (D.M.A., 1991). The realization of the WGS84 satellite datum is the catalogue of coordinates of over 1500 geodetic stations (most of them active or past tracking stations) around the world. They fulfill the same function as national geodetic stations; they provide the means by which a position can be related to a datum. WGS84 is an earth-fixed Cartesian coordinate system with:

 

• Its origin at the earth’s centre of mass, the geocentre (for two reasons: the geocentre is the physical point about which the satellite orbits; and it is preferable to any local geodetic datum).
• Its “z-axis” is aligned parallel to the direction of the Conventional Terrestrial Pole (CTP) for polar motion, as originally defined by the Bureau International de l’Heure (BIH), and since 1989 by the International Earth Rotation Service (IERS).
• Its “x-axis” is the intersection of the WGS84 Reference Meridian Plane and the plane of the CTP Equator (the Reference Meridian being parallel to the Zero Meridian defined by BIH/IERS).
• Its “y-axis” completes a right-handed, earth-centered, earth-fixed (ECEF) orthogonal coordinate system, measured in the plane of the CTP Equator, 90 east of the x-axis.

 

The four defining parameters of the WGS84 ellipsoid are:

• Semi-major axis (a): 6378137m.
• Ellipsoid flattening (f): 1/298.257223563 (derived from the value of the normalized second degree zonal harmonic coefficient of the gravitational field: -484.16685 x 10-6).
• Angular velocity of the earth (w): 7292115 x 10-11 rad/sec.
• The earth’s gravitational constant (atmosphere included) (GM): 3986005 x 10-8 m3/sec2.

 

The UTM System

 

The problem with the geographic coordinate-system is that it is a circular system, and is thus difficult to work with on planar maps. To avoid these difficulties, the UTM and other similar systems introduce orthogonal coordinate systems by dividing the earth into a number of zones where the surface of the earth can be approximated as a planar surface.

In the UTM, the earth is partitioned into 60 equal zones, each with a width of 6 degrees. The numbering of the zones starts at the 180 meridian (the dateline) and extends eastwards from 1 to 60. Each of these zones reaches from 80 degrees south to 84 degrees north. Further, each zone is divided into 20 zone belts.

These have one letter each, from C to X (except I and O) starting in the south. Thus, the earth is partitioned into 1200 zone belts, each numbered with a number and a letter. The zone belts are shown in the figure.

 

Within each zone belt, the coordinates are orthogonal. As shown on figure, each of the zone belts are further partitioned into squares of 100 km in each direction. Within each of the 100 km squares, the position is addressed by the number of meters the point is from the western and southern border of the 100 km square. For example, the UTM-coordinates for Cluj Napoca are 5183898 695377 34T and for Bucharest 4918547 428350 35T.

 

The granularity obtained by the UTM system is 1 meter in each direction. This is good enough for our system. Conversion between the longitude/latitude system and the UTM is not straightforward. For this and other reasons, implementations using the UTM can get complicated. For the end-user, the UTM provides orthogonal coordinates which is easier to use as reference on maps and pixel representations.

 

 

 

 

 

 

WGS84 to UTM Conversion algorithm

 

According to [4] the WGS84 to UTM Conversion algorithm is:

 

 

 

 

 

 

UTM to WGS84 conversion algorithm

According to [4] the UTM to WGS84 Conversion algorithm is:

 

 

 

Significant information is also available in [4] [1] [3].

5.3. Representation of Map related Knowledge

 

The representation of map related knowledge is concerned with accommodating the available geographical data in a relational database. Additionally it must provide the possibility of storing and retrieving additional data, linked to geographical locations:

• position and length of roads
• position of intersections
• position of mobile agents
• position and date of events
• detailed data about the roads, including:
  • street name and numbering
  • number of lanes
  • traffic jam status
  • divider type
  • road condition
  • speed condition
• Supplemental data about the roads should be available, including:
  • Historycal average speed
  • Current average speed
  • Possible events (police, accident)
  • Restricted areas

 

As supplemental functionality, representation must facilitate the calculation of shortest path between two points, find mobile agents in a certain (box) area and be fast enough to provide real time overview of the system.

For this purpose a fast relational database system is highly recommended. A possible database structure is depicted in the schema below:

 

 

 

This logical representation has the great advantage that is uses standard SQL queries to obtain any relevant data. This procedure takes advantage of the optimized SQL algorithm and allows future capacity extensions to be carried out by means of SQL Engine upgrade.

One of the most common operations of the Command Center is finding cars in a specific area.

 

The associated SQL query is:

 

$query = “SELECT `id`, FROM `agent` WHERE `pos1lat` > ‘$lat’
AND `pos1long` < ‘$long’
AND `pos2lat` < ‘$lat’
AND `pos2long` > ‘$long’”;

 

 

 

 

 

 

This query returns all agents in a box of a specified size.

 

5.4. Building Maps

 

The problem of building maps is essential for the success of the system as inaccurate maps can seriously undermine the efficiency and added benefits of whole system. Inaccurate positioning can lead to inefficient use of resources and incomplete roadmaps will lead to improper car guidance and assignments allocation.

After several tests, two methods of (digital) map building have been devised:

1. Digitization
2. Field data collection.

 

Digitization

The method of digitization consists of entering an already existing map (or a satellite image), calibrating it and tracing existing roads. The calibration is made by choosing at least two points (preferably more) on the map with known geographical coordinates.

 

 

Thru internal calculations, the projection of the map and other possible deformations are established. Road tracing can now begin. The process of road tracing is extremely tedious work and requires significant operator assistance: the operator must introduce intersections, road elements, road names and numbers, road characteristics. However, this is not a common operation and generally a map will be built only at the start of the operation.

 

Field Data collection

 

The field data collection method is very similar to the digitization method but it can be applied in situations where there are no accurate available maps. The method relies on direct collection of data from the field via GPS receivers. The calibration phase is excluded with this method but additional personnel (drivers) are necessary in the field, driving along ALL available roads.

 

 

5.5. Evaluation of the performance for the prototype implementation

 

    The most critical aspect of the geographical information system is the speed in by which data can be retrieved and processed.

    By the way the logical representation is structured, the system load is evaluated by the number of roads in the map, the number of intersections and number of mobile agents. Performance was evaluated by measuring the time needed to:

• render a map
• find mobile agents in a defined radius
• find shortest path between two points

The data for the Geographical Information System has been randomly generated. The mobile agents are simulated using a custom application (GPSGhostAgents).

All tests have been performed on the same system, with a reasonable configuration. (2.8GHz /512 RAM /5400RPM HDD)

 

Table 5.5. Experimental performance data for 2 experimental scenarios

 

 

 

 

6. Control and Monitoring System

6.1. Purpose

 

After all necessary data is available (geographical, mobile agents), the control and monitoring system provides the logic link between. The control system must be able to provide at least the following functionality:

• display of maps
• display of mobile agents
• search for a street address on the map
• search for mobile agents in a specific area
• route mobile agents according to street maps
• transmit and receive dispatch commands and status messages to and from mobile agents

 

Table 6.1.1 Control and monitoring system functioning algorithm in pseudo code

 

1: GetMapfromBD()

2: DisplayMap()

3: BuildWeightedDirectedGraphofStreetMesh()

4: While(true)

5:     GetMobileUnitsPosition()

6:    DisplayMobileUnits()

7:    WaitforTask()

8:    If NewTask()

9:        TaskQueue[] ß GetNewTask()

10.    End if

11:    While TaskQueue[] !=Empty

12:        Position = GetTaskPosition(TaskQueue[CurrentTask])

13:        Area = BuildRectangeAround(Position)

14:        While(time)

15:            Units = FindFreeUnits(Area)

16:            SendTaskRequest(Units);

17:            UnitsConfirmed[]ßGetConfirmation(Units)

18:            If UnitsConfirmed!=Emplty

19:        AssginTask(UnitsConfirmed[0], TaskQueue[CurrentTask])

20:    Route=FindRoute(GetPosition (UnitsConfirmed[0]), GetPosition(TaskQueue[CurrentTask]))

21:        SendMssage(UnitsConfirmed[0], TaskQueue[CurrentTask] & Route)                    

22:            Else

23:                Area=EnlargeArea(Area)

24:            End if

25:        End While

26:        End While

27:End While

 

            

 

6.2. Required functionality and algorithms

 

Display of maps and display of mobile agents

 

 

The control system pulls the information from the database storage. The roads are displayed using vector graphics and optionally an underlying bitmap (either with a scanned map or with a satellite image) can be displayed. Mobile agents are rendered on a separate layer that is updated periodically.

    Concurrently an internal model is made of the road structure by using directed weighted graphs. The weight of the graph reflects the desirability of the road and takes into account the length of the road, condition of the road, etc.

 

 

Search for a street address on the map

 

 

The names of the streets are stored in a separate table in the database and are linked to the edges. Street numbers are highly irregular and they’re position is only estimated according to the numbering scheme defined.

 

 

The logical structure of the database and the system permits further development in order to precisely define geographical position of the house numbers.

 

Search for mobile agents in a specific area

Searching for mobile agents in a specific area is needed to establish the available mobile agents close to an assignment point.

 

 

    Since position of the mobile agents is stored in UTM coordinates and this corresponds to Cartesian coordinates, it is rather trivial to find agents in a specific area. The position of the assignment is calculated and all agents in a square box of a specified size are considered eligible if their status permits it.

    As describer in the chapter 5.3, this method is implemented using the SQL Query:

 

Table 6.2.1 SQL Query for finding agents within a rectangle

 

 

 

Route mobile agents according to street maps

 

 

The internal model of the maps is organized by using directed weighted graphs. Using the Disjkstra’s single source shortest path algorithm, the most desirable route to the assignment is calculated. Please note that the weights of the edges are calculated by taking into account not only the length of the street so the result is not necessary the shortest path but rather the fastest.

    The implementation of the algorithm is straight-forward. The algorithm works by keeping for each vertex v the cost d[v] of the shortest path found so far between s and v. Initially, this value is 0 for the source vertex s (d[s]=0), and infinity for all other vertices, representing the fact that we do not know any path leading to those vertices (d[v]=∞ for every v in V, except s). When the algorithm finishes, d[v] will be the cost of the shortest path from s to v — or infinity, if no such path exists.

 

The basic operation of Dijkstra’s algorithm is edge relaxation: if there is an edge from u to v, then the shortest known path from s to u (d[u]) can be extended to a path from s to v by adding edge (u,v) at the end. This path will have length d[u]+w(u,v). If this is less than the current d[v], we can replace the current value of d[v] with the new value. Edge relaxation is applied until all values d[v] represent the cost of the shortest path from s to v. The algorithm is organized so that each edge (u,v) is relaxed only once, when d[u] has reached its final value.

 

The notion of “relaxation” comes from an analogy between the estimate of the shortest path and the length of a helical tension spring, which is not designed for compression. Initially, the cost of the shortest path is an overestimate, likened to a stretched out spring. As shorter paths are found, the estimated cost is lowered, and the spring is relaxed. Eventually, the shortest path, if one exists, is found and the spring has been relaxed to its resting length.

 

The algorithm maintains two sets of vertices S and Q. Set S contains all vertices for which we know that the value d[v] is already the cost of the shortest path and set Q contains all other vertices. Set S starts empty, and in each step one vertex is moved from Q to S. This vertex is chosen as the vertex with lowest value of d[u]. When a vertex u is moved to S, the algorithm relaxes every outgoing edge (u,v).

 

 

Table 6.2.2 Dijkstra’s shortest path algorithm in pseudo code

 

An attempt has been made to use the A* algorithm but it did not produce significant improvements in running time. As memory consumption is a concern in large systems, Dijskstra’s algorithm was chosen.

 

 

 

 

 

 

 

 

Transmitting and receiving dispatch commands and status messages to and from mobile agents

 

Although the message transmission is handled by specialized hardware, it is an integral part of the control system. Transmission and receiving of the messages is needed in order to:    

• mobile agents report position in field
• control center reports assignments to mobile agents
• receive or transmit additional information and filed data

 

For easy programming, the control system offloads all communication to a common web server (Apache) running a custom PHP application. The mobile agents act as normal web clients and submit data over standard HTTP protocol. Each mobile client unique identifies himself to the server and the server responds accordingly. Usage of standard HTTP protocol makes the solution independent to the transmission method and easy to implement. However, this method implies that the clients poll the server for new messages.

 

If faster delivery of messages to the client is desired, HTTP protocol may be somehow limiting, especially because it would necessitate implementing an http server on the mobile clients. In this case the implementation of a custom application is desirable. This project implements a client based on push technology.

 

 

Push technology, also called server push, describes an internet-based content delivery system where information is delivered from a central server to a client computer based upon a predefined set of request parameters outlined by the client computer. Illustratively a client computer such as a mobile client receive information provided by a content provider and as that content is created by the control center, such information is “pushed” or delivered across the internet to the mobile client and further interpreted/displayed by the client.

 

 

7. Mobile System

7.1. Implementation alternatives

 

 

The choice of the mobile equipment is a very sensible one since it will be deployed in large numbers and they have a relatively high cost. The speed, ruggedness and ease of handling of the equipment are crucial for the success of the project.

Any choice of equipment must fulfill at least these minimum functionalities:

• GPS Receiver
• GPRS Modem
• Screen and Keyboard

 

For this purpose I have two possible solutions:

• PDA with GPS and GPRS
• Custom computer with GPS and GPRS

 

In our prototype implementation we use a PDA with GPS and GPRS.

 

Table 7.1.1 Mobile System Functioning in pseudo code

 

1: while(true)

2:    Currentposition=GetPositionfromGPS(0);

3:    If DistanceinMeters(OldPosition, Currentposition) > 20 OR CurrentTime-LastMessageTime > 5

4:        RTCMCorrection=RequestRTCM()

5:        Currentposition= GetPositionfromGPS(RTCMCorrection)

6:        SendMessagetoCCCenter(MyId, Currentposition)

7:        Oldposition=Currentposition

8:        LastMessageTime=Now()    

9:    end if

10:    WaitforTasks()

11:    if TaskAvailable()

12:        Display(TaskName, TaskPosition)

13:        WaitForOk()

14:        If TaskAccepted()

15:            confirm = SendMessagetoCCCenter(MyID, TaskID)

16:            If confirm

17:                GetDetails(TaskID)

18:            End if

19:        End If

20:    End If

21: End While

 

PDA with GPS and GPRS

 

Recent advances in technology have permitted the integration of a GPS receiver and a GPRS modem into a PDA. Such a PDA is the HP hw6510. This equipment lends itself ideally for this kind of project. It’s advantages are:

 

• excellent integration
• superb touch screen
• easy programming environment (WindowsCE Platform)

 

The drawbacks of this solution are:

• high cost (500€/unit)
• relative low ruggedness
• average performance GPS (no WAAS support, no RTCM)
• average processor performance
• no real expansion possibilities (supports serial attaced devices)

 

 

 

7.2. Enhancements

 

The best part of a custom mobile equipment is that it can be extended to accommodate specific applications.

 

Accelerometer

 

An accelerometer can be attached to the board in order to provide additional navigational information and mainly it can be use to detect crashes or significant shocks.

 

OBD Interface

 

 

An OBD (On Board Diagnostics) interface can link the Mobile equipment to the computers car. This way live diagnostic data can be read from the car computer and sent to the Control center. If desired, the control center can send command sentences to the car’s computer using standard ODB sentences.

 

7.3. Low cost alternative

 

 

 

The development of a custom computer with GPS and GPRS support would be almost impossible without a prebuilt module that handles GSM communication and GPS signal decoding. Such a board is the Siemens XT55. For additional logic (keyboard, screen and protocol handling) any general purpose processor can be used. The communication to the XT55 board is made via serial interface. This solution has several advantages:

 

• cheap (about 200€/unit)
• excellent GPS performance (SiRF Star 3 chipset, WAAS/EGNOS support, RTCM)
• high ruggedness
• excellent extension possibilities

 

 

The downsides of this solution are the high development costs and custom programming necessities. Also, if not manufactured in large numbers this is not really an option.

 

8. Prototype Implementation for Taxi fleet control

 

The system as it has been described until now can lend itself ideally to the control of a taxi fleet. Each car in the taxi fleet can carry onboard mobile equipment. If a taxi request is received, the dispatchers at the command and control center can always notify the taxis in close proximity. The taxi driver must confirm the acceptance of the command and proceed to pick up the client.

 

Further, if a large taxi fleet is deployed in the city, the command center has up to date relevant traffic information and can guide the taxi on the fastest route to the destination (taking into account both the length of the road but also external factors affecting traffic).

 

 

As seen in the schematic overview above, a taxi fleet control exploits all aspects of the system described in this paper.

The internal schematic of the operating center is depicted in fig 8.1.3.

 

 

 

The separation of functionalities is designed to allow the system to perform at maximum speed but also to provide the possibilities of monitoring all aspects of the system’s functionality. In this layout it is very easy to operate a hardware upgrade if a speed increase is desired. By monitoring all aspects of the system, problems in the system and also bottlenecks can be quickly identified.

 

In the initial tests it has been discovered that the system can greatly improve operating speed of the dispatcher. As with a classical setup (analogue radio communication) the bottleneck was always finding the appropriate taxi in the area, the automatic vehicle locating speeds up the process to the point where the bottleneck becomes the communication with the client over the phone line. To address this issue, a special program has been developed for the control center phone operator.

 

Phone operator software

 

The phone operator software receives caller-id from the control center’s PBX system. As caller id can be directly linked to caller’s address, the process of fetching a suitable taxi can begin from the first ring of the client. This dramatically improves operating speed of the control center and lowers the load on the operators.

 

 

 

8.1 Monitoring and crash reporting system

 

The monitoring and crash reporting system is an extended vehicle tracking system. Vehicle tracking systems have their roots in the shipping industry. Corporations with large fleets of vehicles required some sort of system to determine where each vehicle was at any given time. Vehicle tracking systems can now also be found in consumers vehicles as a theft prevention and retrieval device. Police can simply follow the signal emitted by the tracking system and locate the stolen vehicle.

 

The Vehicle Tracking System enables vehicle owners or third parties to track the location of a vehicle. Vehicle information can be viewed on electronic maps via the Internet or specialized software.

 

Vehicle Tracking Systems are commonly used by fleet operators for fleet management functions such as routing, dispatch, onboard information and security. Other applications include monitoring driving behavior, such as an employer of an employee, or a parent with a teen driver. Our extended system can provide additional information regarding vehicle usage (via an OBD link) or alarm in case of crashes (using an accelerometer).

 

Vehicle tracking systems are also popular in consumer vehicles as a theft prevention and retrieval device. Police can simply follow the signal emitted by the tracking system and locate the stolen vehicle. When used as a security system, a Vehicle Tracking System may serve as either an addition to or replacement for a traditional Car alarm.

 

The Vehicle Tracking Systems integrates several security systems, for example by sending an automatic alert to a phone or email if an alarm is triggered or the vehicle is moved without authorization or if they step outside a predefined geographical boundary.

 

 

 

The vehicle tracking system can act either active or passive. Passive functionality simply store GPS location, speed, heading and perhaps key on/off, door open/closed. Once the vehicle returns to a pre-determined point, the device can be removed and the data downloaded to a computer for evaluation. Active mode also collects the same information but can transmit the data in real-time via cellular network to a computer or data center for evaluation.

 

For the vehicle tracking system (where no data is sent from the command center to the mobile agents) Google Earth can be used as a monitoring program. Google Earth is free and supports a wealth of data overlays. The data overlay maps can be generated by the command and control center server and rendered locally by any client computer with Google Earth installed. Google Earth offers reasonable resolution images and accurate maps (currently only Western Europe) and a very well designed user interface.

 

 

The data overlays are specified in the KML format.

 

KML, or Keyhole Markup Language, is an XML grammar and file format for modeling and storing geographic features such as points, lines, images, and polygons for display in Google Earth. In KML it is possible to:

 

• Specify icons and labels to identify locations on the planet surface
• Create different camera positions to define unique views for each of your features
• Use image overlays attached to the ground or screen
• Define styles to specify feature appearance
• Write HTML descriptions of features—including hyperlinks and embedded images
• Use folders for hierarchical grouping of features
• Dynamically fetch and update KML files from remote or local network locations
• Deliver current view details from the client to the server in order to fetch KML data based on changes in the 3D viewer

 

A KML file is processed by Google Earth in a similar way that HTML (and indeed, XML) files are processed by web browsers. Like HTML, KML has a tag-based structure with names and attributes used for specific display purposes. Thus, Google Earth acts as a browser of KML files.

 

 

 

9. Conclusions

    

    This paper presents the theoretical foundations as well as prototype implementation for a car fleet monitoring and control system. Every car in the fleet carries mobile equipment with GPS capabilities and GPRS modem, as well as a display and keyboard for user interaction. The mobile equipment periodically reports its position to a command and control center. The command and control center receives assignments from third parties displaced in the field and can dispatch any car that is close to the assignment.

    This type of solution is ideal for controlling large car fleets such as taxis, as it is detailed towards the end of this paper.

    The prototype implements an original solution for the command and control center including a custom geographical information system suited for the application. Also, the software for the mobile equipment (Windows CE PDA) has been developed.

    Extensive effort has gone into the development of an optimized Geographical Information System and into the research of the GPS system (in order to improve its accuracy).

    Significant research has also been carried out in order to develop a low cost mobile system, based around Siemens XT55 GPS+GPRS module.

 

    This paper has proven that monitoring and controlling a large car fleets using GPS and GPRS certainly is a viable option. While the development process has been a challenge, it opened up a wealth of opportunities that guarantee future developments such as:

 

• data collected from the mobile equipments can significantly aid urban traffic optimization
• online sensors can be installed to monitor quality of life parameters (such as air quality)
• accelerometers in combination with a capable command and control center can be used to monitor accidents and dispatch ambulances to crash sites, thus saving lives

 

Additional improvements:

 

• While a HP HW6510 is a capable PDA, it might not be suited for taxi operation due to its rather slow processor (Intel PXA272). A custom platform might provide better service or the MIO A701 (with its 400MHz processor) might provide a viable alternative.
• The GPS system is very sensible to surroundings and can have severe performance degradation in a city. Without augmentation, such as DGPS and course estimation, monitoring can be difficult.

 

 

 

 

10. Bibliography

 

1. C.P. Evans, Development Of A Geospatial Data-Sharing Method For Unmanned Vehicles Based On The Joint Architecture For Unmanned Systems (Jaus) , University of Florida, 2005
2. B. Jaeken, Sensor Guided Application for Precision Irrigation, Master Thesis, Texas AM University, 2002
3. D. Moga, P. Dobra, Smart Sensor Systems, Cluj Napoca, Mediamira 2006
4. Siemens AG, XT55 Siemens Cellular Engine, Siemens 2006
5. SiRF Technology, NMEA Reference Manual, San Jose,2005
6. G. Weber, D. Dettmering, H. Gebhard, Networked Transport of RTCM via Internet Protocol (NTRIP), Bundesamt für Kartographie und Geodäsie, 2005
7. http://www.freegis.org/

 

 

 

 

11. Acronyms

 

 

DGPS – Differential Global Positioning System

EGNOS – European Geostationary Navigation Overlay Service

GPRS – General Packet Radio Service

GPS – Global Positioning System

NMEA – National Marine Electronics Association

NTRIP- Networked Transport of RTCM via Internet Protocol

OBD – On Board Diagnostics

PDA – Personal Digital Assistant

RTCM – Radio Technical Commission for Maritime Services

UTM – Universal Transverse Mercator

WAAS – Wide Area Augmentation System

WGS84 – World Geodetic System 1984

12. Appendix

 

List of common NMEA sentences and their meaning (according to [6]):

 

• RMB

 

$GPRMB,A,x.x,a,c--c,d--d,llll.ll,e,yyyyy.yy,f,g.g,h.h,i.i,j*kk

 

RMB  = Recommended Minimum Navigation Information

 

1    = Data Status (V=navigation receiver warning)

2    = Crosstrack error in nautical miles

3    = Direction to steer (L or R) to correct error

4    = Origin waypoint ID#

5    = Destination waypoint ID#

6    = Destination waypoint latitude

7    = N or S

8    = Destination waypoint longitude

9    = E or W

10   = Range to destination in nautical miles

11   = Bearing to destination, degrees True

12   = Destination closing velocity in knots

13   = Arrival status; (A=entered or perpendicular passed)

14   = Checksum

 

• RMC

$GPRMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,ddmmyy,x.x,a*hh

 

RMC  = Recommended Minimum Specific GPS/TRANSIT Data

 

1    = UTC of position fix

2    = Data status (V=navigation receiver warning)

3    = Latitude of fix

4    = N or S

5    = Longitude of fix

6    = E or W

7    = Speed over ground in knots

8    = Track made good in degrees True

9    = UT date

10   = Magnetic variation degrees (Easterly var. subtracts from true course)

11   = E or W

12   = Checksum

 

• GGA

$GPGGA,hhmmss.ss,llll.ll,a,yyyyy.yy,a,x,xx,x.x,x.x,M,x.x,M,x.x,xxxx*hh

 

GGA  = Global Positioning System Fix Data

 

1    = UTC of Position

2    = Latitude

3    = N or S

4    = Longitude

5    = E or W

6    = GPS quality indicator (0=invalid; 1=GPS fix; 2=Diff. GPS fix)

7    = Number of satellites in use [not those in view]

8    = Horizontal dilution of position

9    = Antenna altitude above/below mean sea level (geoid)

10   = Meters  (Antenna height unit)

11   = Geoidal separation (Diff. between WGS-84 earth ellipsoid and

       mean sea level.  -=geoid is below WGS-84 ellipsoid)

12   = Meters  (Units of geoidal separation)

13   = Age in seconds since last update from diff. reference station

14   = Diff. reference station ID#

15   = Checksum

 

• VTG

$GPVTG,t,T,,,s.ss,N,s.ss,K*hh

 

VTG  = Actual track made good and speed over ground

 

1    = Track made good

2    = Fixed text 'T' indicates that track made good is relative to true north

3    = not used

4    = not used

5    = Speed over ground in knots

6    = Fixed text 'N' indicates that speed over ground in in knots

7    = Speed over ground in kilometers/hour

8    = Fixed text 'K' indicates that speed over ground is in kilometers/hour

9    = Checksum

 

• RMA

$GPRMA,A,llll.ll,N,lllll.ll,W,,,ss.s,ccc,vv.v,W*hh

 

RMA  = Navigation data from present position

 

1    = Data status 

2    = Latitude

3    = N/S

4    = longitude

5    = W/E

6    = not used

7    = not used

8    = Speed over ground in knots

9    = Course over ground

10   = Variation

11   = Direction of variation E/W

12   = Checksum

 

• GSA

$GPGSA,A,3,19,28,14,18,27,22,31,39,,,,,1.7,1.0,1.3*35

 

GSA  = GPS receiver operating mode, SVs used for navigation, and DOP values.

 

1    = Mode:

       M=Manual, forced to operate in 2D or 3D

       A=Automatic, 3D/2D

2    = Mode:

       1=Fix not available

       2=2D

       3=3D

3-14 = IDs of SVs used in position fix (null for unused fields)

15   = PDOP

16   = HDOP

17   = VDOP

 

• GSV

$GPGSV,4,1,13,02,02,213,,03,-3,000,,11,00,121,,14,13,172,05*67

GSV  = Number of SVs in view, PRN numbers, elevation, azimuth & SNR values.

1    = Total number of messages of this type in this cycle
2    = Message number
3    = Total number of SVs in view
4    = SV PRN number
5    = Elevation in degrees, 90 maximum
6    = Azimuth, degrees from true north, 000 to 359
7    = SNR, 00-99 dB (null when not tracking)
8-11 = Information about second SV, same as field 4-7
12-15= Information about third SV, same as field 4-7
16-19= Information about fourth SV, same as field 4-7