Introduction
In my last post, I talked about the "overwhelm" of starting a sensor fusion project. A big part of that initial confusion was simply understanding the data I was supposed to be fusing. It felt like being handed three different maps, each in a unique language and coordinate system, and being told to navigate with them simultaneously.
Before I can even think about fancy algorithms, I need to get the basics right. And that starts with the inputs. So, let's break down the three key file types that are the lifeblood of my project's current phase: the trajectory file, the SP3 file, and the APC file.
Think of this as a prelude to the "GNSS Measurement Engine" I'm building. You can't build an engine without knowing your fuel.
The Rover's Truthful Diary: The Trajectory File
This file (traj_file) is my ground truth, the rover's honest log of where it actually was at every moment. In a real-world scenario, this would come from a highly precise, survey-grade GNSS system. In my simulation-driven stage, it's the absolute reference.
You'll typically find it as a simple text-based file (like CSV) with columns for a time stamp, position (X, Y, Z coordinates or Lat/Lon/Height), and often attitude (roll, pitch, yaw).
Its core purpose is to be the answer key. When my GNSS engine starts estimating positions, I will compare them against this diary to calculate error and validate my system's accuracy. Without this truth, I'd be navigating completely blind.
The Satellite's Precise Dance Card: Navigating SP3 Files
To figure out where you are, you first need to know where the satellites you're listening to actually are. That's where the SP3 file comes in. This file, whose name stands for Standard Product 3, contains the precise orbits of GPS and Galileo satellites.
It’s a standardized text file that acts as a dance card for each satellite, listing its exact position (X, Y, Z coordinates in kilometers in an Earth-Centered frame) and clock correction for specific times.
Using rough, broadcasted orbits introduces significant error. The SP3 file provides "precise orbit" data, which is non-negotiable for high-precision positioning. My engine uses this to get the true source locations for all its calculations.
The Millimeter Adjustment: Correcting with APC Data
Precision is in the details. The position in the SP3 file is for the satellite's center of mass, but the radio signal is generated from its transmitting antenna. The physical offset between these two points is the Antenna Phase Center (APC).
The apc_data file, often from the International GNSS Service (IGS), contains a table that maps satellite types to their specific antenna phase center offsets. It gives us a vector (dX, dY, dZ) to correct the mass-center position and find the true point of signal transmission.
For a basic system, you might ignore this. But for the precision I'm aiming for, these millimeter-to-centimeter corrections are a critical step in reducing systematic errors and respecting the underlying physics of the problem.
Synchronizing the Flow
So, here's the initial data symphony for my GNSS measurement engine: The traj_file tells me where my rover was, the sp3 file tells me where the satellites were, and the apc_data refines those satellite positions to their exact transmission points.
My engine's first job is to consume these three inputs and generate the fundamental "pseudorange" measurements (the estimated distances that form the core of all subsequent positioning math).
Understanding these files wasn't just a bureaucratic step; it was the key to unlocking the entire problem. It transformed the "black box" of GNSS into a structured data processing pipeline.
Now I'm curious for those in the field: Are there other foundational data sources or correction files you found indispensable when building your first positioning engine? What's the one "gotcha" in these standard files that tripped you up? Let me know in the comments.
Top comments (0)