top of page

Table of Contents

First, grasp the basics of RTK communication.

Easily Understand What NTRIP Is

Organize the equipment and roles required for RTK communication

Understand the on-site communication flow in sequence.

Learn about the causes and countermeasures for unstable RTK communication

Consider how to choose communication methods that are less likely to fail in practical operations.

Summary


First, Grasp the Basics of RTK Communication

When people become interested in high-precision positioning using RTK, many practitioners first stumble over how to handle communications. Even if they can picture the receiver’s performance and the positioning app’s screen, it’s not uncommon to proceed with implementation while remaining unclear about how to receive correction information, what to connect to where, and why communication is necessary. As a result, despite having gathered the equipment, positioning can be unstable, fail to obtain a fix, or be unusable in the field.


RTK is a method that aims for higher accuracy than standalone positioning, which determines position using only signals received from satellites. To achieve this, a mechanism is required to receive reference information separately rather than relying solely on the rover. This "mechanism to receive reference information separately" is at the center of communications in RTK. Communication is necessary in order to receive correction information in real time and reflect it in the rover's calculations.


What is important here is that RTK communication is not just a matter of simply connecting to the Internet. In practice, factors such as where the correction information is received from, which terminal is responsible for the communication, how the receiver and terminal are connected, and whether the system can withstand the radio environment at the site are all relevant. In other words, RTK communication needs to be understood not as a single configuration item but as a mechanism that supports the entire positioning operation.


Practitioners who search for 'rtk' in particular will want to know not just the theory but what is actually needed on site. Understanding which communication paths deliver the correction information, what the rover receives, why accuracy drops when communication is lost, and what to check to restore service will dramatically improve the accuracy of deployment and operation.


RTK can broadly be divided into two approaches: using your own base station, and receiving distributed correction information. NTRIP is widely used for the latter. Today, when using RTK in practice, understanding NTRIP is unavoidable. You may be able to configure equipment without knowing what NTRIP means, but to isolate the cause when communication problems occur, you need to understand the role NTRIP plays.


One reason RTK communication can feel difficult is that technical terms appear in rapid succession. Terms like base station, rover, correction information, distribution server, mount point, and communication terminal look complex when viewed only as words. However, the actual way of thinking is not that difficult. The side that has the reference position generates the correction information, which is received via communication and used by the side that measures while moving. If you break down and understand this flow, the overall picture becomes easier to see.


This article organizes RTK communication methods into six key points centered on NTRIP. Rather than merely listing word definitions, it explains what is needed in the field, how components are connected, and where problems are likely to occur. It aims to serve as an operational foundation for those about to implement RTK as well as for those who have already started using it and have concerns about communications.


An Easy Guide to What NTRIP Is

NTRIP is a system for distributing and receiving GNSS correction data over an Internet connection. It's a term that always comes up when discussing RTK communications, but you don't need to overthink it. Put in terms closer to how it's used in the field, it's easiest to understand as the rules for exchanging correction data via the Internet.


In RTK positioning, the rover does not determine its high-precision position on its own. The base station also observes the visibility of surrounding satellites and error trends, and uses that information to correct the rover's position calculations. This correction information must be delivered to the rover in real time. NTRIP is widely used as one of the ways to deliver it.


In conventional RTK, there was also a setup that used radios to send correction information directly from the base station to the rover. This method remains effective for certain uses, but it is easily affected by distance and terrain and requires special operational arrangements. On the other hand, NTRIP has the advantage that, wherever a communications link is available, correction information can be received via the Internet, making it easier to use across a wide area. In particular, for operations that do not set up their own base station each time, understanding NTRIP becomes practically essential.


If you simply divide the NTRIP mechanism, there are three parties: the provider of correction information, the relayer of correction information, and the receiver of correction information. The provider is the reference station or the origin of the correction information. The relayer plays a role similar to a distribution server. The receiver is the mobile station used in the field and the terminals connected to it. When these three parties are connected by communication, the mobile station can obtain the necessary correction information.


A commonly encountered concept here is the mount point. It is like an entry point to multiple correction streams being distributed. In practice, you choose the one that suits your purpose from a list of connection endpoints, enter your user information, and connect. If you do not select it correctly, you may be able to connect but not receive the correction information you want. In other words, it is important to understand that NTRIP is not merely a communication method, but an operational framework that includes which correction information you will receive.


Also, when using NTRIP, simply having an internet connection is not enough. It is important to have continuous, stable communication. Because RTK is highly real-time, communication delays or momentary dropouts can make it difficult to maintain a fixed solution, cause it to revert to a float solution, or reduce the stability of the positioning results. In other words, understanding NTRIP means understanding not only the mechanism of correction information but also the importance of communication quality.


Many people find NTRIP difficult, but on site it’s fine to regard it as the standard way to receive correction information over the internet. With that in mind, understanding which device receives the data, which terminal handles the communications, and which settings are required is sufficient for the practical understanding needed. Rather than memorizing fine-grained definitions of terms, knowing the connection flow and the key checkpoints for troubleshooting is more useful in the field.


Organize the equipment and roles required for RTK communication

When using RTK with NTRIP, it's often assumed that having only a receiver is sufficient, but in reality multiple roles are required. The important thing is to separate which device performs positioning, which device handles communication, and which device is responsible for display and operation. If this organization is not in place, isolating settings and checking things during troubleshooting will become difficult.


First and foremost is the GNSS receiver. This device receives satellite signals and handles the observation data required for RTK calculations. It functions as the rover (mobile station) that determines positions on site. If the receiver does not support RTK, receiving correction information cannot be used for high-precision positioning. Therefore, the first thing to check is whether the receiver you are using is configured for RTK operation.


Next, you need a terminal to secure a communication line. This may be the receiver itself having communications capability, or communication may be carried out via an external terminal. On site, configurations where the operator terminal holds the connection and forwards correction information to the receiver are often used, rather than having the receiver connect directly to the Internet. In any case, to receive correction information via NTRIP you need a device somewhere that handles the network connection.


And the terminal used to perform configuration and operation is also important. It is not just for display. It serves as the operational hub, handling tasks such as specifying the connection destination, entering login credentials, checking positioning status, and monitoring the reception status of correction information. Many of the screens that field personnel view on site are on this terminal, and it is the first place they check when communications are unstable.


Another commonly overlooked aspect is the short-range communication link between the receiver and the terminal. Correction information is not complete just because it arrives via the Internet; it must ultimately be delivered to the receiver. Therefore, a connection to transfer data between the terminal and the receiver is also required. Sometimes they are connected by cable, and other times by short-range wireless. If this link is unstable, RTK will not function even if there are no issues on the Internet side.


In practical work, when communication-related faults occur, the cause is not necessarily a single one. Even if the receiver itself is functioning normally, the terminal's network connection may be unstable. Even if the terminal's network connection is normal, the connection between the terminal and the receiver may be broken. Even if the connection itself is maintained, the NTRIP destination settings may be incorrect. In other words, to successfully perform RTK communications, not only must each device be correct individually, but the role-specific links between them must also be established.


Power management should not be overlooked in communication operations. Even if the receiver is powered on, the communication terminal may run out of power and cut off midway. Conversely, even if the terminal remains operational, the receiver’s power-saving settings can make communication standby unstable. Because continuity is important in RTK communication, ensuring that equipment continues to operate stably on site for a certain period of time is more important than the performance of each individual device.


Seen this way, what RTK communication requires is not merely a "compatible receiver" but multiple elements: positioning functionality, communication functionality, operation-checking functionality, inter-device connectivity, and power maintenance. If you understand this division of roles before deployment, on-site setup will be much smoother, and even if trouble occurs you will be able to calmly isolate the issue.


Understand the sequence of communications used on-site

To correctly understand RTK communications, it is easiest to follow what actually happens on-site and in what sequence. Here, we organize a typical flow for receiving correction information using NTRIP from an operational perspective. When the sequence is visible, it is also easier to identify where things are getting stuck.


First, the GNSS receiver picks up satellite signals. This is the starting point for positioning, not limited to RTK. However, at this stage the receiver is essentially performing standalone positioning, and high-precision corrections have not yet been applied. What matters here is that the receiver can stably track the satellites. If the sky is obstructed or the reception environment is poor, positioning will not be stable even if corrections are applied later.


Next, the communication terminal connects to the Internet. Through this connection it accesses the NTRIP server. What is required here are the stability of the connection and the user credentials used for the connection. If the connection is weak, it will repeatedly connect and disconnect, and correction data will be received only intermittently. Also, if the configuration information is incorrect, you will not be able to connect to the server in the first place.


After that, the terminal accesses the NTRIP server and receives correction information from the specified mount point. Only at this stage does the flow of correction data required by the rover begin. On site, there are cases where it "looks connected but does not Fix", and in such cases, even if the line connection is established, the correct correction information may not be being received. Do not be reassured by the display showing that you are connected—it's important to check the reception status of the correction data as well.


The received correction information is passed from the terminal to the receiver. This point is surprisingly important: even if the NTRIP connection is successful, you will not achieve RTK unless the data transfer between the terminal and the receiver is established. In other words, communication must be connected in a two-stage arrangement on both the network side and the receiver side. In practice, because this intermediate part is difficult to see, isolating the cause can be delayed.


The receiver performs RTK calculations using the satellite signals it is receiving and the correction information it has received. As a result, it can transition from Float to Fix and reliably obtain high-precision coordinates. Conversely, if updates to the correction information stop or delays increase, maintaining a Fix becomes difficult. RTK communication is the mechanism that continuously supplies data to support these calculations.


In practical work, displaying location information, recording, point-name management, and guidance indications are added to this. In other words, while the communication flow itself proceeds in the background, the user performs tasks by looking at the user-facing positioning screen. Therefore, it is important to be able to correctly read the status indicators on the screen. It is not sufficient for coordinates to be displayed alone; one must judge while watching whether it is Fix or Float, whether corrections are being received, and what the communication status is.


Understanding this flow is also useful in troubleshooting. That’s because you can check in order whether the satellite is bad, the network connection is bad, the NTRIP setting is bad, or the connection between the terminal and the receiver is bad. RTK communication feels difficult because everything seems to be working at once, but in reality you can verify it step by step. On site, following the flow one step at a time leads to the quickest resolution.


Learn the causes and countermeasures for unstable RTK communication

When you start using RTK on site, one of the most common complaints is "the connection should be working but it's not stable." Even after completing NTRIP settings and powering on both the receiver and the device, it is not uncommon for it not to Fix, to revert to Float midway, or for the connection to drop frequently. Such instability can be caused not only by equipment failure but by a weak point somewhere in the overall communication configuration.


The most common issue is insufficient mobile network quality. RTK correction data is not large in size, but it is important that it be delivered continuously and in real time. Therefore, rather than raw throughput, low latency and minimal momentary disconnections are more important. Even if there is no problem in urban areas, communication conditions can suddenly worsen in mountainous areas, around slopes or embankments, near structures, or in locations close to underground. This requires caution, because a device may indicate that communication is possible even when it is not sufficient for RTK operation.


Next, poor reception conditions are also a major factor. When discussing RTK communications, it’s easy to focus only on the network connection, but if satellite visibility is poor, corrections won’t be stable even if they arrive. The openness of the sky, nearby trees and buildings, and environments prone to reflections all have an impact. In other words, in practice it’s more accurate to think of RTK stability as the product of communication quality and reception environment.


Also, mistakes in NTRIP connection settings should not be overlooked. If there are errors in entering user information, mistakes in the destination address, or selection of an inappropriate mount point, you may think you are connected but in reality the correction information is not being used effectively. In this case, it can superficially appear that communication is occurring, which can easily cause confusion on site. During deployment, it is necessary to verify not only whether a connection can be established but also the positioning status.


Connection problems between terminals and receivers are also common. With short-range wireless connections, communication can become unstable due to interference from nearby devices, power-saving controls, or background restrictions on the terminal side. Even with wired connections, connector looseness, cable breaks, or recognition failures on the terminal side can occur. These issues are difficult to resolve with NTRIP knowledge alone, but they are extremely important in the actual field.


As a countermeasure, the basic approach is to first check the communication and reception systems separately. By looking independently at whether correction information is being received, whether satellite reception is stable, and whether the conditions required for a fix are being met, the cause becomes easier to identify. Also, even at the same site, moving your position slightly can sometimes lead to improvement, because both the communication signal and satellite visibility can be affected.


Furthermore, pre-checks before entering the site are also effective. Simply verifying the device's communication contract status, login information, connection destination settings, battery levels, and the procedures for reconnecting devices can significantly reduce on-site troubles. RTK communication problems are more likely to occur when settings are configured for the first time at the site. Routinely standardizing procedures is the quickest way to achieve stable operation.


The important thing is not to dismiss RTK communication instability as "just a fluke." Even if it seems difficult to reproduce, in many cases the reason lies in the network, the reception environment, the settings, the connections, or the power supply. In practical work you may not be able to identify the exact cause on the spot, but simply having an established sequence of checks will greatly improve your ability to respond.


How to Choose Communication Methods That Are Less Likely to Fail in Practice

When choosing an RTK communication method, judging solely on whether it is "usable" can lead to difficulties during the operational phase. In practice, what matters more than theoretical connectivity is whether it can be operated continuously and stably on site. Therefore, when selecting a communication method, you need to consider site conditions, the nature of the work, the proficiency of the personnel, and even the simplicity of the equipment configuration.


The first thing to consider is the communication environment at the worksite. The communication configuration suitable for sites located mainly in urban areas differs from that for sites that include mountainous or suburban areas. If the Internet connection is relatively stable, operating using NTRIP is very efficient. On the other hand, at sites where there are many areas out of coverage or where connections are unstable, configurations that are highly dependent on network connections become a cause for concern. In other words, communication methods should be considered according to the actual conditions at the site, not a standard desktop configuration.


Next, the complexity of the equipment configuration also matters. If the receiver, communication terminal, and operator terminal are too separate, flexibility increases but so does the likelihood of connection problems. Conversely, if the configuration is simple, setup procedures are shorter and it becomes easier to reproduce even when personnel change. In practice, the setups that are less likely to fail are not the highly functional ones, but those with fewer points to check and stable operating procedures.


Also, the choice also depends on the tasks required at the site. Whether you are measuring many points in a short time, continuously checking position while walking, or using it with a constant display for construction management, the level of communication stability required will differ. For short-duration static observations, some communication fluctuation may be acceptable, but for continuous use even a momentary disconnection can greatly reduce work efficiency.


From an operational standpoint, it’s also important to consider how much of the communication setup the person in charge can handle. Leaving decisions such as the NTRIP connection destination, user credentials, mount point selection, and reconnection procedures to on-site judgment each time makes the process prone to becoming dependent on specific individuals. By putting these into as standardized procedures as possible so that anyone will perform the same actions, you can reduce failures. Understanding how RTK communications work is important, but in practice it is just as important not to make the operation overly dependent on people’s individual understanding of the system.


Furthermore, it is important not to neglect the continuity of communication while focusing solely on positioning accuracy. RTK tends to draw attention for its theoretical high accuracy, but what truly matters in the field is the ability to maintain the required accuracy for the required duration. Therefore, when selecting a communication method, you should prioritize stability that can be reproduced in everyday field conditions rather than accuracy under ideal conditions.


NTRIP is a very convenient system, but it is not a cure-all. It only becomes effective when connection quality, the accuracy of settings, integration with the receiver, and compatibility with the field environment are all in place. Conversely, if these factors are sorted out in advance, NTRIP can significantly lower the barriers to adopting RTK. In particular, when you want to avoid installing your own base station each time and use high-precision positioning flexibly, it is a method with substantial practical advantages.


To reduce on-site failures, it's essential to choose a communication method not only as a "means of connecting" but also as part of the workflow. When you consider ease of setup, ease of reconnection, portability, and ease of verification, a truly user-friendly configuration becomes apparent.


Summary

An important part of understanding RTK communication methods is organizing and grasping where and how correction information is received, which devices play which roles, and in what order positioning is established. RTK is not determined solely by the performance of the receiver itself; it is a comprehensive operation that includes satellite reception, distribution of correction information, internet connections, the connection between the terminal and the receiver, and power management.


Among these, NTRIP is one of the primary communication methods in current RTK operations. While it may look like a complicated technical term, at its core it is a mechanism for reliably receiving correction information over the network. Simply understanding this makes it easier to make decisions when implementing it, and significantly simplifies isolating problems when communications become unstable in the field.


What matters for field personnel is not memorizing the names of communication methods, but creating a condition in which high-precision positioning can be used continuously on site. To do that, you need to be able to check at any time whether the communication link is stable, the reception environment is good, the settings are appropriate, and there is no undue strain on the connection between the terminal and the receiver. RTK communication has many aspects that are difficult to see, but if you understand the workflow step by step, the necessary items to check are by no means excessive.


If you are planning to introduce RTK, it is important to pay attention not only to the numerical positioning accuracy but also to the ease of operation, including communications. A configuration that can be used on site without hesitation every time will ultimately lead to higher productivity. In particular, if you want communication settings and high-precision positioning to be easy to handle in daily operations, it is essential to choose from a perspective that includes integration with devices and on-site handling.


If you want to make high-precision positioning more accessible on-site, considering an iPhone-mounted GNSS high-precision positioning device like LRTK is also effective. By grasping the concepts of RTK and NTRIP, simplifying the equipment configuration as much as possible, and operating it in a way that is easy to apply in practice, you can more readily unlock the value of high-precision positioning in various situations such as surveying, construction, and inspections. Understanding the communication methods is the first step.


Next Steps:
Explore LRTK Products & Workflows

LRTK helps professionals capture absolute coordinates, create georeferenced point clouds, and streamline surveying and construction workflows. Explore the products below, or contact us for a demo, pricing, or implementation support.

LRTK supercharges field accuracy and efficiency

The LRTK series delivers high-precision GNSS positioning for construction, civil engineering, and surveying, enabling significant reductions in work time and major gains in productivity. It makes it easy to handle everything from design surveys and point-cloud scanning to AR, 3D construction, as-built management, and infrastructure inspection.

bottom of page