Meadville Space Center
Welcome, Guest. Please login or register.
December 01, 2020, 10:55:11 AM

Login with username, password and session length
Search:     Advanced search
Welcome to the new Meadville Space Center forums!
25068 Posts in 2094 Topics by 2267 Members
Latest Member: Apollo Next
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development (Moderators: movieman, Tschachim, Swatch, lassombra)
| | |-+  A7 rendezvous P34 and P35
« previous next »
Pages: [1] Print
Author Topic: A7 rendezvous P34 and P35  (Read 4234 times)
almostfm
Full Member
***
Posts: 48


View Profile Email
« on: October 01, 2012, 02:44:29 AM »

After having real life get in the way, I'm finally getting back into using Orbiter, and am working on the rendezvous with the SIVB in Apollo 7.

I've been using Christophe's excellent RDV spreadsheet for the phasing, insertion and CDH burns, and have gotten pretty good results, with one tiny tweak.  Using the nominal 7.6 fps phasing burn puts us too far ahead of the SIVB at the time of the insertion burn.  This isn't a fault in the spreadsheet.  Using 4.8 or 4.9 fps gets the separation within 5 or 6 km of the "by the book" figures, and the subsequent insertion burn keeps the same "offset", so I think we're OK there.

My question has to do with the subsequent TPI, TPM, and TPF.  Using P34 gives me a good time for TPI (within 1 min of what RDV predicted), but while running through P34, at one point I get a V06N59, with the registers giving velocity for LOS 1, LOS 2, and LOS 3.  LOS 1 is the velocity to be gained at TPI, but I'm at a loss to figure out what points LOS 2 and LOS 3 are (the burns are very small; -1.0 fps for LOS 2, and +1.0 fps at LOS 3).  What I don't know is when those burns are.

Also, if you don't have the state vector for the SIVB loaded in the "other vessel" address when you run P34, it will throw a 1301 error, which makes sense--without position info on the SIVB, the angles become undefined.

Finally, in both P34 and P35, it mentions that you can pause at any flashing display and take optics marks (to refine the trajectory), or allow VHF ranging marks to accumulate.  Since the SIVB doesn't become visible until you're something like 20 km away, you can't take optics marks, and AFAIK, VHF ranging hasn't been implemented, so that doesn't work.  Can we just use a fresh state vector for the SIVB and call it good?

thanks,
Scott
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #1 on: October 01, 2012, 04:54:35 AM »

1. As I recall, the phasing burn from the S-IVB is actually supposed to be 2.5 fps, unless the new procedures suggest otherwise...

2. Those are actually the component dV's for all three axes at the time of burn. Since the rendezvous programs assume both targets are in-plane, it would make sense that there be barely any Y- or Z-component to the burn.

3. As part of the checklist, for A7, the state vector of the CSM/S-IVB stack is loaded into the "other vehicle" slot before separation.

4.You're right about the VHF, and one could just do an S-IVB SV uplink, but I've been able to get the S-IVB in the sextant for tracking before. Also, during TPM and TPF, the marks are actually used to update the CSM's SV, to keep things stable (including a fake mark to make sure the W-matrix is doing its job).
« Last Edit: October 03, 2012, 01:44:51 AM by eddievhfan1984 » Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #2 on: October 01, 2012, 04:45:34 PM »

Quote
I've been using Christophe's excellent RDV spreadsheet for the phasing, insertion and CDH burns, and have gotten pretty good results
How did you do that? When I tried it, I didn't get the orbits the sheet suggested.
Quote
1. As I recall, the phasing burn from the S-IVB is actually supposed to be 2.5 fps, unless the new procedures suggest otherwise...
Our initial orbit (i.e. the orbit the Saturn IB puts us in) is different from the real AP7 orbit. This is caused by our 'simplified LVDC' (I hope this will get better once we have the LVDC++ running). Thus, it is possible that we won't get the exact dV-figures MSFN had planned. As long as we achieve the original orbit data and distances between both vehicles, everything's okay.
Quote
at one point I get a V06N59
This is the dV in LOS coordinates, i.e. it is assumed that the CSM is pointing at the SIVB during the burn. A normal burn would have been done with the CSM aligned with the +x axis along the burn vector and using only forward translational thrust. This meant of course, that the CSM had to get from the tracking attitude to the burn attitude, stabilise, burn, get back to the tracking attitude, stabilise...very time consuming. Keeping the CSM at the tracking attitude saved time; the only price paid was that the astronaut had to use all thrusters to null the dV.
Quote
Also, if you don't have the state vector for the SIVB loaded in the "other vessel" address when you run P34, it will throw a 1301 error, which makes sense
Of course it does. The CMC isn't the wizard of oz. It needs to know where it is and where it has to go to calculate the rendezvous.
Quote
Can we just use a fresh state vector for the SIVB and call it good?
When I remember right, MSFN provided a SIVB SV to start with shortly after NCC2. After that, P20 was used and marks were taken on the SIVB. VHF ranging wasn't used on AP7 - the SIVB had no equipment for that. Tracking the SIVB with P20 is possible in orbiter, I've tried that.
Quote
Also, during TPM and TPF, the marks are actually used to update the <u>CSM's</u> SV,
Really? AFAIK P20 sets VEHUPFLG to 1 when called, i.e. the 'other vehicle' SV is updated. Confused
Logged
almostfm
Full Member
***
Posts: 48


View Profile Email
« Reply #3 on: October 02, 2012, 02:00:52 AM »

How did you do that? When I tried it, I didn't get the orbits the sheet suggested.

I didn't either, but I wasn't aiming so much for the suggested orbit as to put the CSM in the correct position relative to the SIVB, and other than the phasing Delta V, using the suggested Delta V's puts me in the correct position relative to the SIVB after the CDH burn.  The orbital elements of the CSM and SIVB match up pretty well (within 1 degree for LPe, AgP, TrL and MnL.  Inc and LAN are spot on, and eccentricity is .0001 off).  And the TPI TIG predicted by P34 was within one minute of the time from the sheet.

Quote
1. As I recall, the phasing burn from the S-IVB is actually supposed to be 2.5 fps, unless the new procedures suggest otherwise...

A 2.5 fps burn works to give you the separation if it's a pure retrograde maneuver, but the A7 phasing burn was done, according to the press kit, with a 72 degree pitch down attitude.  The spreadsheet calculates the DeltaV f and DeltaV i/o that result in the correct attitude for the burn, but the 7.6 fps is just too much.  After seeing how much it overshot, I figured that a 4.8 or 4.9 fps burn in the same attitude would give the separation needed (4.9 puts us a little too far away, 4.8 is a little too close), so I divided the values in the sheet by 1.55 (7.6/4.9) to get the values for the burn, but still have the correct attitude.

Quote
Our initial orbit (i.e. the orbit the Saturn IB puts us in) is different from the real AP7 orbit. This is caused by our 'simplified LVDC' (I hope this will get better once we have the LVDC++ running). Thus, it is possible that we won't get the exact dV-figures MSFN had planned. As long as we achieve the original orbit data and distances between both vehicles, everything's okay.

That's kind of my thinking as well--if we're ending up in the right position at the right time, then it's probably OK.

Quote
"at one point I get a V06N59..."  This is the dV in LOS coordinates, i.e. it is assumed that the CSM is pointing at the SIVB during the burn. A normal burn would have been done with the CSM aligned with the +x axis along the burn vector and using only forward translational thrust. This meant of course, that the CSM had to get from the tracking attitude to the burn attitude, stabilise, burn, get back to the tracking attitude, stabilise...very time consuming. Keeping the CSM at the tracking attitude saved time; the only price paid was that the astronaut had to use all thrusters to null the dV.

OK--now I understand what it's telling me.  So, the values in R2 and R3 should help cancel out any errors in Y and Z that have built up with the previous burns, correct?

Quote
"Also, if you don't have the state vector for the SIVB loaded in the "other vessel" address when you run P34, it will throw a 1301 error, which makes sense..."Of course it does. The CMC isn't the wizard of oz. It needs to know where it is and where it has to go to calculate the rendezvous.

Yeah, I just thought I'd point it out to anybody who missed a step and didn't know why that got that error (not that I ever did anything like that  Rolling Eyes)

Quote
"Can we just use a fresh state vector for the SIVB and call it good?..."When I remember right, MSFN provided a SIVB SV to start with shortly after NCC2. After that, P20 was used and marks were taken on the SIVB. VHF ranging wasn't used on AP7 - the SIVB had no equipment for that. Tracking the SIVB with P20 is possible in orbiter, I've tried that.

Well, if the ranging wasn't used, I'll stop trying it  ROTFL  And I'll back up and see if I can get the SIVB in the optics.

thanks for clearing up a bunch of stuff for me.
Scott
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #4 on: October 02, 2012, 06:39:18 AM »

Quote
The spreadsheet calculates the DeltaV f and DeltaV i/o that result in the correct attitude for the burn, but the 7.6 fps is just too much.  After seeing how much it overshot, I figured that a 4.8 or 4.9 fps burn in the same attitude would give the separation needed (4.9 puts us a little too far away, 4.8 is a little too close), so I divided the values in the sheet by 1.55 (7.6/4.9) to get the values for the burn, but still have the correct attitude.
This smells like either the sheet or you missed one coordinate system transformation. You took the dV from the sheet, put them in IMFD and then you burned manually or with the CMC?
Quote
OK--now I understand what it's telling me.  So, the values in R2 and R3 should help cancel out any errors in Y and Z that have built up with the previous burns, correct?
Not quite. It's the burn vector transformed to the LOS attitude, i.e. when the CSM is pointing on the SIVB at TPI you would have to burn R1 with the X-thrusters, R2 with the Y-thrusters and R3 with the Z-thrusters.
Logged
almostfm
Full Member
***
Posts: 48


View Profile Email
« Reply #5 on: October 02, 2012, 09:43:06 PM »

Quote
The spreadsheet calculates the DeltaV f and DeltaV i/o that result in the correct attitude for the burn, but the 7.6 fps is just too much.  After seeing how much it overshot, I figured that a 4.8 or 4.9 fps burn in the same attitude would give the separation needed (4.9 puts us a little too far away, 4.8 is a little too close), so I divided the values in the sheet by 1.55 (7.6/4.9) to get the values for the burn, but still have the correct attitude.
This smells like either the sheet or you missed one coordinate system transformation. You took the dV from the sheet, put them in IMFD and then you burned manually or with the CMC?

I put the data into IMFD, which was shared with PAMFD.  I then used the "P30" button on the MFD to transfer the data to the computer, verified that it was correct (by running P30 on the computer and looking at all the data), then did the burn using P41.

Quote
OK--now I understand what it's telling me.  So, the values in R2 and R3 should help cancel out any errors in Y and Z that have built up with the previous burns, correct?
Not quite. It's the burn vector transformed to the LOS attitude, i.e. when the CSM is pointing on the SIVB at TPI you would have to burn R1 with the X-thrusters, R2 with the Y-thrusters and R3 with the Z-thrusters.

And now I understand even better--thanks!

Scott
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #6 on: October 03, 2012, 01:44:15 AM »

P20 has the option of setting which state vector you want to update beforehand. Pre-TPI, updating the S-IVB SV is preferential, as the CSM is relatively free to move around via SPS. After TPI, however, controlling the range rate towards the S-IVB is the top priority, so even if the CSM SV is slightly off from reality in that case, it means the CSM can be navigated more smoothly.

Ah, the dread LVDC coding. Tongue I hope we get that rectified.
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #7 on: October 03, 2012, 04:19:28 PM »

Quote
I put the data into IMFD, which was shared with PAMFD.  I then used the "P30" button on the MFD to transfer the data to the computer, verified that it was correct (by running P30 on the computer and looking at all the data), then did the burn using P41.
Seems good. I'm trying the sheet myself at the moment, but fast forwarding over 20 hours takes its time... Wink
Quote
P20 has the option of setting which state vector you want to update beforehand.
Not beforehand. You can do that only while P20 is running, because P20 switches to the 'other vehicle' slot at start up. If you want to change that, you may key V80E for 'other vehicle' slot or V81E for 'this vehicle' slot while P20 is running.
Interestingly, the 'Apollo 7 rendezvous procedures' doc mentions that after TPI the update option will be changed from LM SV to CSM SV -but the flight plan remains silent on that. Of course, it would make most sense to update the SV of the active vehicle after a burn, but if they really did... Confused
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 454



View Profile
« Reply #8 on: October 05, 2012, 12:39:23 PM »

No joy. No When I execute the phasing as suggested by the sheet, I end up 100 (!!) nm too far away from the SIVB. There must be something very wrong with the calculations, I suggest there's a decimal flip somewhere...
The other problem is that I can't switch the phasing to 'disabled' for recalculating the insertion maneuver and trying to save the day. Sad
Logged
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!