Mark, I dug into the PyEphem code a bit and slapped together my own script that will:
- snatch the latest keps from amsat.org - find all passes taking place within the next N minutes ( this is configurable) - provide the user with text / verbal status updates on whatever interval desired. Feel free to take a look here: http://libjoe.blogspot.com/2009/10/where-is-my-satellite-in-python.html For the record, DO NOT SET LAT OR LONG TO A DOUBLE VALUE. Sorry for screaming but... sometimes... you just have to :-) I had a bit of test code that I wrote and took forever trying to figure out why my local pass times were not coming out correctly. It turned out that the UTC times were off as well... I traced this back to initializing my lat/long observer values using a doubleobject as opposed to a stringobject. You have been warned. I sure hope I didn't miss this in the documentation somewhere... All I could find on these in the documentation (without any digging into any of the code) was: These are the attributes you can set: date — Date and time epoch — Epoch for astrometric RA/dec lat — Latitude long — Longitude elevation — Elevation (m) temp — Temperature (°C) pressure — Atmospheric pressure (mBar) Joe On Sep 28, 2009, at 2:06 AM, Mark VandeWettering wrote: > I just thought I'd drop a quick note here about some fun I've been > having today with satellite orbit prediction in Python. When I > started mucking around with satellites, I used "predict", which was > pretty good, but at some point I wanted to answer some questions which > weren't easy to answer using predict. Questions like "when will > AO-51 be visible from both my home in CM87 and locations in Hawaii", > or "what was the radius of the circle of visibility for AO-7 compared > to ISS"? > > Luckily, I'm a programmer. In fact, I'm a programmer who programs > for fun. So, I did a bit of research, and then coded up a version of > G3RUH's "Plan 13" algorithm in Python, and then wrote some scripts to > download elements from celestrak, and then a simple one to print data > on the next pass of any named satellite. And, they worked pretty > good. I've used them for the last year or so to do all my pass > predictions. But there are still a couple of minor issues with the > library. It didn't handle geosynchronous satellites very well. It > implemented only the most basic of orbital models. I was never > confident that the "is this satellite in eclipse" stuff working > exactly right. > > Luckily though, it turns out that someone else has been busy writing a > more complete library: PyEphem http://rhodesmill.org/pyephem/ > > It's a library whose primary purpose is to calculate the positions of > astronomical objects. I've used it a couple of times to (for > instance) figure out the size of Mars compared to Jupiter, and found > it very easy to use. But today, I realized that it had a full > implementation of the SGP4 and SDP4 orbital models built in, and could > be used to predict satellite passes. As a proof of concept, I > hacked together a 23 line script that could print the details of > upcoming ISS passes. It seems to work great, and is really quite > easy to use. > > You can find some of the simple example code at my blog: > > http://brainwagon.org/2009/09/27/how-to-use-python-to-predict-satellite-locations/ > > I'll probably be porting all of my existing scripts to use this soon. > In the mean time, if you have a similar task, you might look to it to > solve your custom satellite prediction problems. > > 73 Mark K6HX > _______________________________________________ > Sent via [email protected]. Opinions expressed are those of the > author. > Not an AMSAT-NA member? Join now to support the amateur satellite > program! > Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb _______________________________________________ Sent via [email protected]. Opinions expressed are those of the author. Not an AMSAT-NA member? Join now to support the amateur satellite program! Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
