RINEX to UT1 Provider

[gwbres]

The recently released V4 RINEX revision is designed to improve the transcription of anything described by radio messages in GNSS. It spans many topics, from temporal to atmospheric or navigation information. NAV V4 introduces Earth Orientation messages, which contain the offset between the streamed Epoch and UT1.

RINEX V0.17 (not released yet) introduces a direct conversion from RINEX NAV V4 to Hifitime UT1 provider. The provider is integrated on nav feature, and coded in src/lib.rs in the nav feature section.

This is probably a cool feature, but its applications are beyond my use cases and current knowledge.
To me, UT1 is the only timescale that may apply to cosmic / interstellar applications, that's pretty much all I know.

[ChristopherRabotin]

Interesting.

That's also how I understand UT1: it's used for astronomy to correct the rotation of the Earth for observations. In astrodynamics, we just used the Earth Orientation Parameters, which are published by NASA twice a day (they use the data from the Observatoire de Paris).

Let's keep this in mind.

[gwbres]

if you happen to have other Earth orientation related structures within your libraries, we can create other bridges easily.
I'm not aware of people working on astrodynamics from RINEX data, but you never know, the applications spectrum is too broad

[ChristopherRabotin]

In ANISE, all rotations are treated the same way, by computing the direct cosine matrix (and itsttime derivative) from the declination, right ascension, and twist angles. These angles are interpolate from the data in the "earth_high_prec_latest.bpc" file that NASA publishes. However, in almost all cases of astrodynamics, we only care about the position and velocity, so most functions invest a vector and return a rotated vector, cf. https://github.com/nyx-space/anise/blob/83c2487f7102277bacdaa0ed72687d6caa561499/anise/README.md?plain=1#L77 . For the DCM test case, refer to https://github.com/nyx-space/anise/blob/83c2487f7102277bacdaa0ed72687d6caa561499/anise/tests/orientations/mod.rs#L110. The validation also checks the computations against SPICE toolkit itself, for which these files are originally built.

One structure that you may find useful is the Cartesian State: https://docs.rs/anise/latest/anise/math/cartesian/struct.CartesianState.html. In my experience with many professional / corporate software, and open source software, it's way too easy to make errors in the frames. So the Cartesian State stores the frame center and orientation : this means that operations between two states will return an error if the frames are not compatible. The DCM structure also stores the frame data. So if you try to rotate a state that is in the ITRF93 with the DCM that rotates from the J2000 to the ITRF93, you'll get an "Invalid rotation error" : https://docs.rs/anise/latest/anise/errors/enum.PhysicsError.html#variant.InvalidRotation.