Your robot has not lost the correction stream. It has lost the sky.
A robot loses RTK fix between buildings because the surrounding structures block direct line of sight to most of the constellation, and many of the signals that do arrive have bounced off a facade first. With too few clean satellites and reflected ranges corrupting the measurements, the receiver can no longer resolve carrier-phase integer ambiguities, so it drops from fix to float or to a standalone solution. This is a geometry problem, not a correction problem — no base station or NTRIP setting removes it.
What is actually happening
Centimetre-level RTK depends on resolving the whole number of carrier wavelengths between the satellite and your antenna. That resolution needs enough satellites, spread widely across the sky, tracked continuously for long enough to converge. A street between two buildings attacks all three conditions at once.
- Sky-view blockage. A corridor of tall buildings can leave a narrow strip of visible sky. Satellite geometry collapses, DOP values climb, and the vertical channel degrades first.
- Multipath. The receiver tracks both the direct signal and its reflection off glass or concrete. The two interfere, carrier phase becomes noisy, and cycle slips accumulate.
- NLOS reception. Worse than multipath: the direct path is blocked entirely and only the reflection arrives. The measured range is now longer than the true range by the extra path length, and the receiver has no way to know.
Ambiguity resolution needs consistency over time. Every cycle slip resets the process. In a canyon the slips never stop, so the fix never returns — and when the robot emerges into open sky, reacquisition typically takes seconds, not milliseconds, during which it is still navigating on a degraded solution.
Check these first
Several of the common causes are genuinely fixable and cost nothing. Rule them out before concluding the environment is at fault.
- Correction age. Log it, because urban canyons kill cellular connectivity as effectively as they kill GNSS, and a stalled NTRIP stream produces the same symptom. Judge it against the real tolerance: the receiver accepts RTK corrections up to about a minute old, and latency should ideally stay under one second. So a brief stream outage is survivable — but if the fix drops while correction age is still well under a minute, the stream is not your problem. The sky is.
- Antenna placement. The antenna needs a clear upward hemisphere and a proper ground plane. Mounted low, beside a metal mast, or under a sensor arch, it will see reflections preferentially.
- All four constellations, in the corrections too. GPS, Galileo, GLONASS and BeiDou together give you far more chance of enough usable satellites in a narrow strip of sky. Check both ends: your correction stream must carry RTCM3 multi-signal messages for all four systems, because a missing constellation in the corrections degrades performance significantly even when the receiver is tracking it.
- Antenna type. Only an active antenna with a built-in low-noise amplifier is suitable, covering both L1 and L2 bands. Combined GNSS/Wi-Fi/cellular assemblies are a common and costly mistake: they perform poorly for high-precision RTK and can degrade further depending on what the other radios are doing.
- Log the whole route, not the failure point. Record fix type, satellite count, DOP, C/N0 and correction age at full rate. The pattern across a lap tells you far more than a snapshot at the moment things went wrong.
Why it still fails after all of that
Once the checklist is clean, you have reached the limit of the technology rather than the limit of your integration. RTK is a line-of-sight method. Its availability is set by how much sky your robot can see, and between buildings that is not a variable you control. Better antennas, better receivers and better correction networks all raise the floor — none of them makes a satellite visible through a wall.
This matters more than the accuracy number suggests. A float solution is not merely less precise; it wanders. For a robot that must return to a docking station, follow a mapped boundary or hand off to a safety controller, an unbounded metre-scale error is a functional failure, not a degraded mode.
What actually fixes it
The only way to hold centimetre-level position in a place with no sky is to stop depending on the sky alone. That means fusing GNSS with sensors whose accuracy does not depend on satellite visibility:
- A camera measures motion against the environment. Between buildings, where GNSS is starved, visual features are abundant — the same walls that block the satellites are excellent landmarks.
- An IMU carries the solution through fast transients and rough ground where visual tracking is briefly unreliable.
- Wheel odometry constrains scale and helps when the scene is featureless.
- GNSS remains the global anchor: it is what keeps the trajectory in real-world coordinates instead of a drifting local frame.
Fixposition's Vision-RTK 2 is built on exactly this architecture. Its xFusion engine combines two multi-band RTK GNSS receivers, visual odometry, an IMU and optional wheel-speed input into a single tightly fused solution, and outputs global position, orientation and velocity with covariances. Fixposition states it delivers centimetre-level positioning under canopy, in tunnels and in urban canyons, with 100% availability in GNSS-denied or restricted areas.
Frequently asked
Will a better antenna fix RTK dropouts between buildings?
It will help at the margins. A high-quality antenna with a good ground plane rejects some reflected energy and improves tracking of low-elevation satellites. It cannot recover a signal that never arrives, so it will not restore fix in a genuine urban canyon.
Would moving the base station closer help?
No. Baseline length affects the correction quality your rover receives; it does not affect whether your rover can see satellites. A base ten metres away does not help a rover that has four satellites in view.
How long does it take to get RTK fix back after leaving a canyon?
Typically a few seconds to tens of seconds, depending on receiver, constellation availability and how badly the tracking loops were disturbed. Your robot must be able to navigate safely for that whole window.
Is dead reckoning with an IMU enough to bridge the gap?
Only briefly. Inertial-only position error grows with the square of elapsed time, so an unaided industrial-grade MEMS IMU is useful for seconds rather than minutes. See our page on whether adding an IMU fixes RTK dropouts.
Positioning that does not depend on a clear sky. Vision-RTK 2 fuses vision, inertial and GNSS measurements to hold accuracy where RTK alone drops out. See how Vision-RTK 2 works or talk to an application engineer about your route.
