PPK from Logs: Can You Trust a Track Solved After the Fieldwork
On this page
TL;DR
PPK solves a recorded GNSS trajectory after the run, while RTK must deliver positions as the Rover moves. Both can reach centimeter-class accuracy. PPK can revisit weak epochs with later observations, combine forward and reverse processing, and smooth GNSS/INS data. Its logging workflow also survives a lost live correction link when Rover and reference observations remain usable.
Look at a road map: the curve of a ramp and the line separating two lanes had to be measured somewhere. A mapping vehicle drives that road with cameras, LiDAR, and an inertial measurement unit (IMU). Those sensors describe the road and the vehicle's motion relative to one another. GNSS supplies the absolute coordinate anchor that places their observations in the map's frame. Timestamps and sensor mounting geometry then connect each image and scan to that moving anchor.
The vehicle can show an RTK position to its operator and record raw GNSS observations for a PPK solution after the drive. A final map needs a coherent, checked route, not just a live position at each second.
PPK vs RTK: The Same Measurements, a Different Deadline
Post-processed kinematic (PPK) positioning and real-time kinematic (RTK) positioning share the core measurement problem. A moving Rover and a known reference station observe satellites over the same period. Their code and carrier-phase measurements allow a processor to estimate the Rover's position relative to the reference. Resolving carrier-phase ambiguities is central to the centimeter-class result; The RTK Trick explains that measurement in detail.
The operational difference is when the answer is due and how the reference data reaches the Rover:
| Workflow point | RTK | PPK |
|---|---|---|
| When the position is needed | During the run, for live navigation or field feedback | After the run, for the final trajectory and review |
| How the reference is used | Corrections must arrive over a live radio or network link | Overlapping Rover and Base/CORS raw observations are processed later |
| What later data can change | The current answer cannot use observations from the future | Forward/reverse processing can revisit earlier weak epochs |
RTK corrections often reach the Rover through NTRIP or radio. Logging is a separate choice: the same receiver can show RTK positions in the field and save observations for a PPK final track. That combination gives a mapping crew immediate coverage feedback and a later chance to revisit questionable stretches.
The saved data must be raw observations. RTK coordinates cannot be turned back into satellite measurements, and a Rover-side recording of received corrections cannot fill a period when the link delivered nothing. Re-solving that interval requires usable Rover observations and an overlapping Base or CORS record. The trade-off is that the final PPK answer waits for those reference data and the later processing run.
Solving With Hindsight: Forward, Reverse, and Combined
Suppose the vehicle passes a difficult intersection at time t2. A real-time filter can use observations received through t2; it has not yet seen that open sky returns at t3. The post-processing engine has the complete recorded sequence. That changes what can be estimated about t2, rather than merely delaying the same answer.
A forward pass processes the survey from start to finish. A reverse pass begins at the end and works backward. Near startup, after a cycle slip, or while the receiver is reacquiring usable signals, those passes may have different ambiguity states and different confidence. The reverse pass can arrive at an earlier weak epoch after passing through later good observations. A combined trajectory can then draw on both directions, with the weighting and quality decisions depending on the processor.
This is a form of hindsight. Later observations can change the estimate of an earlier position. It is not a simple moving average that rounds off a road curve: a GNSS trajectory is constrained by satellite measurements, ambiguity decisions, and the uncertainty assigned to each solution. Forward/reverse agreement is useful internal evidence, especially when examining a jump or a suspicious fixed ambiguity. It is not independent proof of ground truth; both passes can share a wrong reference coordinate or the same corrupted measurements.
The idea also has two layers. With GNSS logs alone, the passes act on the satellite-derived trajectory. If IMU measurements were recorded too, a later GNSS/INS smoother can revisit the estimated motion and attitude between GNSS updates. Post-processing does not merely delay the answer. It lets later observations inform an earlier position.
Is PPK More Accurate? Compare the Whole Trajectory
RTK and PPK are usually in the same centimeter-class accuracy category; a good PPK run can still produce a more dependable final route. If RTK stayed stably Fixed under clear sky against the same reference, post-processing may change little at those best-case points. The opportunity lies in initialization, reacquisition, short signal losses, and sections where the real-time filter was forced to decide before later measurements arrived. There, forward/reverse processing and review can reduce a jump, shorten a weak tail, or recover usable distance. The size of that benefit depends on observation quality and the software's actual processing method. It is not a promise that every PPK point beats every RTK point.
A road-mapping team delivers a continuous route. Its QA should therefore ask where the solution degraded, how long recovery took, and how much of the route met the project's quality threshold. These checks answer different questions:
| Check | What it reveals | What it cannot prove alone |
|---|---|---|
| Fixed rate and recovery time | How much of the route has a resolved solution and where it drops out | That every Fixed position matches ground truth |
| Estimated precision and forward/reverse separation | Weak sections, jumps, and internal disagreement worth inspecting | Absence of a shared reference-frame error |
| Independent surveyed checks | Position error at selected points outside the processing fit | The accuracy of every unchecked feature or timestamp |
As GNSS Accuracy Decoded explains, a solution label and an estimated uncertainty are not themselves measured error. The practical comparison is the dependable length of the final track.
GNSS/INS Smoothing: Using Both Sides of a Gap
GNSS-only PPK revisits the satellite solution. GNSS/INS post-processing also revisits the vehicle's motion. An IMU records angular rate and acceleration continuously. Fusing those measurements with GNSS estimates position, velocity, and attitude, which a mapping vehicle needs to place a camera frame or LiDAR scan in space. Real-time GNSS/INS can propagate through a brief satellite outage, but small inertial errors accumulate as the outage lasts.
Once the vehicle exits a weak area and GNSS improves, the post-processing smoother can use observations on both sides of that area to re-estimate the intervening motion and sensor errors. The result can improve position, velocity, and attitude estimates across a GNSS gap. When timing and mounting calibration are correct, a better attitude estimate can also improve where each captured road feature lands.
An urban canyon and a tunnel are different problems. Between tall buildings, some GNSS measurements may remain, although blocked signals and multipath can make them difficult to trust. In a tunnel, satellite observations may disappear almost entirely; continuity then comes mainly from the IMU and, where available, vehicle motion constraints. The later exit fix helps constrain the reconstructed middle, but it does not create satellite measurements that were never recorded. A long gap, a drifting IMU, or poor constraints still leave uncertainty.
Loose coupling commonly feeds GNSS position or velocity updates into the inertial estimator. Tight coupling can use lower-level GNSS measurements even when they cannot form a complete standalone GNSS position. Either architecture can be post-processed, but neither turns poor sensor data into certain truth. The processing choice and the IMU grade matter most where the satellite track is weakest.
PPK Mapping: From Raw Logs to Road Geometry
Back at the office, the first check is whether Rover and reference observations overlap across the interval that matters. The reference may be a local Base or a suitable CORS station. Its coordinates and coordinate frame must be known; a wrong reference coordinate can shift an otherwise internally consistent route. Beyond WGS84 explains why a precise fix can still miss the intended map frame.
RINEX is a common way to exchange observation files, but changing the file format cannot restore measurements that were never logged. Baseline length matters too: as Base and Rover move farther apart, their atmospheric errors become less alike. Reference data may arrive after the crew returns and can have a limited retention window. Preserve both logs, the reference coordinates, and the processing choices with the job.
The mapping vehicle also records IMU data, dependable timestamps, camera exposure events or LiDAR scan times, and the measured offsets and rotations among antenna, IMU, camera, and scanner. Post-processed GNSS/INS produces a time-indexed position and orientation. That trajectory places a lane marking seen in a camera frame or a road edge measured by LiDAR in map coordinates. An isolated latitude/longitude each second is insufficient: the sensor looks away from the antenna, and the vehicle moves between those seconds.
This is where PPK's field resilience becomes concrete. If cellular corrections disappear while the Rover still records raw satellite observations and a reference logs the same period, the vehicle can continue its capture run and solve that stretch later. The team can also reprocess the complete raw record if it corrects the Base coordinate afterward. By contrast, severe satellite blockage or multipath damages the Rover observations themselves. Downloading a reference file later cannot automatically undo that damage.
A track can look excellent while its map feature is wrong. A camera frame paired with the wrong timestamp moves the lane marking along the route. A bad antenna-to-IMU lever arm shifts the sensor position; a camera or LiDAR boresight error rotates its observations. A Fixed GNSS state proves neither correct time alignment nor correct sensor calibration. Final QA must inspect solution state, uncertainty, jumps, and forward/reverse differences and check selected mapped features against independent survey evidence. Internal agreement cannot catch a shared reference-frame error. Extracting and updating the actual road geometry still happens after positioning.
Another post-processing path
Precise satellite orbit and clock products can support kinematic precise point positioning (PPP) without a nearby Base. That is a different processing path from the differential PPK workflow described here, which uses overlapping Rover and Base/CORS observations. Downloading precise ephemerides alone does not replace the reference observations required by differential PPK.
PPK for UAV Mapping: Precision Without a Live Correction Link
A mapping drone needs accurate photo coordinates for later photogrammetry; it usually does not need each final geotag the instant the shutter fires. RTK can supply a live geotag, but the Base or network correction must reach an aircraft in motion. Range, terrain, and cellular coverage can interrupt that path.
With PPK, the aircraft records raw GNSS observations and exposure events locally while a Base or CORS records overlapping observations. Processing assigns refined coordinates after landing, so a correction-link outage alone need not trigger a repeat flight when both logs are usable. Flight control, telemetry, and safety communications still have their own real-time requirements.
Accurate antenna positions are only the beginning. The exposure event must correspond to the correct photograph and the antenna-to-camera offset must be applied. Where IMU orientation is used, attitude and camera mounting geometry matter too. If the event count and image count disagree, a well-solved flight track can still assign a precise coordinate to the wrong image.
Ground control points (GCPs) belong to a different step. Differential GNSS PPK solves aircraft positions from aircraft and reference observations; it does not take GCPs as input. Photogrammetry first connects overlapping images through matched features, then uses photo positions during bundle adjustment. Surveyed GCPs can additionally constrain that adjustment and its geographic frame. A well-executed PPK image set may not need GCPs to participate in the adjustment, but local bias or a required project frame can make them useful.
The same surveyed marker cannot tune an image model and then serve as an independent test of it. A road vehicle needs a continuous timed trajectory; a drone needs the right position on each exposure. Their inputs enter different steps of the mapping workflow:
| Input | Processing step | Role in the deliverable |
|---|---|---|
| Aircraft GNSS + overlapping Base/CORS observations | Differential PPK | Solves the flight trajectory and exposure positions |
| Surveyed GCPs marked in images | Photogrammetric bundle adjustment and georeferencing | Constrains the image model and its coordinate frame |
| Independent checkpoints | Final product QA; excluded from adjustment | Tests the orthomosaic or model against surveyed coordinates |
Separate checkpoints should test the delivered orthomosaic or 3D product. In both road and UAV mapping, the map deliverable is the test.
The Best Position May Be the One Finished Later
RTK gives operators a position they can use in the field. PPK works from the completed observation record to produce and inspect the final track, without requiring the live correction link to stay up for the whole run. Forward/reverse processing and GNSS/INS smoothing can strengthen weak sections, while a clean Fixed RTK section may see little change. Using RTK for field feedback and PPK for the delivered route is a practical combination.
Trust in a mapped road or UAV product still rests on complete observations, the right reference frame, independent checks, and correct alignment between trajectory and imagery or point cloud. A convincing solution-status label alone cannot certify those later steps.
Key Takeaway
RTK makes a position useful now. PPK makes the recorded journey available for a better-checked final trajectory.
Frequently Asked Questions
Is PPK more accurate than RTK?
Both commonly deliver centimeter-class positions. PPK can use later observations, forward/reverse processing, and post-run QA to improve some weak parts of a trajectory. A consistently Fixed RTK section may change little, and no PPK processor is guaranteed to outperform RTK at every point. Compare difficult sections and independent checkpoints across the full route.
Can PPK work when the live RTK correction link drops?
Yes, if the Rover keeps recording usable raw GNSS observations and overlapping Base or CORS observations are available for later processing. A lost correction link does not erase locally logged satellite data. Severe satellite blockage or multipath is different: later reference data cannot automatically repair bad Rover observations.
Does PPK need a base station or CORS data?
The differential PPK workflow described here needs overlapping raw observations from the Rover and a known Base or suitable CORS station; you do not necessarily need to set up your own Base. If you have no local reference observations and instead use precise satellite orbit and clock products, that is generally a kinematic PPP workflow—a separate path from differential PPK.
Can RTK and PPK be used on the same survey?
Yes. RTK supplies live position and quality feedback, while the equipment simultaneously saves Rover raw observations for a later PPK solution using overlapping reference logs. Saving only RTK coordinates, or only the correction stream received by the Rover, does not preserve the missing information from a correction-link outage.
Does a PPK drone still need ground control points?
GCPs are not inputs to the differential GNSS PPK calculation. They can constrain the later photogrammetric bundle adjustment and georeferencing, although a strong PPK image set may not need them for every project. Keep separate checkpoints out of the adjustment to test the orthomosaic or 3D model independently.
What happens when satellites disappear in a tunnel?
GNSS-only PPK cannot reconstruct a trustworthy tunnel track from satellite observations that do not exist. A logged GNSS/INS system can propagate with its IMU and later smooth the gap using GNSS before entry and after exit. The result still depends on gap length, IMU quality, and any vehicle-motion constraints.
Continue exploring
GNSS Errors Mapped
See which errors a reference can reduce and which remain local to the moving receiver.
LateralRTK Accuracy Trap
Test what a Fixed status and an accuracy estimate mean in real field conditions.
ApplyRTK GPS for Robotics
Apply correction continuity and re-fix behavior to moving outdoor systems.
