What's the difference between RTK and RTCM? 3 things you need to know to understand the data

Table of Contents

• First, understand what the difference is between RTK and RTCM.

• Knowledge 1 RTK is a positioning method, RTCM is a data format for correction information

• Knowledge 2 RTCM and NMEA are used for different purposes

• When configuring Knowledge 3, consider communication paths, output content, and the handling of coordinates separately

• Points commonly confused on-site

• How will operations change when RTK and RTCM are properly understood?

• Summary

First, understand the difference between RTK and RTCM

RTK and RTCM are both terms commonly encountered in high-precision positioning, but they operate at different levels of meaning. If you confuse the two, it can easily cause confusion in equipment selection, connection setup, and troubleshooting.

RTK is a positioning method used to achieve high-precision satellite positioning. Rather than the mobile receiver receiving satellite signals on its own, it receives correction information from a reference station installed at a known point or from a network-based correction service, aiming for centimeter-level positioning while reducing positioning errors. In other words, RTK refers to the method itself for how to obtain positions with high accuracy.

RTCM, on the other hand, is a representative data format for exchanging the correction information used by RTK. It is easier to understand if you think of it as the format or the message rules used when delivering correction data generated at the reference station to the rover. In other words, RTCM is often the data representation used to make RTK work.

If you rephrase this difference in field terms, RTK is the operational method, and RTCM is the format of correction data that flows within that method. For example, when someone on site says "RTK won't connect," the actual response depends entirely on whether the communication link is down, RTCM from the base station is not being received, the NMEA output is not configured correctly, or a fixed solution is not being obtained. Yet if you treat all of these as the same thing, you won't make any progress in isolating the cause.

In practical work, it's important to get into the habit of distinguishing positioning methods from data formats. When you see the term RTK, first confirm whether it refers to the positioning mechanism. When you see the term RTCM, then consider whether it's about settings related to the transmission or reception of correction data. If the term NMEA appears, organize your thinking to treat it as possibly being about outputting position results or interoperability between devices. Simply being able to separate these three in your head makes on-site understanding much more stable.

What beginners in high-precision positioning often stumble over is believing that simply deploying RTK equipment will automatically provide centimeter-level accuracy (cm level accuracy, half-inch accuracy). In reality, stable operation only becomes possible when several factors align, such as satellite reception conditions, reception of correction information, communication between devices, positioning status, coordinate settings, and output formats. Among these, RTCM is an important element responsible for transferring correction information, but understanding only RTCM does not give you a view of the whole RTK system. Conversely, even if you only know the term RTK, operations will be unstable if you do not understand the contents of the correction data and the reception conditions.

In this article, to understand the differences between RTK and RTCM in a way that can be used in practice, we organize the necessary knowledge into three parts. By covering the role of correction information, the relationship with NMEA, and precautions when configuring systems, you can reduce common misunderstandings on site and make it easier to decide on connections and operations.

Knowledge 1 RTK is a positioning method, RTCM is a data format for correction information

If you clarify the difference between RTK and RTCM at the most fundamental level, RTK is a positioning method and RTCM is a way of representing correction information. This understanding is the foundation for everything.

In RTK, not only the satellite signals received by the rover (mobile station) but also the observations made by the base station are used to correct errors. Satellite positioning is affected by various error sources, such as satellite clock errors, atmospheric effects, satellite orbit errors, and influences from the reception environment. These errors cannot be fully eliminated with standalone positioning, but when a base station observes satellites from a location with known coordinates and sends the differences and the information needed for corrections to the rover, it becomes easier to determine the rover’s position with higher accuracy. This is the idea behind RTK.

What is important here is that RTK is not simply a matter of having correction information available. Even if correction information is received, issues such as poor satellite visibility, strict distance constraints to the base station, unstable receiver tracking, insufficient initialization, or large communication delays can prevent a Fix solution from stabilizing and the expected accuracy from being achieved. In other words, RTK is an operation that only works when multiple conditions, including correction information, are all satisfied.

In this context, RTCM is a standardized message format for exchanging that correction information between receivers. A reference station outputs the satellite observations it made and the information required for corrections in RTCM format, and sends that to the mobile station via communication links, radio, or the Internet. The mobile station interprets those RTCM messages and uses them in its internal positioning calculations. RTCM itself is not a position result; it is merely material used to obtain a more accurate position.

Understanding this point makes on-site conversations easier to organize. For example, the question "Has RTCM arrived?" is a question to check whether the flow of correction information is active. On the other hand, the question "Are you getting an RTK fix?" checks whether the positioning result using the correction information has entered a high-precision state. The difference is that the former is closer to confirming communication or data delivery, while the latter is closer to confirming the positioning status.

In practice, a common point of confusion is assuming that the arrival of correction information and the success of high-precision positioning are the same thing. In reality, even if RTCM can be received, a fix may not be obtained. For example: when the contents of the received RTCM do not match the receiver settings, when messages from the required satellite constellations are missing, when antenna installation conditions are poor, or when there has not been enough initialization time. Conversely, when RTK is unstable, the cause is not necessarily that RTCM distribution has stopped.

Let's take a more practical look at the role of correction information. Correction information used in the field is often understood as something that simply adds or subtracts numerical errors, but in reality it contains various pieces of information related to satellite observations. The receiver uses that information to process carrier-phase and code observations, contributing to ambiguity resolution and the stabilization of position calculations. This is a part that is hard for users to see, but it is useful to think of RTCM as supplying the materials the receiver needs to perform high-precision computations internally.

Also, RTCM does not operate in isolation; it must be considered together with the communications path. Common field configurations include transmitting directly from a base station by radio, receiving a network-type service over the Internet, or passing data to the receiver via another device using Bluetooth or serial. In any of these configurations, RTCM is often used as the format of the correction data that the mobile station ultimately receives, but the intermediate communication paths vary. Therefore, what was thought to be an "RTCM setting" problem is often actually caused by being outside cellular coverage.

In practice, the term RTK is also widely used as a product name or feature name, which makes things even more confusing. Even if a receiver's catalog states that it is RTK-capable, that only means it can handle the mechanisms required for high-precision positioning; you still need to separately confirm which communication method will be used to receive corrections, which RTCM messages it supports, and in which output formats it can deliver coordinates externally. If you decide on field operations based solely on the label "RTK-capable," you may find after deployment that configuration is insufficient or that there are compatibility issues.

On the other hand, simply seeing a label that it supports RTCM does not necessarily mean it will deliver adequate performance in the field. This is because the supported versions and messages, satellite systems, and input/output conditions can vary between devices. In other words, RTK and RTCM are both important, but they are not the same, and the aspects you need to check differ.

If you have this knowledge, conversations about equipment selection and troubleshooting become more concrete. When high-precision positioning cannot be achieved, first break RTK down into its components and consider them. You can check in order: the satellite reception conditions, whether correction information is being received, whether that correction information is appropriate as RTCM, whether the positioning state is Float or Fix, and which coordinate system the reported position is in. The first step in this kind of fault isolation is understanding that RTK is a method and RTCM is a data format.

Knowledge 2: RTCM and NMEA are used for different purposes

When trying to understand the difference between RTK and RTCM, another relationship you should definitely clarify is the one with NMEA. On-site, the configuration screens for RTCM and NMEA are often displayed side by side, and because both relate to position information, their roles can appear similar. However, in reality, the two serve very different purposes.

As explained earlier, RTCM is a data format for exchanging correction information. Its primary role is to deliver the information required for high-precision positioning from reference stations and correction distribution services to mobile stations. The mobile station uses that information in its internal computations to determine a more accurate position.

On the other hand, NMEA is widely used as an output format to convey to external systems the position, time, speed, heading, satellite status, and other information requested by the receiver. In other words, whereas RTCM is input-side information for positioning, NMEA is often treated as output-side information for presenting positioning results externally.

Put practically, RTCM is the material used inside the receiver to enable high-precision computations, while NMEA is like the report used to pass the results of those computations to other devices or apps. For example, it is very common for a GNSS receiver to receive RTCM from a network correction service, perform RTK calculations internally, and finally pass the resulting current position to a tablet or a construction app via NMEA. In this case, RTCM and NMEA, although part of the same system, play completely opposite roles.

A common confusion among beginners is that, because NMEA also contains position and time, they assume it itself is correction information. However, NMEA normally conveys positioning results and status already computed by the receiver, and is not the raw data used for correction calculations. Therefore, the presence of NMEA output does not necessarily mean that RTK corrections are being received correctly. Conversely, even if RTCM is being received correctly, if the NMEA output settings are insufficient, external applications may not be able to properly obtain the current position.

At job sites, you may encounter a problem where correction data is being received but the position in the app is not being updated. In this case, even if RTK computations are succeeding inside the receiver, the NMEA output port, communication destination, output frequency, or the types of NMEA sentences required may not be correct. In other words, RTCM is normal and RTK is established, but NMEA-side misconfiguration makes it unusable. Conversely, even if a position is displayed in the app, using it without confirming whether it is a standalone positioning coordinate or an RTK Fix coordinate can lead to significant misunderstandings about accuracy.

To understand the relationship with NMEA, it's helpful to arrange the data flow in your mind as a one-way sequence. First, satellite signals are received. Next, RTCM is received as correction information. Positioning calculations are performed inside the receiver. The results are then output externally via NMEA and similar formats. In this flow, RTCM is the input, RTK is the computation method, and NMEA is the output.

What is important in practice here is that the contents of NMEA alone may not be sufficient to fully assess the quality of high-precision positioning. If you only look at the coordinate values of the position information, it may at first glance appear to be behaving plausibly, but you must check the quality information as well — for example, whether it is a Fix or a Float, whether the number of satellites is sufficient, and whether there are annual variations or temporary unstable conditions. In construction and surveying, the quality at which a position is provided is often more important than the mere fact that a position is available.

Also, NMEA contains many sentences, and the information required can differ depending on the device or app. Because the necessary position sentences may not be output, information about positioning status may not be interpreted, or the update rate may not match what the app expects, simply turning on NMEA output is insufficient. Unlike RTCM, NMEA is involved in integration with external systems, so problems may not be visible on the receiver alone and often only surface at the connected system.

To sort this out in the field, it is helpful to consciously consider each time what the data is for. Simply thinking about whether the data is for applying corrections, for passing on results, for a device’s internal computations, or for display by external software makes the roles of RTCM and NMEA considerably clearer.

Furthermore, the relationship between RTK and NMEA is another area that is easily misunderstood. RTK is a method, not an output format. Therefore, the phrase “output in RTK” is, strictly speaking, somewhat ambiguous. In practice, the results computed by RTK are output in NMEA or proprietary formats. With this understanding, when looking at a receiver’s specifications you can check RTK support and NMEA output support as separate items.

A common on-site example is that, even though the base station is sending RTCM, the rover does not get a fix, so people try to address it by changing NMEA settings. However, adjusting NMEA does not solve the root cause when corrections are not being applied. Conversely, reviewing RTCM messages will not help if an external app cannot read the position and the cause is insufficient NMEA output. In other words, both RTCM and NMEA are important, but they need to be checked in different situations.

From a practical standpoint, it’s easier to think of RTCM as the behind-the-scenes data that enables high precision, and NMEA as the front-end data that conveys position to field systems. If the behind-the-scenes part is not functioning properly, you won’t get high precision, and if the front-end is not functioning properly, you can’t use that high-precision position in your operations. In RTK operations, it only becomes practical when both are in place.

Knowledge 3 When configuring, consider communication paths, output content, and handling of coordinates separately

Even if you understand the difference between RTK and RTCM, in actual fieldwork you often get stuck on settings. The reason is that the settings screens mix multiple elements such as communication, corrections, positioning, output, and coordinates. In practice, it becomes easier to organize things by thinking of the settings in three parts. First, the communication path — how correction information is received. Second, the output content — how positioning results are passed to external systems. Third, the coordinate concept — the reference used for that position.

First, the communication path. RTCM is meaningless as correction information unless it actually reaches the rover. Therefore, the first thing to check is where and via which route the corrections will be received. Whether they are transmitted wirelessly from your own base station, received via mobile communications from a network correction service, or passed to the receiver through a smartphone or controller will change the likely causes of trouble.

For example, when using a network-based setup, even if the receiver itself is operating normally, RTCM may not be received due to being out of coverage, an unstable connection, tethering disconnection, incorrect authentication information, and so on. In this case, the problem lies in the communication path rather than in the positioning computation. Conversely, with a base-station radio system, antenna direction, output, obstructions, and distance conditions become dominant. Therefore, when you find an RTCM-related issue, it is important to check the path before the format.

Next is the output content. Even if the receiver receives RTCM and succeeds in RTK positioning, work will not proceed unless the results are delivered correctly to on-site applications and equipment. Here, output settings such as NMEA are important. You need to confirm which communication port, at what interval, and which sentences are being output, and whether they contain the information required by the connected equipment.

In practice, you may encounter cases where the receiver's own status display indicates Fix, yet the position on the tablet map appears shifted, updates are slow, or quality indicators do not appear. In such situations, the receiver's internal RTK processing may be working correctly, but the output may be inadequate. If the output content is neglected, the high-precision positioning cannot be leveraged by the field system.

The third point is the handling of coordinates. This is an area that tends to cause failures in practice even after one’s understanding of RTK and RTCM has progressed. RTCM is a format for correction information, and NMEA is an output format for position results, but you still need to separately confirm which coordinate system, which height reference, and which transformation conditions are being used. What is often required on site is coordinates that are consistent with drawings and design values rather than just how they appear on a map, so merely obtaining a position fix is not sufficient.

For example, even if the receiver has a proper fix, if positions are being handled according to a datum different from the drawing coordinates used on site, the whole set will appear shifted when you drop points. In such cases it is not that RTCM or NMEA is at fault; rather, coordinate transformations, projection settings, or the handling of the reference surface may not match. Beginners tend to conclude at this point that "the correction is wrong," but in reality the hierarchy of settings is different.

When configuring, it is particularly important not to treat reception, computation, output, and coordinates as a single problem. For example, when the position doesn't match, check in order whether corrections are being received, whether you have a fix, whether the output is correct, and whether the coordinate settings are correct. If you start changing settings without following this order, you may end up altering items that are not problematic and thereby worsen the situation.

Also, when combining multiple devices on-site, you need to make it clear which device is responsible for what. If the division of roles—whether the receiver receives RTCM and performs RTK calculations, an external terminal handles only communications, or the app receives NMEA for map display—is unclear, it will be impossible to identify the party responsible when problems occur. In particular, in setups that use Bluetooth connections, correction reception and position output may be running on different ports or separate sessions, so it is important not to be reassured by surface-level connection status alone.

It should also be noted that the optimal settings can change depending on field conditions. In obstructed urban environments, areas in the mountains with unstable communications, continuous monitoring of moving platforms, or high‑precision checks at fixed points, the settings you should prioritize differ with the intended use. Increasing the update frequency will improve apparent responsiveness, but external applications may not be able to keep up. If you cut necessary correction information just to reduce communication load, it can affect positioning stability. Therefore, settings should not be copied mechanically from a template; they must be made with an understanding of their meaning for the specific use.

To stabilize settings on site, it is effective to standardize the initial checklist. By checking in the same order every time—whether correction reception is present, the time to reach a Fix, satellite status, output updates, position agreement in external apps, and a simple verification at known points—you will more easily identify where anomalies occur. Those who understand the difference between RTK and RTCM tend not to tinker blindly during setup; they first determine which layer the problem belongs to before taking action.

If you have these three pieces of knowledge, on-site conversations become clearer. You will be able to check separately: "Is RTCM not being received?", "Is RTK fixed?", "Is NMEA being output?", "Are the coordinates correct?", which speeds up root-cause isolation. In high-precision positioning operations, this ability to isolate issues is what determines operational quality.

Common Points of Confusion at the Worksite

Even if you think you understand the difference between RTK and RTCM, in practice similar terms and symptoms often appear together, causing renewed confusion. Here, we will outline the confusions that are particularly likely to occur in the field.

The most common mistake is to equate receiving correction information with having obtained a Fix solution. People tend to feel reassured when there is an indication that corrections are coming in, but that alone is not sufficient. Correction information is merely input for the calculation and does not guarantee a final high-precision state. If satellite reception, the receiver’s initialization status, local obstructions, conditions with the reference station, and so on are not all in place, the solution can remain in Float. Therefore, the presence of correction reception and the positioning status must be checked separately.

Another common misconception is to assume that a displayed position and a high-accuracy position are the same. When the current position is visible on an app or map, it feels like it can be used on site. However, accuracy varies greatly depending on whether that position comes from standalone positioning, is equivalent to DGNSS, RTK Float, or RTK Fix. Rather than focusing on whether it is displayed, you need to check what quality level it is being displayed at.

Also, it's dangerous to assume that corrections are working just because NMEA is being output. NMEA is the output of the result, so if at least a basic position is being output it can be displayed. However, RTCM may have been cut off in the background and accuracy degraded. In other words, the fact that a position is visible is not necessarily proof that corrections are active. Conversely, even if corrections are being applied correctly, insufficient NMEA output settings can prevent external equipment from seeing the position.

Furthermore, it is a common misconception to assume that all coordinate offsets are due to correction errors. When the site measurements do not match the drawings, one tends to suspect RTCM or RTK first, but in reality the causes can include differences in coordinate system settings, inconsistencies in vertical datums, how transformation parameters are handled, and differences in the reference used for known control points. In high‑precision positioning, differences of a few centimeters to several tens of centimeters can affect work quality, so if the hierarchy of causes is misidentified, the issue cannot be resolved.

Misreading device specifications is one common source of confusion. There are cases where people assume that simply because a device is described as "RTK-compatible" it will interoperate without issues with any correction service or external app. However, in practice you must verify the communication method, supported correction input, NMEA output conditions, connection ports, update rate, app compatibility, and so on. When reading a specification sheet, you should distinguish which function RTK, RTCM, and NMEA each refer to.

To prevent this kind of confusion, it is effective to always ask which layer the issue pertains to when a problem occurs. Simply distinguishing whether it is a correction-input issue, a positioning-computation issue, a result-output issue, or a coordinate-operation issue reduces unnecessary trial and error. Especially in the field, where recovery often must be carried out within a limited time, this ability to organize directly translates into work efficiency.

How Will Operations Change When RTK and RTCM Are Properly Understood?

Correctly understanding the difference between RTK and RTCM doesn't stop at knowing the meaning of the terms. It affects field operations, equipment selection, troubleshooting, and even the ease of training.

At the equipment installation stage, the necessary items to check become clear. For the purpose of achieving high-precision positioning, you will be able to confirm not only whether the receiver supports RTK, but also which correction inputs it can accept, what the RTCM reception conditions are, in what format it can output positions to external terminals, and how it will integrate with existing systems. This helps reduce failures after deployment such as being unable to connect, unable to output, or failing to achieve the expected accuracy.

Furthermore, on-site setup becomes faster. If you confuse RTK and RTCM, when a problem occurs you tend to start changing any settings that might be related. However, if you understand the difference, you can check in order: first the correction reception path, then the Fix status, next the NMEA output, and finally coordinate alignment. Simply following this order can greatly speed up on-site recovery.

It is also effective from an educational standpoint. For personnel newly dealing with high-precision positioning, explaining it as a three-layer structure—RTK as the mechanism, RTCM as the format of corrections, and NMEA as the output of results—makes it easier for understanding to take root. Conversely, if you teach while mixing up the terms, people often cannot make sense of connection screens or logs and end up merely memorizing operations. Because personnel frequently change on-site, being able to provide reproducible training is of great value.

In terms of operational quality, the approach to known-point verification and daily start-of-day inspections also changes. Rather than simply checking whether a position is produced, a habit develops of confirming whether correction reception is stable, whether the behavior up to Fix is normal, and whether the output coordinates are being handled by the business system as intended. Changing operations in this way makes it easier to prevent mid-task drift and rework at an early stage.

Also, the way problems are reported becomes more specific. Instead of saying "the position shifts," you can describe issues like "corrections are being received but it doesn't achieve a fix," "it has a fix but the external app doesn't receive the position," or "the position is received but doesn't match the drawing coordinates," which makes interactions with internal teams and support more efficient. Understanding the terminology is not merely a matter of knowledge; it also affects the accuracy of on-site communication.

High-precision positioning is convenient, but because it often appears visually as just a single current-position marker, it’s a technology whose internal workings are easy to ignore. That’s why it’s important to understand the distinct roles of RTK, RTCM, and NMEA, and to be able to tell which layer is experiencing a problem. With this understanding, high-precision positioning becomes easier to use reliably as a tool in the field.

Summary

The knowledge needed to understand the difference between RTK and RTCM is not about memorizing a large number of difficult technical terms. The key point to grasp first is that RTK is a method of high-precision positioning, and RTCM is a representative data format for the correction information used for that purpose. Simply understanding this difference makes it easier to organize how positioning works and the role of the data.

Next, the relationship with NMEA is important. RTCM is the data that goes into the receiver as correction information, while NMEA is the data that delivers the computed position results externally. Both relate to positioning information, but their roles are significantly different. Even if corrections are functioning normally, insufficient output settings make the system unusable for operations, and even if a position is displayed, if corrections have stopped the accuracy cannot be guaranteed.

And in practice, it is important to consider settings separately for communication paths, output content, and handling of coordinates. By checking separately whether corrections are not being received, whether a fix is not being obtained, whether results are not being output externally, or whether coordinate transformations are incorrect, you can speed up root-cause isolation and reduce unnecessary configuration changes.

To operate high-precision positioning stably in the field, the starting point is to avoid treating RTK and RTCM as the same thing. Understand positioning methods and correction data formats separately, and if you can also clarify the differences in roles with NMEA, the quality of equipment selection, configuration, and troubleshooting will improve. High-precision positioning is a field where organizing terminology directly translates to on-site quality. First, using three fundamental areas of knowledge as a foundation, create an operational workflow that lets you verify, step by step, the flow of correction information, positioning status, outputs, and coordinates—this is the quickest route to stable RTK use.