Virtual reference station (VRS) explained: how network RTK creates corrections

What is a virtual reference station?

A virtual reference station is a simulated GNSS base station that a network RTK server creates close to your rover's position. No physical receiver stands at that point; the server generates the observations a real base would have recorded there, using data from the permanent stations around you.

The idea solves the main weakness of single-base RTK. With one base, errors from the ionosphere, troposphere and satellite orbits decorrelate as the rover moves away, so accuracy falls and initialisation slows with distance. An RTK network of continuously operating reference stations (CORS) measures those errors across a whole region. The server interpolates them to your location, so your rover always works against a "base" only a few metres away.

Surveyors often call the service "VRS GPS" or simply network RTK. Strictly, VRS is one of several network RTK methods; the others (MAC and FKP) are described below. The transport layer, NTRIP, and the role of CORS are covered in our NTRIP and CORS explainer, so this article focuses on how the virtual base itself is built.

How does VRS work step by step?

VRS works as a continuous loop between your rover and the network server: the rover reports where it is, the server computes corrections for a virtual base at that spot, and the rover uses them like a normal RTK stream.

1. Reference stations log data. Every CORS in the network streams raw multi-constellation observations to a central processing server, usually at 1 Hz.
2. The server resolves the network. Because station coordinates are known precisely, the server fixes ambiguities between stations and estimates the distance-dependent errors: ionospheric delay, tropospheric delay and orbit error.
3. The rover connects. Your receiver or controller logs into an NTRIP caster with a username, password and a VRS mountpoint.
4. The rover sends its position. It transmits an NMEA GGA sentence with its approximate autonomous position, typically every 1–10 seconds.
5. The server creates the virtual station. It places a virtual reference station at or near the reported position and computes the observations a base there would see, by applying the interpolated error model to data from the nearest real station.
6. Corrections stream back. The server sends RTCM 3.x messages for the virtual base. The rover resolves ambiguities over a baseline of only metres and reaches a fixed solution.
7. The rover keeps reporting. If you travel a long way from the virtual point, some networks generate a new one, which can cause a brief re-initialisation.

Because step 4 is essential, VRS will not work over a one-way broadcast link such as UHF radio. It needs mobile data or another internet connection in both directions.

VRS vs single-base RTK: what is the difference?

The difference is where the reference data comes from: single-base RTK uses one physical station, while VRS uses a modelled base derived from many stations. That changes how accuracy behaves over distance and what equipment you carry.

A full decision guide, including cost and crew logistics, is in our comparison of RTK base and rover vs network RTK. Many firms run both and switch depending on the site.

VRS, MAC and FKP: which network RTK method is which?

VRS, MAC and FKP are three ways of delivering the same network error model to a rover. They differ in whether the server or the rover does the interpolation and in whether the rover must send its position.

VRS (virtual reference station)

The server does all of the modelling and sends a single set of base observations tailored to the rover. Any RTK rover that accepts standard RTCM can use it, which makes VRS the most widely compatible option. The trade-off is that the server must run a separate computation for each connected user.

MAC (Master-Auxiliary Concept)

The Master-Auxiliary Concept sends full corrections for one master station plus compact correction differences for nearby auxiliary stations, using the standardised RTCM 3 network messages. The rover interpolates the errors itself. Because the data is not tied to one user, MAC can be broadcast, and the rover can apply its own modelling. The rover firmware must support the network messages.

FKP (area correction parameters)

FKP comes from the German Flächen-Korrektur-Parameter. The server sends corrections from a real station plus north and east gradients that describe how errors change across the area. The rover applies those gradients for its own position. FKP can work one-way, but the linear model is simpler than VRS or MAC.

How accurate is a virtual reference station?

A virtual reference station typically gives about 1–2 cm horizontal and 2–4 cm vertical accuracy with a fixed solution, provided you are inside a well-maintained network. That figure stays roughly the same across the network instead of growing with distance from one base.

Several factors move results up or down:

• Station spacing. Most networks space stations about 50–70 km apart. Denser networks model the atmosphere better.
• Network edges. Outside the polygon formed by the outer stations, the server is extrapolating rather than interpolating, and accuracy and fix times worsen.
• Ionospheric activity. During strong solar activity, local disturbances can be smaller than the station spacing, so the model misses them and fixes take longer.
• Latency. Mobile data delays of more than a couple of seconds degrade the solution; poor coverage causes dropouts.
• Rover quality. A multi-frequency, full-constellation receiver initialises faster and holds a fix under trees and near buildings far better than a basic unit.

Absolute accuracy also depends on the network's coordinates. Your results are only as good as the network's reference frame and how well it matches your project datum, which we explain in our guide to datums and coordinate systems. For work that cannot rely on a live link, see how post-processing compares in PPK vs RTK correction methods.

How to choose the right NTRIP mountpoint for VRS

Choose a mountpoint whose method, message format and constellations match your receiver, and whose datum matches your project. The mountpoint is the named stream on the NTRIP caster; a network usually publishes several in its source table.

Typical mountpoint types include:

• VRS streams in RTCM 3.x, often with separate GPS-only and multi-constellation versions, or a multiple signal message (MSM) version.
• MAC streams carrying RTCM 3 network messages, for rovers that support them.
• Nearest-station streams, where the caster picks the closest real CORS and sends single-base corrections.
• Single named stations, useful when you need a consistent reference over a long project.

In our support work, most "no fix" calls on network RTK come down to settings, not hardware. Check that the rover is actually sending GGA (VRS fails silently without it), that the message format matches the receiver, that the account has not expired or hit its concurrent-login limit, and that the controller's coordinate system matches the network's frame. Record the mountpoint name in the job notes so the next crew can reproduce your setup.

What equipment do you need to use a VRS network?

You need a network-capable RTK rover, an internet connection on site and a subscription or account with a CORS network operator. No base, tripod or radio is required.

The connection can come from a 4G modem in the receiver or from the controller or phone over Bluetooth. Our Mini Network RTK Rover is built for exactly this: a 409 g, 1408-channel rover with a 60° IMU tilt that takes its corrections from your local CORS account through a phone or data collector, with no base and no radio. For GIS crews, the P2 handheld GIS RTK rover weighs 199 g, connects to CORS directly over 4G and is specified at 8 mm + 1 ppm horizontal RTK accuracy.

If you also work in areas without network coverage, a receiver that can switch modes saves buying two systems. The E1 GNSS RTK receiver works as a CORS/NTRIP rover, a radio rover or a radio base, so the same unit runs on VRS in town and on your own base and UHF link in the field.

When should you not rely on VRS?

Avoid relying solely on VRS where mobile data is unreliable, where you are outside or at the edge of the network, or where a project must stay on a fixed local control framework.

• Remote sites and mines. No coverage means no corrections; set up your own base with a radio link instead.
• Long projects with strict relative accuracy. Networks occasionally update station coordinates or switch reference frames. Tie every project to on-site control points and check them each day.
• Heights. Network RTK heights are ellipsoidal and depend on the geoid model you apply. For levelling-grade work, verify on benchmarks or use a level.
• Disturbed ionosphere. If fixes become slow or jumpy, pause, re-initialise and repeat check shots.

Our engineers' rule of thumb: network RTK is a correction source, not a substitute for control. Observe at least one known point at the start and end of each session and keep a record of the residuals.

If you are equipping crews to work on a CORS network, or want a mixed fleet that can also run its own base, request a quote and tell us which network and mountpoints you use; we will confirm compatibility before shipping.

Frequently asked questions