Nyx to permit Real Time PPP

[gwbres]

One GNSS application of the Nyx core is high quality orbit prediction to allow real time PPP.
It will be the first "real time" navigation mode I propose, the form is not clear yet, as discussed down below.

When solving rovers location, several approach exist and they can be reduced to the input available to the user and the targeted accuracy of the solution.

PPP (positioning algorithm) targets 0.1 to 0.01 accuracy, with the huge advantage over RTK being that it can be deployed anywhere in the world. While RTK achieves 0.01 accuracy much more easily but requires to be located nearby a reference station (10km is about the maximal tolerated baseline).

Anywhere in the world, but not any time. If you’re not familiar with the input products we work with, this table summarizes them all:

The availability of the NGS SP3 products is invertly proportional to the quality of the orbital fit, therefore the error to the actual satellite location, therefore the error in the resolved position. We will arm the Nyx propagators on either a daily or hourly SP3 (post processed but quickly available, so propagation time kept to a minimum), and enable real time ppp, as we keep sampling the signals

Inner workings

rinex-cli is my current application, it allows post processed positioning and will allow post processed RTK very soon.
That means the input are files - SP3 possibly one of one as of today, and we do not handle hardware sources.
The more I think about it, the more I lean towards opening a new application dedicated to real time navigation, and rinex-cli would therefore be dedicated to post processed. Although, I also like the idea of "one tool to do it all".

Real time navigation requires interfacing to hardware.
Real time PPP solely requires one receiver, therefore it will come first.
Real time RTK requires one receiver and network interfacing, therefore it will come in second.

Roadmap

I'm concluding the PPP mode the next few weeks, which is the most complex topic - anything afterwards will only be pure fun.
Then I will add the rtkpost option to rinex-cli, which will take about 2 to 4 weeks, is not very complicated.
Once concluded, this will be my main focus

[ChristopherRabotin]

This sounds like a superb idea, I like it a lot. I'm not entirely sure however what are the inputs and the outputs you'd expect from this tool. Is the idea that the input is the SP3 data (provided by rinex?) and some signal data, and estimated location of the receiver on the ground? Then, if I understand correctly, Nyx would calculate the estimated position of the the GPS spacecraft at a future time t', and a Kalman filter will be used to correct the location of the receiver on the ground (or is that whole sentence the PPP algorithm?)? What would be the final output of this tool?

The reason I ask is because I wonder what amount of the computation happens in Nyx and what amount happens in rinex or in this tool. Also, I don't think Nyx should be parsing the SP3 files directly because Rinex does this, but Rinex also uses Nyx as a dependency, and we must avoid circular imports, i.e. this tool you talk about may need to be independent from both Rinex and Nyx.

[gwbres]

To create the function, we combine 4 libraries: SP3, Nyx, RTK-RS and Ublox.
All we need from nyx, is to create a propagator and iterate it.

The SP3 delivers a serie of SV(x, y, z)(t) until t=T0 the last Epoch described.
We happen to prefer daily or hourly SP3 files, to minimize the Epoch gap we need to iterate, but that is a user decision, it remains a standard file.

Nyx is initialized on the SP3 database and we need it to now ship SV (x, y, z)(t') now that t' is > T0.
t' also happens to be now in the real-time navigation. SV(x, y, z)(t') is one of the input of the RTK-RS API.
At some point, when a new hourly or daily SP3 is officially made available, we want to re-initialize the propagator to maintain reasonnable propagation performances - is that feasible ?

In parallel we use the ublox as real time ephemerides and observation source, to form a Candidate in the RTK-RS API, it is the other required input. The actual solution calculation is done by rtk-rs, which can deploy the PPP principle from these two input and obtain the solution a t' (=now). The navigation filter (in the PPP solving, not SV propagation) also happens to be a KF, typical navgation filter, that is handled by RTK-RS (as any other navigation related calculations)

[ChristopherRabotin]

Okay, that's easy enough. Nyx can trivially propagate many spacecraft at once from an initial state using high fidelity dynamics. It could either build a predictive ephemeris file or it could just return the future state, whichever is preferred.

[gwbres]

many spacecraft at once from an initial state

That is indeed a requirement

It could either build a predictive ephemeris file or it could just return the future state, whichever is preferred.

We will only use files as input (initializer), we just need objects and points in the real-time apps. But the capabilities to predict ephemeris might offer some more advanced options. First we should compare the propagated state to the actual state, that we resolve from the real-time keplerian parameters being streamed.

The other ''problem'' in real-time navigation is the time to first fix, which is limited by the gathering of the ongoing ephemeris information (simple need to wait for the radio messages). The only field I know for sure, is the "second of the week" (SOW) which permits the decoding of the pseudo range code. I doubt we can predict the SOW value, but I cannot say for sure. The pseudo range is mandatory to all position algorithms I know, even PPP.

[ChristopherRabotin]

How is the SOW used to decode the pseudo range code ? Is the pseudo range data actually encoded from the SOW value, or does it just depend on it?
In orbit determination, we typically take the predicted spacecraft trajectory (we covers several days) to start the filter. Then, for each real measurement, we propagate the best estimate of the spacecraft trajectory to that measurement time, and compute the expected measurement if our estimate was correct. The difference between the real and the expected measurement is the "innovation factor", and it's used by the filter to correct our state estimate.

[gwbres]

This is beyond my knowledge and usage, therefore cannot answer completetly.
The pseudo range is not encoded from the SOW value, the SOW value allows complete interpretation of the pseudo range.
The pseudo range decoding process comprises the phase locking (alignment in time) of a local copy of a pseudo random sequence, with a delay line and at some point, you need a reference point in time to fully interprate which frame corresponds to which period and recover the transmission time (which gives you the range, since c is constant). This is what the SOW field helps with