by Travis Goodspeed <travis at radiantmachines.com>,
as presented at Summercon 2013,
inspired by the lectures of Adam Laurie and Jim Geovedi,
with kind assistance from Skytee.
At Black Hat DC in 2008, I watched Adam Laurie present a tool for mapping Ku-band satellite downlinks, which he has since rewritten as Satmap. His technique involves using an DVB-S card in a Linux computer as a receiver through a 90cm Ku-band dish with fixed elevation and a DiSEqC motor for azimuth motion. It was among the most inspirational talks I'd ever seen, and I had a blast recreating his setup and scanning the friendly skies. However, such a rig is limited to geostationary satellites in a small region of the sky; I wanted to see the whole sky, especially the moving targets.
In this article, I'll demonstrate a method for modifying a naval telecommunications dish to track moving targets in the sky, such as those in Low Earth Orbit. My dish happily sits in Tennessee, while I direct it using my laptop or cellphone here in Europe. It can also run unattended, tracking moving targets and looking for downlink channels.
This is my dish, originally a Felcom 82B from Furuno, intended as a mobile earth station on maritime vessels. It would connect to one of the Inmarsat satellites in geostationary orbit, using mechanical gyroscopes to correct the dish against the ship's movements. My use case is the opposite, trying to track moving targets from a stationary ground position.
The first of several modifications was to place the motors under computer control. Rather than build dedicated electronics, I took the lazy route and wired an EiBotBoard into a BeagleBone for motor control. I wired things such that the first motor is Azimuth and the second motor is Elevation, with the Tilt motor disabled.
When testing the stepper motors, I found it handy to have a second EBB that was wired into standalone motors, so that my control software could run away from the dish. The EBB appears to its host computer as /dev/ttyACM0, and it's easy to test the motors by directly sending commands. To move both motors slowly forward 400 steps for three seconds, run echo "SM,3000,400,400" >>/dev/ttyACM0 on the BeagleBone. To do this from software, a control application can simply open /dev/ttyACM0 as a file and write the relevant commands into it.
In case the Azimuth or Elevation become lost, I really don't want to travel for two days just to lift the radome and recalibrate. For that reason, we painted the twelve hours of a clock inside of the radome and added a webcam. When lit by the Sun, the camera can be directed to twelve o'clock in order to ensure the dish itself is pointed nearly South. Finer calibration is performed by radio against geostationary targets.
For handling the radio input and controlling the motors, I have a BeagleBone wired into a USB hub. These are all mounted on the trunk of the assembly inside of the radome, sending data back to a server indoors. Unfortunately, I couldn't fit everything over the assembly's original ring connector, so an umbilical cord connects the dish to the outside world. To prevent this cord from tangling, software prevents the dish from spinning more than 360 degrees in azimuth.
Additionally, I wanted input from an Inertial Measurement Unit. While definitely a luxury rather than a necessity, this allows for direct measurement of the dish's elevation. In future rebuilds, I'll use a much cheaper accelerometer. The unit I chose was a VectorNav VN100, as its UART output could run directly to the BeagleBone without requiring another USB port.
In order to operate the dish, I wanted both a flashy GUI and concise scripting, but scripting was the higher priority. Toward that end, I constructed the software as a series of daemons that communicate through a PostgreSQL database on a server inside the house. For example, I can run SELECT * FROM sats WHERE el>0 to select the names and positions of all currently tracked satellites that are above the horizon. To begin tracking the International Space Station if it is in view, I run UPDATE target SET name='ISS';.
These daemons run on two machines, with everything computationally intensive on an AMD64 server and everything that needs to be locally within the radome on a BeagleBone.
For predicting satellite locations, I wrote a quick daemon using PyEphem that fetches satellite catalog data from CelesTrak. These positions are held in a database, with duplicates filtered out and positions constantly updated. PyEphem is sophisticated enough to predict in any number of formats, so it's easy to track many of the brighter stars as well as planets and deep-space probes, such as Voyagers 1 and 2.
In addition to knowing where the satellites are, it's also necessary to know where the dish is and how the dish is tilted. For this, I have one daemon to watch my IMU's input and a second daemon to control the motor. These two are both used to predict the position, as the motor daemon does dead reckoning to compare against the IMU daemon's values.
Finally, there are a few different daemons and clients for directing the targeting of the dish. Generally, I run one slow background process to retarget every fifteen minutes, so that I can take manual control of the dish using a GUI application.
Once the daemons were running smoothly, I tossed together a GUI using Pygame and the same database library that the daemons use. The GUI is operated by keyboard and mouse commands, with a left-click targeting an object and a right-click targeting a position. Named stars can optionally be shown in the background and moving targets are tracked as they move.
In the screenshot above, the dish is aimed at GOES 3 and has just been ordered to aim at Voyager 1. Future enhancements to the GUI will show radial views and offer some control or visualization of the radio data.
Being written in Pygame, I can run the same exact code on both my laptop and my phones. Coding new features while bored on the Ubahn is a lot healthier than Angry Birds or Sudoku.
My initial build using an RTLSDR dongle. Data processing is done on my server, with the BeagleBone forwarding data from rtl_tcp. To avoid offending the FCC and ham radio operators everywhere, I disabled the dish's 1.5GHz transmitter and use only the 1.6GHz downlink antenna. If I can justify the extra weight, I'd like to drop the RTLSDR in favor of a USRP2 over Gigabit Ethernet in order to get greater bandwidth and sensitivity.
Recordings are stored either as raw I/Q data or as a simple signal strength indicator from the Power Spectral Density (PSD) function. In the near future, I hope to automatically adjust the aim of the dish in realtime based upon the signal quality feedback.
When time and travel allow, I plan to replace the old Low Noise Amplifier (LNA) with one that has wider bandwidth. I'm also hoping to add support for new radio bands either by swappable antennas or by adding more antennas to the collection.
Thank you kindly.
As a final note, I'd like to thank Skytee for trekking six timezones to help me out with this. Thanks are also due to my next-door neighbors for not panicking when they thought I was talking to aliens.