NASSP AGC won't accept uplinks from MCC or MFD

[mnurick]

TL;DR Uplinks don't work, when they do, they result in opr err, and P00 causes the comp acty light to stay on.

AGC seem to be a bit messed up in my CM. LM appears unaffected. MCC uplink initially works, but then I get an opr err during uplink. I tried a P00, but then the comp acty light came on and won't go off. Only a v96 clears it, but the error remains when I try P00 again. I also tried initiating an uplink from the Apollo MFD (state vector and clock update), but the uplink "Failed to connect". All the switches are in the right place to accept an uplink, and I've toggled the switches as well to no avail.

It feels like I'm in AGC bug land. Any advice appreciated!

 

[indy91]

Did you ever have time acceleration at a high setting? I can't recommend more than 50x, high time acceleration has ocasionally caused problems with the Virtual AGC for me. It does sound like more than some of the usual uplink issues are going on. What can happen ocasionally when you have NASSP running, then exit out of the simulation back to the Orbiter Launchpad and then start a scenario again without having closed Orbiter completely, is that some debug message is displayed and uplinks don't work. But you seem to be getting more than that with operator errors and COMP ACTY light being constantly on. So I am not really sure.

Some people (none of us developers unfortunately) have occasionally gotten an AGC bug that broke parts of the erasable memory. Usually the DAP section. But anyway, I can take a look at your scenario like with your LGC clock issue. Maybe it is an easier to explain issue than the seemingly random erasable memory being scrambled.

 

[mnurick]

Indy, to the rescue again! Thanks!

I tried copying a healthy Columbia DSKY and AGC section from the stock scenario included with NASSP closest to my stage of the mission (rendezvous prep), updated the clock and state vectors and will update alignment as well, but it fixed the error. So there is definitely something fishy in the erasable memory or DSKY sections of the save file. I'll share the broken save file with you in case its helpful for future bug fixes.

I've been limiting my time acceleration to 20x, but its possible I may have engaged time acceleration during an AGC process, which maybe caused issues (i'm running orbiter on a windows partition of my macbook pro from 2011)

 

[indy91]

Yet again I can't load your scenario because the S-IVB section of the scenario is incomplete. Are you sure you didn't delete anything there? Can you tell me exactly which version of NASSP you are using? Orbiter 2016 or Orbiter Beta (with revision number) and the exact NASSP build number. I can of course delete the S-IVB from the scenario as I did in your PDI scenario, but it just doesn't make sense to me. You are clearly using NASSP 8, I can see that from the other scenario parameters. But all the S-IVB is saving is the default Orbiter parameters, none of the vessel specific parameters, no LVDC, no EDS, nothing. Why does it do that???? Is the S-IVB module auto build broken???

Apart from that your scenario doesn't look that bad. The AGC seems to be locked up somewhat in the coasting integration routine. You can actually watch that happen by monitoring V16 N38, whichs shows the current GET of the state vector that is being processed. When I do that in your scenario it first shows a GET of about 109h, 13 hours in the past. Not sure why it does that, usually it will automatically update the state vector every once in a while. Did you have the CMC in standby or turned off for some time? Not doing V37E00E for a long time might also cause this, not sure. Eventually N38 would reach the present time and the AGC probably would work fine then, although that can take quite a long time. The AGC is slow.

In any case, a V96 stops the processing and if I then uplink new SVs with the PAMFD it all seems fine. Careful though, don't uplink a LM state vector, the LM is still on the surface and that can be a bit unhealthy for the AGC If you just wanted to fix the AGC then uplink a "Columbia" state vector to the LM slot. Alternatively, the MCC also wants to uplink state vectors which works fine after the V96. And that LM state vector is a useful one.

Now, the state vectors that the MCC uplinks kind of cause the opposite issue. As the Checklist MFD says those CSM and LM state vectors are time tagged at insertion + 18 minutes. So they are 2+ hours in the future. So if the AGC then needs to find a present GET state vector it has to do a bunch of processing again, although not as much as the issue before. The mission documentation often states the time tag for a state vector, but it does cause some issues where the AGC has to do lengthy processing at critical times, especially for Apollo 10. So we are still debating if it is a good idea to uplink state vectors that far into the future, or if it wasn't better to let the MCC uplink state vectors at the present GET all the time. Maybe we are misunderstanding something about those SV time tags.

Anyway, I think all in all your CMC is in good shape. Just do the V96, let the MCC uplink state vectors and you should be fine.

 

[mnurick]

Hi Indy. Thanks again for the detailed reply and context. Really helpful! And to your question on the build of Orbiter I'm running...

I'm running Build 28 v.160828

Let me know if you'd recommend running an alternate build. The S-IVB issue is strange. Definitely never touched the save file prior to tinkering with the EMEM fields in Columbia. Thanks!