An RTK rover may transition from a fixed solution to float, single or no-correction status during field operations. The appropriate response is to isolate the affected layer of the positioning chain: GNSS observation environment, correction stream, local base or radio link, data connectivity, or project configuration. A controlled sequence prevents unnecessary parameter changes and protects the integrity of field records.
Before changing a setting, record the time, location, solution status, correction age, active profile and whether the issue affects one rover or the whole crew. This record provides the evidence required for a controlled diagnosis.
Interpret the solution-status change
Receiver labels differ, but the diagnostic idea is similar. A fixed RTK solution depends on usable GNSS observations, a valid correction source and a compatible setup. When one of those inputs is interrupted or no longer sufficient, the receiver may report float, autonomous, differential or another lower-confidence status. That status is a signal to follow the project’s quality procedure—not proof that a particular receiver, service or antenna has failed.
Apply a five-layer diagnostic sequence
| Layer | Typical sign | First controlled check |
|---|---|---|
| Sky view and antenna environment | Issue appears near trees, buildings, machinery or reflective surfaces | Move to a clear location and compare the status |
| Correction stream | Correction age rises, data stops or NTRIP disconnects | Confirm incoming corrections and the active profile |
| Local base and radio | One distance band, direction or all local rovers are affected | Check base output, power, antenna and radio path |
| Data connection | Network workflow fails at a particular site or time | Test the planned SIM, tether or router in an open area |
| Project configuration | Link looks healthy but results do not fit project checks | Review coordinate, vertical and job settings |
1. Verify the GNSS observation environment
Check the simplest physical cause first. Dense vegetation, tall facades, parked equipment, cut slopes, bridges, water edges, metal roofs and other reflective surfaces can alter the observation environment. Do not decide that the receiver is faulty because a problem occurs at one difficult point. Take the rover to a nearby open point, keep the same correction profile and compare the result. If the solution recovers in the open, investigate the working environment, pole placement and the project’s acceptable collection method before changing system configuration.
2. Confirm correction-stream continuity
In a network RTK workflow, a connected account is not enough. Check whether correction data is actually arriving, whether the selected mountpoint is intended for the work area and whether the controller or receiver still has an internet route. Note the correction-age indicator and any error message. Test a known-good data path before re-entering GNSS settings.
When the workflow uses NTRIP, validate the caster profile, port, credentials, mountpoint and position-reporting requirement with the provider. The separate NTRIP setup guide outlines that chain. Do not share account credentials in a screenshot or support request; report the profile name and service context instead.
3. Verify the local-base and radio link
For a base-rover system, determine whether the base is operating and transmitting the intended corrections before changing a rover. Check power, data output, antenna connection, radio channel and antenna placement. A fault limited to one direction or a certain distance can point to terrain, line of sight, interference or link planning. A fault affecting every rover at once is more likely to involve the base, its correction output or a shared configuration than several independent rover failures.
The practical range of a radio link is not a single number. It depends on terrain, obstructions, antenna height, interference and the site arrangement. Review the RTK base-station range guide when planning the system rather than relying on an intermittent edge-of-site connection.
4. Review project configuration after link verification
Once the rover has a stable environment and active corrections, check the project profile: coordinate reference system, vertical reference, localization, control files and the selected correction source. This is especially important after importing a job, switching a controller, updating field software or moving between projects. Preserve a copy of the last working profile. Then compare one setting at a time against the project documentation or accepted control; changing several parameters together makes it impossible to know which change mattered.
5. Conduct a controlled comparison
A controlled test separates site conditions from equipment. In an open area, use the same rover, correction source and project profile to make the project’s normal check. If the system works there, return to the affected location and note what changes: sky obstruction, distance, data coverage, nearby surfaces or operating procedure. If the problem follows one component across locations, then hardware, cable, radio or antenna inspection becomes a reasonable next step. This approach is safer than replacing equipment based on one difficult observation.
Information required for technical support
Send a short, structured summary: receiver and controller model; field-software version if known; correction type; approximate environment; solution status; correction age; error message; and whether the issue affects one rover, all rovers, one location or one time of day. Add the project coordinate context only through the approved support channel. This record helps a support team determine whether the next action should focus on corrections, antenna environment, radio planning, software or a component check.
For teams reviewing a new system rather than a one-off fault, compare the TOKNAV GNSS receiver range with the complete workflow: rover count, base or network choice, antenna, controller, field software, environment and training. Equipment choice should follow the supported field process.
FAQ
Why does a rover change from fixed to float near a building or trees?
The GNSS observation environment may be affected by reduced sky view or reflected signals. Test the same setup in an open area before changing receiver settings.
Is network RTK always more reliable than a local base?
No. Network RTK can be suitable where service and data coverage are dependable; a local base can suit controlled sites or areas with limited connectivity. Review the project conditions before choosing.
When should hardware be inspected?
Inspect hardware when a controlled comparison shows the problem follows one receiver, antenna, cable or radio across otherwise comparable conditions.
Integrate correction delivery into the project plan
If repeated fixed-solution loss is affecting a survey, construction or GIS workflow, share the correction method, operating area, number of rovers and environment. Contact TOKNAV to discuss a supportable receiver, antenna and correction-workflow path.