Augmentation of low-cost GPS receivers

There are numerous types of GPS receivers in the current international marketplace, ranging from inexpensive, low accuracy handheld devices to expensive, high precision geodetic equipment. By and large, low–cost GPS receivers (whether sold as a plug– in hardware device or as a complete navigation and positioning receiver) have almost assumed mass market status in the consumer electronics industry. Recent advances in micro and wireless technology, reductions in consumer costs, and the apparent growth of the Location Based Services (LBS) industry have somewhat fuelled the need for mobile (information communications and technology) consumers to become “location aware”.

Notwithstanding current levels of maturity in GPS hardware and algorithms, low-cost GPS receivers still suffer from large positioning errors mainly attributable to atmospheric effects, broadcast ephemeris errors, multipath and receiver noise. As a result, they have a limited use in real time applications despite being able to produce positioning and navigation information almost instantaneously. When higher levels of precision and accuracy are required, some form of correction or augmentation must be applied so as to reduce the influence of random and systematic errors on the autonomous positioning solution.

There are a host of augmentation options, in general, that are available for minimising the influence of random and systematic errors in GPS positioning. These include Local Area Augmentation Systems (DGPS, VRS, Network RTK, Pseudolites, US LAAS); Wide Area Augmentation Systems (EGNOS, MSAS, US WAAS, GAGAN); integrated positioning and navigation sensors (gyro, precise clocks, INS, digital compass); various correction algorithms (integrity monitoring, noise filtering, atmospheric modelling, code– carrier phase smoothing, multipath detection); and in the foreseeable future, integrated satellite systems (GPS, Galileo, GLONASS, QZSS). To improve the accuracy of low–cost GPS receivers, the most practicable form of augmentation is via DGPS corrections obtained either from a local broadcasting service or from a nearby reference station. Historically, local area DGPS corrections have been provided through the RTCM protocol over the conventional means of radio transmission.

In recent times, research and development has seen the implementation and analysis of real time Internet based DGPS systems. For instance, the German Federal Agency for Cartography and Geodesy (BKG) together with other partners have developed a dissemination standard called Networked Transport of RTCM via Internet Protocol (NTRIP) for the real time streaming of DGPS or RTK corrections to mobile receivers (Lenz, 2004). Similarly, the Jet Propulsion Laboratory (JPL) has developed a Global Differential GPS (IGDG) system, which facilitates the exchange of corrections to the orbits and clocks of the GPS constellation over the Internet (Muellerschoen et al, 2002). These two developments, together with other independent tests (Gao et al, 2002, Kechine et al, 2003, for example) show that the Internet is able to provide satisfactory levels of accuracy and latency in the dissemination of GPS augmentation information.

In all cases mentioned, the dissemination of corrections is provided over the Internet via constant streaming of data. The purpose of this paper is to examine the XML Web services architecture as an alternative mechanism for exchanging DGPS augmentation information between Continuously Operating Reference Station (CORS) networks and mobile devices over the Internet. The key difference between disseminating data via Internet streaming data and Web services is that the latter requires two–way “request and response” communication. To illustrate the capabilities and performance of an augmentation system based on the Web services architecture, a simple prototype has been developed. The differential positioning technique implemented within the prototype uses the DGPS code range model described by Hofmann–Wellenhof et al (2001). The Web service prototype is consistent with international Internet technology standards established by the Open Geospatial Consortium (OGC) and the World Wide Web Consortium (W3C) and as such, may be accessed and implemented using any standards– compliant software and/or platform.

Principal results from prototype testing confirm that the Web services architecture is a viable option for exchanging GPS augmentation information over the Internet. Tests conducted over peak and off–peak periods using a mobile phone and GPRS show a typical latency of 1–3 seconds in medium– to high–density urban environments. The disadvantages of using the Web services architecture for an Internet based DGPS system relate primarily to the bloat in the message caused from XML tags.

Before the prototype and preliminary test results are discussed in detail, some basic principles concerning Web services and low–cost GPS receivers are outlined.

Web Services

Web services provide a standardised way of interoperating between different software applications, running on various platforms and/or frameworks distributed on a network or over the internet. In particular, a Web service is a piece of application logic residing at a specific network location (or network address) that is accessible to programs via standard internet protocols. When called, a Web service performs one or more functional tasks and then sends a response back to the calling agent. During the process, a Web service may call other Web services and/or run other software applications. The response may be in the form of an entire data set such as a map, a database entry, or simply the result of a computation.

Web services use standardised protocols (i.e. OGC, W3C) so that raw data can be exchanged between operating systems and software components, whether compatible or not, in a platform independent way. The key to the success of Web service interoperability therefore, is in the implementation of open standards for data encoding, communication and transport protocols. The interoperability stack shown in Figure 1 illustrates the standards based enabling technologies upon which Web services are implemented and deployed.

Universal Discovery Description and Integration (UDDI) enables the publishing of services in a directory (similar in concept to the yellow pages), making it possible for other developers to locate and consume a Web service. A Web service’s interface is described using Web Service Description Language (WSDL). Simple Object Access Protocol (SOAP) is a standardised, lightweight protocol for connecting service endpoints distributed over network environment.

Formats for data encoding are described in a schema language such as XML Schema (XSD) or Document Type Definition (DTD). HyperText Transfer Protocol (HTTP) and Transmission Control Protocol/Internet Protocol (TCP/IP) permit the connectivity between software components and Web services by enabling them to send and receive messages. The lifecycle of a Web service request and response is shown in Figure 2.

The Web service lifecycle is based on the concept of bind–once, consume–
many. Thus, once a Web service has been located (2) and software written
to consume it according to its interface description (3), the software sends a request (4) to a Web service and waits for a response (5) synchronously or asynchronously. Steps (4) and (5) are repeated as many times as required. For every request, raw data is serialized (or encoded) into XML format and bound in a SOAP envelope, which in turn is conveyed over the Internet (or network) using HTTP and TCP/IP.

Low–Cost GPS receivers

For the purposes of this paper, low–cost GPS receivers are regarded as those typically used for general purpose positioning and navigation, low accuracy data capture, reconnaissance, bushwalking, marine and in–car navigation, and the like. With an unobstructed sky, low–cost GPS receivers have an expected horizontal and vertical positioning precision in the range of ±10–20 metres and ±20–30 metres respectively. After applying local DGPS corrections, many spatially correlated (or systematic) errors can be removed and hence, it is not unreasonable to expect some low–cost GPS receivers to achieve a horizontal positioning accuracy better than 5 metres.

A practicable means for augmenting low–cost GPS receivers using the Web
services technique is via custom software which is able to read the output GPS measurement information. The low–cost GPS receiver used in this investigation contains a SiRF chipset and outputs GPS information in the SiRF Binary protocol (SiRF, 2004). The SiRF Binary protocol provides an extensive list of input and output messages concerning the original measurements, the positioning and navigation solution, and commands for configuring the GPS chipset. For instance, the SiRF binary protocol supports the output of pseudorange and (integrated) carrier–phase measurements, subframes 1 to 5 of ICD–GPS–200C, receiver clock bias and drift, and various other observation and navigation messages (SiRF, 2004). The SiRF protocol also provides the ability for receivers to be supplied with DGPS corrections from either the US WAAS or broadcasting beacons in RTCM SC–104 format.

Although a (low–cost) SiRF–based receiver has been used for this investigation, it can be shown that any GPS–enabled device (i.e. which outputs time–stamped pseudorange measurements) capable of reaching the Internet can be used to take advantage of a Web services augmentation system.

Prototype for a web services DGPS system

To demonstrate the feasibility of a Web services DGPS system, a simple prototype has been developed. The prototype is comprised of three components: a GPS and Web enabled client (PDA), a server-enabled PC, and a single CORS receiver. Two Web services are hosted on the server ¾ (1) a CORS Web Service for logging the reference station receiver– determined pseudorange corrections and (2) a DGPS Web Service for disseminating those corrections to roving receivers. Accordingly, software has been developed for the PDA to facilitate the request, response and application of DGPS corrections. The architecture of the prototype is given in Figure 3. The specifications of the prototype components developed for this paper are given in Table 1.

CORS Network and Logging software

For the purposes of demonstration, only a single CORS receiver was used for the prototype. The reference station receiver was configured to output a Type 1 RTCM message (Differential DGPS corrections) via a RS232 serial port every second. Software was developed to read the output RTCM messages and in turn send the corrections to the CORS Web service. Figure 4 shows the flow of tasks performed by the reference station software.

Client Software

The client (or mobile device) software has been developed to perform three basic tasks:

1. Obtain the smoothed pseudoranges and position from the SiRF protocol
2. Handle the request and response of differential GPS corrections
3. Apply the pseudorange corrections and display the augmented GPS position To obtain a set of DGPS corrections, GPS time (t) and an approximate position (f, l) are sent to the Web service. Each request is made asynchronously to allow the client to continue operating without waiting for a response. When a response is received, a new position is computed from the corrected pseudoranges. Prior to making a call to the DGPS Web service, the client verifies whether an internet connection has been established. Figure 5 shows the general flow of the prototype client software.

Differential GPS and CORS Web Services

To provide real time DGPS augmentation, the two Web services (hosted on the server) operate independently to facilitate the logging and dissemination of real time corrections. Firstly, when sent by the custom reference station software, the computed pseudorange corrections are logged by the CORS Web service according to the GPS time and satellite ID. Secondly, when and as requested service retrieves the pseudorange corrections based on the GPS time and sends that data to the roving client.

Although the client’s approximate position is sent to the DGPS Web service, it is not used in this prototype. The purpose of sending the client’s position is simply to illustrate that, given an appropriate mathematical model for multi–station interpolation, the DGPS Web service could be extended to provide a set of location– centric pseudorange corrections.