1

Humphrey “Hoppy” Price

April 20, 2022

Erik M. Conway,

Interviewer

Q: This is Erik Conway. I’m talking to “Hoppy” Price. First, Hoppy, tell me your real name 

again just so it’s on the recording.

Price: It’s Humphrey Price.

Q: Give me briefly your background here at JPL.

Price: I came to work at JPL on April Fool’s Day 1978, and I worked doing spacecraft

configurations in Section 352 for a number of years, and my last configuration job was Cassini. I 

was the configuration engineer for Cassini, so I did the top-level blueprints and figured out 

where all the science instruments went. Then I went into systems engineering, worked on a 

number of different projects, like Pluto Express and Prometheus JIMO and the Asteroid Redirect 

Mission, and did some work supporting Constellation and humans-to-Mars architectures. Along 

the way, I was asked to be the project system engineer for GRAIL. That was a great project, and 

I was on from basically the beginning to the end. I was in on missions operations also. I was 

there on console when we crashed Ebb and Flow into a mountain near the north pole of the 

Moon.
2

Q: You must have gone on to GRAIL shortly after JIMO folded. Is that about right?

Price: I think that’s right.

Q: Because I think I initially interviewed you about JIMO long ago.

Price: Yeah, I remember that. That was a fun project to work on. So many fun projects here at 

JPL.

Q: Yeah, it’s too bad they didn’t go anywhere, but I wasn’t very surprised. The cost would have 

just been astronomical.

Price: Oh, yeah. It kept getting more and more expensive, definitely.

Q: So, you went into GRAIL as the project systems engineer, right?

Price: Right.

Q: So tell me, first off, what is the job? What is the purview of a project systems engineer at 

JPL?

Price: The project system engineer oversees all of the engineering and was also a dual role as 

engineering technical authority, which means that I had a separate charge number, which was an 
3

independent charge number. Actually, all of my work was charged not to the project, but to the 

chief engineer’s office, so that way I was unbeholden to anybody for my charge number and I 

was free to be an independent analyzer of system engineering and report anything I thought 

would be amiss. That really never happened, but I did report regularly to the chief engineer’s 

office about how I thought the project was going.

Other aspects of that were overseeing the launch system engineering, the project software 

engineer, verification and validation, the requirements, working with NASA headquarters, a 

typical PSE job. I also worked with Duncan MacPherson, who was the chief engineer. So 

sometimes a PSE is also the system architect or mission architect. Duncan filled that role, and 

that’s mainly what Duncan concentrated on. Basically, I did all the stuff that Duncan really did 

not want to do. [laughs] So that was part of my job.

It ended up part of my job was really translating what Duncan was doing to the rest of the 

project. Duncan, he’s passed away, but he was such a brilliant person, and he would kind of like 

be talking over people’s heads. People wouldn’t get it. So, I think probably my most important 

function was translating Duncan to the project manager and the rest of the engineering team, and 

getting them on the same wavelength as Duncan. Duncan, to his credit, really did so much to our 

architecture to make it function scientifically and do what it needed to do to meet the science 

requirement. He was just brilliant.

Q: Give me an example in terms of architecture. I mean, first off, casual users of this transcript 

probably won’t know what a systems architect does, but give it in GRAIL terms, please.
4

Price: You had to make this precise measurement of the distance between the two spacecraft, and 

to do that, you had to understand the thermal distortions, you had to understand how the 

propellant moved in the vehicle, and so Duncan made a number of changes to the spacecraft to 

make sure that we would be able to do that measurement and have plenty of margin. So, there 

were structural, thermal, and propellant changes that he recommended, and I don’t think I can 

remember all of them. I’d have to look back over my notes. Then, he was also involved with the 

analysis.

The person really in charge of doing the gravity calculations was Mike Watkins, and we 

used this old program called ODP, the Orbit Determination Program, and there was a version of 

that program which was used for measuring the gravity field, and it was an amazing program. 

It’s Fortran, it’s known good code, and it’s thousands and thousands of lines of code, and JPL’s 

used that for decades. Mike Watkins oversaw how that worked and tested it and validated it. 

Duncan also worked with Mike closely and made sure the spacecraft would function to provide 

all of the inputs that that Orbit Determination Program needed to calculate the gravity field.

My contributions were more along spacecraft functionality, which Duncan wasn’t too 

involved in, but the proposal had a spacecraft that was based on a Class D military satellite, and 

it didn’t have high reliability components. So, we were stuck with two single-string spacecraft. 

Both of them had to work in order for the mission to be successful, so each one was kind of like 

a half-string spacecraft, and really nothing could fail.

I led an assessment with a fault tree to try to figure out the reliability of this double 

single-string system, and we also worked with the Aerospace Corporation to get an independent 

assessment of that. We tried to make decisions on what was the best use of what little we had in

mass resources and money resources to try to fix the problem, because I think as was in the 
5

proposal, the two single-string spacecraft were at risk of not performing, and so we looked at 

making certain things dual-string. What we ended up deciding is, no, the best way to fix this was 

to take the weakest-reliability components and replace them with high-reliability components, 

but not make them dual-string because we couldn’t afford the mass or the cost of that, and the 

complexity, because the dual-string spacecraft is more complicated to implement the software on 

the fault protection than for a single-string spacecraft.

It ended up well. Both spacecraft worked well. There were a few dual-string things. 

There were some heater circuits that were dual-string. There were a few other components that 

were dual-string, and they served us well. We actually did need to use some second strings along 

the way, and, luckily, we had them in the right place.

Q: So, part of the strategy was essentially upgrading components for reliability purposes.

Price: Right, right. So, for instance, the inertial measurement unit, they had—gosh, what’s the 

name of that? I can’t remember the name of this military IMU that has been used in a number of 

low-cost projects, but we didn’t think it was going to be reliable enough for this mission, so we 

replaced it with the NASA standard for interplanetary missions, the MIMU, which we use on all 

of our different orbiters and landers, and that worked out well.

We also replaced the star tracker, the reaction wheels, mainly attitude control 

components. We replaced them with the kind of high-reliability components we typically use for 

interplanetary spacecraft.

Q: So, none of it had to be developed anew. It was all relatively standard things that you could—
6

Price: Right. And we also changed out the computer. They initially had selected a flight 

computer that we didn’t think was reliable enough, and so we worked with Lockheed, and 

basically they used the Lockheed standard computer that they use for their high-reliability 

spacecraft. Almost all of those things were single-string.

Q: You couldn’t afford the mass or time or software development to implement a lot of these

other possibilities. From a project systems engineer’s perspective, what was unusual about the 

GRAIL mission? I know it’s kind of an open-ended question, but what was unusual about it?

Price: Well, many things. The fact that we had two single-string spacecraft. Usually if you have 

two single-string spacecraft, it’s because you’re willing to let one of them die, and the odds are

that one of them will survive. But here, two single-string and both of them had to work perfectly 

for it to do the mission. The other is that they were formation-flying around the Moon, and 

nobody had ever done that before, and they had to maintain their distances very precisely, so 

there was a lot of very precise navigation that had to happen.

Also, one thing that was a big advantage was that we didn’t have this time delay that we 

normally have with our interplanetary missions. The Moon’s not that far away, so it’s like onesecond light-time each way. That was very unusual that we could sit on our consoles, we could 

send commands to the spacecraft and get an immediate response. So, we could do real-time 

commanding if we had to, and there were some instances where we did plan on doing some realtime commanding. So that was very nice.
7

We also ended up transitioning into orbits that were very low to the Moon, to get more 

accurate gravity measurements, so we had multi-path issues with telecom. Because we were so 

low to the ground, the radio signals would bounce off mountains and craters and stuff, and it 

would mess up our communication. We had to learn how to deal with that. We did all these 

different kinds of analyses and tests to figure out what parts of the Moon had these problems, so 

then we planned our operations knowing that when the spacecraft got over certain areas, we 

couldn’t rely on communications, and so we didn’t try to. We planned our mission to take 

advantage of the areas where we didn’t have these multi-path issues when we were in the low 

orbits.

Q: Oh, wow. It would strike me as that in itself would be a fairly complex undertaking. You’re 

essentially making a radio map of the Moon.

Price: Yeah, we kind of did that, and there were actually lessons learned here for the Artemis 

Program to land people on the Moon, because they want to land at the south pole, and the Earth

will be very low to the horizon, so we know that they will have all kinds of multi-path problems 

communicating with the Earth. The people in the Human Space Flight Program are aware of that, 

and they’re trying to figure out how to deal with that. It won’t be easy for them.

Q: Whereas your spacecraft at least some of the time will be in relatively decent radio-clear 

zones.

Price: Yes.
8

Q: You also had the issue that they were often on the far side of the Moon and you couldn’t 

communicate with them at all.

Price: That’s true. Yeah, when they’re on the back side of the Moon, we couldn’t communicate 

with our spacecraft, and so we would record data and then get that back when they were on the 

front side of the Moon where we could communicate.

Q: So they had to record all the positional data onboard and transmit it later.

Price: Yeah, all the science data for the gravity measurements, they were recorded, but really 

they were recorded all the time, because we didn’t get the data in real time. We didn’t count on 

that anyway, so we were able to record a number of days’ worth of data and then we would have 

sessions where we would get all of that down again. We didn’t really lose much data. We had 

processes in place to recover data that didn’t come down on the first try, to make sure that we got 

it all back, and we did get it all back.

I think one interesting thing about our mission, which I think we were all very proud of, 

is that for the primary mission, not the extended mission, but the primary mission, we had zero 

command errors. I don’t know of any other project that’s done that. But there were no bad 

commands that we sent up that had any bad effect on the spacecraft. They were all good 

commands.

We did break that trend in the extended mission. We did have some command errors that 

we sent up. One of them was actually a bad command error. It was a file that we sent up to the 
9

spacecraft, and then when we were executing it, we didn’t access the right version of the file, and 

so the spacecraft went into a safe mode. And there was a bad interaction with this non-science 

instrument called MoonKAM, which was made of commercial components, and it had problems 

with solar radiation and it would sometimes just go on the fritz, and we’d have to turn it off, turn 

it back on again, and it would reset. It would be fine, but it had these single-event upsets. So, we 

had this bad interaction which was in combination with this bad command, and the MoonKAm

was turned on when it should have been turned off, and it went into one of these glitches. There 

was an electrical backlash into the power switch card, and it actually burned out a couple of 

power switches.

Q: Jeez.

Price: One of them was for the MoonKAM switch, and another one was for an important heater 

circuit. That was damaged, and that heater wouldn’t turn on. But, luckily, that was one of the 

heaters where we had a redundant heater circuit and a redundant switch, so we went to the 

redundant system and it wasn’t a problem. But that was a close call. If we had been fully singlestring, we may have lost one of our spacecraft.

Q: Boy, that is a bad command error.

Price: Yeah. That was during the extended mission, not during the primary mission. We went to 

the really low orbit, and so we got the best gravity data from the extended mission.
10

Q: Typically in the extended mission you have a smaller staff to do all the work.

Price: That’s right, we did.

Q: I wanted to ask what do you think was the most significant challenge to be overcome during 

GRAIL development?

Price: It’s a good question. I think it was the design changes we made, changing out components, 

changing out the flight computer, and we had a different set of software than what was proposed. 

We had some late deliveries of parts that we needed, and some of the parts that came in at the 

last minute. There were some deliveries that we didn’t get, we couldn’t integrate until we were 

already at the Cape. So, I mean, one of my lessons learned for future projects is to order lots of 

your parts, order extra ones and order them as early as you can. I think we waited a little bit late 

to order some of the parts to make sure these are really the parts that we wanted, and those are 

the ones that we had supply issues with and they came in late. In retrospect, I think we should 

have ordered all of those parts, even if we didn’t know if we were going to use them or not, just 

to make sure we got them in time, because we had enough cost reserves to cover that.

Any other really challenging things? Nothing else comes to mind right away.

Q: I’ve interviewed Dave Lehman, and he thought it was pretty unproblematic too.

Price: Yeah, it was. It was one of the most unproblematic projects I’ve worked on, and 

everybody else who was on the project just thought, “Wow! Everything just went so smoothly.”
11

Q: Interesting.

Price: I’ll give Dave Lehman all the credit for being just a brilliant project manager. We had a 

really good team, but Dave was a great project manager, very level-headed, really kept 

everything going in a calm way.

Q: Sort of a calm, rational, and somewhat humorous demeanor.

Price: Yes, that’s right. Dave has a great sense of humor, but it’s a pretty dry sense of humor. 

Duncan had sort of a sense of humor, too, but it was also very dry, and a lot of people just didn’t 

get it.

Q: So, it sounds like maybe for GRAIL—and I guess you wish for this as a design-oriented 

engineer, but it sounds like the challenges were overcome when Duncan sat down with the 

design and started to rework it almost, right?

Price: Yeah. Duncan did all these gravity calculations, working with Mike Watkins, and looking 

at all the error sources in the spacecraft, and he worked out those issues. Then in parallel, I was 

working out the rest of the spacecraft, the way all the different subsystems function, to check 

their reliability. Then Tom Hoffman, who was the flight system manager, he was working a lot 

of the details with Lockheed. Kevin Barltrop, who was the flight system engineer, was also great 

in working all of the details of the actual spacecraft itself.
12

Q: Kevin’s the one name I didn’t know of that group. I haven’t talked to Tom Hoffman yet, 

because he’s a little busy to get to, and I also have to talk to him about GRAIL.

Price: Kevin you’d be able to get a hold of, and I’d recommend talking to Kevin. He was very 

instrumental in the success of the project as the flight system engineer. He’s still around.

Q: Very good. What’s he working on now?

Price: Let’s see. He was working on, I think, Europa Lander, and Europa Lander didn’t get a lot 

of love in the decadal study, so—

Q: No, it didn’t.

Price: No, it didn’t. They need to just change the name to Enceladus Lander, but, unfortunately, 

the gravity is one-tenth of what it is on Europa, so the lander won’t work the way it is now on 

Enceladus.

Q: I had the immediate response the same way as like, well, maybe they just rebrand themselves. 

[laughter]

Price: There are a lot of elements of the Europa Lander that would be useful for the Enceladus 

Lander, that’s true.
13

Anyway, we’re off topic here. Back to GRAIL.

Q: Yeah, we’re off topic. Back to GRAIL. So, at the beginning of the development, what did you 

think your biggest risk was going to be as opposed to what did it turn out to be?

Price: I thought immediately our biggest risk was the reliability of the spacecraft, the two singlestring spacecraft, so we tried to get on that right away, tried to fix that as soon as we could so it 

would be early in the development, all these changes. There were cost increases and mass 

increases associated with that development, with those changes.

We actually got lucky on one aspect. The proposal proposed this very light version of the 

Delta II, and so it actually couldn’t carry the mass of the changes that we made, but it turned out 

that United Launch Alliance didn’t really have the wherewithal to build this cheaper, lighter 

version of the vehicle. The only version they could produce that was left in this very limited 

pipeline was the full-up Delta II. So NASA paid for that, because that was the only option 

available to them.

So, all of a sudden, we had like an extra 100 kilograms of mass that we could use, 

because we accidentally got a bigger rocket. So, we didn’t get dinged for our mass increase to fix 

the reliability problems, because we just lucked out and had a bigger rocket anyway. If we hadn’t 

gotten the bigger rocket, we would have been in the bad position of saying, “Oh, you know, our 

mass went up by about 35 percent, and we have to have a bigger rocket.” So that wouldn’t have 

looked too good. But we had the problem fixed for us.

Q: And you didn’t even have to ask.
14

Price: Didn’t even have to ask. So that was lucky. So that was what I thought was going to be the 

biggest problem, and we fixed that. After that, I didn’t really see big problems. We were all 

worried about the MoonKAM, because that was basically the Ecliptic Enterprises’ Rocket Cam 

that they used to take all these neat videos of rockets when they take off, but it’s made out of 

commercial parts and it’s only designed to last for like about twenty or thirty minutes or 

something, so we were going to use that throughout the whole mission to take these neat images 

for students, Sally Ride’s thing to involve middle-school students.

We were concerned about having this non-reliable system, so our thought was, “Well, 

we’re going to try to integrate this thing so no matter what goes wrong, it can do no harm to the 

spacecraft.” But in the end, it actually did do harm to the spacecraft. It killed two of our—it 

melted two of our power switches, but that was also in conjunction with a command error that 

we had. If we hadn’t had the command error, we wouldn’t have had that problem. Then we 

became much more careful with the MoonKAM and when we turned it on and how we managed 

that. So, after we had our little incident with the power switches, we didn’t turn on MoonKAM

for a while, but then towards the end of the mission, we did turn it back on again and it got some 

amazing videos of the Moon when we were really low in orbit. I still like going back and looking 

at these videos that MoonKAM took of the Moon. I mean, they’re really spectacular videos of 

the Moon.

Q: So, the reliability of MoonKAM was an issue, and it was a matter of, I guess, redesigning the 

interface in hopes that it wouldn’t actually be dangerous to the spacecraft.
15

Price: Well, it wasn’t redesigning it. So, from the get-go, we tried to design the interface so that 

MoonKAM could do us no harm, no matter what happened to it, and we didn’t do it quite right. 

It turns out there were some—I’m not an electrical engineer, so I may not get this right, but there 

were some diodes or filters or protective things that we could have put in that circuit to protect 

against the current backlash that wiped out these switches, and we failed to do that when we 

designed that interface. So, in retrospect, I would be for flying MoonKAM again, and we have 

some lessons learned about how to do that interface so that there can’t be a backlash of current 

from that instrument.

Q: I should have thought that was possible.

Price: It should have been. So, there was, I would say, a design error in the interface where we 

were not correctly protecting against possible current backlash.

Q: I find this conversation interesting because I would have thought that the measurement 

precision that was required would have had more impacts than it did, or I guess maybe it’s 

another way of saying your upfront dealing with it in the design phase maybe prevented it from 

being a big deal.

Price: Yeah. Duncan identified some materials issues and some construction issues with the 

spacecraft bus that protected against thermal expansion and contraction, because that would have 

impacted the science measurements. We had a little bit of a cost hit and not too much of a mass 

hit for that one. But Duncan worked with Lockheed and they made some changes to the way they 
16

were building the bus. It was kind of a heritage design bus from the XSS-11 Air Force satellite, 

but it was scaled up. Then Duncan worked with them to make design changes in how those 

panels are put together to avoid thermal expansion and contraction.

Q: Wow.

Price: Then the location of the propellant tanks was modified and the location of some of the 

instruments were modified, and also where we put the attitude control sensors was also very 

important to the measurement, because really what we were measuring is the center of mass of 

the spacecraft, the position of that. But the attitude control sensors weren’t at the center of mass, 

so there’s an error between where we’re measuring attitude versus where the gravity ranging

system is measuring. That’s why we had to do a lot of calibrations, and some of those 

calibrations were done in flight.

Another issue was outgassing. We needed to have everything outgas during the trip to the 

Moon so that when we started making gravity measurements, the outgassing wasn’t messing up 

our measurements. So, I actually did a lot of analysis of outgassing and looking at other vehicles 

and trying to project what the outgassing could be. Early in the mission, we could actually

measure the outgassing, looking at the data we were getting, and it took longer to outgas than we 

thought it would.

Oh, another one of the changes that Duncan made was for internal outgassing, initially 

they were going out one vent, so that would have imparted an impulse to the spacecraft, so 

Duncan requested a redesign so that there were two opposite vents on the bus, so that when there 
17

was internal outgassing, the outgassing would tend to cancel itself out, so that wouldn’t mess up 

the gravity measurement. So that was one of a number of changes Duncan and Lockheed made.

Q: That’s some really—what’s the word I want?—brilliant and also kind of sensitive 

engineering, because—

Price: Yeah.

Q: —you are talking about such tiny forces.

Price: Oh, yeah, very tiny forces.

Q: So what else should we talk about from the standpoint of the engineering for GRAIL that was 

significant? Maybe put it in terms of other lessons learned for future projects.

Price: The lessons learned from MoonKAM, I think from the way we did the reliability, the 

single-string systems, I think those are good lessons for future projects that may have singlestring systems, what to focus on. Doing the fault tree is very important. Let’s see. Nothing else 

really comes to mind.

Q: Was there anything unusual about the organization of the project? For example, you 

mentioned you were both the project systems engineer and the independent technical authority, 

so your funds came from the chief engineer’s office. Is that typical?
18

Price: That was actually typical at the time. I think Juno was done the same way. But I don’t 

know if that’s done now. I don’t know if that’s the current practice for how engineering technical 

authority is instituted, whether it’s through the PSE. But it worked out well. I worked with the 

project like I was just a regular part of the team, but everyone knew that I exerted an independent 

technical authority, and so I would sometimes ask questions related to that or ask for 

information, kind of probing into various aspects of the systems engineering, but it was never a 

problem. I mean, everybody on the team got along really well. We got along with the contractor 

team really well, never any fights or anybody getting angry about anything. I think part of it was 

because everything just went so smoothly, everything went so well, but we had some changes. 

We changed some requirements. And the team at Lockheed was great. They really tried to help 

out and just be a part of the team as well as they could.

Q: Great. So I’m down to my last question for the time being, anyway, and it’s kind of my 

famous what haven’t we talked about that we should have?

Price: Ah, okay. I had a lot of fun during operations. We had the Mission Support Area, the main 

MSA in 264, where the project manager was, the mission manager, I was there, Kevin Barltrop 

was there, the flight system engineer. Every now and then during a critical operation like orbit 

insertion or when we crashed the spacecraft on the Moon, there’d be some cameras in there, and 

that MSA really got all the attention, but the nav people had their own MSA, and that was kind 

of on the other side of our floor, and they had the fun MSA [laughs], you know, where nobody 

was really watching them and they didn’t dress up or anything. They always had, all these 
19

snacks. People would bring in cupcakes and cookies. So, we were in the straight-laced MSA, and 

we’d do our work there. Then whenever we got a chance, I would walk over to the fun MSA, 

where the mission nav people were, and have some cupcakes.

I went in there one time, and it was during a critical operation, and somebody had

brought in their baby, maybe three or four weeks old. They’re doing operations on console, so 

she’d hand off the baby to somebody else and she’d be doing work for mission design in nav. 

People were taking turns holding the baby, and the baby was making all kinds of cute noises. So,

I thought that was just great that in the fun MSA not only did they have cupcakes and cookies, 

but they have a baby too. [laughter]

Q: That’s a great story. [laughter] Childcare for the day must have fallen through. [laughter]

Price: Yeah.

Q: Well, great. Sorry, that was supposed to be my last question, but you had mentioned that 

GRAIL was really fun and you really enjoyed it.

Price: Oh, yeah.

Q: So what was fun about it?

Price: Well, I think it was the team and how the team worked together. We also got together 

socially, for parties and things, and that was nice. We’d get together with the people from 
20

Lockheed. We’d go visit them, they’d come visit us. It was just a team that really worked well 

together.

Also, we accomplished a lot. It was a short mission. A lot of these missions, you know, 

like Cassini, if you worked on Cassini from beginning to end, that would be your whole career, 

and there were a few people who actually did that, but this was a mission where I could come 

onboard and then three and a half years later, it was all done and I was there for the whole 

mission. So, I think people really enjoyed being able to be onboard for the entire length of the 

project, from the very beginning of the design phase to the end of the mission, and had a very 

clear, crisp end of mission, you know, crashing the spacecraft on the Moon, and then the Lunar 

Reconnaissance Orbiter took photos before and after where we hit, so we could see where we hit. 

We dug up dark material we excavated from the Moon. The mountain that we crashed into near 

the north pole wasn’t named, so we were able to name it after Sally Ride.

Q: So it was a nice cradle-to-grave experience, I guess.

Price: Yeah, it was.

Q: It’s in some ways a lot more fun than the missions that go on for a lifetime.

Price: [laughs] Right.

Q: Thank you for your time.
21

[End of interview]