Selecting an NTRIP mountpoint for a GNSS rover

A stream name is a starting point

An NTRIP mountpoint identifies a stream available from a caster. The name may contain clues about the source, format or service, but naming conventions are not universal. A short label that resembles the project location does not prove that the stream is suitable. Obtain the provider description and keep it with the job configuration so the crew understands what the selected stream is intended to deliver.

NTRIP transports GNSS data; it does not by itself define the coordinate reference system or guarantee survey accuracy. A caster can distribute different kinds of information for different processing methods. Before entering credentials into a controller, identify whether the rover needs observations for RTK, a particular network service or another correction type. The selection should follow the positioning workflow rather than the order of names in a list.

Continue learning NTRIP explained: caster, client and mountpoint

Check data compatibility

Compare the stream format and supported messages with the rover documentation. A connection can succeed while the receiver cannot use the delivered content. Satellite constellations, signal support and message types all matter. Do not assume that a newer format label automatically improves every receiver. The useful combination is the one supported by both source and rover and validated through the project checks.

Record the receiver model and firmware used for the compatibility test. If another crew uses a different model, test that combination separately instead of copying the preset without verification. Keep a short list of approved configurations. This reduces the chance that an operator solves a communications problem by switching to a stream that connects successfully but does not support the intended positioning method.

Continue learning Planning radio line of sight for GNSS correction links

Understand the reference arrangement

Ask the provider how the stream relates to physical reference stations or a network solution. Some services depend on a rover position message to select or generate suitable data. Confirm the required client behaviour and whether the approximate position being sent is current. A stale location retained from a previous project can confuse the service selection process even when authentication is working.

Obtain the coordinate reference information and relevant service limitations. Include the reference frame and epoch where supplied, and understand how heights will be handled in the project. The stream is only one part of the coordinate chain. A correct mountpoint combined with an inappropriate transformation or geoid model can still produce a coordinate that disagrees with the intended deliverable.

Continue learning Planning GNSS construction stakeout from design to field evidence

Test the actual site

Connect at the work area using the devices, mobile network and application that will be used during production. Confirm that usable data arrive and inspect correction age, solution state and available diagnostics. Test a known point rather than stopping when the connection indicator turns green. The point comparison evaluates the whole workflow, including configuration choices outside the caster connection itself.

Repeat the test at representative locations if the project covers a large or obstructed area. Document the mountpoint, caster address, connection time and observed result. Keep credentials out of shared screenshots. A useful test report identifies the stream precisely while allowing the account password to remain private. This makes later troubleshooting possible without turning the survey archive into a collection of exposed access details.

Continue learning Checking RTCM interoperability between GNSS equipment

Distinguish connection and authorization failures

A rejected login, an unavailable mountpoint and a connected but unusable data stream require different responses. Read the client message and preserve the relevant error text. Confirm the caster address and port before changing receiver settings. If the account works with another approved mountpoint, ask the provider whether access to the selected service is included rather than repeatedly resetting the rover.

Where a sourcetable is available, use it as a discovery aid and verify the details with the service documentation. The table may not answer every question about reference coordinates, operating conditions or account permissions. Maintain a concise support note containing the time, client version and failure stage. That information is more actionable than a report that the receiver simply would not fix.

Continue learning NTRIP explained: caster, client and mountpoint

Control changes during production

Save the approved selection as part of the job record and train the crew to recognize it. If the mountpoint changes, record the old and new values and the reason for the change. A different stream may have a different reference arrangement even when both are described as RTK corrections. Treat the switch as a configuration change requiring a coordinate check, not merely as a network reconnect.

Do not overwrite the original preset immediately. Preserve a copy so the office can reconstruct which stream supported earlier observations. Mark the transition time and identify production points around it. If the new check disagrees, stop combining the datasets until the cause is understood. A transparent transition record is much easier to resolve than an unexplained offset discovered after several crews have finished.

Continue learning Planning radio line of sight for GNSS correction links

Maintain a useful field preset

Include the caster host, port, mountpoint, authentication method and any required rover position output in the private configuration. Store the public technical description separately from passwords. Verify the preset after controller updates or equipment replacement, because an imported connection profile may omit settings that were previously supplied by another application. A saved name alone is not enough to reproduce the connection.

Review the preset when the provider announces service changes. Keep a tested alternative if the project needs continuity, but document its reference and compatibility just as carefully as the primary stream. Mountpoint selection is successful when it leads to usable corrections, appropriate coordinates and repeatable field checks. The strongest evidence is a recorded working configuration supported by observations at the site where it will be used.

Continue learning Planning GNSS construction stakeout from design to field evidence

An approved mountpoint record

A useful mountpoint record can fit on a short project sheet. It identifies the caster, stream name, provider description, required client behaviour, rover versions tested and coordinate reference information. Add the date and results of the site checks. Keep passwords in the private access configuration rather than on the general technical sheet. Another operator should be able to recognize the correct stream and understand its role without gaining access to unrelated account secrets.

When a provider replaces or renames a stream, preserve the old record and create a new revision. Recheck the complete workflow at suitable points before continuing production. A renamed service may be technically equivalent, but that equivalence should come from provider information and field evidence, not from a guess based on similar names. The record is valuable because it separates a convenient saved connection from an approved survey configuration whose reference meaning and observed performance are known.

Use a recognizable preset name that includes the approved service role without embedding a password. Keep the exact mountpoint value in the technical record, since a friendly display name may remain unchanged after its underlying connection is edited. During handover, compare the saved values with the approved record rather than trusting the label alone.

Continue learning Checking RTCM interoperability between GNSS equipment