TLE formatting issues

[trusat]

TLE formatting issues

[interplanetarychris]

Leading zeros are missing in the NORAD ID (column 2 of lines 1 and 2)

@cbassa I referenced https://www.celestrak.com/columns/v04n03/ when looking that the format...

The following paragraph would imply that leading spaces are equally valid as leading zeros. Can you cite a differing documented standard?

In general, any number smaller than the maximum field size can be padded with either leading spaces or leading zeros. In other words, an epoch can be represented as either 98001.12345678 or 98 1.12345678 or an inclination can be represented as 28.1234 or 028.1234. Convention uses leading zeros for fields 1.5 and 1.8 and leading spaces elsewhere, but either is valid.

[cbassa]

The following TLEs are from the trusat_all.txt file.

1. Leading zeros are missing in the NORAD ID (column 2 of lines 1 and 2)

THOR AGENA B R/B
1   426U 62049B   19314.15693840  .00000035  00000-0  30117-4 0  9991
2   426  80.4674 128.9182 0017469 322.6928  86.6998 13.68469214850938
0 THOR ABLESTAR R/B     
1   447T 62060B   19327.07209049 -0.00000132  00000-0 -76033-5 0   07
2 00447  50.1269 247.2660 0065647 207.1981 239.7222 13.39040675791001

Note also the U for 00426 and the T for 00447.

2. Some satellites have negative inclination (take the absolute value and increment RAAN by 180 deg)

0 WGS 4                 
1 38070T 12003A   19267.68864583 0.00000000  00000-0  00000-0 0    00
2 38070  -0.3897  82.1429 0004204 215.3954  41.9143  0.92793498    06

3. The first derivative of mean motion (column 5 of line 1) has no leading 0. This offsets later columns by one character, leading to bad predictions

1  2825T 67053B   19326.73660876 -0.00000017  00000-0  22976-4 0   04
1 NNNNNC NNNNNAAA NNNNN.NNNNNNNN +.NNNNNNNN +NNNNN-N +NNNNN-N N NNNNN

[cbassa]

Leading zeros are missing in the NORAD ID (column 2 of lines 1 and 2)

@cbassa I referenced https://www.celestrak.com/columns/v04n03/ when looking that the format...

The following paragraph would imply that leading spaces are equally valid as leading zeros. Can you cite a differing documented standard?

In general, any number smaller than the maximum field size can be padded with either leading spaces or leading zeros. In other words, an epoch can be represented as either 98001.12345678 or 98 1.12345678 or an inclination can be represented as 28.1234 or 028.1234. Convention uses leading zeros for fields 1.5 and 1.8 and leading spaces elsewhere, but either is valid.

Fair enough about leading zeros on the NORAD catalogue ID. I note that the SGP4 library by Paul Crawford that I use for sattools requires the leading zeros: https://github.com/cbassa/sattools/blob/master/satutl.c#L68

My personal preference would be to include the leading zeros, though I can easily add them if required, which I do for the space-track catalog: https://github.com/cbassa/sattools/blob/master/tleupdate#L34

[interplanetarychris]

My personal preference would be to include the leading zeros

Will probably do so - noting that they were inconsistently formatted in the code:

https://github.com/consensys-space/trusat-orbit/blob/b5604c6025dca0ce05e89c18f39fbfd389b2e657/tle_util.py#L626-L647

Formatting for TLEs with a "U" classification code is as-received from the source. A separate bug is open for making sure that those don't end up in the exported TLEs. TruSat/trusat-backend#81

[interplanetarychris]

@cbassa I think this is fixed now - All the Trusat TLEs have been updated, and I've also added leading zeros to the external TLEs which are currently in the catalog results. Thanks for the heads up!

[cbassa]

The TLEs from trusat_all.txt now load and show correctly in skymap. Thanks!