RTK Float vs Fix When Your Rover Connects
The NTRIP client says it is connected, but the receiver still says RTK Float. Those messages describe different parts of the job: the client has a connection, while the receiver has not resolved a fixed RTK solution.
Changing every setting at once makes the problem harder to find. First separate the correction stream from the receiver's use of it.
A connection is the first link
A successful login tells you that the client reached the caster. It does not establish that usable corrections arrived continuously at the receiver.
The base needs to send suitable observations, the caster needs to deliver them, and any controller or software between the client and receiver must pass them along. One working link cannot prove the whole path.
In RoboGNSS, check the base stream and the rover connection. Then check the correction input on the field receiver itself.
Give each status its proper meaning
| What you see | What it tells you |
|---|---|
| Base stream data | The caster is receiving data from the source |
| Rover connected | A client has connected to the stream |
| Reported RTK Float | The rover reports a float solution |
| Reported RTK Fixed | The rover reports a fixed solution; check it against your work's requirements |
| No fresh GGA | RoboGNSS has no recent rover status report |
If the rover does not send GGA upstream, it may still be receiving corrections and working normally. The caster cannot infer its fix state from outgoing correction bytes.
Look for the change that explains the problem
Did the rover move beside trees or a building? Did the correction connection begin dropping? Did the base position, message configuration, or selected stream change?
Those observations help you narrow the next check. Open sky, suitable observations, correct base settings, and continuity all matter to the receiver's solution.
The base satellite view is useful for the source, but it does not show what satellites the rover can see. Use the field receiver's own display for that part of the diagnosis.
Work through five checks in order
- Confirm the intended stream. Compare the NTRIP settings with the credential box in Rover access.
AUTOmeans the base assigned to that login, not the nearest base. Run the credential's test, then verify correction input at the receiver; the service-side test does not check the rover's own network path. - Compare an open-sky location. Move away from trees, walls, and reflective surfaces and observe the receiver's own satellite and signal display. A change in behavior helps isolate the environment without changing the caster configuration.
- Compare the base settings. Check the receiver's fixed position and station ID against the values broadcast in the stream. Investigate
moving_base,position_mismatch, orstation_id_mismatchflags. Editing RoboGNSS's declared coordinates does not reconfigure the base receiver. - Look for gaps. Read the base's last-data time, data rate, Uptime · last 24 h, and Recent connections. Compare any reported correction age with the field receiver's status. A high total byte count can hide intermittent delivery.
- Check the message set. Compare the RTCM observations and signals your rover requires with what the base sends. Station-position messages 1005/1006 help describe the base, but position messages alone are not an observation stream. Review the MSM messages too.
These checks follow the RoboGNSS troubleshooting guide. Change one setting or condition at a time so you can tell which change helped.
What to record for support
Collect the receiver model and firmware, the approximate base-to-rover distance, the stream selected, correction age if available, and the time the problem occurred. Add the receiver's own status and satellite view, the caster's message counts, and any warning flags. Leave passwords and upload tokens out of screenshots.
That evidence separates three different questions: did the base send usable data, did it reach the receiver continuously, and could the receiver use it at that location?
Use history without reading too much into it
When recording is enabled and a rover sends status information, RoboGNSS can show connection history and reported fix-state summaries. That can help distinguish a repeating connection problem from periods when the rover stayed connected but reported float.
A shared login may combine activity from several connections. Use separate rover credentials when you need to understand individual machines, and keep missing reports separate from a reported loss of fix.
These are receiver reports, not independently verified survey measurements. Read the rover reporting guide for what each view can establish.
Take the next useful step
The RTK Float troubleshooting guide walks through stream selection, sky view, base setup, continuity, and correction messages. Work through the relevant checks and keep a record of what changes.
If you need help, bring the receiver status, correction source, and timing of the problem. That is a better starting point than a screenshot that only says “connected.”
Running your own base? RoboGNSS Free gives you a private caster and stream monitoring so you can see more of the path between the base and rover.