My name is Axel Osika. I recently completed my final-year engineering internship at LATMOS (Laboratoire Atmosphères, Milieux, Observations Spatiales – UVSQ/CNRS/Sorbonne Université, France), where I extended Gpredict to better support our operational CubeSat missions.
During this project, I developed OGpredict (Optimize General Prediction), a modified version of Gpredict designed to help the UVSQ-SAT NG team plan imaging campaigns with 1-second accuracy. The main contributions include:
New “Ephemeris Data” window with three tabs:
Ephemeris: generates ephemerides at 1 Hz with non-blocking GTK worker threads.
Territory: filters predictions by country/territory (using a lightweight ESA WorldCover dataset reduced to CSV).
Points of Interest (POI): lets operators define cities, volcanoes, glaciers, or custom targets and automatically computes the optimal trigger time (UTC) and distance/azimuth to the point.
Data pipeline: built from ESA WorldCover (~200 GB raw → lightweight CSV files) to allow fast filtering without heavy GIS dependencies.
Cross-platform packaging:
Native Linux/WSL execution directly from source.
Full Windows port (MSYS2/MinGW-w64) with .exe, .bat launcher, and an NSIS installer for easy distribution.
Validation: results were compared with vanilla Gpredict (AOS/LOS, azimuth/elevation, ground track) and are consistent to the second across Linux/WSL/Windows builds.
This work brought the tool from concept to TRL 7–8 (prototype demonstrated in a representative environment, packaged for operators). We have already used the new features during one of our imaging campaigns. Next steps could include multi-station support, geospatial indexing for long-horizon predictions, and a CLI/API for integration into automated pipelines.
The full source code is currently local, but I will publish it on GitHub soon. This is my first public release of a software project, so I’m making a few adjustments to ensure full compliance with the GNU General Public License (GPL).
I’d be very happy to receive your feedback, discuss possible improvements, and explore how OGpredict could contribute to the broader Libre Space community.
Best regards, Axel Osika
Engineer in Aerospace Systems — LATMOS / IPSA (France)
If you do, make sure to fork the original repo and commit on top of that head.
After cloning it, you can probably just paste your version on top of it so all the differences show.
Build with Autotools: autoreconf -fi && ./configure && make
Windows portable build (no install required)
Download the zip from the OGpredict_Windows_Version branch.
Unzip to any folder.
Run gpredict.exe.
What’s inside OGpredict
Ephemeris Data window with three tabs (enable ground track of your satellite then right click on your satellite and open Show Ephemeris):
Ephemeris Data : 1 Hz ephemerides using non-blocking GTK workers.
Territory: fast filtering by country/territory (lightweight CSV derived from ESA WorldCover).
POI: define cities/volcanoes/glaciers/custom targets; auto-compute optimal trigger time (UTC), azimuth, and distance.
Data pipeline: converts large land-cover data into compact CSV for quick lookups (no heavy GIS runtime).
Cross-platform: runs from source on Linux/WSL/macOS; packaged .exe for Windows (+ optional NSIS installer).
Validation: consistent to the second vs. vanilla Gpredict (AOS/LOS, az/el, ground track) across platforms.
Notes
License: GNU GPL (see repository for details).
If you clone the Windows branch with binaries, it may use Git LFS; downloading the Release zip avoids LFS requirements.
The Windows executable is unsigned (for now); SmartScreen may warn on first run.
Roadmap ideas
Multi-station support
Geospatial indexing for long-horizon predictions
CLI/API endpoints for automation
I’d love your feedback, bug reports, and feature requests—feel free to open issues or PRs. Thanks for your support and for helping OGpredict grow with the Libre Space community!
Best regards, Axel Osika
Engineer in Aerospace Systems — LATMOS (France)
Thanks for testing the build on Debian (Forky) and for the detailed error report. I’ve seen this issue before.
Right now the repository is aligned with the Linux toolchain. When the code is compiled with the Windows dependency set, a few files fail due to OS-specific differences. You have a few options:
Run the prebuilt Windows executables.
Build the sources on Linux (recommended).
Modify the sources to satisfy the Windows-specific dependencies.
Or wait a bit: I’ll publish the Windows-ready sources soon. I made several changes to produce the .exe and, when releasing, I forgot to push those Windows source updates.
Let me know which option you prefer—I’m happy to help you get it building.
Yeah, it works only on window 11. So sorry, but you can try to run it using Debian Forky I have just upload the Window versions of the source code on github.