Computing Apollo 7 phasing maneuver

meik84

New member
Joined
Oct 28, 2012
Messages
72
Reaction score
0
Points
0
Hello people!

I'm one of the maniacs working on NASSP. One thing we still don't have a solution for is Apollo 7's phasing maneuver, i.e. the short RCS maneuver after separation from the SIVB booster. They did that to simulate a rendezvous some hours later, using the SIVB as the target vehicle. To do that, the CSM had to be at a certain distance and height in relation to the SIVB at some defined time. And that's the problem: how does one compute the dV for the phasing burn? We do have:
- state vectors of passive (SIVB) and active (CSM) vehicle
- time of maneuver
- desired distance and height at given time

I've already looked around in the net, but all pages I found concentrate on actually doing a rendezvous by phasing -but we want to do the very contrary!
You may bombard me with math till I drown -I've already implemented Saturn's LVDC (the G&N computer of the rocket itself), so this can't be worse. At least I hope so.;)
 
Last edited:
How about you reverse time in the equations... just a quick undevelopped idea i just had
 
Is this different than calculating any other orbit transfer?
And wouldn't it have been precalculated before the mission?
 
Is this different than calculating any other orbit transfer?
Depends on how you define 'orbit transfer';)
And wouldn't it have been precalculated before the mission?
No. They tracked the CSM/SIVB combination with doppler radar and fed this data in the RTCC (real time computer complex), which spew out the burn solution. Unfortunately we lack any information about the software they used in the RTCC.
 
From what I have been able to read, what you want to do is to fire the engines, so that your CSM will come back around to the SIVB after a period of time (several orbits).

Because this is occurring just after CSM seperation, I will assume all orbital parameters are identical for the CSM and SIVB.
Variable names are listed in bold.
First, Let T equal the Orbital Period of the CSM.
In order to re-approach the SIVB after n orbits, you want to increase the orbital period of the CSM to a value of T(1 + 1/n)
 
Hi, just getting back into Orbiter/this forum. Do you still work on the problem? I want to understand the problem a little bit more, are you talking about this maneuver:

nM4z3me.png


If yes, you want to calculate the burn at 1 (Phasing) to get to 3 (NSR), right? As this is something I read a lot about (or at least similar) and programmed some stuff, I might be able to help you.
 
Last edited:
I don't know if the forum just swallowed my last post, so I'll try again (@admins: you may delete the other post).
If yes, you want to calculate the burn at 1 (Phasing) to get to 3 (NSR), right?
No. I need the burn to get to 1. It's not on the chart, as it happened about 23 hours before, shortly after CSM/SIVB separation. The rendezvous itself is understood quite well by me, I guess. At least I understand what the targeting routines of the CMC are doing. ;)
 
No. I need the burn to get to 1. It's not on the chart, as it happened about 23 hours before, shortly after CSM/SIVB separation. The rendezvous itself is understood quite well by me, I guess. At least I understand what the targeting routines of the CMC are doing. ;)

Hmm, that's a tougher one then, not only 23 hours, but multi-rev calculations. An "easy" solution would be an "upward" (sorry, forgot the right term) burn that adjusts the orbital period, so that the CSM falls slowly behind (or comes closer from the front), that would be quite possible to calculate. Is this helpful or historical correct? I don't know, but I do know it gets very complicated, even without orbital perturbations, to calculate a 23h, multi-rev transfer.
 
Last edited:
n "easy" solution would be an "upward" (sorry, forgot the right term) burn that adjusts the orbital period, so that the CSM falls slowly behind (or comes closer from the front), that would be quite possible to calculate. Is this helpful or historical correct?
AFAIK the phasing burn was posigrade, about 7.5 fps.
I don't know, but I do know it gets very complicated, even without orbital perturbations, to calculate a 23h, multi-rev transfer.
Isn't this some sort of Lambert's problem, but multi-rev? The CMC's got a routine for that, I believe.
 
AFAIK the phasing burn was posigrade, about 7.5 fps.Isn't this some sort of Lambert's problem, but multi-rev? The CMC's got a routine for that, I believe.

Everything is a Lambert's problem :lol:

If the routine has offset parameters it could indeed work this way. If not, but the routine can target the SIVB over this period of time I can help you getting the offset state vector.


Edit: But if it is a posigrade (=prograde/retrograde? I'm not good with my definitions today) it doesn't have to be this complicated. If the burn only has one dv component, then it can be calculated without needing Lambert targeting and other madness.

I still have slightly problems to understand everything, sorry: The CSM does a seperation burn from the SIVB, phases in front of it. If this is the only burn, then the image is wrong, because it looks like CSM is coming closer to the SIVB with every orbit.
 
Last edited:
offset parameters
Like...?
If not, but the routine can target the SIVB over this period of time I can help you getting the offset state vector.
You mean the state vector of the SIVB after those 23 hours?
still have slightly problem to understand everything, sorry: The CSM does a seperation burn from the SIVB, phases in front of it. If this is the only burn, then the image is wrong, because it looks like CSM is coming closer to the SIVB with every orbit.
Sorry, I just looked in the voice transscripts and not in the mission report: it was retrograde.
 

The desired distance and height at given time.

Sorry, I just looked in the voice transscripts and not in the mission report: it was retrograde.

Let me not waste your time and first look into the details of this. I'll do some "simulations" and let's see what I can come up with. I think I know enough about orbital mechanics and stuff to find a solution, give me a day and I will report back.
 
The desired distance and height at given time.
Ah. No, CMC's lambert routine is a little more universal: it asks for the initial position vector, the target position vector and the time between both (plus some CMC-specific variables). Background is that the routine is used in the rendezvous targeting and reentry targeting programs; computing the target vector is their job.
Let me not waste your time and first look into the details of this.
You aren't wasting my time. The more I learn about it, the better. Every craftsman should know about the tools he's working with...;)
 
Send you this as a PM, but changed my mind about it and wasn't sure, if you'll read it there, so here it is again:

Before we spam the thread with a simple question/answer dialogue just for helping me understand, I ask them here:

Please correct me if these assumptions are wrong: The CSM seperates from the SIVB, it performs station-keeping with the SIVB. Then at 3:20:00 MET the CSM performs a retrograde RCS burn of 2.5 fps according to the Apollo 7 Flightplan vAGC.xls. I've done this numerous times in NASSP, but it's been some time.

I guess 2.5 fps is an assumption to meet realistic conditions 23h later (or to be more precise 26:25:00 MET), when the CSM was supposed to be 75 NM in front of the SIVB and at an height (?) above it, which I didn't find out yet, but you seem to know about it. At this time the first SPS burn is conducted and almost an orbit later a coelliptic burn and then TPI, and so on and on... I guess there was no NCC2 burn necessary, because I can't find anything about it.

In reality, according to the mission report, the phasing burn was 5.7fps and another, unplanned phasing burn of 7.02fps was conducted a few hours later, because of increased decay of the S-IVB-orbit.

And this is an important point: I don't think that's how it will work in Orbiter, the S-IVB won't decay more rapidly than the CSM, I think. Putting the reality aside, what you want to do (I guess) is ONE phasing burn, as intended in the actual flight, putting the CSM in front of the S-IVB. 75 NM in front of it and ?? above/below it? Please give me some numbers on that.

If I understand it correctly the state vectors, at the time you have them, are nearly identical, because they are still very close, right?

Please give me some numbers and answers, and my next reply will be filled with wicked math, I promise :lol:

Since then I have written a short, very basic and incomplete lua script. It can calculate the dv necessary, to put the CSM, which must be still very near to the S-IVB, 75 NM (or any other distance) in front of the S-IVB after 15 orbits. It works fine with two DG's and comes up with a burn of -0.57 m/s under nearly realistic conditions. It's just a start, of course, but might evolve into something I can explain to you, so you can implement it in NASSP.
 
I guess 2.5 fps is an assumption to meet realistic conditions 23h later (or to be more precise 26:25:00 MET), when the CSM was supposed to be 75 NM in front of the SIVB and at an height (?) above it, which I didn't find out yet, but you seem to know about it.
Those 2.5 fps were figured out by try & error, AFAIK. That's not a way to fly a mission.
And this is an important point: I don't think that's how it will work in Orbiter, the S-IVB won't decay more rapidly than the CSM, I think. Putting the reality aside, what you want to do (I guess) is ONE phasing burn, as intended in the actual flight, putting the CSM in front of the S-IVB.
Concurred. Even NASA didn't (and AFAIK still doesn't) know why the orbit of the SIVB decayed. We'll never be able to simulate that. However, from my standpoint NASSP should depict the missions as how they were planned (putting Apollo 13 aside, though).
putting the CSM in front of the S-IVB. 75 NM in front of it and ?? above/below it? Please give me some numbers on that.
AFAIK they aimed for 0 delta-H. However, this was not critical; the rendezvous procedures had to be 'rugged' enough to deal with realistic deviations.
If I understand it correctly the state vectors, at the time you have them, are nearly identical, because they are still very close, right?
They excercised a docking maneuver and flew formation with the SIVB. 10 meters? 20 at most. Note that the booster pitched down 20° below local horizontal and went stellar inertial before separation, so the CSM is 'diagonally down' the SIVB at phasing; otherwise they could hit it when doing the phasing burn. Insurence wouldn't have payed for that...;)
 
Last edited:
0 delta-H is great, makes everything easier. Now another question: Is the maneuver time critical or position critical? The maneuver only has one local horizontal velocity component (retrograde burn), so it is limited how it can change the orbit. My script enforces the distance to be reached after exactly 15 orbits. This will meet the 0 delta-H criteria, but not at the exact time that was given. I can change it to have 0 delta-H at the exact time (26:24:55.2 MET, or whatever), but the distance will vary a little bit. In general this would be the more accurate solution.
 
Is the maneuver time critical or position critical?
Good question. I guess time critical. I've read somewhere that TPF was timed to happen at darkness, I think they didn't want to approach the booster against the sun light.
The maneuver only has one local horizontal velocity component (retrograde burn), so it is limited how it can change the orbit.
Oh, you may use outward and/or in-plane velocity, too. Everything that helps is allowed.;)
My script enforces the distance to be reached after exactly 15 orbits.
But you can vary that? I'm just having Apollo 9 in the back of my head...
I can change it to have 0 delta-H at the exact time (26:24:55.2 MET, or whatever), but the distance will vary a little bit. In general this would be the more accurate solution.
I would appreciate any solution that doesn't restrict us in any of the factors (time, distance, height). I predict that we'll need it, not now, but sometime later.;)
 
The 15 orbits won't be a restriction, if I change it to time critical. Basically there won't be any restriction considering time of the phasing maneuver, time of arrival at the desired distance or the distance itself.

Outward and in-plane velocity changes would make everything much more complicated and considering this wasn't even done in reality, I would suggest only adding it if it really is necessary for another maneuver at another flight. It would lead to more accurate results though, especially with nonspherical gravity enabled and I'll look into the usual deviations.

I'll present you my findings, when I have a working script and explain it to you. It would be good to know, how you plan to implement the calculation of the phasing maneuver.
 
It would be good to know, how you plan to implement the calculation of the phasing maneuver.
It would be nice if we could integrate it in our 'Project Apollo MFD'. But you can also put it in an extra MFD, if you want. PAMFD provides an interface to uplink burn data from another MFD to the CMC/LGC; Jarmo uses it for his IMFD resp. LTMFD.
 
Ok, it took some time to play around with the Apollo 7 scenario itself. I have a little script that works. I used the easy way though: only one dv component (just as in real life) and it will only work for this special case and not for another maneuver in Apollo 9 or so. By special case I mean that you can still modify the distance and times, but not the delta-H.

I know you wanted math, but here my test scenario and the script, just for a first look at what I have done. If you look at the script, don't be scared, I cannibalized another script and it is still a mess and 75% of the code is unnecessary for this purpose.

To run the test, start the scenario and open Terminal MFD. Then type

run('A7phas')

and

autopilot()

and enjoy the show. Just fast forward 23h or whatever to see if it is accurate enough for you. If you like it I will send you an annotated and improved script that will show you everything you need to replicate it for the Project Apollo MFD.
 

Attachments

Back
Top