# [NASSP 7] Apollo 8- MCC PAD bugged (realtime simulation attempt)

#### STS

##### Well-known member
Hello all,

If you know, I did an attempt to fly Apollo 8 on realtime,, non-stop.

Yes, I know this is very ambitious, but I think it is possible, and that is why I did it.

What happened to me during this run, was that everything was going perfect until the point that I received the MCC PAD. The PAD showed nonsense DV´s. I attach a screen capture.

I was running the stable version of NASSP, (NASSP 7 + Orbiter 2010). Some of you suggested that I should upgrade to NASSP 8 and Orbiter 2016, and after thinking about it, yes, I will do that to attempt more of this stunts, but I just want to understand why NASSP 7 does not have support if it´s the stable version and was released (I think I am being realistic) not much time ago.

I can´t understand how a beta version can be more stable than a stable version. (Note: I am not critizicing in any way NASSP or its development, I love the work you put it and the project, and will continue to love it forever).

I attach a Quicksave of the moment that this failure occured. Can you check it and tell me if I screwed up something during the flight, or if this is a bug, why it happened?

Best regards,

#### Attachments

• Apollo 8 Virtual AGC LVDC++ MCC - Launch 0015.zip
27.8 KB · Views: 86

#### n72.75

Tutorial Publisher
Donator
Yikes, those are a bit big.

I was watching this in the beginning, and had very high hopes for you. It is an ambitious project indeed, and I applaud you for attempting it.

I am very surprised you encountered this issue with NASSP 7.0. I not sure I can help too much, as it predates my involvement in NASSP as a developer by a few years. But we will look at it.

If you want to try 8.0 Beta/Orbiter Beta for this I can recommend that. We try very hard (and mostly succeed) to not break things with new updates. In most cases when users find bugs they're easy to fix and the users are able to continue with their mission. I understand in your case, especially with the time commitment, you really need things to go smoothly. If and when you want to try this with 8.0, it is probably worth checking with us on your setup first.

#### Sbb1413

Switching to NASSP 8.0 will be much better if you can download Orbiter Beta following this instruction. Otherwise, switch to AMSO-2016, which I don't recommend due to the different VC look from NASSP.

#### indy91

I'm sorry that this happened to you in your Apollo 8 real time attempt. NASSP 7 is the more stable version for sure. And all the MCC updates were tested before release. I'll look at your scenario, if it is something that can be fixed without a major change then I'm not against doing the (so far) only update to NASSP 7.0 for it.

EDIT: Strange, if I use your scenario and either advance the MCC to the MCC-1 update in the debug menu or just wait for the update to happen, then I get a good solution:

Can you try your scenario to see if you also get a good solution? If you do get a good solution then the problem might be related to your real-time attempt. Maybe something buggy happened because you (probably) started from the T-4 hours scenario and went all the way to this MCC-1 update without reloading Orbiter. Is that correct?

Last edited:

#### STS

##### Well-known member
Yeah, I started from the T-4 all the way until this happened.

Will try that and also share my Orbiter config.

#### STS

##### Well-known member
Well, here is my PAD. This time it was correct...

Unfortunately I lost the orbiter.log file for the realtime session, containing possible useful information about what could happen on saturday.

Here is my Orbiter config file (Orbiter_NG.cfg):

Code:
; === ORBITER Master Configuration File ===
EchoAllParams = FALSE
LPadRect = 792 260 1447 846

; === Logical parameters ===
StartPaused = TRUE
DamageModel = 1
InstrumentUpdateInterval = 0.35
PanelScrollSpeed = 550

; === Visual parameters ===
EnableSpecularRipples = TRUE
EnableLocalLights = TRUE

; === Visual helper parameters ===
Planetarium = 22528

; === Physics engine ===
DistributedVesselMass = TRUE
NonsphericalGravitySources = TRUE

; === Camera parameters ===
CameraPanspeed = 2.81838

; === Device settings ===
DeviceIndex = 0
ModeIndex = 256
Fullscreen = TRUE
FullscreenPageflip = FALSE

; === Active plugin list ===
ACTIVE_MODULES
D3D9Client
ProjectApolloMFD
OrbiterSound
ApolloRTCCMFD
ScnEditor
DX9ExtMFD
END_MODULES

As we didn´t reproduce the issue when relaunching Orbiter (simtime was around 10 minutes on this test, instead of 40211+ seconds) I could try simulating flight day one non stop on a weekend... and see if this happens again. If this happens, I will have to implement an orbiter restart every 2 or 4 hours for example... But I don´t like that!

Also, note that this also happened for MCC-2 on the next day.

#### indy91

What you could also try if this happens again is using the RTCC MFD for the calculation. There is a step by step guide under Doc\Project Apollo - NASSP\Flightplans\Apollo 8\Apollo 8 RTCC MFD Input Parameters.doc to calculate the burn and the Maneuver PAD for it.

And I think I have a theory what could have happened. There is a variable used by the targeting for MCC1 that might be uninitialized. The variable is saved as 0 in the scenario you posted (which would be fine), but it could still potentially be the cause. Do you have some scenario saved after MCC1? You said the issue also happened for MCC2. Was that still all in one go? So you didn't burn MCC1 because the solution was bad and continued on? Maybe you have a scenario from after the MCC1 calculation where that uninitialized, bad value is saved. And if that is the case then my theory is correct and I will create a NASSP 7.0.1 release to fix it.

#### STS

##### Well-known member
What you could also try if this happens again is using the RTCC MFD for the calculation. There is a step by step guide under Doc\Project Apollo - NASSP\Flightplans\Apollo 8\Apollo 8 RTCC MFD Input Parameters.doc to calculate the burn and the Maneuver PAD for it.
Agree. But I didn´t knew how to use it properly, and I aborted at TLI +25 because I was scared as hell.

I post various scenarios after MCC-1, and yes, it was all in one go. I burned MCC-1 using RTCC MFD as it gave me a solution wich made sense to me. But then at MCC-2 PAD was bad again, and I checked with RTCC and it said to scrub MCC-2, and then I checked with P21, but didn´t understand what the AGC was telling me so I aborted... (should have continued to the Moon and everything was going to be fine, but I realized that a few hours later).

Thanks for taking the trouble of updating NASSP 7, very appreciated. I think it will be good for the whole community.

Best regards.

#### Attachments

• Scenarios for Bugged PAD investigation.zip
312.3 KB · Views: 83

#### indy91

I think the scenarios confirm what I thought. The MCC1 targeting thinks LOI happens at 0h GET.

In the code for the MCC1 calculation there is this:

if (calcParams.LOI == 0)
{
calcParams.LOI = OrbMech::HHMMSSToSS(69.0, 9.0, 29.4);
}

That saves the estimated LOI time in that variable, 69:09:24 GET. But if calcParams.LOI doesn't get initialized to 0 then this code isn't called. What is weird though, in your scenario it does save the numbers as 0:

RTCC_LOI 0.000000000000

But it being uninitialized it is probably still possible that the value was very slightly off from 0, but then got saved as 0 due to rounding. But it shouldn't be 0 after the MCC1 calculation anyway, so that already is a problem. The fix for this is simply:

calcParams.LOI = 0.0;

That was missing, for the other saved times like TLI, TEI and entry interface this was already done. And due to the nature of uninitialized variables in release mode, this bug was only likely to happen in your case where you never saved and reloaded scenarios before reaching the MCC-1 calculation. I think. So this one line is the fix and I will create a new NASSP 7 release for it.

EDIT: And a funny side note, this bug got fixed in NASSP 8 on 19 Apr 2017, so not long after the NASSP 7 release: https://github.com/orbiternassp/NAS...70ac7f501737c33114daa59b90b3410507976cfbe0d2d

Last edited:

#### STS

##### Well-known member
I will create a new NASSP 7 release for it
Thanks for the explanation and for this, @indy91 very appreciated!

As I said I will repeat this stunts in the future, with NASSP 8, but what I (we) found here will help many people, so that makes me happy.

Can I ask what my DSKY was saying at the P21 I ran at 7:03:28 on the video I posted above? I don´t understand that output, it says we are going to crash on the moon, if I understand correctly, but that is also normal in a certain way... Can you clarify me here?

Best regards.

#### indy91

Hmm, I'm looking through your videos, but of course I can not check everything. Did you do some P23s before the P21? Had you done a state vector uplink recently before the P21? It's likely that the state vector was outdated and not very accurate, so the predicted perilune altitude would also be off. When I uplink a fresh state vector and try P21 then, then it gives me roughly 65NM, a number confirmed by the Lunar Transfer MFD. Before MCC-2 your trajectory was already quite accurate and I see you getting a very small DV in the RTCC MFD. The MCC-2 calculation from the MCC was bad again due to the same issue as with MCC-1.

Can you confirm again that you never closed and reopened the simulation between launch and MCC-2? All these scenarios you posted save a number for the LOI time which would enable the MCC to recover from the bug, if you had saved/loaded. So it must have been unique to your situation of trying the whole mission in one go. Probably why nobody else found this bug earlier.

The release of NASSP 7.0.1 is imminent, I'll link it here when the build is done.

And the next time you try this I'll make sure to stop by your stream and will try to act as a "flight controller" if needed.

EDIT: It's done: https://github.com/orbiternassp/NASSP/releases/tag/NASSP-V7.0-Release-master-1671

Last edited:
STS

#### STS

##### Well-known member
Thank you very much for this, @indy91 .

I think my state vector before that P21 was off, because I just ran it to "double check" RTCC MFD. I think I said on the video at that moment that I should uplink a new state vector, but I didn´t, as my thinking capacity was degraded because of the night of FD-2 and the "stress" (and another external factor related with a possible interruption of my holidays for this mission... [my boss contacted me during FD-1 for the possibility to cover an unexpected vacancy of a companion during my holidays, but finally it wasn´t required... Wasn´t this supposed to be Apollo 8 instead of Apollo 13? ]).

I confirm, my computer behaved as a champ and orbiter and NASSP was uninterrumped from running since I started the Apollo 8 T-4 launch scenario (paused) at around 3:21 CEST May 8th... I unpaused at 3:51.

You will be more than welcome as a "flight controller"!

Replies
16
Views
2K
Replies
3
Views
279
Replies
19
Views
2K
Replies
17
Views
2K
Replies
14
Views
1K