The same story, over and over. A surveyor drives two hours to a remote site, sets up their equipment, starts capturing - and then spends the next hour troubleshooting a dropped NTRIP connection or a flaky link to a local base. Or they get back to the office and realise the intermittent corrections have compromised their georeferencing. The data is there, but the quality isn't what it needs to be.
What struck me was how much of that pain is avoidable. The underlying GNSS data is being logged. The SLAM is working. The scan is good. The problem is a communications dependency that we can engineer around - and that's exactly what PPK does.
RTK - Real-Time Kinematic - is the traditional approach. It works by streaming live correction data from a base station to your rover while you're capturing. When it works, it's excellent. But it depends on a stable, low-latency connection in the field, and that's a big ask in remote areas or anywhere with long baselines or terrain blocking your signal.
PPK - Post-Processed Kinematic - flips the model. Instead of computing corrections in real time, you log the raw GNSS data during your mission and process it afterwards. The accuracy is equivalent - you're still getting centimetre-level georeferencing - but you've removed the connectivity dependency entirely. The field work and the processing work are decoupled, which changes a lot about how you plan and execute a survey.
How does it work within Aura specifically?
During capture, your GNSS receiver logs raw GNSS observations alongside your LiDAR and IMU data as usual. Once you're back from site, you bring in your base station data - whether that's from a local base you set up, or from a nearby CORS station - and process these corrections using RINEX processing software to deliver a georeferenced trajectory. That corrected trajectory is then fused with Emesent SLAM to produce a georeferenced and corrected point cloud output.
The key thing is that the quality of your georeferencing no longer depends on what was happening with your signal during the scan. You're working from the full logged dataset, processed under controlled conditions.
Yes - PPK support in this release applies to ground-based scanning workflows only - specifically when used in handheld, survey pole, backpack, or vehicle-mounted configurations. It is not currently supported for drone deployments. If you're flying Hovermap on a UAV, your georeferencing workflow remains unchanged for now.
The other thing to note is that PPK still requires base station data for post-processing. You either need to log data from your own base during the scan, or have access to a CORS station within a reasonable baseline distance. It removes the real-time comms dependency - but it doesn't eliminate the need for a reference source altogether.
Remote and regional surveying is the obvious one - anywhere cell coverage is patchy or CORS networks are sparse. We also hear a lot from teams working in open pit and surface mining environments where long baselines make RTK unreliable.
It's also worth mentioning that PPK support extends beyond Aura in this release - Commander 2.3 has been updated to support PPK workflows as well, so the end-to-end experience is consistent across the platform. It's a good example of how these tools are designed to work together rather than in isolation. I walk through the entire PPK georeferencing process, from field capture to point cloud, in this How To video.
More broadly, I think it gives surveyors back something they shouldn't have had to give up in the first place - confidence that the data they're capturing is going to be usable, regardless of what the signal is doing.