Problem Apollo 10 DAP issues

MrFickles

Active member
Joined
Mar 14, 2010
Messages
127
Reaction score
28
Points
43
Starting from LOI-1, CMC controlled SPS burns try to apply too much dV. On LOI-1, Noun 81 and dVT tallies with the PADs but Noun 42 shows a negative Hp.
During the burn, Noun 40 R1 shows a burn time of almost 9min, compared to about 5.5min on the PAD. R2 and R3 correlates with EMS quite closely. If I don't perform a MTVC, the CMC doesn't shut down the SPS when N42 R2 reaches 0ft/s.

During TEI, the DAP just completely loses control of the CSM. Attitude rates build up so quickly that I don't even have time to take control with MTVC.
Same issue also happens as LOI. Computed burn time is about 5.5min for a 3min burn.

Scenarios are in a .zip format since they exceed the forum's limit of 195kb
View attachment Apollo 10 scenarios.zip
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,013
Reaction score
308
Points
98
The DAP section of the erasable memory of the CMC seems to be badly broken. Some addresses wrong, other values don't make sense at all. No idea how that could have happened. Was this scenario only used in NASSP 8.0? Did you launch this mission recently?
 

rcflyinghokie13

LM Junky
Addon Developer
Joined
Jun 4, 2016
Messages
187
Reaction score
56
Points
28
Also, Apollo 10 has a bunch of EMEM changes for DAP deadband and PTC events throughout the mission. It is possible that these were incorrectly performed? Did you do them manually or let the auto checklist type everything for these address changes?
 

MrFickles

Active member
Joined
Mar 14, 2010
Messages
127
Reaction score
28
Points
43
This was run entirely in NASSP 8.0 on Orbiter 2016.

Also, Apollo 10 has a bunch of EMEM changes for DAP deadband and PTC events throughout the mission. It is possible that these were incorrectly performed?
That was my initial guess as to what might have happened as well. I had the auto checklist perform the DAP deadband changes and PTC throughout the misssion.

EDIT: Incorrect EMEM changes peformed during the mission doesn't seem to be the problem. I've loaded up a scenario just after TDE, before any PTC or deadband change, and performed a translunar abort. The computed burn time is still incorrect, and the DAP cannot control the CSM. I made sure that I've updated V48 after jettisoning the LM.
 
Last edited:

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,013
Reaction score
308
Points
98
What is wrong is the DAP padload, so the numbers that are already loaded into the CMC before launch. I'm sure these numbers were correct at launch, so something must have happened so that they were overwritten. One of the wrong numbers is the thrust tailoff, so how much thrust the SPS still generates after the the cutoff command has been sent. This value is loaded as centiseconds of 100% thrust in the CMC, but NASSP doesn't simulate it yet. So we usually have it set to 0. In your scenario a random number seems to be loaded for that parameter, so that probably explains the burntime issue. And other parameters affected are for thrust vector control, also seemingly random values now.

It will probably help if we track down, when those parameters were first wrong. Please look in your scenarios (probably before TD&E, if you already have issues then) for the line:

EMEM3015 175

That's the value the address 3015 should have (one of the TVC DAP steering gains). If we figure out when that first became something else, then maybe we can prevent this issue from happening in the future. I'm still sure this was caused by some procedural problem, but of course it's possible that it's a NASSP or Virtual AGC bug.
 

MrFickles

Active member
Joined
Mar 14, 2010
Messages
127
Reaction score
28
Points
43
I've run a check on my saves, and it appears to have taken place some time between T-5min and T+1h 50min.

EMEM3015 at T-5min was 175. EMEM3015 at T+1h 50min was 5.


I ran through the mission again from T-5min. I tried all sorts of tests to try to replicate the problem, S4B takeover... SV, P30, REFSMMAT updates... x30 time accel... Saving and reloading the scenario with both scneditor and quicksave...

I never was able to replicate the problem, at the time I stopped testing after TLI cutoff, EMEM3015 remained at 175.

Maybe I never noticed until I reached the moon since only the SPS burns are affected, and the first time the SPS is fired for more than just a few seconds is at LOI-1.
 
Last edited:

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,013
Reaction score
308
Points
98
Thanks for checking the scenarios. So it could be something bad happening in P11, the CMC isn't used for much else in that time span. What could cause this, still no idea.

The wrong memory addresses in your scenario are (at least) EMEM3001 to EMEM3031. EMEM3032 and later are also TVC DAP constants and those are still correct and should stay constant throughout the mission. So to fix your later scenarios you have to replace those addresses with the numbers from the launch scenario:

Code:
  EMEM3001 2732
  EMEM3004 77777
  EMEM3005 77777
  EMEM3006 42757
  EMEM3007 11463
  EMEM3010 5605
  EMEM3011 74344
  EMEM3013 5
  EMEM3014 123
  EMEM3015 175
  EMEM3016 37071
  EMEM3017 2244
  EMEM3020 156
  EMEM3021 1000
  EMEM3022 232
  EMEM3025 37777
  EMEM3030 54360
  EMEM3031 21075

Easy mistake to avoid here, do this somewhere in the first half of the scenario, where the state of the CSM is saved. The LGC erasable memory has the same format and is saved in the second half of the scenario. You will need to do this if you want to continue the mission, not just for SPS burns, but some constants for reentry are also affected.
 

MrFickles

Active member
Joined
Mar 14, 2010
Messages
127
Reaction score
28
Points
43
After running through both LOI and TEI with the updated EMEM values, it seems that CMC manages to maintain control of the CSM/LM stack through the burn.

However, SPS burn time is still incorrect. (9min for LOI-1, 5min for TEI) Are there any other EMEM values I should update?
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,013
Reaction score
308
Points
98
The EMEMs above are meant as a block, so missing values in between (EMEM3002, 3003 and 3012) are treated as 0 value. So if you replaced the EMEMs one by one and not as a block, then you might have not set EMEM3012 to 0. That's the "Thrust Off Decay Time". That might be the remaining issue. The (very wrong) octal value 40341 in your scenario is equal to -161.58 seconds. So P40 would show a burntime that is 161.58 seconds too long and it would also cut off the engine that much too late. Setting EMEM3012 to 0 should fix all that.

EDIT: Don't change EMEMs 3002 and 3003 during the flight though, those are the SPS gimbal trim angles. So just leave them as they are in your scenarios.
 
Last edited:

MrFickles

Active member
Joined
Mar 14, 2010
Messages
127
Reaction score
28
Points
43
Yeah, that was it.

Setting EMEM3012 to 0 fixes the P40 burn time.

Thanks for your help indy.
 

MrFickles

Active member
Joined
Mar 14, 2010
Messages
127
Reaction score
28
Points
43
If you can duplicate the issue on a new mission let us know!

Sure will. Although I have no idea what triggered it in the first place. Currently at 25h GET on Apollo 11 and so far all seems fine.
 

Thymo

I like breaking things
Joined
Jun 26, 2016
Messages
85
Reaction score
65
Points
33
Website
vanbeersweb.nl
We've seen some AGCs get corrupted with time acceleration in the past. Wonder if this has anything to do with it.
 

MrFickles

Active member
Joined
Mar 14, 2010
Messages
127
Reaction score
28
Points
43
Just curious, what are the keyboard commands to designate LPD?
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,013
Reaction score
308
Points
98
With the ACA (so your joystick or the Numpad), roll and pitch axis.
 

MrFickles

Active member
Joined
Mar 14, 2010
Messages
127
Reaction score
28
Points
43
Thanks

Managed to land just 20m north of "tranquility base" using just LPD designation and P65

Now practicing flying and landing the LM manually
 
Top