Written by capcom Saturday, 25 October :18 - Last Updated Saturday, 03 January :49

Transcription

1 Introduction This article (titled "The quest for AGC State Vector propagation and orbital navigation") was originally published on another site and stemmed from some work done in trying to understand how to use the orbital propagation functions of the Apollo Guidance Computer software while running it on yaagc, the AGC emulator designed and distributed by Ron Burkey. Ron made the dream of "playing" with the Apollo Guidance Computer true, and we are incredibly in debt with him. Not only he designed and debugged a software emulator of the AGC (both in the CMC and LGC versions), but he also re-typed the hundred of pages of Colossus (for CSM) and Luminary (for LM) from barely readable copies. Today, the Virtual AGC project represents the only piece of real Apollo technology working: Apollo software, a historically unique effort by itself. Credits Ron provided some unique contribution to the material of this article and in solving some issues related to the conversion of floating point values within AGC. The article include info kindly provided at a second time by Christian Bucher. Disclaimer This page is devoted to some efforts I spent in trying and verifying one of the most interesting aspect of the AGC software. Interesting at least from my perspective that I steered toward a top-down approach to Colossus and Luminary. This is, I reckon, in contrast with the big activity which surrounds the AGC Simulator built by Ron, activity rightly concerned with bottom-up tests and verifications. Despite my upbringing in digital hardware and software I preferred to concentrate on the operational aspects of the software thanks to my availability of many interesting Apollo era documents. 1 / 14

2 Since I have to borrow time from my work and my family to pursue this quest, I concentrated my efforts to only this main topic. However, since I am now stuck, I am looking for some help trying to understand where something is wrong. I do expect the error to be mine, and if so I hope that these notes may be at least of help to somebody else. For this reason I will try to explain some aspects in more details that needed by the intended audience (AGC testers) but this is with the aim to clear any possibile misunderstanding I may have originated myself. Background Propagating a State Vector (SV) in time is one of the main tasks that the AGC software is called to perform. Propagating the SV means computing a new position and speed estimate (each in three-components cartesian space) according to different rules. The basic rule, followed while close orbiting a celestial body, is that of direct integration of the SV. While thrusting a different approach is needed, to take into account the accelerations imparted by the thrusting action, and in Midcourse navigation, yet another different integration technique is used to take into account perturbating effects by multiple celestial bodies. The nice thing is that basic integration, that is while idly orbiting, requires no external "hardware" connected to the AGC and it can easily be verified after some "few" keystrokes. These are required to set an AGC time, and to load a State Vector pad which is composed by three position components (radius, R), three velocity (V) components, and a time reference for the validity of the previus R and V values. The AGC (be it the CMC or the LGC) can load both its "own" SV and the "other" SV associated to the other vehicle, and propagate them both in time. This feature is required for a second set of computer routines, devoted to the rendezvous task. After loading the SV (or both) it is possible to query the AGC to obtain some interesting values, like the Apoapsis and Periapsis heights, the time to Periapsis, the Lat/Long coordinates of the subspacecraft point, predict a lat/lon passage, compute rendezvous range and range-rate values, and so on. This opens a whole range of "fun" for AGC enthusiasts and truly permits to "re-fly" part of the outstanding Apollo missions. 2 / 14

3 The next step will be of course that to perform rendez-vous procedures, but that will be another story. Loading the State Vector Getting State Vector pad values How do you get good SV values? In principle, the wealth of documentation available tells a lot (indirectly) about how to build a SV. It is not a complicated problem, after coming to terms with DP scaling issues (thanks Ron). However, to use a "safe" source I turned to Apollo missions transcripts and, after a "very exhaustive" search (letting my PDF reader look for "State vector" in the text) I settled on a set of data given by Mission Control to Ron Evans during the "solo" portion of its flight around the moon. The SV Update was performed before LM ascent and SV times provided were very close to the LM scheduled orbit injection time CMP Okay. And I am ready to start copying. CC Okay, it's a long one. The first one is the CSM state vector. 71; GET is 188:01:42. Index is 21. The following line is all data. I'll break about every five, if you want to stop me. Opposite 02 we go - data as follows: 01501, 00002, 77563, 77431, 77517, 45633, 00013, 11736, 65021, 43762, 11131, 31244, 07624, 10720, 10043, 17330, end of the CSM state vector. Read back. CMP Okay. VERB 71: 188:01:42; 21; 01501, 00002, 77563, 77431, 77517, 45633, 00013, 11736, 65021, 43762, 11131, 31244, 07624, 10720, 10043, CC Good show, Ron. Amid you want to brek here or do you want to take the LM state vector VERB 71? CMP If you are through with the computer, I might start the maneuver to attitude here. CC Negative. We still need the computer, Ron. CMP Okay. Let's go on with the LM then. CC Okay. I'll give you the same thing. Just interrupt me about every five. LM state vector, VERB 71; GET 188:19:00. Index 21 data follows: 01501, 77775, 77472, 77201, 77741, 70163, 00121, 16227, 77273, 41206, 17767, 36400, 05052, 15405, 10051, that's it. You can read back. Tne computer is yours CMP Okay, I'll go to BLOCK. VERB 71; 188:19:00; 21; 01501, 77775, 77472, 77201, 77741, 70163, 00121, 16227, 77273, 41206, 17767, 36400, 05052, 15405, 10051, Over. (A few exchanges later CC passed a CSM weight of 36032, considered to be for the CSM with Ron Evans alone) The A17 Flight Plan also carries predicted SV values for the same mission time, but I discovered that later and using the "flown" ones just seems to be very cool. Note. Additional CSM SV data are found in the A14 and A7 transcripts. However only during 3 / 14

4 A17, to my knowledge, a full set of compatible CSM and LM SVs have been communicated in voice (every mission had many SV updates performed by means of data uplink from Ground). It is quickly ascertained that the SV times provided to Ron Evans aboard the CSM were in the future of the then current AGC time (see the transcript time expressd as MET, or AGC time). It is also ascertained that those times, by looking in the A17 Flight Plan, corresponds to: - The CSM orbiting the moon, after the plane change maneuver (performed at 182:35:45) that aligned the CSM orbit with the LM ascent trajectory. Predicted Apolune and Perlune were 63.0 by 61.3 NM. - The LM, just injected into orbit after ascent with a predicted Perilune of just 9 NM and an Apolune of NM. LM insertion lift time was to be 188:03:14.6 with an insertion time of 188:10:32. After LM insertion the CSM would be just ahead of the LM and above it, ready for its passive role in the subsequent catch-up rendezvous maneuvers. The LM was scheduled to fly a direct-ascent rendezvous to achieve proximity operations with CSM after less than one full revolution. The CSI and CDH maneuver were therefore not required and the next maneuver would be the TPI at 188:57:32. The A17 Transcripts reports a GET lift-off time of 188:01:35.93 and a GET TPI time of 188:55:57.00, pretty close to the flight plan expectations. A separate (say "mathematical") verification of the data (that is SV validity) has been performed and it is described later on. Loading the data 4 / 14

5 Before loading the SV data it is necessary to bring the AGC time to a compatible mission time. It is important to note here that I am still referring generically to AGC because the data set may be used both by the CMC and the LGC. This has been indeed tested. To load the AGC time, V16N36 has been used, according to GN&C procedures found in various checklists, the CSM and LM Operations manuals and, of course, Ron's indication in its AGC Quick Start. Then, after reverting to V37E00E, the SV is/are entered, by using the AGC Update Program invoked with V71. Getting orbit information Upon completion of V71, with a V33E to accept the new data, the AGC is "navigating" in orbit and ready to answer some basic questions. The AGC routines of interest in this case are: - V82 (or R30) which provides the computed HA and HP, based on the current SV, and the Time to Periapsis through the V06N32 monitor or the V16N32 display. - V83 (or R31) which provides the basic rendezvous parameters of Range, Range-rate and Theta (the orbital angle between the vehicles). - V90 (or R36) which provides out-of-plane data for rendezvous. - P21 which provides the Lat/Long information and additional information for tracking landmarks (but that require the IMU to be operating) Arriving at this stage, with the above-mentioned SV load(s), the AGC seems to be working but unfortunately without producing the intended HA and HP values. The rendezvous parameters are also most likely incorrect and the lat/long data are impaired by a secondary issue linked to an infamous quantity, TEPHEM, to which a dedicated paragraph will be devoted later on. 5 / 14

6 Troubleshooting After many tests the following precise sequence has been checked out and is made available. The primary target of the test has been Luminary131, so from now on I will refer to LGC only. What follows is the full list of keystrokes performed after yaagc startup. Results are provided where required and commented. First test, part 1 - LM SV loading *** Initial conditions: yaagc restarted from scratch *** RSET to clear PROG error# Step 1: Load AGC Time 188:20:00.00 # Time value chosen to be very close to the SV loaded.1. V25 N36 E 2. FL > E FL > E FL > E# Step 2: Load SV for LM (as per published procedures)1. V37 E 00 E 2. V71 E 3. FL > 21 E # Index word (number of locations to load) 4. FL > E # Start of SV buffer 5. FL > E # SV for LM in Lunar Orbit 6. FL > E # SV RX_high component FL > E # SV RX_low component FL > E # SV RY_high component FL > E # SV RY_low component FL > E # SV RZ_high component FL > E # SV RZ_low component FL > E # SV VX_high component FL > E # SV VX_low component FL > E # SV VY_high component FL > E # SV VY_low component FL > E # SV VZ_high component FL > E # SV VZ_low component FL > E # SV T_high component FL > E # SV T_low component 7. FL > V33 E # Accept data # We are now back in P00.# Step 3: Ask for LM orbital parameters (at LGC time of about 188:24:00)1. V82 E 2. FL > PRO # To select LM 3. FL R1: # i.e NM for HA R2: # i.e NM for HP R3: # TFF not available 6 / 14

7 4. PRO First test, part 2 - CSM SV loading # Step 4: Load SV for CSM (as per published procedure)1. V37 E 00 E 2. V71 E 3. FL > 21 E # Index word (number of locations to load) 4. FL > E # Start of SV buffer 5. FL > E # SV for CSM in Lunar Orbit 6. FL > E # SV RX_high component FL > E # SV RX_low component FL > E # SV RY_high component FL > E # SV RY_low component FL > E # SV RZ_high component FL > E # SV RZ_low component FL > E # SV VX_high component FL > E # SV VX_low component FL > E # SV VY_high component FL > E # SV VY_low component FL > E # SV VZ_high component FL > E # SV VZ_low component FL > E # SV T_high component FL > E # SV T_low component 7. FL > V33 E # Accept data # We are now back in P00.# Step 5: Ask for CSM orbital parameters (at LGC time of about 188:28:00)1. V82 E 2. FL > V22 E 2 E PRO # To select CSM 3. FL R1: # i.e NM for HA R2: # i.e NM for HP R3: # TFF not available 4. PRO# Step 6: Ask for rendezvous parameters (at LGC time of about 188:30:00)1. V83 E 2. FL R1: # i.e. Range 75.5 NM R2: # i.e. Range rate 300 fps (closing) R3: # i.e. Theta 90 degrees 3. PRO# Step 7: Ask for rendezvous out-of-plane display (at LGC time of about 188:33:00)1. V90 E 2. FL > PRO # To accept current time 3. FL R1: # i.e. Gamma 0.08 NM R2: # i.e. Gamma rate 0.1 fps R3: # i.e. Psi degrees 4. PRO First test - Discussion 7 / 14

8 The test performed correctly in terms of operations but most of the data produced are not those expected. In step 3 the expected HA and HP were respectively about 47 and 9 NM and what we see is a much wider orbit (close to 1000 NM in altitudes). However, and this hints to something useful, the delta height is more or less correct! That is, it is about 39 NM. In step 5 we see the same kind of errors for the CSM. Expected HA and HP were about 63 and 61 NM but we read again altitudes close to 1000 NM. Again, however, the delta height is very close to the expected 2 NM! I first suspected that the LGC might think it was around the Earth. Looking at the code I found two flagwords bits which are of interest (the "absolute" one and the one used by V82). Both were checked to be at the proper state in the proper moment. That is the main flagword bit was found set to 0 (Earth) at "power on" and set to 1 (Moon) after loading the SV. The same for the other flagword, which was set correctly for use by V82. Despite noticing the strange behavior (wrong absolute value, correct delta value) I also checked the SV itself. This has been done converting the position components to floats (using CheckDec) and scaling them according to indications found in Luminary code (and pointed out by Ron). > > ( ) # Rx > > ( ) # Ry > > ( ) # Rz > > ( ) # Vx > > ( ) # Vy > > ( ) # VzScaling R components by 2^27 and computing R = SQRT(Rx^2+Ry^2+Rz^2) yields R = ,561 meters Subtracting meters (Moon radius) and converting to NM it yields H = 13, NMwhich is in agreement with an increase of altitude a little after the insertion time.on the other hand, scaling V components by 2^5 and computing V similarly yields V = 16, m/cs = 1678, / 14

9 m/swhich is broad agreement with orbital speeds for the moon at the same height. (Circular orbit speeds: 60NM -> 1633 m/s, 10NM -> 1670 m/s). Having cleared the SV from indictment I played a lot with the various results. The final outcome has been found subtracting the Moon radius from the values given by V82: HA = NM = m -> XA = HA m = m = 47.0 NM HP = NM = m -> XP = HP m = m = 7.3 NM These values agree perfectly with those expected! And the same has been verified for the CSM SV propagated by the LGC: HA = NM = m -> XA = HA m = m = 61.2 NM HP = NM = m -> XP = HP m = m = 60.4 NM Perfect agreement! In other words, it seems that the AGC provides correct orbital parameters but these are expressed in distance from the Moon center, instead of being altitudes over the Moon radius (reference is the landing zone radius). This cannot be, for instance, a simple difference between SW versions (like an older SW behaviour) because HA/HP values as these were required even during A7 for maneuvers execution. Rendezvous parameters are also not correct. Since the CSM is more or less above the LM at 9 / 14

10 the given times, it was expected that the Range between the two vehicles to be about like the difference in orbital altitude. V83 gives a range of 75.5 NM which is pretty incompatible with the expected 40 NM (about). Also the Theta angle (l.o.s. angle between the LM and the CSM) seems to remain fixed at 90 deegrees while it should slowly change to lower values. On the other hand V90 correctly gives that the difference between orbital planes is close to zero (CSM performed a Plane Change Mnvr just to get in the same plane of the LM orbit), but the Psi angle value, which express the "phase" between the two vehicles, could be right or wrong depending on some assumptions. Second test - Getting more info One way to see if the LGC was "thinking right" while providing bad data is that to use timing information about orbital period. The V82 routine also provides a Time to Perifocus through display V06 (or V16) N32. After re-starting using the above-described sequence I got from V16 N32 a value of about one hour and a half in the future. I thus reset the AGC time to the future (188:45:00) and watched the Time to perifocus reach 0 after a few minutes from invoking the display. I expected it to reset to the new Time of perifocus time instead (quite logically) it continued to count up. Since I wanted to know the time from one perifocus to the next (to get an orbital period) I quickly reset the display but after that the AGC hung, seemingly processing the SV back in time (you can monitor SV integration by using V16 N38). No other command was accepted, not even a restart. For information, the orbital period expected for the CSM orbiting at 60 NM is about 126 minutes. Colossus test 10 / 14

11 I repeated all the tests before-mentioned with Colossus249. I was amazed by the fact that I got practically the same numerical results from V82 and V83 and also V90 (but with a Psi angle of which in a certain sense concurs with the LGC value of ). I do not want to draw any additional comment here, but apparently this clears the work of Ron because two different codes produced the same numbers. Lat/Long and TEPHEM The best way to check if the navigation algorithms work is that to check the predicted sub-spacecraft point over the surface being flown over. P21 offers a Lat/Long monitor (and tried it only once and if I remember well it requires the IMU operating flag to be set). However, every geographical routine needs to know how the Moon (or Earth) is oriented in space at any given moment. The issue here is that of establishing a time reference and counting Moon rotations from that time. In order to simplify AGC software, and considering that the AGC time is expressed as MET, Mission Elapsed Time, which reads 000:00:00.00 at lift-off time, a reference called TEPHEM is required to link all "astronomical" computations (including Sun and planets positions) to a common time. AGC has also limitations in expressing time with 24 bits so the reference could not be some typical astronomical Ephemeris Time reference. TEPHEM is a time quantity (24 bit time, expressed in centiseconds) which is the difference between the UTC time used for reference and the UTC lift-off time. By adding AGC Time to TEPHEM the AGC routines can campute all the required planetary positions and rotations. 11 / 14

12 The problem is that the reference is (to my knowledge) unknown. It is also a mission dependent value. It was typicall corrected in the CMC after launch if the lift-off wasn't as scheduled, and it was provided to the LGC as part of its activation procedure. Unfortunately, most of the times it was uplinked directly from ground so no mention of its value is provided in the transcripts. (In the transcripts it can be found that MCC informed the crew that a new TEPHEM was uplinked. A14 also had some issues with TEPHEM). If we want to really play with the AGC we need to find the right value for TEPHEM or a way to compute it (loading is via V70, Update Lift-off Time). Conclusions (for now) The SV provided in input is most likely correct, and the AGC responds well to data loading and routines invocation. The buffer area (01501) has been also checked and indeed is allocated in the Erasable Assignments. I do not want to discuss possible issues that hamper the correct display of orbital data and/or SV integration. This page serves the purpose of communicating my minimal effort while also asking for help. Most likely all this is the result of a fault of mine in missing some minor, or not so minor, initialization detail. I hope someone will able to point out the problem. Any further results will be published here as soon as available. Of course questions and comments and contributions are welcome! New results Orbital parameters issue solved! After posting the above discussion, Christian Bucher started its own analysis of the problem. After a few iteration he correctly suspected that the Landing Site radius (on the Moon) value 12 / 14

13 wasn't set (or it was set to 0). I was initially suspicious of this because I supposed that such a quantity, as much like as the Launch Site radius (on the Earth) should have been set. Indeed a Moon radius quantity exist in the constants. However Christian paid much more attention to Luminary source code and he found that the required Landing Site radius value MUST be set in order for the orbital navigation routines to work. Now it is my pleasure to point you to the excellent and well detailed page (link to be updated) that Christian wrote on the subject and that I host together with mine. Using his notes you can happily load a State Vector and use many of the orbital programs available including (wow!) rendez-vous routines. Not everything is solved, however. Please read on. Still to solve The Landing Site issue radius poses an interesting question: why updating the value is not part of the GN&C procedures for the LM (or even the CSM)? Even looking at flight plans I wasn't able to spot a place where such information would have been required. Everything seem indicate that the value was hard-loaded in the AGC (for both spacecrafts) but this is not true for the Luminary and Colossus codes we have at hand. Can anybody provide some light about this issue? Another important point to consider, is that of the TEPHEM quantity. I already discussed this issue previously, but now it is of primary importance. Here follows the same discussion in other words. In order to establish positions of celestial bodies like planets and the rotational references of the Earth and the Moon, a set of equation to compute classic planetary ephemeris are available in AGC. Apart for IMU aligning purposes, knowing the rotational characteristics of the reference planetary body (be it the Earth or the Moon) is important to establish the sub-spacecraft latitude/longitude coordinates. They are also required to predict overfly of a given lat/lon and to predict Earth landing zone. 13 / 14

14 In order to save space and probably computational capability, ephemeris data are expressed in acompact form referred to a time reference CLOSE TO THE LAUNCH DATE OF A GIVEN MISSION (this is most likely due to the limitation of the AGC on board time counter). Luminary source code refers to 1st of July (?) reference. In order to get a good Ephemeris Time (or TEPHEM) one has to add to consider the actual launch time and indeed this time is often referred in Flight Plans, Transcripts and, of course, GN&C procedure, for which a dedicated Verb exists. Now the problem is simple: how do we find a good value for TEPHEM? I think that references to the 1st of July were probably good for A11 but not for the other missions. And we know that the code we have at hand was NOT that of A11. It is interesting to note that if ephemeris data are limited in time, then the AGC software cannot be used (at least of orbital navigation purposes, including the critically important landmark routines) outside the time span of a well defined moon mission. Any thoughts on this? Last originally updated, 08/01/ / 14