Re: SDP4 failure example
Bruno Tilgner (Bruno_Tilgner@compuserve.com)
Sat, 29 Mar 1997 17:42:18 -0500
Rob Matson wrote on 28 March:
>Okay, folks, for all those who've been following the SDP4 discussion, here is
>an example that I believe will fail on all existing implementations of the
>SDP4 model. It exploits the coding bug in the Lyddane modification section of
>DPPER that I mentioned, which occurs when the right ascension of ascending
>node makes a transition between quadrants 1 and 4:
>
> (e.g. 359 --> 359.5 --> 0 --> 0.5 )
>
>Try your code with object #23243, 1992-021N, using the following elements
>(from a recent ALLSAT.DAT):
>
>1992-021N
>1 23243U 92021N 95016.23792613 +.00000374 +00000-0 +34706-2 0 00450
>2 23243 003.2770 358.1095 7290859 272.4086 014.1114 02.14568415009855
>
>Plot the track of the above object on January 10, 1995, from 21:33 UTC to
>21:53 UTC. With SGP you'll have no problems; with SDP4 the object will jump
>when its instantaneous RAAN passes through 0 degrees.
Well, it seems to depend on the implementation of the algorithm. The following
is a snippet from TRAKSAT 2.8 with some unnecessary numbers removed:
Date Time (UTC) Lat Long Alt
HR:MN:SEC Deg Deg km
--------------------------------------------------
Tue 10Jan95 21:40:00.0 3.29 20.77 36510
Tue 10Jan95 21:40:30.0 3.29 20.71 36493
Tue 10Jan95 21:41:00.0 3.29 20.65 36476
Tue 10Jan95 21:41:30.0 3.29 20.59 36459
Tue 10Jan95 21:42:00.0 3.29 20.53 36441
Tue 10Jan95 21:42:30.0 3.29 20.47 36424
Tue 10Jan95 21:43:00.0 3.28 20.41 36406
Tue 10Jan95 21:43:30.0 3.28 20.35 36388
Tue 10Jan95 21:44:00.0 3.28 20.29 36370
Tue 10Jan95 21:44:30.0 3.28 20.23 36352
Tue 10Jan95 21:45:00.0 3.28 20.17 36334
Tue 10Jan95 21:45:30.0 3.28 20.11 36315 <--
Tue 10Jan95 21:46:00.0 3.28 20.64 36297 <--
Tue 10Jan95 21:46:30.0 3.28 20.58 36278
Tue 10Jan95 21:47:00.0 3.28 20.52 36259
Tue 10Jan95 21:47:30.0 3.28 20.46 36240
Tue 10Jan95 21:48:00.0 3.28 20.40 36221
Tue 10Jan95 21:48:30.0 3.28 20.34 36202
Tue 10Jan95 21:49:00.0 3.28 20.28 36182
As can be seen, the (EAST) longitude of the subsatellite point is decreasing
until 21:45:30 by 0.06 degrees per 30 seconds. Therefore, at 21:46:00 it
should be 20.05 deg but it is 20.64 deg, i.e. there is a jump of 0.59 deg and
in the opposite direction. This is clearly wrong.
By contrast, my own program does not exhibit this jump (I am using WEST
longitudes, hence the minus sign):
Date Time (UTC) Geocentric Subsatellite Point
RA Dec Lat West Long
----------------------------------------------------------------------
10Jan95 21:40:00 +06:23 +03:16 +3.26 -20.77
10Jan95 21:40:30 +06:23 +03:16 +3.26 -20.71
10Jan95 21:41:00 +06:23 +03:16 +3.26 -20.65
10Jan95 21:41:30 +06:24 +03:16 +3.26 -20.59
10Jan95 21:42:00 +06:24 +03:15 +3.26 -20.53
10Jan95 21:42:30 +06:24 +03:15 +3.26 -20.47
10Jan95 21:43:00 +06:24 +03:15 +3.26 -20.41
10Jan95 21:43:30 +06:25 +03:15 +3.26 -20.35
10Jan95 21:44:00 +06:25 +03:15 +3.26 -20.29
10Jan95 21:44:30 +06:25 +03:15 +3.26 -20.23
10Jan95 21:45:00 +06:25 +03:15 +3.26 -20.17
10Jan95 21:45:30 +06:26 +03:15 +3.26 -20.11 <--
10Jan95 21:46:00 +06:26 +03:15 +3.26 -20.05 <--
10Jan95 21:46:30 +06:26 +03:15 +3.26 -19.99
10Jan95 21:47:00 +06:26 +03:15 +3.26 -19.93
10Jan95 21:47:30 +06:27 +03:15 +3.26 -19.87
10Jan95 21:48:00 +06:27 +03:15 +3.26 -19.81
10Jan95 21:48:30 +06:27 +03:15 +3.26 -19.75
10Jan95 21:49:00 +06:27 +03:15 +3.26 -19.69
My implementation of the SDP4 code is a translation to Microsoft Professional
Development System 7.1 (which is a close relative of MS QuickBasic 4.5) from
T.S. Kelso's PASCAL code which in itself is a translation from FORTRAN. The
deep space routines of the PASCAL code reflect some FORTRAN features, in
particular calculated return addresses from GOSUB's, and these constructs
can easily be misinterpreted or overlooked when converting the FORTRAN code
to other languages.
Apart from the jump, TRAKSAT and my own program agree very well in the
longitude of the subsatellite point, but there is a small discrepancy in the
latitude for which I have no explanation. I take the Earth's flattening into
account, although not with very high precision, and perhaps TRAKSAT does not.
At any rate, the comparision of results from different programs which have
undergone several coordinate transformations is problematic. More direct
comparisons could be made with the cartesian coordinates which the various
NORAD models produce as their native output.
Finally, a consolation for the users of satellite prediction software: The deep
space model is only used for satellites with a period of more than 225 minutes
i.e. less than 6.4 revolutions per day. Most observers will be concerned with
faster moving objects, hence the flaws in the SDP4 code are of no practical
consequences for them, but program developers should of course pay attention
to this problem.
Bruno Tilgner
Paris, France
Bruno_Tilgner@compuserve.com