[NASSP 8] [Apollo 7] Rendezvous questions & difficulties

[STS]

Hello all,

I post a slightly long and boring video, where I show a strange issue I am encountering during my Apollo 7 rendezvous practice sessions.

Problems start around "T-48" (around minute 29 on the video) where I am instructed to update ORDEAL. I switch to CMC - FREE to maneuver the spacecraft to yaw 0, to update my ordeal pitch.. Then I switch back to Auto, some F 50 18 are shown, and I do Pro and Enter to return to Noun 45 and do the auto maneuver. Then, around "T-41" my UPLINK Activity light on the AGC comes on. Then I get a 1202 program alarm (on a different vessel and a little bit earlier than expected on the Apollo program ). I don´t know where these lights and the 1202 comes from, so I continue the procedures.

The video ends showing that I countinually have to move the optics to see the S-IVB and with a 407 program alarm.

I suspect that things start going to hell when I switch to free to set my yaw to 0. Maybe this is not required...

Another question that I have is that my Auto Maneuvers are looking, if I understand correctly, for a 338 pitch, but when the auto maneuver completes, that pitch is not shown neither on FDAI 1 (LVLH) or FDAI 2 (Inertial).

Also, why does the yellow marker that shows where S-IVB is, sometimes dissapear? That makes it very hard to tell where the S-IVB is when I am instructed to look at it through COAS later on the checklist. (Just prior to the TPI burn, if I recall correctly)

Best regards,

 

[indy91]

I think in general it can be helpful to read about P20, P34 and V83 in the Apollo 8 CMP Checklist to learn about the rendezvous: https://www.ibiblio.org/apollo/Documents/A8-CMP checklist-1004.pdf That will probably teach you a few non-standard items that these programs can have, as will become apparent below.

Hello all,

I post a slightly long and boring video, where I show a strange issue I am encountering during my Apollo 7 rendezvous practice sessions.

Problems start around "T-48" (around minute 29 on the video) where I am instructed to update ORDEAL. I switch to CMC - FREE to maneuver the spacecraft to yaw 0, to update my ordeal pitch..

Haha, the "Mnvr to place +Xsc in orb plane (0° yaw)" is such an innocent part of the (real) ORDEAL procedure, but it has been causing people so much trouble. All it really means is that V83 only shows you a correct LVLH pitch angle (to be used for the ORDEAL) if you are close to 0° yaw. But +/-10° would already be acceptable so no need to switch the CMC to free in your case. Lots of people have taken this to mean to e.g. take control of the S-IVB to go to exactly 0° yaw, when that is really unnecessary. I almost want to remove that line from the checklist, but it's in the real procedures. Just that the real astronauts were taught that it doesn't have to be exactly 0°.

Then I switch back to Auto, some F 50 18 are shown, and I do Pro and Enter to return to Noun 45 and do the auto maneuver. Then, around "T-41" my UPLINK Activity light on the AGC comes on. Then I get a 1202 program alarm (on a different vessel and a little bit earlier than expected on the Apollo program ). I don´t know where these lights and the 1202 comes from, so I continue the procedures.

Ok, I think the order of things happening here is this. You were still in CMC mode free and not exactly at the attitude P20 (running in the background) wanted from you. You have P20, P34 and V83 running at the same time. The CMP Checklist says, in the part about V83, that the computer can get overloaded under certain circumstances with P3X programs running. Just after the program alarm you got the 50 18 display that P20 wants you to maneuver. It probably was busy calculating that and when you pressed PRO to exit V83 at the same time the computer overloaded. Congratulations, I have never managed to get the 1201/1202 alarm this way haha.

And then when you went back to auto tracking you did everything right with PRO and then enter on the 50 18. But for some reason it didn't go back to fine tracking of the S-IVB but instead held the attitude in 50 18 inertially. Notice the zero attitude rates, when you actually always have a pitch rate when tracking. Not sure why, maybe the alarm (and associated software restart) reset some flag for this.

Then when the attitude P20 actually wants you to have exceeds 10° attitude error it shows the UPLINK ACTY light. See the P20 procedures in the CMP checklist. The course of action if you see that light is to do V58E. It then calculates a new 50 18 display and you can go back to tracking the S-IVB.

The video ends showing that I countinually have to move the optics to see the S-IVB and with a 407 program alarm.

I suspect that things start going to hell when I switch to free to set my yaw to 0. Maybe this is not required...

As said above, the CSM actually stopped tracking the S-IVB properly. Eventually the attitude is not good anymore for the sextant and you get a 407 alarm, which means the trunnion angle of the sextant would have to be more than 50° to track the S-IVB. So just an undesirable attitude at this point.

Another question that I have is that my Auto Maneuvers are looking, if I understand correctly, for a 338 pitch, but when the auto maneuver completes, that pitch is not shown neither on FDAI 1 (LVLH) or FDAI 2 (Inertial).

Is the GDC properly aligned to the IMU? The 50 18 will always shown an inertial attitude, so if the GDC isn't aligned right (shown on FDAI 2) and FDAI 1 shows LVLH attitude then neither will show the right IMU attitude.

Also, why does the yellow marker that shows where S-IVB is, sometimes dissapear? That makes it very hard to tell where the S-IVB is when I am instructed to look at it through COAS later on the checklist. (Just prior to the TPI burn, if I recall correctly)

The yellow marker is only on when you are fairly close to the vessel I think. And also only when the planetarium(?) mode is on, using the F9 button. So the same thing you have to active to see the Apollo navigation stars.

 

[STS]

Thanks for the answer! Very helpful!

 

[STS]

Hello,

I did another run today and I got further down the road to the S-IVB.

But I must have screwed up something on P35, because at T+18 I got an enourmous DV. Also I got Operator Error lights when I started using P35. I don´t know what I did wrong...

You can see those things around 1:32:00 into the video.

Best regards,

 

[STS]

After thinking about my issues, I will do the rendezvous again, starting from before the first SPS burn, and I will do one or two GDC aligments to the IMU when I have a chance between GET+26 hours and GET+28 hours.
I recall having an issue during the second SPS burn and I think I screwed up the trajectory before GET 28 hours. that is when the scenario I posted starts.

Will post an update when I try this again, later on this week, if I survive the week...

 

[indy91]

The first operator error is fairly clear, it didn't like you doing a V57E while it had the 50 18 display up. The second one seems to be the same thing actually. In the background, while you are typing in the V57E, the 50 18 came up again and then V57E was disallowed again. For a case like this the later LM DSKYs had a priority display light added. That way you would know that a new display came up without you noticing from the display alone. But it's no problem, operator errors are all harmless as the computer prevented you from doing something not so harmless.

As for the large DV for MCC1, I am not sure. You are getting fairly large errors after the 2nd mark still, the 06 49 display. But that alone probably shouldn't be large enough to cause this. I can't see anything obviously wrong. Maybe if both the CSM and S-IVB state vectors in the CMC are off it could happen, but if you were getting small 06 49 errors before that shouldn't really be the case.

 

[Miriam]

Only related in the widest sense (at best): is it possible to equip the S-IVB with some sort of "VHF-transponder", so that one could use the VHF-ranging equipment? I know, the real S-IVB didn't have that; but it would be interesting to play with it. And we don't have to use it "officially"...

 

[indy91]

Not possible right now. The VHF Ranging System class can only have one target vessel that must be a LM. I'm sure this will eventually be improved though. In general there is nothing the VHF Ranging requires specifically from the LM class.

Apollo 7 also had no VHF ranging system installed yet (same in NASSP). That didn't come until Apollo 10. I think the Apollo 8 CM software (which we use for Apollo 7) can handling VHF ranging, but I have never tried it.

 

[STS]

So, today I tried again from GET 26:00:00 hours (did the two SPS burns) and I can confirm that on the previous attempt, a burn was screwed up.

Having the GDC aligned helped a lot, and also I found a way to find the S-IVB when you are requested to look at it through COAS. I take a note of the stars that are visible through the telescope around the S-IVB and then I look around the windows to make me an idea of how I need to maneuver the CSM to look at the S-IVB.

I need to practise a little bit more with the P35, I understand how the crew was so busy. You can´t loose time with distractions here.

Will post a video tomorrow, wich I think it will serve as tutorial and would help people out.

Best regards,

 

[Miriam]

I think the Apollo 8 CM software (which we use for Apollo 7) can handling VHF ranging, but I have never tried it.

That's why I'm asking.? I've seen that in the code, too, and I'm quite interested in trying it. So the only way right now would be to transplant Colossus 237 in Apollo 11 (or 10). You can't simply change the .scn to achieve that, right?

 

[indy91]

That's why I'm asking.? I've seen that in the code, too, and I'm quite interested in trying it. So the only way right now would be to transplant Colossus 237 in Apollo 11 (or 10). You can't simply change the .scn to achieve that, right?

I want to add a "AGC software version override" for scenarios some time, but the way we handle it right now is via mission config files. They can be found under Missions\ProjectApollo. In the file for Apollo 11 you can see the line "CMCVersion=Comanche055" in there. Just temporarily change that to Colossus237.

Now, doing this without updating the erasable memory probably gives you a restart and program alarm at least. And some things are going to be broken like P21, because the AGC uses a yearly coordinate system and Apollo 8 and 11 aren't compatible in that way. But if you happen to have a scenario just after the CDH maneuver (Colossus 237 has no P32 or P33) and you switch to using Colossus 237 at that point you might be able to continue the rendezvous with TPI/P34 and the VHF ranging without too much trouble. Looking through the GSOP for Colossus 237 the VHF is definitely mentioned and I am not seeing any software update for Apollo 10 that specifically made te VHF ranging work from that mission on.

 

[STS]

Hello,

The "tomorrow" seems to be today, I am a busy man...

Here is the video of a partialy successful rendezvous, from GET 26:00:00

And I have a question about V83. How accurate is it? If you watch the last minutes of the video you see me hitting the brakes really hard. I wasn´t aware I was comming in so fast to the S-IVB. Maybe I was reading V83 incorrectly. For 1000 ft distance the checklist says 5 fps, so at 1000 ft I should have the following on the DSKY:
R1: +00016
R2: -00050
R3: XXXXX
But that was never shown for me on this run.

Is V83 not fully reliable and you have to "guess" a little your speed and range by looking through the window and the COAS?

Best regards.

 

[indy91]

The video is blocked in my country (Germany).

Yeah V83 is not working very well at close ranges. The MIT program notes document says this:

The range and range rate displays (in V83 and V85) may degrade considerably at ranges below 0.3-0.5NM depending on marking schedules and resultant AGC navigation accuracy.

So I guess for the last two braking gates it's not 100% useful anymore. Have to judge range and range rate visually, which the crew said to be very difficult in the mission report. All things considered Apollo 7 is really one of the most difficult Apollo rendezvous to do. In the LM you have the rendezvous radar which gives you good range/range rate data until very close to the target.

 

[STS]

Here is another boring video (had to record without music) of the whole process from GET 26:00:00, including the first two SPS burns. For the first one I switched on the two normal thrust switches at T-2 minutes as per the flightplan. I believe this was because they wanted to ensure an ignition, or check if the valves were go, as this was the first time the engine was used (with a crew).

I made a mistake at P35, when you are asked to V32 to recycle. Checklist on the MFD is a little confusing at that point. I made it to the S-IVB with a MA about quad D. I used too much RCS. But well, this is the best attempt so far. I am now focusing on practising P35 and the final approach to the S-IVB.

 

[n72.75]

You're doing great! Minimizing RCS propellant usage is reeeeeeally hard, especially in the last phase.

 

[STS]

Just a question:

I am practising all of this again. At GET: 14:16:00 I got this PAD:

From that I understand that the correction at GET:15:42:00 is not required. It´s that correct?

Best regards,

 

[indy91]

That is correct, but only because there is a bug. For this type of update (only a PAD, no uplink) the fact that the maneuver was scrubbed didn't go through. So it does not display the message "Second Phasing Maneuver not necessary." and it does show the Maneuver PAD, but it is empty because none of the numbers for it were calculated. Should be a simple fix, and it's not a critical bug, so you can continue without updating your NASSP without a problem.

I checked your scenario, you are actually right at the threshold of the maneuver getting scrubbed, which I set at a DV of 1 ft/s. In fact if I let the MCC calculate the maneuver again (CAPCOM menu, button 9 for the debug menu and then button 8 for Reset State) the maneuver is not getting scrubbed but instead is exactly 1 ft/s. So the DV has ever so slightly increased since the maneuver was originally calculated by the MCC. Your choice if you want to do the maneuver.

EDIT: Seems like I had already noticed this bug and fixed it, but only in a development branch of NASSP that hasn't been merged yet and won't be merged for a while. That wasn't very clever...

 

[Thymo]

What commit is it? It can be cherry-picked from your branch and merged separately.

 

[indy91]

What commit is it? It can be cherry-picked from your branch and merged separately.

Ah it's just one line of code, I made it a separate commit for the Orbiter2016 branch.

 

[STS]

Dear all,

During a rendezvous run I did today, on the seecond set of marks at P34, looks to me like marks are not being recognized.

F06 49 is not showing up after the marks.

What could I be doing wrong?

Best regards,