7 Precautions to Avoid Failure When Implementing RTK

RTK is a convenient system that can handle cm-level (in-level) high-precision positioning information, and its use is spreading across many sites such as surveying, construction, as-built verification, layout marking, inspection, and facility management. High-precision positioning, which traditionally required specialized equipment and skilled personnel, has become easier to introduce in recent years due to advances in terminals and apps, and an increasing number of companies are considering it in hopes of reducing labor and improving on-site efficiency.

However, RTK is not the kind of system where you can buy equipment and immediately get results. Even if you can deploy it, in actual operations it is an area prone to failures such as "it doesn't achieve a fix as often as expected," "errors vary greatly depending on location," "positions don't match the drawings," "results vary by operator," and "in the end you end up operating both the new and the traditional methods."

Many of these failures are not because RTK principles are inherently difficult, but because the considerations that should be reviewed before deployment were overlooked. Especially beginners tend to judge solely by accuracy figures and price, but what matters in practice is whether the overall design covers site conditions, coordinate systems, communications, operational structure, training, and verification procedures.

In this article, we outline seven common pitfalls in RTK implementation and provide concrete explanations of what oversights are likely to lead to problems in the field. It is organized to be useful not only for those considering RTK deployment for the first time, but also for those who have already begun using it and feel uncertain about their operations.

Table of Contents

• Don’t choose equipment based solely on price or specifications

• Don’t base decisions too heavily on the communication environment

• Don’t be vague about handling coordinate systems and datums

• Don’t deploy without defining the operational framework

• Don’t proceed on the assumption that it can be used without training

• Don’t underestimate the impact of on-site conditions

• Don’t stop accuracy verification after the initial check

• Summary

A common early mistake when introducing RTK is choosing equipment based solely on price and specification sheets. At a glance, just seeing the term "high-precision positioning" may make all receivers seem largely the same. However, in reality, ease of use after deployment, stability, and field suitability differ greatly between devices.

A common mistake is adopting a product simply because it’s cheap, only to find it fails to meet the actual site requirements. For example, when issues occur—such as the battery not lasting long enough for extended outdoor use, insufficient resistance to rain or dusty environments, unstable connections with devices, long initialization times, or complicated settings for receiving correction information—small frustrations accumulate on site and ultimately the equipment stops being used.

On the other hand, high-spec equipment isn't necessarily the best choice. Selecting a model with more functions than necessary can increase not only the upfront cost but also the complexity of configuration and operation, to the point that on-site staff may not be able to manage it. Whether the device will be used daily by a dedicated surveyor, used by a construction manager only when needed, mainly for short position checks, or required for continuous operations such as as-built management or pile driving will affect the appropriate configuration.

A common oversight here is selecting equipment without clearly defining "what will be used for, at what accuracy, how frequently, and by whom." For example, if the task is verifying current conditions or determining approximate positions, ease of use and quick startup are important; if the main tasks are layout marking at a construction site or checking against design coordinates, then ease of coordinate management and display and on-site reproducibility become more important. You cannot judge based solely on accuracy figures.

Also, you need to consider not only the receiver itself but the surrounding components. Poles, attachments, terminals, communication methods, spare power supplies, and cases all form a single working system. Even if the receiver itself is excellent, problems such as a terminal screen that’s hard to read, unstable mounting, difficulty carrying, or difficulty operating while wearing gloves make continued use on site difficult.

Furthermore, compatibility with existing operations is crucial. If the data formats to be used after implementation, in-house drawing workflows, coordinate management of deliverables, or integration with other equipment are not compatible, it may be usable on-site but will increase work in downstream processes. Before implementation, you should consider not only the act of measuring itself but also how the measured data will be used.

In other words, to avoid mistakes when selecting equipment, it's important to judge not by "whether it has high performance" but by "whether it can be incorporated into your company's operations without difficulty." Price, accuracy, ease of use, durability, communication method, and compatibility with existing workflows must be evaluated together; otherwise, unexpected burdens are likely to arise after implementation. You should understand that RTK is an area where the choice of equipment can greatly change the likelihood of success afterwards.

Don't assume too much about the network environment

RTK uses correction information to achieve high-precision positioning. Therefore, if the communication environment is not properly designed, it tends to become the main source of post-deployment dissatisfaction. In particular, when using network RTK, implementing it on the assumption that "communication will be available" leads to problems such as an unstable Fix in the field, interrupted corrections, and long reconnection times.

A common misconception prior to deployment is the idea that if a smartphone can normally be used in a location, RTK communication will also be fine there. However, what is required on site is not merely the ability to communicate, but the ability to continuously and stably receive correction information. Even a slight tendency to be out of range can cause delays in corrections or intermittent disconnections, making it impossible to maintain a Fix. It is not uncommon for ordinary calls and messages to work fine while RTK operation is insufficient.

In mountainous areas, reclaimed or developed land, around slopes, near structures, in locations close to underground spaces, or on sites where equipment is densely clustered, communication quality can be more unstable than it appears. In addition, congestion at certain times of day, differences between carriers, heat generation from tethering devices, and power-saving controls also affect stability. Rather than relying solely on desk-based assessments before deployment, it is important to conduct communication tests at the actual site where the system will be used.

Particularly easy to overlook are the operating conditions of the correction service itself. If on-site personnel are not aware of login information management, connection endpoint settings, service contracts, the number of concurrent connections, renewal deadlines, and so on, they may find themselves unable to connect on the day they try to use it. Even if the equipment is functioning normally, it is surprisingly common for operations to be stopped by account settings or contractual restrictions, and this is a very hard-to-diagnose problem from the field’s perspective.

Also, configurations that rely solely on network RTK require caution. Even if they usually work fine, they are likely to become unstable in disaster response sites, during network congestion, in mountainous areas, or in temporary setups, creating a risk of operational downtime. You don't need a reference station at every site, but you should at least prepare alternative procedures for "what to do if communications become unstable." For example, it's important to decide in advance criteria such as whether to switch the positioning method, treat that day's measurements as reference values, or defer the work to another process.

Furthermore, when communications are unstable, personnel are more likely to mistake the cause for equipment failure or poor positioning. As a result, even though the real issue is communication quality, on-site evaluations become things like “RTK doesn’t deliver accuracy” or “this equipment is unusable.” If this misunderstanding spreads, the system that was introduced will not become established.

When deploying RTK, communications are not a peripheral concern but a core element that determines accuracy and availability. It is not enough to only check whether you are out of coverage; you need to design for the continuity of corrections, reproducibility of connections, stability of terminals, and even contract management. If you underestimate communications, they will be the first thing to cause trouble on site, so they should be prioritized and verified before implementation.

Do not be vague about the handling of coordinate systems and reference frames

The most serious failures when introducing RTK tend to result from starting operations while leaving coordinate systems and reference frames ambiguous. Even if the equipment is functioning properly, an insufficient understanding of the coordinate system can lead to situations on site where “the numbers are coming out but the positions don’t match.” This is especially hard for beginners to notice, and the later it is discovered, the greater the rework required.

In RTK, there are situations where coordinates close to the global geodetic system are used, and others where you need to compare against drawings or design data managed in the plane rectangular coordinate system. Furthermore, on some sites they use their own local coordinates or arbitrary point references. If it is not clarified which coordinate system measurements are taken in and which coordinate system deliverables are handled in, discrepancies on the order of tens of centimeters (tens of in) to several meters (several ft) can occur.

What's particularly dangerous is when on-site personnel, without fully understanding coordinate transformations or the meaning of reference frames, rely solely on the displayed values and carry out the work. Problems such as points on the drawings not matching the guidance points in the field, design lines being offset from their intended positions, or datasets measured on different days not overlapping are often caused by mismatches in coordinate systems or configuration errors. However, on-site personnel tend to suspect equipment malfunctions or positioning accuracy issues first, which delays identifying the true cause.

Another point that is often overlooked is the height reference. If the handling of elevation and height datums is not standardized, not just the horizontal position, it can lead to critical mistakes in excavation depth, installation height, and finish-level control. Cases where the horizontal position is correct but only the height is off are especially difficult for beginners to recognize and require time-consuming rechecks on site.

What is necessary before implementation is not to understand all the technical theory. What is first important is to clarify the relationship between the coordinate system your company normally uses on site and the coordinates obtained by RTK. You need to standardize—rather than leave it to individual sites—what standards to adopt for each project, which control points to use, how to reconcile with existing drawings, and what to use as the reference when outputting deliverables.

A common mistake here is deciding there is no problem because positioning could be confirmed independently during the pilot implementation phase, and only noticing the discrepancy when comparing with design data after entering full-scale operation. Initial evaluations at the introduction stage are insufficient if they merely check whether the numbers are stable; you must also verify consistency with known points, drawings, and existing results.

Furthermore, if each operator uses different setup methods, results will vary even at the same site. If one person uses the correct coordinate system while another uses the default settings, the reliability of the entire site is undermined. Therefore, it is important not to leave configuration values to individuals, but to document standard settings and verification procedures for each project.

Because RTK is highly accurate, if the reference is off it will reproduce the error with that same high accuracy. In other words, high accuracy can actually make mistakes harder to detect. When introducing it, you need to establish ahead of time a system that prevents confusion on site—not only regarding the equipment’s capabilities but also the coordinate system, known points, vertical datum, and the method for reconciling with drawings.

Do not implement without deciding on the operational structure

At sites where RTK implementation does not go well, the cause is often an unclear operational framework rather than technical problems. Even if there is excitement at the time of introduction, if it is not decided who will manage it afterward, who will configure it, and who will make decisions when trouble occurs, it will quickly fall out of use on site.

A common mistake is the belief that on-site personnel can learn as they go. Admittedly, some RTK devices are relatively easy to operate, but on-site operations involve many tasks, from power management, communication configuration, and app updates to connecting correction services, project setup, data storage, and handling anomalies. Leaving these responsibilities to the goodwill and experience of individual staff leads to inconsistent operations between sites and increased dependence on particular personnel.

For example, one operator checks known points before each task, while another omits it. At one site there are rules for data storage, while at another the data are left on the device. The handling when the correction connection is lost also differs by person—some continue work, others reinitialize. When these kinds of variations accumulate, even when using the same equipment the reliability of results becomes inconsistent.

Another major problem is the absence of a person responsible for maintenance management. Forgetting to charge batteries, failing to apply firmware updates, missing contract renewals, malfunctions after device OS updates, and loss of accessories all seem like minor issues, but on-site they directly lead to work stoppages. RTK is a precision instrument and, at the same time, a system whose results are determined by the quality of its operation. Stable operation becomes difficult when no one is overseeing the whole system.

To ensure a successful implementation, it is important to first clarify role assignments. You should decide who will perform the initial setup, who will check the coordinate settings for each project, who will store and inspect the equipment, and who will make decisions in the event of an anomaly. It is not necessary to concentrate everything on one person, but it is crucial not to leave responsibility ambiguous.

In addition, it is essential to succinctly establish operational rules. For example, simply standardizing a minimum workflow—pre-task checks, known-point verification, communication checks, Fix state confirmation, data saving, and post-task charging and logging—can greatly stabilize on-site quality. Systems used in the field should prioritize being reproducible by anyone over creating ideally detailed rules.

What is even easier to overlook is how to evaluate things after deployment. If you stop at merely implementing it, you won’t be able to see which sites are working well and where problems are occurring. In the first few sites, you need to review trends in measurement error, the conditions under which communication failures occur, assessments of usability, training-related issues, and so on, and reflect those findings in the operational rules.

RTK does not derive its value from the performance of the equipment alone; it only becomes valuable once it is completed as a system that can be used reliably on site. Before deployment, it is extremely important—not only to compare products but also to consider who will use it and how, how it will be managed, and how to recover when problems occur, in order to prevent failure.

Do not proceed on the assumption that it can be used without training.

A surprisingly common mistake when implementing RTK is skipping training because the operation looks simple. It is true that recent devices and apps are easier to use than before. However, appearing easy to operate and being able to use them correctly in the field are two different things. If you confuse the two, accuracy problems and operational errors will frequently occur after deployment.

In RTK, at a minimum you must understand the difference between Fix and Float, the effects when correction information stops, the necessity of reinitialization, the meaning of checking known points, and the importance of coordinate settings. If you use it without knowing these things, you may be reassured simply because a position is displayed on the screen and risk continuing work in a poor-quality state.

Beginners tend to struggle less with operating the equipment itself and more with understanding what the displayed information means. For example, if they cannot determine whether the positioning status is stable, whether the current reading can be accepted as a result, or whether a situation requires rechecking, they cannot guarantee the reliability of the work. In other words, training needs to include not only explanations of button operations but also the sharing of criteria for on-site judgment.

Also, insufficient training creates inconsistency among staff. If only knowledgeable people can use it, sites without them cannot operate it. Conversely, if multiple people start using it with only a shallow understanding, incorrect practices will spread. Either way, it will not lead to organizational adoption.

In on-site implementation, it is not necessary to provide perfect technical training from the start, but at a minimum you should establish a shared understanding of what is required for practical work. For example, it is important to confirm in advance—even briefly—basic rules such as "when it is acceptable to take measurements," "when it is not," "which values to look at to make a judgment," and "what to suspect when measurements do not match the design coordinates." Even this alone can prevent many initial problems.

Furthermore, training provided only once at the time of implementation is insufficient. Even if people understand at first, they tend to adopt their own ways on site, and after a while the procedures break down. Therefore, at a few sites during the early phase of implementation, there needs to be opportunities to observe actual work and correct operational variations. Desk-based explanations alone do not lead to retention; understanding deepens only when linked to concrete failure examples from the field.

One thing to pay special attention to is administrators leaving everything up to the field. If only on-site personnel are trained and managers do not understand the decision criteria, implementation evaluations and troubleshooting will become ambiguous. RTK is not only a field tool but also a system that relates to quality control. Therefore, it is desirable that managers, as well as field users, have at least a basic understanding.

If training is omitted, things may appear to be working at first, but when problems occur the causes become unclear, leaving only impressions such as "hard to use," "unstable," or "not as accurate as expected." In many cases the issue is not equipment but a lack of operational understanding, so it is important to treat training at the time of deployment not as a cost but as a condition for success.

Do Not Underestimate the Impact of the On-Site Environment

RTK offers high precision, but it is not foolproof. If you underestimate the impact of on-site environmental conditions during deployment, you can easily end up in a situation where "it should work according to the specifications, but in the field it is not stable." In particular, beginners tend to assume from spec sheets and demo environments that it will work the same everywhere. However, in practice the stability of positioning is greatly affected by site conditions.

One common problem is poor sky visibility. Near buildings, under trees, beneath bridges, along slopes, around heavy machinery, and in areas with many steel members or equipment, satellite signal reception conditions tend to deteriorate. This can delay initialization, prevent maintaining a Fix, or cause readings to become slightly unstable. Because the deviations may not be large enough to be visibly obvious, inexperienced personnel can have difficulty noticing the problem, which is particularly troublesome.

Also, the effects of multipath are an element that is easily overlooked. In environments with many reflections, the position can be disturbed not only by the direct wave but also by reflected waves. Special caution is needed near buildings in urban areas and at sites with many metal surfaces. Under such conditions, even if positioning appears to be established, stability and