> For the complete documentation index, see [llms.txt](https://docs.premium-positioning.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.premium-positioning.com/troubleshooting/inconsistent-rtk-accuracy-on-site.md). # Inconsistent RTK accuracy on site ## Fix inconsistent RTK accuracy on site If your receiver reports a fixed solution but the coordinates are inconsistent or wrong, the cause is almost always one of a few things: a false fix, multipath, the antenna height or pole setup, or a coordinate-system mismatch. This guide works through them in the order worth checking, and ends with a quick test that catches most of them. The key point to start from: a fixed status is not a guarantee of a correct position. It tells you the receiver believes it has resolved the ambiguities, not that it resolved them correctly. The most useful thing you can do on site is verify, not trust. ### First, confirm it is repeatable Before chasing causes, re-measure the same point twice with a gap between, and re-measure a known point if one is to hand. * Re-occupy the point 20 to 30 minutes apart. In that time the satellite geometry and the atmosphere change, so two occupations that agree are far more trustworthy than one. Two that disagree tell you the problem is real and point to a false fix or multipath. * Re-measure a known point. If you have a marker with published coordinates nearby, measuring it is the fastest absolute check you have. If the repeats agree and the known point checks out, your accuracy is sound and any earlier reading was a one-off. If they do not, work through the causes below. ### False fix A false fix is when the receiver resolves the integer ambiguities wrongly and still reports fixed. The position can be off by anything from a few centimetres to a clean jump of a whole wavelength, and it will look confident the whole time. * Force a re-initialisation. Lose and regain satellite lock deliberately, let the receiver fix again, and re-measure. A position that shifts after re-initialising was a false fix. * Improve the conditions before re-fixing. Move to open sky and wait for a moment of better geometry. False fixes are far more likely on marginal signal, poor geometry, or a rushed, short occupation. ### Multipath Multipath is the signal arriving by more than one path, reflected off buildings, vehicles, water, fences, or the ground. It biases the position while the receiver still reports fixed, and it is the usual reason two occupations of the same point disagree. * Look at what is around the antenna. Anything flat and reflective within a few metres is a suspect. * Move the setup if you can, even a short distance away from the reflective surface. * Lean on time. Multipath averages out over roughly 20 minutes, so a longer occupation or a repeat at a different time reduces it. This is the other reason the 20 to 30 minute repeat matters. ### Antenna height and pole setup A correct position at the antenna is still wrong on the ground if the height or the setup is off. This is the most common cause of a steady, repeatable error rather than a wandering one. * Measure the antenna height three times, independently, and to the correct reference point for your antenna. A single mistyped or mismeasured height puts a constant offset on every point. * Check the pole is vertical. A pole off vertical throws the point sideways by roughly its length times the tilt. A 2 metre pole tilted just 2 degrees moves the point about 7 centimetres. Re-check the bubble during the occupation, not only at the start. * Confirm you are measuring the point you think you are, with the pole tip on the mark. ### Coordinate system or datum mismatch If the error is a consistent shift across the whole job, the receiver and your software may not be working in the same reference. * Confirm the receiver and the software use the same coordinate system, projection, and realisation. * Check the height model. A wrong or missing geoid model shows up as a vertical offset while planimetry looks fine. * Our corrections are delivered in ETRS89. Make sure your project is set up to match, or transformed correctly if you are working in a national or local system. ### Network and signal causes * The GGA heartbeat has stopped. On a network mountpoint, if position sending drops, the network keeps correcting for your last reported location and accuracy drifts the further you go. See [Mountpoint selection and the GGA heartbeat](/guides/mountpoint-selection-and-the-gga-heartbeat.md). * You are far from the network or at the edge of coverage. The longer the effective baseline, the more residual atmospheric error survives, and the harder a clean fix is to hold. * The correction age is climbing. Old corrections degrade the solution. A few seconds is normal; a rising age points to a struggling data link. * The satellite geometry is poor. If the receiver reports a high DOP, wait a few minutes for the constellation to change before trusting a reading. ### The on-site test that catches most of this When a point matters, do all three: 1. Measure it, re-initialise, and measure it again. This catches a false fix. 2. Re-occupy it 20 to 30 minutes later. This catches multipath and geometry. 3. Check a known point. This catches height and datum errors. Three readings that agree, taken under changed conditions, is as much confidence as you can get without post-processing. ### FAQ My receiver says fixed but the position is wrong. How is that possible? A fixed status means the receiver thinks it resolved the ambiguities, not that it did so correctly. A false fix looks identical to a good one until you re-measure. Why do two measurements of the same point disagree? Most often multipath, a false fix, or a pole that was not vertical. Re-occupying 20 to 30 minutes apart will usually show which. My heights are off but the plan position is fine. Where do I look? The antenna height entry first, then the geoid model in your software. Everything is shifted by the same amount across the site. What causes that? A coordinate-system or datum mismatch between the receiver and the software, or a wrong antenna height applied to every point. Still inconsistent after all this? See the general [RTK corrections troubleshooting](/troubleshooting/rtk-corrections-troubleshooting.md) guide, or contact support with your receiver model, the mountpoint, the solution status, and the correction age. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.premium-positioning.com/troubleshooting/inconsistent-rtk-accuracy-on-site.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.