Work of 5 months on New Features in Gpredict

Hello everyone,

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)

9 Likes

Thank you for your work!

I look forward to testing this!

Sounds pretty cool (:

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.

1 Like

Hi everyone,

As a follow-up to my message last week: OGpredict is now available on GitHub :tada:
Repo: GitHub - AxelOsika/OGpredict-source-code-New-Version-of-Gpredict: Satellite tracking & pass planning to the second: OGpredict extends Gpredict with Ephemeris, ISO-3166 territory filter, POI selection, and Windows build.

You’ll find two options:

  1. Source code
  • Build with Autotools: autoreconf -fi && ./configure && make
  1. 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)

1 Like

Thanks for sharing this code, I gave it a try on Debian Forky and run into the following error:

  CC       predict-tools.o
predict-tools.c: In function ‘predict_timestamp_to_string’:
predict-tools.c:53:5: error: implicit declaration of function ‘jd_to_gregorian’ [-Wimplicit-function-declaration]
   53 |     jd_to_gregorian(jd, &Y, &Mo, &D, &h, &m, &s);
      |     ^~~~~~~~~~~~~~~
make[3]: *** [Makefile:805: predict-tools.o] Error 1
make[3]: Leaving directory 'source/git/AxelOsika/OGpredict/src'
make[2]: *** [Makefile:841: all-recursive] Error 1
make[2]: Leaving directory 'source/git/AxelOsika/OGpredict/src'
make[1]: *** [Makefile:440: all-recursive] Error 1
make[1]: Leaving directory 'source/git/AxelOsika/OGpredict'
make: *** [Makefile:372: all] Error 2

Maybe you can point me in a direction to find a possible solution.

Jan | PE0SAT

Hi Jan,

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.

Best,
Axel

Does not work on my end (windows version).

“This software cannot be executed on your computer” windows error.

I am on windows 10.

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.

Unfortunately, does not seem to work on windows 11 24H2 either.