A port of the code described on the page above has been made to the Arduino and I leveraged this code from the QRPTracker project web site. With some simple changes, I have pulled together a simple satellite tracker to drive my AZ/EL camera mount. It should be simple to scale this up to drive an actual satellite antenna array.
Here you can see the project pointing to the point in the sky where the ISS would be located at a point in time today. I took the AMSAT Keplerian elements and processed the six passes today where the satellite was above the horizon at my location. The code currently processes the entire 24 hour period in a day, and tracks in real time each of the passes.
The implementation of Plan13 is not particularly accurate due to the limited precision available in single precision floating point on the Arduino, but with the broad bandwidth of most amateur 144 and 440 MHz antennas, it is of little consequence even if the accuracy was only to the degree level. In fact most low earth orbital satellites can be worked with a fixed elevation on a standard yagi, but the project has been interesting. If there is interest, I will post my code, though most of it was gleaned from the efforts of others.
Beyond the code I have previously published, I have changed the mapping of the azimuth servo to be clockwise from north to match a magnetic compass. I limit the calculated elevation values to those angles physically possible with my AZ/El mount. I prevent movement of the servos if the satellite is currently below the horizon.
I would like to put a real-time clock in the circuit and have it calculate and pre-position the antenna to the point where the satellite rises, add a simple display, add the ability to load Keplerian elements from a wifi connection to the internet and provide for calibration of the servos.
On an Arduino Uno, I am able to load the entire two line elements (TLE) set from here into flash. I have written a routine that will print out the start of every visible pass for my location for every satellite in the list (89 of them). I suspect that it will be unusual to have the entire set in flash at any given time, but it can be done and still have room for the code. Alternatively a storage card could be used to store the data.
On the mighty Arduino Uno, this table fills much of the flash and calculating the position of all 89 satellites for every minute of a 24 hour period takes quite a while. A better approach might be for the process that grabs the KEPS also pre-calculate the start of pass and just generate a table along with the KEPs table. This table could then drive a higher level process to allow the selection a which satellites you want to track today.
The code calculates the effects of doppler and provides a tuning frequency for both the uplink and downlink if the frequencies are provided prior to the calculation. For now I am passing in zeros, but a table of satellite frequencies and a bit of glue code to drive tuning a transceiver could fully automate tracking and tuning tasks.
This has been lots of fun and a precursor to building a LEO satellite station, but for this particular hobby AZ/EL mount, my next task will be to calculate the position of the sun and use this mount to keep a small solar panel array pointed at the sun for battery charging. For that particular task, I am thinking of trying out a couple of approaches. The first would be to calculate the position of sun relative to me as an observer. The second would be to use an analogue approach where the output of the solar panel is used as feedback to drive a correction to the AZ/EL servos to keep the panel at maximum output regardless of the position of the sun. I suppose in theory, I could just set the device out in the sun and let it figure out where to point to maximize output. Who knows, it might decide to point at a white wall rather than at the sun when currently behind tree cover for example. Should be fun!
On an Arduino Uno, I am able to load the entire two line elements (TLE) set from here into flash. I have written a routine that will print out the start of every visible pass for my location for every satellite in the list (89 of them). I suspect that it will be unusual to have the entire set in flash at any given time, but it can be done and still have room for the code. Alternatively a storage card could be used to store the data.
On the mighty Arduino Uno, this table fills much of the flash and calculating the position of all 89 satellites for every minute of a 24 hour period takes quite a while. A better approach might be for the process that grabs the KEPS also pre-calculate the start of pass and just generate a table along with the KEPs table. This table could then drive a higher level process to allow the selection a which satellites you want to track today.
The code calculates the effects of doppler and provides a tuning frequency for both the uplink and downlink if the frequencies are provided prior to the calculation. For now I am passing in zeros, but a table of satellite frequencies and a bit of glue code to drive tuning a transceiver could fully automate tracking and tuning tasks.
This has been lots of fun and a precursor to building a LEO satellite station, but for this particular hobby AZ/EL mount, my next task will be to calculate the position of the sun and use this mount to keep a small solar panel array pointed at the sun for battery charging. For that particular task, I am thinking of trying out a couple of approaches. The first would be to calculate the position of sun relative to me as an observer. The second would be to use an analogue approach where the output of the solar panel is used as feedback to drive a correction to the AZ/EL servos to keep the panel at maximum output regardless of the position of the sun. I suppose in theory, I could just set the device out in the sun and let it figure out where to point to maximize output. Who knows, it might decide to point at a white wall rather than at the sun when currently behind tree cover for example. Should be fun!
Jeff, you say:
ReplyDeleteI would like to put a real-time clock in the circuit and have it calculate and pre-position the antenna to the point where the satellite rises, add a simple display, add the ability to load Keplerian elements from a wifi connection to the internet and provide for calibration of the servos.
Yeah, add a Esp8266 to the circuit, and then get the a Time Update via UDP NTP. Also, you could provide the desired Web Interface? Yeah, I know, I can hear you say: "You just like the Esp8266 !!", . . yep !
I actually have an ESP8266 on an Arduino shield to work with, so that is part of the thinking. I would probably not create a solution that requires web access to work however. Web access to get the tables on an occasional basis, but probably not to get the time or make a UI for it directly via a web page. If I was going to do that approach, I would have it just be an IOT sensor that could be commanded and read and then implement a web page on a hosted server to talk to it as opposed to having it serve up web pages.
DeleteI tested the difference in P13 code between using float and double and the difference in topocentric az and el was only about 0.01 degrees. Far more important are the sidereal and solar constants. You can get updated values from the original P13 post at http://www.amsat.org/amsat/articles/g3ruh/111.html (see notes after the code listing). With the old values I was seeing errors of nearly a degree but with these values, the results even with float are within about 0.1 degrees compared to a full up SGP4 propagator. All tests were done using day-old elements for AO-07.
ReplyDeleteForgot to mention, there's a much cleaner implementation, IMHO, of P13 by Mark VandeWettering (of brainwagon.org fame) at https://github.com/brainwagon/angst.
ReplyDeleteThanks for the results of your testing. I certainly didn't do any comprehensive testing of the error rates. With typical beam widths of satellite antennas, it is completely adequate.
Delete