Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Project Apollo - NASSP
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Notices

Project Apollo - NASSP Development, support and news for Project Apollo.

Reply
 
Thread Tools
Old 11-06-2019, 02:24 AM   #1
grummanonewire
Orbinaut
Default Apollo 11 LOI-1

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
grummanonewire is offline   Reply With Quote
Old 11-06-2019, 09:56 AM   #2
indy91
Addon Developer
Default

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.
indy91 is offline   Reply With Quote
Old 11-09-2019, 07:32 AM   #3
MrFickles
Orbinaut
Default

Sounds familiar indeed... https://www.orbiter-forum.com/showthread.php?t=39635
MrFickles is offline   Reply With Quote
Old 12-20-2019, 03:45 AM   #4
Thespacer
Orbinaut
Default

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
Thespacer is online now   Reply With Quote
Old 12-20-2019, 08:59 AM   #5
indy91
Addon Developer
Default

Quote:
Originally Posted by Thespacer View Post
 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?

Quote:
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.

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

Quote:
Originally Posted by Apollo 11 Transcript
 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.
Quote:
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.

Last edited by indy91; 12-20-2019 at 09:35 AM.
indy91 is offline   Reply With Quote
Old 12-21-2019, 04:43 PM   #6
Thespacer
Orbinaut
Default

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
Attached Files
File Type: txt AGC extract.txt (27.2 KB, 32 views)
Thespacer is online now   Reply With Quote
Old 12-21-2019, 08:02 PM   #7
indy91
Addon Developer
Default

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.

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

Quote:
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.
indy91 is offline   Reply With Quote
Old 12-21-2019, 10:06 PM   #8
Thespacer
Orbinaut
Default

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.

Tony
Thespacer is online now   Reply With Quote
Old 12-26-2019, 12:06 PM   #9
MrFickles
Orbinaut
Default

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.

Last edited by MrFickles; 12-26-2019 at 12:10 PM.
MrFickles is offline   Reply With Quote
Old 12-27-2019, 09:38 AM   #10
indy91
Addon Developer
Default

Quote:
Originally Posted by MrFickles View Post
 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.
indy91 is offline   Reply With Quote
Old 12-27-2019, 12:54 PM   #11
MrFickles
Orbinaut
Default

Quote:
Originally Posted by indy91 View Post
 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.
MrFickles is offline   Reply With Quote
Old 12-27-2019, 05:24 PM   #12
Thespacer
Orbinaut
Default

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
Thespacer is online now   Reply With Quote
Old 12-27-2019, 06:49 PM   #13
indy91
Addon Developer
Default

Quote:
Originally Posted by MrFickles View Post
 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.
Quote:
Originally Posted by Thespacer View Post
 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.

Quote:
Originally Posted by MrFickles View Post
 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.
Quote:
Originally Posted by Thespacer View Post
 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.

Quote:
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.

Quote:
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.
indy91 is offline   Reply With Quote
Thanked by:
Old 01-09-2020, 07:53 PM   #14
Thespacer
Orbinaut
Default

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

Last edited by Thespacer; 01-09-2020 at 10:05 PM.
Thespacer is online now   Reply With Quote
Old 01-10-2020, 11:38 AM   #15
indy91
Addon Developer
Default

Quote:
Originally Posted by Thespacer View Post
 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?
indy91 is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Project Apollo - NASSP


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 11:44 PM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Copyright ©2007 - 2017, Orbiter-Forum.com. All rights reserved.