RTK vs PPK for Drone Mapping

On This Page

• What changes between RTK and PPK?
• Is PPK more accurate than RTK?
• What can fail, and what can you recover?
• What drives the cost difference?
• Which commercial missions fit each approach?

What changes between RTK and PPK?

Both methods use a moving GNSS receiver, called the rover, and observations from a reference station. GNSS means Global Navigation Satellite System. The main difference is when the positioning solution is calculated and how reference data reaches the processor.

With real-time kinematic positioning, corrections arrive from a local base or a network while the drone flies. NTRIP delivers correction data over the internet; a compatible local-base radio link can work without cellular service. RTK therefore requires a working correction path, but it does not always require internet access. Emlid's RTK explanation distinguishes these reference-delivery options.

With post-processed kinematic positioning, the reference and rover record observations for processing later. Camera exposure events connect the resulting trajectory to individual photographs. A file of ordinary navigation coordinates is not a substitute for the observations and timing records that a PPK processor needs. Emlid's PPK documentation explains why synchronizing the camera and receiver matters.

RTK and PPK workflow comparison

Source basis: the Emlid documentation above and Pix4D's RTK/PPK workflow guide, checked September 7, 2026. Operational implications are editorial synthesis.

RTK removes a separate GNSS correction step when the recorded positions are usable. It does not remove photogrammetric processing. Conversely, software that accepts PPK positions may not calculate them: Pix4D documents that PIX4Dmatic imports externally processed PPK data.

Is PPK more accurate than RTK?

There is no universal winner. Compare the same aircraft, camera, flight geometry, reference coordinates, processing settings, and independent checkpoints. Otherwise, differences attributed to correction timing may actually come from another part of the mapping system.

The precision comes from measuring the satellite signal's carrier phase. The processor must resolve the unknown number of whole signal cycles, called integer ambiguity. A fixed solution has resolved those integer ambiguities; a float solution has not fixed them to integers. NovAtel explains the carrier-phase mechanism and fixed and float processing solutions. Satellite geometry, observation quality, and base-to-rover distance still affect the result.

Pix4D's published field and urban comparison illustrates the distinction. Its open-field flight recorded 99% RTK-fixed camera positions. In the urban flight, only 71% were RTK-fixed, and post-processing improved the result. Those are results from its particular eBee Plus and PIX4Dmapper workflow, not performance promises for another drone or site. See the test conditions and results.

Also separate relative accuracy, meaning agreement between features within the model, from absolute accuracy, meaning agreement with their positions in a defined reference frame. A model can have useful internal dimensions and still be displaced on the ground. Pix4D's accuracy guidance identifies image quality, overlap, scene content, geolocation, and control as important variables. Small pixels do not establish equally small position errors.

Ground control points constrain the model to surveyed coordinates. Checkpoints provide a comparison against surveyed positions for quality assessment. Preserve that distinction when assigning point roles in the software; a good fit to coordinates used as control is not an independent test. Pix4D's tie-point documentation explains those roles.

For a commercial deliverable, agree on the required horizontal and vertical checks before flying. Compare both methods against those same requirements. A receiver's fixed-status indicator cannot answer whether the delivered orthomosaic or elevation model passes them.

What can fail, and what can you recover?

Correction-link loss and satellite-observation loss are different problems. PPK avoids dependence on the live correction connection. It still needs usable GNSS observations. It cannot reconstruct a missing base recording or a camera event that was never captured. If the problem concerns aircraft navigation, see what happens when a drone loses GNSS.

Before relying on PPK as an RTK fallback, perform a complete sample-file handoff with the actual aircraft and processor. Emlid Studio's RTK-drone post-processing guide, for example, requires base and drone RINEX observations, a drone MRK event file, images, and navigation data. It also requires matching photo and timestamp counts. These requirements describe that supported workflow, not every RTK aircraft.

Use this field-exit checklist:

• Confirm the base and rover recordings overlap the flight period.
• Retain the original photographs, observation files, exposure events, and positioning-status records.
• Record the reference coordinates and antenna height used for processing.
• Verify the processor's camera-to-antenna offset treatment and the image-to-event association.
• Preserve the corrected position export and identify which image set received it.

These checks follow the Emlid workflow above and its kinematic-processing checklist. Demonstrating the complete handoff before a remote assignment is an editorial recommendation: finding an unsupported file format after demobilization leaves fewer recovery options.

Reference coordinates deserve particular attention. NOAA advises using published CORS coordinates and velocities rather than treating approximate RINEX header coordinates as authoritative. Its CORS FAQ also distinguishes the data archive from real-time services. A reference station appearing in an archive does not establish that it supplies the live stream or flight-period files your workflow needs. Confirm the coordinate frame, relevant epoch, units, and height reference across the project.

What drives the cost difference?

Compare the cost of a completed, checked job. RTK can involve correction-service access, communications, or owning and operating a local base. PPK adds file handling and GNSS processing, with costs depending on software, automation, and staff time. Both retain imagery processing and quality-control work. DroneDeploy's workflow guide identifies the different field-equipment and connectivity requirements.

Use this estimating formula with your own quotes and labor records:

Cost per accepted mapping job = allocated equipment and software cost + reference-data and communications cost + field labor + processing and checking labor + rework cost.

This is a budgeting structure, not a market-price estimate. Keep the deliverable, project area, control plan, and checking requirements identical when comparing options. Include base setup and retrieval time even if the receiver is already owned. For PPK, include file review and correction processing even if the software has no separate charge.

The largest uncertainty may be rework. On a nearby recurring site, an extra processing step may outweigh little travel risk. On a remote assignment, avoiding another mobilization may justify maintaining both correction workflows. Estimate those scenarios from your own operations instead of assuming PPK always saves money or RTK is always faster.

Which commercial missions fit each approach?

The following recommendations apply the documented dependencies to common assignments. They are workflow choices, not measured productivity rankings.

Source basis: Emlid's RTK and PPK documentation, Pix4D's comparison, and DroneDeploy's workflow guide. Mission fit and budgeting implications are editorial interpretation.

Choose RTK when live corrected positions make the operation easier and the correction path is dependable. Choose PPK when collecting complete observations is more reliable than delivering corrections in real time. Where a return trip would be expensive, verify the PPK fallback before departure. Whichever method you choose, judge success by the checked map delivered to the client.

Source notes

• NovAtel: Pseudorange and carrier phase. Technical explanation of precise GNSS measurements.
• NovAtel: Processing modes and solutions. Technical documentation on fixed and float solutions and their dependencies.
• Emlid: How RTK works. Manufacturer documentation on base, rover, and correction delivery.
• Emlid: How PPK works. Manufacturer documentation on recorded observations and camera synchronization.
• Pix4D: RTK and PPK workflow. Software documentation on processing and position-file imports.
• Pix4D: RTK vs PPK drones vs GCPs. Provider-conducted comparison with stated flight conditions.
• Pix4D: Relative and absolute accuracy. Technical guidance on reconstruction and georeferencing limits.
• Pix4D: Tie points in photogrammetry. Software documentation distinguishing control and checkpoint roles.
• Emlid Studio: RTK drone data processing. File, offset, and geotagging requirements for its supported workflow.
• Emlid Studio: Kinematic processing. Observation overlap, reference coordinates, and antenna-height checks.
• NOAA National Geodetic Survey: CORS FAQ. Government documentation on reference data and coordinate use.
• DroneDeploy: When should I use GCPs vs RTK/PPK?. Provider guidance on field equipment and workflow selection.

Last checked: September 7, 2026.