Tag: real-time kinematic

A new method brings together advantages of real-time kinematic (RTK) and precise point positioning (PPP) in a technique that does not require local reference stations, while still providing the the high productivity and accuracy of RTK systems with the extended coverage area of solutions based on global satellite corrections. The real-time centimeter-level accuracy without reference-station infrastructure is suitable for many market segments — and is applicable to multi-GNSS constellations.

 

By Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka

Real-Time eXtended (RTX) positioning is a technology produced by combining a variety of innovative techniques, which together provide users with centimeter-level real-time position accuracy anywhere on or near the Earth’s surface. This new technique is based on the generation and delivery of precise satellite corrections (that is, orbit, clocks, and others) on a global scale, either through a satellite link or the Internet. The innovative aspects of the new solution can be divided into different categories, which directly relate to the areas that have previously limited the provision of global high-accuracy positioning:

• Integer-level ambiguities derivation;
• Real-time, high-accuracy satellite corrections generation;
• Data transmission optimization;
• Positioning technology.

Because of various new aspects of the technique, RTX differs from both differential RTK and precise point positioning as currently understood by the general GNSS community.

System Overview

RTX technology is used to provide centimeter-level GNSS positioning through the CenterPoint RTX service. Figure 1 shows the general infrastructure of the system.

 

Data from monitoring stations distributed around the globe are collected and transmitted via the Internet to operation centers at different locations. The complete operation centers (enclosed by the red dashed square) are redundant in order to assure the very high (~100 percent) availability of the system. In case it is needed, the correction stream source might change between operation centers and/or processing servers within centers. These operational changes are handled in a deterministic way by all parts of the system including the user receiver. Inside the operation centers, redundant communication servers relay the network observation data to the data processing servers, which host the network processors that produce precise orbit, clock, and observation biases valid for any place on the globe.

After being generated, the precise satellite data are compressed in messages compliant with the CMRx format, specially developed for compact transmission of satellite information. The messages are finally routed to either a satellite uplink station or made available for Internet connection access by the users.

The CenterPoint RTX tracking network currently consists of around 100 stations, distributed across the globe, as shown in Figure 2. The CenterPoint RTX service is currently offered in North and South America, via satellite link, as indicated in Figure 3. Today the CenterPoint RTX service has been made available globally for all those with Internet access.

Limiting Factors

To understand the limiting factors associated with global high-accuracy positioning, it is helpful to consider the simplified basic GNSS observation equations for carrier-phase and code measurements:

Φi=ρ+c(dT−dt)+T−Ii+λi Ni,
+Ai−ai+λi(WΦ−wΦ)+BΦ,i−bΦ,i+MΦ,i+nΦ,i
and
Pi=ρ+c(dT−dt)+T+Ii,
+Ai−ai+BP,i−bP,i+MP,i+nP,i

where:

Φi    is the carrier-phase measurement for frequency i in meters;
ρ    is the geometric distance between the antennas of the receiver and satellite in meters;
c    is the speed of light constant in meters per second;
dT    is the receiver clock error in seconds;
dt    is the satellite clock error in meters per second;
T    is the slant neutral atmosphere delay in meters;
Ii    is the ionospheric delay for frequency i in meters;
λi    is the carrier-phase wavelength for frequency i in meters;
Ni    is the integer carrier-phase ambiguity for frequency i in cycles;
Ai    is the combined receiver antenna offset and directional variation correction for frequency i in meters;
ai    is the combined satellite antenna offset and directional variation correction for frequency i in meters;
WΦ    is the receiver antenna phase wind-up effect, in cycles;
wΦ    is the satellite antenna phase wind-up effect, in cycles;
BΦ,i    is the carrier-phase receiver bias for frequency i in meters;
bΦ,i    is the carrier-phase satellite bias for frequency i in meters;
MΦ,i    is the carrier-phase multipath for frequency i in meters;
nΦ,i    is the carrier-phase observation noise and other un-modeled effects for frequency i in meters;
Pi    is the pseudorange measurement for frequency i in meters;
BP,i    is the pseudorange receiver bias for frequency i in meters;
bP,i    is the pseudorange satellite bias for frequency i in meters;
MP,i    is the pseudorange multipath for frequency i in meters;
nP,i    is the pseudorange observation noise and other un-modeled effects for frequency i in meters.

The feasibility of high-accuracy absolute positioning relies on the assumption that phase and code measurements on the different frequencies or on specific observation combinations are modeled quite reliably. This ultimately means that the parameters (or certain combination of them) of the two equations given are known very precisely, that is, with an accuracy of better than a few centimeters.

Having a global system where every component of the un-differenced GNSS observational model is well known requires advanced understanding and modeling of the involved GNSS-related effects. This is a general achievement of the RTX system.

(An extensive section here, encompassing satellite orbits and clocks, receiver clock error, antenna phase center odeling, phase wind-up effects, neutral atmosphere delay, and ionospheric delay, appears in the online version of this article, at env-gpsworld-integration.kinsta.cloud/rtx.)

Real-Time Network Processing

As previously stated, the RTX system works based on precise satellite information generated at processing centers and broadcast to users. The precise information employed by the systems comprises satellite orbits, satellite clocks, satellite biases, and other auxiliary information.

The requirements for the satellite orbits to be used in the global RTX system can be summarized as accuracy, continuity, robustness, and reliability. The satellite positions have to be accurate for obvious reasons, including the fact that orbit errors have direct impact on rover-position determination quality. Furthermore, because the RTX network process algorithms use ambiguity resolution, the reliability of the ambiguity determination is highly affected by the satellite orbits quality due to the distances between reference stations in the tracking network. The continuity requirement is put in place to avoid the need of handling observation modeling inconsistency over time for both network and rover processing.

For the same reason, the overall system employs techniques to properly handle switches between redundant orbit-processing servers without degradation of position quality. As one would expect, network processors have to be, in general, robust against the eventuality of poor data entering the system for various reasons. The RTX network processors employ a variety of quality-control techniques to ensure that only data with the highest expected quality is used for the computation of end products.

Finally, reliability is a very important factor for real-time orbit processing. At the current stage, the RTX real-time orbit processors are able to run for several months with virtually zero intervention from operators, while handling events such as satellites going through unhealthy periods and satellite maneuvers (during unhealthy period or not).

There are at least two strong reasons for justifying the need of implementing and running an RTX proprietary orbit processing server. The first one is simply the need of reliably meeting the above-mentioned requirements. The second one is that from an operational perspective, the RTX system is conceived in such a way that it does not rely on any external source of information to run at its full accuracy capability. Figure 4 shows the achieved orbit errors provided by IGS ultra-rapid products during two weeks of March 2011, where IGS rapid orbit products are used as truth. The ultra-rapid orbits are evaluated using the initial portion of the predicted arc, thus making use of the most reliable part of the predicted arcs as the products become available in real-time. In that case, neither accuracy nor continuity requirements for RTX processing are completely met.

Orbit Estimation. The orbit estimation in the CenterPoint RTX system is based on a combination of a UD-factorized Kalman filter estimating satellite position, satellite velocity, troposphere states, integer ambiguities, solar radiation pressure parameters, harmonic coefficients, and Earth-orientation parameters. The prediction step in the filter uses a numerical integration of the equations of motion in connection with a dynamic force modeling. Forces considered in the approach are: the Earth’s gravity field, lunar and solar direct tides, solar radiation pressure, solid earth tides, ocean tides, and general relativity.

In RTX orbit processing carrier phase integer ambiguities are resolved in real-time. Also, the satellite orbit states are truly estimated in real-time and continuously adapted over time to better represent the current reality. This means that the satellite positions that are evaluated by the user have prediction times of no more than a few minutes since the last orbit processing filtering update, providing negligible loss of accuracy. Figure 5 shows the orbit errors obtained from the RTX orbit processor. Similarly to the previous figure, IGS rapid orbit products are used as reference. The time span is also the same as in the previous figure. The RTX real-time orbit components have a typical overall accuracy of around 2.5 centimeters (cm), and a 3D error accuracy of around 4 cm, considering IGS rapid products as truth.

Clock Estimation. Satellite clock estimation forms an essential part of the RTX system. It plays a fundamental role on positioning performance due to a number of reasons. Satellite clocks map directly into line-of-sight observation modeling, yielding into a one-to-one error impact from clocks into GNSS observables modeling. Due to the same strong relationship, it is of fundamental importance that clocks are generated in a way to facilitate ambiguity resolution within the positioning engine. The processing speed of a clock processor is also of critical importance, due to the fact that any delay in computing satellite clocks is directly translated into correction latencies when computing real-time positions on the rover side. For that matter, one should keep in mind that regardless how late satellite corrections get to the GNSS receiver in the field, positions have to be provided to the user as soon as the rover GNSS measurements are available. Therefore latencies typically introduce errors into the final real-time position. In this article, we define real-time positioning as the computation of positions at the time when the rover observables are available, regardless of the latency of the correction stream. This is a necessary concept in order to support dynamic rover GNSS positioning.

The RTX clock network processor was designed around the requirements discussed earlier. It computes clocks that are compatible with ambiguity resolution on the user receiver. As a matter of fact, the clock network processor itself employs ambiguity resolution for the generation of the RTX clocks. The processor architecture is based on an innovative design that allows processing data of several hundreds of reference stations, including all necessary steps such as data quality control, ambiguity resolution, and the final clock generation, within a fraction of second. The processing time of this kind of real-time network processor has to be minimized as much as possible in order to allow the processor to operate at 1 Hz, and to minimize the final correction latency at the rover end. Note that the final latency of the correction stream is a composition of three basic components: the time for the network data to arrive at the network processing server; the network processing time; and the correction transmission time to reach the final user. Figure 6 shows the typical total correction latency for the RTX system, when corrections are broadcast through a satellite link.

Unlike satellite orbits, satellite clock solutions are more difficult to compare directly. This is because different clock solutions might have offsets between each other, as well as behave differently due to differences in their GNSS reference time realization process as well as in their observation modeling approaches. That said, one way of verifying the quality of satellite clocks is to quantify how well it can be used to model actual receiver observation data. This can be in general achieved by applying satellite orbit and clock correction onto GNSS data and verifying the remaining residuals. Other quantities such as receiver coordinates have to hold their correct values for the residuals to be meaningful. In this case, the combined satellite orbit and clock error are assessed, and not just the satellite clock alone. For our purposes this is perfectly fine, since this is the way orbits and clocks are employed in rover positioning as well. Figures 7 and 8 show typical combined satellite orbit and clock errors at line-of-sight for different satellites. Figure 7 shows the ionospheric-free phase modeling error for GPS satellites, while Figure 8 is for GLONASS. Note that observations of a reference satellite (highest elevation at the time of observation) were reduced from the others. This was done in order to remove the receiver clock errors from the residuals. For both GPS and GLONASS cases, the observation modeling error after using RTX orbit and clock corrections is on average at the 1 cm level, with values typically less than 2 cm. The GPS satellite with outlying behavior in the plot below was setting at that time, and the increased amplitude of the residuals is mostly due to receiver observation errors such as multipath.

 

Communication and Positioning

Once all satellite information is available, it must be compressed in a message that can be broadcast to the user in the field. The transmission of global corrections can be done in different ways, such as via Internet, in case the user has access to it, or using a satellite link. In the latter it is customary that corrections sufficient to cover the transmission satellite footprint are broadcast, rather than corrections complete enough to cover the globe. Firstly, because it is expected that users operating inside the satellite footprint will use the corrections only for that region, and secondly because bandwidth restrictions usually play a role in message design for satellite-based communication. The bandwidth restrictions not only enforce maximum bandwidth utilization below a certain limit, but also require that the utilization over time is homogeneous to ensure optimal usage of the satellite channel.

Furthermore, satellite signals are typically susceptible to frequent message-packet losses depending on the user environment, such as when a receiver is running under canopy. To mitigate packet losses, the message must be built in such a way as to allow the rover to continue operations with minimum loss of availability. In that case not only the message design has to foresee this type of situation, but also the message decoding, usage, and positioning algorithms have to be optimized to most favorably couple with the received messages. All these factors have been taken into account in RTX system communication design. A new message format was created to carry information on satellite orbits, clocks, observation biases, and other auxiliary information. The new RTX CMRx satellite messages deliver 1-millimeter resolution for satellite orbits and clocks.

The RTX positioning engine inherits several technological aspects from Trimble’s pre-existing RTK engine. This aspect makes the RTX positioning mode, and traditional RTK positioning modes (for example, single base, virtual reference station) easy to co-exist. Among other things, the new engine has been thoroughly tested and optimized for challenging tracking environments. In these scenarios the engine is presented with observation data collected with a high level of multipath and low signal-to-noise ratio, often producing cycle slips and gaps in the data. As previously mentioned, at the same time the correction stream also suffers packet losses and the correction data might not be completely available during certain masking conditions.

Positioning Performance. The RTX engine delivers typical final accuracies at 1–2 cm level for horizontal positioning, and 2–4 cm for vertical, 1-sigma. The final convergence of the system is achieved in 10 to 45 minutes after receiver startup. The time to converge might depend on several aspects, including satellite geometry and multipath conditions.

To overcome the increased convergence time as compared to traditional RTK systems, a number of features have been implemented as part of the RTX positioning engine, two of which are worthy of mention here. The Fast Restart feature allows users to power up or place the receiver at a known location and immediately obtain a converged solution. This is also applicable when users have not moved their equipment since the last RTX solution. This feature is quite valuable in agriculture applications, where the user typically does not move the tractor between RTX-steered field work activities, thus avoiding in the majority of cases the need to wait through a new convergence period before starting work, one or more days after the last system usage.

The second feature is also related to avoiding system re-convergence. The Bridging feature, an outage recovery capability, enables the RTX positioning engine to immediately recover from a complete constellation outage with loss-of-lock during any dynamic activity. This prevents the system from entering a new convergence phase in case the receiver loses track of up to all satellites in view, coupled with outages of up to a couple of minutes, such as when running behind a tree line, or under a bridge.

Accuracy

Horizontal position error obtained in real time in a receiver acquiring the RTX correction data through the satellite link in North America is shown in Figure 9. The receiver was running continuously for several days, and was located in Ames, Iowa. As displayed, the horizontal RMS was 1.4 cm, with a 95 percent horizontal error of 2.4 cm. These are typical values for satellite-based RTX horizontal performance.

Figure 10 shows the vertical performance for the same receiver and time period: the vertical RMS was 2.8 cm, with 95 percent vertical error of 4.4 cm.

Time to Achieve Convergence. Convergence is directly connected to the level of productivity that can be achieved for actual field applications. In the following example a continuously powered RTX receiver was used to show an assessment of the RTX (re-)convergence capability. The receiver’s tracking of all satellites was disabled every hour by an antenna switch. Each outage lasted three minutes, during which times no GNSS satellites were tracked.

This procedure was repeated hourly for several days in order to gather enough performance runs to derive meaningful statistics. Figure 11 shows the resulting performance of this assessment. The standard cold-start re-convergence performance is indicated with blue lines, where the solid lines represent 90-percent performance and the dashed line represents 68-percent performance.

As the figure shows, the RTX system converged to better than 5 cm horizontal error after 20 and 25 minutes for 68 percent and 90 percent of the runs, respectively. Convergence time is correlated with a number of aspects, including satellite geometry and multipath environment. Because of these variations, the claimed RTX convergence time is between 10 and 45 minutes for full accuracy achievement.

The red lines in Figure 11 indicate performance obtained with a second receiver, connected to the same antenna, and thus subject to the exactly same GNSS signal outages. This second receiver had the Bridging functionality enabled, and thus is expected to bridge the outages and phase cycle slips without resetting the positioning solution. The red lines confirm that the desired behavior is achieved. To better visualize what happens over time in this case, Figure 12 shows a few hours of the real-time results obtained with the receiver running with the Bridging functionality activated.

Figure 13 gives an example of Internet protocol (IP)-based RTX performance. This is a single run where the system converged to better than 5 cm (horizontal) in approximately 15 minutes. Figure 14 shows how the L1 ambiguities of individual satellites in view during that time converged.

In these two plots, positioning convergence is, as expected, highly correlated with the ambiguities convergence to their final integer values in cycles. Note that satellites that come in after the overall solution is converged (for example, in light blue) achieve their final ambiguity values much quicker than during the position convergence phase, also as expected. The proprietary algorithms used for ambiguity resolution and validation in RTX allow the ambiguities to reliably converge to their integer values. Arbitrary integer number of cycles have been removed from the original ambiguity values to allow better simultaneous visualization of the ambiguities for several satellites.

Optimizing the RTX system to work under different scenarios was necessary because the multipath and signal availability levels are reasonably different between running an antenna with a reference station setup and the actual user environment, where the data tracking conditions impose additional challenges on making high-accuracy positioning effective on a global basis, in a productive manner. Therefore, an extensive field test campaign was conducted during the pre-release phase of the RTX system. The next example shows RTX in-field performance for an precision agriculture application in Illinois. The setup is typical for agricultural use, with the antenna and receiver mounted on a tractor that ran for about 103 minutes. Figure 15 shows theactual track of the tractor; RTX corrections were received via satellite link.

The horizontal positioning performance for that field test can be seen Figure 16. The overall 2D RMS was 2.3 cm and the 95 percent horizontal error was 4.2 cm. Note that this position difference plot is between the RTX solution and a short-range single baseline (SBL) RTK solution providing truth. Therefore the numbers and plot actually show a combination of errors between the global RTX solution and the SBL solution to the local reference station.

Nevertheless the error magnitudes achieved lie within the same range as in the previous assessments shown here.

Summary

RTX positioning brings together the advantages of positioning techniques that do not require local reference stations while providing the productivity of RTK positioning. Its deployment introduces innovations in GNSS network processing, as well as advancements in the rover global positioning algorithms.

RTX employs ambiguity resolution on a global scale for both network and rover processing, including GPS and GLONASS satellites in the solution. The delivery of this new technology is achieved through the CenterPoint RTX positioning service, capable of providing world-wide real-time centimeter-level accuracy without the direct use of a reference station infrastructure.

A longer version of this article was presented at the 2011 ION-GNSS conference in Portland, Oregon.

---

Rodrigo Leandro, Herbert Landau, Markus Nitschke, Markus Glocker, Stephan Seeger, Xiaoming Chen, Alois Deking, Mohamed Ben Tahar, Feipeng Zhang, Kendall Ferguson, Ralf Stolz, Nick Talbot, Gang Lu, Timo Allison, Markus Brandl, Victor Gomez, Wei Cao, and Adrian Kipka are members of the Trimble Engineering Team in Höhenkirchen, German