NTRIP Connection Failed: How to Diagnose and Fix RTK Correction Errors

Estimated reading time: 13 minutes

The corrections are not arriving. The receiver sits in Float, the accuracy readout will not drop below a few tenths of a meter, and a job is waiting on a fixed position.

NTRIP failures feel random in the field. They are not. They come from a fixed set of causes, and the order you check them in decides whether this costs five minutes or the afternoon.

This guide works that order: what a connection failure actually is, a lookup table for the message on your screen, then five checks from cheapest to most expensive. By the end you will know whether the fault is your credentials, your position reporting, your network, your environment, or the service.

What "NTRIP connection failed" actually means

An NTRIP connection failure means one of two things. Either the rover could not open an authenticated session with the caster, or it opened one and no correction data came back. Different faults, different fixes, and field time is lost treating them as one problem.

Everything below sorts into three states. Tell them apart before changing any setting.

• No connection. The client is rejected or never reaches the caster. An authentication error, a hostname that will not resolve, or a timeout. Nothing streams.
• Connected but no data. The login succeeded and the byte counter reads zero. The session is open and the caster is waiting on you.
• Data arriving but no RTK fix. Bytes flow and the solution still reads Float or Single. Corrections reach the receiver and cannot be used.

For background, read what NTRIP is and how the NTRIP handshake works. This article stays on diagnosis.

NTRIP error messages and what each one means

Start with the string on your screen. Every message below is one RTKdata's support documentation records, not a generic example.

Other clients word the same conditions differently: Unauthorized or 401 for authentication, Mountpoint not found or 404 for a bad mountpoint, Host not found or Connection timed out for a network problem, and Wait for GGA when the rover has no position to report.

Step 1: Verify your NTRIP credentials and mountpoint

This is the most common cause and the fastest to rule out, so it goes first. RTKdata's support documentation puts credentials and mountpoint at the top of its checklist too.

Five fields matter: host, port, mountpoint, username and password. The NTRIP login is not the website login: the username starts with rtk and carries its own password. Values are listed under host, port, username, password and mountpoint, and your RTKdata credentials covers where they are issued.

Then check what does not look wrong:

• A trailing space pasted in with the username or password. Retype both by hand.
• A capital O standing in for a zero, or a lowercase l for a one.
• The port left blank. Corrections run over TCP 2101, which IANA registers as rtcm-sc104.
• Full width characters pasted out of a PDF.
• The mountpoint in lower case. Names are case sensitive and go in capitals: AUTO works, auto and Auto return nothing.
• A local coordinate system name in the mountpoint field. Not a mountpoint, and it returns no corrections, usually with no error.

Two account-level causes belong here too. An expired subscription or trial rejects the login exactly as a wrong password does. And two devices sharing one credential set disconnect each other, because every simultaneous connection needs its own data stream.

Step 2: Confirm the rover is sending GGA

If the login succeeds and the byte counter stays at zero, this is almost always the reason. It is also the least explained failure in network RTK.

The caster does not know where you are. It reads your position from an NMEA GGA sentence the rover sends back up the open connection, then selects the nearest reference station and streams from it. No GGA means no position, no station assignment and no data. The session stays open and silent.

The symptoms are distinctive: a successful connection, zero throughput, and a status reading Waiting for Corrections or Waiting for Base.

1. Get a standalone position first. The receiver needs its own satellite lock before it has anything to report. Go outdoors, wait for five or six satellites, then connect NTRIP. Connecting first is the commonest version of this fault: bytes arrive and the solution never leaves Single, because the GGA going back out carries no position.
2. Enable GGA output. The label differs by app: Send NMEA GGA to Caster, Send receiver position and Transmit GGA are the same switch.
3. Set the interval. One hertz is the recommendation. A GGA sentence costs about 70 bytes, so once per second is free and keeps station selection current as you move.

Step 3: Check network reachability and latency

With credentials and GGA ruled out, the link itself is next.

Check for no cellular signal, an exhausted data allowance, airplane mode, a controller attached to Wi-Fi with no internet access, or an interface holding 0.0.0.0. If you use a phone hotspot or USB tethering, confirm that the controller is connected and can reach the internet. Corrections need outbound TCP on port 2101; a firewall, proxy, VPN or carrier restriction can cause an NTRIP connection timeout. On older controllers that cannot resolve hostnames, the failure reads as NTRIP server not reachable and is a DNS problem.

Then measure the right thing. Bandwidth is not the constraint and a speed test tells you little. What matters is how old corrections are when they reach the receiver. RTKdata's guidance is specific: under one second of latency gives full RTK performance, one to three seconds is degraded and produces more Float, and beyond three seconds corrections go stale and accuracy drops significantly.

Do not assume a buffer if the link drops. RTKdata's documentation puts the Float window after a link loss at 10 to 30 seconds before the solution falls to Single at 1 to 3 m. Treat a dropped link as a stop, not a countdown.

Step 4: Rule out sky view, multipath and interference

If data is arriving and the solution still will not hold, look up.

The antenna needs sky, not a view of it from underneath something. RTKdata's guidance is clear sky above roughly 15 degrees from the horizon. Check what changed since this last worked: a vehicle parked alongside, a tree in leaf, new scaffolding. Reseat the cable and inspect the connector.

Keep phones, USB-C chargers and handheld radios away from the antenna. Reflections are the harder problem, covered in multipath and dropouts.

Step 5: Check baseline distance to the correction source

A Fix that will not hold, or a time to fix that keeps stretching, can simply mean you are too far from the nearest station.

The AUTO mountpoint reads your GGA position and streams from the nearest of 20,000+ reference stations across 140+ countries, typically within 30 to 50 km. Inside coverage, expect 1-2 cm horizontal and 2-3 cm vertical. For the tightest work, stay within 15 km.

Before you drive out, check coverage in your area. How accuracy falls off with distance: RTK accuracy vs distance.

RTK NTRIP setup errors by receiver and platform

The same NTRIP settings fail differently on different hardware. These are the platform traps generic guides miss, each with the page that carries the full setup.

DJI Pilot 2 and Agras controllers

Two settings cause most of it. Select Custom Network RTK, not D-RTK 2 Mobile Station, and on Agras models turn the D-RTK 2 search toggle off, since it conflicts with network RTK. The aircraft itself, not just the controller, needs a satellite lock first, so start outdoors. No RTK Data Available, RTK Signal Weak and Fail to Enable Network RTK all point here. A battery swap resets the module, so wait for Fix again. Full sequence: DJI RTK troubleshooting.

Emlid Reach

Confirm Login to Resume Data Sync in Emlid Flow is an app authentication message, not an NTRIP fault. Sign back in, then retry. The setting that decides whether corrections flow is Send receiver position (NMEA) under Correction input, which has to be on. Set the coordinate system to Global CS rather than a local datum, and apply local transformations afterwards. Setup details: Emlid Flow.

Trimble and survey controllers

The failure here is usually correction format, not connection. RTKdata streams RTCM 3.2 using MSM4 and MSM7. The proprietary Trimble formats are never served: CMR, CMR+, CMRx and RTCM 2.3 are not available. A Survey Style left on CMRx connects, authenticates and never produces a fix, one of the commonest reasons corrections appear to work and do not. Select RTCM 3.x. Compatibility: Trimble receivers.

SW Maps and Android NTRIP clients

Check which receiver you are reading. If accuracy shows 10 m or more, the app is still on the phone's internal GNSS and no correction stream will change that. Send NMEA GGA to Caster must be enabled in the NTRIP profile. And if a raw IP sits in the host field, replace it with the regional hostname issued with your account: the IP is a DNS fallback, not the entry point. Walkthrough: SW Maps.

When the problem is your correction source, not your setup

One test separates your kit from the service, and takes two minutes.

Run the same credentials on a second device, on a different network. If the second device connects and streams, the fault is local: settings, GGA output, antenna or cable. If nothing connects anywhere, the problem is authentication or service side, and reconfiguring the rover will not move it. Give the test its own stream, since two devices on one credential set disconnect each other.

If it is the service, the question becomes what to expect from one. Four things are checkable before you commit:

• Published caster status or incident updates you can check for a reported outage.
• Coverage you can verify in advance, on a map, for the ground you actually work on.
• Documented mountpoints and connection settings, readable without opening a ticket.
• Support that answers specifically when you send your NTRIP settings and RTK status.

The full walkthrough sits in the common connection issues documentation, and RTK correction plans sets out what each plan includes. To talk it through, book a session with the team.

Most NTRIP failures come down to configuration or position reporting. An ordered diagnosis keeps a small setup problem from turning into a lost afternoon, and gives you evidence before you replace hardware or change services.

Keep a record of the symptom, what changed and which test made a difference. That record makes a recurring fault easier to recognise and gives support something specific to investigate. Once you have a working configuration, save it for the next job. The useful result is a connection you can explain and reproduce, with a clear reason to trust the receiver's status.