Finding delta-V for super-synchronous GTO

[LouScheffer]

Here is a method, and some code for calculating the Delta-V requirements for super-synchronous transfer orbits.  Assume perigee > geosync, and apogee over the equator.  Then the basic idea is to do the plane change at apogee, where it's cheap.  Also at apogee, you want to increase speed along the equator to increase the perigee to GEO.  These two burns should be combined, since the vector sum of the two burns is is always less than the sum of the two vectors if they are not colinear.  This leaves you in an orbit that has the same apogee, but GEO perigee, and no inclination.  You then burn retrograde at perigee to circularize at GEO.

So the calculation proceeds as follows.  First find the speed at apogee, using the usual orbit equations and the gravitational constant for the Earth.  Break this into a N-S component using sin(inclination) and an along-the-equator component using cos(inclination).  Next calculate the apogee and perigee speeds for the transfer orbit in the same way.  Since this orbit has 0 inclination, all velocities are along the equator.

So for the first burn, you need to cancel the North-South speed, and increase the speed along the equator to raise the perigee.  Since these are at right angles, they sum as sqrt(a^2+b^2).

For the second burn, you are now at the right height (GEO) but going too fast.  You slow down into circular orbit with a burn straight against your velocity vector.

The final delta-V is the sum of these two burns.

Below is the code written for 'awk' in Linux.  The code needs to add the radius of the Earth to the apogee and perigee, since they are measured from the surface of the Earth and not the center, and needs to convert from km to m at the right spots.  You could just as easily do exactly the same in Java, Python, a spreadsheet, etc.  Here is a sample output if you want to see if you get the same results.

Enter perigee in km, apogee in km, inclination in degrees
300 80000 28.5
perigee = 300 km.  apogee = 80000  km.
Semi-major axis 46521
Speed at perigee = 10532.5 m/s.   speed at apogee = 813.497 m/s.
revs/day = 0.865226  days/rev = 1.15577
Speed at perigee = 3564.79 m/s.   speed at apogee = 1739.95 m/s.
Cross v at apogee = 388.167 m/s.  Along track = 714.915 m/s.
Delta-v at top = 1096.07
Delta-v at bot = 489.792
Delta-v (total)= 1585.86

And here is the code that did the calculation:

BEGIN   {print "Enter perigee in km, apogee in km, inclination in degrees";}
        {perigee = $1;                       # in km
        apogee = $2;                         # in km
        inclination = $3;                    # in degrees
        print "perigee =", perigee, "km.  apogee =", apogee, " km.";
        sma  = ($1+$2)/2 + 6371;             #semi-minor axis, 6371 is Earth radius in km
        print "Semi-major axis", sma;
        mu =  3.986005e14;                   # G x M for the Earth m^3/s^2
        vp = sqrt(mu*(apogee+6371)*1000/((perigee+6371)*sma*1e6));
        va = sqrt(mu*(perigee+6371)*1000/((apogee+6371)*sma*1e6));
        print "Speed at perigee =", vp, "m/s.   speed at apogee =", va, "m/s.";
        rpd = 8681663.653/sma^(3/2);         #revolutions per day
        print "revs/day =", rpd, " days/rev =", 1/rpd;
        sync = 35786;                        # perigee = apogee for syncronous orbit
        sma = (sync+apogee)/2 + 6371;        # semi-minor axis for transfer, in km
        perigee = sync;                      # for transfer orbit
        nvp = sqrt(mu*(apogee+6371)*1000/((perigee+6371)*sma*1e6));
        nva = sqrt(mu*(perigee+6371)*1000/((apogee+6371)*sma*1e6));
        print "Speed at perigee =", nvp, "m/s.   speed at apogee =", nva, "m/s.";
        pi = 3.14159265358;
        cross = va*sin(inclination/180*pi);  # V as right angles to equator
        along = va*cos(inclination/180*pi);  # V along the equator
        print "Cross v at apogee =", cross, "m/s.  Along track =", along, "m/s.";
        need_along = nva - along;            # how much extra we need to raise perigee
        dv_top = sqrt(cross^2+need_along^2); # removing cross component and raising perigee
        print "Delta-v at top =", dv_top;
        geo_v = 3075;                        # V needed for GEO orbit
        dv_bot = nvp - geo_v;                # How much V you need to get rid of
        print "Delta-v at bot =", dv_bot;
        total = dv_top + dv_bot;             # Total delta V for both maneuvers
        print "Delta-v (total)=", total;
        }

[sdsds]

"Written for awk."  Love it!

       sma  = ($1+$2)/2 + 6371;             #semi-minor axis, 6371 is Earth radius in km

The spreadsheet I have uses 6378.137 km for the "Equatorial Radius of Earth."  Is that the proper value to use?
Its semi-major axis result is sma = 46528137 meters. I tried modifying your awk script:
===
Enter perigee in km, apogee in km, inclination in degrees
300 80000 28.5
perigee = 300 km.  apogee = 80000  km.
Semi-major axis 46528.1
Speed at perigee = 10531.7 m/s.   speed at apogee = 813.434 m/s.
revs/day = 0.865027  days/rev = 1.15603
Speed at perigee = 3564.79 m/s.   speed at apogee = 1739.95 m/s.
Cross v at apogee = 388.137 m/s.  Along track = 714.86 m/s.
Delta-v at top = 1096.11
Delta-v at bot = 489.792
Delta-v (total)= 1585.9
===

That's compared to your:
Delta-v (total)= 1585.86

... which is remarkably close. But the spreadsheet asserts: 1,585.55. I'm unclear about what precision awk is maintaining.

I guess the best answer is 1,586?

[BowShock]

These two burns should be combined, since the vector sum of the two burns is is always less than the sum of the two vectors if they are not colinear.  This leaves you in an orbit that has the same apogee, but GEO perigee, and no inclination.  You then burn retrograde at perigee to circularize at GEO.

Not at my home computer to smash this out, but the retrograde burn can take out some inclination as well.  Law of cosines make small plane changes during in-plane burns cheap.  Fairly straightforward optimization that can be done with goalseek in Excel or Google Docs that should result in lower total dV.

[Kabloona]

You can also cheat and use this online calculator.

http://www.satsig.net/orbit-research/delta-v-geo-injection-calculator.htm

For Lou's example of 300 x 80,000 km orbit at 28.5 degrees, the calculator gives delta V to GEO of 1485 m/sec, which is about 100 m/sec less than Lou's result. Don't know why the discrepancy. Possibly the retrograde burn taking out some inclination too as BowShock described above.

[LouScheffer]

You can also cheat and use this online calculator.

http://www.satsig.net/orbit-research/delta-v-geo-injection-calculator.htm

For Lou's example of 300 x 80,000 km orbit at 28.5 degrees, the calculator gives delta V to GEO of 1485 m/sec, which is about 100 m/sec less than Lou's result. Don't know why the discrepancy. Possibly the retrograde burn taking out some inclination too as BowShock described above.

It's not completely clear from this page, but it from the final period quoted, it looks like it is circularizing at the higher apogee, which is not what you want here.  It could also potentially be reducing the inclination slightly during launch, so the parking orbit is less inclined than the launch site.

Issues like this are precisely why I wanted to make the calculation explicit.

[Kabloona]

It's not completely clear from this page, but it from the final period quoted, it looks like it is circularizing at the higher apogee, which is not what you want here.

Ah yes, you are right. I missed that. Interesting that the circular equatorial orbit at 80,000 km requires less delta V than GEO does from the 300 x 80,000 inclined transfer orbit.

  It could also potentially be reducing the inclination slightly during launch, so the parking orbit is less inclined than the launch site.

It seems pretty clear that you enter the transfer orbit inclination that the payload gets dropped off in. How it got there (ie whether or not the LV did any inclination change) is immaterial to the calculator. It only calculates rhe additional delta V that the payload needs to supply to get from that inclination to equatorial.

Anyway, good work on your program.

[LouScheffer]

These two burns should be combined, since the vector sum of the two burns is is always less than the sum of the two vectors if they are not colinear.  This leaves you in an orbit that has the same apogee, but GEO perigee, and no inclination.  You then burn retrograde at perigee to circularize at GEO.

Not at my home computer to smash this out, but the retrograde burn can take out some inclination as well.  Law of cosines make small plane changes during in-plane burns cheap.  Fairly straightforward optimization that can be done with goalseek in Excel or Google Docs that should result in lower total dV.

I agree this should always help (since the penalty for including a tiny amount of cross V on the prograde burn is 0), but the effect should be small.  The retrograde burn is smaller, and the efficiency is further reduced since the cross V is multiplied up by the perigee/apogee velocity ratio.  So you'll want to do almost (but not quite all) of your inclination reduction at apogee anyway.

I tried this numerically, and for the example case (300 x 80000, 28.5 degrees) the optimum inclination of the second transfer orbit is 1.55 degrees, for a total Delta-V of 1577.6 m/s, for a savings of 8 m/s.  Hey, every bit helps.

Of course for this particular case, they are using low-thrust ion propulsion, so these impulse calculations are super approximate anyway.

Unfortunately, Google docs has no GoalSeek, only linear optimization.

[LouScheffer]

The spreadsheet I have uses 6378.137 km for the "Equatorial Radius of Earth."  Is that the proper value to use?

Well, since perigee and apogee are distances above the Earth, the question is what radius did they use when measuring these?  But in the bigger picture, these calculations are pretty approximate anyway - impulse burns, spherical Earth, no Sun or Moon, etc.  So I think this is down in the noise.

Delta-v (total)= 1585.9
That's compared to your:
Delta-v (total)= 1585.86
... which is remarkably close. But the spreadsheet asserts: 1,585.55. I'm unclear about what precision awk is maintaining.

I would think all of these would use the native double precision arithmetic of the machine they are on.  Since none of these calculations are numerically sensitive, I'm surprised they would diverge in "only" the sixth digit.  Perhaps someone defined PI as 3.14159, or committed some other hideous numerical sin.

I guess the best answer is 1,586?

Considering that variations in rocket performance are typically a few meters/second, digits after the decimal point are seldom useful, unless you are comparing very similar orbits.

[BowShock]

I tried this numerically, and for the example case (300 x 80000, 28.5 degrees) the optimum inclination of the second transfer orbit is 1.55 degrees, for a total Delta-V of 1577.6 m/s, for a savings of 8 m/s.  Hey, every bit helps.

Of course for this particular case, they are using low-thrust ion propulsion, so these impulse calculations are super approximate anyway.

Unfortunately, Google docs has no GoalSeek, only linear optimization.

Yeah the effect is pretty small.  A more interesting problem is on the launch vehicle side; optimizing the transfer orbit inclination and apogee for minimum dV togo (do you take out more inclination or boost the apogee higher?).