NASA Johnson Space Center Oral History Project
Edited Oral History Transcript

Emil R. Schiesser
Interviewed by Jennifer Ross-Nazzal
Houston, Texas – 7 December 2006

[The questions in this transcript were asked during an oral history session with Emil R. Schiesser. Mr. Schiesser has amended the answers for clarification purposes. As a result, this transcript does not exactly match the audio recording.]

Ross-Nazzal: Today is December 7th, 2006. This oral history with Emil Schiesser is being conducted for the Johnson Space Center Oral History Project in Houston, Texas. Jennifer Ross-Nazzal is the interviewer, and she is assisted by Rebecca Wright.

Thanks again for joining us this morning. We appreciate it.

Schiesser: You’re welcome.

Ross-Nazzal: Especially all the hard work that you’ve put into this.

Schiesser: Oh, well, thank you.

Ross-Nazzal: Last time we ended with the year 1965, and I’d like to start by looking at the year 1966.

Schiesser: Okay. There was an extensive amount of work being done on the Apollo Program, and in our area it centered on the development of the Mission Control Center ground navigation capability and the Apollo onboard flight software. At the same time we were involved in the Gemini Program ground based navigation.

At the tail end of 1965, November, [Howard W. “Bill”] Tindall had called together a group of people to address what happened on Gemini Titan V. I believe that’s the mission where the landing was off by quite a distance, 92 nautical miles. One of the IBM [International Business Machines] guys, Frank Ditto, came up with a list of possible navigation causes, but as I recall, the actual fault lie elsewhere. A programmer truncated the numerical value used for the rotational rate of the Earth so that it wasn’t accurate enough to locate the landing site for deorbit computations.

The Gemini Program wound down in 1966. By the end of the year it was over. I didn’t have a direct role in the in-flight execution of the navigation function in the control center for those missions. Jim [James C.] Stokes did the ground based navigation orbit determination during all of the Mercury and Gemini flights, first at Goddard Space Flight Center (GSFC) Greenbelt, Maryland, and later when the function was transferred to JSC.

During 1966 and into 1967, the definition of ground navigation displays and controls, tracking data reception, handling and preprocessing, and an orbit prediction capability was continued in addition to the navigation filter analysis and formulation effort mentioned earlier. The orbit predictor is used to estimate prior or future position and velocity and associated orbital elements given an initial estimate. It is also used to define the trajectory or orbit that is adjusted to fit through tracking data to determine position and velocity. The predictor does this through a step-by-step integration of the effects of the forces acting on the vehicle. Provision was made to include the effect of planned future maneuvers and historical maneuvers.

We selected an Encke orbit or trajectory prediction approach for computational, numerical, and other reasons, following numerical evaluation of various options. There was a substantial effort developing the Apollo ground navigation program, including the requirements formulation, implementation, and testing. The final formulation was described in a requirements document, published and shipped over to the division that was responsible for its implementation into the control center in accordance with a review and approval process. That set of requirements went through revisions over time, so it wasn’t just one time delivery.

The Mathematical Physics Branch had a group that included Paul [M.] Mitchell and Sam [Samuel O.] Mayfield and Art [Arthur C.] Bond, Bill [William] Boyce, Sue Shaper and others, who were engaged in estimating the accuracy with which position and velocity could be determined throughout the flight through the use of error analysis techniques.

The location of the trackers that belonged to the Manned Spaceflight Network used during Mercury and Gemini were initially determined through classic geodetic means. The location of the Hawaii tracker was mislocated relative to the U.S. and other worldwide features. In March of 1966, it was determined that the geodetic coordinates for the Hawaii tracker were off 700 feet. I guess it was determined earlier than that, since there were a series of meetings about that subject with Goddard, who was responsible for the network. GSFC was reluctant to change the location of Hawaii based on the results from tracking satellites but finally between their effort and ours the tracker location was updated, which just means that we wrote different numbers down for its location and used them in the processing of the data during the flight. The error in the location of center of the current Deep Space Network antennas is measured in centimeters.

The Apollo Navigation Working Group, mentioned previously, was periodically meeting during 1966. It had expanded to include support from Marshall Space Flight Center [Huntsville, Alabama] and MIT [Massachusetts Institute of Technology, Cambridge, Massachusetts] though to a lesser extent perhaps than Goddard and JSC and JPL [Jet Propulsion Laboratory, Pasadena, California].

Joe [Joseph R.] Thibodeau joined the branch around 1966, and was engaged in a variety of activities including coordinate transformations. At that time Jim [Troy James] Blucker was working on Apollo Command Module onboard attitude determination through the use of the sextant and telescope. And we seemed to get fairly heavily involved in various aspects of the rendezvous navigation tasks in 1966.

In September, we published the basic requirements for the Apollo 503 mission ground navigation program. Some of the contributors to that were Laurel [A.] Phillips, Bob [Robert T.] Savely, myself, Wilene Coym, Gerry [Howard G.] deVezin, Mike [Michael] Oles, and others, including such as Sam [A.] Kamen, Larry [J.] Dungan, Mike [Thomas M.] Conway, Lamar Bannister from Analytical Mechanics Associates, one of the people that Sam [Samuel] Pines hired to help us; Sam himself, and Jane Morgan from IBM. The IBM people were Frank Ditto, of course, Schiller [phonetic] and Roberts [phonetic], and there are some others that I likely left out.

During this time we were occasionally asked to look at Apollo Applications Program support. They were beginning to think about follow-on activities to the Apollo Program. There were a number of activities in the onboard area. I think the reason this came about is because there was a lot of concern about the development of flight software for the LM [Lunar Module] and the Command Module at MIT, and Bill Tindall was assigned somehow to work that. He would spend two or three days each week in Boston [Massachusetts]. The onboard software development processes were apparently not as well disciplined as for the Mission Control Center. I personally don’t remember much about this subject and those interested might find more about it in a book published by [James C.] Tomayko [Computers in Spaceflight: The NASA Experience in] 1987, including some description of Tindall’s entrance into that activity and some of the ways that he worked it with the MIT people.

Tindall established a means for checking and qualifying what was happening in the way of formulation development and software design and implementation, and as a result our branch got involved in that aspect of it. We created software programs that numerically duplicated the onboard navigation computations to evaluate navigation performance for checkout and verification of flight software.

As a result of that, we had an ability to support the flights by staffing an onboard navigation console (O-Nav) in the Houston Mission Control Center. We had a good understanding of the onboard navigation capability in the Command Module and Lunar Module. In 1966, I think, Bob Savely, who was heavily involved in ground based navigation, was turning more and more of his attention, along with Jim Blucker and others, to flight software and the onboard navigation capability and the support of that function during the flights.

Flight simulators were developed to train the astronauts and those that participated in flight operations in the Mission Control Center. For all appearances, the control center people witnessed the flight as it would occur. The simulator was able to generate simulated ground tracking data, range, and Doppler measurements, as per an actual flight, and it was up to the ground based navigation console to extract position and velocity from the data the same as if it came from actual trackers. At first I think most of the emphasis was on training the flight control team without an ability to simulate the tracking data for the ground navigation console, but we wanted to make sure that our people were trained to do the ground navigation job and requested the added capability.

Somewhere about this time Wilbur R. Wollenhaupt, who went by Bill, joined our group. He had extensive background in ground-based navigation at JPL. He was pretty familiar with the JPL Deep Space Network (DSN) Trackers after which the Apollo trackers were patterned. He had actually walked around on the dishes. The DSN trackers were 85 and 210 feet in diameter. He was familiar with how these trackers operated and what it was like to actually run one of them, plus he had knowledge of the orbit determination process.

It was a really big blessing that we got him, and I don’t know how that happened. I guess the managers took care of us. Bill’s not available to ask anymore; he has long since passed away. Bill was put in charge of ground coasting phase navigation, and that was cradle to grave. Although he didn’t participate in the formulation and the creation of the ground program, he was responsible for its use including checking out the end-to-end system including the tracking network. He worked with Goddard and, I suppose, JPL to some extent, on that.

Although the Manned Space Flight Network was created for Apollo and was in addition to the three Deep Space Network sites that were already in use by JPL, we used three JPL DSN trackers also. All together there were around seventeen trackers located at fourteen sites. Three sites had two trackers. The Apollo ground navigation capability didn’t get built all at once. Aspects of it were in use prior to Apollo 8 for Earth-orbiting missions, and in time more of the lunar-type capability was added.

We were fortunate to have access to some very capable people such as [Raynor] Duncombe at the [U.S.] Naval Observatory [Washington, D.C.], an expert in how to keep track of time, universal time coordinated [UTC], UT-1, UT-2, and folks at JPL who used sophisticated time management methods. Around this time frame there was an increased need for programming support to help us with the development of software for engineering analysis in addition to the engineering software developed by TRW [Thompson Ramo Woolridge] as part of tasks assigned to them.

There was a Computations and Analysis Division (CAD) and an average of about nine CAD software development and software engineering type people supported us toward the end of 1966. During this time our branch had interfaces with higher level managers, Dr. [Joseph F.] Shea on down. Jim [James C.] McPherson, the branch chief, was an excellent mature manager, and would brief the higher level management on the work status, technical and otherwise.

The partitioning of the navigation function between the ground and the onboard systems was still in work in 1966. The overall navigation system, the end-to-end system, was a combination of the ground and the onboard capability. Certainly by 1966 it was known that the ground was primary for the determination of vehicle position and velocity during the travel to and return from the Moon and in lunar orbit, with an onboard backup capability if communications was lost with the ground.

The ground (Houston Mission Control Center) extracted spacecraft position and velocity knowledge from ground tracking data. The resulting position velocity was used to update the MCC mission ephemeris, transferred to the spacecraft for use onboard, and used to determine the maneuvers the spacecraft had perform in order to reach the intended destination. Once off course, the task was to create an efficient means for arriving at a desired destination rather than to get back on to the pre-mission planned trajectory. That was a task performed by other elements of the MCC including support from MPAD [Mission Planning and Analysis Division] mission planners.

Onboard knowledge of position and velocity is often used to maintain vehicle attitude or orientation relative to the Earth or Moon. The computer knows down from up for attitude control based on vehicle position knowledge. At other times the vehicle is aligned relative to stars. During a maneuver the change velocity due to the engines is measured through the use of IMU [Inertial Measurement Unit] accelerometer data to cut off the engine when the applied change in velocity matches the intended. The IMU accelerometer data are also used onboard to propagate a pre-burn position and velocity through the maneuver. After a maneuver, the Mission Control Center retrieves the onboard measured change in velocity and the onboard estimated position and velocity vector through telemetry and uses that information for initial estimates of the effect of the maneuver on achieving intended target conditions. Fresh estimates of the actual trajectory are made as more and more post maneuver tracking data arrives until the solution is freely determined only on post maneuver ground based tracking data.

In-flight navigation techniques were in the process of being developed in 1966, but probably more so in 1967 and in earnest in 1968. For example, the development of means for convincing ourselves in-flight as to what actually happened during an orbital maneuver and whether the vehicle was on the proper course, the ability to know that a solved for position and velocity were indeed valid, and to assess the accuracy of that knowledge.

That brings me to Tindall’s “data priority” activity. Tindall was given the task of working out all of the flight techniques required for the execution of the Apollo missions around 1967. I think the effort went by two names, Flight Techniques or Data Priority. This was a tremendous, difficult job because in order to determine what needed to be done to conduct the missions, both missions that went as planned and the activities that needed to be in place to address things that might go wrong, Bill had to coordinate all of the factions of the program that were involved in the development and operation of the spacecraft, Mission Control Center, and other Apollo supporting ground facilities. Everything from hardware, software, the flight crew, the ground operations people, flight controllers, and all of the associated disciplines had an interest and input to be coordinated and resolved.

Tindall had the authority and the capability to work this area, and those that would be interested in following some of these activities in detail could review the “Tindallgrams,” of which there are still copies. A review of the Tindallgrams would likely provide insight to the way he approached the problem, the thought processes, and provide some idea of how the data priority task was organized and accomplished.

Tindall was very fair in conducting the meetings. He listened and respected all, belittling no one. The meetings would have anywhere from a few people up to perhaps seventy or more in them, depending on what was needed and how much exposure there had to be in real time as compared to after the fact. Of course, there couldn’t always be a consensus. He would make the final decisions and though not all would agree, the decisions were respected. For example, if engineers could not agree on a number he might choose one if it was necessary. Upon the expression of concern by those present he would mention that all should go with that number and at such time as it was determined that it was not acceptable to come back with a better value and a good reason to change it and it would be changed. He knew that the activities and analysis in place would result in an assessment of the number and by choosing or defining its value, with a degree of wisdom, he kept the program moving forward. If it weren’t for Tindall we would never have landed on the Moon before the end of the decade, as requested by [President John F.] Kennedy.

TRW engineers helped us create duplicates of the Command Module and Lunar Module flight software to run on our engineering computers. That is, given the same input the software, when run on engineering computers, would create the same numerical result as the flight software, though it was programmed in a different language and had other internal differences. We used those programs to help check the actual onboard flight software, to predict navigation flight performance, and to prepare for in-flight support.

I was an engineer from ’61 to ’63, served as a section head from ’63 to ’68 and as assistant branch chief from ’68 to ’73 when I was appointed branch chief. Additional engineers joined the branch in ‘66 and ‘67 and our interfaces with other people were becoming more involved and complex.

Ross-Nazzal: I’m wondering if you could describe for us that complexity. How were you able to share information with people in California, Maryland, Alabama, and the other experts?

Schiesser: I guess—hmm, that’s a toughie. Some of the easy parts of that answer are that we had the formal organizational structures, such as the Apollo Navigation Working Group [ANWG], which specified or enabled the working arrangement between NASA centers. An ANWG charter was created by [John P.] Mayer and [Fritz] Von Bun and approved by NASA Headquarters [Washington, D.C.] and at the NASA Center directorate and division levels. We were paired with counterparts at MIT relative to spacecraft flight software as the result of Tindall’s activity. At JSC, we had a structured relationship with those in charge of Mission Control Center development, including the software in the control center used for flight operations. A formal process was in place for the transfer, acceptance, implementation, test, verification, and use of control center software between the Mission Planning and Analysis Division and others within the division in charge of the JSC Mission Control Center. I think the division in charge of the control center was called the Ground Data System Division (GDSD) and at the time Lynwood Dunseith was the division chief. Maybe it was called the Flight Support Division. Others could perhaps comment on the variety of other formal and less formal working arrangements as an expansion of the above.

Larry [J.] Dungan and Mike Conway were GDSD engineers and following the control center software development, including that required for ground based navigation. GDSD had computer supervisor civil service people who were in charge of the control center computers during the flight, including Bob [Robert C.] Arndt and Earl [L.] Shinpaugh. I’m not sure of the proper descriptions of their positions, but it think these controllers were the only ones in the control center that could issue a command to the computers.

The unfortunate circumstance is that I have really not too good of a memory, and I could hold together in my head the complexities of the results of the meeting or the decision process for a while, but then it would leave. So what I would do is make note of them. If it was important and something that needed to be retained or sent out, I would write a memo of it. These had to be hand-typed.

There were layers of documentation all the way from notes, handwritten notes in a journal, all the way up from section- and branch-level memos, to more formal documentation, and including documentation that was scheduled and required for the capability development and use, such as the requirements documents and testing documents and so on, and letters of request or response that had to be written for the appropriate level of signatures. There was a formal process for defining the constants to be used in the ground and onboard navigations systems. Specific engineers were responsible for the creation, review and certification of that data. We were responsible in our branch for taking the JPL ephemeris data (DE-19 ephemeris tape), which defined the location of the Moon and planets, and preparing the data in an efficient form for use during the flight, and for other ground and onboard navigation related constants.

The Math Physics Branch was very fortunate to have had some really outstanding office management and secretarial support from Barbara Beasley, Norma Jean Wyscarver, whose married name is Dell’Osso, Faye D. Broussard, and later Sally [A.] Sanford. We had a good-sized branch with a lot of activity going on and Norma was for many years our lead support. The branch secretaries reported to the division secretary. That would be John Mayer’s secretary [Doris P. Folkes]. She was always friendly and, I don’t know, a positive and easy-to-talk-to person. I think John Mayer invited her to JSC from Langley [Research Center, Hampton, Virginia], so she would be one of the original Langley people, and stayed with him, I think, the entire time he was division chief, until he quit.

Ross-Nazzal: I have a general sense, but I’m wondering if the general reader of your transcript online might not have a sense of what the difference was between the Manned Space Flight Network and the Deep Space Network. If you could, describe the two.

Schiesser: Oh, sure. Yes, the JPL Deep Space Network had been in place for some time and was used for the Ranger and the Surveyor missions to the Moon, to support the Langley Lunar Orbiter missions, and planetary missions. The DSN trackers were, and still are, located at three sites: Goldstone, California; Madrid, Spain; and Canberra, Australia. Each site had multiple trackers, for instance, the 210-foot diameter dish, and 85 foot dishes.

The Headquarters people, I don’t know how, came up with a directive to create the Manned Space Flight Network. It was under the sponsorship of Goddard Space Flight Center. It had two parts to it, what they viewed as deep space tracking sites with 85 foot antennas, located at and compatible with JPL’s Deep Space Network, and what they viewed as an Earth-orbiting satellite tracking network which consisted of thirty-foot diameter dish antenna S-band sites, about a dozen of them, scattered around the Earth within the latitudes that we expected to fly in Earth orbit. We also had a C-band network, although I think they were predominantly DOD [Department of Defense] trackers, supplemented with some NASA-owned C-band skin and beacon trackers.

These C-bands could either bounce the signal off the surface of the satellite or vehicle, or they could interact with a transponder on the vehicle. The C-bands did not provide us with Doppler measurements but with range and angles off the antenna mount; azimuth and elevation in the case of the C-bands. The S-Band trackers provided range and Doppler, plus angles, but these angles were x and y angles off of a different type of a mount.

In practice both the eighty-five-foot trackers located at the DSN sites and the thirty-foot trackers were used all the way to the Moon and back, so we had three or four trackers concurrently in use all of the time. The thirty-foot S-band trackers, which were, I think, intended for Earth orbit use, were extremely important and necessary for cislunar and lunar orbit navigation purposes.

That’s basically an overview of the Deep Space Network and the Manned Space Flight Network. In practice I believe we utilized some of the Deep Space Network trackers as well as the Manned Space Flight Network trackers, where it was needed. The Apollo network is gone except for the Merritt Island [Florida] thirty-foot tracker and two of the eighty-fives, which they’re talking about decommissioning. It would not be possible to conduct Apollo type navigation today since the network and the required Mission Control Center software are gone.

Ross-Nazzal: Earlier you had made reference to the limitations that you had in terms of computers on the ground. Could you share with us what some of those limitations were?

Schiesser: Yes. Well, that breaks down into those used for the control center and those used for engineering software, and then, of course, there’s a third component, the onboard computers. I could say a few words about that now, but then I’ll need to refresh my memory on the rest of it.

On the Mercury Program there was no onboard computer. We had a sequencer, and it was necessary for the ground to tell the Mercury capsule the time to fire the retrorockets to achieve deorbit. The Gemini spacecraft had an onboard computer and it was needed in order to execute the rendezvous. There is a transition from just strictly ground capability on Mercury to a combined ground-onboard navigation function for the first time on Gemini. The orbit determination for coasting orbital flight was done on the ground, but for rendezvous there was a degree of onboard autonomy. In the case of ground engineering computers, we had an IBM 704 to begin with and later the use of UNIVAC 1108s. A description of the computational characteristics of these machines would include the word length and execution speed, how long it takes to do a division or multiplication, for example; and how much memory was resident in which the program could execute. There were three layers of memory, rapid access main memory, fast magnetic drum access and the magnetic tapes. Off the cuff, I just don’t quite remember how all that played out for the engineering machines.

The control center used IBM 360 machines. These main-frame computers were inferior to the current desktop computers in terms of memory and speed. I remember being assigned, in the eighties I think, to a Tiger Team to address where the control center might evolve to, and for my part I asked the group what the implications would be if someday the entire room of computational capability could be handled by a box on a table. The question wasn’t addressed, but that’s about what’s since happened.

The current control center is different from the one used during Apollo in a number of regards. One of the aspects is that servers take the place of that huge room of equipment. There is still equipment to receive telemetry and tracking data and feed it to the servers. But then the data also goes to workstations which have replaced consoles, and some of the computational capability in the mainframe has migrated to servers and other of it to workstations. There were problems associated with the migration from mainframes and consoles to servers and workstations that one might not imagine. For example: During a flight if we had a certain display up, we could get on the voice loop discuss it with ComSup [Computer Supervisor], and they would see exactly what we were seeing since the display was created by a common source. How does one ensure that both see the same display if each location has their own local computations driving that display?

So the functional capabilities of the Apollo control center were a challenge to reproduce with a distributed-workstation type of approach, not only from that point of view, but from the point of view of configuration control of the software. How do you ensure that the software that you’ve used for training, simulations and flight preparation, is, in fact, sound and not changed since the last time you used it and is properly configured for flight control, for a workstation approach that permits individual console operators to modify their software as compared to a central computational capability implemented with software from a single software factory? These questions were addressed and resolved long after Apollo and deep into the Shuttle era after my shift ended.

Ross-Nazzal: The last question that I thought of—I’m just curious. Other than using the mainframe computers, what were some of the other tools you used to do your job during this time?

Schiesser: Okay. We did have a local small computer for a while, an IBM 1620, but most all of the engineering computations were performed on an IBM or UNIVAC machine in the sixties and seventies. The extent to which people might have had a mechanical Frieden or some other means for arithmetic computations, I don’t know. I don’t remember using them. I think we did most of the work by keypunching up cards and hauling them over to run on the main frames. We didn’t get small calculators that could do trig [trigonometry] functions until the mid-eighties, well beyond the Apollo Program. If you wanted to get a sine or cosine, you had to do an interpolation from a table or else do it on a computer.

Let’s see. So it was a blessing when calculators such as the HP-35s came out with trig and other functions. They were very expensive. It was a thrill to get one. They cost three or four hundred dollars apiece, I think. Relative to engineering tools, I guess for us it amounted to computers and pen plotters, later calculators. The Engineering Divisions had more interesting tools.

In the case of control center flight support we just had displays that were defined, implemented and checked out. These contained digital data and crude plots. As I mentioned earlier, we had no control except to be able to call up a display, except through the ComSup people, who could edit a tracker measurement data point and control the configuration and execution of the navigation capability. Navigation console support was a pencil-and-paper activity. All the Apollo flight logs were handwritten. The logs included tables of results to keep track of navigation performance during the flight, all hand-done.

The control center mainframe computer software wasn’t readily modified and couldn’t be used by a console operator to perform arithmetic computations. After Apollo 12 we managed to get an Olivetti calculator more sophisticated than the Frieden. It might have been sort of a precursor to the handheld calculators we got in the mid-eighties. It was the size of a typewriter and it was utilized it in addition to hand calculations. There were a lot of new hand computations performed for the first time during Apollo 12 near Lunar Module powered descent

initiation in support of the pinpoint landing. Gerry deVezin and Alan Wylie were primarily responsible for them but Paul Flanagan and Matthew Grogan concurrently performed computations for confirmation.

Ross-Nazzal: That’s pretty amazing.

Schiesser: It’s primitive compared to today.

Ross-Nazzal: Especially when you think of the size of a calculator, the way you described that size.

Schiesser: Yes, they were about the size of IBM Selectric typewriters.

Ross-Nazzal: Did you have any questions?

Wright: No.

Ross-Nazzal: Okay. Well, I guess we’ll stop here—

Schiesser: Okay.

Ross-Nazzal: —and give you the opportunity to look through your records for ’67.

[End of interview]

Return to JSC Oral History Website