An RTK GPS tracker is online, its position appears on the map, and the correction service shows a connection. However, the positioning status remains Float instead of changing to Fixed.
This is a common challenge during high-precision tracking deployment.
An internet connection alone does not establish that the receiver is receiving and using suitable correction data. Satellite visibility, antenna installation, correction compatibility and reference-station configuration also influence the result.
Before replacing hardware, follow the complete positioning chain and identify which condition is preventing a stable RTK solution.
What Is the Difference Between RTK Float and Fixed?
RTK positioning uses carrier-phase measurements together with correction data to improve positioning performance.
During ambiguity resolution, the receiver estimates the unknown number of complete carrier cycles. A Float solution has not resolved those ambiguities to accepted integer values. A Fixed solution indicates that the receiver has accepted an integer ambiguity solution.
Receiver documentation can expose these states through protocol fields. For example, the u-blox ZED-F9P integration manual documents separate Float and Fixed indicators in NMEA and UBX output. content.u-blox.com
| Positioning state | Practical interpretation |
|---|---|
| Standalone GNSS | Position calculated without an RTK solution |
| Differential GNSS | Differential corrections used, without a fixed carrier-phase solution |
| RTK Float | Carrier-phase solution available, ambiguities remain unresolved |
| RTK Fixed | Integer ambiguity solution accepted by the receiver |
| Invalid position | No valid position available |
Exact status labels and output fields depend on the receiver.
A Fixed indicator is useful, but it does not independently prove that the absolute coordinates meet a project’s accuracy requirement. Reference coordinates, installation and field verification still matter.
1. Check Whether Correction Data Reaches the Receiver
Start by separating three conditions:
- The tracker has internet access.
- The correction client has connected to a service.
- The GNSS receiver is receiving and using valid corrections.
These are different checkpoints.
NTRIP transports GNSS correction data over the internet. A successful connection is one part of the correction delivery path. u-blox
Inspect the complete route:
Correction service → NTRIP client → device interface → GNSS receiver
Check received byte counts, timestamps, interface errors and receiver diagnostics.
If the tracker’s application processor receives data but does not forward it correctly to the GNSS module, the receiver cannot benefit from that connection.
2. Verify NTRIP Settings and the Selected Mountpoint
An incorrect configuration may prevent correction delivery or connect the device to an unsuitable stream.
Review:
- Caster address.
- Port and connection requirements.
- Username and password.
- Mountpoint.
- Service coverage.
- Subscription status.
- Required position messages sent by the client.
Some services require the client to send its approximate position to select or generate suitable corrections. Confirm the provider’s requirements.
Also test reconnection after a temporary cellular outage. A device that works only immediately after startup is not ready for unattended field operation.
Store credentials securely and keep them out of ordinary diagnostic exports.
3. Confirm Correction Compatibility
A stream can contain valid data without containing everything the selected receiver needs.
Compare the correction service output with the GNSS receiver’s documentation. Review supported message types, satellite constellations, observation signals and firmware requirements.
Do not assume that the label “RTCM” establishes complete compatibility.
For diagnosis, use receiver tools to inspect correction reception and positioning status. The u-blox EVK-X20P guide, for example, describes monitoring correction messages and checking the receiver’s Float or Fixed state. content.u-blox.com
The relevant tools and message names will differ for other receiver families.
4. Monitor Correction Age and Interruptions
Correction data needs to remain sufficiently current for the receiver and operating mode.
An active network session may still experience pauses, delayed delivery or repeated reconnections. Inspect correction age where available and compare it with the receiver’s documented operating requirements.
Useful diagnostic records include:
- Time of the last correction received.
- Correction age reported by the receiver.
- Connection interruptions.
- Reconnection attempts.
- Positioning-state transitions.
There is no single correction-age threshold suitable for every receiver and service. Use the selected equipment’s documentation and validate behavior during field tests.
Avoid presenting a connected NTRIP icon as proof that correction delivery is healthy.
5. Inspect Satellite Visibility and Antenna Placement
Correction data cannot replace usable satellite observations.
An RTK vehicle tracker may perform well in an open test area and struggle after installation beneath a metal panel. A wearable RTK GNSS tracker may experience changing reception as the user turns or walks beside buildings.
Inspect:
- Sky visibility.
- Nearby walls and reflective surfaces.
- Tree cover.
- Metal shielding.
- Antenna orientation.
- Antenna cable and connectors.
- Ground-plane requirements.
- Nearby sources of electrical interference.
Test the complete product in its final enclosure and mounting position.
For a vehicle installation, compare results in an open area with results along the intended operating route. This helps separate a persistent configuration problem from an environmental limitation.
6. Check the Reference Station and Coordinate Setup
For a local base-station deployment, review both the base and the rover.
Confirm that the base antenna is securely installed, its coordinates are established appropriately, and the correction output matches the rover’s requirements.
An incorrect base coordinate can shift rover positions even when the rover reports Fixed.
For a network correction service, confirm its reference frame and how those coordinates relate to the project’s maps or surveyed control points.
A stable offset between the tracker and a site drawing may involve coordinate systems or reference data rather than a failure to resolve ambiguities.
7. Evaluate Distance from the Reference Station
For conventional base-and-rover RTK, increasing separation can make it harder to treat atmospheric errors as common between the two receivers.
The usable distance depends on the equipment, environment, correction method and required performance.
Avoid applying one advertised distance to every installation.
For a large farm, industrial park or equipment fleet, evaluate whether the proposed local base or network service covers the actual working area. Test the most demanding locations, including distant areas and partially obstructed routes.
8. Distinguish Positioning Performance from Upload Frequency
An RTK tracker has several separate operating rates:
- GNSS measurement rate.
- Position-solution output rate.
- Correction input rate.
- Platform upload interval.
A dashboard updating once per minute does not reveal whether the receiver remained Fixed throughout that minute.
Similarly, frequent platform updates do not establish high positioning accuracy.
During a pilot, record local receiver status at a suitable rate and compare it with the reports received by the platform. Include position timestamps and quality fields in the communication protocol where supported.
Common Symptoms and First Checks
| Symptom | First checks |
|---|---|
| NTRIP connection fails | Credentials, address, port, subscription and network access |
| Client receives data but receiver shows standalone GNSS | Forwarding interface, receiver input configuration and correction compatibility |
| Float persists in an open area | Correction use, antenna setup, reference configuration and receiver diagnostics |
| Fixed is lost near buildings | Obstruction, reflected signals and installation |
| Fixed is lost after a cellular interruption | Correction freshness and automatic reconnection |
| Fixed position has a consistent offset | Base coordinates, reference frame and map alignment |
| Dashboard shows old Fixed status | Timestamps, upload delays and stale-status handling |
These checks narrow the investigation. Receiver logs and measured results should determine the corrective action.
What Should an RTK Tracking Platform Display?
A high-precision tracking platform should provide more than latitude and longitude.
Where supported, useful fields include:
- Current solution type.
- Position timestamp.
- Server receipt timestamp.
- Correction age.
- Receiver-reported accuracy estimates.
- Satellite information.
- Correction connection status.
- Reference-station identifier.
- Device power and communication status.
Keep receiver estimates separate from independently measured positioning error.
A platform should also distinguish “last report was Fixed” from “current positioning is Fixed.” If communication stops, the previous quality indicator should become visibly stale.
Test RTK Performance Before Ordering in Volume
Run a pilot that represents the intended application.
For an RTK vehicle tracker, include open roads, parking areas, building edges and temporary coverage loss. For a wearable RTK tracker, include normal wearing positions and movement patterns.
Record:
- Time to first Fixed solution.
- Percentage of valid test time in Fixed.
- Position error against a suitable reference.
- Recovery after obstruction.
- Recovery after correction loss.
- Communication delay.
- Power consumption.
Define the denominator when reporting Fixed availability. Excluding difficult periods without explanation can make a deployment look more reliable than it is.
A useful acceptance test measures repeatable operation across the working area, rather than relying on one screenshot showing Fixed.
Planning an RTK GPS Tracking Project
When discussing an RTK GNSS tracking project with Shenzhen Jinshengchang Technology Co., Ltd., provide the application, deployment country, operating area, installation method and required positioning performance.
Also specify the intended correction source, power supply, reporting interval and platform integration.
For vehicle, personnel or equipment applications, confirm the selected product’s RTK hardware and firmware configuration. RTK functionality should be verified for the exact model being quoted.
The correction service, antenna installation, receiver and platform should be evaluated together before deployment.
Frequently Asked Questions
Does RTK Float mean the tracker is defective?
No. Float can result from environmental conditions, correction delivery problems, incompatible settings or other limitations. Diagnose the complete system first.
Does a 4G connection guarantee RTK Fixed?
No. Cellular connectivity can transport corrections, but the receiver must receive suitable data and have usable satellite observations.
Can RTK Fixed still show the wrong location?
Yes. Incorrect reference coordinates, coordinate-system differences and other errors can affect absolute position. Verify performance against an appropriate reference.
Should the tracker keep displaying its last Fixed position?
It can retain the last position, but the platform should show its timestamp and make clear that it is historical.
What is the best first test when a tracker stays in Float?
Test in an open location while recording correction reception, correction age and receiver status. This provides a useful baseline before investigating more difficult installation environments.
