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 later.) 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