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.
Its objective is to resolve Position Velocity and Time (PVT) solutions with high accuracy.
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. Once PPP is completed (current work in progress), we will start by unlocking dynamic positioning (roaming) and allow the possibility to present the solutions without the position known ahead of time.
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 coordinates, either with
--rx-geofor coordinates expressed as Latitude and Longitudes DDEG, or--rx-eceffor coordinates expressed as ECEF [m] WGS84.
To determine whether a refernece position is described in your context or not, you can run a couple of our analysis 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 framework allows expressing the final clock offset in any desired TimeScale.
This is set by the TimeScale option of the Config script.
This is useful for example, to express solutions as UTC and not GPST.
Depending on the Constellation you want to work with, some limitations will apply.
Note that this framework currently garantees sane results in GPS and Galileo. We are currently working on unlocking QZSS and BeiDou.
For PPP the best scenario is to work with GPS, Galileo or Glonass, considering the IGS/NASA high precision products are available for all of them.
When working with BeiDou (BDS), SP3 and CLK RINEX products do not seem to exist.
If you know how to gather such data, please let us know.
If that is true, that means you are limited to broadcast Radio navigation and solutions
will be degraded (not fully PPP compatible).
Precise positioning and therefore, advanced solver strategies, required good quality data and more signal observations. For example in Code PPP (CPP) we need pseudo range observations on two separate frequencies. In PPP (so called Precise Point Positioning), we need pseudo range and phase observations on two separate frequencies.
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 X, Y, and Z 3D error and 3D velocity errors are also presented in separate plots. This is the best option to visualize precisely how good we are performing
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.
