4
$\begingroup$

Does anyone know happened at NORAD or NASA or wherever the published TLEs originate, that caused the ISS TLE wonkiness during the last week of 2019? It did not happen in 2018. What happened? The day of year incremented past 365 days (not a leap year), and the year remained 19 (2019), for computed TLE sets that went into and past the first week of year 2020.

I get my ISS TLE sets from here:

https://spaceflight.nasa.gov/realdata/sightings/SSapplications/Post/JavaSSOP/orbit/ISS/SVPOST.html

and here:

https://tle.info/data/ISS_DATA.TXT

My code now corrects those TLE dates stored in my archive, after two days of rewriting some code to watch for it next time, (and on the upside, it brought my attention to some lurking future problems of my own that are now also fixed). But I would like to know if it was only a hiccup, or is there some change in the format underway, being 'tested'? As of 1/2/2020, the TLEs I received today are now back in the expected format, no longer referenced as days of 2019 beyond 365.

The official word?

Understand, I am very grateful that we have all these wonderful services available, and that I no longer need to squint at the paper reports from Greenbelt, MD, or type them in manually, as was necessary so many years ago (but even then, grateful for that). I would like to know if there are changes in the works that I could be preparing for ahead of time. And a big thank you to all those who maintain the servers and services and software tools so truly appreciated here.

Update 1-2-2020

In response to uhoh's request in the comments, here are three sample TLE sets acquired 12-30-2019, but the problem first seen on 12-24-2019, from the above mentioned links. Note the first one here (which wasn't the first TLE on the webpage, but I'm condensing). It is fine. But the others, of which I show two, have 2019 as the year (of course the leading 20 is not shown in the standard format), but then the day of year is 366 (not a leap year), and then in the last TLE, the day of year is 372? And the year is still 19. What I called 'wonky'.

ISS
1 25544U 98067A   19365.78947330  .00016717  00000-0  10270-3 0  9114
2 25544  51.6407 101.7439 0005315  86.0590 274.1168 15.49502788  5904

ISS
1 25544U 98067A   19366.82137887  .00016717  00000-0  10270-3 0  9129
2 25544  51.6392  96.6358 0005156  88.7140 271.4601 15.49497216  6061

.
.
.

ISS
1 25544U 98067A   19372.17436792  .00016717  00000-0  10270-3 0  9187
2 25544  51.6415  70.1365 0004825 107.1627 253.0051 15.49525362  6890

I modified my code to catch and correct this when reading from my archives, of course also recalculating the checksum, since my archives retain the 'wonky' ones as I first got them. (For those itching to ask the question, Yep, I forgot about recalculating the checksum on the first go.). Here is the processed version of that last set, which now works fine with pyephem (which I am glad bluntly did not like the wrong checksum):

ISS
1 25544U 98067A   20007.17436792  .00016717  00000-0  10270-3 0  9184
2 25544  51.6415  70.1365 0004825 107.1627 253.0051 15.49525362  6890

I'd be happy to provide more details or code, if they would help, but primarily I'm asking if anyone knows if this was only an end of year processing hiccup, like a mini y2k thing, or are there some changes to the format in the works, and they weren't quite ready for prime time? Like most people, I'd prefer to code ahead for a known upcoming change, than to be surprised by it. And that is the partial motive of my question.

Update 1-4-2020:

Now reading spacetrack report #3 for further insight. For those interested, link is here:

https://celestrak.org/NORAD/documentation/spacetrk.pdf

As I continue researching this, I continue to hope for and welcome and appreciate more insight from others.

Although I do not yet have my answer, a practical take away from this subject is for others to be aware that the doy > target year's days in a year situation is a possible epoch date that may be encountered in TLEs in the last week of that year, or even beginning the previous year(?! since we have not yet ascertained if there is a fixed hard limit less than 999 before the year is incremented and the doy gets adjusted properly for that year increment), and so one's own code base needs to deal with it wherever it may cause problems, if it does unexpectedly occur. IOTW, write code to expect it.

Improve this question
$\endgroup$
14
  • 1
    $\begingroup$ @uhoh in response to your comment, I added an update today with some samples. $\endgroup$
    – always_learning
    Commented Jan 3, 2020 at 4:43
  • 1
    $\begingroup$ @asdfex after reading several sources providing a key for understanding the data in the various positions of a two line element set, I have not yet encountered any detail such as your It's very common to refer to things like 'day -1' for the last day of the last month or 'October, 34th' to refer to the the third day of November.. I believe I am not the only one who would like it stated more clearly and plainly and officially on the many pages that are there to inform us. Thank you for inspiring a filling of that gap with your comment. $\endgroup$
    – always_learning
    Commented Jan 3, 2020 at 15:20
  • 1
    $\begingroup$ If it is indeed, as has been said, "very common", this begs the question, "How far outside standard expected ranges in this context, can one reasonably expect an official tle's epoch date to drift outside the culturally common expected ranges of the Gregorian calendar? Five days? Nine weeks? Less than 999 days?" Is there a document that clarifies this? It might prove to be immensely helpful when designing code and writing tests for that code. $\endgroup$
    – always_learning
    Commented Jan 3, 2020 at 15:22
  • 2
    $\begingroup$ @asdfex ok. Understood. My code makes extensive use of such functions. What was unexpected was actual published data straying outside a reasonably expected range, based on documents providing a key to understanding the values, and implying the ranges to be in culturally accepted bounds. A day of year value of 372 for year 2019 is not the normal culturally accepted bounds for days in a Gregorian calendar year. Hence my OP. Is a doy of 372 for 2019 actually better at presenting a clear and non-confusing useability of the data? Even a footnote on a tle format key would help. Yes? $\endgroup$
    – always_learning
    Commented Jan 3, 2020 at 16:06
  • 2
    $\begingroup$ @always_learning Just look at the spec. Io and behold, there are multiple. One thing they all have in common is that the epoch is the julian day + fraction, given as three characters in the range [0-9]. So 999 is definitely the largest acceptable number, negative numbers are not allowed. STK also says that the largest permissible value is 366, a restriction that is absent in the NORAD spec. So if you strictly implement the NORAD spec, you are required to allow days up to 999. $\endgroup$
    – Polygnome
    Commented Jan 3, 2020 at 21:10

1 Answer 1

Reset to default
3
$\begingroup$

The SGP4 propagator does not actually use the day of year (just time since epoch), thus a value beyond 366 is just fine. Some people may add some checks to a TLE to raise this as an error, but the propagator itself would see no problem in it. Also, if you want to see how much "time since epoch" is there between the TLE epoch and a given date, you might get into trouble using one such TLE, but then again, this isn't a problem with the TLE nor with SGP4.

My guess is that the issue is with the TLE generating software (which is not disclosed by NORAD). They probably propagate the ISS orbit into the future using better numerical methods, and fit a TLE to a mix of actual and propagated positions, but place the epoch close to the end of the fit window. Possibly, depending on how long the window is supposed to be and when the TLE was generated, they'd end up generating an epoch that takes place "next year", but the year field is not touched by the software, only the day of year field.

Another script/program could fix it, and possibly the software/server was moved or updated, and maybe someone didn't notice it was needed or that it wasn't running. Maybe someone disabled it for performance improvement because it is "never" needed and forgot to re-enable.

Notice this is partially speculation, but then again, we are wondering why a non-disclosed software presented a result that is not necessarily a problem (though I'd agree it should be fixed).

Improve this answer
$\endgroup$
4
  • $\begingroup$ +1 "The SGP4 propagator does not actually use the day of year (just time since epoch)..." Wow I never fully realized this until now! Yes a quick check of Revisiting Spacetrack Report #3 shows only zonal harmonics (J2, J3, J4) and no tesserals which would then require knowing absolute time and a model for the rotation of the Earth, and the expressions are always expanded about (t-t_zero). $\endgroup$
    – uhoh
    Commented Jan 6, 2020 at 22:32
  • $\begingroup$ There is some related discussion at Is SGP4 propagation necessarily more accurate near the epoch chosen for TLE generation? $\endgroup$
    – uhoh
    Commented Jan 6, 2020 at 22:42
  • $\begingroup$ Well, having been occupied lately, and now seeing this, its about 3/4 of what I'm now editing for about the fourth time. So it looks like we are all generally on the same page. I'm doing some graphic examples to further make the point, but it may not be posted for a week. And I'm taking an ideal TLE epoch epoch back in years to bring the doy of year to near 999, to see it work, and again show that an epoch is mainly a snapshot of a moment in time. As spacetrack rpt3 says, some components of it, for deep orbits, using an offset of 1950 jan 0.0 for accountting for the sun and moon gravity. $\endgroup$
    – always_learning
    Commented Jan 7, 2020 at 14:39
  • $\begingroup$ ... And a recurring variable of TSINCE in the fortran IV code of most of the subroutines. A defining moment in time, and time since that moment then defining the current moment of time of interest. $\endgroup$
    – always_learning
    Commented Jan 7, 2020 at 14:41

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