Tag Archives: Moon

Demonstrating Science: From the Ames Research Center Science Back Room

Reposted from  https://blogs.nasa.gov/analogsfieldtesting/2012/07/31/post_1343767437112/ and https://blogs.nasa.gov/mission-ames/2012/08/31/post_1343858990664/.

Ames scientist Kimberly Ennico wrote this blog entry on July 20, 2012 while working on a field test for RESOLVE, the Regolith and Environment Science and Oxygen and Lunar Volatile Extraction. 

43rd anniversary of “One small step, One giant leap”

I write this after the conclusion of our multi-day field demo of the RESOLVE payload. Prior to any activity, as with all organized operational tests, a clear set of success criteria is identified. RESOLVE, having being defined by NASA’s exploration and technology divisions, has the following goals:

CAT 1 Objectives (Mandatory):

  1. Travel at least 100m on-site to map the horizontal distribution of volatiles

CAT 2 Objectives (Highly Desirable):

  1. Perform at least 1 coring operation.  Process all regolith in the drill system acquired during the coring operation
  2. Perform at least 1 water droplet demo during volatile analysis.

CAT 3 Objectives (Desirable):

  1. Map the horizontal distribution of volatiles over a point to point distance of 500m.

            * Surface exploration objective is 1km

  1. Perform coring operations and process regolith at a minimum of 3 locations.
  2. Volatile analysis will be performed on at least 4 segments from each core to achieve a vertical resolution of 25cm or better.
  3. Perform a minimum of 3 augering (drilling) operations

            * Surface exploration objective is 6 augers

  1. Perform at least 2 total water droplet demos.  Perform 1 in conjunction with hydrogen reduction and perform 1 during low temperature volatile analysis.

CAT 4 Objectives (Goals):

  1. Perform 2 coring operations separated by at least 500m straight line distance

            * Surface exploration is 1km

  1. Travel 3km total regardless of direction
  2. Travel directly to local areas of interest associated with possible retention of hydrogen
  3. Process regolith from 5 cores
  4. Perform hardware activities that can be used to further develop surface exploration technologies

At first glance, they are pretty much very operations based: 100 m (328 ft) here, 1 km (3,281 ft) there, three locations, three auger (drilling) ops, etc. They were the driving forces of this demo, no pun intended. Our main focus was to demonstrate the technology and the operations. However, as each day went on, you could hear on the voice loop the engineers asking more and more about what we scientists – those on site or in our “Ames science backroom” – were discussing and observing with each new scan, spectra, and image. Also, we actually found ourselves demonstrating science in this activity. That was the whole beauty of this project: science enabling exploration and exploration enabling science. Each team member, excited about roles played by others, united by our shared excitement in the concept of pushing our ability to explore beyond our home planet.

At the end of our field demo, we clocked 1,140 m (3,740 ft.) total in-simulation roving distance, 475 m (1,558 ft.) separation travel distance between hot spots, with total separation of traverses greater than 500 m. (1,640 ft.) We located nine hot spots, completed four auger operations, four drill operations, and four core segment transfers to the crucible (oven) for volatile analysis and characterization. We had seven remote operations centers plugged in to our central system. We logged 185,918 rover positions, collected 227,880 near-infrared spectra, 136,273 neutron spectrometer measurements, 139,703 drill measurements, 3,630 image data products, and wrote 2,446 console log entries.


Band-depth (a measurement of abundance) for a water band (at 1.5 microns) plotted for the whole simulation. Most of the water detected this way turned out to be “grass” in the spectrometer’s field of view, but we did rove over some pretty “dry areas.” Variety indeed. The red line shows our traverse path on July 19. (Right) Counts for the neutron spectrometer for the simulation. This aerial photo shows how we traversed over a range of geological features, a mixture of glacial (old outwash) and volcanic (olivine basalt) deposits. Image credit: NASA

While some of the ISRU technology demonstrations focused on pre-arranged drill tubes filled with pre-planned test materials, we were particularly excited to drill into the native tephra. Its saturated soil (up to 20%) is more consistent with the Mars surface rather than the lunar surface. If successful, this test also would show practical drill performance parameters for future Mars drill missions. The approved procedures allowed us to core down to a maximum of 50 cm (19.6 inches). We reached 45 cm in about 56 minutes. Then, instead of putting the sample into the oven, the core tube was “tapped” out onto the surface while the rover moved forward to lay out the sample for evaluation by the near infrared and neutron spectrometers. This was a new procedure developed jointly by the rover, drill, and science teams, which demonstrated a new way of extracting material and quickly evaluating it.


Artemis Jr rover DESTIN (drill) acquiring sample from native soil. Image credit: NASA


The Ames science backroom team, clockwise from top left: Erin Fritzler, project manager; Bob McMurray, system engineer; Kayla La France, intern; Ted Roush, scientist; Carol Stoker standing, scientist; and Jen Heldmann, scientist. Not shown: Stephanie Morse, system engineer; Josh Benton, electrical engineer; and me – Kim Ennico, scientist. With our team of nine people we staffed three consoles in two shifts, for eight-days.


Ames science team members in Hawaii. They were our main interface for the Ames backroom to the Flight, Rover and Drill teams, whose leads were in Hawaii, but whose support teams were at KSC in Florida, JSC in Texas, and CSA in Canada. Left to right: Rick Elphic, Real Time Science and Tony Colaprete, Spec. Photo by Matt Deans.

To end on a fun note: mid-way through the sim, I got my updated console request so I could monitor the neutron spectrometer and near infrared spectrometer simultaneously to look for correlations (this combination of techniques had never been done before). I spotted this one (image below) as we were roving about. Camera imagery had been down, so we were “in the dark” from visual clues. Upon seeing the two signals, I called out a strong hydrogen and water signal to the Science team in Hawaii over the voice loop.


Screengrab of one of my console screens. Top trace is the neutron spectrometer Sn counts showing a modest signal. Bottom traces are two different near-infrared water spectral regions that showed changes at the same time.

And it turns out we roved over this, a trench of water and a piece of aluminum foil reflecting the clear blue Hawaiian skies. The neutron spectrometer is designed to detect hydrogen at depth, whereas our near infrared spectrometer is more suited for surface water.


A test target along traverse path for July 19. Image credit: NASA

This target, like others we traversed over the past week (buried pieces of plastic, netting, etc.) had been dug out in the wee hours of the morning by other members of the RESOLVE operations team. Good way to get a few hours exercise after being cooped up behind monitors!

So what’s next? A “lessons learned” exercise is called out for next week. The different teams wrote down our learning points daily when they were fresh in our minds. We will review them as a team and move forward with the next steps – building a version that works in a vacuum. And our Ames backroom science team has identified a few science papers to write. We are excited!

For more information about the In-Situ Resource Utilization analog field test and the RESOLVE experiment package, visit www.nasa.gov/exploration/analogs/isru


Iterations of Science & Exploration

Reposted from https://blogs.nasa.gov/mission-ames/2012/07/19/post_1342737399087/.

Ames scientist Kimberly Ennico wrote this blog entry on July 16, 2012 while working on a field test for RESOLVE, the Regolith and Environment Science and Oxygen and Lunar Volatile Extraction. This week you can follow RESOLVE live on Ustream [Note: link was active in 2012].

On this 43rd anniversary of Apollo 11 launch, the moon is on my mind, naturally.

I am a NASA scientist who typically spends days in the office staring at my computer screen, “crunching” data, making plots, analyzing the results and writing up what is being demonstrated by the completed experiment. You know, that scientific method. The experiment could be an observing run at an observatory, a lab-based test or a series of images taken by a space telescope (at some past date) that is sent down to the ground or retrieved from a data archive. Quite frankly, I am often a passive (but always strongly passionate) participant in the advancement of science.

This week, I found myself in the rare moments where I am contributing to the operations of a space mission. In this case, it was a field demonstration of a future lunar rover. For full disclosure, in 2009 I also got the chance to participate in a real space mission with LCROSS, which was an amazing experience. This “field demo” experience is slightly different and provided me with an opportunity to reflect on the power and honest “truth of iteration” and how valuable it is for learning.

First, I need to set the stage. We are now in day four of a seven-day “field demo” of the RESOLVE payload. RESOLVE stands for Regolith and Environment Science & Oxygen and Lunar Volatiles Extraction. Snazzy name, eh? It is a payload designed to be on a movable platform on the moon. Its objectives are to locate areas of high-hydrogen, which is an indicator of possible water ice in the subsurface. After identifying a “hot spot” the rover is commanded to stop and begin initial “augering” with active monitoring for water and other molecular signatures. The augering process takes about an hour and samples down to about 30-50 centimeters (to give us a sneak-peak of what lies beneath). It can drill deeper, but the amount of subsurface material brought up is expected to be limited. If we find something interesting, the drill is put into place to drill down 1 meter, the limit of our initial surface detection methods, and extract “core samples” from a series of depths. Finally, the last leg of this “roving laboratory” is to take each of the “core samples” and place it inside an oven where it is heated to liberate the molecules. To identify what is in the sample, the vapors are collected by a mass spectrometer and gas chromatograph. It is essentially a mini-lab, very similar in approach to the Mars Science Laboratory currently en route to the Red Planet.


Right: The RESOLVE payload on the Artemis Jr. rover (left) and mock-lander (right) during a field demo exercise in Hawaii (Photo from RESOLVE team).

Why are we doing this? Well, not only has LCROSS data indicated the presence of water on the moon, but datasets from NASA’s Lunar Reconnaissance Orbiter, Lunar Prospector, Cassini, Deep Impact and Clementine also point to “significant quantities” of hydrogen-bearing molecules, particularly in permanently shadowed craters near the lunar poles. The form of the hydrogen is widely debated, so there is a need for “ground-truthing.” Lets dig and sample that dirt! At the same time, these hydrogen-bearing molecules could also be extremely useful resources for water, propellant, etc. So in comes a trendy-buzz word in space circles, ISRU, which stands for In-Situ Resource Utilization.  Historically when explorers reached new lands on our planet, if you could “live off the land” using items that you found along the way, you considerably extended your exploration journeys because you have to carry everything with you (not to mention the related expenses). Hunting and gathering for food, making shelters from forests, mining local fossil fuels, etc. As we journey to other worlds, we can do the same.

Enter analog-missions. We’re using Hawaii for the moon. Sadly I am not there (my scuba diving urges will just need to wait). I am sitting in the “Science Backroom” here at NASA’s Ames Research Center in Moffett Field, Calif. It is basically a room full of desks, with lots of computers and monitors and headsets to hear audio loops.


Right: Me (left) and Carol Stoker, drill expert and Mars scientist, in the Ames Science Backroom looking over activities. Image credit: Jen Heldmann

Analog missions have been performed for years to validate architecture concepts, conduct technology demonstrations and gain a deeper understanding of system-wide technical and operational challenges. And let me say, on day four, it is doing exactly that. A lot of stops and gos, lots of “oh I wish I could see this or that,” etc. etc.

We have a distributed team, and this is not uncommon for most operations activity. Some are in Hawaii to assist with physical items associated with the rover and payload. At a nearby building in Hawaii, others have access to real-time data for monitoring and control. Supporting control centers are in place in Texas (NASA’s Johnson Space Center in Houston) and Florida (NASA’s Kennedy Space Center), while in California (here at Ames), others support the mission science with access to high-tech visualization tools. We all have our respective roles, but we need to work as an integrated team to achieve success. At the same time, “not all should speak at once” otherwise you talk past each other and you can miss things. So there is a bit of needed protocol at work. In our “science backroom” we talk with our on-site science reps Tony Colaprete & Rick Elphic who are actively monitoring the flight and rover voice-loops, which we may not always be listening in on. Our purpose is to focus on real-time and archival science analysis, because, when you come right down to it, we are exploring. We don’t know what we will find next.

This mission concept also is relying on humans to make decisions at critical junctions, so it is far from being an autonomous machine. And by involving people, you can run into some pretty interesting decision points. We are also test driving (pardon the pun) a new way to integrate our visualization of our data. We have the “typical” live telemetry from the instruments on the rover and their trends. But we are also overlaying in near-real time the instruments’ data and rover position onto a Google map. We are taking advantage of an existing data visualization tool and its properties (layers, grids, pin locations, commentary, etc.). And we are linking the photos from the on-board rover cameras to the Google maps just like people do with their holiday pictures. It is actually rather elegant, but also needs some tweaks.


Above: (Left) Screengrab of one of our visualization tools of a traverse-trek with data from the neutron spectrometer colorized to indicate signal strength. The green line shows the planned path; red line shows the actual path. Shown here is the trace from a “hotspot localization” routine so we can pinpoint the source further for analysis. (Right) Same scene but this time overlaid are locations of each of our rover-camera images, with one shown as an example.


Right: Examples of rover images before, during, and after a drilling exercise from (top) a fish-eye lens camera in the rover underbelly and (bottom) a camera that is coincident with the near infrared spectrometer field of view.

We are learning as we go. Each day we have a series of tasks to complete whether it is a number of meters to traverse, or completing the drilling of multiple sites, etc. Timeline is extremely important since in a real flight mission; there will always be limited items such as fuel or power. Roving plans are decided ahead of time, but things do not always go according to plan, especially if something we did not expect appears on our data streams or the rover does something unexpected on unexplored terrain. With each unexpected event, we learn.

My personal challenge is keeping up with all the conversations going on, those that address what we are seeing real-time, those that are focused on how we can improve our approach and those all about the real thing — when we do this on the moon.


Right: This was my monitor today as I was trying out a new method to look for a water signature, monitoring any correlation between the neutron spectrometer signal and various band depths from the near infrared spectrometer. My requests for a new visualization tool are being incorporated into the system and will be ready for me when I go on console tomorrow.




What Happened on Impact Night?

From the LCROSS Flight Director (Paul Tompkins) Blog. Reposted from https://blogs.nasa.gov/lcrossfdblog/2009/12/16/post_1260990722929/

Kimberly Ennico Note: I contributed the information in Mark Shirley’s addition to this entry in Paul Tompkins (Mission Operations Manager) LCROSS blog series about what was happening on the LCROSS payload during impact night. Mark was sitting in the MOCR/Mission Operations Control Room while I was in the SOC./Science Operations Control across the hallway.

The LCROSS mission was ultimately focused on the final four minutes of flight, starting at the time of the Centaur impact, and ending with the impact of the Shepherding Spacecraft.  During that time, the Payload Engineer and the Science Team took operational center stage.  Once the science payload was powered on, the team’s job was to confirm the full functionality of the instruments, and then to adjust instrument settings to make sure the data we received was the best it could possibly be.  For Impact, there were no second chances – the Shepherding Spacecraft was to be destroyed as a forgone outcome of its observation of the Centaur lunar collision.

In this post, I’ve invited Payload Engineer Mark Shirley to provide his perspective of impact night.  Mark was the Payload Software Lead, in charge of the design and implementation of onboard instrument command sequences and other onboard software components, as well as a large fraction of the science-related data processing software used on the ground.  During flight, Mark sat in the Mission Operations Control Room (MOCR) with the rest of the Flight Operations team.  On the final day, his job was to assess and maintain the engineering functionality of the science payload in those minutes before impact.

In the impact video sequence, from the public’s perspective, there were a lot of things that happened operationally that were probably difficult to understand.  Mark will explain the plan for gathering data from the impact and also describe what actually happened in flight.  On a lighter note, Mark was one half of our now famous (or notorious) “high-five malfunction” that created such a buzz on the social media circuit after impact.  He’ll explain that as well. I’ll let Mark take it from here.  Enjoy!

I’d like to describe our plan for collecting data about the Centaur impact from the shepherding spacecraft (S-S/C), how actual events differed from the plan, and what that says about the process of developing and flying spacecraft.  In particular, I’ll cover why some of the pictures were fuzzy and some were white and why we were sending commands during the last minutes.  I won’t touch on the scientific interpretation of the data, only the process of gathering it.  This story contains some hard work, a few mistakes, a little nail biting tension, and finally, success.

Central to the story is the type of mission LCROSS was: a cost-capped, fixed-schedule mission.  That meant if LCROSS had been late, LRO would have flown with a dead or inactive LCROSS.  If the project had run out of money, whatever hadn’t been done wouldn’t have gotten done.  Within the LCROSS project, the instruments were in a similar position.  The original idea was to observe the Centaur impact from Earth only.  Onboard instruments were soon added to the design but with a total instrument budget of approximately $2 million.  That’s much less than single instruments on many other missions.

Two things made success possible.  First, project managers kept a tight focus on using the barest minimum hardware and testing required to perform the science, and went beyond that, only as the budget allowed, to increase the likelihood of success.  Second, everyone stayed on budget. The payload team had no choice, but if any other part of the project had overrun by a lot, the payload might have been eliminated or flown only partially ready.

The LCROSS Instruments

LCROSS carried nine instruments.  Five were cameras to take pictures over a large range of wavelengths, that is, colors. One was for visible light that our eyes can see.  Two near-infrared cameras captured mineralogy and water signatures, and two mid-infrared cameras captured thermal signatures from -60C to +500C).  LCROSS carried three spectrometers to measure color very precisely.  One covered ultra-violet and visible wavelengths and two covered near-infrared wavelengths.  The latter spectrometers were the best at searching for water, and one looked down toward the Centaur impact the vapor cloud it kicked up and the other looked to the side as LCROSS passed through that cloud.  Finally, LCROSS carried a high-speed photometer to measure the brightness of the impact flash.

The instruments are described in detail here.  Data from all nine instruments had to share LCROSS’ one Mbps (one megabit or million bits per second) radio link to the ground.  At that rate, it takes 2 seconds to transmit a typical cell phone picture.  This was the maximum data rate available for the LCROSS mission and used only twice: lunar swingby on June 22nd and impact on October 9th. All other instrument activities that took place during the 112 day mission used speeds less than 256 kbps (kilobits or thousand bits per second), which was sufficient for collecting data to calibrate the instruments.

Link to LCROSS Instruments

The Observation Plan

The two components of the LCROSS mission, the Centaur and the Shepherding Spacecraft (S-S/C), separated about 10 hours before they reached the moon.  At the moment the Centaur impacted, the S-S/C was still 600 kilometers above the surface.  Falling at 2.5 kilometers per second, the S-S/C reached the surface 4 minutes later.  Observations of the Centaur impact event made during those 4 minutes were the purpose of the mission.  Unlike orbital missions that can usually try multiple times to collect data, we had just one shot.

The diagram below shows the plan for observing from the S-S/C, starting one minute before Centaur impact, at the beginning of what we called “Sequence 2” in the NASA TV video.  The diagram plots our intended schedule of instrument observations against time: each row represents one of the instruments (instrument abbreviations appear below each row of data), and each tick mark along a row represents one observation, either an image or a spectrum.  Over some intervals, the observations are spaced so closely that the plot looks like a solid bar.


Figure 1 The LCROSS impact observation plan: These timelines indicate when each image and spectra was planned to occur during the final four minutes of the mission.  The horizontal axis represents time.  Each row represents an instrument, and each tick mark represents the timing of a sample (an image or spectrum) from that instrument.

The last four minutes were divided into three periods, called FLASH, CURTAIN and CRATER.  Each period focused on a different aspect of the expected impact event and emphasized data collection from different instruments.

FLASH started one minute before the Centaur impact and focused on the very short burst of light generated by the Centaur impact itself.  Starting from the top of the diagram, the plan was to stop both the Visible Light Camera (VIS) and the Near-Infrared Camera #2 (NIR2).  This would allow us to focus on NIR1 images which we felt had the best chance of catching the location of the impact flash which we expected to be visible for less than one second.  These three cameras shared a common input to our payload computer, called the Data Handling Unit (DHU), and could not be used simultaneously. By stopping VIS and NIR2, we could run NIR1 at a faster rate (see the segment labeled ‘A’), increasing the odds it would image the flash.  The planned sequence also increased the NIR1 exposure time to capture the flash signature even if it was very faint.  We knew this would produce a badly overexposed image of the illuminated lunar surface, but our goal was to locate the impact.  We’d have plenty of other pictures of the surface.  This sort of shifting attention between cameras accounts for the periods where one camera image would stop updating for a while.

We also designed the FLASH strategy for the spectrometers around our expectation of a dim, short duration flash event.  Near Infrared Spectrometer #1 (NSP1), the main water-detection instrument, was put into a high-speed, low resolution mode (represented by the yellow bar).  The Visible and Ultraviolet light Spectrometer (VSP) was commanded to take long exposures, and Total Luminescence Photometer (TLP) was powered early enough to reach equilibrium and be at its most sensitive for the flash event.

The second phase, CURTAIN, started just after the Centaur impact and ran for three minutes.  Its purpose was to take spectra and images of the expanding vapor and dust clouds thrown up by the impact.  CURTAIN was the most important period and also the simplest.  All instruments ran in their default modes, as follows.  The DHU shifted between the three analog cameras in a stuttering pattern – VIS, VIS, NIR1, NIR2 – repeating.  Both thermal cameras monitored the plume shape and temperature. The two downward-facing spectrometers (NSP1 and VSP) looked for water and other chemicals.  The side-looking spectrometer (NSP2) also looked for water and other compounds, but from sunlight scattered or absorbed by the dust and vapor cloud.  The TLP continued to take data during this period, but it’s primarily function was during FLASH.

The goal of CRATER, the final period, was to image the crater made by the Centaur impact to get its precise location and, more importantly, its size.  From its size and their detailed models of crater formation, the LCROSS Science Team can potentially tell us how the crater evolved over the few seconds of its formation and how much material was excavated.  The primary instruments in this period were the two thermal cameras, MIR1 and MIR2.  Their sample rates were increased relative to those for CURTAIN.  To image the crater in a second frequency band, NIR2, the more sensitive near infrared camera, was commanded to its most sensitive setting.  NIR1 and VIS would not be used during this period because neither was sensitive enough to see anything in the permanently shadowed area.  All spectrometers would continue running to look for light reflected off of any plume or vapor cloud.  At the end of this phase, the S-S/C would fall below the rim of Cabeus Crater, cutting off radio transmission to Earth, and then impact the surface a couple of seconds later.

There were three keys to making this plan work:

  • Downlink Bandwidth: the data collected had to fit within the 1 megabit radio downlink. We did a lot of testing before launch to work out a data collection plan that was further confirmed and refined based on on-orbit performance. We gave priority to data from the most important instrument, the near-infrared spectrometers, to provide robustness to the design. The best scheme was pre-programmed and ready to go in case we were unable to command the spacecraft in the final hour.
  • Camera Exposure: We had to change camera exposure settings during the descent to reflect the changing    brightness of the impact event and the surrounding scene.  Defaults were pre-programmed based on the latest lighting models for impact morning from NASA Goddard Space Flight Center.
  • Command Timing: In the instrument command sequences governing FLASH, CURTAIN and CRATER periods, we had to orchestrate changes in instrument configuration as they were needed to focus on    different aspects of the impact event.  Sometimes these changes had to be interleaved with instrument data    collection in a way that was vulnerable to small timing changes.

So What Actually Happened?

Well, as reflected in the recent LCROSS press briefing, we collected a very rich and interesting data set that met the needs of our science objectives.  However, we had challenges in all three areas – bandwidth, exposure settings and timing – although all ultimately proved minor. However, in some ways, it was a close call.  This diagram shows what data was actually collected during the final four minutes of the mission.


Figure 2 Actual performance of the LCROSS payload: These timelines indicate when the images and spectra were taken on the morning of the impact.  The pattern gives clues about the performance of the hardware  and software systems that collected the data.

First, the rows representing the spectrometers, NSP1, NSP2 and VSP, look almost exactly as they should.  Except for one problem with the Visible and Ultraviolet light spectrometer (VSP), which I describe later, our plan for collecting spectra worked perfectly.  This is very good, because the spectra carried most of the information we were trying to collect.

As for the cameras, several differences from the plan jump out.  The most obvious is that the timing of observations along some timelines is irregular with many observations missing, e.g., the visible camera pointed to by note E. This occurred with all five cameras (the first five timelines) but not with the spectrometers (the next three timelines).

Scene Complexity and Bandwidth Limitations

Image compression is the process of finding and reducing redundancy in an image in order to transmit it more efficiently.  On LCROSS, to fit within the 1 Mbps data rate limitation for our downlink, we used a lossy compression algorithm that typically reduced each image to 1/20th its original size.  Lossy methods achieve greater compression than lossless methods by actually removing parts of each image.  The algorithm tries to find subtle details whose removal the human eye won’t notice.  Being able to combine many different kinds of data into a single digital data stream is so useful that this approach has been standard practice for many years.

In flight, the irregularity of observations occurred because we underestimated the complexity of the lunar scene during ground testing.  We had done much of our testing with a large reproduction of the moon’s pole in front of the cameras, but it turned out this didn’t mimic the high contrast and detail of the real scene.  Scene complexity mattered because the images were highly compressed and changes in the moon scene changed the sizes of the compressed images by a factor of 4. We first observed this behavior during the lunar swingby LCROSS performed during the first week of its mission.  Turning on the instruments during the swingby was intended as a learning experience, and it proved critically important.  It provided the best operational practice we got for the impact as well as data to calibrate the instruments.

After the lunar swingby in June, I changed the thermal camera sampling rates in the instrument command sequences for the final hour.  Unfortunately, the compression problem turned out to be about 20% worse during the final hour of the mission than during the lunar swingby.  This forced us to change the thermal camera rates again in real-time, but we had practiced changing them during rehearsals, just in case.  In the NASA TV impact video sequence, you can hear the Science Team requesting a change of MIR1 rates to 1 Hz, and MIR2 to 0.1 Hz.  See note F in the figure.  The rate for thermal camera #1 (MIR1) changes just before this note and changes for MIR2 just after it.  Even though we’d practiced, this was still a very tense time as we were losing some data while the changes were being made. Changing the MIR rates felt like it took forever.

The bandwidth problem could have been avoided if in addition to changing camera sampling rates in the command sequences, we had also changed the stuttering pattern for the analog cameras mentioned above to eliminate one VIS image during each repetition.  However, our instrument simulator didn’t have the full set of instruments like the spacecraft, which made it impossible to adequately test this change on the ground.  At one point, we discussed testing this change onboard before the impact, but lost the opportunity due to the fuel loss Paul described in his blog on October 4th (see “A Test of the Flight Team”).

One other problem caused by the complex lunar scene was damaged images.  After compression, some of the visible camera images were still too large to fit within a single data packet for transmission to Earth.  Here’s an example of the kind of damaged image that resulted.  The shadowed area should be completely dark, but instead contains wispy bright areas. These compression-artifacts are intimately linked to the scene and need to be taken out with image post-processing.


Figure 3 Example of damage to downlinked images due to clipping in the telemetry packet formatting software.

What caused these compression artifacts?  I didn’t know it at the time, but the software for compressing these images had been written some years before to clip the compressed form of images to ensure they always fit within a single data packet (maximum size 65536 bytes).  We used a wavelet-based compression algorithm, and clipping the compressed images removed some information needed to recreate the image accurately.  The alternative would have been to split the images across multiple packets and reassemble them on the ground.  This certainly could have been done in principle, but doing so would have introduced significant changes right at the heart of software that we had planned to reuse without change after its successful use on previous projects.  With what we know now, changing this would have been justified, but it would also have been risky given how central image compression was to the overall design.  With what we knew at the time, I believe we would have left it alone because of our short development schedule and all the other things that had to work.

November, November!

Most of the commanding we did from the ground was to adjust the exposure times of the near infrared cameras as the scene changed.  The other cameras either controlled themselves (VIS) or had only one appropriate setting (the thermal cameras, MIR1 and MIR2).  We controlled the exposure setting for the near infrared cameras explicitly because we were trying to image a relatively dim flash and ejecta curtain close to bright mountain peaks.

Near the beginning of the FLASH period, we discovered we didn’t get this balance right. To image the dim centaur impact flash, we deliberately overexposed the sunlit peaks.  This setting combined with the Cabeus scene overdid it. The sunlit areas electronically bled into nearby parts of the image.  That occurs when electrons in overexposed pixels move across the image detector to other pixels.  In this case, the shadowed area of Cabeus crater was completely covered, obscuring our view of the impact.  That was why the only image that was updating just before the Centaur impact was white.  We hadn’t seen this level of bleeding earlier in the mission, or in almost any of our testing.  However, after searching through our data archive, I realize now we did see it occur once, two years ago, in one flashlight test in a darkened room but did not fully comprehend the implications.

The FLASH period was designed to start 1 minute before the Centaur impact, so we had a little time to recover once we saw the problem.  During this minute, our first priority was to confirm that the spectrometers (NSP1 and VSP) and photometer (TLP) were working properly.  Once that was done, we focused on the NIR1. Since we still had commanding during this period, we tried to change the exposure setting (Payload Scientist Kim Ennico called out “Flight, this is Science, please change NIR1 to OPR 9, over.”). We had less than 30 seconds to get this command sent up to the spacecraft.  The command was actually sent but arrived a few seconds too late to capture the impact. In hindsight, this was a challenging stretch for the camera’s range, due to the scene and the potential for bleeding. Our strategy – to aim for the most sensitive exposure setting followed by one attempt to back-off depending on the data-might have worked had we been looking at another region of the moon, that is, had, we launched (and impacted) on a different date, where the terrain and lighting would have been different. While all this was going on, the impact flash was captured by NSP1, so the key science measurement was made.

We intentionally caused the same issue later, during the CRATER period, but we had better success (see above figure at the segment labeled ‘B’).  Initially, the NIR2 camera images were badly overexposed for the same reason as during FLASH (hence the white images that appear in the NASA TV video just after entry to DV Mode).  Kim Ennico, the Payload Scientist, made the call to reduce the exposure time slightly, from what we called OPR 15 to OPR 10.  (Again, you can hear this request over the voice loop in the NASA TV video.)  She was using live-information from the NSP1 spectrometer and checking those values in real time against a spreadsheet near her seat.  You can see her checking and rechecking on the video before making the choice.  We only had only one chance to choose the right one.  The command was sent and received 30 seconds before the S-S/C’s impact.  Kim’s call initially left the images overexposed, but as the lit peaks slid out of the field of view, her choice produced excellent images of the very dark crater floor, including the image that gave us our best estimate of the Centaur crater size.  These images go all the way down to 2 seconds before S-S/C impact where the craft was 5 kilometers above the surface. The crater floor of Cabeus was indeed brighter than any of the predictions, at least in the infrared. That’s another reminder of science and exploration. Sometimes you are surprised as you collect new data, especially data from areas never looked at before.


Figure 4 This image sequence was captured just before the end of the mission and shows the NIR2 camera going from badly overexposed to acceptably exposed as the lit peaks surrounding Cabeus leave the field of view.

How do we know that’s the Centaur crater?  Because it was also seen by the two thermal cameras (MIR1 and MIR2) while it was still warm, and we can overlay the images.  The left figure below shows aligned images from NIR2 and MIR1, taken before the Centaur impact.  The figure on the right shows aligned images from these cameras taken just before the S-S/C impacted and showing the Centaur impact crater (see inset).  These images don’t align perfectly because they were taken about a second and 2.5 kilometers apart.  To obtain images of the Centaur crater using three different cameras was our goal, and we succeeded.



Figure 5 The bottom image shows the Centaur impact crater in both near-infrared and mid-infrared images.  The top image overlays images taken before the impact by the same two cameras.

Kim’s call of “NIR2 to OPR 10″ yielded a great image of the Centaur crater, but it also caused some confusion.  The name for Near-Infrared Camera #2 (NIR2) was too similar to the name of Mid-Infrared Camera #2 (MIR2).  We had practiced this interaction over our voice communication loops, but we hadn’t practiced it enough to do it quickly and perfectly under time pressure.  Kim had to repeat her call using the phonetic term ‘November’ for the ‘N’ at the beginning of NIR2 (during CURTAIN phase in the NASA TV video, you can hear the Flight Controller, Jim Strong, ask “is that ‘November’ or ‘Mike’?”, referring to NIR2 or MIR2, ).  We didn’t realize when we picked the obvious names for these cameras three years ago that the names could cause confusion when spoken over the voice loops connecting our mission control rooms.  Back then, our plan avoided real-time commanding completely, but as we learned through our practice sessions before launch and actual experience after launch, we realized we needed the flexibility.  We retrofitted a process for proposing and confirming real-time commands into our mission operations architecture as best we could given the facility and time constraints.  Note that we didn’t consider doing this for maneuvering the spacecraft or for the most critical science instruments, only the secondary instruments.

Command Timing

The commanding side of the automatic sequence ran almost perfectly.  We did have one problem with the Visible and Ultraviolet Spectrometer during the CURTAIN period, though.  Because the instrument data handling unit (DHU) was at its maximum data throughput capacity during the first part of CURTAIN, one command to change exposure time was delayed and sent during a period when the instrument wasn’t listening.  That command was ignored.  This resulted in capturing fewer spectra with longer-than-planned exposure times.  Luckily, the longer exposure times turned out to be a blessing, since the ejecta curtain was much fainter than some models predicted. The loss of more frequent sampling due to the longer exposures did not affect the science measurement.

High Five Fail

Yes, I should have.  After the end of the mission, I missed a high five that was captured on camera.  I was teased about it by my colleagues that morning and by my kids that night. The other operator involved, our Telemetry Data Manager, known as “Data” over the voice loop, is both a good colleague and a friend.  I didn’t intend to embarrass him and have since apologized.  We had been told to avoid high fives to prevent exactly the sort of mistake I made, but once the hand went up, I should have responded.  So, here it is, for the record:


Why didn’t I respond?  I honestly don’t remember the moment clearly, but I did have two things on my mind.  First, my job at that point was to move to the Science Operations Center (SOC) to prepare for the post-impact press conference.  We had two hours to make sure we’d gotten the data we expected, to prepare presentation charts and to look for anything obvious.  I was concerned about that because I had missed seeing the plume we had hoped for like most everyone else.

More importantly, I was really stressed out.  The DHU, the computer that processed all instrument data, was struggling with the very large packet sizes of visible camera images, and the DHU almost crashed a number of times during that final hour.  We had developed and practiced a procedure to recover from such a crash to prevent a substantial loss of science data.  Flying a spacecraft is a group effort with lots of cross-checking, and as the Payload Software Lead, I felt especially responsible.

During payload development testing, we found and fixed several problems that would have been problematic for the payload.  This problem which led to potential crashes of the DHU was known and was the most difficult software problem we saw.  The root of the problem was a small chip that controlled the data bus connecting the video capture and compression chips to each other and to the main processor within the DHU.  Under certain circumstances this bus controller chip would stop responding, and the DHU software would crash.  Since we didn’t have access to the chip’s design to understand why it would stop, and we didn’t have time to replace it, our approach was to create a method for quickly recovering on orbit.  This method had two parts.  The first part was a software patch we developed that reset the bus controller when the DHU’s main processor noticed it had stopped responding.  The second part was a procedure for quickly rebooting the whole DHU from the ground if the software patch didn’t catch the problem.

We developed and tested the software patch just a few weeks before the payload was shipped to Southern California for integration with the rest of the spacecraft. From that point on, through the rest of our testing on the ground and in orbit, we didn’t see this problem again. That is, we didn’t see it until the morning of the impact.  That morning, the patch needed to reset the bus controller two dozen times.  The vertical green lines in this figure show when.


Figure 6 During the final hour of the mission, Data Handling Unit (DHU) software detected and corrected an anomalous condition on a bus controller chip multiple times.  The green lines show when these events occurred.  The right end of this figure, starting at the label ‘I’ (the time of Centaur impact) corresponds to the time spans of the planned (Figure 1) and actual (Figure 2) performance plots. Earlier events happened while monitoring payload performance in the 56 minutes prior to Centaur impact.

Once these events started, I was prepared, on a hair trigger, to start the process of rebooting the DHU if the patch didn’t work.  I was constantly checking and rechecking the fault response procedure I had developed for our payload.  The details of this procedure varied over time.  As the on-board sequence progressed and we got closer and closer to the Centaur impact, we had different decisions to make to recover if something went wrong.  This strategizing was being done over another voice loop with Kim and Tony Colaprete, the LCROSS Principal Investigator, in the Science Operations Center (SOC) which was not audible to the audience watching on NASA TV.  We had to keep track of a lot of independent data threads and contingencies simultaneously.  Our actual trigger for starting this recovery, a gap in numeric sequence of the data coming from the instruments, even occurred once, but it was unrelated and didn’t need a response.  In the end, our defenses worked.  The software patch performed exactly as intended and no crash occurred.  After the S-S/C impact, I breathed a sigh of relief and moved to the next room to start preparing for the press conference.

Final Thoughts

As I said above, we had challenges in all three areas critical to making our plan work: downlink bandwidth, camera exposure, and command timing.  Ultimately, all of the problems we had proved minor, and we collected the data we needed to draw conclusions about the presence or absence of water and other substances in Cabeus crater.

We at NASA all too often strive to give the impression that complex, difficult missions are routine.  They’re not.  They’re complex and difficult.  What makes them possible is long planning, teamwork, and careful review by people both inside and outside the project.  One name for this process is “Systems Management”, which recognizes that people need backup just like the parts of a complex machine.  I personally made some mistakes and caught some mistakes.  Together, we caught enough of them that we were successful.  For me, it was a huge privilege and a wonderful experience.  I’m very grateful to have been a part of this mission.