RTK Not Getting a Fix? Troubleshooting Float and Connection Problems

Updated October 3, 2026.

If your GNSS rover is not getting an RTK Fix, start by checking whether it receives usable corrections, then check the satellite observations at the base and rover. An NTRIP connection can be active while the receiver remains in Float or Single.

Use the table below to choose your first check. Read the receiver's solution status and correction age in its own app or controller; YouCORS Sessions helps you investigate the connections carrying those corrections.

Quick RTK troubleshooting checklist

1. The base station is sending poor corrections

A rover needs observations from a suitable correction source. A base can connect successfully to a caster while publishing a stream that does not match what the rover needs.

Check that:

• the base is stable and has a clear view of the sky;
• its correction output includes the RTCM messages, signals and constellations required by the rover;
• the expected mount point receives recent data;
• the rover is using the intended base or correction service;
• the base-to-rover distance is within the conditions supported by the equipment and correction service.

Also verify base coordinates, antenna height and the project's coordinate reference system. A fixed solution does not by itself prove that the coordinates are correct. A setup error can shift a survey even when the receiver reports Fix. Consult the receiver's specifications for baseline limits and initialization requirements; a single distance or satellite-count threshold does not apply to every setup. See Trimble's guidance on RTK accuracy factors.

For connection configuration, use the guides to mount points and NTRIP clients. Source credentials belong to the base connection; client credentials belong to the rover.

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

Check the whole correction path:

Base station → NTRIP caster → internet connection → rover

Both the base and rover also need their own GNSS satellite observations. A connected NTRIP client only establishes part of this setup.

Compare these three checks:

1. At the caster: is the intended base connected, and are there recent traffic observations?
2. At the rover connection: are status reports current, and does the received-byte total increase between updates?
3. At the receiver: are corrections being used, is their age acceptable for this receiver, and what solution status does it report?

If the rover cannot connect, verify the hostname or IP, the instance's NTRIP port, the exact mount point name and client access. Check the receiver's network connection and the instance's authorization attempts. The caster setup guide explains where to find these settings.

If it connects but receives no usable corrections, check the source and stream format before changing receiver settings. A byte counter is evidence of data transfer, not proof that the receiver can use every message. Likewise, the caster's throughput chart is not a measurement of correction age at the receiver.

Example: investigate a rover in YouCORS Sessions

Suppose an operator reports that Rover-02 is staying in Float. The following walkthrough uses screenshots of the YouCORS interface with demonstration data. It shows how to narrow the investigation; it is not a record of a confirmed customer fault or a successful fix.

Open the correct base session

Open Account menu → Sessions, or open the mount point's Session history. Select the base session covering the operator's reported time. Use the Sessions guide if there are several source connections with the same name.

In the example, the base is NORTH-FIELD. Select Rover-02 under Rovers to open that specific connection's inspector.

Demonstration data. Select the screenshot to read the inspector at full size.

Read the observations before deciding what failed

The screenshot shows:

• Rover-02 is Active, with “Status stale · 36s.” Active means the connection has not been recorded as ended. The stale report means its current condition needs checking.
• Received (caster to rover) is 134 kB. This is a cumulative total. Refresh and compare it with a later observation to check whether transfer is continuing.
• Average rate (lifetime) is 300 B/s. It summarizes the base session, not the current rate to Rover-02.
• The base traffic chart contains a gap. A gap represents missing observations; it does not establish that the base sent zero bytes.

First refresh the detail page and check its update time. If status remains stale, compare the base and other rover reports to see whether the missing telemetry affects one connection or several. Ask the operator to check the receiver's correction age, solution status and network connection at the same time.

Compare connection events

Open Events and look around the time the problem was reported. The detail page uses UTC, so align the operator's local time before comparing records.

Demonstration data. These entries establish when Rover-02 connected; they do not establish why it later reported Float.

The visible events show Connected and Session started at 08:23 UTC. They do not show a disconnection or prove a mobile-network failure. If your own session shows repeated connection endings and starts, inspect the reported reasons and compare the timing with the receiver or modem logs.

Use the evidence to choose the next check:

• Only this rover has stale reports or repeated reconnects: investigate its connection and telemetry, including mobile coverage, power and controller behavior.
• Several rovers are affected at the same time: investigate the shared source and network path.
• Reports are current and data continues, but the receiver stays in Float: inspect correction compatibility, correction age, baseline and local GNSS conditions.

Use Copy connection link to give a teammate with account access the exact connection to investigate. See Inspect a rover and Review events for the available fields. Sessions describes connection and transfer history; confirm RTK Fix and positioning accuracy on the receiver and through survey checks.

Diagnose connection problems with an AI assistant through MCP

The YouCORS MCP server lets a connected AI assistant retrieve account records for this investigation. It can compare base and rover sessions, transferred bytes, the latest status and transfer observations, recorded end reasons, and authentication results. This helps you assemble a connection timeline when several rovers or caster instances are involved.

Follow the MCP connection guide and authorize your account. For diagnosis, use the read-only access described in the guide. Then give the assistant the account, mount point, rover identifier, and the date and time of the problem, including the time zone.

For the example above, adapt this request with your own names and time window:

Investigate why Rover-02 on NORTH-FIELD in the Survey Team account was staying in Float between 08:20 and 08:40 UTC on October 3, 2026. Use read-only tools. Find the matching base and rover sessions, including ended sessions, and compare them with other rovers on that source. Check transferred bytes, the latest status and transfer observations, recorded end reasons, and authentication failures. Summarize the evidence with timestamps, flag missing records, and suggest the next checks on the receiver. Do not change configuration or display passwords.

Ask for a timeline and an explanation of which records support each conclusion. Missing or stale observations should remain explicit gaps in the evidence. MCP exposes connection records; it does not directly measure the receiver's correction age, satellite signal quality, or RTK solution status. Confirm those on the controller when deciding whether to investigate correction delivery or local GNSS conditions.

3. The rover is working in poor GNSS conditions

If correction delivery checks out, inspect the rover's sky view and observations. Nearby walls, vehicles, metal structures and foliage can obstruct or reflect signals. A high satellite count alone does not establish that enough suitable observations are available for a reliable fixed solution.

Review the receiver's signal-quality indicators, satellite geometry and solution status. Compare results in a clear area while keeping the correction source and receiver settings the same.

Why won't my GNSS rover get a fix under tree canopy?

Tree canopy can obstruct satellite signals and create reflected paths, making RTK initialization and continuous tracking more difficult. A working internet connection and fresh corrections cannot restore the rover observations lost behind an obstruction. Manufacturer guidance recommends clear sky and avoiding multipath during initialization; see Trimble's RTK initialization guidance.

Try this comparison:

1. Record the solution status and correction age under the canopy. Note the time so you can compare it with Sessions.
2. Move to a nearby safe, open area with the same receiver, mount point and settings. Keep the antenna stable and follow the manufacturer's initialization procedure.
3. Check whether correction delivery remains current and whether the receiver obtains Fix in the open area.
4. Compare the two locations. If delivery stays healthy but Fix is lost under the canopy, local GNSS conditions are a stronger suspect. If correction age rises or connections drop too, investigate both signal obstruction and the mobile link.

If the required measurement point is obstructed, choose a survey method appropriate to the required accuracy, such as a supported offset workflow from a clear position or a total station. Recheck control points and follow your equipment's quality checks. Waiting longer or restarting the receiver does not guarantee reliable results under canopy.

How to troubleshoot without guessing

Record the time, receiver model, mount point, solution status and correction age before changing settings. Then check the source, delivery path and rover observations in order. Change one setting at a time and compare the result.

For a quick view of current connections, open the YouCORS Dashboard. Use Sessions for connection history and traffic, and Casters to check instances, mount points and client credentials.

When there is more than one cause

A rover may have poor sky visibility and an intermittent mobile link at the same time. A base may publish continuously while its correction format is unsuitable for one receiver. Resolving one issue does not establish that the rest of the setup is correct; repeat the checks after each change.

Summary

For RTK Float or a lost Fix, check usable source corrections, their delivery to the receiver, and GNSS observations at both ends. Use YouCORS to narrow down connection problems, then verify the solution and measurement quality on the survey equipment.

If you are setting up a correction-delivery service for your team, start with the YouCORS private NTRIP caster and follow the caster creation guide.