Apollo 14: RTCC LM S.V. and CSM S.V. Update Procedure

Wedge313

Well-known member
Joined
Apr 18, 2020
Messages
488
Reaction score
118
Points
58
Location
Boston
Hello again,

I'm having problems with the Apollo 14 lunar descent, and I'm trying to figure out where I'm going wrong. I'd like to ask a few questions as I troubleshoot.

Let's start with a RTCC procedural question: I'm at about 106:30 on the flight plan, and I'm supposed to uplink to the LM the CSM SV (PDI-10) and LM SV. I'm messing something up here, and I've been trying a number of different things to see what it might be.

Before the uplinks, my V83 and AGS 317R, 440R and 277R all are in agreement, so I think I'm starting off from a good spot.

Let's do the CSM SV First. (Or does the order matter, should you do the LM SV first?) On the RTCC I'm on UPLINKS>DIS>21 for the LGC CSM update, I input the time as PDI-10. What should the TGT be, Kitty Hawk or Antares?

After doing CLC>UPL on the CSM SV does the uplink automatically go to the correct slot? Or do we have to do a V66?

For the LM SV I'm going UPLINKS>DIS>20, using present time. Again, what should my TGT be here, Antares or Kitty Hawk?

If someone could walk me through the correct steps I'm hoping I can figure out where my error(s) is/are.

Thanks
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
Let's do the CSM SV First. (Or does the order matter, should you do the LM SV first?) On the RTCC I'm on UPLINKS>DIS>21 for the LGC CSM update, I input the time as PDI-10. What should the TGT be, Kitty Hawk or Antares?

That is all correct. The target is the vehicle for which the state vector is calculated. So for a CSM state vector to the CMC or LGC you should select Kitty Hawk (the CSM) as the target.

After doing CLC>UPL on the CSM SV does the uplink automatically go to the correct slot? Or do we have to do a V66?

The slot where the state vector is being uplinked to is determined by the uplink type (LGC CSM vs. LGC LM). The slot is part of the uplink data. Definitely don't do a V66 in either vehicle after undocking, in the LGC that copies the LM state vector to the CSM state vector slot. And if you had just uplinked a new CSM state vector then you would overwrite it with the V66.

For the LM SV I'm going UPLINKS>DIS>20, using present time. Again, what should my TGT be here, Antares or Kitty Hawk?

Yes and select Antares, because that's the LM.

I hope that is help enough. There would be an added complexity if you had MPT mode enabled in the RTCC MFD. Then the state vector would be taken from the CSM or LM ephemeris. But I don't think it lets you select a target vehicle in that case, so you likely don't have that enabled.
 

Wedge313

Well-known member
Joined
Apr 18, 2020
Messages
488
Reaction score
118
Points
58
Location
Boston
Thanks indy91. It looks like I've been doing the uplinks correctly. But after the uplinks, one thing I notice is it takes a VERY long time if I try to run P00 (COMP ACTY stays on for a long time). If I try to run V83 it also takes a VERY long time to display information.

And after going V47 and 414+1, my V83 values and 317R, 440R and 277R aren't anywhere close.

I attached a .scn before I ran the uplinks. Is there something obvious you can see that I'm failing to do, or doing incorrectly? I feel I'm forcing bad information into the LGC and confusing it.

Thanks
 

Attachments

  • REDO 106+07 LND RDR CHECK COMP.zip
    64.8 KB · Views: 105

rcflyinghokie

LM Junky
Addon Developer
Joined
Jun 4, 2016
Messages
608
Reaction score
327
Points
78
Location
Colorado
Thanks indy91. It looks like I've been doing the uplinks correctly. But after the uplinks, one thing I notice is it takes a VERY long time if I try to run P00 (COMP ACTY stays on for a long time). If I try to run V83 it also takes a VERY long time to display information.

And after going V47 and 414+1, my V83 values and 317R, 440R and 277R aren't anywhere close.

I attached a .scn before I ran the uplinks. Is there something obvious you can see that I'm failing to do, or doing incorrectly? I feel I'm forcing bad information into the LGC and confusing it.

Thanks
I just did the uplinks, I can enter P00 right away and the V83 seems normal to me. Also my DEDA output addresses are all correct.

All I did was a display 21 with Kitty Hawk as target at present GET and display 20 with Antares as target at present GET.

Are you getting the issue with time tagging or present GET? Also are you trying to time tag the LM SV or the CSM SV for the LM uplink?
 
Last edited:

Wedge313

Well-known member
Joined
Apr 18, 2020
Messages
488
Reaction score
118
Points
58
Location
Boston
All I did was a display 21 with Kitty Hawk as target at present GET and display 20 with Antares as target at present GET.
Maybe this is where I'm going wrong? I'm using present time for the LM S.V. (Display 20), but for the Display 21 CSM S.V. I thought the flight plan asked for the vector to be calculated for time PDI-10. In my case my PDI is scheduled for 108:43:29.28, so I entered a time (TIM) of 108:33:29 and then did the calculation and uplink.
 

rcflyinghokie

LM Junky
Addon Developer
Joined
Jun 4, 2016
Messages
608
Reaction score
327
Points
78
Location
Colorado
Maybe this is where I'm going wrong? I'm using present time for the LM S.V. (Display 20), but for the Display 21 CSM S.V. I thought the flight plan asked for the vector to be calculated for time PDI-10. In my case my PDI is scheduled for 108:43:29.28, so I entered a time (TIM) of 108:33:29 and then did the calculation and uplink.
Nah you are correct to timestamp the CSM SV (display 21) with PDI -10m.

I did the same and there is a delay on P00/V83 etc which is completely normal. DEDA outputs should be close but might not be spot on at that time.
 

Wedge313

Well-known member
Joined
Apr 18, 2020
Messages
488
Reaction score
118
Points
58
Location
Boston
Well, I'm at a loss. I went through the AGS Initialization Routine a few times this morning, and I'm doing something wrong.

Again, before the process my V83 and DEDA numbers match up. After the S.V. uplinks but before V47 414+1, V83 looks good and the DEDA still matches up. But after V47 and 414+1 the AGS is wrong, 317R and 440R show basically +00000.

Here's a .scn after the V47 414+1 initialization.

And just to elaborate on my LGC delay times, after the two S.V uplinks it takes my LGC 170 seconds (almost 3 minutes) to display V83 numbers. That seems a bit off to me, which is why I wonder if I'm inputting something incorrectly.

The rest of the story: The first time I ran through this whole process I just assumed I was messing up the AGS but that the LGC was set up correctly. ( I've struggled with the AGS on every other mission I've run (11, 15, 16, 17) and have gotten used to pressing on without the AGS (always intending to go back and correcting the AGS but never actually doing it).

But on this mission when I continue on with the PDI, I'm getting very bad results. P63 seems to start out OK, but around 42,000 ft when the ALT and VEL lights go out, the landing radar numbers are acting strangely, alt rate is all over the place, PNGS and LR Alt are a few thousand feet off and never converge. If I accept the data with V57 and press on things quickly fall apart through P64, flashing ALT light, horizontal velocity pegged, and basically a unstable unacceptable approach. The landing radar acts like it doesn't see the ground. I tried pressing on without using radar data (V56) but the LGC still sets me up with a large horizontal velocity. So I'm thinking somewhere in the process I've stuck bad data into the LGC, and this point (where I'm doing the V47 414+1) is where I first notice things going awry.
 

Attachments

  • 106+29 After Bad 414+1.zip
    64.9 KB · Views: 94

rcflyinghokie

LM Junky
Addon Developer
Joined
Jun 4, 2016
Messages
608
Reaction score
327
Points
78
Location
Colorado
Just fired up this save and did time tagged CSM and present LM state vectors. N38 looked normal watching the time integration. Also my V83 matched my AGS once again after an AGS update.

Are you doing a V47 immediately after the uplink or letting it go to P00 and finish integrating first?

(I will fly this to PDI and see if I get any of those LR issues down the road)

EDIT: Flew this to PDI/landing with no problems at all. So I am curious if you can replicate your issues on PDI and provide a save right before with that configuration?
 
Last edited:

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
Just from what I can see with some tools in the RTCC MFD:

In that scenario the LGC CSM state vector is good, the LGC LM state vector has a 18,000 feet downrange error which is fairly bad. The two AGS state vectors are both garbage, the position vectors of them are completely zero. So they probably haven't ever been loaded into the AGS.

EDIT: Ok, I don't really trust that 18,000 feet error. Because if I do the V47 procedure then the AGS has two good state vectors without the error. So the 18k feet could just be some bug in the RTCC MFD.

So you have always had problems with the AGS? When you do "414+1" you are actually doing these steps: "Clear 414+10000 Enter". Not 414+00001, right? That would be wrong, but an easy mistake to do when you are unfamiliar with the DEDA.
 
Last edited:

Wedge313

Well-known member
Joined
Apr 18, 2020
Messages
488
Reaction score
118
Points
58
Location
Boston
Are you doing a V47 immediately after the uplink or letting it go to P00 and finish integrating first?
I've been waiting for the integration to finish after each SV uplink. (eg. uplink the CSM SV, then when the uplink is complete I go V37E00E and wait (after the CSM uplink it took 103 seconds before P00 kicked in). Then uplink the LM SV, then wait for P00 (this one took 87 seconds). Once that was done I go V47 on the DSKY, the k factor I'm using is 100:00:00, then CLR 414+10000E, then PRO on the DSKY. I've been pulling up 414R to watch the process, it takes a while to get 414+00000 (two minutes? I didn't time this one) then another 30 seconds to get F 50 16, and then PRO. I've run through it maybe six times now, still can't get it to where the DSKY V83 and DEDA 317, 440, and 277 readouts agree.
So you have always had problems with the AGS?
Each flight varies, but I've yet to get through an entire flight where I felt the AGS was programmed correctly. (A15 was probably my best attempt, AGS worked great throughout the descent and landing. I was actually practicing aborts using the AGS and thought I was getting the hang of it, but then programming it for the ascent something went wrong with my programming and I gave up on it). But usually somewhere during the descent prep I go wrong with programming and the AGS stops giving reliable info. There's just a lot of times where I'm punching in numbers not understanding what it's doing (like here on A14, the last initialization before P63, the timeline has me type in values for DEDA 240, 254, 261, 262, that I'm taking from the timeline and then 404-12345, and I really don't understand what I'm doing here, just punching numbers.)

And now here, where I think I'm doing the initialization correctly, but can't get the PNGS and AGS to agree. Frustrating.

Thanks for taking the time to look at this.
 

rcflyinghokie

LM Junky
Addon Developer
Joined
Jun 4, 2016
Messages
608
Reaction score
327
Points
78
Location
Colorado
I've been waiting for the integration to finish after each SV uplink. (eg. uplink the CSM SV, then when the uplink is complete I go V37E00E and wait (after the CSM uplink it took 103 seconds before P00 kicked in). Then uplink the LM SV, then wait for P00 (this one took 87 seconds). Once that was done I go V47 on the DSKY, the k factor I'm using is 100:00:00, then CLR 414+10000E, then PRO on the DSKY. I've been pulling up 414R to watch the process, it takes a while to get 414+00000 (two minutes? I didn't time this one) then another 30 seconds to get F 50 16, and then PRO. I've run through it maybe six times now, still can't get it to where the DSKY V83 and DEDA 317, 440, and 277 readouts agree.
From that save try the following:

Uplink time tagged CSM SV
Uplink present time LM SV (make sure the uplink page says present GET)
V37E00E
Wait for COMP ACTY lt to extinguish
V47E
DEDA 414+10000E
414R
PRO

Then once you get it uplinked and you have the F 50 16, PRO to clear the DSKY and then call V83
Also monitor V16 N38 after calling V83 and you can watch the time integrate. After this your AGS and PGNS should agree (they did for me)
The only thing I did different than that, and it probably is insignificant, is I calculated the AGS K factor in RTCC and used that time (100:00:00.62)
There's just a lot of times where I'm punching in numbers not understanding what it's doing (like here on A14, the last initialization before P63, the timeline has me type in values for DEDA 240, 254, 261, 262, that I'm taking from the timeline and then 404-12345, and I really don't understand what I'm doing here, just punching numbers.)
The G&N dictionary is your best source for this. I don't think I have an Apollo 14 copy but 13's is close enough. http://www.ibiblio.org/apollo/Documents/76-a13-g+n-dictionary.pdf

These numbers are based on FP7

240: X position component (this gets set to the RLS)
254: LM Ephemeris (Epoch time)
261: Y velocity component (LM)
262: Z velocity component (LM)
404: dVX in octal

Basically just initializing things for an abort in this case.
 

Wedge313

Well-known member
Joined
Apr 18, 2020
Messages
488
Reaction score
118
Points
58
Location
Boston
OK I give up. I've run through this numerous times and can't get the initialization to work correctly. I've gone back to other save points after the CSM/LM separation and still can't get it to work.

What bothers me is that, using my saved scenario, you're not having the same issue. Which would mean the problem is me. But I'm trying to do this carefully following the steps you gave me and I can't get it to work.

I'm going to go back to a save point just prior to entering the LM, and start from scratch.

But one more question: when I do these S.V. uplinks, my LGC V83 always looks correct (I'm checking against the CSM VHF RNG on the EMS). But doing the AGS initialization (V47, 414+10000) doesn't seem to transfer the info to the AGS correctly. Sometimes 317R reads -00001. The next time I run the initialization it reads +54376. Sometimes 440R reads +00000. The next time it displays values that vary all over the place. The process doesn't produce repeatable results.

Is there something I may have messed up in NASSP? Some RTCC configuration that's wrong? Incorrect time? I'm starting to think this is a problem with Orbiter or my computer that I've accidently introduced.

Thanks for the help.
 

rcflyinghokie

LM Junky
Addon Developer
Joined
Jun 4, 2016
Messages
608
Reaction score
327
Points
78
Location
Colorado
OK I give up. I've run through this numerous times and can't get the initialization to work correctly. I've gone back to other save points after the CSM/LM separation and still can't get it to work.

What bothers me is that, using my saved scenario, you're not having the same issue. Which would mean the problem is me. But I'm trying to do this carefully following the steps you gave me and I can't get it to work.

I'm going to go back to a save point just prior to entering the LM, and start from scratch.

But one more question: when I do these S.V. uplinks, my LGC V83 always looks correct (I'm checking against the CSM VHF RNG on the EMS). But doing the AGS initialization (V47, 414+10000) doesn't seem to transfer the info to the AGS correctly. Sometimes 317R reads -00001. The next time I run the initialization it reads +54376. Sometimes 440R reads +00000. The next time it displays values that vary all over the place. The process doesn't produce repeatable results.

Is there something I may have messed up in NASSP? Some RTCC configuration that's wrong? Incorrect time? I'm starting to think this is a problem with Orbiter or my computer that I've accidently introduced.

Thanks for the help.
Hmm if you are using that save and doing exactly what I laid out there, then perhaps the problem is elsewhere. I get consistently good results on your save and the procedure I posted. It's almost like you aren't getting a good downlink to your AGS for some reason. Which version of NASSP are you on?

I don't think going back will help you at all as everything is fine (other than the AGS SV) in the save you posted. Something is messing up with your AGS/PGNS downlink from what I am reading.

Just for giggles, what happens if you uplink two present time state vectors to the LGC then do a V47?

Without actually watching at this point, I can neither confirm nor deny you are making a mistake in this procedure somewhere. As I have mentioned before, you are free to jump in discord if you want some extra eyes looking for potential issues that aren't coming across here. https://discord.gg/MDWWEsJR
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
But one more question: when I do these S.V. uplinks, my LGC V83 always looks correct (I'm checking against the CSM VHF RNG on the EMS). But doing the AGS initialization (V47, 414+10000) doesn't seem to transfer the info to the AGS correctly. Sometimes 317R reads -00001. The next time I run the initialization it reads +54376. Sometimes 440R reads +00000. The next time it displays values that vary all over the place. The process doesn't produce repeatable results.

Absolutely no CSM or LM state vectors ever arrived in the AGS in your "after bad 414+1" scenario, I can see that from the AEA memory in your scenario. What it could be is, for the LM the AGS automatically includes accelerometer data if a certain acceleration threshold is reached. So the CSM state vector is at the very center of the Moon, but the LM state vector is slightly removed from it due to acceleration data. The accelerations it measures are probably tiny and could be in a random direction. That explains what you are seeing, I think.

Ah no, what I wrote was wrong. There are current CSM and LM state vectors in the AGS, they are just total garbage.

Is there something I may have messed up in NASSP? Some RTCC configuration that's wrong? Incorrect time? I'm starting to think this is a problem with Orbiter or my computer that I've accidently introduced.

Are you using time acceleration during this procedure? PGNS and AGS computer cycles are not simulated in a loop together, so it does the number of computer cycles in a simulated frame (e.g. 1/60 second for 60 fps) for the PGNS and then then same for the AGS. And on the next frame the same, all at your current frame rate. At e.g. 10x time acceleration it does the same, but the timing requirements are stricter than that. Like, the PGNS has already send more data packages to the AGS in that time than it can process. So in short, the PGNS to AGS downlink probably doesn't work at 10x time acceleration, depending on the frame rate.
 
Last edited:

Wedge313

Well-known member
Joined
Apr 18, 2020
Messages
488
Reaction score
118
Points
58
Location
Boston
Which version of NASSP are you on?
NASSP-V8.0-Beta-Orbiter2016-1898. If I install a more recent version will it make my .scn saves unusable?
Just for giggles, what happens if you uplink two present time state vectors to the LGC then do a V47?
Yeah, I tried that, same results. I tried different combinations of uplinks before V47 and 414+1; LM SV present time and CSM SV PDI-10, LM SV and CSM SV both present time, LM SV by itself, CSM SV by itself. I also tried no SV uplinks, just did V47 and 414+1. They all cause the AGS to go bad.
Are you using time acceleration during this procedure?
No, I'm at 1x. Would trying something slower like 0.5x make a difference? I haven't tried that.
 

rcflyinghokie

LM Junky
Addon Developer
Joined
Jun 4, 2016
Messages
608
Reaction score
327
Points
78
Location
Colorado
NASSP-V8.0-Beta-Orbiter2016-1898. If I install a more recent version will it make my .scn saves unusable?
I dont think it would break any old saves.
No, I'm at 1x. Would trying something slower like 0.5x make a difference? I haven't tried that.
I dont think it would, but you can of course try. I really am at a loss as to why your AEA is getting bad SVs
 

Wedge313

Well-known member
Joined
Apr 18, 2020
Messages
488
Reaction score
118
Points
58
Location
Boston
Tried installing the latest NASSP, no joy. I grabbed a few older saves and the problem repeats. I think I'm going to attempt the nuclear option and re-install Orbiter Beta, NASSP et al.

Something to occupy me on these quiet summer days.
 

rcflyinghokie

LM Junky
Addon Developer
Joined
Jun 4, 2016
Messages
608
Reaction score
327
Points
78
Location
Colorado
Tried installing the latest NASSP, no joy. I grabbed a few older saves and the problem repeats. I think I'm going to attempt the nuclear option and re-install Orbiter Beta, NASSP et al.

Something to occupy me on these quiet summer days.
Do you use git to install NASSP or do you download the build? The reason I ask is if you "paste" in new builds, old/obsolete files arent removed and could potentially cause problems. I cant think of anything that would cause your AEA issues but its worth a shot to think about.
 

Wedge313

Well-known member
Joined
Apr 18, 2020
Messages
488
Reaction score
118
Points
58
Location
Boston
Do you use git to install NASSP or do you download the build?
I go here: https://github.com/orbiternassp/NASSP/releases

Then when I unzip I click "yes" to replace files.

Before I do the whole Orbiter re-load, here's two screenshots of the RTCC CSM and LM SVs that I'm uplinking, does anything look wrong?

Then again, I get the problem when I do the AGS init even without the SVs. So that's probably not where the problem lies.
 

Attachments

  • Orbiter 2016 [D3D9Client] 7_11_2022 3_00_27 AM (2).png
    Orbiter 2016 [D3D9Client] 7_11_2022 3_00_27 AM (2).png
    15.3 KB · Views: 99
  • Orbiter 2016 [D3D9Client] 7_11_2022 2_57_21 AM (2).png
    Orbiter 2016 [D3D9Client] 7_11_2022 2_57_21 AM (2).png
    15.7 KB · Views: 99

rcflyinghokie

LM Junky
Addon Developer
Joined
Jun 4, 2016
Messages
608
Reaction score
327
Points
78
Location
Colorado
I go here: https://github.com/orbiternassp/NASSP/releases

Then when I unzip I click "yes" to replace files.

Before I do the whole Orbiter re-load, here's two screenshots of the RTCC CSM and LM SVs that I'm uplinking, does anything look wrong?

Then again, I get the problem when I do the AGS init even without the SVs. So that's probably not where the problem lies.
Yeah continuously replacing files wont remove any rendered old or obsolete, but a clean install will remedy that.

Those look totally normal. Are you entering P00 via V37E00E and waiting for the SV integration to complete before running a V47/414+10000?
 
Top