NTRIP Connection Flow Explained

Estimated reading time: 8 minutes

Key takeaways

• NTRIP streams GNSS corrections over the internet using three roles: client (rover/app), caster (server/router), and mountpoint (named stream).
• Pick the right mountpoint from the sourcetable (format like RTCM 3.x MSM, required constellations, proximity) and confirm whether NMEA‑GGA is required for VRS/NEAR.
• Know the protocol differences: NTRIP v1 replies with ICY 200 OK; NTRIP v2 is fully HTTP/1.x and uses the Ntrip-Version: Ntrip/2.0 header.
• Time‑outs are not standardized. Typical starting points: connect 5–10 s, read 30–60 s. Use exponential backoff with jitter and failover to alternate mountpoints/casters.
• Monitor “Age of Corrections” instead of a heartbeat: aim for ≤ 2 s (application‑dependent); trigger reconnect/failover when gaps rise.
• Security & networking: Port 2101/TCP is common; many deployments also offer HTTPS/TLS on 443 for easier firewall traversal.
• RTKdata automates sourcetable parsing, credentials, dynamic retry/backoff, and multi‑mountpoint failover for reliable RTK streaming.

Introduction to NTRIP protocol

A robust NTRIP connection keeps your RTK solution steady and precise. NTRIP (Networked Transport of RTCM via Internet Protocol) delivers GNSS correction data from networks of reference stations to your rover over standard internet links.

• Client: the rover or app that requests corrections.
• Caster: the server/router that lists streams (“mountpoints”) and forwards data.
• Mountpoint: a named correction stream with a format, coverage, and policy (e.g., whether GGA is required).

Connection flow in NTRIP: client, caster, mountpoint

1. Open TCP session to the caster (commonly port 2101; some services also provide 443 for TLS).
2. Fetch sourcetable: request “/” and parse the returned list of mountpoints (RTCM format, constellations, auth, NMEA requirement, etc.).
3. Select a mountpoint that matches your rover’s capabilities and proximity.
4. Connect to the mountpoint with an HTTP‑style GET (include Authorization if required). After success, the caster streams RTCM.
5. (If required) Send NMEA‑GGA immediately after connecting and periodically so the caster can generate VRS/NEAR corrections for your position.
6. Monitor and maintain the link: track data gaps and Age of Corrections; reconnect with backoff and failover when needed.

# Fetch sourcetable (v1)
GET / HTTP/1.0
User-Agent: NTRIP my-rover/1.0

# Typical v1 sourcetable response header
SOURCETABLE 200 OK
...
ENDSOURCETABLE

# Connect to a mountpoint (v1)
GET /MY_MOUNT HTTP/1.0
User-Agent: NTRIP my-rover/1.0
Authorization: Basic <base64 user:pass>

# Response (v1)
ICY 200 OK
<binary RTCM stream...>

NTRIP v1 vs v2: handshake & headers

Understanding the handshake saves hours of debugging, especially when using strict HTTP libraries:

• v1: Sourcetable returns SOURCETABLE 200 OK, and mountpoint connections reply ICY 200 OK (Shoutcast‑style). Some HTTP stacks reject ICY unless explicitly allowed.
• v2: Fully HTTP/1.x compliant; clients should send Ntrip-Version: Ntrip/2.0. Servers often reply with HTTP/1.1 200 OK and may use Transfer-Encoding: chunked.

# Sourcetable (v2)
GET / HTTP/1.1
Host: caster.example.com
User-Agent: NTRIP my-rover/2.0
Ntrip-Version: Ntrip/2.0
Connection: close

HTTP/1.1 200 OK
Content-Type: text/plain
...

# Mountpoint (v2)
GET /MY_MOUNT HTTP/1.1
Host: caster.example.com
User-Agent: NTRIP my-rover/2.0
Ntrip-Version: Ntrip/2.0
Authorization: Basic <base64 user:pass>

HTTP/1.1 200 OK
Transfer-Encoding: chunked
<binary RTCM stream...>

Sourcetable fields explained (STR/CAS/NET)

Sourcetables contain lines starting with STR, CAS, or NET. For mountpoint selection focus on STR entries:

• Mountpoint name (case‑sensitive)
• Format & details (e.g., RTCM 3.2 MSM4)
• Nav systems (GPS/GLO/GAL/BDS)
• Solution type (single base, i‑MAX, VRS/NEAR)
• NMEA flag (0/1) — 1 means GGA required
• Authentication (N=none, B=Basic, D=Digest)
• Approx. location & bitrate

STR;MY_MOUNT;My Network VRS;RTCM 3.2;1004(1),1006(10),1077(1),1087(1);GPS+GLO+GAL;N;N;0;0;RTK;N;MY-ORG;DE;52.52;13.41;0;1;B;N;0;

NMEA‑GGA requirements for VRS/NEAR

Network solutions like VRS or NEAR need your current rover position to tailor corrections.

• When: Send one GGA immediately after connecting; continue periodically (typ. every 5–60 s) or when your position changes significantly.
• Format: standard NMEA‑GGA (WGS‑84). Ensure the coordinates are in the correct datum and reasonably accurate.
• If you skip GGA: many casters will not deliver a usable stream or will fall back to a generic solution.

$GPGGA,123519,5252.1234,N,01324.5678,E,1,12,0.8,45.4,M,0.0,M,,*5C

Authentication & security (Basic Auth & TLS/ports)

• HTTP Basic Auth is most common: send Authorization: Basic <base64(user:pass)> in your mountpoint request.
• TLS/HTTPS: Many services expose NTRIP on 443 for encrypted transport and better firewall compatibility (some enterprises block 2101).
• Library quirks: Strict HTTP clients may reject ICY 200 OK (v1). Either use v2, or allow ICY responses in your stack.
• Proxies/NAT: Prefer persistent TCP with keep‑alive disabled for long‑lived streams; ensure proxies don’t buffer or drop idle connections.

Timeout & reconnection best practices

• Connect timeout: 5–10 s baseline (mobile networks).
• Read timeout / idle: 30–60 s baseline; increase in poor coverage. There is no universal standard—tune for your network.
• Backoff with jitter: 5 s → 10 s → 20 s → 40 s (cap), add random jitter to avoid thundering herds.
• Failover: Pre‑configure alternates (other mountpoints/casters, including TLS endpoint on 443).
• Health monitoring: Track Age of Corrections and message continuity. Reconnect if AoC drifts beyond your threshold (e.g., > 3–5 s).

Troubleshooting and recommended setup

Common issues and quick checks:

• Auth errors: wrong username/password or missing Basic Auth header.
• Wrong mountpoint name: case‑sensitive; verify against the latest sourcetable.
• Format mismatch: rover expects MSM but stream is legacy RTCM; choose a compatible mountpoint.
• GGA not sent: VRS/NEAR mountpoints with NMEA=1 won’t serve valid data without periodic GGA.
• Firewall/ports: 2101 blocked; try TLS endpoint on 443 if available.
• Over‑aggressive timeouts: raise read timeouts in marginal coverage; apply backoff and jitter.
• HTTP library rejects ICY: switch to v2 or enable ICY compatibility.

Recommended setup: pick the nearest compatible MSM stream, verify auth & NMEA flags, set sane connect/read timeouts, backoff with jitter, and configure at least one failover mountpoint (ideally on TLS/443).

Developer cheat sheet

Reliable RTK link with RTKdata

Success with NTRIP comes from careful sourcetable parsing, correct mountpoint choice, and resilient connection management (timeouts, retries with jitter, and failover). RTKdata streamlines these steps so your team can focus on field work, not sockets and headers.