I've been using the example script for ground track from the beyond library documentation. I've been using TLEs from Celestrak's set of NOAA satellite TLEs, located here. This was working fine until I attempted to generate a ground track of NOAA 1, at which point the program failed, returning the following error:

  File "C:\Users\USER1\Documents\Python Scripts\apis\untitled2.py", line 38, in <module>
    for point in orb.ephemeris(start=start, stop=stop, step=step):

  File "C:\Users\USER1\anaconda3\envs\bravo\lib\site-packages\beyond\orbits\orbit.py", line 128, in ephemeris
    for orb in self.iter(inclusive=True, **kwargs):

  File "C:\Users\USER1\anaconda3\envs\bravo\lib\site-packages\beyond\orbits\orbit.py", line 113, in iter
    self.propagator.orbit = self

  File "C:\Users\USER1\anaconda3\envs\bravo\lib\site-packages\beyond\propagators\sgp4.py", line 29, in orbit
    tle = Tle.from_orbit(orbit)

  File "C:\Users\USER1\anaconda3\envs\bravo\lib\site-packages\beyond\io\tle.py", line 316, in from_orbit
    return cls(f"{name}{line1}\n{line2}")

  File "C:\Users\USER1\anaconda3\envs\bravo\lib\site-packages\beyond\io\tle.py", line 136, in __init__

  File "C:\Users\USER1\anaconda3\envs\bravo\lib\site-packages\beyond\io\tle.py", line 198, in _check_validity
    raise TleParseError(

TleParseError: Invalid TLE size on line 1. Expected 69, got 68. 

I was able to replicate this issue with the TLEs for NOAA 2 through 5, as well. I've ensured that all of the TLEs that raised the error are compliant with standard, and I can't seem to find any other issue that would cause this, nor any other reports of this happening online. I will admit I am quite new to this community, so there could very easily be something that I am overlooking out of ignorance.

Any assistance or advice is greatly appreciated.

  • 4
    $\begingroup$ I’m voting to close this question because it's a programming question, not a question about space exploration $\endgroup$
    – Erin Anne
    Aug 23, 2022 at 22:09

1 Answer 1


It appears that beyond python package considers a TLE that has a zero in character 3 of line 1 in the TLE to be an invalid TLE.

According to the beyond package, this is an invalid TLE:

NOAA 1 [-]              
1 04793U 70106A   22235.17827549 -.00000042  00000+0  97883-5 0  9990
2 04793 101.5520 297.2947 0031664 191.6576 231.9756 12.54006942365958

If, on line 1, you replace both character #3, and character 69 with a 1 (to get past check digit issues), the listed program executes.

I'm guessing this is an issue with integer casting of the satellite number being used as part of the string length validation, instead of the original string value..

  • 2
    $\begingroup$ After a quick glance in the package code, it looks like tle.py reconstructs the TLE from stored variables, and validates that. Because the Satellite Number is an integer, and it doesn't left-pad the value when reformatting, it will reject any TLE with a Satellite Number of less than 10000 $\endgroup$
    – notovny
    Aug 23, 2022 at 23:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.