Both are GNSS correction techniques, both produce centimetre-grade positions, both are commonly quoted as if they're equivalent. They aren't — and the difference shows up in deliverables long after the capture is done.
If you've reviewed enough drone LiDAR quotes you've seen the words RTK and PPK used interchangeably. They look like jargon, they both involve a base station and a drone, and both produce cm-grade positioning. So why do experienced engineering teams insist on PPK for any capture they'll be audited against?
Because the workflows are genuinely different — and the difference matters more when something goes wrong than when everything goes right.
This is the engineering version. By the end you'll understand what each acronym actually does, where they fail, and the questions to ask a provider to validate which workflow they're really using.
A raw GNSS receiver on its own — even with multi-constellation support (GPS + GLONASS + Galileo + BeiDou) — gives you a position accurate to about ±1–3 metres horizontally, worse vertically. That's fine for finding your way home; it's hopelessly loose for survey work, where the deliverable specification is typically ±15–30 mm.
To close that ~100× gap, you need to compare the drone's GNSS observations against a second receiver at a known location — a base station. The base sees the same satellite errors (orbit, clock, ionosphere) and can compute a correction; the drone applies that correction and produces a much tighter position.
Both RTK and PPK do exactly this. The difference is when the correction is applied.
In an RTK workflow, the base station broadcasts the correction data live, either over a UHF radio link or via a cellular NTRIP service. The drone receives the corrections in real time, applies them at the GNSS receiver, and reports a corrected position immediately.
What you get:
What you don't get:
In a PPK workflow, the base station doesn't broadcast — it just logs its raw GNSS observations to a RINEX file. The drone also logs its raw observations. Neither applies any correction during the flight.
After landing, post-processing software (NovAtel Inertial Explorer, Applanix POSPac, Trimble Trident) takes both logs, matches the satellite observations between them epoch-by-epoch, and computes the corrected trajectory of the drone through the entire flight.
What you get:
What you don't get:
For engineering-grade deliverables — captures that will sit in a design pack, drive earthworks invoices, or be audited by a regulator — PPK is the industry standard. Not because it's marketing-friendly, but because the engineering case is unambiguous.
RTK depends on a live link from base to drone. Over UHF radio, this is bandwidth-limited and lossy at the edges of the operating distance. Over NTRIP (cellular), it requires good cellular coverage at flight altitude — frequently flaky on remote sites, in valleys, or behind ridge lines.
When the link drops, the RTK-equipped drone falls back to standalone GNSS for the duration. Standalone GNSS is the ±1–3 m positioning we started with. Every laser pulse captured during the dropout is geo-referenced against that loose solution; every point ends up in roughly the right area but offset by metres rather than millimetres.
Most pilots see "RTK_FIXED" reported the whole flight and assume all is well. The fix may genuinely have been good for 95% of the flight; the 5% you didn't notice produces unusable point cloud.
With PPK, the entire trajectory is computed after landing from the logged base + drone observations. Link dropouts are irrelevant because no link existed during flight — the correction is computed from records, not transmitted live.
PPK software typically processes the trajectory twice — forward from start-of-flight to end, and backward from end to start. The two solutions are compared and combined.
This matters because GNSS solutions converge differently at flight edges than in the middle. Run forward and the start has wide covariance because the algorithm is still settling; run backward and the end has the same problem instead. Combining the two gives you tight solutions at both ends.
The net effect is a 30–50% tighter trajectory than RTK could achieve on the same hardware in the same conditions. Sometimes that's the difference between hitting and missing the project's accuracy spec.
A PPK capture ships with the RINEX base log and the drone log. If six months later the project asks for re-processing — say the client's design package shifted to a different vertical datum — the trajectory can be re-run against the new control. If the post-processing software is upgraded with improved algorithms, the capture can be re-run with the new pipeline.
RTK provides none of this. The real-time correction is consumed at the receiver; no log of the raw observations exists. If the delivery has problems, the capture has to be redone — there's nothing to re-process.
For repeat-cycle programmes (monthly mine reconciliation, quarterly clearance audits), this auditability is especially valuable. Every historical capture stays comparable as the pipeline evolves.
The case for PPK isn't just abstract engineering — there are specific, real-world failure modes that only PPK can detect and recover from.
RTK reports "RTK_FIXED" when the receiver has a high-quality solution. The problem is that "RTK_FIXED" is a binary indicator, not a quality measure. The fix can degrade significantly while still reporting fixed status, and the resulting position can drift several centimetres without the pilot noticing.
The drift is invisible during flight. It surfaces only after processing, when independent control checkpoints reveal localised residuals that shouldn't be there. PPK reveals this in post-processing because the covariance estimates from forward + backward solution show exactly where the trajectory was less certain.
UHF RTK has a typical operating range of 1–3 km depending on power, antenna placement, line-of-sight and interference. On a larger site or in dense terrain, segments of the flight inevitably fall outside reliable range.
Without PPK, those segments produce loosely-corrected data the pilot didn't see at the time. With PPK, the post-processed trajectory uses the same logged observations regardless of where the drone was relative to the base — the algorithm computes the correction from the raw data, not from when the radio link was strong.
The base station's own position solution depends on its environment. A base placed near metal structures, vehicles, reflective surfaces or under trees can suffer multipath — satellite signals reflecting before reaching the antenna, corrupting the base's idea of its own position.
Every RTK client inherits the corruption immediately. With PPK, the base log can be analysed post-flight: multipath shows up as characteristic noise patterns in the residuals, and the base position can be cross-validated against CORS networks. Problems that would silently corrupt an RTK delivery are visible and correctable in PPK.
In fairness, RTK has legitimate uses:
But none of these are the same as engineering-grade deliverables. For any capture that's going to be audited, used for design, or relied upon for asset decisions, PPK is the engineering choice regardless of how good the RTK looked on the day.
Cut through the marketing and surface what's actually being done:
Do you post-process the trajectory with PPK? Yes / no answer. A vendor that says "RTK was fine" is signalling something you should weight.
Can I see the base station RINEX log for my capture? Should be available as standard. Provides full audit trail.
What forward + backward processing was used? Inertial Explorer or POSPac are common; both support FB processing. Verify it was used (not just available).
What's the trajectory covariance plot look like? A flat tight covariance through the flight indicates a good solution. Spikes indicate localised problems.
Were independent checkpoints used to validate the accuracy? Marks used in calibration are guaranteed to fit. Marks withheld from calibration are the genuine accuracy test.
Any reputable provider answers all five without difficulty.
Two adjacent acronyms worth knowing:
CORS (Continuously Operating Reference Station) networks — AusCORS, GA-managed network in Australia — provide standardised RINEX logs from permanent reference stations across the country. If your project is within reasonable baseline distance (typically 50 km, sometimes up to 100 km) of a CORS station, you can skip the local base station entirely and PPK against the public CORS log. Same accuracy, no equipment to set up, full auditability.
PPP (Precise Point Positioning) is an alternative to both RTK and PPK that doesn't need a base station at all. It uses precise satellite orbit and clock corrections published by the IGS to derive accurate positions from a single receiver. The catch: convergence times are typically 10–30 minutes per session, and the accuracy is decimetre-grade rather than centimetre-grade. PPP has niche use for very remote projects far from CORS networks or for applications where decimetre accuracy is acceptable; it's not a replacement for PPK in engineering work.
Both RTK and PPK reach cm-grade positioning. PPK is more accurate, more auditable, more recoverable, and only marginally more expensive. For engineering-grade drone LiDAR captures the choice is unambiguous — PPK is the workflow.
A provider quoting "RTK" without mention of PPK or post-processing is either using a different acronym for the same thing (sometimes PPP) or relying on the real-time correction alone. The second option carries silent risk that surfaces only at audit time.
The right question to ask isn't "do you do RTK?" — it's "do you PPK-correct the trajectory against a logged base, and can I see the QA pack?"
Tell us the deliverable spec and the audit context. We'll scope the capture with the PPK + control + checkpoint workflow your project needs to defend its numbers.