RTK: Behind the Scenes
October 1, 2007
Today, thousands of users around the world access highly precise correction data on hundreds of Real-Time Kinematic (RTK) networks ranging in size from a few reference stations to hundreds of Global Navigation Satellite System (GNSS) receivers. By providing accurate and repeatable RTK results, RTK networks have rapidly become a mature and indispensable utility worldwide.
The growing availability of RTK networks has caused the GNSS user community to revisit its processes, procedures and results when using RTK for production survey work. This renewed focus has helped yield firm conclusions about best practices, and has further established RTK networks as a stable, essential utility for rapid development of large infrastructure projects.
Due to increasing reliance on RTK networks for critical field operations, administrators must focus on techniques for managing data accuracy and assuring network integrity. Attaining these important objectives requires the assessment of three main areas: communications; atmospheric modeling methods and quality; and management of reference station position dynamics.
The Communications ComponentCommunications is key to effective RTK network operations. Both communications links--from the permanent reference station to the central server and from the central server to the field rover--must be highly reliable with low latency. (The reference station-server link is not addressed in this article.)
The rover-server link plays a critical role in network performance and is supported by one of two main communications choices: unidirectional (broadcast) or bidirectional (two-way) communications.
For network operators, this communications choice determines the network modeling format and services offered. For end users, several considerations help determine their communications choice. First, what communications method does the network support? And, equally, what method does their equipment support? Some legacy equipment may only be usable in a network offering a specific modeling format. Today, many networks offer both communications options. Here’s a brief overview of both.
Unidirectional or broadcast communications requires a radio transmitter such as UHF or spread spectrum. Radio-based infrastructure requires an initial setup cost for both network operator (radio towers and transmitters) and user (receiver). While there are no costs for ongoing access, there are additional issues with radio including line-of-sight requirements; transmitter power and broadcasting antenna height limitations; reliability of the link and governmental restrictions, such as licensing; and other operational limitations.
Bidirectional or two-way communications, which include Internet-based cellular or wireless local area network (LAN) connections, have become crucial for RTK users. Because of issues with the radio spectrum, more users are utilizing bidirectional modes today; increased investment and development by telecommunication providers have made these methods more reliable and available.
An additional benefit of using a cellular link is the growing number of augmented services available. Tools are available for this method that enable network operators to monitor/track usage. For field users, cellular links provide accessibility to Internet-based information in the field.
User considerations for both choices include assessing the method that carries the fewest issues such as: up-front expenses versus recurring service costs; and communications coverage and reliability. In addition, it is critical to know the modeling formats supported by local networks before making this decision.
Ensuring Accurate ModelingAny time-of-flight measuring technology, whether optical, RTK or network RTK, must deal with atmospheric errors, usually expressed in parts per million (PPM). Correcting optical total station measurements for local atmospheric--temperature and pressure--conditions is commonplace. Correcting PPM errors inherent in GNSS is more complex.
GNSS signals travel over 12,000 miles through space, incurring potentially significant errors from ionosphere and troposphere atmospheric conditions. While users can’t necessarily correct for PPM errors at the rover, the complex algorithms--or modeling formats--available in network RTK software can. Due to its real-time operations, network RTK modeling allows users to deal with the dynamic and changing atmosphere. From the users’ perspective, two approaches exist for applying a model for network RTK: rover-centric and server-centric.
In rover-centric solutions, the central server pre-processes raw GNSS data to make the reference station data consistent. It then broadcasts information to the rover to create its own model.
Examples of predominantly rover- centric solutions are FKP (Flächen-korrekturparameter or flat plane correction) and Master Auxiliary Concept (MAC), which use two different methods. FKP solutions develop a model on the server and send modeling corrections to the rover; the rover applies the corrections to measurements. This method only sends a “fit” plane approximate to the network’s PPM errors. In MAC solutions, the rover receives all data from the server to re-create the raw reference station data and create its own model. This method depends on the rover for complex atmospheric modeling; without the massive processing power of a central server, models generated by the rover are generally less complex and may not take into account some residual atmospheric effects. Additionally, in this method, two rovers can operate side by side and attain different results. Because the rover does the modeling, the quality of atmospheric modeling applied to the rovers is highly dependent on embedded firmware of the rover used.
Rover-centric solutions are normally broadcast using unidirectional communications links. These solutions are useful to fill in areas that do not have cell phone coverage; they must, however, deal with the radio issues noted earlier. These methods can also be used with a cellular communications link, but since data is being delivered only one way, users lose the benefits of cellular technology’s additional services, such as fleet tracking, managing crews, etc. In addition, these formats are not backward compatible: If the user’s rover is not compatible with RTCM 3.1net or FKP messages, it cannot be used in rover-centric RTK network solutions.
The server-centric approach relies on two-way communication between rover and server. The server receives raw GNSS data from the reference stations and creates data consistency to solve ambiguities for all stations in the network. Rather than sending the data to the rover, the server computes sophisticated models to estimate the network’s PPM errors. In addition, the rover sends its position for use in interpolating the model; the server then provides customized data for that rover’s location. The enhanced format of server-centric methods provides additional correction information to a standard RTK solution.
The server-centric method means that complex models and analyses are performed by the network and monitored by network administrators; less processing power or post-processing is required of rovers or field personnel. Today, the server-centric approach is the direction of much of the IT industry, from Google Earth to Oracle/SAP systems.
This approach provides users with a consistent modeling method over the entire network, improving consistency throughout the system. All rovers receive the same modeled data, which differs from the rover-centric methods that depend on different rovers and firmware for results.
The server-centric method also allows for backward compatibility with older receivers since legacy RTCM formats can be used. Because the server is continually receiving data to produce a model, it only needs to update the model as opposed to producing it from scratch for each user. Rather than the rover producing the model after connection, the model is instantly available as soon as the user hooks in to the system. As a result, the system has enhanced quality control.
Today, the most widely used server-centric approach is the Virtual Reference Station (VRS*) method. A common misconception of VRS technology is that it is not tied to anything physical. In reality, however, all data is tied with vectors back to the nearest physical reference station. As this method archives modeling information and raw data, the data can be easily re-created with post-processing methods.
Most networks can provide multiple formats, both rover- and server-centric. What is actually used depends on which communications method is chosen or available--and what options users’ equipment will support. Many network operators recommend using the server-centric method when more than one mode is available to the user (usually because cell phone coverage is becoming more pervasive in all but the most remote areas).
Managing RTK Networks for ReliabilityToday, network operators have numerous ways to ensure system availability including backing up communications lines to provide greater than 99 percent uptime. However, how do operators know that the system is performing correctly, that nothing has moved, that reference station results are consistent and that network results are correct?
In order to monitor and ensure network integrity, network operators need to understand and evaluate the subtle or obvious movements of reference stations. Network integrity and positioning results rely, ultimately, on the known positions of its reference stations. But reference station location is surprisingly dynamic: Sources of movement include acute, localized movement caused by factors such as accidents, weather or vandalism; acute, widespread movement due primarily to tectonic movement and earthquakes; and chronic movement such as shifting due to flows in and out of aquifers, mining activities, drilling and other recurring activities.
Two considerations are paramount in evaluating reference station dynamics: understanding the level of movement that requires concern, and determining the given time to detect that movement and notify the operator.
Network operators can get millimeter-level results by applying long-term post-processing techniques; however, detection time on those results is much longer. Conversely, operators can detect movement quicker by setting larger movement detection parameters.
A network operator needs multiple methods to determine motion; verification of movement should not rely on one analysis method alone, which would result in false alarms. By using several different cross-checked analyses, operators can analyze and verify that movement is real and guarantee that users are receiving reliable data. Monitoring software used by operators can be configured to sound alarms when movement rates (as quick as 3 cm/sec between epochs) or magnitudes (in the millimeter to centimeter level) exceed preset values. These tools give network operators additional high-level data for informed decision making.
Performance Expectations and Considerations for UsersThe practical outcome of utilizing reliable communications links, proper modeling and system design, and network dynamics management of network RTK is clear: reliable, accurate positioning ability. This is the benefit of highest importance to users. When using RTK networks, however, users must take into account several field considerations.
RTK networks work well for providing precision repeatability, or how well observations fit over time. But in determining accuracy, it is crucial to make sure the geodetic reference frames between the reference stations and the control being evaluated are consistent.
RTK solutions and techniques provide a double-difference, fixed-ambiguity solution. The advantage of this solution is that its availability is quick and accurate; the main drawback is that solutions are highly dependent on satellite geometry and are still susceptible to multipath at the rover.
So while modeled RTK solutions eliminate some error sources in GNSS solutions, there are still errors inherent to RTK techniques that require proper survey procedures to be addressed. Site calibrations, especially for the vertical component, are still necessary to ensure optimum results.
A similar consideration is traceability, or the ability to re-create solutions. Currently, survey associations throughout the country are addressing the legal requirements involved in using RTK and network RTK--an issue for GNSS use in general. How do users adhere to the normal legal requirements of a surveyor when using RTK and RTK networks for cadastral purposes?
Of interest is how this issue has been dealt with in Europe. Today, some EU survey associations have instituted that all surveys must be standardized by using RTK networks, which means all surveys will be using the same reference system and control. Traceability issues for network RTK are not any different than issues for single-base RTK. Because data can be stored as raw data from reference stations and rovers, any measurement or observation can be re-created. Within this, specific local cadastral requirements vary.
Managing Integrity for ReliabilityManaging the different system integrity issues of RTK networks makes them more reliable and provides greater product quality for the end users. With expert system administrators operating and managing the networks in real time, RTK network systems today are significantly more reliable than any surveying technology available in the past.
*The term “VRS” is widely used to describe real-time correction networks. Trimble was the original provider of a VRS network solution and has a trademark on the term VRS.