Gpredict, SGP4 propagation and the TLE set behind every prediction

Two-line element sets and the propagation algorithm behind them

Gpredict is a real time satellite tracking and orbit prediction program for the Linux desktop. The mechanism is stated in the first line of the README: it uses the SGP4 and SDP4 propagation algorithms together with NORAD two-line element sets.

That is the whole scientific content, and it is worth being precise about what it implies. A TLE is a compact description of an orbit, and SGP4 and SDP4 are the standard ways of propagating it forward to a given time to work out where the satellite will be. So the accuracy of any position Gpredict shows is bounded by two things: the age of the element set, since orbits drift and the set must be refreshed, and the accuracy of the propagation model, which is a general model rather than a per-satellite fit.

This is why the tool belongs to a specific audience. The topics attached to the project name amateur radio, ham radio, satellite, space, GPS, GNSS and AMSAT, and the home page is at gpredict.oz9aec.net, with the sign-off from the author carrying the amateur radio callsign OZ9AEC. An operator wants to know when a satellite will be visible from their location, how long the pass will last, and what the radio Doppler will be, and Gpredict is built to answer exactly those questions on a desktop with a map.

The scope claim in the README is that the number of satellites tracked is limited only by the physical memory and processing power of the computer, which is a reasonable framing for a propagation model that is cheap to evaluate.

Modules, ground stations and the several ways to look at a pass

The interface is built around modules, and that is the concept you have to understand before anything else. A module is a self-contained view, and Gpredict lets you have many of them open at once, either in a notebook-like arrangement or in their own windows, and they can also run in full-screen mode.

Within a module, the same tracking data can be shown in lists, on maps, as polar plots, or in any combination of those. A polar plot is the polar projection view that a radio operator uses to see where a satellite sits in its own orbital plane, which is the coordinate system that matters when the antenna is pointed by hand or by a rotator with azimuth and elevation limits. A map view answers the other question, which is whether the satellite is visible from where you are standing, and the list view is the numeric answer.

Ground stations are a first-class concept, and the README says you can use many of them. That matters because a pass prediction is only meaningful relative to a position, and tracking several sites at once, for instance a home QTH and a portable one, is how operators compare options.

On top of the display sits the function the tool exists for: predicting upcoming passes. The README treats this as a headline feature rather than a detail, and the manual at the documents page is what a new user is directed to for the details of any of it.

Time control is the feature that separates planning from watching

Gpredict can run in real time, in simulated real time, and with manual time control, and the README calls out detailed information in both the real time and non-real time modes.

That third mode is the one that changes what the program is for. With manual control you can put the simulation at any instant and read the position, the azimuth and elevation, the Doppler shift, the range and the pass duration as they would be at that moment. With simulated real time you can fast forward and go backward, so a whole pass, or a sequence of passes, can be reviewed in seconds.

For an operator this is the difference between watching and planning. A pass you did not expect, an antenna whose rotator limits make the middle of the pass unreachable, a Doppler shift that is out of band at the edges of the window, all of these become visible in simulation before the satellite is anywhere near overhead. A satellite that will be visible but barely above the horizon is a different proposition from one that passes overhead, and a polar plot in simulated time is the clearest way to see which of the two you are looking at.

The trade is that the whole model rests on the element set, and simulation cannot make a stale set accurate. Time control lets you explore the future implied by the data you have, which is useful, and it does not extend the validity of the data itself.

Hamlib turns a prediction into a radio and antenna command

The two features that reach beyond the screen are Doppler tuning of radios through the Hamlib rigctld daemon, and antenna rotator control through Hamlib rotctld.

Both work by talking to a local daemon rather than to the hardware directly, which is the usual Hamlib arrangement and the reason the dependency is listed as runtime only, not required for the build. The consequence is a clean separation: Gpredict computes what the frequency and the pointing should be, and a separate process owns the serial port, the radio or the rotator.

The Doppler case is the one operators care about most. A satellite moving relative to your ground station shifts the received frequency, and the amount of shift changes as the satellite approaches and departs. A rig that can be tuned by a computer can be tuned to follow it, and Gpredict will do that if the daemon is running.

The rotator case is the second half of the same loop. A rotctld daemon exposes the rotator over a local interface, and Gpredict can drive it to follow the predicted azimuth and elevation. Put the two together and the chain is complete: a scheduled pass, a radio tuned to the Doppler-shifted downlink, and an antenna pointed at the satellite, all from one application.

What the README does not describe is the configuration of that chain, which daemon to run, which port it listens on, how the frequency map is expressed, or how the rotator is calibrated. That information lives in the user manual and in the Hamlib documentation, and a user setting this up for the first time should expect to read both.

Building from a tarball, or from the git repository with autogen.sh

Gpredict is a GTK 3 application, and the README lists the libraries needed for a successful compilation: Gtk+ 3 or later, GLib 2.32 or later, Libcurl 7.16 or later, and Hamlib, which is required at runtime only and not for the build.

On Debian and Ubuntu the build dependencies are installed with two apt commands, and the README notes that building from source needs the development packages, which are often named with a -dev or -devel suffix:

sudo apt install libtool intltool autoconf automake libcurl4-openssl-dev
sudo apt install pkg-config libglib2.0-dev libgtk-3-dev

To build from a source package, unpack it and run the usual three steps:

tar -xvf gpredict-x.y.z.tar.gz
./configure
make
make install

The install step usually needs root, and the README offers the alternative of installing into a directory of your own by adding a prefix to configure:

./configure --prefix=$HOME/gpredict

which puts the files under your home directory in a gpredict folder. If you are building directly from the git repository, the README says to run./autogen.sh instead of configure, and the same options can be passed to it. For the full set of installation options it points to the INSTALL file, with the parenthetical that it is not for beginners.

The repository layout matches that workflow. There is configure.ac, autogen.sh, a Makefile.am, git-version-gen for stamping the version, plus src/, data/, doc/, po/ for translations, icons/, pixmaps/, snap/ for a Snap package and a win32/ directory for the Windows build.

Support moved to a forum and GitHub, and the old lists still run

User support is provided through the Gpredict forum hosted by the Libre Space Foundation, and the README also points at the newer GitHub Discussions on the repository. Both are named, and the forum is mentioned twice, once for support and once in the terms and conditions section as the place to ask for help if you have problems installing or using the program.

The history is documented as well. The development environment has migrated from Sourceforge to GitHub, and the README notes that mailing lists and old bug trackers are still available on Sourceforge, with the old project page linked. That is a small but useful fact for anyone with an old thread in mind: the archive is still reachable even though the work happens elsewhere.

The licence terms are stated plainly. Gpredict is released under the GNU General Public License and comes with no warranty whatsoever. The file at the root is COPYING, and the repository also carries AUTHORS, a ChangeLog, NEWS, contributing.md and a .clang-format file.

On releases, the tags are versioned properly and arrive fairly often: v2.5.1 on 2026-03-22, v2.5.2 on 2026-07-19 and v2.6 on 2026-08-16, with the last push to the repository on 2026-10-11. Unlike a lot of desktop projects, this one has a maintenance history you can point at, and the version numbering is the kind you can cite in a bug report.

Where Gpredict is the wrong tool

Three limits are worth stating plainly.

The first is that it is a desktop application. The README describes it as a program for the Linux desktop written with the GTK 3 widget set, and while the widget set is available on most Unix-like systems, on Mac and on Windows, the tool is a GUI. If your need is a number in a script, a value on a web page or a record in a log, this is the wrong shape, and nothing in the project suggests a scripting interface.

The second is the element set, and it is the one that bites in practice. The README says the program comes bundled with some example data and will run out of the box, but it does not describe a mechanism for downloading current TLEs, and it does not say where the bundled set comes from or how old it is. Since every position, pass time and Doppler value is derived from that data, a user who never updates the element set is reading a correct model of a stale orbit. Anyone adopting this should settle the question of where the TLE files come from and how often they are refreshed before trusting a pass prediction.

The third is scope. This is a tracker and planner for overhead satellites, with radio and rotator control attached. It is not a GNSS receiver decoder, it does not process live satellite telemetry, and it does not model the ionosphere or the atmosphere, so a prediction near the horizon or below about ten degrees elevation is where the model and reality part company.

Editorial conclusion

Gpredict fits an amateur radio operator who wants to plan passes, rehearse a contact with time simulation, and hand the result to a rig and a rotator without writing the glue themselves, and it runs on any desktop with GTK 3. It does not fit a headless server, a script that needs a numeric solution, or anyone who needs current orbit data automatically, because the README describes no mechanism for fetching fresh element sets and the bundled example data is what ships with the program. Before adopting it, check where your TLE files come from and how often they are refreshed, then build it with --prefix if you do not want to install as root. The licence is GNU GPL, the last push was on 2026-10-11, and releases v2.5.1, v2.5.2 and v2.6 landed between March and August 2026.

Frequently asked questions

Official sources

1. csete/gpredict on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases