[NASSP 8][Apollo 8] State vector propagation stuck?

STS

Well-known member
Joined
Feb 1, 2009
Messages
560
Reaction score
316
Points
78
Location
Vigo
Website
orbisondas.es
Hey guys

I am practising Apollo 8 and I think I got to a glitch. I am at GET 05:20:00 and I ran P21. However it never finishes, and State vector seems as stuck around 68:53:36 (V16N38).

I did two of the three P23 runs.

Can you check if something is wrong?

Best regards.
 

Attachments

Hey guys

I am practising Apollo 8 and I think I got to a glitch. I am at GET 05:20:00 and I ran P21. However it never finishes, and State vector seems as stuck around 68:53:36 (V16N38).

I did two of the three P23 runs.

Can you check if something is wrong?

Best regards.
You used "69:10:00" for your P21 time, so you are forcing it to propagate out to that point. The actual mission stalled out as well here.

007:27:43 Borman: We can't get the Program 21 to integrate up to LOI; just stalled out around 61 hours and 2 minutes.
007:57:43 Mattingly: Okay. On P21, the thinking runs that you had a slight error in your state vector at the time you started, and when that was integrated out, it intercepted the lunar surface where it locked up and this is contained in a fairly recent program note.

Post-flight analysis of their trajectory is included in the Mission Report on page 5-9. In table 5-III, the best available state vectors that resulted from a manoeuvre are calculated forward to show the expected time and altitude of closest approach to the Moon. According to this table, their current trajectory as set by their second separation manoeuvre is too fast and, if uncorrected, would swing them behind the Moon at an altitude of 848.4 kilometres. However, Mission Control are still analysing their flight path and the state vector within the spacecraft's computer is out of date. When P21 calculates it forward, it shows the flight path actually hitting the lunar surface (in a mathematical sense) whereupon, the program refuses to go on working.

Ken Mattingly's comment regarding the 'program note' might very well resonate with those readers who support any software application. Even in the 1960s, software vendors maintained documentation of known bugs and programming limitations in their products. It is often said that few if any bugs were discovered during a flight. This is perhaps quite true, but the conditions known to create problems were well documented in program notes. Procedures and mission rules were designed to avoid these problematic situations.
 
There's something deeply satisfying about the number of times I've seen NASSP "bugs" on OF, in effect, marked as "WONT_FIX (bug-compatible)".
Well the nice thing about running the actual AGC software for instance is we get the actual quirks and bugs the astronauts dealt with ?
 
Yeah, your current trajectory seems to impact the Moon and so does the AGC state vector. In the later AGC software they added a program alarm for this, alarm 430 "Orbital integration has been terminated to avoid possible infinite loop". If I change the software used for Apollo 8 to Comanche 45 (Apollo 10 CMC) then I do get that alarm instead of the infinite loop in your scenario. So they at least taught the AGC to handle this case a little bit better.
 
Back
Top