I studied surveying and mapping engineering before joining TOKNAV as a product manager. When I discuss a CORS or VRS RTK project with a survey team, I do not begin with a specification sheet. I begin with the field workflow: where the team works, how corrections arrive, what must be checked, and what the office needs at the end of the day.
This is the pre-deployment checklist I use to turn those conversations into a practical RTK receiver configuration.
1. I start with the correction route
First, I ask which CORS or VRS provider will support the project area. The team should confirm mobile-data coverage, login credentials, mountpoint and correction format at the actual site—not only in the office. If the work sometimes leaves network coverage, I also ask when a local base-rover workflow is needed.
For the overall network-correction workflow, I recommend reviewing the TOKNAV VRS and CORS solution before finalizing the field plan.
2. I match the receiver to the job, not just the spec list
My next question is simple: what will the crew deliver? Control, topographic survey, stakeout, mapping and machine guidance each place different demands on the equipment and field software. For teams looking for a compact rover for network RTK work, the NET660 GNSS receiver is a useful product page to compare against the real project requirements.
3. I confirm the coordinate reference before collection begins
A stable correction stream does not automatically mean the final coordinates are right. I ask the project owner to confirm the horizontal datum, projection, geoid model, units and localization parameters. For recurring work, I recommend saving a named profile and recording who approved it, so the field and office teams work from the same reference.
4. I test the complete field connection
Before deployment, I would test SIM data, the receiver-to-controller connection, credentials, mountpoint selection, correction age and fixed-solution stability at the planned operating location. This short test makes it much easier to separate a coverage issue from a settings issue before the crew is under schedule pressure.
5. I make control checks part of the shift
I encourage teams to start and finish on an independently known point whenever the project procedure requires it. If the result is outside tolerance, I would pause collection and check the correction source, antenna height, coordinate profile and receiver setup. A fixed solution is valuable, but it is not a substitute for a project control check.
6. I agree the handover before the first measurement
In product discussions, I also ask about file format, point naming, codes, photos and quality records. These details reduce rework when field data reaches the office or another crew. They also help a buyer evaluate the complete workflow rather than choosing a receiver from a datasheet alone.
When I recommend CORS/VRS
I see CORS or VRS as a strong option when the project has reliable coverage, crews move between sites, and the coordinate framework is clear. If you are still deciding between a local base and network corrections, read VRS vs. RTK base station: which correction method fits your project?.
My field acceptance record
I use a short written record to make the setup reproducible. Before accepting production measurements, I record the receiver and controller models, firmware or application version, service and mountpoint, correction format, antenna-height method, coordinate profile, observation time and independent control-check result.
- Connection succeeds at the actual work site, with the expected correction stream.
- The provider’s position-message requirement is met for the selected network service.
- The solution status and correction age are checked against the project’s procedure.
- A known-point comparison passes the project tolerance, including the intended height reference.
- A test export preserves coordinates, codes, units and required quality fields.
- A restart or reconnection is followed by a repeat check before production work resumes.
For an imaging and stakeout workflow, I also review the T40Pro receiver and its current technical documents. Hardware features do not remove the need to validate corrections and project control.
Frequently asked questions
Does a fixed solution prove that the coordinate profile is correct?
No. I still compare against independent project control and verify the horizontal and vertical references.
What should I check when a VRS connection opens but corrections do not arrive?
I check the service instructions, mountpoint, correction format, communications and whether the provider requires an approximate-position message. I do not change the approved coordinate settings merely to force a fix.
Should we share our service password in a product enquiry?
No. Share the provider name, correction format and field symptoms, not passwords or confidential coordinates.
Let us plan the configuration together
Please share your operating country, correction-service plan, field application and controller preference through our CORS/VRS RTK receiver configuration form. I will use that context to help the TOKNAV team recommend a project-ready receiver and correction workflow.