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:
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?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:
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? 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:
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? tle, propagateorbit, two-line elements MATLAB Answers — New Questions

​