RTK Fix Lost? A Field Troubleshooting Guide for Base, Rover and Network RTK

RTK fix lost events can occur when a rover shows a good position one minute and then switches to float, single or no correction the next. Rather than restarting every device, identify which part of the positioning chain changed: satellite reception, correction delivery, base-station output, radio link, network login, antenna environment or rover settings.

This guide gives survey teams, contractors, integrators and equipment buyers a repeatable way to investigate RTK fix loss. It applies to local base-rover systems as well as network RTK workflows. If the project needs a new receiver, antenna, local base or network-correction design, use the checks below to describe the problem clearly before requesting a recommendation.

What does “RTK fix lost” mean?

An RTK solution uses GNSS observations together with correction data to resolve positioning ambiguities. When the rover cannot maintain the required observations or correction stream, it may change from a fixed solution to float, autonomous, DGPS, or an unavailable state. The exact labels vary by controller and software, but the diagnostic logic is similar.

A fixed status does not guarantee that every field result is suitable for every task. A team should still follow its project control, check-shot and quality procedure. Likewise, a float status is not automatically a hardware failure: it often points to an environment, correction, configuration or communication issue that can be isolated.

First: separate the problem into five possible layers

Do not change several settings at once. Make one controlled change, note the result, then continue. This is especially important when several field crews use the same base or network service.

Step 1: Check the rover environment before changing settings

Obstructions and reflected signals are a common reason for unstable RTK performance. A rover may perform normally in an open area and lose its fixed solution near dense vegetation, tall structures, cut slopes, cranes, parked machinery, metal roofs, power infrastructure, water edges or vehicles.

Move the rover to a clear point for a short comparison. If the status returns to normal in the open, the likely next step is to assess the working environment rather than replace the receiver. For difficult sites, review pole height, antenna position, expected sky view, work sequence and control checks.

The right antenna and mounting method also matter. A base station or permanent installation should be planned around its own environment, not selected only by the rover’s field use. See the GNSS antenna selection guide for RTK, CORS and monitoring antenna planning factors.

Step 2: Confirm whether the rover is receiving corrections

For a network RTK workflow, confirm that the controller has a working data connection and that the intended correction service is active. Check the selected mountpoint, login status, correction format and correction age. If the service is available but the rover is receiving no data, test a known-good data connection before changing GNSS settings.

For a local base-rover workflow, verify that the rover is listening to the correct radio channel or data link and that the base is transmitting the intended corrections. Check the base power state, radio antenna connection, cable condition and placement. Terrain, buildings and distance can affect the practical radio path, so a problem that occurs only in one direction or at one distance band may be a link-planning issue.

If the project is deciding between a site-owned base and network corrections, read VRS vs. RTK Base Station before changing the overall workflow. It explains where each approach is normally a better starting point.

Step 3: Check base-station setup for local RTK work

A base that is not stable, not transmitting, poorly located, or configured differently from the rover can affect every field user. Before changing rover settings, check these questions:

• Is the base powered and running the expected correction output?
• Is its antenna mounted securely with a clear sky view and protected cable route?
• Is the base position appropriate for the project’s control procedure?
• Does the rover use the same correction message format and radio/data-link configuration?
• Did the problem start after moving the base, changing a radio, changing a controller profile, or updating field software?

For projects that need a dedicated base-station path, review the TOKNAV tBase GNSS receiver together with the project’s correction, antenna and radio requirements. Product selection should follow the workflow; it should not replace site testing or control validation.

Step 4: Rule out a network RTK or NTRIP issue

Network RTK introduces a second set of dependencies: mobile data coverage, service credentials, mountpoint selection, caster availability and project reference-frame configuration. An RTK fix that is reliable in one area but not another may indicate local cellular coverage, service coverage, mountpoint choice or an environmental issue at the working location.

Use a simple comparison:

1. Test the rover in an open location with known usable mobile coverage.
2. Confirm that correction data is actively arriving and that correction age is reasonable for the workflow.
3. Verify the selected mountpoint and coordinate/reference-frame settings with the correction-service operator.
4. If possible, compare with a controlled local-base test rather than treating the entire GNSS receiver as the cause.

For a multi-user or wider-area correction project, start with the TOKNAV VRS solution page and share the planned coverage area, number of users, applications and correction-delivery constraints.

Step 5: Verify coordinate, datum and field-project settings

An RTK link can be technically healthy while the field result is still unsuitable because the project setup is wrong. Coordinate reference system, geoid model, datum transformation, localization, base coordinates and controller job settings should be reviewed as part of the investigation.

This is particularly important when a team moves between projects, imports a new control file, changes a controller template, uses a different correction service, or combines GNSS results with design, CAD, GIS or machine-control data. Preserve a copy of the previous working project profile before editing it, and compare one setting at a time.

A practical RTK fix-loss checklist to send to technical support

When an issue persists, send the following with the inquiry. It lets the technical team assess the system path rather than guessing from a screenshot.

• Receiver and controller model; field software and version if known.
• Local base, radio, network RTK, CORS/VRS or other correction method.
• Approximate location and working environment: open sky, urban area, canopy, slope, water edge or other obstacles.
• Rover solution status, satellite count, correction age and any error message.
• Base power/output state or network mountpoint status.
• Whether the issue affects one rover, all rovers, one location, or one time of day.
• Project coordinate system, localization or control-point context where relevant.

When to review the hardware path

Hardware review is appropriate when a controlled test shows that the problem follows one receiver, antenna, radio or cable rather than the site or correction source. It is also appropriate when the planned application has changed: for example, a short survey job becomes a long-duration base operation, a single rover becomes a multi-crew workflow, or a temporary site becomes a correction-network project.

Use the GNSS receiver range to compare RTK receiver paths, then request a recommendation with the checklist above. Include country, application, correction method, expected working environment and the number of rovers or base stations required.

FAQ: RTK troubleshooting

Why does my RTK rover change from fixed to float?

The change usually means the rover cannot maintain the observations or correction data required for a fixed solution. Check the sky view, multipath environment, correction age, local radio/data link, base output or network RTK connection before changing several settings at once.

Can a local base station lose RTK fix because of radio range?

Yes. Terrain, buildings, antenna placement, interference and distance can affect the practical link. Confirm whether the rover still receives corrections and whether the issue is limited to a particular direction or work area.

Is network RTK always more reliable than a local base?

No. Network RTK can be suitable where service coverage and data connectivity are reliable. A local base can be appropriate for controlled site work or areas with limited network access. The best choice depends on the project, coverage, control requirements and operating conditions.

What should I include when asking for RTK support?

Share the receiver/controller details, correction method, field environment, solution status, correction age, error messages and whether the issue affects one device or the whole workflow.

Discuss an RTK receiver or correction workflow

If your team is troubleshooting repeated RTK fix loss, planning a new base-rover kit, or comparing network RTK with a local base, contact TOKNAV with the project details. A clear description of the field workflow makes it possible to discuss the relevant receiver, antenna, base-station and correction options.