# FTL Travel Revisited

I have, previously, talked about the FTL system, and that it dumps spacecraft on the 0.1g boundary of a system, at no velocity relative to the target planet. Later on, in the economics post I changed that to a stable orbit for easier math. As ericthered on the GURPS forums points out, the no-velocity solution somehow seems neater. I actually agree on that, which means I’ll spend this post on orbital mechanics, to compute things like deltaV and orbital times - hard numbers!

## The Formulae

### Orbital Speed and deltaV

One of the main formulae we’re looking at is the vis-viva equation, which tells us how fast we’re moving at which point of our orbit. The equation is

where is our velocity, is the planet’s standard gravitational parameter (about for Earth), is the current distance between the spacecraft and the planet, and is the semi-major axis (i.e. the longer of the axes of the ellipse, i.e. the mean of periapsis and apoapsis distance).

How do we get the deltaV from here? Let’s look at an example: We’re currently orbiting Earth at a low orbit of 250km, and want to raise our apoapsis (the highest point of our orbit) to a geostationary orbit (~42164km). At our current distance, the speed of our orbit is

Note that I am specifying in , which makes the numbers smaller. Note also that the orbital distance is 6621km - that’s because we’re 300km above the Earth’s surface, meaning we have to add the Earth radius. In this case, computing is very easy - periapsis and apoapsis are identical, so is the same as either of those.

For our new orbit, is just the average of periapsis (our old 6621km) and apoapsis (our new 42164km), 24392.5km. Easy. Substituting the other parameters, we get

What does this tell us? Well, intuitively, when we’re at our point of burn, we are moving at 7.75km/s. For our new orbit, we’d have to be moving at 10.20km/s to be in our new orbit. How much deltaV do we need to change orbits? Simply 10.20km/s - 7.75km/s = 2.45km/s. Easy!

But were we actually correct? We can look at a deltaV map and compare the deltaV needed to go from low Earth orbit to Geostationary Transfer orbit - 2.44km/s. Perfect.

In fact, the spreadsheet I used (which internally doesn’t round) gave me 2.442km/s.

### Orbital Period

I’m also going to need the orbital period (i.e. time to complete one orbit). For this, the formula is

with all of the values as before. Again, let’s take the Geostationary Transfer Orbit as our example. We already have a as 24392.5km. Inserting that gives

37913s is difficult to work with; this is about 10h 32min. The wikipedia article gives 10.5h, so we’re right on target again.

## Jump!

With these formulae, we can now compute a deltaV-efficient trajectory. We still can’t say much about how to decrease the necessary time, but that’s fine for now.

### Jump Emergence Orbit

So, first of all, we look at the “orbit” (controlled fall) we end up in after jumping. First question: What’s the emergence distance (the apoapsis of our orbit?)

We again can introduce a new formula: The gravitational force:

where is the gravitational constant, and are the masses of the planet and spacecraft, and is the distance between them. We can directly combine to , the standard gravitational parameter above. Reformulating this gives us

Let’s look at Earth: We know from above. And, nicely, can be expressed both in and in ; our value is 0.1N/kg (about 0.01g). Meaning we can rewrite and then insert our values as follows

Nice how that works out, isn’t it?

Using that, what do we know about our orbit and speed? First the emergence speed is 0. We can either plug that into the vis-viva equation to compute the semi-major axis, or think logically for a second, figure it’s a circular orbit, so the semi-major axis is our . I did the former, of course, because common sense isn’t that common.

So, how long before you die a fiery death? About a quarter of the total orbital time. Let’s write that more generally, though:

Let’s eliminate the square root first, by looking at

and insert the from above

And pulling the root again gives us

This formula, if you need to be told, is quite ugly, but it would allow us to directly compute the orbital time for any object and any gravitational border.

For Earth, it’s 157875s, or 43h50min, meaning you die after about 11h.

### Transfer orbits

Now that we know at what distance we arrive, let’s define the burns we have to make. First off, we’ll assume that we’re moving into the highest recharging orbit (1N/kg of gravitational force). For that, we’re going to have to make two burns: The first one drops the periapsis to the target altitude (and avoids us dying a fiery death), and the second one (executed at periapsis) circularizes the orbit.

All of this can be computed using the vis-viva-equation above - yet it turns out there’s an issue. Looking at the moon as an example, it’s a clearly superior choice compared to almost everything: You’d have to spend less than 1km/s of dV and still transfer for only five hours. As a consequence, I’m increasing the necessary gravitational acceleration for jump recharge to 3N/kg. This means that, aside from the Sun, only the gas giants, Earth, Venus, and Mars can be used as recharge stations. This will also pull all of the traffic towards planets - perfect for my purposes.

As an example, for Earth that’s an altitude of about 5150km. You need to spend about 3km/s dV (3.6 for LEO), with about eight hours of transfer time. Luckily, that’s fairly close to what I assumed anyway during the economics discussion.

### Fast Transfer Orbits

But we might not want to spend 8 hours of transfer time; we want to get there faster. Computing that is more complicated: We essentially have to accelerate increase eccentricity of our orbit (which may lead to a hyperbolic orbit) and then decelerate again to circularize at the recharging orbit. Intuitively, this would also shift periapsis, from the opposite of where we’re emerging (minimum deltaV) to offset by 90° (infinite deltaV). To compute this - and especially the time needed - we need to introduce variables such as the eccentricity of the orbit - which I don’t want to do at this point. So I’m going to do an approximation.

Specifically, I’ll ignore the “sideways” gravitational acceleration due to the planet. I can do that by assuming instant acceleration and bending the orbit by a bit. This leaves me with a travelled distance of the twice the semi-major axis (or periapsis plus apoapsis) and a certain average speed (simply from my half-orbital period):

That’s the same formula as above, just to remind you: is the deltaV needed to be invested, is the semi-major axis, and is the orbital period.

In our Earth example, that’s 2.38km/s speed. If I want to spend more dV, I can just divide the orbital distance by my additional speed - or actually half the dV I’m willing to additionally spend, since I have to decelerate again.

For Earth, if I want to spend at most 5km/s to get to LEO, it will leave only 650m/s for accelerating, and will get me there in about six hours.

### Leaving Again

To leave, we just do the circularization burn but in reverse; so it’s the same dV. This will get you onto a minimum-deltaV trajectory towards the jump limit.

For accelerating, I’m again going to use the approximation above.

## Putting Everything Together

Let’s stay with the example of Earth. If we’re allowed to use a total of 10km/s for everything, we’re going to split the left-over dV into three parts: Acceleration and deceleration for the incoming burn, and accelerating for the outgoing burn. In the case of an Earth-LEO parking orbit, you’ll have about 7km/s dV left; this will accelerate both incoming and outgoing travel to about 4h15min each. Since that’s quite a bit faster than my first approximation, I’m going to increase recharging time to 15.4 hours (15h24min). This also leaves everybody with more time to load and unload cargo.

## Changes to the FTL drive

Compared to the first version, the new FTL drive

- emerges at a gravitational threshold of 3 N/kg (which excludes moons)
- recharges in 15.4 hours

All the other details are simply because I spent the time looking at the actual parameters. And I have to agree with ericthered - emergence at rest is nicer.