Ascent advice

sw34669

Active member
Joined
Dec 16, 2020
Messages
217
Reaction score
31
Points
28
Location
uk
Another reference for many procedures is the post-mission technical debrief for each mission. You can pick up many little nuggets that have relevance to NASSP. For example, it turns out the Apollo 11 crew only commenced CSI about 27mins from nominal burn time. So, they too were running late (see https://www.hq.nasa.gov/alsj/a11/a11tecdbrf.html).

I’m unfortunately unable to help with the video, but this is one procedure I’ve practised many times, if you have further questions.
running late :) they let the LM crew sleep on a bit whilst they woke up collins i remember.
thanks for the debrief doc link
one thing i've issue with is nulling residuals after the inital ascent. Putting Orbiter into translation mode doesnt seem to work (at this point). Is that due to the mode the computer is in ?
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
one thing i've issue with is nulling residuals after the inital ascent. Putting Orbiter into translation mode doesnt seem to work (at this point). Is that due to the mode the computer is in ?

Is the left TTCA/TRANSL switch in the disable position maybe? Also, about ascent residuals, only try nulling R1, so in the x-axis. It's a quirk of the ascent guidance that will always make R3 become larger over time. That's expected, don't try to get that to exactly zero.
 

sw34669

Active member
Joined
Dec 16, 2020
Messages
217
Reaction score
31
Points
28
Location
uk
ok great thx will check that switch
looking at the g proc checklist and timeline i notice something strange and it accounts for 10 mins i'm missing
ins+17m should see you finish the P52
My engine cut off is 41 plus 17 = 58
but the next part of the checklist to lock the radar starts at 124:48
will keep at it
 

Thespacer

Active member
Joined
Oct 26, 2019
Messages
109
Reaction score
44
Points
43
but the next part of the checklist to lock the radar starts at 124:48
Seems like your ascent TiG was relatively late, at least compared to the nominal timeline? If so, then probably best to ignore the “actual” times listed in the Mission G procedures document, and monitor progress against the “relative” times (e.g., +17mins; -12mins etc). Presumably your CSI etc times have been similarly adjusted if your ascent was comparatively late...?
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
You probably arrived late in lunar orbit, LOI-1, LOI-2 and all events following it will have that same delay. Sounds like 10-11 minutes late to me with your insertion time. The Checklist MFD tries to do as little as possible with fixed GETs, but rather times relative to certain events. Or at least it should do that, you might have noticed the Apollo 11 checklist in the later half of the mission isn't very refined yet :D

On my Apollo 11 mission the delay is only 3 minutes, the upcoming MCC update uses slightly different targeting that causes that difference. On Apollo 10 we got up to 25 minutes, so 11 minutes isn't that bad...

I would trust more in the LM Rendezvous Procedures document than the Checklist MFD for the rendezvous, if I was you. The Checklist MFD will get better, but it's not right now. Just ignore any GET in the Checklist MFD, it's no use for the rendezvous.
 

sw34669

Active member
Joined
Dec 16, 2020
Messages
217
Reaction score
31
Points
28
Location
uk
the deda keypad has been doing something strange
i came to enter 373 and 275
373 went ok (hit reset 3 7 3 +03320)
hit enter
moved onto 275 .... hit enter nothing display just showed 275 and +04281 i had entered
cleared it again and tried 5 times ...... nothing, like the enter not working
tried a 6th time nothing
moved onto put to co-tangent in (605) entered it perfectly
went back to 275 , enters it right away with no delay and screen blanks as it should
is this a glitch as it burned 5 mins just trying to get these numbers in havnt seen this before

just had the same entering 416, tried 6 times, on enter nothing happens
re-entered 605, that worked , then 416 worked and cleared the screen when i hit enter
 
Last edited:

sw34669

Active member
Joined
Dec 16, 2020
Messages
217
Reaction score
31
Points
28
Location
uk
You probably arrived late in lunar orbit, LOI-1, LOI-2 and all events following it will have that same delay. Sounds like 10-11 minutes late to me with your insertion time. The Checklist MFD tries to do as little as possible with fixed GETs, but rather times relative to certain events. Or at least it should do that, you might have noticed the Apollo 11 checklist in the later half of the mission isn't very refined yet :D

On my Apollo 11 mission the delay is only 3 minutes, the upcoming MCC update uses slightly different targeting that causes that difference. On Apollo 10 we got up to 25 minutes, so 11 minutes isn't that bad...

I would trust more in the LM Rendezvous Procedures document than the Checklist MFD for the rendezvous, if I was you. The Checklist MFD will get better, but it's not right now. Just ignore any GET in the Checklist MFD, it's no use for the rendezvous.
ok thanks but i was looking at the GET in the G proc doc.
the csi time i got from mcc was 125:32
 

sw34669

Active member
Joined
Dec 16, 2020
Messages
217
Reaction score
31
Points
28
Location
uk
Seems like your ascent TiG was relatively late, at least compared to the nominal timeline? If so, then probably best to ignore the “actual” times listed in the Mission G procedures document, and monitor progress against the “relative” times (e.g., +17mins; -12mins etc). Presumably your CSI etc times have been similarly adjusted if your ascent was comparatively late...?
yes, managed to make 12 mins up in another attempt but unfortunately the deda is now playing up, every 2nd number I stick into in, pressing enter it wont do anything. clearing and re-entering the same number still wont work, putting a prev number back in again works, then the actual number I was on then can be input. I've just had this on 4 deda numbers in a row.

Tried a quick test to enter the same address and setting a few times and get the same , 2nd or third time enter does nothing. The only way I can get it to accept that value again is to enter another value, which works right away, then the one i want.

This burned the 12 mins I made up and i'm back to where i started on the timeline. Not seen this from the deda before.

after 15 mins i quit out and re-loaded the scenario. Now when I hit clear I can enter any of the values any number of times. Prior to that it was like the clear button wasn't clearing.
 
Last edited:

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
The Checklist MFD, when it uses GET, the flight plan and the Mission G procedures document all use the nominal timeline. And your Apollo 11 mission is about 11 minutes late it seems. Nothing to worry about. But you can treat all GETs you are reading accordingly, add 11 minutes to them. The MCC does that as well. In lunar orbit the MCC schedules mosts updates relative to revolutions and time into the current revolution. In lunar orbit this is defined as crossing the 180° longitude line. So your first orbit (rev 1) will start close to LOI-1. So even if you arrive late at the Moon the MCC will have no trouble. It has to do that, an event like PDI has to happen at a certain longitude rather than a GET. And DOI is relative to PDI in time, sep is relative to DOI and so on and on. Same thing for the ascent.

Weird with the DEDA. I've also never seen that before. Normally the clear button fixes any issue like this. Doing anything with the DEDA should have a CLEAR button press preceeding it. You aren't using 0.1x time acceleration, are you? The computer of the AGS, the Abort Electronics Assembly (AEA) is quite slow, so you might just have to keep buttons pressed for longer in 0.1x, or it might not recognize that you pressed the button. But if that doesn't help and clear doesn't help then that would be a new behavior that I haven't encountered.
 

sw34669

Active member
Joined
Dec 16, 2020
Messages
217
Reaction score
31
Points
28
Location
uk
I know about the DEDA clear this for sure is an issue if you have a read over what I saw before and after a save/quit and re-load.

It wasn't a speed thing, when it was refusing to accept a couple of the values I let it sit for 2 mins clicking ENTER every 5 seconds, nothing. I then hit clr, entered the address again and it's value and hit enter , same again, waited a few mins clicking enter. Only by entering another number (here's your clue to track this down) that worked and then the number i was trying to enter worked. Only a restart has fixed this, i got stopped in my tracks with 5 deda addresses that needed entering and i've been using it for a few weeks without issue.
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
Hmm ok, let's assume it's a DEDA bug. How would I go about replicating it? Saving/reloading seems to fix it. What scenario were you initially loading where the issue is happening? Pre or post insertion?

There is a known DEDA issue where if you did a readout and then save/load the number it shows is nonsense. Clearing and doing the readout again fixes that. I doubt this is related though.
 

sw34669

Active member
Joined
Dec 16, 2020
Messages
217
Reaction score
31
Points
28
Location
uk
here we go, i started with this scenario, flew upto insertion and my problems started when i got to the deda entry of CSI and co-tan etc.
I also had the time compression set to 0.1 at the time so i dont know if that is a factor a throwing DEDA into a bad mood. I was trying to harvest some time for my bad P52.
When it stopped working I took the time compression back to 1.0 but it was still not working until a full restart
I'm just going to run it again now.
 

Attachments

  • Moon 1m to liftoff CSM P119.zip
    61.9 KB · Views: 137

Thespacer

Active member
Joined
Oct 26, 2019
Messages
109
Reaction score
44
Points
43
FWIW, I too have experienced mildly funky DEDA behaviour. Similar to sw34669, but nowhere near as bad or frequent. In my case (and it hasn’t happened in a while), I recall trying to enter maybe a 450-related entry, and “enter” didn’t have the desired effect. Moving on to, eg., 451 was ok, and then re-trying 450 proved successful.

That’s hardly enough to help for any bug-tracking purposes, and it only inconvenienced me slightly... so FWIW.
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
I did a first attempt to try and replicate it, but wasn't successful. I tried to take shortcuts though, so I'll try again properly later. I had one weird idea though. In your scenario the abort button is still pressed in. I wonder if that causes the AEA problems when it's trying to start doing rendezvous calculations. Maybe it's also trying to run abort routines. So the AGS version of the 1202 alarm, except that the AEA doesn't give alarms. So, when you encounter it again, "unpress" the abort button and maybe that fixes it? Would be an interesting issue if this was the fix...
 

Thespacer

Active member
Joined
Oct 26, 2019
Messages
109
Reaction score
44
Points
43
While on topic, a separate issue I have noticed, with the PGNS during rendezvous (both during the post-insertion P52, and more generally during P20 activity), is that sometimes a F 50 18 manoeuvre will be requested, and PRO will accomplish the auto-manoeuvre, but sometimes only in roll and pitch, not yaw. Auto mode is definitely activated. I note that manually yawing (using the FDAI error needle as a reference) will sort the issue. I know “manual yaw” is an intended function of the DAP, while in P63 in PDI and until 30,000ft, but I wonder if this is intentional DAP behavior more generally?
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
Yeah that feature is called x-axis override and it's allowed in most mission phases, including P00. The flag that decides that is even called LPDPHASE in some documents, which is of course not quite correct, the flag is set at 30k feet as you say, not when P64 starts.

But that shouldn't mean that the computer has no control over yaw. It only means that if you deflect your joystick with the PGNS in auto mode then you can override yaw, but not roll and pitch. Maybe you used a joystick and the LGC detected the "ACA out of detent" condition. That would probably disable PGNS control over yaw, without a yaw rate being commanded yet.
 

Thespacer

Active member
Joined
Oct 26, 2019
Messages
109
Reaction score
44
Points
43
Thanks Indy. Based on what you indicate, I suspect there is some noise in the yaw axis of my cheap joystick (most noticeable when, in the CSM, I’m doing the manual SPS gimbal test... the GPI indicate definitely bumps around until I nudge the joystick to settle it). I therefore guess the noise in the X axis is taken as manual override. At the very least, it keeps the virtual LM commander on their toes!
 

sw34669

Active member
Joined
Dec 16, 2020
Messages
217
Reaction score
31
Points
28
Location
uk
Ok i think i know what it is. the buttons in slow speed or normal have 2 levels of click. It's more noticeable when in slow speed.

If you dont give them a good press and hold, they show they have been depressed, but dont register. This was why pressing CLR too quickly wont make it register ergo whatever you type next isnt on a blank entry for the DEDA. It's funny, i noticed the same with the dsky if you are too quick sometimes hitting PRO , the button goes down, it makes the noise but it doesn't register. The Read button on the DEDA is also the same. I had the dsky in idle in a prog ready for PRO and i used the mouse to click it really quickly, the sound occured but not the PRO action. When you slow things down a bit it gets more pronounced, especially on the deda.

It's like the code is running like this

(0 seconds)
detect button push
animate key going down
play sound
if (still_clicked())
PRO or ENT
else
discard push
(<1 second)

I've also got a quick question on P52 - it has auto selected 2/40, but it's not at all in the front view, it's in the middle of detent 3 and 4 and this was after the move to angle. Reading the actual plan the auto selected stars were in the correct detent.
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
Ah yeah, I have seen that as well many times, with DSKY and DEDA. The issue is that the computers don't react as quickly to the button press as the panel code. The panel code will run the button animation, play sound and set an input discrete to the AGC or AEA. All that nearly instantly, on the next timestep. But the computer might take a little bit of time to react to that. And the Checklist MFD also can recognize the button press that quickly. Because it looks at the button itself, not its interaction with the computers. Not much we can do about that. The auto checklist holds the buttons pressed by a defined amount, but that logic is not used to detect a button press from the user.

Not sure about the P52 issue. I feel like I have seen that before, but I can't remember what it was.
 

sw34669

Active member
Joined
Dec 16, 2020
Messages
217
Reaction score
31
Points
28
Location
uk
understand. thx
its the PICAPAIR P52 checklist that is missing the PRO i think to actually make the move so it's sitting on an RPY move it doesnt make.
Strange as i've used the LM P52 PP checklist a few times and not seen this
anyway just having a go at getting a few stars now
 
Top