Why RTK Fix Fails: 3 Places Where Problems Usually Start

When a GNSS receiver does not reach RTK Fix and stays in Float or Single, the receiver itself is not always the problem.

RTK is a chain, not a single device:

Satellites -> Base station -> NTRIP caster -> Internet -> Rover

If one part of that chain is weak, the rover may still see satellites, connect to the network, and receive some correction data, but fail to resolve a fixed RTK solution.

These are the three areas worth checking first.

1. The base station is sending poor corrections

RTK starts at the base, not at the rover. If the base station is unstable or publishes a bad RTCM stream, the rover cannot reliably resolve carrier-phase ambiguities.

Common causes include:

• incorrect base station coordinates;
• poor sky visibility at the base;
• nearby reflective surfaces, metal structures, or trees;
• missing RTCM message types in the correction stream;
• corrections for only part of the satellite constellations in use;
• a temporary antenna setup that moves because of wind or vibration.

This often happens during quick field deployments, when the base is placed somewhere convenient but the observation quality and coordinates are not checked carefully.

Check that:

• the base coordinates are correct and use the expected coordinate system;
• the base tracks enough GPS, Galileo, BeiDou, GLONASS, or other supported satellites;
• the RTCM stream is actually reaching the caster;
• the mount point receives data continuously, without long gaps;
• the antenna height is entered correctly if it is used in the workflow.

If the base is publishing poor corrections, changing the rover SIM card or restarting the field controller will not solve the problem. Start by verifying the correction source.

2. The NTRIP connection exists, but the stream is wrong

Sometimes the rover shows that the NTRIP connection is active. The user sees an online status and assumes the internet connection and caster are fine.

For RTK, that is not enough. The rover must receive the right correction stream, continuously, with acceptable latency.

Common issues in this part of the chain include:

• the rover is connected to the wrong mount point;
• the username or password belongs to a different project;
• the caster accepts the rover connection, but the base is not publishing data;
• the correction stream has high latency;
• the mobile connection drops repeatedly;
• several rovers share the same credentials, making sessions hard to diagnose;
• a firewall or router blocks the required port.

A healthy setup is easy to recognize: the dashboard shows both the publishing base and the connected rover, and correction data flows without repeated interruptions.

In YouCORS, active sessions help with this check. An administrator can see which base is publishing corrections, which client is connected, and whether the rover is using the expected mount point.

Check that:

• caster address, port, username, and password are correct;
• the rover is using the right mount point;
• the base is publishing data right now;
• the rover is not reconnecting frequently;
• the stream matches the area where the rover is working;
• correction latency is not too high.

If the rover receives corrections from a base that is too far from the job site, Fix may take a long time, drop frequently, or never appear.

3. The rover is working in poor GNSS conditions

Even with a good base and a stable NTRIP connection, RTK Fix is not guaranteed. The rover still needs clean GNSS observations of its own.

RTK performs poorly when satellite signals are blocked, reflected, or changing constantly.

Difficult rover environments include:

• dense urban areas;
• work next to walls, fences, vehicles, or metal structures;
• trees or wet foliage above the antenna;
• deep excavations;
• nearby power lines or radio interference sources;
• an antenna mounted too low;
• an unstable pole or uncompensated tilt.

In these conditions, the rover may show a reasonable satellite count while the signal quality is still not good enough for Fix.

Check:

• satellite count and sky distribution;
• SNR or C/N0 values;
• PDOP;
• signs of multipath;
• antenna height and position;
• behavior in an open-sky test area.

A simple comparison helps: take the same equipment to an open area and connect to the same mount point. If Fix appears quickly there, the issue is probably not the caster or credentials. It is likely the local GNSS environment.

How to troubleshoot without guessing

The fastest approach is to check the chain in order.

Start with the base:

• is it installed at a stable point;
• are the coordinates correct;
• is it publishing an RTCM stream.

Then check the caster:

• does it receive the base stream;
• does the rover connect;
• do the mount point and credentials match;
• are there latency spikes or repeated disconnects.

Finally, check the rover:

• is it inside the practical range of that base;
• does it have clear sky visibility;
• does it support the constellations and correction formats being used.

This order saves time. Changing rover settings before checking the base and correction stream can send troubleshooting in the wrong direction.

When there is more than one cause

In the field, RTK problems are often caused by a combination of factors.

For example:

• the base location is poor and the rover's mobile internet is unstable;
• the mount point is correct, but the base is too far away;
• the RTCM stream is present, but important message types are missing;
• Fix works in an open area, then drops to Float next to a building.

That is why it is useful to look beyond the receiver's final status and review the whole correction delivery chain.

Summary

When RTK Fix does not appear, start with three places:

1. the base station;
2. the NTRIP connection and correction stream;
3. the rover's GNSS environment.

RTK Fix depends on good satellite observations, valid corrections, stable internet, and correct configuration. When each part is checked separately, the real cause is usually much easier to find.