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 not feasible using the following constellations
- IRNSS
- Glonass
- QZSS
- SBAS
Use the proposed filter to filter out those constellations.
Note that QZSS is to be supported very soon, the others will come after that.
Also note that this toolkit has been extensively used with GPS and a little bit of Galileo. We sill have to thorouhgly use Galilo and get started with BeiDou. Any help is welcome.
Use the Rust logger (see other introduction pages) to truly understand what's happening.
It is important to pay attention during initial phase, the solver will let you know if the provided
data is somewhat strange or could be improved.
The solver will always let you know when something's wrong, especially why it failed to produce a solution.
For advanced user, the solver will easily emphasize which Epoch it is targetting, the current orbital and temporal context and also signal quality.
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.
Use the preset we propose in this toolbox to get started and tweak them.
The preset are located in rinex-cli/config/rtk and are formatted in JSON.
Unfortunately commets are not allowed in JSON, therefore you have to refer to this Wiki page to truly understand them.
GPST_SPP_BASIC.json is the ""most"" basic configuration, the method is SPP, interpolation order is compliant
with complete 24h RINEX observation (reduce that if need be). All compensations are activated as we aim towards
high accuracy. Remove one of them to see how this physically impact the solutions.
gpst_ppp_basic.json si the basic PPP configuration. It is the exact same configuration as the previous one,
but the method is switched to PPP. Use this one to compare both methods.
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.
"SPP" is define in the "Method" field of the configuration setup.
We currently propose a Code based PPP positioning method. In this case, the Ionospheric bias is measured and no longer modeled. This is the best thing to do regarding this topic and it actually saves calculation time.
Code based PPP will present similar results to advanced SPP.
RINEX-Cli can express PVT solutions as CGGTTS files for remote clock comparison,
for so called "time transfer" technique.
