Finding the Plot Twice: Why Field Trials Need Repeatable Coordinates

In field trials, the hard part is often not finding the field. It is finding the same point again after the flags are gone, the crop is taller, the intern has changed, and last season's notes have turned into a spreadsheet.

That is where ordinary phone GPS starts to show its limits. A few feet of drift may not matter when you are driving to a gate. It matters when a plot corner, a soil sample, or a drone GCP is supposed to line up with last season's data.

Most research crews need a smaller workflow: capture points, revisit them, and keep plot IDs, samples, images, and treatment records tied to the same place over time.

This article looks at how a handheld RTK GPS for field trials workflow fits plot work, georeferenced sampling, and drone GCPs in North America — especially for teams that want a phone or tablet workflow instead of a dedicated survey data collector. For broader phone-based positioning workflows, see RTK receiver for a phone or tablet. For the underlying NTRIP and RTCM correction mechanics, see Inside NTRIP. Field boundary mapping and acreage measurement use the same hardware but a different workflow, and a future article in this series will cover that.

Field Trials Need Repeatable Coordinates, Not Just Better Navigation

A phone GPS that gets you to the field is not necessarily a phone GPS that gets you back to the same plot corner. Navigation is forgiving — a couple of meters off and you correct on the way. Plot work is not forgiving — a couple of meters off and the sample is in the wrong row, the GCP no longer matches last year's flight, and the field record no longer matches the trial plan.

The hardware that fits a field-trial team usually depends on what kind of work the team actually does:

For teams that specifically need RTK for research plots — breeding strips, agronomy replications, or small-plot variety trials — the workflow is primarily about GPS for plot trials: capturing a coordinate once and returning to it reliably, season after season.

Where Position Drift Shows Up in Real Plot Work

Plot layout, georeferenced sampling, and drone GCPs each have their own symptoms when position drifts — but the underlying cause is the same.

Plot layout and re-staking

In North American field trials, many research teams already manage trial IDs, plot layouts, treatment structures, replications, and assessment data through tools such as ARM, AGROBASE Generation II / Genovix, spreadsheets, or internal databases. The RTK workflow does not need to replace any of that. Its job is narrower: to add a layer of repeatable coordinates that exports cleanly into the existing trial ID, plot layout, treatment table, and assessment workflow the team is already using.

In practice, that means a workflow that starts in the office — plot list, point list, treatment map — and ends in the field with stakes, flags, or marker discs at coordinates the next operator can find again. The difficulty is not laying out the plots on day one. The difficulty is re-staking them after a tillage pass, after a wet spring, after the original markers are gone and the intern who placed them has moved on.

That is where the RTK layer earns its place. The same coordinate, captured under the same correction source and the same datum, can be re-occupied by a different operator next season without guessing.

Georeferenced sampling

Sampling work in a field trial is usually a crew member walking between plots with a Dutch auger, a Giddings probe, or a tissue bag — a handful of points per plot, recorded on a phone or tablet. The accuracy demand is not in the soil chemistry. It is in being able to come back to the same point in October, next May, or three seasons later, and pull a comparable sample from soil that has not been disturbed by a different sampling location.

This is a different workflow from commercial soil-sampling fleets, which run on ATV-mounted hydraulic samplers and rugged tablet stacks designed for high-throughput grid sampling. That market has its own form-factor needs — a handheld phone-plus-RTK workflow is not a fit there, and this article does not try to cover it.

Drone GCPs and repeat flights

Many professional agricultural and mapping drones now include RTK or PPK (post-processed kinematic) workflows as standard or common configurations. The DJI Agras spraying series and the DJI Mavic 3 Multispectral ship with centimeter-level RTK positioning; fixed-wing mapping platforms such as the senseFly eBee X support RTK or PPK; and Wingtra systems run a PPK-based survey workflow. With onboard RTK or PPK and the right correction stream, many ag-mapping projects can reduce or remove the need for full GCP layouts in routine work.

That has shifted the role of GCPs rather than removed them. GCPs and check points are still worth the effort in three situations: when historical archive flights captured without high-accuracy positioning need to be aligned to current data; when multiple seasons of imagery, possibly captured with different drones or different correction sources, need to be tied to a single coordinate frame for trend analysis; and when the photogrammetry accuracy claim has to be defensible to an external reviewer or peer-reviewed publication. Even on drones with RTK or PPK, keeping a few independent check points is still a common practice in research-grade work — they verify that the onboard solution actually delivered what it claims.

In any of those cases, every GCP coordinate is itself a candidate for the same drift problem as a plot corner. A GCP that moved 30 cm between the May flight and the October flight will show up in the orthomosaic as a misregistration that no photogrammetry software can fully correct. The drone can only benefit from GCPs if the coordinate set was captured once and can be re-occupied later.

When Revisit Error Starts to Matter

In a 12-meter plot grid, 30 cm does not sound like much. In the office, it looks smaller than the line width on a printed map. In the field, it can put a sample close enough to the wrong row, the wrong treatment edge, or the wrong GCP mark to make the data harder to trust.

The problem is not that every 30 cm error ruins every trial. The problem is that the error is usually invisible. The point still looks reasonable on a phone screen. The operator still feels close to the flag location. The spreadsheet still accepts the coordinate. The mistake only appears later, when the May sample and the October sample no longer behave like they came from the same treatment area.

The size of the plot determines the size of the problem. On a small breeding plot — a row or two of corn, a 1.5-by-6-meter strip of wheat — even 5 to 10 cm of revisit error can put a sample on the wrong side of a treatment boundary. On a larger agronomy plot, 30 cm may still sit inside the same treatment block but pollute the inner buffer. For drone GCPs, what matters is not the ground number but how that error projects into the orthomosaic at flight altitude. None of these is a hard threshold. They are reasons to ask whether the workflow can hold the same point twice — not whether the receiver can hit a number once.

For the plot revisit accuracy that field trials actually need, a receiver that can hold a fixed solution, use the same correction source, and export points with clear metadata is more useful to a research crew than a vague promise of "high precision."

A Practical Phone-plus-RTK Workflow for Research Crews

A handheld RTK workflow for field trials is mostly about getting four things to behave consistently, in the right order, on every visit.

A basic setup does not need many parts. But if one part is missing — the correction source, the pole height, the app setting, or the export format — the point record becomes hard to reuse next season.

The pieces that make up a basic field-trial setup, and what each one actually does:

In the office, the workflow starts with a plot list or point list pulled from the trial management system — ARM, a spreadsheet, an internal database — and exported as CSV, shapefile, or KML into the collection app. That import step is the easiest place to lose plot IDs or treatment labels, so it is worth checking once before walking out the door.

In the field, the routine is short but not trivial. Connect the phone to the rover over Type-C. Start an NTRIP session, preferably from the same correction source the team used last season — the simplest way to keep coordinates consistent is to keep the source consistent. If a switch is unavoidable — a state RTN goes offline, the project moves to a different region, the team adds a commercial subscription — verify that the new source uses the same reference frame as the old one, log the change in metadata, and check the transfer against a known point before relying on it. Wait for a fixed solution. Record the antenna height, the datum, and the correction mountpoint in the point metadata, not just in the operator's head. Then walk the plots.

At the end of the season, export the point set and archive it with the project ID, season, operator, correction source, and datum. Many "lost" plots start as a season-end handoff problem: the coordinate survives, but the metadata needed to interpret it does not.

The North American Detail Many Teams Miss: Datum and Correction Source

When old points do not line up with new points, the receiver often gets blamed first. In North America, the quieter problem is often the coordinate frame. The two North American details that most often turn a working RTK workflow into a confusing one are the correction source and the coordinate frame — and they sit one layer below the receiver, where most teams do not look first.

Correction sources: public CORS is not the same as an RTN subscription

Real-time correction options in North America fall into a few tiers, and which one fits depends mostly on what the research station can reach from its area:

NGS CORS is public infrastructure: the station data is openly available and the network is operated by NOAA's National Geodetic Survey as part of the broader National Spatial Reference System. That is not the same thing as a real-time RTK service for a phone in the field. The CORS data is intended for post-processing and reference, and most field-trial RTK work runs on a state RTN, a commercial RTN, or a local base. Some state networks are free or low-cost; others require registration, agency affiliation, or paid access — coverage, mountpoints, and account terms vary widely from one state to the next.

The practical step for a research crew is not to map out every network in the country. It is to confirm what correction source is reachable from the trial site, register for it, and treat the choice as a workflow decision rather than a per-trip pick. When more than one source is in play, the team should know which one they are using on each visit and whether the sources agree on the reference frame.

Datum continuity: not a textbook problem, a re-survey problem

If last year's points came from a phone app logging WGS84 and this year's rover is set up around NAD83(2011), the mismatch may be small in casual mapping but large enough to confuse plot-level revisit work. The receiver may be behaving correctly. The datums simply are not the same.

The datums that show up in North American agricultural workflows are not interchangeable, and the differences are large enough to matter for plot revisit:

Most crews do not need to become datum experts. They just need to stop saving points as "GPS coordinates" with no note on correction source, datum, or season. Two practical habits cover most of the risk: label coordinates with the specific realization — write "NAD83(2011) epoch 2010.0," not a generic "NAD83" — and keep the correction source recorded next to the points. NOAA's National Geodetic Survey has released beta components for the modernized NSRS, including the 2022 terrestrial reference frames such as NATRF2022. As of mid-2026, these products remain part of the transition from today's NAD83-based NSRS toward the modernized system, with official adoption dependent on final testing, approval, and rollout. The exact operational date matters less for this workflow than the habit: record the coordinate realization, correction source, and season with every saved point.

Where SCOUT Fits — and Where It Does Not

A compact Type-C RTK rover fits the handheld side of this workflow: phone or tablet as the field screen, RTK receiver as the positioning source, and the collection app as the point archive. KALMIX SCOUT is one example of this category — for teams that want to use a phone or tablet as the field interface instead of carrying a separate survey data collector or a standalone Bluetooth rover.

That makes it most useful for static or slow field tasks: staking plot corners, revisiting sampling points, capturing drone GCPs, and building a coordinate archive that can be handed from one operator to another. For teams whose data already lives in QField, ArcGIS Field Maps, or a custom collection app, the Type-C connection removes one device, one battery, and one Bluetooth pairing step from the field routine.

Behind that form factor is a standard serial-data workflow. SCOUT connects to the host as a USB serial device and outputs NMEA 0183 over that link. On Linux and many Android environments, this workflow is usually handled through standard USB-serial support. On Windows, driver behavior depends on the USB-serial chipset, driver package, and system image, so the full receiver-cable-app chain should be tested before field deployment. That keeps SCOUT outside of any single vendor's app ecosystem, which is the right shape for research teams that want to keep their own data path.

This is a different path from the two more familiar ones. A Trimble R-series or Topcon Hiper paired with a TSC7-class data collector covers high-end survey workflows and machine control, at a price and form factor that matches that use. An Emlid Reach RS2+ or RS3 covers the standalone-rover-over-Bluetooth path, which works well when the field crew wants a self-contained device with its own display. A Type-C integrated receiver covers the case where the team's phone or tablet is already the field interface and the workflow does not need a second device. The right choice depends on what the crew already carries into the field. For teams also weighing the lower-level choice between a bare GNSS module, a development board, and a field-ready receiver, see RTK Module vs RTK Receiver.

SCOUT should not be described as a replacement for every survey-grade setup. The built-in dual-feed dual-layer ceramic antenna is compact, IP67-rated, and well suited to handheld plot work, but it will not behave like a survey antenna or a choke-ring antenna in every multipath environment. For most plot-revisit work, that trade-off may be acceptable. For control work that requires survey-grade antenna stability, the antenna and mount should be sized accordingly — and a different form factor may be the right call.

Both SCOUT and SCOUT Pro come in a Standard RTK configuration and an RTK+DR configuration. The DR variant adds dead-reckoning capability to bridge short GNSS interruptions — useful for slow-moving platforms such as a phenotyping cart. A future article in this series covers the dynamic-platform workflow in more depth.

Conclusion

Most field-trial positioning failures start in the workflow: the same plot corner captured under a different correction source, the same sample logged in a different datum, or the same GCP re-occupied by a different operator without the metadata that lets the new coordinate match the old one.

The minimum workable answer is small: a phone or tablet, a compact RTK rover, a stable pole, a single correction source, a recorded datum, and an end-of-season archive that carries those four pieces of metadata forward. Most research crews already have most of that. The receiver only helps if the crew also keeps the point names, correction source, datum, and season notes with the data.

For field-boundary work and acreage measurement, the same hardware extends naturally — a future article in this series will cover that workflow. DIY tractor autosteer with the same kind of receiver, including the AgOpenGPS path, will also have its own dedicated article. Both build on the same handheld foundation described here.

Frequently Asked Questions