search

nsat / pypredict

Spire port of predict open-source tracking library
GNU General Public License v2.0
64 stars 17 forks source link

Wrong results .. comparison with gpredict and pyephem #21

Closed alexschultze closed 4 years ago

alexschultze commented 9 years ago

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 commented 8 years ago

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 commented 4 years ago

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.