NumberFormatException when parsing TLEs with B* with three-chars exponent

Orekit development
1

Hello,

We found an issue in the TLE constructor from two lines strings. If B* has an exponent encoded with three chars, e.g. e-10, a NumberFormatException is thrown.

Example TLE that triggers the error:

1 53577U 22101BC  25345.55693763 -.00000288  00000-0 87000-10 0  9991
2 53577  53.2164  89.5151 0001373  89.9326 270.1823 15.08845301183965

I have already opened an issue on the forge NumberFormatException when parsing TLE string with B* with three-chars exponent (#1880) · Issues · Orekit / Orekit · GitLab

@Serrof I can fix it today if you want to include it in v13.1.3.

Cheers,

Alberto

1 Like
2

Hi Alberto,

sure if you provide the fix this week, it’ll be in the patch.

Out of curiosity, is this TLE from space-track.org or somewhere else?

Cheers,
Romain.

3

Hi Romain,

I’ll open a MR then. Thanks.

Yes, the TLE is from SpaceTrack

Alberto

4

This turns out to be a bit more complicated than initially thought.

In the corresponding OMM the B* value is 8.7e-11. So should we assume that there is always a decimal point in front of the string representation, e.g. 87000-10 → 0.87000e-10, even if the first digit is at index 54 where there is usually a space?

5

The provided TLE from space-track appears unusual, and is rarely seen.

1 53577U 22101BC  25345.55693763 -.00000288  00000-0 87000-10 0  9991
2 53577  53.2164  89.5151 0001373  89.9326 270.1823 15.08845301183965

On space-track, the Basic Description of the TLE Format only specifies that B* Drag Term is between Columns 54-61 of Line 1 (index starting from 1), and no more restrictions on its format.

According to CelesTrak: NORAD Two-Line Element Set Format, the TLE is expected to be in the following format:

AAAAAAAAAAAAAAAAAAAAAAAA
1 NNNNNU NNNNNAAA NNNNN.NNNNNNNN +.NNNNNNNN +NNNNN-N +NNNNN-N N NNNNN
2 NNNNN NNN.NNNN NNN.NNNN NNNNNNN NNN.NNNN NNN.NNNN NN.NNNNNNNNNNNNNN

it indicates that Column 54-61 (index starting from 1) are formatted as +NNNNN-N and represent
BSTAR drag term (Leading decimal point assumed).

That is the exponent part of B* is most likely occupies 2 chars, and a decimal point assumed between column 54 and column 55 of the coefficient part (index starting from 1). And this is what is done in orekit now,

// index starting from 0
final double bStarValue = Double.parseDouble((line1.substring(53, 54) + '.' +
                                    line1.substring(54, 59) + 'e' +
                                    line1.substring(59, 61)).replace(' ', '0'));

In Vallado’s Fundamentals of Astrodynamics and Applications, a widely used version of SGP4 treats B* in the same manner.

Therefore, it may be prudent to mark this TLE as abnormal and maintain Orekit’s TLE parser in its current form.

The provided TLE could be manually corrected as,

1 NNNNNU NNNNNAAA NNNNN.NNNNNNNN +.NNNNNNNN +NNNNN-N +NNNNN-N N NNNNN
1 53577U 22101BC  25345.55693763 -.00000288  00000-0  08700-9 0  9991
2 53577  53.2164  89.5151 0001373  89.9326 270.1823 15.08845301183965
2 Likes
6

Hi @xzguo,

I did some more research myself, and I came to the same conclusion. Thanks for the thorough explanation. I will close the issue for now.

Alberto

1 Like