propagateOrbit function hangs for no obvious reason

When the propagateOrbit function is fed certain TLEs, it simply stalls instead of throwing an exception. Since the propagateOrbit function is compiled, there is no way to trace and debug the hangup. When I press the "Pause" button, it greys out and says "pausing". If I press "Stop", I get the following message:

Operation terminated by user during matlabshared.orbit.internal.SGP4.propagate

For example, this TLE appears to be toxic:

1 52643U 00000A   22181.91667824 -.00046528  00000-0  32759-0 0    10
2 52643  53.2133 206.5805 0002347  15.7379 205.9837 15.73290591  1300

Here is a code example:

formatTime = 'uuuu:DDD:HH:mm:ss.SSS';
start_time = 2022:182:11:08:05.800';
dt_start_time = datetime(start_time,'InputFormat', formatTime);
tlestruct = tleread('tle_52643.tle');
[r,v] = propagateOrbit(dt_start_time, tlestruct);

In some cases, propagateOrbit() is unable to resolve an orbit. This is to be expected; however, instead of throwing an exception, the function outputs a set of matrices containing complex numbers.If you then try to do a coordinate transformation on the r and v matrices using eci2ecef(), the code blows up.

Here is an example of a satellite TLE that does not resolve. Looking at the Epoch field (11327.05272112) it is apparent that this TLE had not been updated in 11 years, as of 2022. Since the computation of Mean Anomaly is based on the Epoch, it is no wonder that SGP4 fails.

1 87954U 00000A   11327.05272112  .00003699  00000-0  57015-0 0    10
2 87954  98.4963 251.3127 0116186  87.4088 331.4134 14.69587133  3680

[r,v] = propagateOrbit(dt_start_time, tlestruct);

r = 1.0e+24 *
-1.2748 - 3.5603i
-4.3786 - 5.0800i
 7.0058 - 3.8228i

On a related note, the tleread function will fail if the BSTAR term's minus sign is not exactly in column 54. If the BSTAR mantissa is less than five digits long and the minus sign gets displaced to the right, tleread() is unable to generate a TLE. Some sites like Celestrak are more diligent about adding leading zeros to the BSTAR term, but others are not and can lead you to trouble.

SUGGESTION: Make tleread() more user-friendly?

[Kurt]

SOME REASONS WHY AN SGP4 PROPAGATION MIGHT FAIL:

1. Eccentricity is negative/ BSTAR is negative
2. A (semimajor axis) is too large (parabolic?)
3. Orbit has decayed
4. Epoch is too old: lost satellite
5. Other?

Answer 1

[Kurt]

This is an interim solution until Mathworks modifies the propagateOrbit function. This is based on the code previously mentioned.

Filter out all TLEs in the catalog that are more than a month old:

epoch = tleStruct(i).Epoch;
result = get_TLE_age(epoch, dt_start_time);

%--------------------------------
function result = get_TLE_age(epoch, dt_start_time)
% compute age of TLE compared to current (epoch) time
% set these just in case; TimeZone is not always set by default
    epoch.TimeZone = 'UTC';             % 30-Jun-2022 22:00:00
    dt_start_time.TimeZone = 'UTC';     % 18-Oct-2022 11:00:13
    deltat = dt_start_time - epoch;     % get elapsed time
    hms = strsplit(string(deltat), ':');
    hours = abs(double(hms(1)));
    result = hours <= 720;          % elapsed time < 30 days?
end

If result == 0, then the TLE is more than 30 days old, so reject it.

[Kurt]

Apparently this does not cover all situations. If a satellite has decayed, then it is still possible for propagateOrbit to barf even if the TLE is recent.

I found a code example for SGP4/SDP4 in the File Exchange at this location:

https://www.mathworks.com/matlabcentral/fileexchange/132693-sgp4-sdp4

According to the sgp4.m code, these are the contingencies that can cause SGP4 propagation to fail:

%   outputs       :
%     r           - position vector                     km
%     v           - velocity                            km/sec
%     return code - non-zero on error.
%                    1 - mean elements, ecc >= 1.0 or ecc < -0.001 or a < 0.95 er
%                    2 - mean motion less than 0.0
%                    3 - pert elements, ecc < 0.0  or  ecc > 1.0
%                    4 - semi-latus rectum < 0.0
%                    5 - epoch elements are sub-orbital
%                    6 - satellite has decayed

[Kurt]

A SOLUTION THAT WORKS:

Change the propagateOrbit() call to reference SDP4 instead of SGP4:

[r,v] = propagateOrbit(dt_start_time, tlestruct,PropModel="SDP4");

This will prevent the hangups that the default SGP4 call apparently causes.