Approaches to providing real-time kinematic (RTK) solutions at high rates have existed in various forms for decades, providing value for high precision applications. This technique is nearly universally adopted in the industry, and many surveyors may have been using it for years without realizing it. Yet there are persistent misconceptions about the subject.
By Gavin Schrock, PLS
For many on the development side of high-precision real-time kinematic (RTK) GNSS, like those we interviewed for this article, the incorporation of high-rate solutions into their RTK products is a given — and has been for a very long time. Yet, in some end-user communities there may still be many question marks: Does my gear do it? Does other gear do it? What can it do for me? What are the pluses and minuses?
We asked for insights from 10 prominent firms that develop and manufacture RTK-enabled high-precision GNSS solutions and equipment, spanning multiple applications:
- Bad Elf
- CHC Navigation
- Emlid
- Hemisphere GNSS
- Hexagon | NovAtel
- Leica Geosystems
- Septentrio
- Tersus GNSS
- Topcon
- Trimble
First, however…
What is high-rate RTK?
By high rate, we mean higher than 1 second (1 Hz) increments, such as 0.2 second (5 Hz), 0.1 second (10 Hz), etc. Part of the confusion about high-rate RTK is that there are two scenarios. One is transmitting corrections from a base or network at high rate, receiving and solving on-the-field sensors or rovers at a high rate (for example, 5 Hz base + 5 Hz rover).
The other is base transmission of corrections at a lower rate and receiving/solving on the rover at a higher rate (for example, 1 Hz on the base + 5 Hz or more on the sensor/rover).
While both can be valuable for different applications, what has been adopted as standard for most surveying, construction, agriculture and mapping applications is the latter.
What are applications that would run the base and rover at higher than 1 Hz? “Moving Base” applications are prime examples, where you are seeking to resolve positions for one or more sensors relative to a base that is also on a moving platform. Think of a barge on the ocean where a helicopter (or rocket) might be landing. Here is a definition from the user manual for a popular OEM receiver that has been in many makes and models since 2003:
“Moving Baseline RTK is an RTK positioning technique in which both reference and rover receivers can move. Moving Baseline RTK is useful for GPS applications that require vessel orientation. [For example, the] reference receiver broadcasts [correction] data at 10Hz, while the rover receiver performs a synchronized baseline solution at 10Hz. The resulting baseline solution has centimeter-level accuracy. To increase the accuracy of the absolute location of the two antennas, the Moving Reference receiver can use differential corrections from a static source, such as a shore-based RTK reference station.”
Beyond such specialized applications, running the base at a high rate is a burden on radios or bandwidth. Additionally, as industry experts explain below, it is of little (or no) value and may only unnecessarily use excess bandwidth and burden broadcast radios.
When would you run the base at 1 Hz and the rover at higher than 1Hz, such as 5Hz, 10Hz, or more? When the base is static. That pretty much covers nearly all surveying, mapping, precision agriculture and construction applications. What is meant by high rate in the sensor/rover receiver and its RTK engine, in the context of such applications? As one of the firms interviewed stated:
“The number of RTK position fixes generated per second defines the update rate.”
For most of the surveying, mapping, precision agriculture and construction applications, that means base 1 Hz + rover 5 Hz or 10 Hz. Then there are specialized applications, such as structural monitoring and geophysical studies, that may run sensors/rovers at 20 Hz, 50 Hz or (though rare) as high as 100 Hz. Whether a higher rate is a default, or 1 Hz is the default, changing the rate is almost always a user-configurable option.
A general perception is that base-rover gear defaults to base 1 Hz + rover 1 Hz. However, as the experts below note, that is not necessarily the case — often the rover rate is higher by default.
By any other name…
The respective approaches, and their appropriateness for different end-use applications, may seem fairly straight forward. However, part of the confusion about the subject for end users comes from the wide range of terminology used to describe how high rate is applied across the industry.
The understanding of processing approaches is clear among GNSS engineers, and in specific terminology, but this rarely gets translated well or consistently in terms meaningful to end users in documentation or marketing.
Developers might have different approaches to achieving high-rate solutions and would of course not wish to completely reveal their cards, but many of the fundamentals are the same. A mutual recognition of parallel development among GNSS engineers, and the manufacturers they develop for, in that each strives to continually improve solutions, means that the high-rate element of RTK generally does not get much marketing hype.
Often, when high-rate RTK does get laterally mentioned — in manuals, marketing or labeled as configuration options in GNSS field software — the mix of terms can confuse the user. Such terms as extrapolation, prediction, update rate and solution rate could evoke a negative connotation to an end user who is used to hearing one set of terms, and they might view otherwise like terms as contrasting terms.
GNSS engineers do not have issues with mixed terms. As some indicated in their respective interviews, they seem a bit puzzled as to why anyone would misunderstand the subject, and how marketing spin might lead users to be confused.
In recent years, the subject seemed to get discussed a lot more than usual in various high-precision end-user social media platforms. Perhaps this was a natural progression in growth of understanding of the nature of GNSS among these constituencies, and a desire to know more about what goes on in those black boxes — a positive thing. There may also have been some instances of marketing nudge.
For whatever reason it became a subject of discussion, we heard from readers who asked us to look into it. So here, in alphabetical order, are insights from of the experts in this field. You can jump ahead to the specific section for your equipment vendor, but we encourage you to read through each; combined, they provide a more complete picture of the subject.
Bad Elf
With Larry Fox, VP for Marketing and Business Development
Bad Elf has long provided GNSS solutions for aviation- and mapping-grade field applications. Several years ago, the company introduced a survey-grade-precision system, Flex. It is offered with an option for a modest initial investment in the hardware, and an innovative token system for enabling and operating at centimeter precision.
Larry Fox has been in the industry for a long time and has seen the evolution of real-time GNSS. He is Bad Elf’s vice president for marketing and business development, but he also had a key role in the development of the Flex system. Fox said that, of course, high-rate RTK is supported. “We allow options up to 20 Hz on the rover if the user has this enabled.”
For the approach of 1-Hz base and higher rates on the rover, he said that Bad Elf does not have a specific term for this. “For purposes of description, I could refer to it as high update rate, but I suspect high solution rate is pretty much synonymous.”
Fox explained how the standard approach works. “The rover knows the location of the fixed base and therefore applies the same processing techniques by simply reusing the last received data.”
He also mused about various hypothetical scenarios. “Given that the converse is also possible — a slow data rate from the base, say, 0.2 Hz at the base and 1 Hz at the rover — is there fundamentally any difference?”
For many applications, Fox does not see a substantial advantage in running at higher rates: “I see no benefit for higher data rates in a static situation such as a survey. I would argue that in a survey workflow, one should allow the RTK algorithm to settle over the static shot being taken, as the RTK algorithm likely benefits from aging out some of the data it used while moving.”
He adds, “I would suggest that once you have occupied a point for a modest amount of time and you remained fixed, I can’t see any benefit. My argument here is that by the time you have leveled and prepared your collector of choice, any decent RTK receiver with a good sky portrait and good corrections will not observe any benefit.”
As for disadvantages and trade-offs, “More and faster data,” Fox said, “must be better, correct? Sarcasm included. Unless there is a tangible need for more samples, what is one going to do with all the extra data? I could have seen a possible argument that a single constellation receiver may benefit from averaging, but that could be a be a whole different subject as multi-constellation is now standard. Arguably, at a higher data rate one could capture more epochs and reduce the time on station. With multi-constellation receivers I am just not convinced that these techniques have the same merit they may have had in the past.”
Bad Elf doesn’t support higher correction transmission rates from the radio. “The current module only supports RTCM3 at a 1Hz rate,” Fox said. “Even if we could transmit faster, the payload required would exceed the capability of the message transmission rate of the radio. The battery life of a radio is directly correlated to the transmission duty cycle. The more you are transmitting, the less battery life you will have. I would argue this would impact the useful field time you would have without an external battery solution.”
Fox notes that any application where a rover is moving — such as on a vehicle or for machine control — could benefit from high rate. “I could see a potential application for drones,” he added. “I would want to have the epoch of an image recording very tightly coupled to the image captured. Fundamentally, an RTK drone’s imagery is only as good as that. If one was taking video at any reasonable framerate, a higher frequency RTK GNSS may benefit the geolocation of more individual frames with less extrapolation.”
What about rates higher than 20 Hz? “We have run our receiver up to 20 Hz on the rover side. Although there are units capable of even higher rates, I don’t have any data that would convince me that this is viable, for mapping or surveying.”
I asked about some of the misunderstanding out there about high-rate RTK, and Fox replied, “We can be creatures of habit and tie ourselves to beliefs that ‘this is the way I did it and it worked then.’ People should always ask themselves the question, ‘do I still need to do it this way?’ Again, there is the premise that more is better. I can’t tell you how many times I have seen people collect very high-rate data for lines and poly features only to decimate the data because it reduced performance, increased storage, or lowered the performance of the apps rendering the data.”
Emlid
With Svetlana Nikolenko, Lead Application Engineer
Emlid, a relatively new entrant to the market for high-precision GNSS, has made a splash with their line of affordable systems, such as the Reach RS2 rover and base-rover kits, and RTK systems for UAVs.
“All our devices support this,” said Svetlana Nikolenko, lead application engineer. “We do not have a special term for this, as it is simply a standard. We recommend 5 Hz and higher for a moving rover, but it can be overkill for a stationary one.”
Asked why one would want to run at high rate, Nikolenko explained, “The need to set a higher update rate depends on the rover’s velocity and acceleration. The higher the update rate, the more solutions per second are calculated. So, if you’re moving fast, the higher update rate simply allows you to keep your position current. If the rover is stationary, there are no issues with working at 1 Hz. Still, there is nothing wrong with running a stationary rover at 5 Hz or higher: it is excessive, but produces more samples with different satellite geometries.”
For moving applications such as UAVs, higher rates are of value. “It really depends on velocity,” Nikolenko said. “For example, if the rover is on a drone flying at a speed of 5-20 m/s and the update rate is set to 1 Hz, you won’t have the actual positions of the images. The higher update rate our devices have is 10 Hz, and at a drone speed of 20 m/s, even if you take photos each second (which might be a bit excessive), you’ll get accurate positions.”
Emlid does not support a moving base. However, if there is a strong demand from users, they will consider adding this. For non-moving applications, Nikolenko said, an approach of broadcasting from the base at a high rate is excessive. “This increases the load on the radio (or any other connection link) because the base sends its position and corrections to the rover as often as it calculates it. Anything excessive simply adds load to processors and batteries.”
CHC Navigation
With Carlos Cao, Technical Manager for the Asia-Pacific region
CHC Navigation, or CHCNAV, has steadily grown as a recognizable brand of GNSS and other geospatial products internationally. While the brand might be new to some in North America, in some regions of the world CHC has a substantial share of the market, selling hundreds of thousands of units over the past 15 years. The company develops its own solutions, but also incorporates OEM components. In all cases, CHCNAV has provided high rate as standard from its earliest days.
Carlos Cao, technical manager for the Asia-Pacific region, said that his company supports the approach of broadcasting at 1 Hz and solving at higher rates on the rover. “For example, you can get coordinates every 0.2 seconds in the Landstar 7 Topo Survey software,” said Cao. “Meanwhile, with different OEM boards, RTK models and supported software, [the equipment] can also reach 10-Hz or 20-Hz static data recording and NMEA data output (including GNGGA coordinate data).” Their term for solving RTK solutions at a high rate on the rover is “high update rate.”
This can bring advantages, specifically for moving applications, Cao said. “When you stake out, the 5-Hz update rate brings faster coordinate updates, especially when surveyors walk quickly. When you survey by time during movement, you can get denser points; while you survey by distance, the accuracy will be better if you are at high speed. For example, speed is 6 m/s, and you want to survey a point every 5 meters; 1 Hz update rate cannot do this with high accuracy.”
When would 1Hz be sufficient? “Normally,” Cao said, “a 1 Hz update rate is enough for a topography survey because users won’t survey at a high speed, so our default setting is 1 Hz, though you can choose higher rates if enabled and as needed. Unless you are moving, however, such as when some surveyors mount a rover on a vehicle, there is no significant difference in the final results.” He added that running at high rates can drain the battery faster.
Broadcasting at higher rates has several major issues. “With more satellites launched, especially BeiDou, correction data becomes much larger,” Cao said. “It means that network RTK requires more data flow, and UHF radio RTK needs a UHF modem that can send data at a high rate. It is a very big challenge for base RTK.”
Meanwhile, notes Cao, “The rover could even have a correction age of 5 or 10 seconds, and it will use the previous package to calculate the position. Since 1-Hz base and 5-Hz rover can work without degradation of precision, there’s no need to change the base to 5 Hz.”
Other applications CHC supports often use higher rates. “Navigation, machine control and precision agriculture normally use a 10-Hz, 20-Hz or 50-Hz update rate,” Cao said, “because these devices work under high-speed movement status, especially navigation. Also, they need to combine with high-update inertial measurement unit (IMU) data. The max update rate is 50 Hz. Normally the application data for these uses is NMEA data output by COM port or TCP/IP protocol. For surveying applications, such as topography, 1-Hz base and 5-Hz rover is enough. For other applications that need higher rates, we also provide such devices.”
Hemisphere GNSS
With Kirk Burnell, Senior Product Manager
“At Hemisphere, we simply refer to this as RTK,” said Kirk Burnell, senior product manager for Hemisphere GNSS. Burnell added that they do not have any special term for this — it is simply a standard.
We were discussing specifically the approach of solving on the rover at higher rates than the base corrections. “All Hemisphere RTK products can work in this way, meaning corrections can come in at 1 Hz or slower, and rover output can be at 1 Hz, 5 Hz or 10 Hz as the user sees fit and as the application demands.”
Hemisphere develops GNSS and multi-sensor solutions for many industries: surveying, construction, agriculture and more. While Hemisphere has its own branded survey rovers, its OEM boards are in many other popular rover brands, makes and models. So, whichever you are running, you get high rate as a standard option.
Burnell explained further that this is a given in the industry. “This is the standard expectation for RTK amongst our competitors, based on their product offerings, documentation, and standard operation. When describing RTK, the expectation is for 1-Hz base-station corrections, and a user-selectable rover output rate. Understandably, when people discuss RTK in technical terms, they may use different phrases to help distinguish between different techniques, which is why there might be different phrases out there. For us, it is simply RTK.”
As for the benefits of high rate, Burnell explained that inside the receiver, the measurement engine and RTK algorithms are typically running at 10 Hz or 20 Hz, and the selected output rate of the solution does not impact the RTK engine’s performance. The receiver will fix as fast and as accurately as possible given the quality of the RTK correction stream. Survey users could see a smoother update rate on their screen using 5 Hz compared to 1 Hz. This makes such tasks as leveling the rod or watching the change in height on screen while moving from the bottom to the top of a curb feel more natural. The user is not waiting an extra second each time to see the stability of the output. “A 5-Hz update rate is a good tradeoff for smooth workflows versus consuming CPU and battery power, compared to 10 Hz or 20 Hz,” he explained.
Would there be a disadvantage to simply running the rover at 1 Hz? “When using a 1-Hz update rate to the data collector, there will be fractions of a second spent waiting for the screen to update,” Burnell said. “Over the course of a day’s work, this could add up to a few minutes of extra time spent. In reality, this does not impact the ability to deliver a job on time. If the user does not feel impeded by the slower update rate of the screen, there is not a significant difference between the quality of the data, comparing 1 Hz and 5 Hz.”
Addressing one misconception that some users have about high rate, that it might significantly improve precisions, Burnell clarified, “For classic RTK surveying, outside of the workflow differences for the surveyor, the same quality of data is produced.”
Disadvantages? “Once you move beyond 5 Hz you start to exceed people’s hand-eye coordination ability, and the benefits diminish,” said Burnell. “Additionally, the data collector has a lot of communication to process, data to unpack, calculations to do, and screen refreshes to accomplish. Faster than 5 Hz leads to stresses in these aspects of the user experience, and ultimately can consume the data collector’s batteries at a faster rate.”
There have been instances of high rate being marketed as enabling users to save a lot of time, but as Burnell noted, this might actually be a potential problem. “There could be a false sense of having no latency, which could lead to rushing through a job, increasing the chances of making a mistake. A surveyor’s observations and measurements are the currency of their trade, and they should be made with care and attention to the work being done. Most surveyors take pride in a job well done.”
Regarding the other scenario, broadcasting at a high-rate and solving on the rover at the same high rate, “This mode of RTK operation has little or no benefit and a host of drawbacks,” Burnell said. “The biggest issue is the volume of data. For a multi-frequency multi-GNSS solution, there is an immense amount of data to be transmitted from the base to the rover. Running a link at 5 Hz requires huge data bandwidth generally only possible using an internet link as compared to a 450-MHz or 900-MHz radio link. Drawbacks for internet links are data volume costs. For dedicated radio links, the issue is most likely to impact radio range. To send five times as much data, the over-the-air baud rate needs to be five times greater. This means that the energy per bit of data is five times less when at high speed. The signal will lack the ability to punch through obstacles. While some may suggest that having five times as many corrections reach the rover compensates for this, some radio protocols can be configured to transmit multiple retries with 1-Hz data.”
However, there are advantages to running at higher rates for specific applications, Burnell said. “If data is being collected in a kinematic fashion as compared to shooting individual points, there will be more detail when collecting at 5 Hz. For example, driving along a road with a receiver mounted to the roof, in 1 minute of driving there will either be 60 measurements at 1 Hz or 300 measurements at 5 Hz. For many non-survey applications, this is critical. For example, at highway speed, 1-Hz data means 1 point every 30 meters (100 feet) or so. In machine control, the systems are not relying on hand-eye coordination and reaction time, and 20 Hz or 50 Hz are common speeds. Autonomous applications also typically use between 10 Hz and 50Hz for GNSS, and often combine this with 100-Hz or 200-Hz IMU data. Aerospace and defense applications have demanding conditions and use 100-Hz to 200-Hz IMU data to navigate, often combined with 1-Hz, 10-Hz or 20-Hz GNSS data.
There are even some applications for which it is warranted to broadcast corrections at rates slower than 1 Hz. “One example was a user in Japan, where radio links are often throttled to 4800 baud,” said Burnell. “They were looking to see how to slow down corrections to less than 1 Hz so that they could take advantage of multifrequency multi-GNSS RTK. Another example: I recently asked for some 10-Hz rover data for analysis. With very large files, analysis took much longer — I wished I had asked for 1-Hz data!”
Hexagon | NovAtel
Hexagon | NovAtel is a prominent tech firm providing positioning, navigation and timing (PNT) solutions for multiple industry segments, including defense, surveying, construction, agriculture, autonomy and more. While GNSS is a core technology, NovAtel develops multi-sensor systems (including inertial) and has a broad reach with its OEM products. Surveyors, for instance, might not be familiar with NovAtel first-hand, but have likely used its technology via NovAtel’s many OEM customers.
Iain Webster, senior director of Geomatics and Software Engineering for NovAtel, said that not only does NovAtel support high-rate RTK, but the customer can choose the position output rate desired — 1 Hz, 5 hz, 10 Hz, 20 Hz, etc. — and the receiver will output RTK positions at that rate.
“We distinguish between a matched solution (where a correction is matched with a rover observation at the same time tag), and a low-latency solution, where base observations are extrapolated for position computation at the rover,” Webster said. He provided a description from a company manual:
“The RTK system in the receiver provides two kinds of position solutions. The Matched RTK position is computed with buffered observations, so there is no error due to the extrapolation of base station measurements. This provides the highest accuracy solution possible at the expense of some latency, which is affected primarily by the speed of the differential data link. The MATCHEDPOS log contains the matched RTK solution and can be generated for each processed set of base station observations.
The Low-Latency RTK position is computed from the latest local observations and extrapolated base station observations. This supplies a valid RTK position with the lowest latency possible at the expense of some accuracy. The degradation in accuracy is reflected in the standard deviation. The amount of time that the base station observations are extrapolated is in the “differential age” field of the position log. The Low-Latency RTK system extrapolates for 60 seconds. The RTKPOS log contains the Low-Latency RTK position when valid, and an “invalid” status when a Low-Latency RTK solution could not be computed. The BESTPOS log contains either the low-latency RTK, PPP or pseudo range-based position, whichever has the smallest standard deviation.”
NovAtel does not brand this as a specific feature — it is just a standard part of its RTK solutions, but the company refers to it in their documentation as a “low-latency” solution.
The main benefit of this solution, Webster explained, is for kinematic users to allow better representation of their actual trajectory (such as in applications on moving vehicles). “The higher the dynamics, the more impact the latency of the matched solution will have to the point that we recommend the low-latency solution to all but specialist customers with known static positioning needs. For surveyors, there may be improved workflow with the low-latency solution as they will be able to move from point to point more quickly.”
Webster noted that for applications where the rover is static for observations, 1 Hz can be fine, but for moving rover applications — kinematic — running at 1 Hz is probably unacceptable, so low latency is quite standard.
Additionally, he pointed out, there are applications where longer periods between corrections may not necessarily be detrimental. “Note that some manufacturers, including NovAtel and Leica, offer the possibility of using PPP corrections to extend RTK solutions beyond, for example, a 60-second timeout,” Webster said. “There are various proprietary methods to achieve this, but ultimately the RTK solution could be extended without limit in this way.”
Are there tradeoffs to using extrapolation or other high-rate approaches? “With corrections coming in at 1 Hz,” Webster said, “there is very little error over that period, so for most users, there is little disadvantage and perhaps some productivity advantage with a higher rate. If there is any trade-off, it is between getting the highest accuracy possible versus the lowest latency solution.”
As for the other scenario — the base broadcasting at greater than 1 Hz and the rover solving at greater than 1 Hz — “There is little advantage,” Webster said, “except in some specialized applications such as when the base is moving (called moving baseline) to provide a cm-level baseline between the base and the rover for relative positioning. For typical surveying applications with a static base, the rover would have to wait until the corrections arrived before outputting a solution. Other downsides include increased bandwidth on the communication link and more loading on the rover CPU, meaning lower battery life.”
What are the non-surveying applications where a high rate (in either scenario) can yield a specific benefit? Webster noted that, in fact, they deal mostly with non-surveying applications. “Most use cases need 10 Hz or 20 Hz for machine control or precision ag. We do have some very specialist applications that have required up to or beyond 100 Hz — but it is often best in those cases to do a GNSS/inertial navigation system (INS) solution and use the IMU to output at that a high rate. As previously mentioned, there are other specialist applications where the base is moving. In this case, we run a matched solution at a high rate between the base and the rover.”
Leica GeoSystems
With Xiaoguang Luo, Senior Product Engineer, GNSS Product Management Group
Leica Geosystems (part of Hexagon) has been a major global developer and manufacturer of GNSS systems for multiple disciplines for several decades, introducing its first GPS receiver, WM101, in 1985. Since then, Leica has been among the leaders in GNSS receiver innovation, including integrated systems such as a rover that incorporates calibration-free tilt compensation and an image-point capture feature (GS18 I). Therefore, it is no surprise that for Leica Geosystems equipment features high-rate RTK as standard.
Xiaoguang Luo is a senior product engineer in the GNSS Product Management group at Leica Geosystems. He confirms that this option is supported in all Leica Geosystems RTK rovers of the current product portfolio, and this option is enabled by default in the Leica Captivate (surveying field) software. A term Leica Geosystems uses is prediction for its high-rate RTK approach.
The standard positioning rate is 5 Hz on the rover. “As far as GNSS processing is concerned, there is no fundamental need to go to higher positioning rates,” Luo said. “The need for high rates is mainly driven by applications. For example, we are using the 5-Hz position update rate at the rover by default for an improved staking workflow and user experience. The 10-Hz rate is also supported in Captivate, for example, when streaming NMEA messages.” He added that 10 Hz is supported for other applications, such as structural monitoring, and 20 Hz for machine control.
As for the advantages of a rate higher than 1 Hz, Luo said that working at high observation and solution rates enables the possibility of modeling fast-changing error effects with a period below 1 second, and allows for high-rate non-surveying applications such as bridge monitoring. Does a high rate have any significant effect on the final results? He said that it strongly depends on the use case where high-rate observations and positions are involved. In addition, the quality of prediction also affects the final results.
By this he means that while the standard approach for applications where the base is stationary, such as surveying, can work so well with a base data rate at 1 Hz and rover at 5 Hz, the key conditions do not change much over a single second.
Luo’s colleague Bernhard Richter, vice president of geomatics, explained it. “To understand this, you need to separate the elements of corrections into those that are fast changing and range dependent (see the graphic below). If the errors change slowly, then they can be estimated and predicted very well. Or, if the range dependency is low, errors could come from a different source than the base station. If the range dependency is medium or high, then the corrections are more difficult to estimate on the rover side, but if such errors change very slowly, they can still be predicted very well with the precondition that corrections have been received at least once.”
You’ll notice that multipath is high in both regards. This brings up another misconception about high-rate RTK — some users have an expectation that it will improve their performance in limited sky-view situations (like thick tree canopy) or high multipath environments. This is not so. Any improvements in such environments come from having more satellites, more observations, and more modernized signals. With regard to high-rate and multipath, Richter said, “It is anyway futile, since multipath decorrelates so quickly that the advanced mitigation has to happen both in an analog and a digital way on the rover.”
While there are benefits to running at high rate, such as for staking, a balance has to be struck — for instance, in not running it at too high a rate. Luo outlined disadvantages that must be considered when performing high-rate RTK.
- High processing load and battery drain, particularly with multi-constellation and multi-frequency RTK.
- High temporal correlations between observations, which may not be considered in a sophisticated manner in the RTK algorithms.
- High base rates provide challenges for the RTK data link devices, such as radios.
In addition, he noted that while any kind of predictive solution will introduce some amount of error, that would be so small in, for instance, a base data rate at 1 Hz and rover at 5 Hz solution, as to not even be noticeable in the positioning results.
Septentrio
With Bruno Bougard, Research and Development Director
“Our rover solution computes RTK up to 100 Hz,” said Bruno Bougard, R&D director at Septentrio. “Update rate requirements for industrial machine control applications are typically 20 Hz. This is necessary to capture the motion dynamics. Also, it is not only the update rate that matters in those applications, but also the latency, which should be low (<20 ms typically) and constant.”
Septentrio NV is a designer and manufacturer of high-end multi-frequency GNSS receivers and integrated solutions. Markets they serve include surveying, mapping, construction, science, timing, agriculture, marine, autonomy, and more — all with specific applications where high-rate RTK may be employed They also provide OEM boards and modules for further integration by others.
Surveying users for instance may be familiar with their Altus line of rovers, such as the NR3, where high rate is a standard option. “There are new applications where a higher update rate is required,” said Bougard. “Surveying with UAV, using photogrammetry or lidar scanning requires at least 10Hz. In mobile mapping in general, RTK-INS solutions such as SPAN, Applanix or Septentrio SBi, require update rates up to 200Hz.”
Bougard acknowledged that manufacturers use many terms for their high-rate solutions. “Some may be used to masquerading a low-rate solution as a high-rate one. This is not what we do. The rover observables are captured at high rate and can be up to 100 Hz. The rover RTK filter is also run on high rate. Fixed base-station data does not have to be high rate. 1 Hz is typically enough. For moving base applications — for example, when the base station is on another vehicle, and we want to compute the baseline between the moving base and the rover — 10 Hz is required.”
Bougard said that the benefit is to track the motion of the rover. This is critical in machine control, but also relevant for new survey flows (such as UAV-based and mobile mapping). The disadvantage, he explained, is that it requires higher CPU loads. “Suppliers, who focus on cost, tend to compromise on this, notably running higher rate only for a subset of the constellation or signals. We use them all.”
Is running the base station at a higher rate advantageous? “It is possible to increase the output rate of our base station correction stream but, as explained, this is not needed if the base is static,” Bougard said. “This is applicable to moving base scenarios as explained above. Indeed, if you increase the base-station correction rate, the bottleneck becomes the datalink.”
Tersus GNSS
With Xiaohua Wen, Founder and CEO, Tersus GNSS
Xiaohua Wen, based in Melbourne Australia, is the founder and CEO of Tersus GNSS, another new entrant in the centimeter-grade GNSS market. One distinction about Tersus is that the company has developed and produces its own GNSS boards, instead of using OEM boards from other companies. Tersus implements its own tech, including GNSS receivers and IMUs in its own survey rovers, such as the Oscar, and for other high-precision applications. Additionally, it produces OEM boards for integration by others. Tersus entered the market with full multi-constellation support and, of course, high-rate RTK options, and has recently announced a PPP (precise point positioning) service.
“Our RTK boards support up to 20 Hz,” said Wen. “Often, surveyor will choose 5 Hz. We do a 5-Hz solution in this manner: the baseband takes raw measurements at a wanted moment, say at 1.2 s or 1.4 s, and RTK calculates solutions with the raw measurements. We understand that some older solutions might simply extrapolate or interpolate based on a position and velocity sequence, which is sometimes called predicted RTK or extrapolated RTK (though those terms get used in different ways by different developers). That is not how we approach our RTK solution updates. All Tersus RTK boards also support a maximum 20 Hz raw measurements outputs.”
We asked about some of the advantages users may envision of high-rate RTK in general. Wen said there may be little or no gain with regard to faster initializations. Likewise, there is no significant gain with precision and accuracy. However, Wen said that higher rates can sometimes improve staking workflows. “For example, in the case of our Oscar rover with tilt compensation, the RTK outputs solutions at 10 Hz, while the IMU samples at 100 Hz. Oscar calculates the pole tip’s position at 10 Hz, aligned with the RTK solutions, and the data controller or tablet displays the point of the pole tip on the screen. We find that the point better refreshes at 2 Hz or higher to respond to the pole tip movements without noticeable lagging.”
That movement is an example of a key value of high rate,“Speed or movement,” Wen said. “For surveying applications, I would say that 1 Hz could suffice, considering the characteristic very low speed. Usually, applications like machine control and precision agriculture require an RTK update rate at 5 Hz or higher. Some UAV applications may use a 100-Hz position update. Most of these applications use an INS+RTK solution. With INS, it’s easy to get a 100-Hz position update, while for an RTK solution, a rate of 20 Hz is probably enough.”
Wen said that broadcasting corrections at a higher rate is pointless for most applications, “because the base data is highly correlated in the short term. If it’s a moving base, the high-rate base data would make some sense. Otherwise, it just imposes a greater load on communications and computation, with almost no gain.”
Topcon Positioning Systems
With Alok Srivastava, Director of Product Management
“It is a standard option in our rovers,” said Alok Srivastava, senior director of Product Management (PM) at Topcon. “Around the time I joined the PM team, in 2010, the decision was made to make 10 Hz the standard, though this is user configurable and can be 5 Hz, 20 Hz, up to 100 Hz.” He explained that faster rates have been available through several generations of their receivers.
Typical applications consist of a static base and a moving rover. Fast-moving applications can benefit from higher rover position update rates since the RTK engine is computing real positions at a faster rate. Higher rates on the rover side provide accurate changes in position that can be missed by interpolating between positions computed at a slower rate.
High update rates on a base station do not provide advantages except in rare cases where the base is moving. While rovers are computing movements of the rover antenna, base stations are providing GNSS satellite corrections. A rate of more than 1 Hz for a static base station does not benefit rover accuracy; it only creates a burden on the communication between base and rover. Base and rover communication needs to be optimized to reduce bandwidth requirements. This is especially true as we continue to add constellations and signals to GNSS solutions.
Sufficiently high rates have been standard on Topcon rovers for a long time. Srivastava would rather see more focus put on other aspects of GNSS — such as interference, spoofing, the impacts of 5G, precise point positioning (which Topcon provides through its Topnet Live service) and sensor integration. “In many of our construction applications, we have IMUs,” Srivastava said. “When an application has an IMU for tilt compensation or for machine control, the IMU and GNSS complement each other. In kinematic mode, the IMU can help reject outliers.”
Trimble
With Stuart Riley, Vice President, Technology – GNSS
“High rate can be considered a common default mode of operation,” said Stuart Riley, vice president, Technology – GNSS, Trimble. “Typical rover position solution rates are 5 Hz, 10 Hz and 20 Hz.”
Trimble is one of the pioneering companies in GPS and GNSS, and Riley has been directly involved in the evolution of the company’s GNSS solutions for more than two decades. He has seen a lot of change, and in noting the nature of key technological advances, offered this intriguing observation about high rate: in many ways it has become less relevant.
“There have been considerable advances in RTK technology in recent years that make many of the earlier concepts related to how base and rover data should be combined for baseline processing largely irrelevant,” said Riley. “Most recently, survey receivers have included INS support for tilt compensation applications, and these receivers have available high-rate IMU data — at a much higher rate than GNSS observables — which drive the final GNSS/INS integrated solution. Thus, the rover GNSS data rate is not so important.”
Riley noted another relevant technology that Trimble has implemented: the use of precise satellite clock and orbit corrections — such as from the Trimble RTX precise point positioning (PPP) service — to augment RTK when there is a loss of the base correction stream. The implementation of PPP is broadening across the industry, and the company was an early implementer of a global service. It has the RTX-based xFIll feature that runs on and high-end survey receivers. One of the misconceptions about PPP services such as xFill is that it is just there to “take over” should the RTK or NRTK corrections be interrupted. Yes, it does that as well, but to be able to do that, it is running all the time, simultaneously with the RTK, so the rover is getting these enhanced PPP service clock, orbit and other data. This improves what the rover can do. “The emphasis in modern survey receivers,” Riley said, “is based more on the availability of rover data, and a fundamental base data rate of, say, 1 Hz, is all that is required.”
Along with various advances in the rover RTK engine, the GNSS constellations have expanded considerably, requiring increased bandwidth for the corrections from base to rover. “Our products can use various communication technologies to transmit corrections, such as Wi-Fi, cellular, and UHF (450 MHz or 900 MHz) radios,” Riley said. “Maintaining a 1-Hz correction rate enables all the GNSS observables to be broadcast from the base, providing a suitable highly compressed data format such as when Trimble’s proprietary CMRx format is selected.”
Many terms are used in the industry, and they typically refer to some proprietary aspect of an RTK engine. Riley said that a generic term would simply be high update rate. “Providing the position is based on the most current phase observables at the rover, a low latency solution is possible,” he said. “Thus low-latency solution goes hand-in-hand with a high update rate. Predicted RTK may refer to an old method where the static base corrections are propagated forwarded to account for radio latency and thus synchronize base/rover data. This is not used in modern PVT (position, velocity, time) RTK engines.”
High rate on the rover is standard, but what benefits should the user expect from it? “A fast update rate provides the best user interface experience in the field, in particular for stakeout,” Riley said. “Quite simply, nobody wants to be working with a laggy display. For survey field work, 5 Hz is typical. Other applications, such as machine control, benefit from higher update rates where a default of 10 Hz would be used, with options for higher rates.”
If the user chooses 1 Hz on the rover, what would be the downside? “Running at a 1-Hz rate is not really suitable for stake out,” Riley said. “For occupying static points, 1-Hz updates would suffice, as a typical occupation has a minimum time of 1 or 2 seconds. Very high rates for survey applications do not really buy anything in terms of field look and feel or performance.” I asked him about any points of diminishing returns, and he responded, “The higher the rate, the wider the measurement bandwidth (that is, the noise increases — you cannot get something for nothing), so in fact going for an unnecessarily high rate would start to be a disadvantage. For example, there would be no advantage to using a 50-Hz or 100-Hz rate for a land survey application. There is a relationship between measurement bandwidth and position noise.”
When is a high base rate a good idea? High rates are supported for some machine control and “moving base” applications where the reference frame has to move with the moving base, Riley said. In this case, the base and rover observables must be synchronized and the final solution has a fundamental latency depending on the base rate. For this reason, moving base rates are more typically 10 Hz or 20 Hz. For a static base, it is possible to use a higher rate. However, as Riley noted, “It’s more likely that a lower rate such as 0.5 Hz might be desirable to accommodate the radio when using repeaters (time multiplexing the data) or low data rates. There are disadvantages to high base rates, mostly related to radio bandwidth. Other factors, such as ‘high rate = more radio transmit power’, may need to be considered (affecting battery life).”
Are there other cases for even higher rover rates? “As mentioned, machine control applications use higher rates — necessary to reduce position latency in control loops,” Riley said. “Other applications such as UAVs and autonomous driving clearly benefit simply because of the speed of the platforms (higher dynamics). Precision agriculture is an excellent example of machine control, where auto guidance is used. Although high rates are possible, nearly all applications manage perfectly fine at rates up to 20 Hz. A more important consideration is system performance in terms of positioning accuracy and convergence times, which is dependent on the technology used in the PVT engine, such as Trimble ProPoint technology, rather than the correction stream data rate. ProPoint also includes xFill, as mentioned earlier, which provides centimeter-level backup for continuous operation when RTK or VRS correction streams are interrupted.”
Other Manufacturers
This was only a sampling of the developers and manufacturers, but it should be noted that several of the above firms produce OEM boards featured in dozens of other brands and models, such as Carlson and GeoMax. To try to list them all would be a challenge and might be missing a key point: high rate is quite standard, is not big news anymore, and you probably have it by default (or optional) no matter what system you are using.
Hypeful
As the insights the from industry experts above show: high rate can be essential for many applications, but unnecessary for others. It seems more about user experience (staking workflows or moving rover) than some way to seek higher precision.
Additionally, to borrow the gaming term hypeful, some users believe (or have been led to believe) that running at high rate will yield higher precision or work some kind of magic in dense tree cover or high multipath environments. Some may argue that it could get a result faster, but in practical terms even that might not be the case.
High rate has been around for a long time. And like any tech, has gone through different development and adoption phases. Think about automatic transmissions for motor vehicles; they have been around in one form or another for more than a century. There was a period in the mid-20th century where the development of different approaches was promoted in marketing campaigns with fanciful product names, like Durashift, Presto-Matic, Geartronic and Torque-Flite. But rarely do you see auto transmissions highlighted with such marketing flourish since then.
High-rate RTK was never singled out like that; it is common, and any differences are mostly in how it has been adapted for different applications. I suppose a firm could choose to emphasize it for marketing purposes and give it a buzz name like “Turbo Thrusted RTK”, which his fine for marketing purposes (albeit a bit “cheugy”). Every developer and manufacturer will have slightly different approaches, but if you believe, or are led to believe, that any represent high-rate fundamentals exclusively, that would be inadvertently misleading, if not subtle gaslighting.
As one of the experts said, “It does not really matter what manufacturers claim or don’t claim. You cannot beat physics. You can only understand and manage the physics.”
Coolness Ahead
While high-rate might seem a bit old hat, where GNSS development is going is not. The developers we interviewed are more interested in highlighting their complete high-precision solutions. For example, adding inertial measurement units (IMUs) for no-calibration tilt compensation, additional sensors for imaging (and likely soon, lidar), and multiple real-time GNSS solutions complimenting RTK, such as L-band precise point positioning (PPP).
The “high-rate” that is truly exciting is that of R&D, multi-sensor integration, automation of certain elements of workflows, artificial intelligence and multi-constellation/multi-signals.
