More SDP4 business

27 Mar 1997 19:19:08 -0800

Hi Curtis,

Saw your reply on Seesat-L.  Thought I'd catch you up on the current state of
affairs.  You wrote:

> I was somewhat surprised by the large disagreement between SGP
> and the supposedly more accurate SDP4 model that was reported by
> Rainer. I tried to reproduce the discrepancy using my own software,
> but I could find no great difference between the output using SGP
> or SDP4 for the case he mentioned.
> ... when I looked closely at Ranier's analysis of the problem
> in the DEEP.FOR code, I ran across an inconsistency.  He stated,
> "This causes an error of about 4 deg in the predictions, because
> XNODES and ACTAN(ALFDP,BETDP) are taken from different
> quadrants!
>XNODES is derived from the RAAN of the elset (331.8258), which is
>in the range of 0 to 360 deg. The ACTAN-function yields angles in
>the range of -180 to 180 deg.

Shortly after this post, Rainer realized that the ACTAN function was not an
intrinsic function, but one included with SR #3.  The ACTAN function coded
there works fine, even though the code is pretty ugly and frankly unnecessary.
 [The expression "Pi - ATAN2(-Y,-X)" can completely replace this function.]

Rainer's implementation failed because the ACTAN function in the *PASCAL*
version is wrong.  (It returns values for quadrant #4 between -90 and 0
degrees, instead of 270 to 359.999).  He has since made the necessary
correction to that function, and his test case no longer shows the 4-degree
OMGASM discrepancy.  (The SDP4 results are STILL wrong however -- more on that

Even with a good ACTAN function, the Lyddane modification in Spacetrack Report
#3 will still fail under certain circumstances.  I'll put together a test case
for everyone to play with which will fail on every implementation of SDP4 out
there that I'm aware of.  The failure is based on the simple fact that if
angle A is from 0 to 360 and B is from 0 to 360, the quantity ABS(A-B) can be
close to 360 when A and B are nearly the same phase, but one is in quadrant 1
and the other in quadrant 4.  (Example:  A = 1 degree, B = 359 degrees; 
ABS(A-B) is 358 degrees.)  Extra logic is required to come up with the correct
answer of 2 degrees in this case.  (I've made this correction in my own code).

As I eluded to earlier, SDP4 (as coded in SR #3) still has problems with the
solar/lunar perturbations.  Specifically, they should be zero at epoch.  They
aren't.  Actually, it's not that there is no solar/lunar perturbation at epoch
-- there is.  But the two-line elements are supposed to give an accurate
satellite position at epoch.  Whatever the S-L perturbations are at epoch,
they're factored into the elements.  What the code *should* do is determine
what the S-L perturbation was at epoch, and use it as an offset for all
subsequent times.

For example, suppose the S-L perturbation works out to +.35 degrees in right
ascension of ascending node at epoch.  You shouldn't add that +.35 degrees to
RAAN when determining the satellite position at epoch.  It's already right. 
Instead, when you later want to know the satellite RAAN at, say, 4 days after
epoch, you should calculate the unperturbed RAAN at that time, calculate the
S-L perturbation at THAT time, and then SUBTRACT +.35 degrees before adding it
to the unperturbed RAAN.

This is, at it turns out, what they try to do in Spacetrack Report #6.  (SR #6
has another problem, but I'll save that for another day).  Anyway, this
probably partly answers your last question:

> The question of problems with SDP4 (and DEEP) is an interesting
> one.  I am not a professional programmer and not connected with
> the aerospace industry, but I wonder if any of the "insiders" in US
> Space Command might tell us if they really are using a "corrected"
> version that differs from the code published in Spacetrack Report
> No. 3 in 1980?

Yes, most definitely, they do not use Spacetrack Report #3.  I, myself, am
using a hybrid of SR #3 with SR #6, plus additional corrections/changes that
don't appear in either.  These will all be incorporated in the next release of
SkyMap, which you may have seen mentioned here on Seesat.  --Rob