NASA Johnson Space Center Oral History Project
Edited Oral History Transcript

Jack Knight
Interviewed by Jennifer Ross-Nazzal
Houston, Texas – 10 July 2009

Ross-Nazzal: Today is July 10, 2009. This interview with Jack Knight is being conducted for the Johnson Space Center Oral History Project in Houston, Texas. The interviewer is Jennifer Ross-Nazzal, assisted by Rebecca Wright. He begins by discussing a chapter he wrote for the publication Legacy of the Space Shuttle Program: Scientific and Engineering Accomplishments.

Knight: The reason I wrote that the way I wrote it was based on the original story that Helen [W. Lane, editor] gave me as to what they were trying to do. Now it seems to have shifted some. What I experienced over many years with Operations was that all these outsiders come in, says, “Why does it cost so much?” They have some kind of notion that Operations ought to be real cheap, but it isn’t. Yet it’s only 6, 7% of the total Shuttle budget, but you always had these outsiders come in saying, “You guys.” It’s marching armies, and all this kind of thing. In fact, it wasn’t really so, but I was trying to somehow communicate the volume of the work.

From time to time over the years, we had a couple of astronauts inserted in as deputy director or associate director. One of them, Tom [Thomas D.] Akers came in. After he was there a few months, he said he just never understood or knew what MOD [Mission Operations Directorate] did. Now, of course, it evolved over the years. When you started out in Apollo, there were different divisions. Then there were a lot of mergers over the many years. So it became somewhat bigger. In fact, I guess in Apollo a good bit of the flight data file and a lot of the training was in the Flight Crew Operations and not in FOD. It was called Flight Operations [Directorate] at that time. There’s been a lot of evolution over time, but where we started out in Shuttle is about where we are now, with the exception [that] George [W.S.] Abbey [added] the NBL [Neutral Buoyancy Lab] and some of that stuff in Building 9 (mockups) into MOD. It became somewhat bigger in that we merged with the people that built the control centers. That became part of MOD. It’s now somewhat bigger than it was in terms of facilities. The core flight control thing, there was some merger there over the years. So it became bigger than it was.

Nevertheless, what I was trying to do was communicate the breadth of what MOD did. If you try to run it through just a single flight, you may not get that picture, because a good bit of the size of MOD has to do with the fact you have multiple flights in work simultaneously. If it takes you two or three years to build a trajectory, and what flows from that is part of the training trajectory and the training systems. Then you’ve got a flight a month or a flight every two months, so now you’ve got two years stack, stack, stack. You have to go down and see how many simultaneous flights in flow that you have. That tends to drive the budget. The picture people have is these guys that hop up on console and that’s it, and there’s a lot more to MOD. That’s what I was trying to convey.

Whether you can do that or not focused on a single flight, I don’t know, because I haven’t read what you’re trying to do. But let’s go answer these questions here, and then I can come and I will verbalize, and then we’ll see if I want to go back. You asked for some specific examples. Memory fades.

Ross-Nazzal: When I was going through the chapter I had some questions.

Knight: The last flight I worked, actually worked on personally as a flight controller, was STS-4. After that I was in management: technical assistant, a branch chief, and then eventually deputy division, division [chief], and then I moved to facilities. I can also give you some other names if you want to get some more detail. Why don’t we go through the questions or however you’d like to do this and then see where it goes.

Ross-Nazzal: That’s perfectly fine. I’m just looking for information to flesh this out.

Knight: Let me see. Did you get to read what I wrote?

Ross-Nazzal: I did, I did, yes.

Knight: Did you have any questions on those?

Ross-Nazzal: I’m wondering if you can talk a little bit more about the facility modifications themselves.

Knight: Let’s see. I numbered. You mean typical changes instituted at MCC [Mission Control Center], that question?

Ross-Nazzal: Yes, the typical changes instituted at the MCC for a new Space Shuttle mission.

Knight: Let me give you some more as background. The Mission Control Center originally, of course, was built for Apollo. Then it was modified or evolved over time. Some of it was just pure replacement of hardware. IBM [International Business Machines], “Here’s a new machine; we got a new operating system.” So we incorporated those kind of things, and then we laid our apps [applications] on top of that. As technology evolved, when you could justify it, you’d bring it in. Apollo evolved to Skylab, and then Skylab evolved to Shuttle. The Mission Control Center originally for Shuttle, from the outside, looked pretty much like it did for Apollo and Skylab.

Ross-Nazzal: You were using the same consoles for STS-1?

Knight: The console shells. Then what was internal to the consoles, there was evolution behind the scenes. Things that used to be done in separate hardware to drive event lights, for example, came into the Mission Operations Computer [and] were driven by software. The communications panels, for example, were originally all hardwired. If you wanted to change it you had wiring that went all the way down to the first floor and then back up to the second and third floor. We replaced that eventually with a system that was more software-oriented, so it was easier to change over time.

We started out the Shuttle with the mainframe, the MOC [Mission Operations Computer] and so on, although it was different hardware than we had originally. Like I say there was a whole evolution on that, and there’s a document that discusses that. That’s how we started Shuttle out. We had the third floor and the second floor. Then as part of that Shuttle, remember, was sold and approved by the [Richard M.] Nixon administration to be the only launch system for the country. So it had Department of Defense [DoD] stuff in it. The third floor was modified to be secure. They had this thing called TEMPEST [Telecommunications Electronics Material Protected from Emanating Spurious Transmissions or Transient Electromagnetic Pulse Emanation Standard Requirements] for RFI [Radio Frequency Interference] emissions and things like that. A lot of work was done on the third floor. There were access changes made.

The two floors became a little different. Until [STS]-51L [the Challenger accident], we flew the DoD flights off the third floor, and the second floor was generally other flights, although we could fly both on each. The modifications that were made were typically software, after that initial setup was done. [STS]-51L was in 1986. Then we were down for two and a half years. The country changed its priorities. DoD says, “We don’t like that Shuttle anyway, we want to go back and do our Titans,” etc. The country said, “We’re not going to launch satellites that can be launched off of unmanned launchers. We’re not going to risk crews,” etc. So we changed the whole mode.

Station was coming along. The model and the theory was that the building that we had for Shuttle was not enough to fly Station, which was a continuous operation when it came into place. So Building 30 South was funded and was built. At that same time, the commercial technology for minicomputers was blooming and was available, and we embarked on a process to distribute the processing, get away from the mainframe, which we deemed to be more expensive and go to these things. That was an evolution that began in the ’90s. The [new] building [B30 South] was finished ’93ish or thereabouts. We said we were going to populate that out. We were going to do that with a distributed system.

Now that took several years to do, and we had command, we had telemetry processing, we had trajectory processing. Telemetry processing was first to move to a distributed system. Command was later. So about 1995, I think, we started our first flight doing telemetry processing. We still had the MOC, the mainframe. Command went through there, and trajectory was done there. Then they distributed that data off of a local area network. Why am I telling you all this? This is all background. But what kind of things did we do? So we put all of that in place to make the change process mostly software, because hardware would take longer and was more expensive, depending on the kind of hardware. We tried to put as much in software as possible so that what you changed for a Shuttle flight is pretty much all software.

Now, the thinking at the time was on Payload Operations Control Centers (POCCs). You asked a question along those lines. We put in hardware to account for what we considered to be the peak loading, so that [when] we’d have a Spacelab customer or something like that, and we said what’s the maximum that could be. We put that in place. When you have less requirements for that, they just use fewer of the hardware consoles. It was again a distributed system, so you could buy these DEC Alphas, which is what we used to begin with. When you needed them, you’d buy more. Then as they obsoleted, you wouldn’t replace them.

Now while I was there in the 2000s, DEC went out of business. Their Alpha chip was not a bad chip, it was a good machine, but they just quit manufacturing. We went to a PC [Personal Computer] class machine, an Intel type processor. We went to a Linux operating system for most of it, not all of it. The main core processors and its distribution system are IBM. The [Cisco] switches, switching networks all internal, the Ethernet switches, those are commercial. We just use them as we need them.

So what that means is that as change needs to come in, it’s pretty much all software. If a customer comes in, and he’s going to operate out of the MCC, what do you need? Well, we need three of these consoles, four of these consoles. Working through the Shuttle, if they have commands, command typically goes up to the vehicle, goes through the GPC [General-Purpose Computer], the SM (system management) computer and off to the payload. That means they have to go through the Shuttle process to define those commands. That’s all a well-defined process. It goes through the Shuttle Program. They take all those requirements, build a mass memory load that is the flight software.

Also, that process of developing that software spins off Shuttle data tapes, which is what we use to build command and telemetry datasets that we can use in the control center. As the Internet expanded and became more reliable, some of these customers said, “We don’t even want to bother to come there. Just ship us the data.” Okay, well, we’ll do that. We have interface servers and stuff like that. Ship it to them. Command is a little more controlled. If they want to send commands, they come here or from Marshall [Space Flight Center, Huntsville, Alabama]. Marshall has a payload ops control center—POIC [Payload Operations Integration Center] for Station, but this is Shuttle. When we were running Spacelab operations, Marshall was responsible for Spacelab, even though the Germans built the first one. Marshall picked it up. So they had an operations control center there. They could send commands because we had those direct interfaces. They’d send commands through here, and then they’d go up to the vehicle.

Again all this allows you to do software, and it is through a software process, some of which MOD controlled and some of which we are customers of the Shuttle Program, because Shuttle Program, today, owns and keeps their flight software development and production. Now, we house it in our buildings as a facility, but they own the process, if you understand the distinction. They pay the people that do the work. We house, we power, we have the people that maintain the functional system. But they own it. Now does that help you?

Ross-Nazzal: It does. Let me just make sure that I understand it. When you’ve got a new mission, say, STS-28, primarily the only things that would change would be software. If you had a different Orbiter than the one you used last time, depending on the payloads. Is that correct?

Knight: Yes, that’s essentially correct. That’s where we tried to go. I think we were pretty darn successful at that. The software requirements that are for that new mission come out of the Shuttle Program. We take that, and then we modify, build, and test our software appropriately. Then we also build the training loads that go to the trainers.

Ross-Nazzal: Can you talk to us about working with the various customers over the years? DoD, partners, other Centers?

Knight: Working with DoD—they actually came here. We helped train them, they sent a lot of people here. They worked for us. They were intending to have their Blue Cube [operations center at Onizuka Air Force Base, California] out there and were going to control flights out of Vandenberg [Air Force Base, California]. All that collapsed. So that was the kind of interface. It was just flight controller to engineer. After 51L, our interface with DoD was search and rescue—that was a KSC [Kennedy Space Center, Florida] interface with them. Our interface with them was for the debris avoidance and for certain use of their assets if we needed them for photography, taking pictures with some of their assets. So we worked with them on that kind of thing.

We also worked with them for range safety at the Cape [Canaveral, Florida]. We would send them our predicted launch trajectories. They would build their impact predictors, so they’d know when to do destruct if they had to. Then we worked with them a lot on the destruct issues. That was just people-to-people interfaces. Mostly it was trajectory and flight director, but in fact, there’s a little contingent of DoD people that live in the control center. Mostly I think for asset usage, and in case you have to dump a Shuttle or something like that.

It’s a very select group of people. There’s what’s called a STU [Secure Telephone Unit]-III phone that the FDOs [Flight Dynamics Officers] have that is a secure phone. So you can talk to them using secure access.

Ross-Nazzal: What goes into that debris avoidance? How does that work?

Knight: Well, the Air Force for years has [had] a bunch of radars. I think their control center is Colorado Springs, but their radars are somewhere in various places. They’re there to track ballistic missiles. They also track other debris so you can distinguish good things from bad things. These pieces that occur because of parts come apart, explode, stuff like that, well, now there’s debris all over the place. Most of it is very small. They can track down to a certain level, but those debris trajectories meander around. They eventually can have intersecting trajectories between human stuff: the Station, the Shuttle, whatever, and we prefer that not to happen. The bigger it is, the more potential impact it would have.

They track that stuff all the time, and those, because of solar activity, the atmosphere goes up, comes down, those trajectories change. Depending upon what your launch azimuth is, those can have potentially intersecting trajectories. Now, those are all statistical calculations. So you’ll have a big ovoid that says the Shuttle will be here, and this debris will be here within some probability. If those probabilities reach a certain level they call us and say, “You got a potential conjunction.” Depending upon that conjunction probability, the flight director and the FDOs will decide—and whatever else is going on in the mission—whether or not a maneuver is worthwhile. If it’s cheap to do, you got the consumables, maybe they’ll move, but it’s all a probability distribution. When you move, you’re always going to make a maneuver that’s going to reduce the potential for conjunction. That’s the debris avoidance stuff that the DoD and MOD does.

Ross-Nazzal: Does that happen on a regular basis? Are there any missions you can recall?

Knight: Oh, it’s all the time for Station, because the Station is up there all the time. Its trajectory is moving up and down. It decays. It gets lower and lower and lower over the months, and then you have to push it back up again. Now when we launch a Shuttle to the Station, you want it as low as possible because it takes less energy for the Shuttle to get there. So those plans are done over long periods of time. Then as soon as the Shuttle is gone—or sometimes if Shuttle has extra fuel, it’ll push it up a little bit. Then it can come down. Then usually one of the Russian FGBs [Functional Cargo Block] or one of their Protons or whatever—those have fuel, and they will run it up to a higher orbit. Then it decays again, but that’s Station.

Now when the Shuttle launches, they have constraints, one of which is meteor showers. You don’t launch during that period of time in the year when you have the—is it the Perseids or something like that? I think it’s November. There’s a meteor shower that comes once a year. We typically avoid launching in there if we can, but it depends on the other circumstances as well.

So that’s debris avoidance. Once the Shuttle is launched, and you know exactly what its trajectory is or what it’s projected to be, then the Air Force’ll run their conjunction analysis. Any time you make another maneuver, you run another conjunction analysis because now you’ve changed the conditions. That goes on as long as the Shuttle is in flight.

Ross-Nazzal: Do you remember any instances?

Knight: Oh, there have been conjunctions, yes. There’ve been maneuvers. I don’t remember a specific one, but you could go back and ask if you are interested in specific ones, ask the Flight Director Office. Probably they can go back. All of them that were done on a flight, that’s been recorded in the logs.

Ross-Nazzal: What about working with some of the other federal agencies or Centers?

Knight: You tend to work with Goddard [Space Flight Center, Greenbelt, Maryland] all the time, because Goddard has the network and the TDRSS [Tracking and Data Relay Satellite System] network, so we always work with them. Their network director comes down and is part of the Flight Readiness Review [FRR] process, says, “The network is ready.” Which includes the TDRSS and White Sands [Test Facility, Las Cruces, New Mexico] and MILA [Merritt Island Spaceflight Tracking and Data Network Stations] and a few other sites around that are still there and functioning. Marshall we work with all the time, because they own the ET [External Tank] and the SRBs [Solid Rocket Boosters] and the Main Engines and so those, the values that have to do with propellants and engine performance and SRB performance comes from Marshall. That’s done all the time.

And they also did a lot of payload ops. So on a flight-by-flight basis, you work with Marshall a lot. On top of that, in case we have a hurricane here, you can go to Marshall and use some of their facilities. Mostly with Shuttle, though, you go to the Cape I think, if I remember. Now things have changed, it’s been three years since I’ve been there. So it depends on which of those two programs you’re talking about.

I think the Marshall thing is mostly a Station thing for emergencies. I think we still go to the Cape if we have a hurricane here when the Shuttle is on orbit, and you’re going to enter. Shuttle can’t stay up—well, if it’s attached to Station, it’s got a long period of time. Hurricane will come and go, you hope the place doesn’t get wrecked up too bad. Once Shuttle is free, it doesn’t have enough—some of the onboard systems like IMUs [Inertial Measurement Units] degrade over time. They drift. Unless you have some independent means of tracking all that, they’ll get to the point where they can’t guarantee entry. Typically, if you don’t have that capability to do those drift tracking, which you typically don’t have in an emergency situation, we just take up a few laptops and go to the Cape.

All this is documented in an emergency Mission Control Center plan, but you have to come back pretty soon. So for Shuttle it’s the Cape. Now other Centers, if they have payloads, like Ames [Research Center, Moffett Field, California] will have a payload, then we’ll work with them on that particular payload. Other agencies of the government, Homeland Security now, FAA [Federal Aviation Administration]. If you have to land, there’s some east coast landing sites; you work with them on an off-and-on basis. Let them know that there might be a situation.

It’s typically a black zone situation, very unusual, but it’s one where you can’t make a TAL [Transatlantic Abort Landing site] because an engine has quit or something like that. Now there’s some east coast landing sites that you could come screaming in as they say, and you’re gliding. There’s no go-around, so it’s one of those where you say, “Clear the runways, clear the runways, clear the runways,” to run everybody off and you hope you make it. Or you bail out.

Let’s see. Goddard, Marshall. KSC you work with a lot for the range safety, and of course then they are responsible for the recovery. Once a vehicle has landed, they have to get it back, whether it’s Moron [Spain] or someplace like that. So you’re always working with KSC in the normal end of mission. Most of it is fairly standard stuff. Things have evolved over time. … It was intended to. Does that help?

Ross-Nazzal: Yes. One of the things that you mentioned in the chapter that I thought was interesting that I was hoping you could give some examples, you talked about payloads and resource conflict. Could you give some examples from some missions?

Knight: Well, we flew a mission called SIR [Shuttle Imaging Radar], and that mission used some DoD stuff, but it was a radar mapping mission. That kind of mission, first of all they wanted to go to a higher launch azimuth so you’d get more of the United States. The most efficient launch out of KSC is to launch due east, because when you launch due east, you get maximum advantage of the Earth’s rotation. At the Equator it’s about 1,000 miles an hour. The higher up you go, it drops off generally. I think it’s by the cosine of the angle or something like that. Then the more northerly you launch, the less you have advantage of that velocity. You lose payload capability, launch mass capability, the more you launch north.

Putting the Station up—the reason it’s at the launch azimuth and the angle that it is to the Equator is because of the Russians. Their due east launch site is much more northerly than our due east. It’s 51.7 degrees, and that’s where their launch site is. For them to get a maximum capability for their launch vehicles, they want to launch due east, but that means that you can’t have an angle of inclination to the Equator that is lower that would help us. So that’s why it’s where it is.

Well, SIR was another one, and it wanted to look at a lot more of the US and a lot more of North America. It had to launch more northerly, because it was a radar scanning mission and it was in the payload bay. You had to have the payload bay to the Earth. If you had another payload that wanted to say look at the Sun, you were out of luck. That’s a trajectory conflict. Also it’s a mass properties conflict. Those are the kind of conflicts that you have. It means you can’t mix certain types of payloads, or you can’t mix them easily.

I’ll go back to Skylab for a minute because it had similar types of conflicts. Skylab had biomedical [experiments]. It had about four major areas for science. Solar physics, which means you want to point at the Sun. That means you want to have a vehicle that when it’s not blocked by the Earth, it’s always pointing at the Sun, so it’s inertially Sun-oriented. You had a biomedical [investigator] which said, “I don’t care where I’m pointing, but I want time for the crew.” You had Earth resources, which meant you wanted to point at the Earth. That’s not an inertial thing. That means you’re constantly pointing along a vector to the Earth, which means the vehicle has to rotate all the time. That conflicts with the solar physics. It also conflicts with getting energy from the Sun, because on Skylab the solar arrays did not rotate like they do on Station. That meant that if you’re going to point to the Earth all the time, then the solar arrays don’t point to the Sun nearly as often. The batteries run down. Then the fourth thing was called corollaries, which is whatever else you can fit in.

Skylab was a constant balancing of all these priorities, as well as you [have] got to keep the batteries charged. That’s the physics of keeping the vehicle going. Since you’re up there for a longer time [on Skylab], you could finally balance all these things out. Now you get to Shuttle. Shuttle is a little less time on orbit, but when you have payloads that are like that, you have the conflicts, and you can’t put certain payloads together.

The other conflict is crew time. How much time you could have individual crewmen or crew people devoted to working your experiment. They have to sleep, they have to eat, they have to do their exercises. Then whatever eight hours or so is left over can be devoted to somebody’s experiment. How much is that? Some of those experiments, they want them to take pictures, they want them to narrate, they want them to react to given phenomena. That takes crew time. The more of those things you have, the more you have to split. Now the Spacelab missions were a lot like that. You pile a bunch of experiments in there, and then somebody has to integrate them so that everybody gets an appropriate amount of time, because it’s very expensive to launch a Shuttle, no matter how much you work on it.

You’d like to get as much out of a flight as you can. You had contingencies, so that if this fails then you can move this in here. It was a constant replanning activity going on during a flight. If something failed, you had to do in-flight maintenance. You had one thing or another. You had to adjust things. Or the ground people said, “I can’t make it.” Or they had a failure or something like that. You could try to adjust these things. There’s a constant tweak of the plan going on just to maximize return.

When you were building a mission from the beginning, then the program office—and I said in here—the program office mostly, because they were looking out way [beyond one flight]. The Shuttle Program funded some of these experiments. They were years in the making. University XYZ or commercial McDonnell Douglas or something like that says, “We want to do this kind of experiment. We think we can build the hardware, test it, and have it ready four five years down the road.” So they would put that tentatively on a flight. Then you would gather things up that would be more or less compatible with crew time and the trajectory requirements and whatever your major payloads were. Does that help?

Ross-Nazzal: That’s great. I think the example of Skylab is perfect.

Knight: In the Shuttle world it has to fit into those sets of Shuttle constraints. Generally you might have one or two driving payloads. These are the ones that force the trajectory. They needed solar, they needed lighting at this point in time, they needed this or that. That drove the trajectory. Then you had a lot of stuff that you could add into that. The Spacelab flights, the ones that Marshall had, where you had an internal Spacelab module, they typically were filled with a lot of biomedical stuff, stuff with animals, stuff with flame propagation, some chemical reactions. It didn’t matter what orbit you were in, you just wanted a weightless environment.

Ross-Nazzal: Talk to us about how the flight control team worked on trajectory planning for launch and for landing. How does that work?

Knight: The trajectory flight control team did all of that. The systems flight control team, payload ops, EVA [Extravehicular Activity], Robotics had almost nothing to do with that. Over the years, the trajectory team evolved and had a very rigorous rigid process to go through, because if you screw up, you don’t have a chance to recover for a launch phase or entry phase. It’s just too late, if you make a big mistake. Typically early on they had what they called an engineering release, and then they had a final release in the early part of the program. That would be about three or four years’ worth of effort. It wasn’t necessarily a lot of people but once you got this you iterate on it, because there’s a lot of iteration. There was the control points of the Shuttle where you had to control the temperatures. There was the load numbers during the launch phase, because it’s an asymmetric launch vehicle.

You have the winds in the year. Marshall ran a bunch of studies real early on to define what the upper atmosphere winds were. They’re seasonal winds. I don’t know if they were done on a monthly or a quarterly basis, but you have spring, summer, fall, winter environments, and you had a set of trajectory preliminary loads that were tailored to those environments. In the later part of the Shuttle Program what we have, and we have it today, is day of launch winds. You have a preliminary set of trajectory parameters, and then in order to maximize your margins you have a day of launch wind. So they release some balloons and track those balloons, and then that’ll tell you what those upper level winds are, and then you factor those into the last minute set of constants or I-loads that are put on the vehicle on the day of launch.

There were people that ran ascents, people that ran orbit [analyses] and people that ran entry [analyses]. They would get a flight and define, “I got an Orbiter,” probably don’t have necessarily the engines you’re going to fly with, and you certainly don’t have the SRB datasets yet. You work a set of preliminary trajectories. They will include aborts to RTLS [Return to Launch Site] aborts. They’ll include Transatlantic Landing site aborts. They’ll include abort once around trajectories.

They set them up, and then they do what they call a Monte Carlo analysis where they will have a bunch of variables. Then they will change the variables and make a bunch of runs and change the variables and make a bunch of runs. Those are trajectory runs that are against a set of criteria. Then what you’re looking for is what they call two or three sigma margins relative to hard lines that you do not violate: “Do not exceed this.” Those, you really probably talk to a trajectory guy if you really want to get more detail. I’m giving you the layman’s view.

There’s also other things. They’re trying to maximize performance, which is get the most out of the propellant that you have, and get the maximum amount of payload or mass that you can launch. It’s a constant iterative process to maximize performance. That’s part of the reason that it’s expensive, because you don’t do it like commercial airliners. Commercial airliners, they’re driven by a different metric. Also the FAA defines margins. You just don’t go outside those margins. An airline says, “Okay, I’m going to take off from [William P.] Hobby [Airport, Houston, Texas] and I’m going to Dallas [Texas] or something. Or let’s say further way. I’m going to Indianapolis [Indiana].” Now, the FAA says you have to be able to go to Indianapolis and then have the ability to divert to another airport within a certain circle and have enough fuel to do that and loiter for so long. That’s to protect the public [and] the passengers. So that can define a minimum fuel load.

Now then the economics of the situation will define for the airline, like Southwest, what else it wants to do, because okay, I want to go from Indianapolis to Detroit. Well, it may be better to load a little more here in Houston and load less there, because they only want to spend 15 minutes in Indianapolis. Then the economics takes over, but their structural margins and all that, those are defined by the FAA, “Do not exceed,” etc.

We optimize every single Shuttle flight. You optimize it for performance, which is max payload to orbit. You optimize it for structural margins, three sigma variance of the variables that can happen like the winds and the errors, things that can happen because of the IMUs have potential errors in there, those kind of things.

Once you’ve built the software, it’s going to do what it’s going to do. It has no errors. If you have a bug in it that’s inherent, then it’s there, but in and of itself it’s going to execute on whatever data comes in. The data that’s coming in from its rate gyros or its IMUs or whatever, that’s where errors might occur. There’s variation in those things. All that is done on a statistical basis. Those other errors and the unknowns from the outside, like winds that are different from what you thought, those introduce load errors and things like that. All that is part of this Monte Carlo analysis that’s done. Software is just going to execute and do what it’s told to do.

If you screwed up, you put a bad load in, well, yes, you’re screwed—probably. In fact, that’s how some of the launch ascent training is done, they put bad errors into the actual flight software. Otherwise they can’t get anything to go off to the side one way or another. That’s the ascent case. They have all these aborts.

The on orbit is typically [where] you’ll have rendezvous. So where is your rendezvous point? What if you had a bad burn, what if you had a failure of a jet, or an OMS [Orbital Maneuvering System] went out? You can rework trajectories for that. Then they constantly optimize to maximize fuel use, maximize margins in case something else goes wrong.

Entry, you got a capability to enter almost any time. Not quite. So every day the FDO generates potential entry points in case some systems problem causes you to have to quit right now. You have a hole in the cabin, you have a debris impact, meteoroid, or whatever. So those are done. That’s not so much the prelaunch stuff, but that’s done every day. On the prelaunch planning, then the entry is a planned entry. The program office used to have objectives, like crosswind landing objectives. Sometimes you’ll have more crosswinds at a given time of the year than others. They’ll put that factor into the equation. They also will plan entries in case you had a deployable payload you could not deploy. You have to enter with more propulsion mass than you had planned on. Those are variables that go into the entry trajectory planning.

You asked a question in here. After [the STS]-107 [accident], they decided in case we have another one of these things not [to] have all that debris that fell over Texas. They tend to try to plan the entry profile—it’s called an ascending node, which means that you come across Mexico. As you’re getting lower you’re coming across the Gulf, so the debris path now falls in the water, and then you land at KSC. That limits some of your options. You can go the other way, you can have a descending node, but that puts you across the entire US just like 107 was.

Now 107 was not a flight to the Station, because that would have put you in a higher inclination. That was just a due east launch. So that’s why it followed the path it had. Had it been a Station flight, and they came across the US, it would have been quite a bit higher. Or if it was coming in from the bottom, it’d have been lower down. So after [107], they put that factor into the equation of entries so that you can avoid population areas.

Ross-Nazzal: Do you want to talk about how the flight control team works on things like cargo operations, maneuver plans, consumables, any of those things?

Knight: Typically maneuver plans are a combination of the prelaunch trajectory work and the propulsion guys. Propulsion guys and their systems people, they track the consumables usage. You had a question in here: the preflight work, the trajectory work. There’s also other work, one of which is consumables. The consumables typically is water loads, cryogenic loads, propulsion loads. I think you said something about CO2. CO2 is something that is generated by the crew, and then lithium hydroxide is what takes it out, if you’re using the canisters. They had another thing called the regenerative CO2 removal system that we used a couple times. It adsorbs CO2 to a bed, and then you heat it and expose that bed to vacuum on a cycle, and it pushes the CO2 out. Then you put it back into the cabin, and it adsorbs CO2 again. So you had two beds working like that I think.

There’s always a tradeoff on that kind of thing. The weight of that regenerable package was typically a little more than the weight of the canisters for a typical Orbiter flight, which was typically seven days. Now it’s gone longer. Those tradeoffs were made way back in the early part of the Shuttle Program. Those canisters are consumables. You load as many as you think you need plus spares. Let’s see. The water—for drinking and waste management; the cryo, for electricity. We don’t typically load too much of that, because you generate water with the cryogenics. What other?

Propulsion. Got the forward RCS [Reaction Control] system, got the aft RCS system, the two OMS pods, and that’s a lot of propellant as it turns out. Then APU [Auxiliary Power Unit] fuel and APU water. Those sometimes were managed for mass properties considerations, and then there’s a CG [Center of Gravity] control, and you can load ballast in the aft compartment again depending upon the flight as to where that CG will vary. There’s a box, and it has to be in the box or you don’t have good control during entry. Not a launch problem typically, just mass you add or subtract.

People know, “Here’s what the flight is, here’s the duration, here’s the users of electricity,” so you generate how much cryo you need. Then the mass properties guys are saying take it off. We’d say, “Well, EECOMs [Emergency, Environmental, and Consumables Operations Manager] want as large of them as you can have.” It’s a balancing act that’s done preflight. Then tell KSC what to load at the last month or so. Then they’ll load and go. Load up when it’s on the pad.

They generate how much ET load. That’s loaded up of course day [of] launch, or the launch process. There’s also a payload safety process that MOD runs. There’s a whole set of safety criteria that is put on the payload providers. It would have to do with [something] as simple as sharp edges, anything, what are you doing that might be toxic, offgassing, shock, heat, temperature, those kind of things. They just go through that process and say what it is and evaluate what crew protections need to be in place.

There’s also some integration, especially later in the Shuttle Program when you could have all these digital cameras and laptops. Everybody’s got to have a laptop, maybe multiple laptops. All those things require power, and so you got to find places to plug them in. So you’ll end up with conflicts there. There’s not enough plugs in the wall, so to speak, or downstairs or upstairs. So you put a plan together called a plug-in plan for that. Day one this way, day two it’s this way, day three. You like to minimize the plugs and unplugs if you can. You optimize that way as well. All that is done preflight.

Ross-Nazzal: What about planning for rendezvous and docking?

Knight: The thing we rendezvous with—if we’re going to retrieve something or go to Hubble [Space Telescope] or Station, you’ve got to know where they are. Somebody tells you, the Station guys, “We will be at this place at this point in time.” That helps define the launch time. The launch windows [are set up] to minimize rendezvous time and rendezvous propellant. See, if you had plenty of energy, plenty of propellant, plenty of delta-v, a lot of these problems go away, but you don’t. That’s why you optimize.

That’s why we have a launch window of about five minutes. Five to eight minutes is your launch window, like tomorrow morning. If you don’t get launched, you could launch a little bit later than that, but it means it takes you four days to get there instead of two days or three days. You don’t want to spend that time. You don’t have enough propellant, you don’t want to use it to just burn.

If you look in the early days, we could do one-day rendezvous if you had the propellant to do it. We just don’t. At the Moon when we did the Apollo, we launched off the Moon, we rendezvoused [in] one rev. Those are considerations that go into it. Now, when you try to do that, you don’t have much margin. One-day one-rev rendezvous, everything’s got to click. If something goes wrong and you’re off, you either got to have a lot of propellant to make up the difference, or you’re going to spend a lot of time catching up. You can do it, it’s just time and optimization of flight plan.

Ross-Nazzal: What about docking?

Knight: The Apollo docking, the Skylab docking. Those were designed in, so they were always axial docking. The Russians are the same way. You’re docking along the axis that includes the center of gravity. That’s pretty much a piece of cake, [relatively speaking], or it reduces the variables. Now all you’re really concerned about is how much structural impact there is. That tells you what the impact velocity needs to be. Typically it’s low. You want it to be as low as possible, but you also want to hit strongly enough to engage the latches. It depends. Again, that’s a design issue. You can do it in different ways.

If you did, say, very strong magnetic latches, you could come up extremely slow, but the slower you go, the more variation there is, because you’re going along in space. You’re going along at five miles a second in the low Earth orbit. Well, the further you go, the more these two vehicles are varying, because their orbits are always slightly different until they contact.

The way the Russians have it, it’s along the axis of the CG. The Shuttle was never designed for this kind of work. So their CG is offset. The docking module is typically right behind—especially if you’ve got other payloads—the crew module. That means it’s offset from the CG by quite a bit, relatively speaking. Working off all the software and the maneuvers to do the actual docking took a while to do. [The Charles Stark] Draper Labs [Cambridge, Massachusetts] did the work for the digital autopilot. The actual maneuver, you come up and then you have to burn these jets in a certain order right at the last minute to clunk them together with the minimum offset loads. It was a tricky kind of a thing. It’s a result of trying to use something for what it was not really intended to do. There’s other constraints having to do with the jet plumes and the solar arrays [they] are impacting, all of which is a very complex kind of a thing.

So it was trying to make two things do stuff together that were not optimized and designed to do them. We forced the use of Shuttle, so to speak, on this thing. The Shuttle is a unique beast in that. When Shuttle goes away, whatever you design thereafter can be optimized for that. The Orion is much more like the Apollo Command Module. It’s going to be docking along its CG axis pretty much. You can adjust the jets to account for that.

Ross-Nazzal: What about working on EVA plans? How far out does that happen?

Knight: Of course they always want to know as soon as they can, because EVA is typically a choreographed activity. If you have to make any models and whatnot to put in the NBL, then you want some lead time on that, again for scheduling purposes, procuring equipment, and procuring materials. The longer you have, the more you can optimize for cost. So of course, where you are now, you know you’re going to Station. That’s the last part of Shuttle you’re doing. It’s all you’ve got left to do, and it’s been going on for years now. You know there’s going to be EVAs to install the stuff and connect it up and whatnot.

A lot of that is canned now. You know where the handholds are, but when you’re doing something new that you hadn’t done before, what you do is you go look at the payload. What am I going to do with it? Where can I install handholds to make this easiest for the crew, give the most leverage? All those things are part of it. Now the other thing is you’re always dealing with different crewmen. You’re training new people in many cases. You were in the older days. That’s all part of it, why you want to know as soon as possible.

Now there was resistance on the part of the Flight Crew [Operations Directorate] and especially George Abbey when he was running the show to name a crew. Because once you have named a crew, you’ve put things in place that you take them out of the PAO [Public Affairs Office] rotation, the PR [Public Relations] rotation. They’re now focused entirely on that flight. They are locked in, and other people know they’re not. So there’s a certain amount of things going. You’ve read the books on that. I’m not telling you anything you don’t know, but Abbey would delay as long as possible for those reasons.

You’ve excluded a bunch of people, and you’ve also focused in on people. So they had an EVA cadre. Sometimes early on, a lot of it was just paper exercises. Once you get a named crew, then you can go through the actual practicing this. “We’ve got a paper choreography. Let’s now go through it in the NBL.”

Robotics was somewhat similar, because they need to know if you’re going to take something out of the bay, or you’re going to capture something, where’s the CG. Has to do with what the arm can do and not do, what its restrictions are, what your margins are. Hubble was designed for capture and EVA. It was designed to be deployed with an arm. Early on they’d say, “Okay, put a grapple fixture here or here. Gives us our best CG capability, gives our maximum margin getting it out of the bay without banging around or anything. Capturing it. Putting it down. Getting crewmen available where the handholds [are], so you can open doors.” All that was optimized on Hubble, but you had to get started at the early design phases of Hubble. You have to define what your payload is and what you want to do with it, and then you can assign somebody to start working on it.

Ross-Nazzal: Let’s talk about training. Move from the planning to training. Talk about the flight certification that flight controllers had to participate in for the Shuttle Program.

Knight: Certification typically was not necessarily programmed. It was how does the operator operate, but you had to understand your systems. So that became Shuttle-oriented. Certification was a written evaluation that said, “This person understands their systems, they can communicate effectively, they can recognize and evaluate problems in telemetry signatures and perform in a way that gives us confidence they can do the job in a real situation.” So people over time defined problems they wanted [to see]. If you were a propulsion person, they wrote down [for example], “We want them to see an OMS failure.” They want them to see an RCS leak. They want to see a failure of this valve or a failure of that valve. So they defined a whole bunch of those. That became fodder for the training people to build scenarios.

It was fairly expensive to do training with the best trainer, which was the SMS (Shuttle Mission Simulator). When you did team training, you couldn’t put too many failures in, because it blew the sim [simulation] out of the water. You did a few, and you’d optimize those for who you were particularly trying to get certified on this particular run. There were a lot of part task trainers. There was a lot of what’s called tribal knowledge extraction or on-the-job training. So you get a new person in the systems world or the trajectory world, and they were assigned to a discipline like EECOM or the EGILs [Electrical Generation and Illumination], the power guys, or the PROP [Propulsion] guys, or GNC [Guidance, Navigation, and Controls Systems] or somebody else or Robotics, EVA. They got in the group. Then they learned by doing and learned by watching and learned by participating.

They would go in and they’d sit beside a certified flight controller during a flight, during a sim. Then they would go on their part task trainers and just work on their particular areas and learn how it looked from the crew’s perspective. What happened if you did this? What happened if you did that? They were assigned systems handbook drawings. They were assigned console handbooks procedures. It was a lot of learn by doing, learn by observing, learn by doing. Then they’d be given a little more responsibility. Write a flight rule for this. Then work with an expert person. Then they’d typically start out on orbit. There were three basic phases for Shuttle: launch, orbit, entry. Two critical ones were launch and entry, because once you were embarked on those there was no turning back. You couldn’t back out of it and you didn’t have a lot of time. So if something went wrong, you had to respond immediately or the system responded and you went from there.

On orbit you can say, “Well, okay, we’ll turn it off and think about this.” The MER [Mission Evaluation Room] was there, and the MMT [Mission Management Team] wanted to have a say. You safe the system, but you had time often then to wait and bring in more expertise. Ascent and entry you did not. Once you were there, you were there. So you’d start off typically in the MPSR [Multipurpose Support Room], which is the back room position. You’d train. You’d be assigned to a flight. Well, sometimes you were assigned a flight before you were fully certified, but you’ve had some practice runs. You’ve sat in with some people. You’ve run on another mission a sim or two or something like that.

Your supervisor says you’re okay. You’ve had evaluations by the sim people on your performance during a sim. You’ve demonstrated to your management that you have some modicum of knowledge of the flight rules and the procedures for your systems and the console procedures. So they’ll assign you to a sim. Then you go execute the sim. Then you’ll be evaluated. Then you go do another one, you go do another one. Then you’ll say, “I’m ready to be certified,” and you’ll tell the training people that. So-and-so, this is a cert [certification] run for him or her. Then they will tune that sim up to exercise these guys in a number of ways. So you might have one or two of those. Then if you get evaluated by your supervisor and your sim guy for the back room, and maybe somebody else, and they’ll write that down. They’ll certify you, and they’ll write a piece of paper, and you’re certified now for that phase and for that system.

Then you move on and you move up. Sometimes you can move from a MPSR orbit to an orbit FCR [Flight Control Room].

Ross-Nazzal: What’s a MPSR?

Knight: Multipurpose support room. It’s called the back room. In the Apollo days, it was called the SSR, System Support Room. Now it’s called the Multipurpose Support Room. There’s some more history with that, but that’s not worked out the way it was thought it might work out. The FCR is the Flight Control Room, that so-called front room. So you can go from orbit MPSR to orbit FCR. Or you might go from orbit MPSR to ascent entry MPSR. Just depends on the circumstances.

You typically start there, and then you’ll move out to the equivalent. Some people decide they don’t want to do that, or can’t do that, or they can’t take the pressure, or don’t need to, don’t want to. So they just stay orbit. That’s what they want to do.

Payload, similar kind of a thing, except they typically don’t have an ascent or entry role. FDOs, the trajectory, similar kind of a thing. Back room to the front room. They’ll do back room certification, front room certification. When you’re certified for the FCR, the front room, you also have again sim supervisor and a flight director.

Ross-Nazzal: How long does it take normally to get certified?

Knight: It varies a lot. It varies for a lot of reasons. Some of it is just personal problems. Some of it is is there enough sim time around to get them. Because ascent entry sims, for those, because of the rapidity of response capability, you can’t just have sim and then wait a month, another sim and wait a month, and then have a cert. You just lose your proficiency. For an ascent entry certification, you usually need to have at least a sim a week for two or three weeks before you have your cert sim, or maybe two sims a week. Sometimes those are hard to come by, [depending on] what flights are running and how close they are. It can take a while. A really proficient guy, just bang bang bang you hit them, you might get it done in a year and a half from the time you started into the process and maybe you spent six months or more there, but that was real rare. John [P.] Shannon may have been one of the real fast ones.

A lot of it is just due to circumstance. Rick [Richard N.] Fitts wrote up a presentation of that many years ago when Bonnie [J.] Dunbar was assigned to MOD, and we went through that with her because they said, “Why is it taking so long?” A lot of it was just circumstance, availability of slots, finding enough sims where you could do cert sims, because you were trying to use flight-specific sims to certify somebody for another flight. So it was awkward. We didn’t have a purely independent certification process. It was integrated in with flight support. There’s a template, but there’s not an absolute time. You could always force things if you wanted to, but then you had to give up something to make that happen or cause people to do more work.

Ross-Nazzal: When did flight control teams start training for a mission? Was that well after the crew had been selected?

Knight: Pretty much. The crew had to be named, and then you could start into it. Usually the template would typically start with when’s launch day. Then you backed up from that. There was a lot of pressure over the years to reduce cost. Reducing cost meant you tried to make the template shorter, because remember, I was telling you about how these costs worked out. You had time going that way and so you had mission, mission, mission, mission. [Demonstrates] Then preparation for this mission might take this long.

For this mission you started back here. Maybe the crew was named there, then flight controllers. I was running Systems Division. We tried to let people know what’s your life like. So for a couple years we’d like to name teams a couple years in advance. Didn’t mean that’s exactly how it was going to come out, because who knows? People might get hurt or die or go off to a career change or whatever. You could lose some people. Nevertheless, you had these things going on.

If you take just a particular slice in time I might have one, two, three, four flights in flow. Simulations had to be account for that. Now I think my recollection is—again I’m three years out of date—you typically start integrated sims about six months prior to launch day or whatever you knew that launch day was at that time. That could slip, as we all know. Things slip for one reason or another.

There’s constant iteration of these things. Typically a flight director said, “Who’s my prime team?” That’s his team. A lead flight director typically is an orbit guy, because that’s what I’m going to do on this flight. Then you have an ascent entry flight director. You have fewer of those. They might just do the ascent and the entry, and then you’ll have three other flight directors do the orbit stuff. If a flight was long enough, you might have four teams because we had these work limitations. So many days in a row. That was driven by incidents, like 51L was an incident. We had another incident where somebody put a bad vector up, caused the vehicle to start going out of control.

We did those kind of things. Once a flight exceeded like 12 days, they would have a fourth team. That makes it awkward scheduling, because to me once I got on a shift, like if I had the dayshift or the mid-shift or the nightshift, I liked to stay there. Because your sleep cycles and your work—if you get off of that, try to come back, I don’t know, for me it was not very good.

Ross-Nazzal: … What aspects of the flight did you typically work most frequently? Ascent and entry, or orbit, EVAs?

Knight: Me personally or people?

Ross-Nazzal: Just the flight teams in general.

Knight: Typically ascent/entry is going to get more sims, both standalone crew and flight team, because they’re critical phases. The timing is critical, and you want to get those pretty well down pat. Orbit sims, what do you pick? Well, you pick a critical phase, so if there’s a deployable you probably pick the deploy, and that’s about all you do. If there’s a Spacelab, you want to integrate Marshall in there. You pick a day that had enough stuff in it to keep them all going. You do a rendezvous and the rendezvous docking. You do an EVA or two or three.

You’d involve the NBL sometimes. For the trajectory guys, when you’re doing an EVA, what do they care? They’re just boring holes in the sky. They won’t have a lot of participation, or they’ll do emergency deorbit kind of playing around with, because they’ve got separate computers and they can go run those kind of things.

Booster won’t participate in any of those. Robotics may or may not. Depends on whether they have anything going on that EVA. Usually the systems guys are all going to be there mostly thumb-twiddling. Payload maybe, maybe not. Flight activities, yes. So you have those focused. They were doing something. They would do FDO booster sims where only FDO and Booster was there for launches. Those maybe you’d have a crew, maybe not.

So again, over the years we modified things to try to optimize training and minimize the amount of standing around that you had to do. It’s constantly going on.

Ross-Nazzal: Were there any simulations done with Launch Control?

Knight: With the Cape? I don’t have a lot of recollection of that. Apollo used to have a little more. There was a trainer at the Cape; the crew would go down to the Cape, and then we’d have some integrated sims, but generally it wasn’t with Launch Control. I think they do some paper sims, and they do a lot of talking. But it’s just too expensive. KSC has their own training capability. Early on I think they didn’t have much of that. They said, “Hey, we do enough work just with the vehicles itself. That’s all we need to do.”

Over time they did institute some capability. In fact, it led to a couple problems. If you’re not careful what you’re doing, and it has to do with how you set things up. They have a thing called Shuttle Data Center. That’s where all their data is established. They’ll ship out their downloads that go to their computers in the Launch Control Center. They also do some sim stuff from there. They had four Launch Control Centers, and they have certain places where you can send commands out and it’s supposed to go over to the Shuttle Data Center, but it can also go to real stuff. If somebody is not paying attention to that, you can think you’re sending stuff here, but it’s going there. They had an incident down there one time. They were going to do a sim, then it got postponed, they were doing something else, shift change happened, and they came back on. They started to do the sim, but they hadn’t moved the command path. So these guys were doing the sim and they were sending out commands, and there was somebody walking over in the VAB [Vehicle Assembly Building] and they heard this click click click click click around one of the Solid [Rocket Boosters].

Ross-Nazzal: Yikes.

Knight: Well, that was ordnance. Fortunately, it was unhooked. “But what’s going on here?” They went back and traced it back, and they had not made the switch. There’s manual interventions that you do for convenience purposes to give you flexibility. If you’re not really careful with your procedures, and you do shift changes, and you’re not communicating, you can end up with a real bad situation when you have real stuff down there. We don’t have that so much here.

Our system is connected. The sim guys can go in and log into the flight side. In fact, they use that for simulations sometimes where they can modify our calibration curves and force things to look like—they had cases where they have logged into the real flight thinking they were doing a sim, because we can do sims and flight simultaneously. I think this was probably on Station, but somebody went in and modified a cal situation on the Station with the real [time operations]. Fortunately a flight controller says, “Something’s funny here.” He knew something was wrong. They tracked that back down, too.

With a real flexible system like that, you have to have well-trained people. So we tried to put in place some things that says, “You’re in the wrong place,” by color, something like that. We participate in countdown demonstration tests, sometimes do, sometimes don’t. That’s when the crew is on the vehicle. We’ll go through a countdown demo, send commands and do some [monitoring].

Ross-Nazzal: Let’s talk about the flying portion. How does MOD determine that it’s ready to go for flight?

Knight: We have a Flight Readiness Review about a month before flight. That’s our internal MOD Flight Readiness Review, and says either everything is already ready or there’s still a few things [yet to do]. Like remember the day of launch I-loads? That doesn’t happen until later in the game. So those don’t get put in. “We got these processes in place, and we got this work yet to do, and it’s scheduled,” and [etc]. Goddard guy comes down, “We’re ready to fly. TDRSS is going to be ready,” [etc]. We say, “We’re all ready, this work left to do.” That’s our readiness statement. “Flight controllers are certified or will be certified by this date.”

The MOD flight directors take that [to the] FRR down at the Cape, go down there and say, “Okay, this has been done, this has been done, this is left to do, we’re ready to go.” Everybody comes forward and says, “All the things that we’re responsible for—the flight data file is ready, the ground procedures are ready, the software is ready, it’s locked up,” whatever they’re responsible for they say is ready right now or will be ready on launch day or a week before launch day.

Ross-Nazzal: Tell us about the launch phase at the Mission Control Center in those eight and a half minutes as the crew goes from the pad into Earth orbit.

Knight: Of course KSC is responsible until SRB ignition. So we’re monitoring and following, and flight director is talking to the launch director or is available. He’s polled and says, “Is MCC ready?” They have hold points. They have a something like—is it 20 minutes? I forget. Something like a 20-minute hold point. Then there’s another one at five minutes before they started the APUs. Once you’ve started the APUs, you’re using that fuel. Once you get down to that point, if you have to abort—you’ve got a window because the APU fuel only lasts so long, because it’s got to go through orbit, and it’s got to be there for entry. So you have a short thing there. You better be ready to go.

I think when they come out of that 20-minute hold, the launch director is going around. “Is everybody ready?” He calls every position including MCC. Then the flight director polls his people. “Is everybody ready? Yes, yes, yes.” Then they say, “Go.” They come out of that 20-minute hold. Then the APUs get started at five minutes. So they click click click [through their processes] and there’s a whole bunch of other stuff that’s going on at the Cape. I’m not familiar with that, but they’re topping off the ET and doing whatever they do. The Orbiter goes on internal power before APUs start. It goes on internal cooling just after. [Actually], I’m a little fuzzy on whether it’s before or after APUs start. So you have this rising tension, I’ll put it that way.

Ross-Nazzal: Do you want to take a break for a second?

Knight: Well, I’m trying to remember here. Let’s see. The IMUs are freed up, and onboard GPCs get control, and there’s a launch sequencer. It’s a GPC thing. It just goes down and counts. It’s five minutes or so, and they have this other potential place to stop, and if no then the crew starts the APUs. The vent doors shut. It’s four and a half seconds or something like that. The Main Engines start. It’s all automatic. I think they come up to speed, and they have to pass a bunch of criteria internal to the Main Engine controllers.

It passes all these automated criteria, and then the Solids ignite. Once the Solids ignite it’s moving. At that point, control is shifted to Houston in terms of abort calls and whatnot, but everybody’s still monitoring and watching. So it’s lifted off. Goes through a roll pretty much right off the pad.

You asked about that. I’m not sure. Originally the way the US did it, it aligned the launch pads in a certain way. For whatever reason that’s lost to me, but I think having the launch pads aligned in a certain geographical thing has to do with—I’m guessing here—gravity vectors and alignments of IMUs. Because the way the axes of the IMUs are aligned they’re called [x, y, and z]. [One of them is pointing] north, one of them is pointing west, and one of them is pointing up. That allows you to calibrate things.

Of course the pads were originally all built for Apollo. It was a symmetrical launch vehicle, going to launch due east. The Shuttle comes up here, and it’s an ungainly thing, and it can launch at multiple azimuths. When it comes off the pad it just goes up. Originally, I’m not sure we had a roll in it. It just went up, tilted, and went on into orbit. Much later in the Shuttle Program, they wanted to come off with the Orbiter on top, probably for lighting purposes. Because when you get up there, if you’re launching in the morning, and you want to launch in the morning at the Cape because the weather is better or less likely to have thunderstorms or whatnot, so when you come off the Sun is nice for photography. Also, the ET falls away down. If you come off on the bottom, you’ve got to now maneuver to do your burn. I think it was done to ease or optimize some of the later on activities.

So you come up. They watch you do the roll. You’re just watching. The [ground trajectory] computer is taking in the velocities, and it’s taking in the Main Engine performance, and it’s got this thing called abort region determinator (ARD), which is a bunch of software that takes current velocities and current engine performance as best it knows it, and it’s predicting what if the engines fail here, where is it going to land. So it’s constantly, as this thing goes up, plotting potential aborts and telling you what kind of aborts you can do. That’s a big FDO thing. Most everybody else is watching. Of course, Booster is watching his engines. How are they performing? Solids, you’re watching them, but there’s not much you can do about the Solids. They’re going to do what they’re going to do. You’re sitting there watching. FDO is watching all that trajectory and his abort region determinator. Generally, if you have a Main Engine failure in the first four minutes or thereabouts, 3:58, four minutes, it’s a Return to Launch Site, but it’s velocity-driven.

Coming off about a minute up, thereabouts, the engines throttle down. They throttle down because of these structural limitations that I mentioned to you before. Even though you’ve got nearly 6 million pounds of thrust on these two Solids combined, and you’ve got 1 million pounds of thrust on the Main Engines, they’ll throttle down the Main Engines from 100% down to 60% or something. I guess this is one of the variables on a given flight. It throttles down for a short period of time till they get through that max dynamic pressure, because there’s a limitation of like 800 pounds per square foot or something like that. They wanted to maximize the margin. So they throttle down, [and] then [they] throttle back up again.

Now, if one of them doesn’t throttle up, and it just keeps on burning at 40%, well, you can still make it, but you’re probably going to be a little short or you have to burn a little longer. There is consideration for that. So you come up. Now then your big criteria is your two minutes or thereabouts where the Solids run out. They start slinging slag and whatnot, and the pressure drops off. They hopefully will come down at about the same—because if they came down at significantly differential thrusts, it would start to tilt, and it may be more than the gimbals can take care of, but they don’t.

I’ll divert. They make Solids in pairs. These pairs need to be always kept together. They are segmented. Morton Thiokol will mix up a batch of propellant. Half of it is for this segment, and half of it goes in this segment: on the right solid, on the left solid. Then the next segment, they mix up another batch. Half of it goes in this segment, half of it goes in this segment. You have a matched pair. Hopefully all the burn time will be the same, and it’ll be very close to the same thrust.

The Solids go off. Everybody says, “Yay!” Now you’re on your three Mains. They just keep on burning. Depending on the flight, there are sometimes during the real late parts of the ascent, I think they’ll burn some OMS propellant, which helps reach trajectory a little bit. It varies. Again that’s another optimization activity, but you just keep on running up. Just maybe 30 seconds or thereabouts before scheduled MECO [Main Engine Cutoff], they start to throttle down, because they don’t want to exceed three or 3.3 Gs or something like that. If you keep the engines at full thrust, because now you’re getting lighter and lighter and lighter, you would exceed the design G levels.

So they throttle down. Then when you reach the velocity cutoff, the Engines shut off. Then the ground—they’re watching everything because there’s other things that could go wrong. An APU failure or a leak in the cabin or some fuel cell or something like that. They have defined procedures for each one of those. They’re watching for that kind of stuff. You reach MECO. They do a couple things on; closing off the Main Engine valves. I think they may move the engine bells in a certain position. Then they go through APU shutdown. Now you’re on orbit, more or less. If there’s any trim that needs to be done, FDO says, “Okay, trim, burn two tenths foot per second,” or something like that. Then they go through and [give a] go for orbit ops. Then [the crew]’ll go through and start doing things like take their helmets off. Then they go and open the payload bay doors. Then you’re [set up] for on-orbit ops. Then you can take off your suits. You go through a whole bunch of other crew things [in] preparation for orbit ops.

Ross-Nazzal: Tell us about communications with the flight crew and how that evolved over the years.

Knight: It all really started back in Mercury. I wasn’t here for Mercury. Then we went to Gemini and Apollo. I guess probably early on, maybe it was flight director that talked to the guy, but you didn’t want to have too many people talking to somebody, because they’d step on each other. You could miscommunicate. Eventually we got to the point where in Gemini and Apollo, you liked to have preferably a flown crewman, but if you didn’t have one, somebody that trained with the flight crew to be the guy that communicated with them.

We used to send these guys out to remote sites. So you had to have several. Well, let’s see. It wasn’t always a crewman at the remote sites. Once it became consolidated in the MCC, typically it was a crewman. It was a couple of reasons. One, they were familiar with the training. They were familiar with the cockpit. They had discussed with the actual flight crew things that were going on, in case they were the ones that flew. They had a real close relationship and familiarity with what the cockpit looked like and what the impact to a crewman was of asking him to do one thing or another. They could give a best communication.

Now within the control team, the control team would say, “Flight, we need the crew to do this or that. Could you ask them to do this or that?” Then the CapCom [Capsule Communicator] was there, and he was listening. Then if the flight director wanted to slightly modify that, he’d hail CapCom. “Okay. Go ask them to do this or do that.”

Early on it was minimized, because you only had short site passes. You might have a three-minute pass. You might have a maximum of a ten-minute pass. Everything had to be pretty concise. The CapCom would be the primary communicator. Now when the guys are talking back down, they’re talking to the whole world, but the guy they expect to answer is the CapCom.

That has stayed with us for a very long time. It’s changing a little bit in Station, because the crews are just tired of being there all the time. They don’t want to be there 24 hours a day. “We haven’t got enough crew,” and that kind of thing. So we’ve got some other people that do that, but the Russians, for example, [I’ve heard] any position can talk to their crew. I don’t know how much that’s true or not, but that’s what I’ve been told. We have not done it that way. We’re a little bit more control freakish. It also minimizes the chance of getting stuff really garbled. A CapCom will garble things every once in a while, but there’s people that are listening say, “Oh, no, this, say this.”

When the guys are talking down everybody’s listening. The expectation is that the responsible positions will hear a crew person say something. They say, “Oh, Flight, ask them that.” Or “No, that’s wrong.” Or “No, they got that wrong.” Or “Do this.” Or “Do that.”

Ross-Nazzal: Tell us about the Mission Control and how it monitors the vehicle during flight.

Knight: Well, telemetry comes down through TDRSS to the White Sands Ground Station [Las Cruces, New Mexico] into the MCC. Calibrated, put up on displays that the people built. They are always monitoring. There’s a human intervention. Sometimes they will have built special computations that will calculate, sum up total quantities of this or do a rate calculation, so many pounds per minute or hour or something like that. They’ll have limits on those so that they get alerted. They have a lot of tools now that we didn’t have early in the game that monitor for events or combinations of events and will give you messages. That part of the job has got a lot easier now since we’ve got some of those tools and we learned how to use them.

Also it can have a detrimental effect in the sense that if you come to count on them too much, you forgot what’s there, and you’ve lost sense of your own system. One guy told me some years ago, he says during sims, he turns off some of these tools every once in a while to force himself to pay attention and to learn what his scan patterns are. It’s like passwords in your computer, in the sense of if you keep your email online you can tell a computer, “Remember my password,” and it does, as long as you’re on that computer. If your computer dies and you haven’t used your passwords in months and months and months and it asks you, “What’s your password?” if you didn’t write it down you forgot what it was. Personally I don’t do that. I say, “Do not remember this password,” so I’m forced to put it in every time, which helps keep my memory.

These tools have good effects and can have bad effects depending on the particular operator, but it’s monitored constantly. Since you have TDRSS, you’ve got pretty much constant communication. When we’re at lunar distances, you had constant communications, because there was one of the three deep space sites was always in view once you get far enough away. When you’re working just with ground sites, like real early Shuttle was before TDRSS was, you’ve got sporadic [coverage]. You have a three-minute pass here, an eight-minute pass here. Then you may have an hour with no passes at all. It varied depending upon where you were.

Ross-Nazzal: Can you talk about some of the support the MCC provided in terms of satellite deployment or retrieval, EVA, things like that?

Knight: The crew is very limited in they have no sense of trajectory. You can keep a world map and say about where you are, but you don’t know precisely where you are. If a satellite needs to be deployed at exactly over this point rather than this time, the ground tracks all of that. If you want to delay it, anything goes wrong, you want to delay it, then the ground generally has to be involved in all that. The ground manages the com [communication]. The crew has no idea whether TDRSS is working or not unless they’ve got communications. If west TDRSS is good and east TDRSS has gone bad, the crew has no way of knowing that until they get there. The ground knows. All of that kind of stuff is what the ground does. The ground helps crew keep track of all the consumables. Crew has too many other things they need to worry about. So this business people talk about autonomy depends on how you define it, but especially with payloads, they’re interacting with the ground people, unless they have something that you just turn on in the mission, go back and turn it off.

Ross-Nazzal: Tell us about reentry in the Mission Control Center. How does that work?

Knight: The entry, they’re always planning for emergency entries. You prefer to land at KSC, so there’s weather considerations. You have a couple, two or three opportunities. The weather will be different on each one of them. Lighting will be slightly different. Your entry trajectory is mostly onboard-controlled. You could have a situation where first entry the crew makes a left-hand turn, whereas the last one it could be a right-hand turn, so it’s a different visual thing. (You need to take that with a grain of salt. I think that’s true, but I’m not absolutely sure.)

They’re looking at the weather, they’re looking at the various opportunities. Because if the weather is bad, can I wave off? You have to make that decision before the deorbit burn. You’d like to make that decision before you close the payload bay doors, because once you’ve gone through the payload bay door closure, you’re now on internal water boiling to cool the thing rather than using the radiators. Then backing out of it takes longer.

There’s a lot of decision making, especially in regards to weather and consumables planning, because you want to have as much water as possible. It’s an interactive kind of thing. Like this last one, you waved off a couple times. That’s the typical thing, is try to get your wave-off decisions done before payload bay door close, which means you delay payload bay door closing as long as you can. Then you can wave off again, if you have to, before the deorbit burn. But after you’ve done the deorbit burn, you’re in, and it’s all pretty much all automatic after that. You’ve done the deorbit burn. You’re pointing in the wrong direction. You pitch over, now so you’re headed nose first. Your vehicle will get the right angle of attack. Then you’ll hit entry interface about 30 minutes later.

It’s all trajectory. The deorbit burn is about one hour from landing. Entry interface is about 30 minutes from landing. That was always my observation. Just before the deorbit burn you start one APU, two to three minutes before the deorbit burn. Let it keep burning. Just before entry interface, about five minutes, you start the other two APUs, assuming they’re good. After that you’re pretty well set.

The crew doesn’t really do anything. John [W.] Young did. He flew the needles, because he either didn’t trust them or whatever, but they’re all auto. So the vehicle does its S-turn and dadada until you get down about 20,000 feet or thereabouts, just before you come around the heading alignment circle. At that point, they switch to crew sort of controlled. Crew is making stick inputs. You’re still flying the needles, but they always claim they want to get a feel for the vehicle. Because if you have to take over late and you don’t have a feel for the vehicle, it’s problematic. You’re more likely to make errors.

So they take over about that [time], and then they fly it around the circle. It’ll fly auto, but that’s what they typically do. In fact, we never certified autoland, but it probably would. What you can’t predict is winds. That’s why we typically fly an STA [Shuttle Training Aircraft] up there just before the crew enters. [The STA pilots] say, “Upper level winds are this.” You tell that [to the] crew. When you come around the circle you can either go a little wide if the winds are pushing you this way, or you can go a little tight if the winds are pushing you that way. [Demonstrates] Then you come down. What you’re watching very closely is you’re watching your altitude rate of descent and your velocity. You want to maintain your energy margins until the last minute, because you have no engines. If you come in short, you’re screwed. If you come in hot, you’ve got brakes. You can just open your speed brake as wide as possible. You’ve got the drag chute. You prefer to come in hot, but on that landing site at KSC you’re in a swamp if you come in short. It’s going to wreck everything.

He’s flying it, and he’s flying the needles. It’s got a head-up display. It’s telling you too high or too low. Just fly the needles. You’re looking out the window. So if the needles are taking you to the wrong place, you can adjust for it. I don’t think they ever have, but they could. You come down, and then you’ve got checkpoints, and you got a place that says, “Lower the gear.”

When you lower the gear, you put drag out there. You typically wait [as long as practical]. You drop the gear. Then once you’re coming down at that high angle of attack, it’s drag anyway. You just set it down. Then you set the nose gear down, deploy the chute, and just before you stop rolling you blow the chute off so it falls off on the ground and doesn’t mess up the Main [Engines] any more than it might. That’s it.

Ross-Nazzal: Following the end of the mission, you share lessons learned. How do you implement those for the next mission?

Knight: Anything that’s real obvious you can do. If it’s a flight rule change or procedure change, something like that, that’s typically not a problem, if it’s applicable to the next mission. It might not be applicable to the next mission. If it’s something you learned, say, dealing with Hubble, it’s probably not going to affect Space Station much at all, but if it’s something like cuts on the gloves of the EVA crewmen, now that may or may not have shown up. [It] depends on how fast somebody is inspected and says, “Hey, there’s a cut here,” but that’s maybe a sharp edge thing. It’s typically a procedural thing, because the next mission might be a month away. So you’ve set a lot of things in stone, but you can change rules and you can modify procedures.

If it’s something that’s a flight software problem, wow, you just barely got away with this, you might have to delay, you might have to patch or something. That’s a different story. The crew typically will write up a report. They’ll have squawks, and they’ll have three or four things they think, “By God, you really need to change this.” Those are documented and shipped over, and MOD will respond, ”Yes we will” or “We won’t.” May or may not be the next mission. May be the next mission on that vehicle, which could be three missions down the road, but if it’s something that really needs to be done, it’ll be done. It’s effective on that next mission.

Ross-Nazzal: Does MOD do the same thing that the crews do? Do they come up with a lessons learned package?

Knight: Oh sure. Typically each discipline, like Systems Division will go have their postflight review of systems issues: what needs to be changed, what did we do, what could we do better, is there something that needs to be changed in the MCC, how long is it going to take to put in a statement of requirements for that. Trajectory does the same thing. Trajectory have a very formal, they call it a postmission reconstruction where they’ll go back and review the whole mission and codify or write down altitudes, attitudes, those kind of trajectory-oriented things for later reference in case somebody later on says, “What altitude were we at? How close—wow, there was a near conjunction there.”

You have to have that postflight reconstruction to know exactly where it was. Whether where preflight it was supposed to be, because the burns didn’t happen right on time or there was more drag or whatever. There’s any number of reasons that they do that. Payload people, but again, if that payload is not on this next flight—maybe it’s never going to show up again. Not much to worry about there. Everybody looks at it. Of course, they’re doing some of it in real time too. Then program office has one, too, with their MER. Then anomalies, risk assessments, and anomaly reviews go on after the flight.

Ross-Nazzal: I think you have answered all of my questions, but I wanted to ask Rebecca.

Wright: Oh, boy, that’s a lot of good information.

Ross-Nazzal: You think there’s anything we haven’t talked about?

Knight: Well, let’s see. Did you go down through these? DoD, flight control trajectory, flight rules. Determining specific flight rules for a new mission. There’s a whole documentation tree on the flight rules. There’s a generic flight rules book. There’s some other flight-specific books, because the rationale is in the books. Typically generic rules are just what they do. They’re generic. They don’t change that much from flight to flight. Flight-specific rules are payload-specific. They will be unique to that flight. They may apply to later flights as well, but they might be unique to that flight, because there’s something unique on that flight. They’ll probably be used for the basis for the next flight, like EVA on Station.

So those are reviewed. There’s a thing called the Flight Rules Control Board. That’s sanctioned by the Shuttle Program Office. MOD runs it. Then prior to a flight, we come up to the program office and say, “Okay, these are the flight rules that we have changed or modified for this flight.” We brief them on that. They say, “Okay. “ That authorizes them, so to speak. That’s how that’s done. It goes on all the time. Probably Flight Rules Control Board meets every month or as necessary.

Certification, training evolved over the years. It’s become more formal over the years, I’ll put it that way. In terms of what did we write down that we needed to give the sim guys to do, it used to be they just listened at flight rules mission meetings, flight techniques meetings and decided what they needed to do.

Fly. Launch phase. Launch windows. How are launch windows determined? It’s just mission requirements. Like the launch window for 107 was two or three hours, because it didn’t have to rendezvous with anybody. It just needed to get there. There are restraints on how long the crew can lie on their backs. Once they get in there, there’s a clock that starts. They’re closed out. Then it’s about maybe two or three hours. Then they either launch or get out. Even though trajectorywise, it doesn’t matter.

Then the launch windows, when you have to rendezvous, is very precise, if you’re going to try to do it in a relatively efficient period of time. Ascent period. Communication. Did I get enough on that one? MCC support for EVA? We have specialists. EVA is a specialist position. So they’re only there if there’s an EVA. Robotics, same way. Booster is only there for launch. Sometimes they’ll come in for entry if there’s something that they’re looking for.

Resources were monitored. Orbital debris we talked about. Entry data we talked about. How did [the] Columbia accident change reentry landing trajectories? As far as I know, that was adjusted to minimize the debris fallout in case there was another one of these incidents over land. It was population protection. It also may or may not have affected some of the launch aborts as well. The guys ran through a certain amount of—I don’t want to say it’s hocus-pocus, but you can’t totally predict where the debris is going to be. It depends on how the vehicle would break up as to where that debris is going to fall. Once it falls apart, typically they say once you start hitting atmospheric restrictions, instead of going like this it comes [straight down]. [Demonstrates]

Somebody, I remember in the Columbia investigation, some guy said most of these things, once you get at about 50,000 feet, it’s just falling straight down at that point. If there was an explosion, things are going to go all over. Some of them will be slowed down, some of them will go forwards, speedier, some of them will go off to the side. So they’re going to keep going in that direction until they start running into atmospheric drag. Then after that, then they start to really slow down and fall off if they don’t burn up. That describes the debris field. You can only do that within so much margin of error.

Okay. So I guess we did.

Ross-Nazzal: I think so, yes. Yes. I went through your chapter and things that I had questions about. Just wanted to clarify with you.

Knight: Well, then I probably exhausted. Let’s see.

Ross-Nazzal: I saw you came in with some notes. Did you want to refer to those?

Knight: I said mission ops. Planning procedures. Program office was a big part of that. The process evolved over time. There was a thing, an official release called an FIDP, Flight Integrated Data Pack, that the program office released. It’s mostly trajectory-oriented, but it said, “This is what the flight is about. This is the mission content. The mission objectives.” Those kinds of things. So that became a checkpoint, especially for USA [United Space Alliance] to do their trajectory work. We had a crew procedures management plan that defined how flight procedures were managed. There was a flight design process trajectory. EVA, the NBL was used. Robotics training. Crew alone. Team training we talked about.

ISO [International Organization for Standardization] 9000 system procedures. When Abbey took over, we got into this period of time when ISO 9000 was the greatest thing since sliced bread. That was put on the Center, and then MOD is part of that, so we documented a number of things. That was probably a good thing in some sense. We have work instructions for most of these processes. Flight design in particular has an—I don’t know, 25-volume set of procedures and processes.

Flight procedures. There’s a thing called a flight ops review where we had the preliminary set of procedures were sent out to all the players: payload people, customers and whatnot. We had a big review. They got to review the procedures, and we had a big thing called a flight ops review, and they got to comment on all the procedures. Then we took all those comments and updated procedures. That was part of that process.

Ross-Nazzal: When did that occur?

Knight: Gosh, I don’t know, a couple months, two, three months before. There’s a whole template of this stuff. Let’s see. The MCC ground facilities. Cargo payload unique formats. Customer service provisions. You had asked, I think, about POCCs. Building 30 South laid out all of that thing and put POCCs in place and the customer support room. It evolved. Then after [the] Columbia accident, we added a big whole new MER. MER had been in different places at different times. We built a whole new one for them over in the 30M section as it turns out.

The interesting thing is Building 30 South was built as a Space Station Control Center. Space Station control is now in Building 30M. Shuttle is in the 30 South. The latest Space Station Control Center is the old FCR-2, which is where we flew Shuttle from originally, and Apollo. Kind of interesting.

If you want real details about these things, now, Earl [W.] Thompson was big in planning. He’s retired now. He ran the ops early in the Shuttle Program. The people that are currently over there in place that might help you, Pete [Peter J.] Beauregard on training. Mike [Michael G.] Hess is running the EVA and Robotics, and his deputy Sue [Susan B.] Rainwater. Dan Lindner was big on [Robotics in] the early days. He’s running the MCC now, but he used to run Robotics. He’s the division chief. Sue Rainwater is deputy to Mike Hess. In trajectory world, Rick [Richard T. Gavin]. He’s the deputy chief of trajectory, of DM. The chief of DM used to be in training and is brand-new, relatively. So he wouldn’t have any history on trajectory, but his deputy would. Rick is deputy DM, deputy director, deputy division chief of DM. If you want a lot more detail or something fleshed out. What I’ve given you is my observations.

I was always in systems. I can speak pretty authoritatively for that. Then the later parts of the MCC development, and the earlier parts, because I had a role in that. My knowledge of trajectory is observation of years of flight techniques and watching the guys operating the control center and occasionally talking to people and just general interest. Operations, the payload officers is more observation and then the flight activities officers. They take—what does the crew do or what’s their timeline? It’s observation.

Ross-Nazzal: Well, I think based on what Helen told me she’d like to see, I think just a general overview is sufficient. So this is very helpful.

Knight: Good luck.

[End of interview]

Return to JSC Oral History Website