Stated in the latest CCSDS OEM (v3) standard, and applied in OREKIT, the values of MEAN_MOTION_DOT and MEAN_MOTION_DDOT are divided by 2 and 6 respectively when converting from OMM to TLE implying that the values read straight out of the TLE are actually scaled units (2 rev/day^2 and 6 rev/day^^3).
Celestrak or Space-Track (S/T) support exporting in both TLE and OMM formats, but the values are the same in both formats.
Assuming OREKIT is right has anyone gathered evidence as to whether the TLE or the OMM format from S/T and Celestrak is correct (e.g. by propagating against observations).
If I had to guess (which I’d rather not) I’d guess TLE are OK on S/T and Celstrak, but that OMM are not?
I note that the OMM version from both these sites is 2.0, an alternative view might be that for Version 2.0, where no clarification was made, that the values in the OMM should also be scaled like the TLE?
Has anyone engaged with 18SDS or Celestrak to discuss this discrepancy?
The issue was raised when I worked with CCSDS navigation group four years ago, when I was working on the implementation.
Here is the relevant part of the message I sent on 2021-03-24:
The second remark is more troublesome since it was already present in
previous ODM versions, but it has no real consequence. In table 4.3
for OMM data, the last entries of the TLE block for MEAN_MOTION_DOT
and MEAN_MOTION_DDOT specify the units to be rev/day**2 and rev/day**3.
Retrieving TLE data in either TLE, KVN or XML format from T.S. Kelso
celestrack site
(<https://celestrak.com/NORAD/elements/gp.php?NAME=STARLETTE&FORMAT=TLE>,
<https://celestrak.com/NORAD/elements/gp.php?NAME=STARLETTE&FORMAT=KVN>,
<https://celestrak.com/NORAD/elements/gp.php?NAME=STARLETTE&FORMAT=XML>)
show the ODM units are fully consistent with TLE format, the difference
being only in syntax. However, in David Vallado famous 2006 paper
"Revisiting Spacetrack Report #3", the table in section B specifies
that MEAN_MOTION_DOT and MEAN_MOTION_DDOT also take into account
the factorials from Taylor expansion (i.e. the first one is divided
by 2 and the second one is divided by 6 as they are second and third
derivatives of the mean anomaly). I have never seen a TLE with
MEAN_MOTION_DDOT set to anything but 0.0, but many TLEs have non-zero
MEAN_MOTION_DOT. This has in fact no operational consequence since
neither derivatives is used in the SGP4/SDP4 models everybody use.
They are certainly used in SGP8, but I have not found any reference
about this.
Daniel Oltrogge, from comspoc, fixed this in the CCSDS standard according to my remark. As explained in my message from 2021, this has no operational consequence in SGP4/SDP4.
So I guess Orekit and CCSDS are in line with Vallado’s table, which could be considered to be the ultimate reference. I did not reach out 18SDS or Celestrak, but it would certainly be a good thing to do.
Would you mind contacting them, pointing out to this thread?
I’m also looking at this. CCDS standard units for MEAN_MOTION_DOT is rev/day^2 and MEAN_MOTION_DDOT is rev/day^3, however it appears they are stored within Orekit as scaled:
/** Scaled revolutions per square day unit. */
public static final Unit REV_PER_DAY2_SCALED = Unit.parse("2rev/d²");
/** Scaled revolutions per cubic day divieded by 6 unit. */
public static final Unit REV_PER_DAY3_SCALED = Unit.parse("6rev/d³");
But are not scaled when parsed; reading an OMM from Space-Track with the following values:
Given that the said variables turn out not to be used in SDP4/SGP4, then I guess it is moot and perhaps why it lingers on. Albeit incredibly confusing given that the said sources state in the OMM that SDP4/SGP4 is used.
I think the units are really scaled both at parsing and at writing, which explain you get the same output as the input. When we look at lines 61 and 65 of OmmTleKey.java and lines 59 and 60 of OmmTleWriter.java, we see the scaled units are used for reading and writing.
The scaled parameters are therefore available within the library when using the TLE.
If the source of MEAN_MOTION_DOT and MEAN_MOTION_DDOT is a TLE or
if these values are intended to be used as a TLE, then these values need to be divided
by 2 and 6 respectively to reflect the SGP theory Taylor Series expansion terms.
Honestly, I don’t know how to interpret this, and has it is not used in the models, I cannot really check. I don’t know what to do.
Thanks, CCSDS states the units in the OMM for MEAN_MOTION_DOT is revs/day^2 and various sources say the value in a TLE should be 1/2 this (hence why you divide by 2 when generating the TLE). The only remaining sticking point is that you output the units as 2revs/day^2 when I believe it should be revs/day^2. If it was stored as 2revs/day^2 then it wouldn’t need to be divided by 2 when generating the TLE.
I know it’s somewhat a moot point, but if we could reach agreement here it would be helpful
I agree with you.
Could you open an issue on the forge (and maybe provide a patch, it should be easy if it only means changing the units scaling factor, which is set up directly when the REV_PER_DAY{2,3}_SCALED fields are created.
If we want this to be included in a minor version, we should add new fields without the _SCALED suffix and use them, and only deprecate the scaled fields, because these fields are public, so they theoretically could be used by users.
