Tiny Space Program Guide

What This Thing Actually Does

Tiny Space Program Guide is a lightweight reference and scripting framework for simulating basic orbital mechanics, trajectory calculations, and spacecraft state management in constrained computational environments. It was built for people who need quick orbital predictions without importing a six-gigabyte astrophysics library. The core concept is small: you pass in position, velocity, and a time step, and it spits back updated states using patched-conic approximations and basic Keplerian propagation. The download is hosted on the developer's GitHub repo under the tiny-space-program tag. Grab the latest release, unpack it, and you get a Python package plus a C fallback if you need something lighter for embedded projects. There's no installer, no registry keys, nothing fancy. Clone, pip install, go.

Getting Started With the Tiny Space Program Guide

Import it the normal way. Set your gravitational parameter to whatever body you're modeling, initialize a state vector, and call the propagator. That's it for the basic case. The example files in the repository are adequate but not exhaustive, so don't expect them to cover every scenario you'll actually hit. I spent three days fighting a bug where my low Earth orbit propagation was drifting by roughly 400 meters per orbit, which sounds small until you're trying to time a rendezvous window and suddenly your phasing is completely off. The issue turned out to be that the default J2 perturbation coefficient assumes a purely spherical Earth model with a hardcoded oblateness factor, and for any orbit below 600 kilometers altitude the node precession rate compounds fast. The fix was straightforward once I found the right parameter override: set the J2_model flag to true in the initialization config and explicitly define your base radius and J2 constant from the WGS84 standard. After that, the drift dropped to under 20 meters per orbit over a 24-hour propagation window. Here's something most beginners miss. The patched-conic approach in this library works fine for interplanetary transfers, but it completely breaks down when you try to use it for lunar trajectories. The sphere-of-influence boundaries are hardcoded to solar system scale values, so when you're inserting into a moon's gravity well the transition is essentially instantaneous and causes discontinuities in the state vector. I solved this by wrapping the propagator with a simple handoff function that switches bodies at a custom SOI threshold calculated from the ratio of gravitational parameters rather than using the library's built-in constant. It adds maybe fifteen lines of code and fixes the problem entirely.

Another thing worth knowing: the time-step handling is adaptive but not smart about it. If you're simulating a highly elliptical orbit and leave the default maximum step size, the integrator will take enormous steps near apoapsis and completely miss periapsis dynamics. Set your max_step parameter to roughly 1/100th of the orbital period, and you'll get reasonable accuracy without excessive computation. For a typical MEO satellite orbit that means a step size around thirty seconds. The Tiny Space Program Guide is genuinely useful for quick prototyping and education, but you need to understand its limits. It doesn't handle atmospheric drag past about 200 kilometers altitude in any meaningful way. The drag model is a single coefficient with no density variation, which makes it practically useless for anything in low earth orbit unless you're doing order-of-magnitude estimates. It also has no support for thrust profiling beyond simple impulsive burns, so if you're designing low-thrust spiral transfers you'll need to layer your own integrator on top of its state management. For those specific cases where drag and low-thrust matter, I'd recommend pairing it with GMAT or even just writing a basic Runge-Kutta 4 integrator that reads the TSPG state vectors as an initial condition. That combo gives you the convenience of the library's orbital mechanics math without the gaps in the physical models. The learning curve is about two days if you know basic Python and orbital mechanics, and maybe a week if you're comfortable with both but new to this particular codebase.

The documentation is sparse but the source code is readable, which means you can usually figure things out by tracing through the relevant functions rather than waiting for the README to explain them. That's both the strength and the weakness of this project. It's maintained by a small team that prioritizes correctness over comprehensiveness, and honestly that's fine for what it is, but don't expect it to hold your hand through advanced use cases.