Wrong results .. comparison with gpredict and pyephem

[alexschultze]

I recently started to try to compare a specific observation to see how the different free programs perform. I could not get the right value out ouf pypredict. The complete observation Is in the second post here:
https://stackoverflow.com/questions/18763484/wrong-range-rate-with-pyephem/29500861#29500861

Your input is very welcome. :)

[LongHairedHacker]

I can confirm this.

Comparing with gpredict the timing is off about a few minutes as well as all the peak elevation values.
Based on the sattelite signals I captured, the gepredict values should be correct.

Reading all the bugs in this tracker I came across #9.
Negating the second component of the station tuple yields similar values to gpredict.
(I assume +-2seconsds and +-0.3° can be marked of as rounding errors.)

[jerematt]

In the stackoverflow post linked, it seems to use a qth of (0,10,0) in the pypredict example even though it uses the observation point of (0,0,0) in gpredict/pyephem? any reason why? Changing the qth to (0,0,0) for pypredict seems to yield the same result as the other tools used.
As for non-zero observation points, then yes issues #9 and #20 apply - the qth uses West rather than East for its second parameter due to the underlying predict implementation.

Closing as a duplicate of #20 (and #9) for the East/West difference, feel free to re-open if that's not correct.