positioning
Precise positioning is one of the most major opmodes of RINEX-Cli.
RINEX-Cli combines the RINEX core library and the RTK-rs position solver to create a very efficient and powerful interface.
Post processed precise position is requested with -p.
The objective here is to locate the GNSS receiver with the highest accuracy.
The output are called PVT solutions for Precise, Velocity, Time solutions.
RINEX-Cli currently only applies to static and geodetic positioning, where the position of a single receiver is known ahead of time (usually by means of a geodetic survey), and we use that position to compare how well we perform. Soon (once PPP is fully stabilized) we will unlock dynamic positioning (roving) and will improve how to manage a possible reference point (geodetic survey).
Post processed positioning either deploys in default configuration,
or using a custom setup that is defined with -c. Either way,
the logger will let you know the configuration that is being used.
User interested in solving (precise) positions, must comply two requirements:
- provide the required input data (basically, form a correct context) for the desired algorithm or solving strategy. PPP has more stringent requirements, while SPP will work with just GNSS signals observation and orbital information (so basically one OBS and one NAV file).
- the provided data quality must comply with the targeted accuracy. High quality data is required for PPP to truly work. Running SPP on high quality data will exhibit very performant result as well. Poor quality of data will dramatically reduce the output accuracy you can reach.
To verify the quality of your context, the -Q Quality Check opmode is there.
To define the reference point (that we also refer to as the "apriori position"), we have two options
- most of the time it is defined in the input RINEX. In this case you don't have anything to do, we pick it up automatically.
- or you can manually specify it with the
--apriorioption.
To determine whether it is contained in a RINEX context, you can first run a couple of
the analysis we propose, or try a -p run and read the logs.
The minimal requirement for this tool to produce solutions, will always be at least one Observation RINEX and one Navigation RINEX. The optimal context will always be to couple these files to one related SP3 and Clock RINEX files. In this case, you are forming a 100% PPP compliant context. This truly help us (even computation wise) to generate PVT solutions.
The position solver generates several plots (in HTML) that represent the PVT solutions.
The most important ones are the world map centered around the position and the receiver clock offset.
PVT solutions are also wrapped as CSV to be easily exported to third party tools.
The solver has resolved positions that we project on a world map
We also project the position errors between the resolved PVT and the user guess, in 3D
The receiver instantaneous X, Y, Z velocity components are presented in separate plots:
TODO.
TODO: add illustration
T in PVT is the receiver clock offset to the selected timescale, which we present in a dedicated plot:
⚠️ Navigation is currently limited to GPS vehicles, this reduces the type of data you can inject into this tool.
This ecosystem prefers accuracy over calculation time. One possible usecase is to downgrade the default setup (use custom settings), to reduce calculation time a little bit. Another usecase is to reduce the interpolation order, especially when using short RINEX (like only a few hours of observation). This is not needed when using complete 24h RINEX files.
So called Single Point Positioning (SPP), which is kind of poorly named, is supported by this toolbox.
We recommend becoming familiar with SPP prior moving to PPP, especially if you are new to precise positioning.
RINEX-Cli is preset to PPP by default, you can "downgrade" to SPP by combinding --spp to the -p opmode.
PPP is currently under development
RINEX-Cli can express PVT solutions as CGGTTS files for remote clock comparison,
for so called "time transfer" technique.
