Earth Satellite next_pass gives different values over NASA website for the ISS

[rdenadai]

Hi, great job with pyephem. Im facing the following problem... im trying to calculated the next 5 passes of the ISS over my town, and it gives me different values than the NASA web site http://spotthestation.nasa.gov.

Looking at the next passing time on the web site, it gives me the following: http://spotthestation.nasa.gov/sightings/view.cfm?country=Brazil&region=None&city=Campinas#.VGNKRrtyi8M

Date: Fri Nov 21, 9:40 PM Visible: < 1 min Max Height: 16° Appears: 11 above SSW

Disappears: 16 above S

Using the following script in pyephem: http://pastebin.com/KpgsLYM6

running the script above it returns: rise: 2014-11-21 22:01:26 set: 2014-11-21 22:05:22 rise eclipsed: False set eclipsed: False rise az: 147.830114547 set az: 126.942467159 rise sun_alt: -7.07382415214 set sun_alt: -7.50473865244

the DATE are correct but the TIME of rise and set are not... if we run the same script for Sydney (Australia) the results are also different. Im using pyephem correct? Or am i missing something?

Also, this is not related to pyephem, but i was checking in Skyfield if there's a way to do the calculation pass of the ISS?

Thanks, and great work

[wenzul]

Hi rdenadai, look at that pass. It's a very short one. So first: it highly depends on the TLEs you will use. Just print your passes without all the restrictions and assumptions you have done. For example pyephem predicts this pass about a sun altitude of -30. You have to play around with these values. I don't know how accurate pyephem calculates the eclipsed values. Because in your case eclipsed is already True in both rise and set. Also take care of timezones, you picked the wrong pass. The unfiltered output follows:

rise: 2014-11-21 23:35:32.541003
set: 2014-11-21 23:46:09.495516
rise eclipsed: True
set eclipsed: True
rise az: 133.069652278
set az: 58.6996565951
rise sun_alt: -26.2082059492
set sun_alt: -27.1575834608

Also take a look at the datetime functions which provides you datetime from ephem.Date objects. For example:

rise_time = tr.datetime()
set_time = ts.datetime()
duration = (set_time-rise_time).total_seconds()

[rdenadai]

Hi @wenzul thanks for the response. Well, the TLE data im using came from celestrak link (http://www.celestrak.com/NORAD/elements/stations.txt)... suppose to be the most update resource right?

The raw output you printed there it doens't seem equal compared with heavens above link you pass... the only thing that is correlated is the date, and some of the time, but the azimuth are different.

From pyephem docs: On artificial satellites, also sets: eclipsed — Whether satellite is in Earth’s shadow So the eclipsed settings must be false, so that a satellite must be visible to the Observer right?

Also, don't know if the exacly thing is related to this => https://github.com/brandon-rhodes/pyephem/issues/2

Sorry to put more questions on that...

[wenzul]

Yes, TLE source should be right. But after 1 or 2 weeks it will shift away.

I know the eclipsed flags. I think they are almost right but you have still a bit inaccuracy. The point I want to make, for short passes it may differs with other sources. Anyway, that was not the point here.

There is a mistake in the order of your code. I used just a simple example now. I think you have to look in the order you compute for different objects.

rise: 2014-11-21 23:35:29.011399
set: 2014-11-21 23:46:07.759043
rise az: 208.449382147
set az: 58.7077093881

Furthermore it now looks not like an issue here but rather for stackoverflow. I hope you can fix it in your code with that snippet. Good luck. :)

[rdenadai]

@wenzul ok... i gotted! You are totally right, it was my ignorance that was blurring my thought on this. The max time and set time, were not represented on the heavens above web site, so there was my confusion... i think i got to much envolved in trying to find where i was wrong the missed the small things... anyway, thank you very much for the help and elucidating my question.

Next time i put those kind of doubt on stackoverflow.

cheers!

[wenzul]

But you were right that the rise azimuth was not equal. With your code I got 133 and then correct it to 208.

[rdenadai]

yes, you are right, the function i was using it was not giving me the correct value for this... using numpy rad2deg as you use, correct that issue... its good to know!