How to Check Control Points with RTK: Field Guide
Set up your rover in Fixed solution. Navigate to a known control point (a benchmark or previously coordinated survey monument — not the same point used to set up the base). Record the RTK coordinate. Compare it against the published value. Accept if the horizontal difference is within ±20mm for standard survey work. Check at least two independent control points before recording any production data. If either check fails, investigate before proceeding — never accept a single passing check or begin production on a failed check. This two-minute procedure prevents datum mismatches, base coordinate errors, and geoid model errors from corrupting an entire day's work.
The control point check is the most important two minutes in any RTK survey session. Every error that corrupts an entire day's dataset — wrong base coordinates, datum mismatch, geoid model error, wrong CORS mountpoint — produces the same field symptom: RTK Fixed, but coordinates wrong by a consistent offset. The check catches all of these in two minutes before they affect production data. Most surveyors know they should check. Fewer do it consistently. This guide covers the exact procedure, what tolerance to accept, how to interpret results, and what to do when a check fails.
1. Why the Control Point Check Matters
The RTK Fixed status confirms only that the receiver has resolved carrier-phase integer ambiguities. It does NOT confirm that the coordinate system, datum, geoid model, or base station coordinates are correct. A receiver can be in perfect Fixed status and still deliver every point 50 metres from the correct position — if the datum is wrong.
When a field receiver achieves a fixed status, the internal RTK engine has successfully resolved the carrier-phase ambiguities between the base transmitter and the mobile rover. This mathematical certainty indicates that the relative vector between the two antennas is precise to the millimetre level. However, this vector remains floating in absolute space until it is referenced to a specific coordinate framework. If the reference coordinates assigned to the base station are incorrect, or if there is a fundamental RTK status datum mismatch inside the field software configuration, that millimetre-level relative precision will be anchored to an incorrect absolute position.
The critical systemic errors caught during a control point check include:
- Base station coordinate entry errors: Manual transcription slips, swapping northings and eastings, or selecting the incorrect reference monument identity when initializing a local base.
- Project datum configuration mismatches: Selecting a global reference framework like WGS84 or ITRF within ApekSurv when the project mapping parameters mandate a localized national datum such as Minna, TUREF, or SAD69.
- Geoid model selection errors: Failing to apply or applying the incorrect local geoid separation file, which leads to large errors in orthometric heights while horizontal values appear stable.
- CORS mountpoint mismatches: Linking the rover to a network reference station operating in an adjacent geographic zone or on a different coordinate epoch, introducing a localized grid shift.
- Antenna height measurement errors: Incorrectly entering the physical height of the base station instrument or measuring to the wrong reference point on the receiver chassis, which directly biases vertical data.
Because every single one of these configuration errors results in internally consistent data points that are uniformly shifted away from real-world coordinates, standard data checking cannot reveal the issue after the survey is complete. Executing a physical check survey setup sequence against established monuments remains the only defensive measure available to field operators before production logging begins.
2. What You Need Before You Check
Before performing the check you need an RTK rover in a Fixed solution with a differential age under 2 seconds for CORS or under 4 seconds for a base+rover configuration. You must have at least two independent control points with published coordinates loaded into ApekSurv as design points, and your base station must be fully operational if running a local network.
To ensure the validation process provides clear, uncompromised information, the field equipment and spatial reference data must meet specific readiness criteria. The mobile rover receiver—whether an AP40 Laser+, AP20 AR, or AP80 Pro—must maintain a stable Fixed solution. The age of differential corrections must remain low; correction latencies exceeding 2 seconds on CORS links or 4 seconds on local UHF radio streams indicate communication issues that introduce tracking noise and skew accuracy checks.
Surveyors must also verify that at least two physical control points are accessible within the active boundary of the project site. These points must consist of authenticated national geodetic benchmarks, formal municipal survey monuments, or primary control stations established during previous static GNSS campaigns and processed through rigorous least-squares adjustments. Prior to leaving the office, the official published coordinate values for these reference points must be correctly input into the ApekSurv project database as design check targets. This prevents manual transcription errors in the field.
It is critical that the control points chosen for this daily RTK control point check remain completely independent of the physical monument used to support the local base station transmitter. Placing the rover over the base monument itself only checks whether the user re-entered the exact coordinate numbers that were used to initialize the base. It cannot uncover datum translation errors, geoid model scaling problems, or global reference frame shifts. True validation requires checking entirely separate, independent physical monuments located further out in the project grid.
3. The Check Procedure — Step by Step
This standard operational sequence must be performed at the start of every single shift. It isolates potential setup errors before any production tracking can occur.
Power on the receiver and open your field controller. Check the main telemetry bar in ApekSurv to confirm that the positioning engine has achieved an absolute Fixed status. Verify the correction age reading. If using a network CORS profile, the latency must consistently stay below 2 seconds. If using a local base station with internal LoRa modems, the latency must stay below 4 seconds. If the system remains stuck in Float or exhibits fluctuating age spikes, stop and use our guide to troubleshoot the tracking architecture before proceeding.
Set up the ApekSurv map interface into point stakeout mode and select the imported design coordinates for your first control point. Walk to the physical monument position. Place the sharp tip of the carbon-fibre rover pole precisely into the center punch mark or etched cross lines on the monument cap. Adjust the bipod legs or hold the pole steady to center the circular leveling bubble perfectly. Keep the pole completely plumb and stable throughout this process.
Once the leveling bubble is centered and the system indicates a stable Fixed solution, initialize the point storage command. Do not use an instantaneous single-epoch shot for this check. Configure the storage routine in ApekSurv to perform a multi-epoch average over a window of 3 to 5 seconds. This averaging process smooths out high-frequency atmospheric noise, multipath variations, and slight hand movements, providing a reliable position value.
As soon as the averaged position is stored, review the automatic coordinate comparison display inside ApekSurv. The software compares the measured RTK coordinate against the imported design point parameters. Note down the precise horizontal separation (dH) and vertical delta (dV) values. Do not rely on visual estimation on the map view; check the exact numerical values on the delta status page.
Pick up the rover assembly and move to the second independent control point monument located elsewhere on the site. Repeat steps 2 through 4 precisely. To verify RTK accuracy field conditions reliably, you must secure passing values on two distinct points. Passing a check on only one monument does not rule out localized monument movement or rotational datum shifts across your project area.
4. Interpreting the Results
Evaluating the coordinate differences recorded during the check requires sticking to strict engineering tolerances. You cannot adjust these values based on project timelines or convenience in the field.
| Horizontal Difference | Vertical Difference | Decision Status | Mandatory Field Action |
|---|---|---|---|
| ≤20mm | ≤30mm | Pass | Clear the receiver for production work; begin logging points. |
| 20–50mm | 30–60mm | Marginal | Halt work; isolate the error source before starting production. |
| >50mm | >60mm | Fail | Absolute system rejection; do not log any production points. |
If the coordinate comparison shows that both the horizontal and vertical differences remain within the passing limits across both control points, your RTK datum verification is successful. This confirms that the base station coordinates, project datum, transformation parameters, and geoid model are all configured correctly. You can proceed with confidence and begin your production survey work.
A marginal status indicates that while your system has achieved a valid RTK lock, the position is hovering right on the edge of acceptable accuracy tolerances. This situation typically points to a localized issue, such as a reference monument that has been slightly nudged by machinery, heavy multipath interference from nearby trees, or a worn center-mark on an old benchmark. You must investigate immediately. Try re-leveling the pole, clearing any obstruction, or moving to an adjacent third control point to isolate whether the issue lies with that specific monument or your overall RTK configuration.
Any result that falls into the failure tier means you must stop all field operations immediately. Do not record any production data points under a failed status. Logging points when a control check fails will result in a corrupted dataset that must be entirely resurveyed. You must keep the system paused until you identify and fix the underlying configuration issue, following the troubleshooting steps outlined in Section 5.
5. What to Do When the Check Fails
When coordinate differences exceed acceptable limits, the pattern of the errors usually points directly to the underlying technical cause. Use these diagnostic blocks to identify and fix configuration errors.
Symptom: Every control point checked across the project site exhibits an identical horizontal shift in the exact same direction. For example, every measured position reads exactly 2.34 metres north and 0.81 metres east of the official published coordinate records, showing a systematic grid shift rather than random variation.
Cause: This uniform shift is a clear sign of a systematic error, typically caused by a project datum configuration mismatch inside ApekSurv or an error in the reference coordinates entered for the local base station. If the system is connected to a CORS network, this uniform shift can occur if the chosen NTRIP mountpoint references an older or mismatched geodetic epoch.
Fix: Open your project properties menu within ApekSurv and verify that the selected coordinate system, ellipsoid, projection type, and datum transformation parameters match the official specifications of your control point datasheets. If you are operating a local base station, check the coordinate configuration page to ensure no numbers were transposed during setup. For CORS configurations, check with your network provider to ensure your mountpoint matches your local coordinate framework.
Symptom: The horizontal check results are excellent, falling well within the ±20mm limit. However, the vertical check fails completely, with measured heights showing a consistent deviation of 0.35 to 1.50 metres above or below the published reference benchmark values.
Cause: This issue is typically caused by applying the incorrect geoid model file (.ggf or .bin format) within the project settings, or entering an incorrect antenna height value for the base station receiver. Because GNSS hardware natively measures ellipsoidal height, any error in the geoid model calculation will directly distort the resulting orthometric elevations while leaving horizontal data unaffected.
Fix: Access the coordinate system settings menu in ApekSurv and verify that the correct local geoid model file is active for your project location. If you are running a local base station setup, walk back to the unit and physically re-verify the antenna height measurement. Double-check whether the height was measured to the bottom of the mount, the slant height tape hook, or the center phase mark, and make sure the correct measurement type is selected in the software interface.
Symptom: The coordinate differences vary randomly from point to point across the site. For instance, the first control point shows a 45mm shift to the northwest, the second shows a 30mm shift to the south, and a third point shows a 60mm shift to the east, with no predictable pattern.
Cause: This random variation indicates that the issue is likely caused by localized physical instability or signal interference rather than an overall software configuration error. This pattern usually points to physical damage or movement of the reference monuments themselves, severe local multipath interference from overhanging trees or metal structures, or poor satellite geometry during measurement.
Fix: Check the physical integrity of each monument to ensure it has not been disturbed, tilted, or undermined by nearby construction activity. Check the quality metrics on your field controller, paying close attention to the number of tracked satellites and the PDOP value. If you suspect local multipath interference from nearby trees or structures, extend your averaging time to 30 epochs, or locate an undisturbed control point further away to isolate the issue.
6. Common Mistakes in Control Point Checks
To keep your daily quality control process reliable, field crews must avoid common shortcut mistakes that can hide configuration errors and compromise your data integrity.
The most common procedural mistake is checking accuracy by placing the rover directly over the base station monument. This only confirms that you entered the base coordinates correctly into the software. It cannot reveal systematic datum shifts, projection errors, or geoid issues, because any configuration error will affect both the base entry and the rover calculation equally. You must always use a completely separate, independent reference monument for your check.
Another frequent issue is relying on a single control point check. A single check can pass by pure coincidence if a physical shift in that specific monument happens to cancel out a systematic error in your coordinate system setup. Checking at least two separate, independent control points across the site is the only way to confirm both the position and the orientation of your survey grid are correct.
Additionally, field crews must avoid these common errors:
- Logging checks while in an RTK Float state: Any accuracy check performed while the receiver is in a Float status is invalid, as the coordinate floating errors will mask the real systematic configuration errors you are trying to find.
- Accepting marginal errors under schedule pressure: Accepting a horizontal error of 45mm on a high-precision project just to keep up with a tight timeline compromises your data quality. You must stop and resolve the error immediately.
- Re-checking the exact same point twice: Measuring the same physical monument twice does not provide any new validation info. It simply repeats the initial measurement and fails to check for grid rotation or localized monument movement.
7. FAQ
Do I need to check control points when using CORS?
Yes. While using a CORS network removes the risk of manual coordinate entry errors at a local base station, it does not prevent datum selection errors, geoid model mismatches, or selecting the wrong network mountpoint inside ApekSurv. Performing a physical check against known control points confirms your entire positioning chain is configured correctly—including your network connection, coordinate transformation parameters, and local geoid adjustments—before you begin collecting data.
How many control points should I check?
You must check a minimum of two completely independent control points. Checking only one point is not enough to catch errors, as a localized shift in that monument could potentially mask an overall systematic grid error. Verifying your position against two widely spaced control points across your project area confirms both the absolute position and the rotation of your survey grid. For high-stakes legal cadastral or engineering projects, checking three or more points is highly recommended.
What tolerance should I use for control point checks?
For standard topographic, environmental, and general construction surveys, you should maintain a maximum tolerance of ±20mm horizontally and ±30mm vertically. On high-precision cadastral or structural engineering projects, you must tighten these limits to match the specific accuracy standards mandated by local regulations or project specifications. For general GIS asset mapping where sub-metre accuracy is acceptable, you can expand your tolerance window up to ±50mm.
Should I check control points again mid-session?
Yes. For any survey sessions extending beyond 4 hours, it is best practice to re-check at least one known control point in the middle of your shift or right before wrapping up for the day. This second check confirms your positioning solution has not drifted over time, which can happen if a local base station is accidentally bumped by machinery, or if a CORS network shifts to a different reference station during your session.
TWO MINUTES. ZERO CORRUPTED DATASETS.
The control point check takes two minutes and prevents an entire day's data from being unusable. APEKS receivers with ApekSurv display horizontal and vertical difference against design points automatically — no mental arithmetic required.
Send an Inquiry → WhatsApp Us →References
- ISO 17123-8:2015 — Field Procedures for GNSS RTK
- APEKS AP40 Laser+ Technical Datasheet, 2026
- ApekSurv Field Software User Guide, 2026
- Unicore Communications UM980 Product Brief