The Four Roles Behind Every NTRIP Connection
Component | What It Does |
|---|---|
NTRIP Source | The GNSS reference station itself, a receiver at a known or surveyed position generating raw correction data |
NTRIP Server | Software that takes the source's data and uploads it to a caster, either a single base station's corrections or a network RTK engine's computed stream |
NTRIP Caster | The central HTTP server that receives streams from one or more servers and distributes them to connected clients, handling authentication and mount point selection |
NTRIP Client | The rover, the receiver or app that connects to a caster, requests a specific stream, and applies the corrections it receives |
The caster is genuinely the component most people mean when they talk about "connecting to NTRIP", it's the address, port, username, password and mount point entered into a receiver's correction settings. Our What Is an NTRIP Caster? guide covers that component specifically, including how it advertises what's available and who typically runs one.
The Actual Connection Handshake
A rover's NTRIP client opens a standard TCP connection to the caster's address on port 2101, the same port most network RTK services and casters use by default. It then sends an HTTP request identifying the specific mount point it wants, along with a username and password if the service requires one.
The caster checks those credentials, confirms the requested mount point exists and is active, and if everything matches, starts streaming RTCM correction messages continuously over that same connection. From the rover's side this all happens automatically once a correction profile is saved, the visible result is just a status changing from "waiting for corrections" to an active stream, followed by the receiver progressing through SINGLE, FLOAT and toward FIX.
Finding the Right Stream: Mount Points
A mount point is a named data feed on a caster, each one representing a specific correction source: a single physical base station, a Virtual Reference Station computed for a general area, or a network RTK engine's output for a particular region. A caster hosting a national network RTK service can list dozens or hundreds of mount points side by side, one rover connecting to exactly one at a time.
Choosing the wrong mount point, a single base many kilometres away instead of the nearest one or the correct VRS option, is a common cause of a rover holding FLOAT or converging slowly even though the connection itself is working fine. A caster's sourcetable is what lists every mount point it offers, covered in full in our NTRIP Caster guide.
What's Actually Riding Inside the Stream
Once connected, the data flowing from caster to client is RTCM3, the same correction message format a physical base station broadcasts over LoRa or UHF radio, just carried over an internet connection instead of a local radio link. NTRIP itself doesn't generate or compute any correction, it's a delivery mechanism, not a correction method; the accuracy a rover ends up with depends on the quality of the source data feeding into it, not on NTRIP as a protocol.
That distinction matters for one specific reason: a single-base mount point and a VRS mount point both arrive over exactly the same NTRIP connection, the difference is entirely in what's computed before the data reaches the caster. Our What Is RTK? guide covers what the correction itself actually does once it reaches the receiver.
What This Means in Practice
Every piece of information needed to diagnose an NTRIP connection problem maps onto one of the four roles above: no connection at all usually means a caster address, port or credential problem; a connection that holds but never reaches FIX usually means the wrong mount point or a source too far from the rover's actual position; a stream that drops repeatedly usually means the internet connection at the client end, not the caster itself. Knowing which of the four components a given symptom points to is most of what separates a quick fix from an extended troubleshooting session.
RTK Network Subscription - 1Y Unlimited
More than 7,500 base stations · Accuracy of 1.5cm with EU Certification
Free Gifts Included
Free Gifts Included
Common Questions
2101 is the common default, used by most network RTK services and casters, though a specific provider can configure a different port.
NTRIP is a delivery mechanism, not a correction method. Accuracy depends entirely on the source data feeding into the caster, a single base station or a network RTK/VRS engine, not on the protocol carrying it.
The server uploads correction data from a source to the caster; the caster is the central point that receives from one or more servers and distributes to connected clients. They're often run by the same organisation but are functionally separate roles.
Usually the wrong mount point selected, too far from the actual correction source, or a VRS service not receiving the rover's own position correctly. A connection succeeding is not the same as a usable correction being applied.
Yes, throughout the session. If the connection drops, corrections stop reaching the rover and accuracy degrades back toward standalone GNSS until the link returns.
