Apollo 11 LOI-1

[grummanonewire]

Running from one of the saved scenarios Apollo 11 pdi day got to LOI burn and about 2 minutes in the rates go all over
Followed checklist to the t got a good alignment and in hi rate
at about 3 minutes remaining if I do not go scs ill be tumbling end over end during the burn its like theres a spurious signal driving tvc all over hell and the rcs is trying to damp the rates and tvc trys to damp what rcs does therefore a feedback loop that grows exponentially on both sides

 

[indy91]

That sounds quite familiar. The issue is the AGC not working right (in some old scenarios) with the Orbiter Beta or the AGC working correctly, but in combination with Orbiter 2016. Which scenario were you using? "Apollo 11 - 08 - Before LOI-1 T+75h50min.scn"? I just checked, and the padloaded AGC parameters are all correct there. So I would suspect you are using Orbiter 2016. Orbiter 2016 should be working fine with the latest NASSP versions, except for docked burns (SPS or DPS). If you are actually using a recent Orbiter Beta then you might be using an old scenario you had saved. I can tell you what to fix in the scenario in that case.

 

[MrFickles]

Sounds familiar indeed... https://www.orbiter-forum.com/showthread.php?t=39635

 

[Thespacer]

Hi All

Flying Apollo 11 and just advising that I’m having similar issues described in this and the linked thread, specifically, about 3mins into LOI-1, the stack can’t hold its attitude and eventually goes all over the place. Followed checklists carefully. The following observations might be relevant:
1) I’ve been using time accel (although generally when CMC is inactive)
2) During P30 for this burn, the HA/HP values were inexplicably wrong (by a large margin), even though the burn data is nominal
3) Throughout the mission to this point, I’ve found the DAP to be very poor at executing attitude changes, in contrast to the situation in Apollo 8. It seems that the CMC is unable to predict when to null out rates as it approaches the target attitude, such that it always chases the target (and uses up the RCS fuel).

I can’t attach a scn file, due to size restrictions, but I have one available.

Grateful for any guidance.

Tony

 

[indy91]

Flying Apollo 11 and just advising that I’m having similar issues described in this and the linked thread, specifically, about 3mins into LOI-1, the stack can’t hold its attitude and eventually goes all over the place. Followed checklists carefully. The following observations might be relevant:

That it happens at 2 minutes and 3 minutes into the burn for grummanonewire and you is quite interesting, as any Orbiter 2016/Beta and CMC padload related issues usually means that it becomes unstable very early on it the burn. So this might be something else then. But I still have to ask. Was this mission flown with the Orbiter Beta and was it using one of the two Apollo 11 launch scenarios?

1) I’ve been using time accel (although generally when CMC is inactive)

The theory behind this being a possible cause is that something weird might happen with the Virtual AGC emulator during a framerate drop or too much time acceleration and that it writes some random numbers in the erasable memory, overwriting some important stuff for the DAP. These random numbers appearing definitely happened to some people before, although not me, meaning I've never really been able to debug it. But it could be an issue with the erasable memory for you as well, so maybe post that section of your pre-LOI scenario here. What I need is almost at the top of the scenario file, the lines starting with EMEM0000 and so on until EMEM3777 (if it has a value in EMEM 3777). That should be small enough for an attachment.

2) During P30 for this burn, the HA/HP values were inexplicably wrong (by a large margin), even though the burn data is nominal

This part at least is perfectly normal. For the HA/HP calculation the AGC simply adds the DV vector to the state vector at ignition as if it was an instantenous maneuver and not a multi-minute burn with a long burn arc. So for long burns like LOI that display becomes fairly useless. On some missions (including Apollo 11) the crew got both sets of HA/HP, the one you should see in V82 after the burn and also the one in P30 before the burn:

072:51:24 McCandless: [...] The values which you would see on Noun 42 prior to LOI burn are HA, plus 431.3; HP, minus 128.2.

3) Throughout the mission to this point, I’ve found the DAP to be very poor at executing attitude changes, in contrast to the situation in Apollo 8. It seems that the CMC is unable to predict when to null out rates as it approaches the target attitude, such that it always chases the target (and uses up the RCS fuel).

Well the control of the CSM+LM stack definitely behaves differently than the CSM alone, but especially in the Orbiter Beta where the moments of inertia of docked vessels have been fixed (as compared to Orbiter 2016) it shouldn't be that bad. So this might be an issue related to the LOI burn problem, which I might be able to see in the erasable memory.

 

[Thespacer]

Hi Indy

I am using Orbiter 2016, it seems. I should try the beta I guess.

I was using the stock Apollo 11 MCC scenario.

I've attached the EMEM extracts in the attached file. Hope it is of use to you.

Thanks for the info on P30 and HA and HP. I have generally been referring to the Apollo Flight Journal and the transcript of transmissions as a reference. I should have looked more closely to see McCandless' input.

Thanks as always for your help!

Tony

 

[indy91]

It's just the same thing as MrFickles had in the thread he posted above. A vital section of the erasable memory with numbers for the DAP has been scrambled, in your case some of those numbers have simply been moved by two addresses (why????). The problematic addresses are not exactly the same as in MrFickles' scenarios, but close. Hard to tell if really only this section of the memory has been broken or others as well. Most of the memory is used temporarily only, so any problems there wouldn't really be significant, unless you were running some program other than P00 at the time.

I've never had this issue and I've never been able to come up with a good explanation for it. Maybe it's a bug in the Virtual AGC, maybe one in our version of it (we use nearly, but not the exact same code for it as the standalone Virtual AGC). No idea. For now I can only give you the section of memory that needs to be fixed.

EMEM3012 0
EMEM3013 5
EMEM3014 123
EMEM3015 175
EMEM3016 37065
EMEM3017 2245
EMEM3020 156
EMEM3021 1000
EMEM3022 232
EMEM3023 0
EMEM3024 0 
EMEM3025 37777
EMEM3026 0
EMEM3027 0
EMEM3030 54360
EMEM3031 21075

Just replace the relevant part of the scenario with this, I hope this is sufficient.

As you are using Orbiter 2016 and not the Beta this fix might not fully help you. In that case you need to use slightly different values for these three addresses:

EMEM3016 17433
EMEM3017 4510
EMEM3020 333

These are the numbers for the SPS thrust vector control we used to use in Orbiter 2016 and before. The only thing that 100% doesn't work in Orbiter 2016 is a burn of the Descent Propulsion System while the CSM and LM are docked. Everything else works, in some case with numbers that are different from the ones used during the actual missions. Although as you noticed, attitude changes aren't working that great and need a lot more RCS propellant than you would like.

 

[Thespacer]

Great, thanks Indy. I’ll try those when I next get a chance. It sounds like I’m better off with the beta, particularly as my RCS is just below 50% and I haven’t even entered lunar orbit. :lol:

Tony

 

[MrFickles]

Whoa, what are you spending so much RCS fuel on?

The only thing I can think of pre-LOI that uses a lot of RCS is TDE and maybe 1/2 MCCs, but even then, >50% fuel usage seems way too excessive. Have you been using time acceleration while in anything other than SCS/FREE?

With fuel quantity at those levels before LOI, the mission should definitely be aborted.

 

[indy91]

Whoa, what are you spending so much RCS fuel on?

The only thing I can think of pre-LOI that uses a lot of RCS is TDE and maybe 1/2 MCCs, but even then, >50% fuel usage seems way too excessive. Have you been using time acceleration while in anything other than SCS/FREE?

With fuel quantity at those levels before LOI, the mission should definitely be aborted.

I've flown half of Apollo 15 in Orbiter 2016 and if you follow all the attitude maneuvers in the flight plan (P23s, P52s, science...) then you really do spend a lot of RCS propellant. I was down to 50% early in lunar orbit I think. So flying a complete J-type mission in Orbiter 2016 is probably difficult just due to RCS. It's no problem in the Orbiter Beta with the smaller docked moments of inertia though. There you will spend a realistic amount of RCS.

 

[MrFickles]

I've flown half of Apollo 15 in Orbiter 2016 and if you follow all the attitude maneuvers in the flight plan (P23s, P52s, science...) then you really do spend a lot of RCS propellant. I was down to 50% early in lunar orbit I think. So flying a complete J-type mission in Orbiter 2016 is probably difficult just due to RCS. It's no problem in the Orbiter Beta with the smaller docked moments of inertia though. There you will spend a realistic amount of RCS.

I'm not sure how it's supposed to be done, but for any attitude change with a CSM/LM stack, I'll first rotate the spacecraft manually to the required attitude. Once there, I use auto maneuver to trim and hold the attitude.

I've always found the auto maneuver spends too much RCS in Orbiter 2016. I haven't tried beta yet, maybe the AGC is tuned for a more realistic moment of inertia.

 

[Thespacer]

MrFickles

Like Indy said, I’ve just been following the flightplan. No exotic or unnecessary att changes.

I also do not know how manoeuvres were executed in real life, but if an att change was required, I executed a V49 manoeuvre on DAP. After all that seems its design purpose (and it works beautifully when CSM-only, the way it programs an att change to arrive at the desired RPY at the same time... nice work).

The CSM-LM stack is definitely a beast to move compared to CSM only and the quads fire excessively (in 2016 edition anyway, I have not yet had a chance to use the Beta). Realising the usage was out of control, I started to manually rotated the stack for MCC4 and LOI1 (which is now as far as I have made it).

P52s have been particularly frustrating because of the fact the LM occults the AGC-selected stars half the time, necessitating a roll to a new attitude (pitching or yawing definitely definitely required more RCS thrust than roll). I understand, however, that this was a problem for Mike Collins (was it “fixed” for later missions?).

I also looked up the A11 mission rules about RCS usage, but could not locate any numbers, below which an abort would be required. Curious if there are any.

Tony

 

[indy91]

I'm not sure how it's supposed to be done, but for any attitude change with a CSM/LM stack, I'll first rotate the spacecraft manually to the required attitude. Once there, I use auto maneuver to trim and hold the attitude.

I also do not know how manoeuvres were executed in real life, but if an att change was required, I executed a V49 manoeuvre on DAP. After all that seems its design purpose (and it works beautifully when CSM-only, the way it programs an att change to arrive at the desired RPY at the same time... nice work).

Mostly V49 was used in reality I would say, the flight plans usually say when a manual attitude maneuver is to be used (e.g. a 180° roll maneuver), but that becomes a bit more clear in the flight plans of the later missions.

I've always found the auto maneuver spends too much RCS in Orbiter 2016. I haven't tried beta yet, maybe the AGC is tuned for a more realistic moment of inertia.

The CSM-LM stack is definitely a beast to move compared to CSM only and the quads fire excessively (in 2016 edition anyway, I have not yet had a chance to use the Beta). Realising the usage was out of control, I started to manually rotated the stack for MCC4 and LOI1 (which is now as far as I have made it).

It definitely behaves like a beast in Orbiter 2016 and before and it becomes quite a bit better with the fixed moments of inertia in the Beta. AGC likes it more and the RCS reserves as well. It still maneuvers a bit... sedate though.

P52s have been particularly frustrating because of the fact the LM occults the AGC-selected stars half the time, necessitating a roll to a new attitude (pitching or yawing definitely definitely required more RCS thrust than roll). I understand, however, that this was a problem for Mike Collins (was it “fixed” for later missions?).

The main fix was to properly work out the whole attitude timeline and follow through with it in the flight plan. And very often mission control gave the crew a better attitude to use.

I also looked up the A11 mission rules about RCS usage, but could not locate any numbers, below which an abort would be required. Curious if there are any.

https://www.hq.nasa.gov/alsj/a11/A11MissRules.pdf PDF page 55 has the chart for this. It seems the CSM rescue redline would be just about violated with 50% RCS propellant gone, so a completely normal mission might not have been flown then.

 

[Thespacer]

Hi Indy

FYI I finally got round to this again. I installed the beta, edited the last scenario with the new EMEM figures above (hoping to just pick up where I left off in Orbiter 2016). I executed the LOI1 and it went well. The stack definitely moves much more fluidly in the beta.

EDIT: upon receiving the PAD for LOI-2, it seems the MCC uplink does not function (when going through the checklist and selecting “uplink”, there is no uplink activity light, perhaps a side-effect of transporting a scn from a different version of Orbiter.

Tony

 

[indy91]

upon receiving the PAD for LOI-2, it seems the MCC uplink does not function (when going through the checklist and selecting “uplink”, there is no uplink activity light, perhaps a side-effect of transporting a scn from a different version of Orbiter.

It's just the LOI-2 uplink that doesn't work? The Maneuver PAD calculated fine with reasonable numbers?

 

[Thespacer]

Correct. The P30 maneuver PAD for LOI-2 appeared at the appropriate time and the figures were all reasonable.

Tony

 

[indy91]

I guess you can approach this from two sides, the MCC and the spacecraft. Try forcing the MCC to recalculate the LOI-2, by going to the CAPCOM menu, from there to the debug menu (key 9) and there "Reset State" (key 8). That should recalculate the Maneuver PAD and the uplink. Then try the uplink again.

And from the CSM side you should check if the UP TLM CM switch is in ACCEPT and maybe just do a V37E 00E on the DSKY just to be sure. If that all doesn't help look in the scenario where the LOI-2 PAD and uplink have already been calculated and search for "MCC_upString". There should be an uplink sequence saved in the scenario. If not then it might be a NASSP bug.

 

[Thespacer]

Thanks Indy. I have just managed to both rectify and reproduce the issue, FWIW: initially, when going through the uplink checklist, I had left the AGC running V83 (displaying V16 N54, as I was in orb rate). I directly went to P00 (V37E 00E) from there, following which the uplink failed. However, on my re-attempt, I didn’t go straight to P00 from V16 N54, rather I PRO’d out of the routine first, and then went to P00. This appears to have made all the difference.

So I did not get to try your troubleshooting but good to know for reference.

Tony

 

[grummanonewire]

Is my understanding correct then I need to have a working copy of Orbiter Beta to use NASSP and it run properly or ?

 

[indy91]

Is my understanding correct then I need to have a working copy of Orbiter Beta to use NASSP and it run properly or ?

Yes, NASSP 8 is being developed for the Orbiter Beta. If you run Orbiter 2016 then that would explain the LOI-1 issues you are getting. I posted a procedure to solve that issue in the other thread: https://www.orbiter-forum.com/showthread.php?p=604361&postcount=6

I do recommed using the Orbiter Beta, but with a few exceptions Orbiter 2016 can be used. The main exception is any sort of docked burn. SPS burns do work by changing some parameters as I explain in that post. Docked burns with the DPS do not work at all though, so Apollo 9 for example can't be done in Orbiter 2016, only in the Beta.