Question about Nyx::Orbit.ecc()

[gwbres]

Hello Chris,

in my position solver, I need the user to provide several attitude parameters (more generally: orbit parameters) for each Spacecraft in orbit.

Currently, this is wrapped as a gnss_rtk::prelude::InterpolationResult, which is quite simple and easy to use. But I'm thinking of converting this to a nyx::Orbit, considering it already has P(t), V(t) and especially now that I have this new requirement.

I'm working on a new bias compensation which requires providing the "Eccentricity of the osculating orbit", E in this equation :

Could you explain me whether that is what Nyx::Orbit.ecc() returns or not ?
If that's what it is, that will end the debate about converting to your type or not.
If that is the case, could you please confirm I should then use the Frame::Earth2000 in your API - as you previously showed me, considering my Position and Velocity vectors are both expressed in ECEF frame ? thanks a lot !

[ChristopherRabotin]

Hi Guillaume,

Yes, the ecc function returns the eccentricity of the osculating orbit, specifically, the norm of the eccentricity vector calculated with this formula.

For an end-to-end example, I'd recommend looking at the "cosmic" integration test here. Essentially, you need to load the planetary information (using Cosm::de438s() for example), retrieve the relevant frame (in your case, it's the Earth Mean Equator J2000, or EME2000, also called Earth J2000 -- it's the Earth centered inertial frame), define the epoch, and then build an orbit structure.

Ignoring the imports, your code will look like something like this:

let cosm = Cosm::de438();
let eme2000 = cosm.frame("EME2000");
let epoch = Epoch::from_gps_nanoseconds(gps_ns);
// Assuming that the interpolation result is in km and km/s.
let position_vec_km = my_interp_result.position;
let velocity_km_s = my_interp_result.velocity.unwrap(); // Assume it is set 
let orbit = Orbit::cartesian(position_vec_km[0], position_vec_km[1], position_vec_km[2], velocity_km_s[0], velocity_km_s[1], velocity_km_s[2], epoch, eme2000);

println!("{}", orbit.ecc());

Note that as part of #86 , the whole "Cosm" will be removed in favor of the much more precise ANISE backend. This will only start taking affect with version 2.0.0-beta.1, hopefully ready before 01 Jan 2024.

I hope this helps.

[gwbres]

I hope this helps

Oh it surely did, thank you for getting back.

I was also inaccurate in my statement: both the eccentricity and the anomaly are required in the equation i'm interested in, and your API can provide both.

This is fun - seriously. In this simple topic, I managed to fall into all the traps you can think of 🤣 🤣
I think I should write somesort of a student's workbook on this project 🤣 my wiki pages might wind up like it in some ways.

I was getting zeros all the time initially, and by re-reading your post, realized the velocity is mandatory for this to work out.
My API was built with optional velocities - I personnally don't know how to interpolate the velocity.
It was easy to deduce the velocity from the past position vector and start getting results in the range of a few nanoseconds, as you would expect here.

Then, after starting using it, rapidly saw that it did more harm than good to my PVT solutions.
Turned my two brain cells back on, and realized I managed to create a weird situation where, the Sagnac effect was "asymetrically compensated" for in my derivative calculation v(t) = d/dt(p(t)), like compensated for in the past position, but not in the ongoing position.
The Sagnac effect (frame rotation to take into account of the earth's rotation) is the physical effect I just introduced before this very topic.

Resolve without taking relativistic effect into account : (basically, where I was when I asked this question)

rinex-cli -p --lsqspp -P GPS \
     -c config.json \
     -f test_resources/CRNX/V3/ESBC00DNK_R_20201770000_01D_30S_MO.crx.gz \
     -f test_resources/NAV/V3/ESBC00DNK_R_20201770000_01D_MN.rnx.gz \
     -f test_resources/SP3/GRG0MGXFIN_20201770000_01D_15M_ORB.SP3.gz

cat config.json

{
   "timescale": "GPST",
   "interp_order": 11,
   "max_sv": 10,
   "min_sv_elev": 20.0,
   "min_snr": 20.0,
   "modeling": {
      "sv_clock_bias": true,
      "sv_total_group_delay": true,
      "tropo_delay": true,
      "iono_delay": true,
      "earth_rotation": true, 
      "relativistic_clock_bias": false
   }
}

Compensate for relativistic clock bias with

{
   "timescale": "GPST",
   "interp_order": 11,
   "max_sv": 10,
   "min_sv_elev": 20.0,
   "min_snr": 20.0,
   "modeling": {
      "sv_clock_bias": true,
      "sv_total_group_delay": true,
      "tropo_delay": true,
      "iono_delay": true,
      "earth_rotation": true, 
      "relativistic_clock_bias": true
   }
}

Side note: check out how Earth's rotation during the signal time travel, ends up as a static bias that simply offset the solutions to the East

{
   "timescale": "GPST",
   "interp_order": 11,
   "max_sv": 10,
   "min_sv_elev": 20.0,
   "min_snr": 20.0,
   "modeling": {
      "sv_clock_bias": true,
      "sv_total_group_delay": true,
      "tropo_delay": true,
      "iono_delay": true,
      "earth_rotation": false, 
      "relativistic_clock_bias": true
   }
}

Ignoring the imports, your code will look like something like this:

let cosm = Cosm::de438();
let eme2000 = cosm.frame("EME2000");

Yeah, that I understand since you helped me out in early September.
The solver owns the models internally so we only load them once, at boot time.
It is fixed to Earth EME2000 and the Sun body, considering that's where most rovers are located at the moment.
And now I just realized Nyx does not limit us to Earth 👽 👽

Note that as part of #86 , the whole "Cosm" will be removed in favor of the much more precise ANISE backend. This will only start taking affect with version 2.0.0-beta.1, hopefully ready before 01 Jan 2024.

Then I need to keep up to date and will need to understand what migrating will require