comparison with SatTrack SGP4/SDP4 solution?

I am looking into understanding the behavior of a geostationary satellite around its equilibrium point. As a great fan of SatTrack [1] for decades, this has been my first obvious choice, but the lack of resolution and the suspicious “*” symbols when computing the solution led me to look for an alternative (I have always used SatTrack successfully for LEO satellites, first time I am looking into geostationary). I have hence compared this Python library with the SatTrack output and observe some significant difference. Obviously I am using the TLE well beyond their expiry date, but am wondering why, as both libraries seem to be relying on the same SPG4 (or SPD4 for geostationary bodies) solver, the solutions are diverging. Has any benchmark been assessed between solver implementations? FYI, the TLE is from Telstar11N downloaded from Celestrak at two dates, namely March 27 2022 and April 18 2022 and am comparing how quickly the solutions diverge. Thanks and the associated software for generating the satellite range/azimuth/elevation with the Python library

#1 34111U 09009A   22086.18243766 -.00000270  00000+0  00000+0 0  9991
#2 34111   0.0189 162.3771 0001463 203.1699 207.1412  1.00270119 47943
TLE = """1 34111U 09009A   22086.18243766 -.00000270  00000+0  00000+0 0  9991
2 34111   0.0189 162.3771 0001463 203.1699 207.1412  1.00270119 47943"""

L1, L2 = TLE.splitlines()

from skyfield.api import Loader, EarthSatellite
from skyfield.api import N,S,E,W, wgs84
from skyfield.timelib import Time
import numpy as np
import csv

halfpi, pi, twopi = [f*np.pi for f in [0.5, 1, 2]]
degs, rads = 180/pi, pi/180

load = Loader('~/Documents/fishing/SkyData')
data = load('de421.bsp')
ts   = load.timescale()

planets = load('de421.bsp')
earth   = planets['earth']
lab     = wgs84.latlon(+47.0*N, +6.0*E,elevation_m=143)

telstar11n = EarthSatellite(L1, L2)
hours = np.arange(0, 750, 0.1)
time = ts.utc(2022, 4, 12, hours)
diff=telstar11n-lab
Rpos    = diff.at(time).position.km
Rposecl = diff.at(time).ecliptic_position().km
topocentric=diff.at(time)
alt, az, distance = topocentric.altaz()
print(distance.km)

re = 6378.

r_Roadster = np.sqrt((Rpos**2).sum(axis=0))
alt_roadster = r_Roadster - re
with open('dist2703.csv', 'w', newline='') as csvfile:
    o=csv.writer(csvfile, delimiter=' ', quotechar='|', quoting=csv.QUOTE_MINIMAL)
    o.writerow(distance.km)
with open('alt2703.csv', 'w', newline='') as csvfile:
    o=csv.writer(csvfile, delimiter=' ', quotechar='|', quoting=csv.QUOTE_MINIMAL)
    o.writerow(alt.degrees)
with open('az2703.csv', 'w', newline='') as csvfile:
    o=csv.writer(csvfile, delimiter=' ', quotechar='|', quoting=csv.QUOTE_MINIMAL)
    o.writerow(az.degrees)

[1] https://ieeexplore.ieee.org/document/499660/similar whose source code I still have from https://sources.debian.org/src/sattrack/3.1.6-9/ after applying a Y2K bug patch

[jmfriedt]

As @jmfriedt hasn’t replied since April, and since Skyfield is happy to use the official SGP4 solution for satellites, and since there’s no volunteers have popped up here in the issue who want to go through SatTrack’s code line-by-line figuring out how it works and why its results are different from the official routine, I’m going to go ahead and close this issue.

This exchange has been most instructive and although I did not participate for lack of technical knowledge I was most interested in learning about such subtleties in geostationary satellite path prediction. On a positive note, I did the same for GPS satellite position prediction and the result is amazingly consistent with online tools and observations. Thanks a lot for looking into the issue, greatly appreciated.

[brandon-rhodes]

@CelesTrak — Thank you for your July comment pointing out that different propagators can still be expected to agree to within millimeters, and that the difference in distances reported by @jmfriedt indicate a serious divergence in opinion about where a satellite is.

@rmathar — It doesn’t look like the earth object is used anywhere in @jmfriedt’s code after being created, so I suspect it was just cut-and-pasted in as part of another example? I don’t think it can affect the outcome here since that object isn’t used in the calculation. But I agree with your other points, and they make good sense of several of the details in the plots.

I have the feeling that there’s lots of detail missing because the SatTrack elevation and azimuth are being rounded off to tenths of degrees, which erases any little details like the nearly-diurnal waviness of the SGP4 solution that @rmathar points out. It could be there in the SatTrack data too, but the rounding to tenths of degrees turns whatever curve was there into a stair-step.

As @jmfriedt hasn’t replied since April, and since Skyfield is happy to use the official SGP4 solution for satellites, and since there’s no volunteers have popped up here in the issue who want to go through SatTrack’s code line-by-line figuring out how it works and why its results are different from the official routine, I’m going to go ahead and close this issue. I welcome any further comments on the closed issue and will plan on responding to them when I get the chance, but I don’t guess at this point that any Skyfield contributors are going to be jumping in to do a detailed analysis of the differences between SGP4 and SatTrack.