RTK Correction Failures: Causes and Field Fixes

A GNSS receiver that drops from fixed to float halfway through a setting-out run does more than delay the crew. It creates uncertainty around every point collected since the last reliable check. RTK correction failures are therefore not simply an IT problem or a frustrating warning on the controller. They are a quality-control issue that can affect levels, positions, machine control and the programme.

For surveyors and site engineers, the quickest response is rarely to restart everything and hope for the best. A structured check of the correction source, communications link, satellite environment and coordinate setup will usually identify the cause. Just as importantly, it helps determine whether the data already collected can be trusted.

What an RTK correction failure actually means

Real-time kinematic positioning works by applying correction data from a known base station or a network of reference stations to the rover receiver. Those corrections compensate for much of the error caused by satellite clock drift, orbital information and atmospheric effects. When the rover resolves the carrier-phase ambiguities, it can report a fixed solution at centimetre-level accuracy under suitable conditions.

A failure can occur at several points in that chain. The rover may have poor satellite reception, the correction stream may be unavailable, a UHF radio link may be weak, or the receiver may be connected to the wrong mountpoint. It may also appear that RTK has failed when the real issue is a coordinate reference system, geoid model or base-station configuration.

The distinction matters. A receiver with no corrections will normally show an autonomous or DGPS position. A receiver receiving corrections but unable to resolve ambiguities will show float. A fixed solution with the wrong datum can look technically healthy while placing every point in the wrong location.

The common causes of RTK correction failures

Lost or unstable correction data

For Network RTK, the correction stream normally reaches the rover through a SIM-enabled controller or receiver using NTRIP. Weak mobile coverage, an expired data allowance, an incorrect APN, blocked roaming, or an inactive caster account can all interrupt that connection. On a live construction site, temporary welfare units, hoardings and local terrain can also affect mobile signal more than expected.

With a local base and rover setup, the issue may be the UHF radio path instead. Check that base and rover use the same frequency, protocol and channel spacing, and that the selected transmit power is lawful and appropriate for the equipment. A low base antenna, damaged cable, flat radio battery or obstruction between the base and rover can reduce the usable range sharply.

Do not assume that a connection icon means the corrections are useful. Look at correction age and data rate. Corrections that are several seconds old, or arriving intermittently, are unlikely to support a stable fixed solution.

Poor satellite visibility and multipath

RTK needs a strong, clean satellite signal. Trees, deep cuttings, tall façades, steel-framed structures and bridge decks reduce visibility and can reflect GNSS signals. These reflections, known as multipath, make the measured path appear longer than it is and can prevent ambiguity resolution.

A clear sky view is particularly important when initialising. If possible, obtain and verify a fixed solution in an open area before moving close to buildings or vegetation. If the fix is repeatedly lost in one location but returns once the rover is moved a short distance, the site environment is the likely cause rather than the network.

Satellite geometry also changes through the day. A low number of tracked satellites, poor PDOP, or several satellites at low elevation can make a normally reliable setup struggle. This is one reason to plan time-critical work around predicted GNSS availability rather than treating every hour as equivalent.

A mismatch in base, rover or network settings

A surprisingly high proportion of support calls come down to a configuration mismatch. The rover may be set to the wrong correction format, the wrong network mountpoint, or a base station may have been moved without updating its known coordinates. Firmware differences can also cause unexpected behaviour, particularly where a receiver, radio and controller have not been updated as a tested set.

For a base-rover pair, the base must remain precisely where its entered or surveyed coordinates say it is. Moving a base tripod after initialisation, even slightly, shifts the reference for all rover observations. On repeat visits, use a stable mark and follow the same coordinate and antenna-height procedure each time.

Check antenna heights carefully too. A correct RTK fix with an incorrect measured height will produce consistently wrong levels and positions. Confirm whether the field software expects slant height or vertical height, and whether the antenna measurement point has been selected correctly.

Datum, transformation and geoid errors

This is the failure mode most likely to create confident-looking bad data. The screen may show a fixed solution and acceptable residuals, yet the points do not agree with the design, control or adjacent survey.

UK projects commonly require careful handling of ETRS89, OSGB36, OSTN transformations and an appropriate geoid model for orthometric heights. A network correction service may deliver coordinates in one reference frame while the job is configured for another. Similarly, a design file may use local site coordinates that require a correctly defined localisation.

Vertical discrepancies deserve particular scrutiny. GNSS naturally measures ellipsoidal height, whereas drawings and site control often use heights related to Ordnance Datum. Without the correct geoid separation and project setup, the difference can be significant. Never correct this with an arbitrary offset unless the project control strategy specifically calls for one and it has been checked.

A field process for diagnosing the fault

When RTK stops fixing, begin by recording what the controller reports: solution status, correction age, satellite count, PDOP, radio or mobile signal and any error message. This creates a useful starting point and avoids changing several settings at once.

First, establish whether corrections are reaching the rover. For Network RTK, confirm the SIM connection, caster login, selected mountpoint and current data flow. For radio RTK, inspect antennas and cables, confirm batteries are adequately charged, then compare frequency, protocol and channel settings at both ends.

Next, move to a clear, known location. Allow the receiver time to track satellites and watch whether it achieves a fixed solution. If it does, return to the working area and observe whether the fault reappears near a specific obstruction. If it cannot fix in open sky despite current corrections, review receiver settings, firmware and the correction source.

Once a fixed solution is obtained, verify it against a known control point. Check both horizontal position and height, using the project’s stated tolerance rather than assuming centimetre-level RTK is sufficient for every task. For high-consequence setting out, independent checks with a total station or a second occupied control point remain sensible practice.

If the receiver has been floating, disconnected or operating autonomously, identify the time and extent of affected work. Points collected before the loss of fix may be valid; points observed afterwards need review. Keeping clear field notes, screen captures and raw observation logs makes that decision far easier back in the office.

Preventing repeat RTK correction failures

Prevention starts before arriving on site. Confirm that subscriptions, SIMs and login credentials are current, and that firmware is compatible across the kit. Charge rover, controller and radio batteries, carry suitable spares, and inspect antenna threads, cables and connectors for damage.

A short daily verification against known control is one of the best safeguards available. It tests the entire chain: receiver, antenna, correction source, transformation, geoid and field-code setup. It also gives the crew confidence that the job has opened in the correct coordinate system.

For projects with limited mobile coverage, radio interference or demanding accuracy requirements, assess whether a local base station, external UHF radio, correction-service alternative or hybrid workflow is more appropriate. Network RTK is efficient across many UK sites, but it depends on mobile connectivity and network availability. A local base provides greater independence, but requires disciplined setup and control management.

Training also has a direct effect on data quality. Operators need to understand the difference between fixed and float status, why correction age matters, and when a coordinate check is required. A familiar controller workflow is useful, but it should never replace an understanding of what the receiver is reporting.

Where faults persist, professional testing can be quicker and cheaper than losing another shift to uncertain results. Survey Tech can help teams assess whether the issue lies with the receiver, radio, antenna, configuration or project workflow, as well as arrange servicing, repairs, equipment hire and practical user training.

The aim is not merely to restore a green fixed indicator. It is to return to work with a correction stream, coordinate setup and independent check that support decisions made on site.