Ascent - Rendezvous Radar Help

[ADT187]

Hi all,

Have got as far as lunar ascent in Apollo 11, and am gradually learning about the various bit of the rendezvous sequence and the LGC programs for each.

Need some help however...

Liftoff successful, P52 done accurately enough. Get to the point of starting P20 and taking marks with the RR. It doesn't seem to start properly, and the radar appears not to be working.

Oddly I have been showing good signal strength and 'no track' extinguished at points during the ascent.

Any advice appreciated!

Alex

 

[indy91]

I'll take a look at the scenario.

Oddly I have been showing good signal strength and 'no track' extinguished at points during the ascent.

That is the powered flight RR designate routine in the LGC trying to point the RR at the CSM already during the ascent. Was never used during an actual mission, as Apollo 11 didn't have the RR powered up during ascent because of the RR related program alarms. Apollo 12 didn't have the RR powered either and later on the routine got deleted from the software. But in the normal procedures Apollo 11 would have the RR powered on, so we have it in our checklists as well. It used to work very well in NASSP, but with the new ascent stage behavior it wobbles around too much for it to keep lock it seems. Might be realistic, but the RR auto tracking might need some tweaks which will end up making it work better again.

EDIT: I tried your scenario. RR lock-on worked perfectly for me. I think the only problem is just that it takes a while to drive the RR to the right direction. Probably because of the attempt during ascent to already track the CSM, the RR is pointing more backwards than forwards. The checklist has a missing V37E before the 20E to start P20, but you might have figured that out yourself. Once in P20 the COMP ACTY light is on for a bit, some state vector propagation going on probably. After that the LGC starts driving the RR, which you can watch from the outside (it's a bit dark, but you can see it). That takes half a minute or more. But then the RR points right, I see the signal strength and it locks on. Just PRO on the V50 N72 display and you are good.

 

[ADT187]

indy,

Thank you for such a comprehensive response. The extra background on what happened on the actual mission really adds to the experience!

I'll go have another go and be patient with it!

Cheers,

Alex

 

[Thespacer]

ADT187,

You may also find some of the discussion in this recent thread to be on-point to your queries: https://www.orbiter-forum.com/threads/counting-rr-5-marks-in-lem-agc-apollo10.36757/page-2

 

[ADT187]

Thought I'd just bump this thread rather than make a new one.....

Have got as far as making the TPI burn (and seem to be roughly in the right place).

However I can't seem to get P34 to run properly. It does not blank at TIG -35 seconds so something definitely seems wrong!

Wondered if someone could take a quick look at my scenario and see what might be going on! Feels like it might be an accumulation of previous errors......

Cheers,

Alex

 

[indy91]

I think you just need to continue with the checklist. P34 isn't the program that does the maneuver, it just calculates the TPI maneuver. The scenario is at the flashing V37. A few steps later you do 41E and with that you enter the program that actually does the maneuver, P41. Just like CSI and CDH.

One note about P41 in the LM though, the display for ignition (V16 N85) isn't actually persistent. That means if you look at V06 N86 to see the DV vector used for the AGS then you can't simply key release to get back to the automatically updating V16 N85. You either have to manually type V16 N85 or you wait until T-35 seconds when the display blanks (if it wasn't already blank) and then at T-30 seconds the V16 N85 display comes back on its own. That all works fine in your scenario. Just a weird thing about the LM thrust programs, can't remember if that got changed in a later Luminary version.

 

[ADT187]

Ok thanks!

So I've done that, proceeded through the checklist. Strangely, I still don't get a blanking DSKY at -0:35. Also to other odd things I've experienced:

In ATT HLD, when I try and translate forward in Z axis, the LM tumbles end over end (almost as if my centre of mass is wrong)

Secondly no matter hard to try, can't get the DV value for Z (R3?) to reduce. The values seem to be changing so something is happening, just not what I desire

Thanks again for helping me back on track!

Alex

 

[indy91]

In P41 the first display is V50 N18. You don't want it to do an automatic attitude maneuver so you press ENTR (instead of PRO) and it switches to V16 N85. And that then will blank at T-0:35 and come back at T-0:30. I tried it in your scenario, it worked.

Did you do the V77 from the checklist? With the switch position in att hold the DAP has a minimum impulse mode which you start with V76 and disable with V77. When in this mode only manual attitude inputs are used to cause very short thruster firings (quite useful in P52), so it doesn't actually hold attitude. Can be confusing, this is the main reason why starting with Apollo 15 the LM DSKY had a NO DAP light which would be on when in minimum impulse mode. In any case, the center of mass is never perfectly aligned with the RCS thrusters, so when you command a translation the ascent stage will also try to rotate. So if the DAP isn't properly configured and doesn't hold attitude then it will quickly start spinning.

The DV targeted by P34 will always be a bit jumpy. It uses Lambert aimpoint guidance (so does P35), which doesn't try to burn a specific, precalculated DV vector but tries to guide you along an intercept trajectory to the CSM. So the DV actually gets recalculated every few seconds. That being said it should still be quite possible to get the DV to very close to 0. Do you mean you can't make the number in R3 change at all or do you just have trouble trimming it to the last few tenth of a foot per second?

 

[ADT187]

So I've just had a rather embarrassing revelation...

Had been taking the TIG of TPI to be 127:04:27 ..... from the original PAD. I had been looking for everything too early.
Didn't realise that the time had slipped (guessing that new time would have been uplinked?)

When I waited a bit, DSKY blanked as it should and the V77 kept me stable, and the refreshed V16 N85 showed the thrusting effect as it should have!!

Sorry to have wasted your time, this is all a big (but fascinating) learning curve for me!!

Alex

 

[Thespacer]

Had been taking the TIG of TPI to be 127:04:27 ..... from the original PAD. I had been looking for everything too early.
Didn't realise that the time had slipped (guessing that new time would have been uplinked?)

The TIG TPI you receive from the lunar ascent PAD is an estimate, provided for the purposes of setting up the CSI (and following) manoeuvres. The TIG is refined over the course of the CSI/CDH process, as a result of the LM updating its knowledge of its own and the CSM’s state vectors. The ”refined” TIG is therefore not uploaded by MCC-H, but rather deduced onboard (or at least that’s how I’ve done it, I think if there was concern about the accuracy of the PGNS, then values read up from the CSM or MCC-H would have been considered, but at least for NASSP purposes you only get the initial TPI TIG before lunar ascent).

To give you an idea of how this looked in real life, in Apollo 11 the predicted TIG read up during the lunar ascent PAD was 126:57:00, and the final (actual) TIG was 127:03:51. Just under 7mins later than predicted. My last simulated Apollo 11 flight had my actual TPI TIG about 2 mins earlier than the PAD value.

 

[ADT187]

Ah ok that makes sense. Thank you for the explanation!

Cheers,

Alex