# ProblemApollo 10 DAP issues

#### MrFickles

##### Active member
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

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
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
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

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
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

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
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

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
Yeah, that was it.

Setting EMEM3012 to 0 fixes the P40 burn time.

#### rcflyinghokie13

##### LM Junky
Yeah, that was it.

Setting EMEM3012 to 0 fixes the P40 burn time.

If you can duplicate the issue on a new mission let us know!

#### MrFickles

##### Active member
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
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
Just curious, what are the keyboard commands to designate LPD?