Introduce Epoch::precise_timescale_conversion

[gwbres]

• Introduce Epoch::precise_timescale_conversion
  • supports both forward and backwards conversion
• Introduce Polynomials for interpolation terms description
• Add one example
• Add one test

[gwbres]

The fundamental idea, is that Hifitime is responsible of the calculations, while the user is responsible for Polynomials correctness. All we can verify is that it is an actual transition. That is, target is not the origin timescale.
Which is also kind of silly, because a null correction is still a valid correction.
I'm reaching the conclusions we should not guard anything and expect the user to know what they're doing.

[ChristopherRabotin]

This is superb! Really good work, I just have minor comments and cleanups, but I really like this implementation. Does it fit your purpose with GPST corrections?

[ChristopherRabotin]

For what reasons should we limit it t one day in practice?

[gwbres]

the equations apply at all times and remain valid.

In practice, especially when targeting high accuracy, you want to keep your residual error small, and it is said to grow rather fast when it comes to clock behavior. RINEXv3 (NAV) describes polynomials (like GPST-UTC, GST-GPST, BDT-GST, TAI-UTC) for 24 hours. And people have been using it for many years and still to this day. Personnally I'd consider that huge but whatever. It simply means as the day goes by, the error when you convert for example GPST to UTC grows. Now they have "invented" RINEXv4, which allows to update these corrections during the day, so you can maintain the error to a minimum.

Side note, I'm still not very familiar with Clock RINEX, but I think it describes TAI-UTC and can describe UTC(k)-UTC and UTC(k)-TAI, for example k=USNO.

The only thing that is fundamental, is the time interval needs to be expressed in the LHS timescale.
In GGTO=|GST-GPST| example, GPST is the reference, so LHS is GST. Apparently that remains true even in reversed equation, but I'm not 100% sure about that, and I have a hard time finding documentation. I think my implementation is correct, src/epoch/l225 : reference_epoch = reference_epoch.to_time_scale(self.time_scale), assuming self.time_scale is LHS and user did the right thing.

[ChristopherRabotin]

I think we should introduce a new enum type for this case, maybe InvalidTimeScaleConversion? The enum is marked as non-exhaustive already so it would not be a breaking change.

[gwbres]

I am not sure what the right thing is honestly. The fundamental thing is we need to be certain that the time interval should always be expressed in LHS domain.

[ChristopherRabotin]

I think that's fine as-is,m just with a different enum variant for the error.

[gwbres]

This is superb! Really good work, I just have minor comments and cleanups, but I really like this implementation. Does it fit your purpose with GPST corrections?

My application is ideally to navigate (by that, I mean resolve P.V.T solutions) using any constellation/timescales (1) and output correct T (absolute time solution) in any prefered timescale (2) or at least with maximal flexibility (3).

To achieve all of that, we need the correction equation obviously but is not enough. The rest of the work is out of scope of hifitime. Currently my framework does both, so I will backport this (equation side) to my framework, and maybe one day, hifitime will provide the basic support.

• the equation is needed to be able to apply correct conversions. (1) and (2) mean you need to be able to express your measurement in the final T timescale
• (2) and (3) mean that the conversion method is not enough. You need some kind of intelligence to manage all your Polynomials, make sure you're using the correct one for that timescale at that instant. In gnss_rtk I coded the AbsoluteTime manager that does just that.
• I'm also trying to offer maximal flexibility, where AbsoluteTime is yet another "pool" manager. Let say you only have
  |GST-GPST| and |GST-UTC|, you can obtain |GST-UTC| by recombination.
• The conclusion, is we should obtain something that is correct at all times: say you want T in UTC, it remains correct whether you used GPS or BDS. It also means my framework starts to remain correct in modern scenarios, where you combine constellations like GPS+BDS. And also, offers a high level of flexbility
  • possibility to express the range measurements in whatever timescale (for example UTC)
  • possibility to express T in whatever timescale we support (providing you have a few polynomials)

[ChristopherRabotin]

Would you want to try out this framework in RINEX before merging? Or maybe try it out before we officially release 4.1.0 ?

[gwbres]

Would you want to try out this framework in RINEX before merging? Or maybe try it out before we officially release 4.1.0 ?

It would definitely be best I think. But I was simply counting on you not releasing it right away and naturally have time to play with it. Yet I just realized it's not easy and not enough. All my stuff relies on both anise+nyx so I need some kind of branch with "up to date" hifitime

[ChristopherRabotin]

Okay, let's merge this then, and I can create a non-release branch of ANISE that always points to the git repo of hifitime. Sounds good?

Edit: ANISE now has a branch called dep/hifitime-github that used the master of hifitime.

[gwbres]

awesome thanks ! I will keep you updated. I have to update my framework to the branch. I will re-run the tests I ran to validate my current state. I am also about to be able to produce more tests, I will keep you updated on all that.

Edit: ANISE now has a branch called dep/hifitime-github that used the master of hifitime.

very cool! I should probably do this in my own stuff

side note: that made me realized I can get rid of the nyx dependency and solely depend on anise in gnss_rtk (in its current state).
Now that the eclipse solver was backported there. And I am still unable to use your navigation filters, so I remain using my own as of today