Hi Curtis, Well, I guess there's more to creating these test cases than meets the eye! The problem is that the quadrant problem with XNODES will either manifest itself when the old (unperturbed) XNODES crosses zero, or the new one does, depending on whether the original XNODES has been maintained in the range of 0 to 2*Pi. The XNODES in SR #3 could come into DPPER with a value greater than 2*Pi. And this is the case for you. But T.S. Kelso later modified DPPER to make sure XNODES was from 0 to 2*pi. If you've got this mod, the test case I gave will fail as advertised. (This is why TRAKSTAR fails -- it's got the Kelso mod). But without Kelso's mod, the code will *still* exhibit the bug. It just occurs when the perturbed XNODES crosses zero. In the case of the second example I cited, it happens a little less than an hour later. I recompiled my code to match yours in order to find the quadrant crossing time on the perturbed XMODES. It occurs between 14:42:30 and 14:43: UTC Date: 1/17/97 position in km UTC Time X Y Z -------- ---------------- ----------------- ----------------- 14:40:00 12058.6968436073 -9088.05059434088 -1604.73341693802 14:40:30 12207.3904182008 -9040.79898042420 -1596.37913955513 14:41:00 12354.8551383471 -8992.63608004684 -1587.86366489113 14:41:30 12501.0976325425 -8943.58238643458 -1579.19061502540 14:42:00 12646.1245522158 -8893.65787621351 -1570.36352079508 14:42:30 12789.9425652844 -8842.88202551640 -1561.38582463892 (jump) 14:43:00 13726.9960697113 -7532.85729295977 -1330.06349285878 14:43:30 13862.6766127548 -7467.35366752016 -1318.48402930620 14:44:00 13997.0964328723 -7401.16989068805 -1306.78421250686 14:44:30 14130.2638901796 -7334.32287724387 -1294.96703273207 14:45:00 14262.1872942258 -7266.82911673137 -1283.03540513679 So run your code at the later time. I'll bet you see the jump... --Rob Note to Bruno Tilgner: Could you try it also? Yours should fail too.