Hifitime V4 + Nyx V2: high precision static surveying

[gwbres]

The upgrade to Hifitime V4 and Nyx V2 has kept all its promises and gives us the best results ever achieved.

We're still not 100% there yet, we still have a few topics to fix as I'm writing, but most of the upgrade has been stabilized. The following results demonstrate the quality of the new version of the nyx-space tools and the introduction of ANISE.

The following are extracted from two analysis performed by rinex-cli (application). These capabilities are still under development and result from 3+ months of work. The idea is to wrap all our capabilities in a single, coherent and powerful analysis report. One can see this as a complete geodetic report, but it is broader than simple navigation applications, for example it may apply to atmospheric condition analysis. In this demo, the report is customized with PPP solutions and CGGTTS solutions

# This has not been merged yet
git clone https://github.com/georust/rinex -b sbas
cargo build --all-features --release
# Static surveying of this station, 
# geostationnary vehicles are not considered in the navigation process yet, only in preprocessed analysis (ongoing work).
# In this demo, we perform one analysis and attach PPP solutions (high precision post processed navigation).
# Then, a secondary run is deployed to attach CGGTTS solutions (common view timing)
./tutorials/GAL+SBAS/esbjrg.sh

# Same run, this station happens to be very close to the latter, 
# it has similar setup and sees the same sky conditions
./tutorials/GAL+SBAS/mojn.sh

This is static surveying, the target is static and we resolve a position and local clock time without apriori knowledge: which is the most challenging. This is typically required by stations that want to serve as actual reference stations.

Summary report

The reference position (red dot on the map projection) is the position the station surveyed itself (profesionnally) and most likely streams over the network for RTK

PPP summary report

These examples use Galileo MEO solely, we're current unable to use GEO vehicles in the navigation process due to limitations in the rinex-cli interface to gnss-rtk

Residual Spatial error / coordinates

Error between our survey and the station official survey (professional solution?).

Esbjerg DNK:

Mojn DNK:

Clock offset

Absolute offset between the local clock and GPST, resolved by PPP navigation

CLK (ESBJRG)

CLK (MONJ)

REFSYS is once again the absolute offset to GPST, but obtained by special 16' CGGTTS smoothing.

REFSYS (ESBJRG)

REFSYS (MONJ)

The consistancy in the REFSYS offset between all vehicles demonstrates the coherency of the navigation process (gnss-rtk), the timing calculations and referencing to GPST (hifitime). The consistancy between the CGGTTS and the PPP solutions confirms the PPP solutions as well.

More info

• ESBC00 (Denmark) reference station
• IGS Reference stations network

Congrats

for all your work and I look forward to putting ANISE to greater use. It can already replace the last attitude calculations that we have in a few places, I will try to do that soon

[gwbres]

I'm in the process of upgrading the GNSS toolkit to use the Orbit object (from ANISE) for anything releated to orbital states.
This removes a few dependencies, simplifies the interfaces and also expose the deep functionalities that Orbit may offer.
It's not 100% complete, I'm in the process of upgrading the high level methods, but the gnss calculator is already upgraded.
Now that i've done that, it seems we're getting slightly better results. The filter has more tendency to converge towards something coherent. But it seems to start farther, i'm not sure what would be best, I'd like to only expose the best part of the process!

This is the exact same survey (./tutorials/GAL/esbjerg-brdc):

I don't think we've ever had DOP below one, which is said to be the marker of geodetic performances

The granularity on clock offset is still 1ns (jumps you can see here)

Post CGGTTS fit is even smoother and looks great

its derivative starts to show tiny values

[ChristopherRabotin]

This is super encouraging! Just to be sure, you're using a least squares filter, right? If so, it's surprising to me that there would be such a big difference in the initial state error and the subsequent state errors, but I'm not very well versed in least squares estimators, so maybe it is to be expected.

[gwbres]

I agree with you that the first few iterations behave blatantly different than following others, it is very clear when you look at the geometric error (any DOP) and also the resolved clock profile.

For me the main topics that need to be investigated, some or all of them may impact:

1. Increase the Matrix size from 4x4 to possibly NxN.
   Currently, my solver is fixed to 4x4, which means we only use 4 SV (yet very well selected) to navigate. This means we cannot "over estimate" the problem: we have the bare minimum input to resolve a 3D problem. Increasing to NxN will improve the geometry of the solution (DOP).

2. Investigate the first iteration.
   Similarly limited to 4x4, we could increase the first special iteration to NxN which will obviously increase its quality.

3. Initial solution confirmation.
   Currently, once it is possible to resolve an initial position (usually quite rapidly..) it is considered as initial solution.
   We might need to introduce some criteria to confirm or invalidate possible low quality initial solutions. We might then start closer.

4. Implement proper KF (following your question).
   This was a KF. It is badly operated with unitary Q matrix, to my understanding, this will anhiliate the capability of the KF to predict.
   Following

5. Investigate where the tiny glitches come from, see around MDJ=59025.20, 59025.5, 59025.8.
   I suspect this comes from an SV going out of sight and a new SV appearance, with respect to being limited to 4x4

6. Improve the solution analysis, study and confirmation process

7. Describe the input Orbit more precisely.
   Currently we're making tiny errors because we inject Orbits that are expressed in the ECEF that v0.4.2 proposes, while they should be expressed with specific ellipsoid shape (for example, WGS84)