My interest in microcomputers and the International Space Station developed together. Early in my exploration of microncomputers, I wanted to make something that could track celestial objects through the sky. The Sun, Moon, and planets were early candidates. Then I found this — a 3D-printed satellite dish that moves!
I had no idea that you could see the ISS as it passed overhead — sometimes high in the sky, sometimes low. Sometimes for a long time, sometimes for a short time. In fact, the ISS is “overhead” about six or seven times a day — but you can’t see it in the daytime, you can’t see it when it’s in the Earth’s shadow, trees and houses block your view when it’s low to the horizon, and you can’t see it when it’s cloudy.
Inspired, I decided to build my own satellite dish that would point to the ISS and track it as it passed overhead. Along the way to the finish line, I learned about celestial navigation, star magnitudes, azimuth and altitude/elevation, two-line elements, stepper motors, and more.
Baby Steps
There were many. things I needed to learn before I could put everything together.
- Can I determine when the ISS would be visible at my location?
- Can I print a number that would tell me where in the sky the ISS is right now?
- Can I get an arrowhead on a stepper motor to point to a dial face indicating the altitude and direction to look and see the ISS?
- Can I print and drive a satellite dish?
- How do I calibrate the dish?
Pieces of the puzzle
One of the resources I used in the final design is https://api.n2yo.com. This is a REST API.
You send it some parameters, you get data back. According to the author,
“The purpose of the API is to provide data for software/web developers to build satellite tracking or prediction applications.“
Another API resource is https://forecast.weather.gov which gives me a measure of cloud cover expected during a future pass. (There’s no point setting an alarm for 3am to see a passing if it’s completely clouded over!)
I wrote getpasses.py to run on a headless Raspberry Pi Zero W. getpasses.py queries the https://api.n2yo.com and the https://forecast/weather.gov REST APIs. It then prints a table of visible and/or invisible passes. (Lately, I only do visible passes, but during development I also did invisible passes so that I could run tests even when the Sun was shining.) Here’s what getpasses.py logs.
sAZ sAL maxAz maxAl eAZ eAL mag dur clouds Oct-17 10:35 Oct-17 05:35 V 230.55 36.06 Oct-17 05:40 141.16 78.83 Oct-17 05:46 56.20 0.32 -2.3 400 1% Oct-18 09:48 Oct-18 04:48 V 219.04 32.47 Oct-18 04:53 139.85 45.34 Oct-18 04:58 59.62 0.36 -1.2 255 2% Oct-18 11:25 Oct-18 06:25 V 262.14 11.00 Oct-18 06:30 336.08 29.17 Oct-18 06:35 51.39 0.33 -1.0 485 1% Oct-19 09:01 Oct-19 04:01 V 206.87 8.18 Oct-19 04:06 134.78 26.72 Oct-19 04:11 64.13 0.41 0.6 110 10%
(Scroll the table left and right to see all the columns)
Red timestamps are in UTC and green timestamps are in the local timezone.
The columns are
| Column | Meaning |
| sAZ | azimuth (compass direction) where the ISS will first appear above the horizon. |
| sAL | altitude of the ISS when it first exits the Earth’s shadow and becomes visible. (Altitude here does not refer to the height above the surface of the Earth. It’s an elevation — the angle you have to raise your arm to point to it.) |
| maxAz maxAl |
the azimuth and altitude of the ISS at its highest point in the sky. |
| eAZ eAL |
the azimuth and altitude when the ISS blinks out because it is below the horizon or has entered the Earth’s shadow — ending that pass. |
| dur | the number of seconds that the ISS will be visible on this pass. |
| mag | the brightness of the ISS. The more negative, the better. The ISS is BRIGHT! |
| clouds | the percentage of cloud cover. |
Calendar Updates
Every day at 3pm, getpasses.py runs and writes all this data to a file. This flat file is read by an Apple Script on my MacBook Pro that I launch manually. The script takes the details of each upcoming visual pass and adds an entry to my Calendar so that I can plan ahead and watch the pass live if I choose. The further out in time, the less accurate the prediction. By running getpasses.py daily, the predictions for future events are as accurate as can be expected.
A most critical function
getpasses.py does not track the ISS as it passes overhead. getpasses.py tells me when future passes will occur. It also adds a line to crontab for each visible pass. At the time of the predicted pass, the crontab line launches trackISS.py. It is trackISS.py that computes where the ISS appears at that instant and controls the satellite dish to point to the ISS as it moves across the sky.
Here’s a sample of what getpasses.py writes to crontab.
47 9 16 10 * /usr/bin/python3 trackISS.py -I 0.25 -z 180 >> ISSpath.txt 2>&1 # Oct-16 04:47 - ISS ISSv pass 16 -0.1 295 87% 22 11 16 10 * /usr/bin/python3 trackISS.py -I 0.25 -z 180 >> ISSpath.txt 2>&1 # Oct-16 06:22 - ISS ISSv pass 64 -2.1 545 80% 35 10 17 10 * /usr/bin/python3 trackISS.py -I 0.25 -z 180 >> ISSpath.txt 2>&1 # Oct-17 05:35 - ISS ISSv pass 79 -2.3 395 8% 48 9 18 10 * /usr/bin/python3 trackISS.py -I 0.25 -z 180 >> ISSpath.txt 2>&1 # Oct-18 04:48 - ISS ISSv pass 45 -1.1 250 2% 25 11 18 10 * /usr/bin/python3 trackISS.py -I 0.25 -z 180 >> ISSpath.txt 2>&1 # Oct-18 06:25 - ISS ISSv pass 29 -1.0 480 2%
Sky charts
A sky chart is worth a thousand words. The https://heavens-above.com web site provides a sky chart for each visible pass. It shows when visibiliy begins and ends and traces its path across the sky. Looking at the skychart gives you a much clearer picture of whether the pass is worth observing directly. Long trails high in the sky are great. Short, low trails are not. I review these charts each time I run the script to update the calendar.
Calibrating the dish
The physical dish and components are mounted onto a long board. To use the dish, you take the board outside and align the board along the North/South longitude. Once the board is aligned, you then need to adjust the dish so that it is pointing at the Southern horizon. When trackISS.py starts, it assumes the dish is pointing due South and zero altitude. These are arguments passed in on the crontab line. The simple stepper motors I use to move the dish can’t tell where the dish is pointing. calibrate.py is a program to manually put the dish into the proper orientation. I visually see if the dish is pointing South (180 degrees). It’s dead on or it’s either left of South or right of South. I’d empirically determined how many steps it takes to move the dish 1° (left or right). If I see the dish is too far to one side, I hit either the < or > to swivel the dish by 180° (x steps) in the appropriate direction.
If I overshot, South, I hit a key and backtrack 90°.
If I undershot, South, I hit a key and continue in the same direction but for only 45°.
I keep swiveling left or right by ever decreasing angles until the dish is either dead center on South. It’s a binary search for the correct position and only takes a few taps for even the most grossly misaligned dish.
The first thing trackISS.py does during a pass is to blink an LED a few times to warn bystanders that the dish is about to move. It also sounds a klaxon. (This annoyed my wife no end several times per night, so it has since been silenced.) trackISS.py accesses https://celestrak.org to get the list of two-line elements (TLEs) from NORAD. TLEs are literally two lines of numbers. Each space object tracked by NORAD has a TLE. The numbers in the TLE are updated daily and are used to calculate the position of that object at any future time. Here’s a sample of what NORAD provides. The TLE for the ISS is the first entry.
ISS (ZARYA) 1 25544U 98067A 26288.11220063 .00005682 00000+0 11168-3 0 9991 2 25544 51.6331 66.6267 0006716 264.3647 95.6576 15.48871015590345 POISK 1 36086U 09060A 26288.11220063 .00005682 00000+0 11168-3 0 9999 2 36086 51.6331 66.6267 0006716 264.3647 95.6576 15.48871015586433 CSS (TIANHE) 1 48274U 21035A 26288.24410899 .00023064 00000+0 27253-3 0 9995 2 48274 41.4694 312.8000 0000702 139.8855 220.2036 15.60756584311914
After initialization housekeeping, trackISS.py enters a loop with a 1/4 second delay. During each pass through the loop, trackISS.py calls the skyfield Python library to compute the azimuth and altitude of the ISS. trackISS.py doen’t care if the ISS is visible. It tells you the spot in the sky where the ISS is. Tracking works for visible and invisible passes.
Once the position is computed, trackISS.py sends commands to the two stepper motors. There is an imperceptible lag between computing the ISS position and the dish physically moving there. Since the starting position of azimuth: 180° and altitude: 0° was assumed, it’s easy to compute how many steps each motor needs to take to point to the actual ISS azimuth and altitude. After the ISS has gone below the horizon (a negative altitude), the dish parks itself back to [180°,0°]. That’s trivial. The dish knows how many steps each motor has taken during a pass and simply takes that many steps in the opposite direction.
Building the disk
I used the Thingiverse model that inspired me. Details of that build can be found on Thingiverse. I won’t repeat the details here.
Putting all the hardware together.
The main software components run on a headless Raspberry Pi Zero W. The Pi connects to two stepper motors — one for azimuth and one for altitude. Each stepper has its own driver circuit. There’s a warning led and a piezo speaker used for the klaxon. A 1602 LCD displays the current azimuth & altitude during a pass. The LCD is connected to the Pi through an Arduino board. A separate PyPortal sits near the dish and displays a map of the world with the position of the ISS. This display runs continuously to show the point on the Earth’s surface that is directly below the ISS.
Conceptually, it looks like this.
It actually looks like this:
Running the app
trackISS.py produces this log as it runs. Each time the azimuth or altitude changes, it prints a line. The line shows how many steps the motor needs to take (left/right or up/down) to move the disk into position.
Oct 14 11:20:08.251473 AZ 1 219.69 1250 225 cw 219.51 Oct 14 11:20:15.552479 AZ 19 219.51 1249 -1 ccw 219.34 Oct 14 11:20:22.507475 AZ 44 219.34 1248 -1 ccw 219.16 Oct 14 11:20:29.459123 AZ 69 219.15 1247 -1 ccw 218.99 Oct 14 11:20:35.853427 AZ 92 218.98 1246 -1 ccw 218.81 Oct 14 11:20:41.972600 AZ 114 218.81 1245 -1 ccw 218.63 Oct 14 11:20:48.095327 AZ 136 218.63 1244 -1 ccw 218.46 Oct 14 11:20:51.995606 AL 150 0.19 -1 -1 ccw -0.18 Oct 14 11:20:53.675497 AZ 156 218.46 1243 -1 ccw 218.28 Oct 14 11:20:54.802687 AL 160 0.36 -2 -1 ccw -0.35
trackISS log
Here is a video testing my calibration strategy.
Here’s a timelapse video of a live test tracking an actual, daytime pass. Overlayed is the position data as it is calculated.
Lastly, there’s a video of the first, night-time, confirmation that the dish really does point to the ISS. When the tree and rooftop come into shot, there will be an arrow pointing left. It’s pointing to a tiny, white dot moving left. THAT’S THE ISS! When the camera pans down to the apparatus, you can see the dish is pointing to the dot.
Future enhancements
There are things I’d like to change about my setup.
It’s not easy to move from the lab to outside or another site. The components are not glued to the board. It’s easy to knock something loose. I’d like to mount all the components onto a PCB and do away with most of the wires.
The dish itself is not level and plum. It kind of droops a bit and is held together with painter’s tape.
There’s a lot of backlash. The altitude motor is mounted on top of the platform that swivels through azimuth. That’s more mass to move than desired. I’d like to have both motors glued to the board and provide linkages to the moving parts.
I look forward to making those things happen. I just hope I’m done by the time the ISS is decommissioned and plunges back to Earth.
