Hi Bruno, You wrote: "A more fundamental fix to this problem, which might occur in more places of the code, is to replace the ACTAN function by the function ATN2 which, if it doesn't already exist in the programming language used, can be written in such a way as to always yield a result in the range 0... 2*pi. That's what I have done about 5 years ago." Actually, Rainer has since realized he was mistaken about the ACTAN business. ACTAN is not an intrinic function, but a user-defined function included with Spacetrack Report #3. It's an ugly function as coded there, but it works, returning values from 0 to 2*Pi. It is the ACTAN implementation in the PASCAL version (that I believe T.S. Kelso coded) that is flawed (it doesn't always return values from 0 to 2*Pi). But this ACTAN function is completely unnecessary. I never coded it. As you pointed out, every decent programming language has a 2-argument arctangent function that is quadrant-preserving. For my FORTRAN, it's ATAN2(Y,X), where Y is the sine of the angle, and X is the cosine. It returns values from -pi to +pi. A simple change will return values from 0 to 2*pi: Angle = Pi - ATAN2(-Y,-X) Not surprisingly, they got rid of the ACTAN function In Spacetrack Report #6. And the coding of the deep space routines in SR #6 contain some of the very code fixes we've come up with for SR #3. But the coding in even SR #6 is flawed. Some time in the next few days, I expect to be perhaps the first person ever to be running an implementation of SDP4 *as it was originally designed by R.S. Hujsak and Felix Hoots*. I can tell you that anyone running SDP4 based on SR #3 is getting the wrong results. They may seem accurate most of the time, but the solar/lunar perturbations are not correctly accounted for. (They should be zero at epoch, and aren't). --Rob