What does prx do?

GNSS receivers typically output both

• An internally computed PVT (position, velocity, time) estimate
• Slant observations of pseudorange, carrier phase and Doppler along with the decoded satellite navigation message

Using the receiver's PVT estimate is convenient, but not very useful for more interesting estimation schemes such as tighly coupled fusion with an inertial measurement unit or even GNSS-only differential positioning.

Using a GNSS receiver as a sensor outputting slant obervations has a few particularities that makes it a bit challenging to use in practice:

• We use both the receivers ranging observations and the satellites' state - their position, velocity, clock offset etc. - to estimate the receiver's state. The satellite state is however output by the receiver as ephemeris parameters; it is up to the user to compute satellite states
• A lot is constellation-dependent, such as time scales and ephemeris formats

RINEX 3.0x and SP3x are today's de-facto formats for GNSS observation, clock and ephemeris exchange. For a standalone user who wants to estimate a receiver's position in postprocessing, the typical steps are

• Parse RINEX observation file(s)
• Parse RINEX or SP3 ephemeris & clock file(s), if precise orbits and clocks are desired
• Compute satellite positions & clock offsets, applying each constellation's interface control document (ICD)
• Run state estimator with these inputs

The goal of prx is to replace these steps by

• Process RINEX observation file with prx once (broadcast ephemerides and sp3 precise solutions are downloaded automatically, if not provided)
• Parse the resulting files (CSV or JSON, or both) to get observations and satellite positions & clock offsets, both precise and broadcast
• Run position estimator with these inputs

In more general terms, the idea is to move as many processing steps as possible into the prx tool to leave the user more time to focus on the interesting stuff.

No loss of information

We need to make sure that we do not drop any information that forces a user to go back to the input RINEX/SP3 file to retrieve it.

No new standard

We do not want to introduce any new conventions, but instead re-use wherever possible existing ones, such as three-letter RINEX signal codes to make it easy to use the preprocessed files for someone familiar with RINEX.

Constellation-independent?

We want to abstract away differences between constellations as much as possible.