At present, data from Global Navigation Satellite Systems (GNSS) such as GPS and GLONASS are being streamed over the Internet from receivers at base stations all over the globe. Anyone can receive many of these streams for free. While the quality and availability of the service at any given time is not always guaranteed, many streams have good data available most of the time. Whether their subscription is free or for a fee, the data streams can help a great diversity of users find their precise position in real time. The applications range from land surveys to real-time remote sensing requiring precise navigation to interpret the sensor data. Moreover, by getting free data in real time from many different places in the world, developers now have at their disposal a world-wide test bed for trying out and validating their ideas and products, using data from a variety of receivers and places gathered under quite different reception conditions.

Central to all this has been the adoption of a common standard protocol for transmitting GNSS data over the Internet, known as NTRIP, and to the gradual appearance of a decentralized, world-wide network of stations, servers and broadcasters (or “casters”) that use NTRIP to distribute hundreds of streams to thousands of users.

While real-time GNSS positioning of fixed and moving receivers is a success story, one important old problem remains. In the case of wide-are (or long-baseline) positioning, it can take a long time before the solution becomes very precise, be it at the start of a session or, sometimes, after a restart following a break caused by poor reception, insufficient data, or some other serious problem. This delay is known as the solution convergence period. There are several ways to shorten it and speed things up, but none has yet been found for wide-area applications that is as fast, reliable, and effective as the resolution of ambiguities on the fly is in short-baseline solutions (with less than 20 km between base station and rover).

Finally, as shown here with an example, processing off-line (or post processing) the data, is intrinsically more precise than real-time processing, because with the former one uses all the data collected during a session, while with the latter one uses only the data collected from the start of the session up to the present. It is also more forgiving, and hence more reliable, because the analysis can be repeated if something goes wrong the first time. Users must decide whether to use real time or post processing based on their true needs.

For those interested in reading more about these topics, there is a list of references at the end.

Some definitions:

Precise Positioning: Here, it means finding the position of fixed GPS receivers within centimeters of their true fixed positions, and of moving receivers within 20 cm or less of their true instantaneous positions.

Wide-Area RTK: Precise, real-time kinematic positioning of receivers supported by networks of stations with GNSS receivers that cover very large areas, with all stations separated by hundreds of kilometers. This includes both differential and point-positioning navigation. Only dual-frequency receivers are used.

Figure 1. BKG’s map of world-wide sources of NTRIP streams, as of 11 September 2008. Not all streams are publicly available. The number of sites has been growing steadily and at a fast pace, for several years.

Figure 2. Stations used for the “Iberian Test”, showing the inter-site distances. Blue stars: EUREF stations (reference sites); red star: a station of the regional ITACyL network (“rover”).

Positioning and the Internet

During the last twenty years, the dissemination over the Internet of GPS (and, more recently, of GLONASS) data has progressed gradually but steadily. It started in a significant way with the exchange of data among research organizations that, beginning in the early ’90s — helped by technical advances and favorable international political changes — gradually joined what is today the International GNSS Service (IGS). One result of this has been the creation of common data archives, such as that of NASA’s Crustal Dynamics Data Information System (the CDDIS; http://cddisa.gsfc.nasa.gov/gnss_datasum.html). In there, anyone can find and download by anonymous FTP the data deposited by many IGS stations around the world, as recently as a few hours ago, and going back for many years. As well as receiver data, one can download files with such products as the IGS ultra rapid, rapid, and final orbits, and similar products from the individual IGS Associate Centers.

In the late ’80s and in the ’90s, in several countries, national networks of Continuously Operating Reference Stations (CORS) were set up by government mapping agencies to provide surveyors and other users with reference receiver data that they could download from the Internet for free, and use to make differential solutions by combining them with data from their own receivers. At the time, these services supported only off-line differential positioning.

n the late 90’s, studies by researchers associated with the IGS demonstrated the definite possibility of using precise point positioning (PPP) techniques to get results with user data from a single receiver, if precise GPS orbits and satellite clock corrections were also available. As a result, now such products are distributed not only after a few days (the “final” IGS orbits and clocks), but also in near-real time (the IGS’ “rapid” orbits and clocks).

In early May of 2000, the US government eliminated the Selected Availability (SA) of GPS, an intentional degradation of the precise timing provided by the GPS atomic clocks that could be corrected only by having special chips in the receivers. Those chips had to be issued and used under strict security arrangements that made it available only to those with US government’s clearance, and was very inconvenient even to them. With the end of SA began a period fast growth and diversification of real-time and off-line uses of GPS, particularly those involving the very convenient PPP approach, because until then high precision had been limited to differential positioning, which was not directly affected by SA.

Afterwards, for real-time differential positioning, the IGS made available “ultra rapid” orbits, updated every six hours, with predicted satellite positions for the next 24 hours.

Coincidentally, there were also sustained improvements in Internet speed (with more powerful servers, better software, and fiber optics links), in lower-cost, faster personal computers (able to analyze larger data sets in a short time), and in receiver technology (better data). These advances inspired numerous studies and experiments to find out if data could be streamed, reliably and timely, over the Internet; that is: offered in continuous downloads, one epoch’s worth of data after another, so users connected to stream servers could combine them and their own receiver data to do, for example, precise differential positioning in real time.

A very important characteristic of present-day Internet GNSS data streaming is that latency (the delay with which the data are received) is rarely of more than 10 seconds, and very often much less than that. Since SA was ended, it has been possible to predict the values of data still under way but needed now, on the basis of their recently received values, because data from fixed receivers is highly predictable for several seconds.

The principles behind the idea of real-time precise positioning were demonstrated, in the late ’90s, by operators and users of a form of network RTK (for “real-time kinematic”) known as Virtual Reference Station (VRS), where information collected with the GNSS receivers of a network of ground stations is sent to users as corrections to their data, so they can get very precise position in either kinematic or static mode. The transfer of data is made over radio links, using different message formats. For VRS, distances between receivers are usually less than 100 km, which is considerably shorter than for wide-area networks.

All these related developments led to the present situation with the adoption of the standard protocol for data streaming known as NTRIP.

Finally, at the time of this writing, the estimation and streaming in real time of precise satellite clock corrections for use in real-time PPP are being tested within the IGS and elsewhere.

What is NTRIP?

The Network Transport of RTCM over the Internet Protocol (NTRIP) is a communications standard adopted in September of 2004 by The Radio Technical Commission for Maritime Services (RTCM) to transmit data and messages over the Internet in the official formats of this organization: RTCM versions 2.x and 3.0. NTRIP includes a subset of the HTTP control language, and its transmissions use the Transport Control Protocol (TCP), so both start and end points of the connection have some control on the transmission of a message. When some of the packets of bits into which the message is divided are lost, or received with errors, they can be retransmitted. At present, NTRIP version 1.0 is in use, and version 2.0 is being tested. With such a standard in place, it is much easier to communicate with and among sites around the world, because it is like a common language: The same software can be used to receive streams and process their data, no matter where they come from or who sends them.

Infrastructure

Along with the NTRIP protocol, there is a data dissemination infrastructure consisting of station receivers, their servers, casters, and clients, all of which use software compatible with RTCM and NTRIP.

With NTRIP and the related data collection and distribution infrastructure, it is possible to disseminate hundreds of streams simultaneously to thousands of clients distributed all over the world.

NTRIP is used today in a variety of commercial equipment and software applications: Real Time Kinematic (RTK) with base station and rover receivers, PDA’s and mobile phones with integrated GPS receivers, etc. NTRIP data can be streamed over wire, optical fiber, radio link, etc.

As explained in the documentation available at the website of the Bundesamt fuer Kartographie und Geodaesie (BKG, the German Federal Office for Cartography and Geodesy), the NTRIP system consists of four major components:

1. NTRIP Sources of GNSS (GPS, GLONASS) data fed into the system. These are, primarily, the GNSS receivers that provide observations or generate RTK correction data. There are also streams that contain precise orbits and — for now experimentally — satellite clock corrections.
2. NTRIP Servers that read data from an NTRIP Source (e.g., a receiver) and send them to an NTRIP Caster.
3. NTRIP Casters that split incoming data from NTRIP servers, and send them simultaneously to many clients, at their request.
4. NTRIP Clients are the software that stationary and mobile users need to access the streamed GNSS data.

Each client asks for data from NTRIP sources available from one or more NTRIP casters. For this, NTRIP includes a Source Table maintained in each NTRIP caster, describing the content (data rate, RTCM format version, etc) and the Internet ID of any GNSS data stream available through this caster.

Information, documentation, Source Tables, and free NTRIP-related software can be downloaded from BKG. I received the data streams used for the example with the MS Windows version of BKG’s client software BNC Version 1.5 (there are both LINUX and Windows versions).

The map in Figure 1 shows the current locations of many stream sources available through BKG and associated organizations. At the time of this writing, 1 Hz, dual-frequency GPS data are available from many of them. However, there are no guarantees that any particular stream will be available at any given time. This map is updated frequently; looking at a version from one year ago, one would see considerably less sites on it than there are now.

The growth of the NTRIP stations has been very rapid, and continues to be so. The stations belong to various networks run by different, unrelated organizations which have in common the use of NTRIP.

Example: Iberian Test

For this test, four streams of data were used, from the sites shown on the map of Figure 2: three of them (blue stars) were EUREF sites, one in Portugal and two in Spain, used as reference, or network, stations. The fourth site (red star), near Madrid, was the “rover”, and belonged to the ITACyL network run by the Institute of Agricultural Technology of Castilla-Leon, in north-central Spain.
All site coordinates were already known at the 1 cm level of precision. All receivers observed and streamed data at the rate of once per second. During the test, the Madrid site was positioned kinematically in real time, also once per second. The instantaneous position fixes of MDRD were compared to the precisely known position of that site. The test was conducted at the home of the author, using a domestic broad-band Internet connection and a laptop with a 1.7 MHz Intel Centrino CPU and 1 Gb of RAM, running under Windows XP. The real-time navigation software used was “Real-Time IT”, written by the author and based on his post-processing software “IT” (for “Interferometric Translocation”).

Program “BNC”, the NTRIP client software, previously downloaded from the BKG Web site, was used to connect over the Internet with the EUREF and ITACyL casters, and to request and receive their data streams. The GPS data were converted from NTRIP to RINEX format before processing. Files with recent broadcast orbit and satellite clock information from the GPS Navigation Message, as well as precise orbit information from the latest IGS ultra rapid files, were downloaded, whenever new updates became available, from the CDDIS.

It took, on average, about 0.1s to fully update the navigation filter, which was done once per minute, and 0.01s to compute the instantaneous position, once per second.

Figure 3. Results of the Iberian test: comparison of the known position of the Madrid site with instantaneous, kinematic real-time results.

Convergence Time

The plot of the results of the test, in Figure 3, show an initial period of almost 40 minutes with large initial discrepancies caused by errors in the kinematic solution that gradually subside until they mostly remain below 20 cm in the vertical and 10 cm horizontally. This initial interval is known as the period of convergence of the solution. Depending on the number and distribution across the sky of the satellites observed from the “rover”, and on the amount of noise in the data, particularly in the form of multipath interference, this period could last anywhere between half an hour and one hour and a half. A long convergence time is characteristic of wide-area (long baseline) differential solutions, and also of point-positioning solutions without local network support. This contrasts sharply with the short time needed to fix ambiguities in short-baseline and VRS solutions. The main reason is that, besides the position of the rover, it is necessary to solve also the unknown, real-valued biases (i.e., “floated” ambiguities) in the ionosphere-free combination of the carrier phase, and to estimate the errors in the standard correction for the neutral atmospheric delay. The solution cannot be precise until these unknowns are sufficiently well known, and extracting that knowledge requires most of the information in the data collected during the convergence period.

The length of this period can be a significant practical problem in real time, because any work that depends on knowing precisely the rover’s position cannot begin until the solution has converged. A few basic approaches have been tried in the past to speed up the convergence of real-time kinematic solutions:

1. Fixing ambiguities on the fly with the help of very precise corrections for the ionospheric delay. This, essentially, is how it is done in VRS, but it has been shown to work also, over wide-area networks, using first a locally determined, tomographic model of the ionosphere to help fix relative ambiguities between base stations.
2. Starting or stopping at locations with precisely known coordinates, and using these to constrain the solution.
3. While staying or passing close enough to a network station, resolving the carrier phase ambiguities with any of several effective short-baseline techniques.
4. Using GNSS data averaged over a 2 or 3 minutes to estimate the average position of a floating object. The effect of ordinary waves on the average position is very greatly diminished by using a simple “box-cart” averaging scheme. The vertical movement that remains is a very gradual change in mean sea height due, for example, to the local tide, a fact that can be used to constrain the solution.
5. With a combination of carrier phase and pseudo range, averaged over a number of epochs, resolve first the ambiguity of the wide lane, and then that of the narrow lane, this time using as data the carrier phase ionosphere-free combination. This idea has been used, for many years, in long baseline static surveys and, more recently, in determining orbits of satellites carrying GPS receivers, both problems with naturally strong dynamic constraints on their solutions. Quite recently, several authors have reported significant reductions in convergence time using variants of this approach in both differential and point positioning kinematic solutions that lack such constraints.

Finally, other studies suggest that, once three-frequency signals become available, certain combinations of phases and pseudo ranges might make it possible to resolve ambiguities in as little as 15 minutes.

Real Time or Post Processing?

Figure 4, below, shows results obtained with exactly the same data as those shown in Figure 3. But the period of convergence is nowhere to be seen in the new plot. The reason for this striking difference is that Figure 4 shows the result of post-processing the data. When post-processing, all the data collected during the session influences the position obtained at any given epoch, and not just those measurements made from the start until that epoch. This is obvious for batch least squares, but is equally true for off-line recursive least squares (with Kalman filtering and smoothing). Another advantage is that one can make several trial solutions with the same data, to find the best way to process it. So post processing is intrinsically a more forgiving, reliable and precise approach than real any time technique. With the proper software and some good management, a post-processed solution can be made in a few minutes, soon after the end of the session, with little inconvenience and delay. As with everything else that matters, the choice between real time and post processing should be made taking into account what is really needed and best for the job at hand.

Figure 4. Results of a post-processed solution, obtained with the same data used in the real-time solution.

Note: I presented the test results shown here at ION-GNSS 2008, held in Savannah, Georgia, in September 2008, and they will appear in the proceedings of that conference.

Acknowledgements

The real-time navigation software “IT” has been developed as part of a precise real-time positioning project directed by Alan G. Evans at the NSWC, Dahlgren Division, with help from his colleagues Andrew Sutter and James P. Cunningham.

Thanks go to Georg Weber, from BKG, in Frankfurt, for providing the BNC NTRIP client software, and explaining its use, and Alberto Garcia-Rigo from UPC, in Barcelona, for helping me subscribe to the data streams for the Iberian test. And many thanks to those responsible for the EUREF and Castilla-Leon networks, and NOAA’s NGS test network, for providing free access to their NTRIP data streams, making this study possible.

Further Reading

NTRIP

Gebhard, H., Weber G.: “Networked Transport of RTCM via Internet Protocol,” Design-Protocol-Software, published by Federal Agency for Cartography and Geodesy (BKG), June 2003

Henning, W., “Real Time Positioning and the Role of the NGS”, Presented at the CORS Users Forum, CGSIC-47th Meeting, Fort Worth, September 2007.

“Ntrip Documentation,” “Ntrip Implementation,” both PDF files.

Precise Positioning

Zumberge, J.F., Heflin, M.B., Jefferson, D.C., Watkins, M.M., F.H. Webb, “Precise Point Positioning for the Efficient and Robust Analysis of GPS Datafrom Large Networks,” J. Geophys. Res., 102, 5005-5017, 1997.

Zumberge, F.M., M. M. Watkins, F. H. Webb, “Characteristics and Applications of Precise GPS Clock Solutions Every 30 Seconds,” Navigation, Vol.44, No. 4, pp. 449-456, Winter Issue 1998-1999, December 1998.

Colombo, O.L., “Long-Range Kinematic GPS,” In GPS for Geodesy, P. Teunissen and A. Kleusberg, Editors, Springer Verlag, Lecture Notes in Earth Sciences, 1998.

Kouba, J., P. Heroux, “Precise Point Positioning Using IGS Orbit Products,” GPS Solutions, Vol. 5, No. 2, pp12-28, Fall of 2000.

Convergence Time Problem

Colombo, O. L., Hernandez-Pajares, J. M. Juan, J. Sanz, “Wide-Area, Carrier-Phase Ambiguity Resolution Using a Tomographic Model of The Ionosphere,” Navigation, Vol. 49,No. 1, 61-69, Spring 2002, December 2002.

Colombo, O.L., A.W. Sutter, A.G. Evans, “Evaluation of Precise, Kinematic GPS Point Positioning,” Proceedings ION GNSS 2004, Long Beach, California, September 2004.

Colombo, O.L., Evans, A.G., Ando, M., Tadokoro, K., Sato, K., T. Yamada, “Speeding Up The Estimation Of Floated Ambiguities for Sub-Decimeter Kinematic Positioning at Sea,” Proceedings ION GPS 2001, Salt Lake City, September 2001.

Weber, G., Mervart, L., Lukes, Z., C. Rocken, “Real-time Clock and Orbit Corrections for Improved Point Positioning via NTRIP,” Proceedings of ION GNSS 2007, Fort Worth, September 2007.

Laurichesse, D., Mercier, F., Berthias, J.P., J. Bijac, “Real-Time Zero-Difference Ambiguities Fixing, and Absolute RTK,” Proceedings of IGS GNSS 2008, Savannah, Georgia, September 2008.

Hatch, R. (2006). “A New Three-Frequency, Geometry-Free Technique for Ambiguity Resolution,” Proceedings of ION GNSS 2006, P309-316, 26-29 September, Fort Worth, TX.

Dr. Oscar L. Colombo
GEST/NASA Goddard SFC