Space Center Oral History Project
Edited Oral History Transcript
by Jennifer Ross-Nazzal
Houston, Texas – 7 December 2006
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.
Especially all the hard work that you’ve put into this.
Oh, well, thank you.
Last time we ended with the year 1965, and I’d like to start
by looking at the year 1966.
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,
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
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,
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
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 (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
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
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.
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?
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
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
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.
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.
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.
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?
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.
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?
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.
That’s pretty amazing.
It’s primitive compared to today.
Especially when you think of the size of a calculator, the way you
described that size.
Yes, they were about the size of IBM Selectric typewriters.
Did you have any questions?
Okay. Well, I guess we’ll stop here—
—and give you the opportunity to look through your records for
to JSC Oral History Website