Multi-GNSS, Timescale support & Absolute time

[gwbres]

Mutli-GNSS, Timescale Transposisions & Absolute Time correctness

The following is my validation run of the new Hifitime (pending v4.1) + RTK-rs framework (pending rtk=v0.8 and cli=v0.13).
ANISE impacts our framework as well, but the initial rotation (as of today) is made manually by gnss-rtk, so we solely rely on the fact that ANISE treats the epoch as is and correctly, which is true.

Although this topic is rather easy for one who understands navigation and the principal of measurements, it depends on many interdependent subtil aspects. In particular:

• Timescale support: the capability to express a duration within a specific space time.
  Although the following only applies to the most basic timescales like GNSS.
  Advanced timescales like TDB do not apply or will not be tested.

• Constellation support: capatiblity to differential spacecrafts and relate
  them to a timescale.

When I say navigation, I mean solving x, y, z and dt absolute coordinates of a target in space time, where dt is expressed in a selected timescale. Until today, navigation was only feasible in GPST and measurements had to be expressed in GPST.
Selecting other timescales would lead to temporal corruption (correction not handled by the framework).
Injecting measurements in something else than GPST was totally forbidden.
Mixing constellation could only lead to corruption of the dt coordinates.

The most complex use case we will deal with here is UTC timescale, because:

• it is very different from other GNSS timescales (leap second, big gap)
• it is not a GNSS timescale, so it requires a conversion on the input side

but we come in a time where Hifitime supports all of that gracefully and correctly, so that did not cost any effort.

The test script is rinex-cli/demos/ABSOLUTE_TIME.sh (bash) and only deals with RINEXv3.
Other tests will be done later using RINEXv4 or other timescales.

Requirements

• Hifitime v2 + ANISE /dep/hifitime
• entire framework reindexed to this branch
• Observation RINEX files (=measurements) published by IGS and expressed in GPST by default.
  Although that would totally be valid, I have never seen general public providers like them, express their measurements in other timescales.
• I developped two new options in rinex-cli app to forge test data and unlock many possible combinations, and work around the previous point. Although, these operations rely on the topic being validated here.. At least it allows testing all scenarios

Initial setup

The initial setup is measurements in GPST (untouched) and navigation (resolution) in GPST (no conversion involved).

GPS measurements & navigation

When working with GPS:

• -P GPS for GPS Only navigation
• -P GPS,xxx for Mixed GPS navigation
• --fp data/CRNX/XXX to inject the GPST measurements
  • untouched input product
  • no transposition involved in the process
• --fp $test.rnx to inject the GPST measurements transposed to other timescales
  • transposed input product
  • transposition required on the input side
• -c gpst_xxx.json used to request GPST solutions
  • no transposition involved
• -c xxx.json used to request GST or UTC solutions
  • transposition on the output side

Galileo measurements & navigation

When working with GAL:

• -P GAL for GAL Only navigation
• -P GAL,xxx for Mixed GAL navigation
• --fp data/CRNX/XXX to inject the GPST measurements
  • untouched input product
  • transposition involved on the input side
• --fp $test.rnx to inject the GPST measurements transposed to other timescales
  • possible transposition on the input side
• -c gst_xxx.json used to request GST solutions
  • no transposition on the output side
• -c xxx.json used to request GPST or UTC solutions
  • transposition on the output side

UTC measurements & navigation

When working with UTC:

• --fp data/CRNX/XXX to inject the GPST measurements
  • untouched input product
  • transposition involved on the input side
• --fp $test.rnx to inject the GPST measurements transposed to UTC
  • possible transposition on the input side
• -c gst_xxx.json used to request GST solutions
  • no transposition on the output side
• -c xxx.json used to request GPST or UTC solutions
  • transposition on the output side

Test summary

Only a few cases reported here, check the test results

Navigation	Measurements	Solutions	x, y, z	dt	Status
GPS	GPST	GPST			Reference ✔️
GPS	GST	GPST			x, y, z unchanged ✔️
GPS	UTC	GPST			x, y, z unchanged ✔️
GAL	GPST	GPST			Unexplained Higher accuracy. Accepting so, dt seems similar in shape ✔️
GAL	GST	GPST			x, y, z, t unchanged ✔️
GAL	UTC	GPST			x, y, z, t unchanged ✔️
GPS+GAL	GPST	GPST			x, y, z and t all better than GPS only case (as expected) ✔️
GPS+GAL	UTC	GPST			x, y, z unchanged: transposition OK, t unchanged: transposition OK ✔️
GPS+GAL	GST	GST			Unchanged x, y, z: transposition is correct. Hifitime limitates the T solution difference ✔️
GPS+GAL	UTC	GST			Unchanged x, y, z: transposition is correct ✔️
GPS+GAL	GPST	UTC			Unchanged x, y, z: transposition is correct ✔️
GPS+GAL	UTC	UTC			Worst case, both transpositions work, x, y, z are identical ✔️

Due to the very tight difference between those timescales and 1ns limitation in hifitime, it is not possible to really see a true difference in the temporal solutions (1-2 nanoseconds difference at most).

Conclusions

1. Timescale support is correct. Hifitime offers many timescales correctly and conveniently
2. RTK-rs supports many constellations correctly and conveniently
3. Precise timescale transposition works as expected: upgrade seems OK.
   Unfortunately, I can only demonstrate this by transposing my measurements and obtain similar x, y, z geometry.
   But still, that is a valid case.
4. UTC support is correct (which is the most complex tested today)
5. We now tolerate measurements expressed in any timescales
6. Multi-GNSS is now conceivable

Work that remains to be done

• Improve hifitime accuracy and rerun if accuracy is ever improved
• Run this with BDT (find some data)
• Support indirect correction by means of recombination
• Run this using RINEXv4
• Study Clock RINEX and possible UTC(k) cases

[ChristopherRabotin]

Guillaume,

Will the code for this verification be made public? I'm especially interested in seeing how the rotation is done outside of ANISE, and determine whether this is something that ANISE should support.

Thanks

[gwbres]

Oh it already is, and we've actually discussed that step recently in #399 on the ANISE side

Here https://github.com/rtk-rs/gnss-rtk/blob/main/src/pool/mod.rs#L98 we are gathering hopefully 4 satellite observations, that means determine 4 orbits. TX epoch, is "simply" RX epoch that we have translated back in time a little bit (~80ms for GNSS). We want the Orbit at TX epoch, RX epoch would be a false delay introduction. The user provides it (usually by solving kepler equation). Now you have this orbit at TX and your measurement system is at t RX. You need to rotate the RX measurement system in opposite direction of the planet rotation, to align it where it was at TX. Otherwise, you introduce an eastern bias of about 10m in GNSS. This is the rotation I am talking about, and the only rotation gnss_rtk handles itself. If I understand the current state of the code, you can see I do the rotation myself, and build a complete new Orbit, and force "t(=rx)" to remain. It's a "trick" I use to have the satelltes and the measurement system at the same time so ANISE continues working. It would make more sense to have everything expressed now at TX.

What i'm trying to emphasize in the introduction, is that the PVT solutions can only be obtained by exploitation of the entire fraemwork. ANISE+Hifitime are not enough, RINEX is far from enough. So we have building blocks, validated at their level, to eventually create that kind of capacity.

What stands out from this first test is that measurements can be expressed in any timescale. And measurements impact the navigation very much, to maintain identical final coordinates means something.