If RTK is the live correction on the controller, PPK is the same idea applied after you land. The acronym sits next to RTK on aircraft specs and survey scopes. Plenty of mapping pilots who already fly Fixed still cannot explain what happens when that live link never shows up.
PPK stands for Post-Processed Kinematic. In PPK drone mapping, the aircraft is still the rover. Corrections from a base or CORS network are applied to the rover observations after the flight, not over a radio or NTRIP stream while you fly.
Pilot Ledger is ops and CRM for commercial pilots, not a GNSS engine. This is the field explanation of what the correction is doing when it happens at the desk. For the live side of the same story, start with What Is RTK? Drone Mapping Explained.
What PPK means
A typical drone GNSS receiver without a correction is usually good to a few meters. That holds a flight line. It is not enough if the client drops the orthomosaic onto a civil set and expects a curb to land on a curb.
The error sources do not change between RTK and PPK: clocks, orbits, atmosphere. A second receiver sitting still (a base) sees those errors too. In RTK, that base or a network caster pushes corrections to the rover in real time. In PPK, both receivers log raw observations. After the flight, processing software combines the rover log with the base or CORS log and recomputes the photo positions.
A good PPK run gives corrected positions for the images you already flew. It is not a stamp that the map is finished. Fixed solutions, known points, datums, and independent check shots still decide whether the deliverable belongs on someone else's control.
PPK versus RTK
RTK and PPK are two delivery schedules for the same kinematic correction idea.
RTK applies corrections while you fly. You watch Fixed or Float on the controller. If the radio fades or the cell link drops, the live correction stops even if the aircraft keeps flying. That is the failure mode PPK is built to handle.
PPK applies corrections after the flight. You do not need a live radio or NTRIP session for positions to be corrected later, as long as the rover logged usable observations and a matching base or CORS log covers the same time window. The trade is no live Fixed status on site. You learn how the solution came out when you process.
Neither method is a different kind of accuracy by itself. Both can support centimeter-level work when the solution fixes, the base is tied to a known point in the right datum, and you still verify with check shots.
What logs you need
PPK only works if the observations exist. An aircraft labeled "PPK ready" does not invent missing files.
Rover observations
The aircraft (or its GNSS module) must log raw rover observations for the flight: carrier-phase and code measurements tied to time. Without the rover obs for the period you flew, there is nothing for the base to correct later. Confirm logging before launch, not after you pack up.
Base or CORS observations
You also need reference observations that cover the same window:
- A local GNSS base left logging for the whole flight (antenna height measured, sky open).
- Or CORS / network station files that overlap takeoff through landing, pulled after you get home.
A base that stopped mid-flight, or a CORS file that misses your window, leaves gaps you cannot invent later. Checklist: rover obs for the sortie, base or CORS obs for the same interval, and a clear record of which point and datum that reference sits on.
When PPK saves a flight that lost RTK
You planned RTK. The rover showed Fixed at launch. Halfway through, the radio faded or the NTRIP caster dropped. The aircraft kept flying. The live correction did not.
If the rover was still logging raw observations, and a base or CORS log covers that stretch, PPK can reprocess those epochs after the flight. That is the recovery path when the live link fails: corrections can also be applied later.
PPK does not rewrite physics. If the rover never logged, or the base was not running, there is nothing to post-process. Logging that the aircraft is RTK-capable is not the same as a flight that stayed Fixed, and it is not the same as a flight that left you the obs files to fix later. Treat lost RTK as a lost live correction. Keep flying only if the logs are still writing and you have a post-process plan. Otherwise restore the link, confirm Fixed, then continue.
Fixed versus float after processing
In RTK, Fixed and Float show up on the controller. In PPK, the same words show up in the processing report.
Fixed means the processor resolved the integer ambiguities in the carrier-phase measurements. That is the solution you want before you treat photo positions as survey-useful.
Float means the processor had a better guess than raw GNSS, but those integers stayed ambiguous. Float is not a finished survey position. Do not deliver a civil-overlay map on a float-heavy PPK report and hope the orthomosaic looks accurate enough.
Read the report. If the epochs that matter did not fix, you do not have PPK in the sense the client thinks you do.
Known point, datum, and check shots still matter
PPK does not replace a known point, the coordinate system, the vertical datum, or independent checks.
The correction is relative to the reference you used. A local base on a bad coordinate produces a tight map in the wrong place, whether you applied that base in real time or after the flight. A CORS solution in a datum the civil set does not use produces a clean overlay that misses. Absolute accuracy is where the map sits on the Earth; relative accuracy is how well the map holds together with itself. PPK can help both. It does not certify either.
If the deliverable will sit on a civil set, take independent check shots (GCPs or checkpoints you did not use to steer the solution) and report how the map sits on those points. A fixed PPK flight with no checks is a claim. A fixed PPK flight with checks is a map you can stand behind.
What to confirm before you rely on PPK
- The rover is logging raw observations for the full flight, not only writing geotags.
- A local base is logging for the same window, or you have a plan to pull CORS files that cover takeoff through landing.
- You know the reference point, antenna height, and datum you will assign in processing.
- You can read Fixed versus Float in the PPK report, not only a green "processed" status.
- You have independent check shots planned for any map that has to land on someone else's control.
None of that requires a geodesy degree. It requires treating PPK as post-flight correction from real observation logs, not as a mode that forgives a missing base, a wrong datum, or a flight with no checks.
If a log format, a CORS pull, or a Fixed-versus-Float report still is not clear, ask the follow-up on Ask Mav at pilotledger.com.
If RTK is the live correction on the controller, PPK is the same idea applied after you land. The acronym sits next to RTK on aircraft specs and survey scopes. Plenty of mapping pilots who already fly Fixed still cannot explain what happens when that live link never shows up.
PPK stands for Post-Processed Kinematic. In PPK drone mapping, the aircraft is still the rover. Corrections from a base or CORS network are applied to the rover observations after the flight, not over a radio or NTRIP stream while you fly.
Pilot Ledger is ops and CRM for commercial pilots, not a GNSS engine. This is the field explanation of what the correction is doing when it happens at the desk. For the live side of the same story, start with What Is RTK? Drone Mapping Explained.
What PPK means
A typical drone GNSS receiver without a correction is usually good to a few meters. That holds a flight line. It is not enough if the client drops the orthomosaic onto a civil set and expects a curb to land on a curb.
The error sources do not change between RTK and PPK: clocks, orbits, atmosphere. A second receiver sitting still (a base) sees those errors too. In RTK, that base or a network caster pushes corrections to the rover in real time. In PPK, both receivers log raw observations. After the flight, processing software combines the rover log with the base or CORS log and recomputes the photo positions.
A good PPK run gives corrected positions for the images you already flew. It is not a stamp that the map is finished. Fixed solutions, known points, datums, and independent check shots still decide whether the deliverable belongs on someone else's control.
PPK versus RTK
RTK and PPK are two delivery schedules for the same kinematic correction idea.
RTK applies corrections while you fly. You watch Fixed or Float on the controller. If the radio fades or the cell link drops, the live correction stops even if the aircraft keeps flying. That is the failure mode PPK is built to handle.
PPK applies corrections after the flight. You do not need a live radio or NTRIP session for positions to be corrected later, as long as the rover logged usable observations and a matching base or CORS log covers the same time window. The trade is no live Fixed status on site. You learn how the solution came out when you process.
Neither method is a different kind of accuracy by itself. Both can support centimeter-level work when the solution fixes, the base is tied to a known point in the right datum, and you still verify with check shots.
What logs you need
PPK only works if the observations exist. An aircraft labeled "PPK ready" does not invent missing files.
Rover observations
The aircraft (or its GNSS module) must log raw rover observations for the flight: carrier-phase and code measurements tied to time. Without the rover obs for the period you flew, there is nothing for the base to correct later. Confirm logging before launch, not after you pack up.
Base or CORS observations
You also need reference observations that cover the same window:
- A local GNSS base left logging for the whole flight (antenna height measured, sky open).
- Or CORS / network station files that overlap takeoff through landing, pulled after you get home.
A base that stopped mid-flight, or a CORS file that misses your window, leaves gaps you cannot invent later. Checklist: rover obs for the sortie, base or CORS obs for the same interval, and a clear record of which point and datum that reference sits on.
When PPK saves a flight that lost RTK
You planned RTK. The rover showed Fixed at launch. Halfway through, the radio faded or the NTRIP caster dropped. The aircraft kept flying. The live correction did not.
If the rover was still logging raw observations, and a base or CORS log covers that stretch, PPK can reprocess those epochs after the flight. That is the recovery path when the live link fails: corrections can also be applied later.
PPK does not rewrite physics. If the rover never logged, or the base was not running, there is nothing to post-process. Logging that the aircraft is RTK-capable is not the same as a flight that stayed Fixed, and it is not the same as a flight that left you the obs files to fix later. Treat lost RTK as a lost live correction. Keep flying only if the logs are still writing and you have a post-process plan. Otherwise restore the link, confirm Fixed, then continue.
Fixed versus float after processing
In RTK, Fixed and Float show up on the controller. In PPK, the same words show up in the processing report.
Fixed means the processor resolved the integer ambiguities in the carrier-phase measurements. That is the solution you want before you treat photo positions as survey-useful.
Float means the processor had a better guess than raw GNSS, but those integers stayed ambiguous. Float is not a finished survey position. Do not deliver a civil-overlay map on a float-heavy PPK report and hope the orthomosaic looks accurate enough.
Read the report. If the epochs that matter did not fix, you do not have PPK in the sense the client thinks you do.
Known point, datum, and check shots still matter
PPK does not replace a known point, the coordinate system, the vertical datum, or independent checks.
The correction is relative to the reference you used. A local base on a bad coordinate produces a tight map in the wrong place, whether you applied that base in real time or after the flight. A CORS solution in a datum the civil set does not use produces a clean overlay that misses. Absolute accuracy is where the map sits on the Earth; relative accuracy is how well the map holds together with itself. PPK can help both. It does not certify either.
If the deliverable will sit on a civil set, take independent check shots (GCPs or checkpoints you did not use to steer the solution) and report how the map sits on those points. A fixed PPK flight with no checks is a claim. A fixed PPK flight with checks is a map you can stand behind.
What to confirm before you rely on PPK
- The rover is logging raw observations for the full flight, not only writing geotags.
- A local base is logging for the same window, or you have a plan to pull CORS files that cover takeoff through landing.
- You know the reference point, antenna height, and datum you will assign in processing.
- You can read Fixed versus Float in the PPK report, not only a green "processed" status.
- You have independent check shots planned for any map that has to land on someone else's control.
None of that requires a geodesy degree. It requires treating PPK as post-flight correction from real observation logs, not as a mode that forgives a missing base, a wrong datum, or a flight with no checks.
If a log format, a CORS pull, or a Fixed-versus-Float report still is not clear, ask the follow-up on Ask Mav at pilotledger.com.