Category: Blog

Measuring water depth in a reservoir, collecting water samples from a lake, or inspecting a river channel all require equipment that can reach the right location and collect useful information. An unmanned surface vehicle, or USV, provides a way to carry out these tasks without an operator onboard.

But choosing a USV involves more than selecting a boat. The platform, sensors, positioning system, communication links, and operating software all need to fit your work.

This guide explains what a USV is, how it works, and what to consider when choosing a system—including the TOKNAV TBoat series—for your project.

What Is a USV?

A USV, short for Unmanned Surface Vehicle, is a vessel that operates on the water’s surface without a crew onboard. You may also see the terms “uncrewed surface vessel,” “survey drone boat,” or simply “unmanned boat.”

Depending on its design and configuration, a USV can be controlled remotely or follow planned routes while an operator supervises its activity. “Unmanned” describes the absence of people onboard; it does not automatically mean the vessel operates without human oversight. NOAA’s guide to uncrewed survey systems explains these operating approaches.

Unlike an underwater vehicle, the USV itself stays on the surface. Sensors carried by the vessel can measure conditions below or around it.

For professional users, common applications include:

• Bathymetric surveying: measuring water depth and collecting data used to map underwater terrain.
• Water-quality monitoring: measuring selected water parameters using suitable sensors.
• Water sampling: collecting physical samples for subsequent analysis.
• Inspection: gathering visual or sonar information to support assessments of a waterway or site.

The equipment fitted to the vessel determines which tasks it can perform.

How Does a USV Work?

A working USV combines several systems, each with a different role.

The vessel and propulsion system carry the equipment and move it through the water. Hull design, propulsion, battery capacity, and payload all influence its operating capabilities.

The positioning and navigation system helps determine where the vessel is and guides its movement. Survey configurations may use GNSS with RTK corrections when the project requires precise positioning.

The task equipment collects the information you need. This might be an echo sounder for depth measurement, a water-quality sensor, a sampling device, or a side-scan sonar.

The communication and control system connects the operator with the vessel, allowing supervision and control within the system’s supported operating conditions.

For a bathymetric survey, for example, an echo sounder measures depth while the positioning system records location. Those observations are then processed, checked, and referenced appropriately to produce useful survey results.

This explains a key purchasing principle: the boat gets the equipment to the measurement location, but the complete system determines the usefulness of the data.

Start with the Job You Need to Do

Before comparing specifications, define your main task and the result you need to deliver.

Water-depth and underwater-terrain surveys

If you need to map a reservoir, assess sediment accumulation, or support dredging work, begin with the required survey coverage and deliverables.

Consider whether you need individual depth profiles, a terrain model, or data suitable for volume calculations. These requirements help determine the sonar, positioning, survey planning, and processing workflow.

Water-quality monitoring

If your project involves environmental monitoring, list the parameters you need to measure and where measurements must be taken.

Temperature, pH, dissolved oxygen, conductivity, and turbidity are examples of parameters that suitable sensors can measure. Confirm the selected sensor package, calibration requirements, and measurement depth for your project.

Water sampling

Monitoring and sampling serve different purposes. A sensor measures a parameter in the field, while a sampling system collects water for further testing.

For sampling work, specify the number of collection points, sample volume, collection depth, and procedures needed to preserve sample integrity.

Inspection and underwater observation

Start by identifying what you need to inspect. A camera can document visible surface conditions, while side-scan sonar can provide imagery of underwater features.

Sonar imagery and bathymetric measurements answer different questions, so choose equipment according to the information your project requires.

Match the USV to Your Water Environment

Two projects with the same measurement objective may need different equipment because their operating conditions differ.

Water depth and access: Consider the shallowest sections, underwater obstacles, shoreline conditions, and available launch points. A sensor’s measurement range does not establish the vessel’s minimum safe operating depth.

Current, wind, and waves: Assess whether the vessel can maintain a useful survey speed and follow its intended route under expected conditions. Maximum speed alone does not describe its ability to complete a survey.

Vegetation and debris: Floating rubbish, aquatic plants, and submerged objects may affect propulsion, sensor performance, and route planning.

Transport and recovery: Think about how your team will carry the equipment, launch it, retrieve it, and access the site with batteries and accessories.

Communication coverage: Check the available control and data links against the site’s operating distance, terrain, obstructions, and network coverage.

These practical details often matter as much as the headline specifications.

Choose the Right Sensors and Payloads

A USV should be evaluated as a configured working system.

For a survey project, confirm the sonar type, positioning arrangement, correction source, mounting requirements, and data-processing workflow. For environmental work, confirm the sensor package or sampling system and its operating procedures.

If you intend to perform several tasks, ask whether the required equipment can operate together or needs to be exchanged between missions. Additional equipment can affect power consumption, vessel balance, deployment, and endurance.

Also distinguish between individual equipment specifications and overall results. GNSS positioning accuracy, depth-sensor accuracy, and final survey accuracy are different measurements. Calibration, sound velocity, vessel motion, water-level referencing, and processing can all influence the final output.

The right configuration is the one that supports your required deliverable under your actual working conditions.

Look Beyond the Specification Sheet

Before purchasing, review how the system will fit into your team’s daily work.

What to evaluate	Why it matters
Mission endurance	Battery performance should support your planned workload with the selected payload and a suitable return margin.
Operator training	Your team needs to understand preparation, control, supervision, recovery, and routine checks.
Data export and processing	Collected information must fit your existing software and reporting requirements.
Maintenance and spare parts	Batteries, propulsion components, and sensors need an achievable maintenance plan.
Technical support	Clear support arrangements help your team resolve setup and operating questions.
Included equipment	A quotation should identify the vessel, sensors, batteries, accessories, software, and services supplied.

For cost comparisons, consider the complete package and its ongoing requirements. A lower initial vessel price may not represent the lower cost of a ready-to-use system.

Explore the TOKNAV TBoat Series

The TOKNAV TBoat series provides USV options for water-survey and environmental tasks. The range includes TBoat10 and TBoat20, with application configurations listed for bathymetric surveying, water-quality monitoring, water sampling, and side-scan sonar patrol work. Explore the TOKNAV TBoat series.

The published hull dimensions provide one practical starting point when reviewing transport and deployment:

Platform	Published hull dimensions
TOKNAV TBoat10	980 × 520 × 254 mm
TOKNAV TBoat20	1280 × 580 × 430 mm

Platform size is only part of the selection. Your intended payload, operating environment, measurement requirements, and team workflow should guide the final configuration.

For example, a team measuring reservoir depths should begin with the bathymetric survey configuration and its positioning and data requirements. A team collecting water samples should instead begin with the sampling arrangement and collection procedure.

When discussing TBoat options with TOKNAV, explain the work you need to complete. This gives the team a useful basis for recommending a platform and confirming the equipment required for your application.

What Information Should You Send for a Quote?

A clear project brief makes product selection and quotation more efficient. Include:

• Location: your country or region and the type of water body.
• Main task: bathymetric survey, water-quality monitoring, sampling, inspection, or a combination.
• Site conditions: expected depth, current, waves, vegetation, and launch access.
• Operating requirements: survey area, distance from the operator, and typical mission duration.
• Required results: measurements, maps, sample quantities, or reports you need to deliver.
• Existing equipment: sensors, GNSS equipment, or processing software you already use.
• Purchase plan: expected quantity, budget range if available, and project timing.

You do not need to know every technical specification before contacting a supplier. Describing your project clearly is a useful first step toward selecting the right system.

Find the Right USV for Your Project

A suitable USV connects three things: the task you need to complete, the conditions you work in, and the information your customer or project requires.

Start with those requirements, then choose the platform, sensors, and workflow that support them.

Planning a water-survey or monitoring project? Explore TOKNAV USV platforms and share your application, site conditions, and required results with TOKNAV to discuss a suitable TBoat configuration and request a quotation.

When I discuss a hydrographic USV project, I do not start with a model name. I start with the water body, sensor package, launch point and final deliverable. I studied surveying engineering before becoming a product manager at TOKNAV, and this is the same practical sequence I use to help teams compare TBoat10 and TBoat20.

Both platforms are intended for hydrographic and water-project workflows. The useful choice is not simply “smaller versus larger”: it is the vessel that can carry the planned payload, operate safely from the available launch point and support the actual survey plan.

Compare the published platform records first

Planning point	TBoat10	TBoat20
Listed payload capacity	35 kg	50 kg
Stated endurance	7 h at 1.5 m/s	7 h at 1.5 m/s
Listed maximum speed	7 m/s	6 m/s
Listed protection	IP67	IP67

These are published product-record figures, not mission guarantees. Payload, sensor mounting, battery condition, route, water conditions, communications coverage and local operating rules all affect the field plan.

Choose TBoat10 when the mission fits its payload plan

The TBoat10 product record lists a 35 kg payload capacity. In my comparison, I would check the complete sensor package—not only the sensor’s headline weight. Include mounting hardware, cabling, power draw, balance, working distance and the time needed to collect the required coverage.

For this platform, the published record also lists a 2.4 GHz control range of up to 3 km and 4G communications. Those values need site validation; line of sight, local regulations, interference and weather can change the workable operating plan.

Choose TBoat20 when the sensor package needs more payload headroom

The TBoat20 product record lists a 50 kg payload capacity. That can be the better starting point when the proposed sensor and integration package needs additional headroom, but I still recommend reviewing launch and recovery conditions, vessel handling, mount geometry and the expected route before making a selection.

Its stated endurance is also 7 hours at 1.5 m/s. Use that figure as a planning input, then validate the actual mission duration against the selected payload and water conditions rather than treating it as a fixed project outcome.

Make the vessel decision part of the hydrographic workflow

A hydrographic vessel is only one part of the survey system. The route plan, GNSS correction method, echo-sounder setup, water-level or draft process and data checks need to agree before mobilization. Our TBoat hydrographic survey planning guide walks through that full workflow, while the river-survey echo sounder guide helps teams frame the depth and positioning questions.

Questions I ask before recommending either platform

• What sensor payload, mounting geometry and power requirement will the vessel carry?
• What water conditions, launch access and recovery constraints apply at the actual site?
• What survey-line coverage, depth workflow and deliverable does the client require?
• How will GNSS corrections, control, communications and field quality checks be handled?

Frequently asked questions

Does payload capacity alone determine the right TBoat model?

No. Payload is a useful first screen, but the final decision should also cover the real sensor package, mounting, power, water conditions, launch and recovery, route plan and operating procedure.

Can I use the stated endurance as the mission duration?

No. The stated endurance is a product-record condition. Confirm the field mission against the selected payload, water conditions, route, battery condition and operating procedure.

What should I include in a TBoat enquiry?

Please include the survey method, sensor package, water conditions, working distance, launch point, required mission duration, destination country and intended deliverable.

Discuss a TBoat hydrographic survey configuration →

Confirm the complete USV payload before ordering

Ask for a configuration list identifying the vessel, sonar model, GNSS and motion sensors, mounts, power distribution, data interfaces and acquisition software. Confirm which components are included, optional or supplied by the integrator.

Review loaded draft and balance, sensor offsets and timing, correction coverage, communications and recovery behavior. Request a representative test dataset and calibration records for the proposed combination. Published payload capacity alone does not establish sonar compatibility.

Use the USV configuration checklist, shallow-water planning guide and data-quality acceptance table.

GNSS data collection is more than recording field coordinates. The reliability and reusability of a dataset depend on a controlled relationship among the required deliverable, positioning method, field application, coordinate reference, connectivity, operator procedure and quality review. The receiver or rugged device is one component of this operational system.

Define the map, register or decision that the project must deliver. Then select the workflow that produces the required data consistently, rather than evaluating device specifications in isolation.

Define the required deliverable before selecting equipment

“Field mapping” can mean a tree inventory, utility asset register, construction as-built, environmental observation, parcel review, drainage survey or a control-related task. These jobs may all use GNSS, but their data structure, accuracy requirement, field interface and quality checks are different. A sound procurement conversation starts with the output: points, lines, polygons, attributes, photos, documents, inspection forms or a combination.

Write down the accuracy or tolerance required by the project owner, the coordinate reference and vertical context, the field application, expected file or synchronization path, operator count and working conditions. Those details reveal whether the team needs a rugged handheld, a controller plus external receiver, a local base, network corrections or a simpler data-capture method. They also keep the supplier evaluation focused on the operational requirement.

Select the positioning method within the data design

The appropriate positioning method follows the deliverable. Some inspection and asset workflows can use a lower-accuracy location when the record is meant to identify an area or a feature for later review. Survey-grade mapping, construction, utility and control-related work may require a defined RTK or other correction workflow. Do not use a generic phrase such as “high accuracy” in place of a documented project tolerance and check process.

When RTK is needed, define the correction path early: local base and radio, network RTK, CORS/VRS service or another approved arrangement. Consider coverage, terrain, mobile-data reliability, number of users, project control and how a crew will record an interruption. The VRS vs. RTK Base Station guide is a useful starting point for that choice. A connection status alone is not a quality plan; the project still needs an accepted validation procedure.

Confirm application and device compatibility before procurement

In many GIS projects, the field app is already selected. That makes compatibility a pre-purchase requirement, not an issue to discover after delivery. List the application, operating system, version, required data formats, positioning-input method, offline behavior, photo/form requirements and synchronization path. Then verify the exact intended combination with both the application owner and equipment supplier.

A rugged GIS handheld may be used on its own, or it may work with an external GNSS receiver. A controller-plus-receiver workflow may suit another team. Neither pattern is automatically better. The chosen path must support the field app, correction method, power plan, mounting, connection method and operator routine. Explore the TOKNAV Rugged & GIS range and GNSS receiver range as category starting points.

Establish a repeatable field procedure

1. Prepare and release the job package

Before leaving, load approved maps, forms, feature codes, instructions and coordinate settings. Confirm the team knows which features require a check, which attributes are mandatory and what to do when a site condition does not match the plan. If control is part of the project, make the control-check procedure visible in the job instructions.

2. Establish and record the positioning method

Connect the device or receiver to the planned positioning source. Record the status indicators and any correction source that the project requires. If a crew changes correction source, profile or coordinate context, treat that as a project event to document—not a silent setting change. The separate NTRIP setup guide covers the internet-correction delivery path in more detail.

3. Capture features to the defined procedure

Consistency matters as much as equipment. Define how long to occupy a point when needed, how to trace lines and polygons, how to name photos, which attribute values are valid and how to record exceptions. A clear rule helps a later reviewer distinguish a missing record from a deliberate field decision. It also reduces variation between crews and shifts.

4. Complete field quality control before leaving the site

Review a sample of attributes, photos, feature geometry, duplicate records and position status while a return visit is still possible. If the job relies on known control or a defined check shot, complete it using the approved procedure. The goal is to identify data needing correction before delivery.

5. Synchronize data with a handover record

Use the project’s approved upload, versioning and review route. Record information that a downstream GIS, survey or project team needs to interpret the work: collection date, field team, coordinate context, correction source if relevant, application version, exceptions and unresolved items. This short record can be more valuable than a screenshot because it explains the conditions behind the data.

Apply a focused configuration-selection checklist

Use this checklist when evaluating a rugged handheld, controller or external GNSS-supported configuration:

• Required data types, accuracy/tolerance and coordinate context.
• Field application, operating system, connectivity and synchronization requirements.
• Correction method, coverage and validation process where applicable.
• Screen, gloves, daylight, battery, charging, mounting and accessory needs.
• Camera, barcode, rangefinder, external antenna or other peripheral requirements.
• Offline collection, data security, support, training and country-specific service needs.

The objective is not to buy the most complex configuration. It is to choose the simplest supportable workflow that meets the data, positioning and field-use requirement. For custom integrations, also document whether the buyer needs a single unit, a multi-user rollout or a combined hardware-and-software process. The TOKNAV software path can help frame the broader field-to-office discussion, while final compatibility must always be checked for the selected project.

FAQ

Does every GIS project need RTK?

No. The required positioning method depends on the deliverable and project tolerance. Choose and document the method before field collection begins.

Can a rugged device work with an external GNSS receiver?

Some combinations can, but the exact device, operating system, application and connection method must be verified before procurement.

What should a buyer send for a workflow recommendation?

Share the field application, data types, accuracy requirement, coordinate context, correction method, users, environment, country and preferred deployment timeline.

Plan the field-to-office implementation

If you are preparing a GIS, asset-collection or RTK field-mapping rollout, share the project checklist with TOKNAV. The discussion can focus on the device category, positioning path, application compatibility and deployment questions to resolve before implementation.

An RTK rover may transition from a fixed solution to float, single or no-correction status during field operations. The appropriate response is to isolate the affected layer of the positioning chain: GNSS observation environment, correction stream, local base or radio link, data connectivity, or project configuration. A controlled sequence prevents unnecessary parameter changes and protects the integrity of field records.

Before changing a setting, record the time, location, solution status, correction age, active profile and whether the issue affects one rover or the whole crew. This record provides the evidence required for a controlled diagnosis.

Interpret the solution-status change

Receiver labels differ, but the diagnostic idea is similar. A fixed RTK solution depends on usable GNSS observations, a valid correction source and a compatible setup. When one of those inputs is interrupted or no longer sufficient, the receiver may report float, autonomous, differential or another lower-confidence status. That status is a signal to follow the project’s quality procedure—not proof that a particular receiver, service or antenna has failed.

Apply a five-layer diagnostic sequence

Layer	Typical sign	First controlled check
Sky view and antenna environment	Issue appears near trees, buildings, machinery or reflective surfaces	Move to a clear location and compare the status
Correction stream	Correction age rises, data stops or NTRIP disconnects	Confirm incoming corrections and the active profile
Local base and radio	One distance band, direction or all local rovers are affected	Check base output, power, antenna and radio path
Data connection	Network workflow fails at a particular site or time	Test the planned SIM, tether or router in an open area
Project configuration	Link looks healthy but results do not fit project checks	Review coordinate, vertical and job settings

1. Verify the GNSS observation environment

Check the simplest physical cause first. Dense vegetation, tall facades, parked equipment, cut slopes, bridges, water edges, metal roofs and other reflective surfaces can alter the observation environment. Do not decide that the receiver is faulty because a problem occurs at one difficult point. Take the rover to a nearby open point, keep the same correction profile and compare the result. If the solution recovers in the open, investigate the working environment, pole placement and the project’s acceptable collection method before changing system configuration.

2. Confirm correction-stream continuity

In a network RTK workflow, a connected account is not enough. Check whether correction data is actually arriving, whether the selected mountpoint is intended for the work area and whether the controller or receiver still has an internet route. Note the correction-age indicator and any error message. Test a known-good data path before re-entering GNSS settings.

When the workflow uses NTRIP, validate the caster profile, port, credentials, mountpoint and position-reporting requirement with the provider. The separate NTRIP setup guide outlines that chain. Do not share account credentials in a screenshot or support request; report the profile name and service context instead.

3. Verify the local-base and radio link

For a base-rover system, determine whether the base is operating and transmitting the intended corrections before changing a rover. Check power, data output, antenna connection, radio channel and antenna placement. A fault limited to one direction or a certain distance can point to terrain, line of sight, interference or link planning. A fault affecting every rover at once is more likely to involve the base, its correction output or a shared configuration than several independent rover failures.

The practical range of a radio link is not a single number. It depends on terrain, obstructions, antenna height, interference and the site arrangement. Review the RTK base-station range guide when planning the system rather than relying on an intermittent edge-of-site connection.

4. Review project configuration after link verification

Once the rover has a stable environment and active corrections, check the project profile: coordinate reference system, vertical reference, localization, control files and the selected correction source. This is especially important after importing a job, switching a controller, updating field software or moving between projects. Preserve a copy of the last working profile. Then compare one setting at a time against the project documentation or accepted control; changing several parameters together makes it impossible to know which change mattered.

5. Conduct a controlled comparison

A controlled test separates site conditions from equipment. In an open area, use the same rover, correction source and project profile to make the project’s normal check. If the system works there, return to the affected location and note what changes: sky obstruction, distance, data coverage, nearby surfaces or operating procedure. If the problem follows one component across locations, then hardware, cable, radio or antenna inspection becomes a reasonable next step. This approach is safer than replacing equipment based on one difficult observation.

Information required for technical support

Send a short, structured summary: receiver and controller model; field-software version if known; correction type; approximate environment; solution status; correction age; error message; and whether the issue affects one rover, all rovers, one location or one time of day. Add the project coordinate context only through the approved support channel. This record helps a support team determine whether the next action should focus on corrections, antenna environment, radio planning, software or a component check.

For teams reviewing a new system rather than a one-off fault, compare the TOKNAV GNSS receiver range with the complete workflow: rover count, base or network choice, antenna, controller, field software, environment and training. Equipment choice should follow the supported field process.

FAQ

Why does a rover change from fixed to float near a building or trees?

The GNSS observation environment may be affected by reduced sky view or reflected signals. Test the same setup in an open area before changing receiver settings.

Is network RTK always more reliable than a local base?

No. Network RTK can be suitable where service and data coverage are dependable; a local base can suit controlled sites or areas with limited connectivity. Review the project conditions before choosing.

When should hardware be inspected?

Inspect hardware when a controlled comparison shows the problem follows one receiver, antenna, cable or radio across otherwise comparable conditions.

Integrate correction delivery into the project plan

If repeated fixed-solution loss is affecting a survey, construction or GIS workflow, share the correction method, operating area, number of rovers and environment. Contact TOKNAV to discuss a supportable receiver, antenna and correction-workflow path.

An RTK rover operating without a local radio base requires a controlled method for receiving correction data. NTRIP is commonly used to transport correction messages over an internet connection. A reliable deployment requires more than server entries: it requires verified service parameters, a stable data route, compatible receiver and field-software settings, a defined coordinate workflow, and validation before production collection begins.

Use this procedure to configure and document the correction path. It complements the project control procedure, the correction-service provider’s instructions and validation against accepted control.

What NTRIP does in an RTK workflow

NTRIP is a method for delivering GNSS correction data over an internet connection. In a typical network RTK workflow, a reference-station network or correction provider makes a stream available through a caster. The rover, controller or connected application uses mobile data or another internet path to connect and receive that stream. The receiver then uses the incoming correction information as part of its RTK solution.

Required configuration information

Ask the correction-service provider for the connection details in writing and record them in the project file. Most clients require a caster host or IP address, port, username, password and mountpoint. The provider may also specify a correction format, whether the rover should send an approximate position and any regional coverage or reference-frame notes. Never guess a mountpoint or copy credentials from an unrelated project.

• Connection route: confirm whether mobile data comes from the receiver, controller, a phone tether or a field router.
• Rover/client: identify the receiver, controller and software profile that will make the NTRIP connection.
• Provider details: record the host, port, credentials, mountpoint and any expiry or account limits.
• Project context: confirm coordinate reference, vertical reference and the team’s validation method before work begins.

NTRIP configuration procedure

1. Establish the initial GNSS solution

Power the rover outdoors where it has an open view of the sky. Give it time to obtain a normal standalone position before trying to connect. Many workflows use the rover’s approximate position to help select or serve an appropriate correction stream. Starting indoors, beside large reflective surfaces or under dense cover makes the later diagnosis less useful.

2. Verify the data communication path

Check that the device responsible for data has a working connection in the work area. A controller may appear connected to a rover while still lacking mobile data. If possible, confirm the data path with the planned SIM, tether or router—not only with office Wi-Fi. Record the condition when a project site has intermittent coverage so crews know whether to plan a local-base alternative.

3. Create a controlled correction profile

Open the receiver or field-software correction settings and create a clearly named profile for the project or service. Enter the caster, port, login and mountpoint exactly as supplied. Select the correction format only when the provider and receiver workflow specify it. Preserve a working profile before editing it; a duplicated profile is safer than overwriting an established setup used by another crew.

4. Confirm position reporting and data reception

Some services require the client to send an approximate rover position, often labelled NMEA GGA or “send position.” Confirm the provider’s requirement and that the field client is permitted to send the information. Then watch the correction status: the useful question is whether the rover is actually receiving a current stream, not merely whether the login screen accepted the password.

5. Stabilize and validate the solution

A connected stream is not the end of the process. Observe the solution status according to the receiver’s terminology, then use your project’s normal check against known control or another accepted quality procedure. Confirm that the coordinate and vertical settings are appropriate for the deliverable. A healthy connection cannot correct a wrong localization, wrong datum choice or an unreviewed project template.

Select the correction architecture for the project

NTRIP-based network corrections can be practical when service coverage and field data connectivity are dependable. A local base-and-radio workflow can be appropriate when a site needs an independent local correction source, when mobile coverage is limited or when the project control approach calls for it. Neither path should be selected by a single label such as “network” or “radio.” Consider coverage, terrain, number of rovers, control responsibilities, mobility and the consequence of a connection interruption.

For a wider comparison, review VRS vs. RTK Base Station and the RTK base-station range guide.

When the correction session is unstable

Do not immediately reset every device. First note the time, location, rover status, correction age, data signal, selected mountpoint and error message. Test the same profile in an open area with known usable data coverage. If the connection works there but not at the project location, the next check is likely coverage or environment. If multiple rovers fail at the same time, investigate the service account, provider status or common network path before treating each rover as a separate hardware fault.

A field support request is much easier to resolve when it includes the correction method, the provider’s non-sensitive service details, the receiver/controller combination, the site environment and a screenshot or log of the status. Do not send passwords in an unsecured channel. For recurring issues, use the TOKNAV support path to document the workflow rather than relying on an informal description.

FAQ

Does NTRIP replace a GNSS base station?

NTRIP describes correction delivery over the internet. It may be used with a network service or a base that publishes a stream, but it does not remove the need to choose and validate the correction source for the project.

Why is the rover connected but not ready for production?

A login can succeed while no usable data is arriving, the rover environment is poor, or the project coordinate setup is unsuitable. Check the incoming stream and apply the accepted field validation procedure.

What should a crew record?

Record the correction provider, mountpoint, connection route, coordinate context, solution status and known-point or project check. This makes the setup repeatable for the next shift.

Assess the correction architecture before deployment

For a new rover, local base or network-correction project, share the country, coverage area, number of users, control requirements and data-connectivity constraints. Contact TOKNAV to discuss the appropriate GNSS receiver, antenna and correction path.

Compatibility evidence to request before acceptance

Record the receiver model and firmware, controller/application version, NTRIP client version, caster and port, mountpoint, correction-message list and whether the service requires GGA. Keep account passwords out of shared acceptance records. Confirm authentication and transport requirements with the provider.

Validate three separate outcomes: connection to the caster, usable correction reception, and independent coordinate agreement on project control. A pass at one stage does not imply a pass at the next.

Return to the RTK receiver compatibility guide or use the field acceptance record.