eph2tle.txt

;   Any line starting with ';' is treated as a comment.  This file
; is read by 'eph2tle' (see 'eph2tle.cpp') as boilerplate to be put
; at the start of all TLE files.
;
#    The following TLEs (Two-Line Elements) were generated by fitting
# a numerically-integrated ephemeris,  based on the orbit given below,
# to the SDP4/SGP4 models.  Each TLE is good for the interval between
# its epoch and the epoch of the subsequent TLE (usually one day).
# The maximum deviation between the numerically integrated ephemerides
# and the TLE-based ephemeris, in kilometers,  is given for each TLE
# as the "worst residual".
#
#    This fitting is done using the 'eph2tle' code packaged with Find_Orb.
# The code has details on how the TLEs were computed :
#
#    https://github.com/Bill-Gray/find_orb/eph2tle.cpp
#
#    Be warned:  the error given is that between the numerically
# integrated ephems and the TLE model.  There will usually be at
# least some additional difference between the ephems and the actual
# motion of the satellite,  especially if the ephemerides are based
# on a short arc.  If the following orbital elements say something
# like "[based on] 10 observations 2015 Jan. 1-13",  and the TLEs
# are for 2015 May,  the extrapolation may be tenuous at best.  If
# your application requires a specific level of accuracy,  you may
# want to contact me;  I can give you some idea as to the fit of the
# underlying data (and possibly TLEs based on newer data).
#
#   You can usually find the underlying observational data,  and the
# fitted orbit,  residuals,  ephemerides,  and sometimes some comments
# about the object,  among the pages listed at
#
#    https://www.projectpluto.com/pluto/mpecs/pseudo.htm
#
; HEX         (Only show following paragraph if the hex version is used)
#    WARNING:  for this object,  "normal" TLEs cannot be fitted.  (This
# usually means an object with an hyperbolic or nearly-parabolic orbit.)
# For this and similar cases,   an alternative model is used,  in which
# most of the traditional TLE data is replaced by six signed 8-digit hex
# numbers.  These six numbers are a state vector,  numerically integrated
# using a simplified force model.  This is necessary for objects at L2 or
# L1,  and sometimes for objects in high orbits where the SDP4/SGP4 model
# fails.  Some documentation is in 'get_el.cpp' in the source code at
# https://www.github.com/Bill-Gray/sat_code ; look for 'hex' in that file,
# with the actual integration done in 'sdp4.cpp'.  But be aware:  it's my
# own extension,  doesn't work with other code,  and is therefore used
# only when necessary.
#
;         (End of hex-only section)
; SGP4    (Only show following paragraph if we've forced SGP4)
#    WARNING:  The TLEs in this file are all fitted to SGP4,  even if
# they're in deep space (longer than a 225 minute period).  This is only
# done in cases where SDP4 fails or fits the ephemeris poorly.  The problem
# is that,  while SGP4 fits here,  many programs don't actually look at the
# ephemeris type code byte.  They will produce garbage results when using
# these TLEs.  (Sat_ID and all programs by me,  Bill Gray,  will use these
# TLEs correctly.  But I may be the only one doing that.)
#
#    If you're stuck with software that can't handle these TLEs,  please
# let me know.  I can probably provide "traditional" SDP4-fitted TLEs for
# the object in question.  They will be less precise,  but possibly good
# enough for your use case (and,  as with all the TLEs I produce,  the error
# will be a known quantity).
#
;        (End SGP4-only section)
#    Also,  if you use a TLE outside the "correct" time range (between
# its MJD and that of the next TLE),  all bets are off.  I've carefully
# computed and minimized the worst error over the "correct" time frame,
# but the ephemeris may (or may not) diverge wildly outside of it.
#