Resources / Learn

NTRIP Explained: Streaming RTK Corrections Over the Internet

Casters, mountpoints, clients and servers — the 10-minute guide to NTRIP for drone crews.

NTRIP Explained: Streaming RTK Corrections Over the Internet

The moving parts: caster, server, client, mountpoint

NTRIP — Networked Transport of RTCM via Internet Protocol — is nothing more exotic than HTTP streaming for GNSS corrections. Four roles: an NTRIP server pushes a correction stream from a source (your base station) to a caster; the caster is the switchboard, hosting one or more mountpoints — named streams — behind usernames and passwords; an NTRIP client (your drone controller, rover, or tractor terminal) connects to a caster, requests a mountpoint, authenticates, and receives RTCM. That is the entire architecture, whether the caster is a national CORS operator, Emlid's free Emlid Caster, or a caster running inside your own base.

The vocabulary trips newcomers because vendors mix it. DJI Pilot 2 calls the client side “Custom Network RTK”; Emlid Flow shows “Base output → NTRIP” for the server side; survey software says “connect to CORS”. Same protocol underneath, RTCM 3.x payload throughout.

Three ways to run it in the field

Public / commercial caster: subscribe to a network (state CORS, VRS Now, SmartNet), receive credentials, point every rover at it. Zero hardware, full coverage dependence, per-rover fees. Cloud relay for your own base: push your base's stream to a free relay like Emlid Caster, and rovers pull it from anywhere with internet — elegant when base and rover both have connectivity but no line of sight. Base-hosted caster: the base itself runs caster and server onboard; rovers (or the drone controller joined to the base's Wi-Fi, or over 4G) connect directly to it. This is the self-contained pattern — UAV Mate's console at 192.168.2.1:8080 exposes exactly these credentials, and Emlid's Local NTRIP is the same idea — with no third party in the loop and no fees. The three differ only in where the caster lives; the client configuration is identical.

Setting up a drone client, concretely

In DJI Pilot 2: RTK settings → RTK Service Type → Custom Network RTK, then enter host (the caster's IP or domain), port (2101 is the NTRIP convention), mountpoint, username, and password, then Save. Mountpoints are case-sensitive; a wrong-case entry connects to the caster and receives silence. Within seconds the aircraft should report a FIX with correction age of 1–2 s. Emlid, CHCNAV, South, Trimble, and Leica rovers ask for the same five fields in their own software; auto-steer terminals likewise. One caster, one mountpoint, any number of simultaneous clients — the broadcast economics that make a single base feed an entire mixed fleet (walkthrough with a Matrice 350 in the M350 guide).

Bandwidth, latency, and what ‘correction age’ tells you

An RTCM 3.x MSM stream is tiny — a few kilobits per second — so any 3G-era link carries it; what matters is continuity. Clients display correction age: the seconds since the last correction arrived. Healthy links sit at 1–2 s; ages climbing past ~5 s degrade the solution toward FLOAT, and past ~30 s most engines drop RTK entirely. Age spikes diagnose the transport, not the base: cellular handovers, congested sites, or a controller sharing a phone hotspot at the edge of coverage. When a site's cellular is marginal, stop fighting it — switch transports to UHF radio or RC link, which carry the identical RTCM without the internet dependency (choosing a path).

Security and multi-user hygiene

Casters authenticate with plain credentials, so treat them like any shared password: unique per project when clients are external, rotated when crews change, never reused from other systems. A base-hosted caster narrows exposure further — credentials only matter inside your site's radio horizon or your own 4G APN. For fleets, one mountpoint per base is normal; resist creating per-rover mountpoints that multiply administration without benefit. And log usage where the caster allows: knowing which clients connected when turns “why was the tractor in FLOAT at 2 pm” from a mystery into a lookup.

When NTRIP is the wrong tool

No cellular, no NTRIP — remote sites route around it entirely with radio or RC link. Ultra-low-latency machine control loops on some sites prefer radio's determinism to cellular jitter. And a solo pilot with one drone and a base three metres away gains nothing from a cloud round-trip — Local NTRIP over the base's own Wi-Fi or the RC link is simpler and unbreakable. NTRIP earns its keep at distance and scale: many rovers, long baselines, existing connectivity. Knowing when not to use it is half of mastering it.

Anatomy of a connection: what happens in the first two seconds

Watching the handshake demystifies every failure. The client opens a TCP connection to host:port and sends an HTTP-style request naming the mountpoint with Basic-auth credentials. The caster replies ICY 200 OK — then bytes of RTCM begin flowing, continuously, no further negotiation. A wrong mountpoint typically earns the sourcetable (a text listing of available streams) instead of corrections: the client sits “connected” receiving a menu it cannot eat, which is exactly the connect-but-no-FIX symptom. Wrong credentials earn a 401. A dead server behind a live caster earns silence and a climbing correction age. Three failure signatures, each visible in seconds once you know the handshake — and every NTRIP client from Pilot 2 to a tractor terminal is performing this identical ritual.

The sourcetable is also a diagnostic gift: fetch it with any client (or a browser at http://host:port) and you see every mountpoint the caster offers, its format, and its nominal position — instant confirmation that the base's stream exists before you ever configure the rover.

Scaling up: one base, a mixed site, zero drama

A working example ties it together. A construction site runs a base-hosted caster on the site's PPP base. The Matrice 350 connects via Custom Network RTK through the RC Plus on 4G; two excavators' machine-control ECUs connect over the site Wi-Fi; a surveyor's Emlid Reach RS3 connects through a phone hotspot; a grader on the far pad, out of Wi-Fi, takes the same RTCM over the UHF radio instead. Four client types, three transports, one mountpoint, one absolute datum — and when the fibre contractor's Trimble rover arrives unannounced, it joins with five typed fields. That frictionlessness is what NTRIP standardization bought the industry.

One-line takeaway

NTRIP is just HTTP-style streaming of RTCM: a caster, a mountpoint, five credentials — master the handshake and every brand's ‘network RTK’ screen becomes the same five boxes with different paint.

Further reading

For the payload inside the stream, see RTCM 3.x explained; for when to abandon the internet path entirely in favour of radio or the drone's RC link, the decision table lives in choosing a correction path.

Frequently asked questions

What port does NTRIP use?

By convention 2101 (sometimes 2102 or 80). Your caster's documentation or base console states it explicitly — enter exactly what it shows.

Why does my client connect but never reach FIX?

Usually a silent mountpoint mismatch (case-sensitive), wrong credentials, or a base that is not actually broadcasting. Verify the base's stream state first, then re-enter the five fields character-for-character.

Is Emlid Caster free?

Yes — Emlid operates it as a free cloud relay for passing corrections between a base and rovers over the internet. Base-hosted casters remove even that dependency.

Can NTRIP work without internet?

The protocol needs an IP network, but not the internet: a base-hosted caster over the base's own Wi-Fi (Local NTRIP pattern) serves clients with no external connectivity at all.

Centimetre RTK. No CORS. Anywhere.

UAV Mate is a self-converging PPP/RTK base station: 1.5 cm ITRF2020 coordinates in minutes, broadcast to any RTCM 3.x drone or rover.

See UAV Mate

Related reading

RINEX Logging and the PPK Backup Workflow