Fixed Solution, Wrong Coordinates?

Understanding VRS and Solving Common CORS Problems

Zoe Zhao, Tersus GNSS      14 July, 2026

If you've been doing RTK surveying for a while, you've probably run into this before: your CORS account hasn't expired and your network is fine, but you just can't get a fixed solution; or everything worked perfectly yesterday, but today when you power on, your coordinates are off by over 10 centimeters; or you're sure you've set the correct coordinate system, but the points you're measuring are still wrong. Behind all these "mysterious" problems, there's actually a clear logic to follow.

This article explains the three most common CORS problems: can't connect, cannot get fixed, and fixed but wrong coordinates, along with a practical troubleshooting workflow for each:can't connect, cannot get fixed, or gets fixed but coordinates are wrong, how to troubleshoot them step by step, and what tools can save you time and effort.

1. VRS Dynamic Behavior: Why Does the Base Station "Change Every Time"?

Before we get into specific troubleshooting, it's important to understand how VRS (Virtual Reference Station) works—many seemingly "abnormal" behaviors are actually normal characteristics of VRS.

The core of VRS technology is this: the data center generates a "virtual" base station near your location based on the approximate position (GGA) you upload, then sends virtual observation data to you. The virtual base station is typically a few meters away.

 | So why does the base station seem different every time?

Because your position at each startup (the approximate coordinates you send) may be different, and the data center generates a new virtual base station based on your current location. So at different times and different starting positions, both the virtual base station's location and the baseline distance may vary.

But note: this variation is normal. What really matters is whether you're measuring the same physical point. For the same physical point, no matter how the virtual base station changes, as long as your coordinate system settings are correct, the final computed coordinates should be consistent. VRS algorithms are designed to give the same coordinate result for the same physical point even when the virtual base station changes.

So what exactly does "correct coordinate system settings" mean? It refers to the coordinate frame (e.g., WGS84), projection parameters (central meridian, etc.), and height system (ellipsoidal height vs. orthometric height) configured in your data collector software. In practice, height-system mismatches are often responsible for much larger errors than horizontal coordinate system mistakes. These parameters together determine how your device converts the raw observations from CORS into the final displayed coordinates. As long as these settings are consistent with the coordinate system broadcast by your CORS provider, measuring the same point at different times will yield consistent results.

 | VRS Types: Traditional VRS vs. Grid VRS

There are different types of VRS. The strict definition of traditional VRS generates a virtual base station in real-time for each individual user—it offers the highest accuracy but puts significant load on the server. Grid VRS, on the other hand, pre-generates virtual base stations at fixed grid spacing over the service area, and users simply use the pre-generated virtual base station of the grid cell they're in. This supports massive concurrency but may introduce interpolation differences near grid boundaries, depending on implementation. In this article, we're focusing on VRS services. Other modes like single-base CORS, MAC, and FKP aren't covered here—VRS is one of the most widely deployed network RTK approaches today.

| How Often Does VRS Update the Virtual Base Station?

This is a common question. In practice, VRS virtual base station updates aren't based on a fixed time interval—they're triggered by position changes.

When you move to a new location, you need to upload a new GGA (approximate position) to the data center, which then generates a new virtual base station. The generation itself happens on-demand in real-time—each time you upload GGA, the server may recompute the virtual base station. Actual strategies vary by provider:

• Some providers only regenerate VRS when the GGA position changes beyond a certain threshold (e.g., 5 km of movement)

• Some providers recompute with every GGA upload, though this puts more pressure on the server and requires more sophisticated data broadcasting strategies

• Grid VRS uses pre-generated virtual stations at fixed grid points—users get whichever grid cell they're in
  

  
  

Many experienced surveyors choose to reconnect after moving several kilometers, although the actual threshold depends on the VRS implementation.

As the rover moves farther away from the location used to generate the current virtual reference station, spatially correlated errors become less effectively modeled. Reconnecting allows the network to generate a new virtual station closer to the rover, helping maintain RTK performance.

2.  RTCM 1021-1027 and Coordinate System Settings: First Figure Out Whether Your CORS Broadcasts Them

Now that we understand how VRS generates differential data, we need to tackle a more fundamental question: how do the raw data actually become the coordinates you see on your data collector?

The answer lies in a specific set of RTCM messages—1021 through 1027—which are specifically designed to broadcast coordinate system transformation parameters.

• Control messages containing Helmert or Molodensky transformation parameters

• Ellipsoid shift grid residuals

• Projection parameters (1025 is the Transverse Mercator projection, the most commonly used)
  

When RTCM coordinate system transmission is implemented, RTCM specifies that transformation, residual grid and projection information should be transmitted through a defined set of messages (1021-1027). However, many modern CORS networks do not broadcast these messages and instead provide coordinate system information through documentation or network configuration.

So the problem falls into two categories:

Case 1: Provider broadcasts RTCM 1021-1027 + Data collector supports decoding

Your device will automatically read the transformation parameters from these messages and complete the coordinate system conversion. You don't need to manually set coordinate system parameters—this is exactly the value of RTCM 1021-1027: saving you the hassle of manually entering seven-parameter transformations, projection parameters, and other complex settings.

Case 2: Provider does NOT broadcast 1021-1027, or the data collector doesn't support decoding

This is the most common situation. Many CORS systems don't broadcast these messages, or your data collector software may not support decoding them (though most mainstream software now supports 1021, 1023, and 1025, some older ones still don't).

In this case, you must manually set the coordinate system parameters—properly configure the coordinate frame (e.g., WGS84, etc.), projection parameters (central meridian), height system, and so on in your data collector software. If these parameters are wrong or missing, even with a fixed differential solution, your measured coordinates will be incorrect.

As for whether your CORS provider actually broadcasts this set of messages and whether your data collector is decoding them correctly—we'll leave that for the troubleshooting section later. For now, just remember: if they broadcast and decoding is supported, it's automatic; if not, manual input is required.

3.  Step-by-Step Troubleshooting: From Tools to Methods

Here's the core of this article—a complete troubleshooting roadmap covering the entire chain: can't connect → connected but no differential → fixed but coordinates are wrong.

| Step 1: Check Network and Account—The Basics Are Most Often Overlooked

• Is the network on your data collector or phone working? Some carriers have better coverage in certain areas
  

• Has your CORS account expired? Have you reached the concurrent user limit?
  

• Is the port correct? Different ports typically correspond to different coordinate frames
  

• Is the mountpoint correct? Different mountpoints correspond to different data formats

| Step 2: Third-Party Tools for Cross-Checking—Desktop strsvr or Mobile Ntrip Client

strsvr from RTKLIB is a powerful tool for troubleshooting CORS connection issues.

strsvr (RTKLIB) can verify account access, inspect RTCM message types, and record correction streams for later analysis.

If you're in the field without a computer, you can also use a mobile Ntrip Client for basic checks: verify that GGA is being uploaded properly (without GGA, the server doesn't know your location and won't send differential data—this is why many "connected but no differential" issues occur), monitor whether differential data flow is stable, and check whether the solution state is single-point, float, or fixed. However, deep-dive analysis like checking RTCM message types still requires strsvr.

| Step 3: Troubleshooting Reference Table

For CORS issues, just match your symptom to the table below:

| Remember two key concepts

Whether differential data arrives—either the rover's request has a problem (GGA isn't uploading properly, so the server doesn't know where you are), or the server's broadcast has a problem (account permissions, mountpoint configuration, or server-side data stream anomalies). During troubleshooting, first confirm that GGA is successfully reaching the server, then check whether the returned differential data is being received by the data collector.

Whether the final coordinates are correct—either there's a problem with the data collector settings (coordinate frame, projection, height system don't match what CORS broadcasts), or there's a problem with the CORS side not correctly delivering coordinate system parameters (they're not broadcasting RTCM 1021-1027, or the data collector doesn't support decoding them). During troubleshooting, first confirm the coordinate frame CORS broadcasts, then systematically check your data collector's coordinate system settings against it.

Once you understand where the differential data comes from and how the coordinates are computed, you'll have a clear direction for troubleshooting most CORS issues.