An RTK rover operating without a local radio base requires a controlled method for receiving correction data. NTRIP is commonly used to transport correction messages over an internet connection. A reliable deployment requires more than server entries: it requires verified service parameters, a stable data route, compatible receiver and field-software settings, a defined coordinate workflow, and validation before production collection begins.
Use this procedure to configure and document the correction path. It complements the project control procedure, the correction-service provider’s instructions and validation against accepted control.
What NTRIP does in an RTK workflow
NTRIP is a method for delivering GNSS correction data over an internet connection. In a typical network RTK workflow, a reference-station network or correction provider makes a stream available through a caster. The rover, controller or connected application uses mobile data or another internet path to connect and receive that stream. The receiver then uses the incoming correction information as part of its RTK solution.
Required configuration information
Ask the correction-service provider for the connection details in writing and record them in the project file. Most clients require a caster host or IP address, port, username, password and mountpoint. The provider may also specify a correction format, whether the rover should send an approximate position and any regional coverage or reference-frame notes. Never guess a mountpoint or copy credentials from an unrelated project.
- Connection route: confirm whether mobile data comes from the receiver, controller, a phone tether or a field router.
- Rover/client: identify the receiver, controller and software profile that will make the NTRIP connection.
- Provider details: record the host, port, credentials, mountpoint and any expiry or account limits.
- Project context: confirm coordinate reference, vertical reference and the team’s validation method before work begins.
NTRIP configuration procedure
1. Establish the initial GNSS solution
Power the rover outdoors where it has an open view of the sky. Give it time to obtain a normal standalone position before trying to connect. Many workflows use the rover’s approximate position to help select or serve an appropriate correction stream. Starting indoors, beside large reflective surfaces or under dense cover makes the later diagnosis less useful.
2. Verify the data communication path
Check that the device responsible for data has a working connection in the work area. A controller may appear connected to a rover while still lacking mobile data. If possible, confirm the data path with the planned SIM, tether or router—not only with office Wi-Fi. Record the condition when a project site has intermittent coverage so crews know whether to plan a local-base alternative.
3. Create a controlled correction profile
Open the receiver or field-software correction settings and create a clearly named profile for the project or service. Enter the caster, port, login and mountpoint exactly as supplied. Select the correction format only when the provider and receiver workflow specify it. Preserve a working profile before editing it; a duplicated profile is safer than overwriting an established setup used by another crew.
4. Confirm position reporting and data reception
Some services require the client to send an approximate rover position, often labelled NMEA GGA or “send position.” Confirm the provider’s requirement and that the field client is permitted to send the information. Then watch the correction status: the useful question is whether the rover is actually receiving a current stream, not merely whether the login screen accepted the password.
5. Stabilize and validate the solution
A connected stream is not the end of the process. Observe the solution status according to the receiver’s terminology, then use your project’s normal check against known control or another accepted quality procedure. Confirm that the coordinate and vertical settings are appropriate for the deliverable. A healthy connection cannot correct a wrong localization, wrong datum choice or an unreviewed project template.
Select the correction architecture for the project
NTRIP-based network corrections can be practical when service coverage and field data connectivity are dependable. A local base-and-radio workflow can be appropriate when a site needs an independent local correction source, when mobile coverage is limited or when the project control approach calls for it. Neither path should be selected by a single label such as “network” or “radio.” Consider coverage, terrain, number of rovers, control responsibilities, mobility and the consequence of a connection interruption.
For a wider comparison, review VRS vs. RTK Base Station and the RTK base-station range guide.
When the correction session is unstable
Do not immediately reset every device. First note the time, location, rover status, correction age, data signal, selected mountpoint and error message. Test the same profile in an open area with known usable data coverage. If the connection works there but not at the project location, the next check is likely coverage or environment. If multiple rovers fail at the same time, investigate the service account, provider status or common network path before treating each rover as a separate hardware fault.
A field support request is much easier to resolve when it includes the correction method, the provider’s non-sensitive service details, the receiver/controller combination, the site environment and a screenshot or log of the status. Do not send passwords in an unsecured channel. For recurring issues, use the TOKNAV support path to document the workflow rather than relying on an informal description.
FAQ
Does NTRIP replace a GNSS base station?
NTRIP describes correction delivery over the internet. It may be used with a network service or a base that publishes a stream, but it does not remove the need to choose and validate the correction source for the project.
Why is the rover connected but not ready for production?
A login can succeed while no usable data is arriving, the rover environment is poor, or the project coordinate setup is unsuitable. Check the incoming stream and apply the accepted field validation procedure.
What should a crew record?
Record the correction provider, mountpoint, connection route, coordinate context, solution status and known-point or project check. This makes the setup repeatable for the next shift.
Assess the correction architecture before deployment
For a new rover, local base or network-correction project, share the country, coverage area, number of users, control requirements and data-connectivity constraints. Contact TOKNAV to discuss the appropriate GNSS receiver, antenna and correction path.