Support for SPK Segment Type 10

[dahlend]

Hubble's spice kernels are of SPK Segment Type 10, I now have an example to add support from:

kete.spice.kernel_fetch_from_url("https://naif.jpl.nasa.gov/pub/naif/HST/kernels/spk/hst.bsp")

[dahlend]

I have had loading of these files working since sunday afternoon, however there is a discrepancy between neospy and SPICE.

A few things that I have discovered which are incorrect in the SPICE file for hubble:

• There are at least 2 epochs where the TLE have been incorrectly saved. These are visible in the plot below as large spikes. These spikes are visible in my implementation as I have not included the interpolation between neighboring TLEs which SPICE uses. The TLEs vary relatively slowly, meaning that they can be interpolated well. However if there is a large difference from one TLE to the next then the error between interpolation vs not interpolation will get worse, and then get better again as it moves over the bad data point. Because I am not interpolating yet, this error is extremely visible. If I had implemented interpolation then these discrepancies would not be visible. The "smearing" of the differences, IE, the visible banding of the error is what should be expected for the difference from interpolation vs not interpolating.

• Hubble file contains 5-6 Earth gravitational constant terms which are out of date, and not what are used by other agencies. Specifically they are not using the WGS84 standard which is the expected values for the provided TLEs. I have compared the TLEs present in their spice file against the external source of this information and they match precisely, meaning these constants are not being recorded correctly.

The main issue:

After spending a few hours on this I believe there is an error in time conversion, and I am somewhat certain that this conversion is incorrect in cSPICE itself. Much of this error may be fixed by applying a small linear offset to time which causes about a 3 second offset in 2024 vs a 0 second offset in 2000. I am currently trying to diagnose the source of this, I have checked and validated that my time conversion matches cSPICE time conversion to the microsecond level.

EDIT:
I am using an external library to analyze the TLEs, which has been validated to match the official standard TLE implementation to the expected numerical precision of the TLE format. I trust this source of the computation far more than the implementation present in cSPICE.

[dahlend]

I will continue to work on this on my own time, but I will merge what I have for now, as it is mostly working, if not at 100%.

[dahlend]

For a point of comparison, here is the same plot for the difference of earths position in spice vs neospy, less than about 100 micron:

[joemasiero]

I think these spikes correspond to the space shuttle servicing missions. They boosted the orbit right around the same time you're seeing the spikes, so that might be why there are differences?

[dahlend]

Good catch, servicing mission near may 11 2009

[dahlend]

Pretty sure their interpolation fails near those dates due to interpolation being a bad move for discontinuous events.

[dahlend]

Here is a more detailed plot showing the effects of interpolation, the minimums in the sin waves are when exact dates are saved in the spice kernels. The overall offset of about 17km is the underlying time conversion issue.