Satellite Tracking (Update)

In a previous post I discussed the possibility of tracking satellites through the use of 9 degrees of freedom (9DOF) sensors to indicate the position of an otherwise arbitrarily positioned antenna.

Interestingly enough a kind reader pointed out to me a recent publication of a nearly identical solution to what I had envisioned.  Not wanting to necessarily duplicate the work of someone else, I faced the dilemma of continuing my efforts without reference to this other body of work or not.  It would be nice if the other author had done a poor job and I could improve on his work by publishing an update with an improved implementation.  However, I would find it difficult to improve on the work that has already been published.

So, my solution is going to be to recommend that you go take a look at the fine work done by Elwood Downey over at http://www.clearskyinstitute.com/ham/AST/ and leverage the excellent write-up and complete code listings if you are interested in building such a device.

I will be taking my own advice and implementing Elwood's solution, no doubt customizing things along the way.  Once I have that functional, I will publish an article here on my implementation of his work.

Nice work Mr. Downey!

Satellite tracking

The beginnings of a new project.  Software is coming together, but now it's time to pull together the hardware.  This will be an antenna azimuth/elevation  satellite tracker.  In previous posts I have explored the calculations necessary and the details of using hobby servos to create a simple proof of concept.

For now I am experimenting with the ATMega2560 board (on the left) as it has plenty of flash and RAM space for the task at hand.  I plan to control the device via a web page that it serves up, so for now I have an ethernet shield attached, though in the end the plan is to use WiFi.

Calculating satellite passes requires an accurate position for the observer in terms of latitude and longitude, but also elevation and time-of-day.  I am using a GPS module to provide this information (lower right).

While the mighty ATMega2560 is certainly capable of generating the necessary PWM signals to position servos, I have decided to offload that to separate controller based on the PCA9685 which provides I2C interfacing of 16 channels of 12 bit PWM data.  This particular board was originally intended to be used as an RGB LED controller, but my plan is to re-purpose it for this task.  It has its own internal 25 MHz oscillator that offloads the ATMega2560 from having to generate these signals.  That, plus the fact that I happened to have one on hand drove the decision to use this component to drive my servos.

After spending some time in the Avionics industry and working on electronic aviation attitude indicators, the math involved in Euler angle solutions to the orientation of a rigid body, plus the mapping of raw gyro, accelerometer and magnetometer sensor data into 3D space is a bit tedious.  Fortunately for me, Bosch has done an amazing job of taking MEMS data from on-die sensors and adding an ARM Cortex M0 processor to produce a single chip solution that abstracts away all the raw sensor fusion and spits out data directly in quaternions, Euler angles or vectors.

The plan is to use this sensor mounted on the antenna fixture to measure azimuth and elevation relative to the calculated position on earth with no careful alignment of antenna orientation required.  The Arduino will accept keplerian elements for the desired satellite and then automagically track the spacecraft as it passes overhead.

More updates as this comes together into a demonstrable solution.

Arduino Satellite/Sun Tracking

I have put together the recent bits and pieces of test code that I have been playing with to control my AZ/EL servo camera mount and an Arduino port of the old Plan13 code, originally written in Basic back in 1983 by James Miller G3RUH.  You can read about his efforts over on the AMSAT web site here.  Jim gives a great treatment of the math involved and example code in Basic.

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!

Satellite Tracking with Propeller (cont)

Well, I am going to set this aside for a little while and do other things as I am a bit tired of the project.  I calculated a perigee pass for AO-51 at .02 km.  Hmmm...  I am thinking that at less than 70 feet, that might be a little low, eh?  :)  Ah well...  Obviously I have work to do.  But, for now this one is shelved and I will come back to it when more refreshed.

Satellite Tracking with Propeller (cont.)

Good progress today.  I am actually down to the place where I am debugging the SGP4 implementation.  I have initially hardwired the observer's position to be the lat/lon for my home QTH.  I also do not handle deep space objects or deal with geostationary objects yet.

All the pre-calc work is done and the SGP4 calculations have completed.  The post processing code has some problems that I am working on, but now it is time for sleep.

Satellite Tracking with Propeller

Work continues to build a SGP4 object implementation on propeller.  Getting the mathematical expressions correct is at best painful.  I have been converting a C language implementation into spin little by little.  I have written some utilities to assist with that conversion and progress is more quick now and less error prone (I hope).  I use the FPU utilities provided to convert the math expressions into FPU assembly language and then run through my utility to convert that to spin.

I could really use some insights into how to validate the results.  I can of course always compare results against the version I am converting from, but who is to say that it is correct?  Ideally there would be a standard test kep set and a standard observation location that would create known results that could be validated.

The SGP4/SDP4 specification does speak to this a bit, but my understanding of it is not yet adequate to evaluate.  If anyone has insights here, I could use some advice.