Evaluating a network RTK correction service for survey work
A network RTK service should be tested for coordinate compatibility, coverage, continuity and independent field performance before routine use.
Evaluate the service as part of the survey system
A network RTK service supplies correction information derived from a reference station infrastructure and processing workflow. The rover still depends on suitable satellite observations, compatible messages, communication and correct project configuration. Begin by identifying the intended application and acceptance requirements. A successful login or a rapid fixed solution is an operational milestone, but it does not independently establish that the delivered coordinates match the project's framework or quality objective.
Review the service's current official documentation and support information. Commercial terms, coverage and technical offerings can change, so verify them directly when making a decision. Record the service and mountpoint used during the trial. Avoid treating all streams from the same provider as interchangeable, because they can differ in correction method, supported observations or reference definition.
Continue learning CORS and network RTK: understanding the reference service
Confirm the coordinate framework
Ask which reference frame, realization and epoch underpin the service coordinates. Determine how heights are handled and whether any geoid or local transformation is applied by the rover rather than the service. Compare those definitions with project control before collection. A rover can produce stable repeatable coordinates that remain systematically displaced if the service framework and project framework are not reconciled.
Retain the authoritative framework statement with the trial record. If the service publishes station coordinates or metadata, identify the relevant versions. Where the project uses a local grid, document the approved transformation and keep its verification separate from the service's internal performance. A local fit can align results without independently proving the correctness of every upstream reference assumption.
Continue learning Evaluating multi-frequency GNSS receivers for real projects
Check technical compatibility
Verify receiver support for the selected correction messages, signals and service method. Confirm the required rover information, authentication and communication settings according to the provider's documentation. A stream can connect successfully while some observations or corrections are unsupported. Review diagnostics and processing behavior rather than relying only on a connected indicator or the fact that data bytes are arriving.
Keep the tested firmware and configuration associated with the result. If several rover models are used, test representative units rather than assuming identical behavior. Include export and office processing in the trial, especially where raw observations or quality fields are required. A service that works in the field but produces an ambiguous handover can still create substantial project risk and manual office effort.
Continue learning Mapping water network assets with GNSS and reliable field records
Test coverage under representative conditions
Choose trial locations that reflect the actual work area, including suitable known control and relevant communication environments. Distinguish satellite observation difficulty from cellular or internet coverage. A failure beside buildings may involve local GNSS conditions, while a remote open site may fail because corrections cannot be received. Record the evidence for each dependency so the provider and project team can interpret the trial meaningfully.
Do not extrapolate a successful test at one location to an entire region. Service coverage boundaries, reference geometry and communications can vary. Review the provider's stated area of use and test important project extremes where practical. If work moves outside the verified area or changes substantially in elevation or environment, reassess suitability rather than treating the original demonstration as a permanent approval for every later task.
Continue learning Planning GNSS control networks for mining operations
Use independent control checks
Collect checks on suitable marks with understood provenance and uncertainty. Compare horizontal and vertical components in a compatible framework. Plan repeated occupations with meaningful independence according to the project method. A second store from the same unchanged setup provides less evidence than a deliberately remade occupation, and both can still share a common service reference error.
Keep transformation points separate from independent checks where external verification is the objective. If every available point is used to fit a localization, the final residuals describe the fit rather than an independent test of the complete workflow. Preserve original service coordinates, local transformed values and check differences so a reviewer can distinguish service behavior from the effect of the project's own alignment process.
Continue learning CORS and network RTK: understanding the reference service
Evaluate continuity and recovery
During the trial, record correction age, connection interruptions, solution transitions and recovery behavior using the supported diagnostics. Test normal authorized operational scenarios, such as moving between representative work areas or restarting a planned session. Do not create interference or disrupt shared infrastructure. The aim is to understand how the crew recognizes and handles ordinary service or communication interruptions.
Document what happens to stored points during degraded conditions. Does the workflow block collection, warn the operator or permit provisional values? The project procedure should make the accepted response clear. A service can be reliable overall while still requiring a contingency for outages, and an apparently brief interruption can matter if important points are collected before the rover's suitability has been reverified.
Continue learning Evaluating multi-frequency GNSS receivers for real projects
Review support and operational transparency
Assess how the provider communicates planned maintenance, station changes and incidents. Determine whether relevant metadata and status information are available to users. A clear support process helps the organization distinguish a local equipment problem from a service issue. Record a reproducible support case during the evaluation if one arises, including the information needed to investigate without disclosing credentials unnecessarily.
Consider account management and access control for multiple crews. Shared undocumented credentials can complicate support and continuity. Use the provider's supported arrangements and protect secrets outside public project files. The service evaluation should include practical operation over time, not only the quality of one favorable coordinate, because sustainable survey work depends on both technical performance and manageable day to day administration.
Continue learning Mapping water network assets with GNSS and reliable field records
Build a contingency plan
Identify what work can continue when corrections are unavailable or independent checks fail. Options can include another approved correction source, a local base, postprocessing or a different survey technique. Each alternative needs its own configuration and verification. Switching streams without checking reference compatibility can introduce a coordinate shift that is harder to detect than the original outage.
Keep accepted configuration templates and a concise crew checklist. Record the time and points associated with any service change. If raw data is part of the contingency, verify that it is being recorded and that matching reference information can be obtained. Do not assume that the office can recover every interrupted real time session after the field team has demobilized.
Continue learning Planning GNSS control networks for mining operations
Approve a documented operating method
The evaluation report should identify the service, mountpoint, coordinate framework, tested equipment, locations, independent checks, continuity observations and limitations. State the approved procedure and circumstances requiring reassessment. Keep current provider documentation with the record where permitted, and distinguish measured trial results from general service claims or commercial commitments.
A good network RTK evaluation produces more than a provider preference. It establishes a repeatable workflow whose reference system, compatibility, field evidence and outage response are understood. That allows crews to use the service efficiently while retaining the independent checks needed to demonstrate that the final project coordinates are suitable for their intended purpose.
Continue learning CORS and network RTK: understanding the reference service
Practical checklist
- Evaluate the service as part of the survey system.
- Build a contingency plan.
- Approve a documented operating method.
Plan your GNSS setup
Compare the EQ10 and EQ20 receiver specifications, then discuss the configuration and support your project needs.
Compare GNSS receivers
