Showing posts with label Apollo 16 subsatellite. Show all posts
Showing posts with label Apollo 16 subsatellite. Show all posts

Monday, February 14, 2022

Impact Analysis


The simulation environment I am using, GMAT, doesn’t know anything about the Moon’s mountains or valleys. When it calculates the altitude of an orbit, that altitude is relative to the “mean radius” of the Moon, somewhat comparable to “sea level” on Earth. So far, in the simulations I have run for the Eagle and Snoopy, that hasn’t mattered, because the orbits of both objects remain high above the surface. But to estimate the location of a possible impact, as for the Apollo 16 subsatellite, we have to do a deeper analysis. In this post I’ll explain how that works. 

Let's start with the big picture. An orbit has become more eccentric…the high point of the orbit has moved higher, and the low point of the orbit has moved lower. On Earth, as the spacecraft began to skim the atmosphere, it would slow down, then burn up, and the heaviest bits might make it all the way to the surface. Since the Moon has no atmosphere, the spacecraft, at the low point of its orbit, can zip past the lunar surface at very low altitude, moving more than a mile per second, and if it misses the surface, even barely, it can continue around for another pass. 

Figure 1: The path of a spacecraft passing low over the Moon's surface

If the Moon were a smooth ball the impact might occur at the lowest approach. However, the Moon is not so smooth. In fact, it is quite rough, with jagged surface features thrown up by countless meteoroid impacts, undiminished by wind or rain. If a spacecraft comes streaking by and strikes the surface, that impact will likely be on a piece of high terrain, perhaps the side of a mountain or a crater wall. To work out the location, we’ll need a good elevation model of the Moon’s terrain. Fortunately, these are freely available, with resolution as high as 512 points per degree, which works out to one elevation point for every 100 feet or so.

We also need the simulator to give us a full “ground track” record, instead of just the lowest point of each orbit. The ground track is a list of latitude, longitude, and altitude points and typically a point is recorded for every 10-20 seconds of simulated time, as in the example shown below. Given that the spacecraft is traveling at about one mile per second, there is a lot of ground between each point. It’s not enough detail to locate the impact exactly, but it shows us the places where the spacecraft is close to the surface…places where we can zoom in for a closer look. As we go through this exercise, we will be zooming in on the points highlighted in green.

Figure 2: Ground track file excerpt. The terrain and "AGL" altitude data (in km) was added by post-processing the output from the simulator.

The first thing we need to do is to “post-process” the ground track file, looking up the height of the surface for each point in the file. For this method I am greatly indebted to a space enthusiast named Daniel Estevez, who ran simulations to try to estimate the impact location of a lunar satellite and posted his results here. I use a modified version of his method, wherein I run two passes on the ground track file.

Step one is to go through the ground track, one line at a time. From the latitude and longitude, we can look up the nearest terrain altitude point in the elevation model. Once we know the spacecraft altitude and the terrain height, we can calculate its “Above Ground Level” altitude. I write out a new copy of the ground track file with the extra terrain altitude and “AGL” data points added to each line, like the yellow values shown in the figure above. To limit the size of the new file I discard any point where the spacecraft is more than 5 km above the surface.

Here is a plot of a ground track file showing two low revolutions of a spacecraft over an area of the Moon. One thing to notice right away, even though this is covering 30 degrees of longitude, or a distance of about 900 km, the "zero" altitude point is flat, and the satellite trajectory curves upward, away from the Moon. This is just to make it easier to plot out the data. I promise the Moon is NOT flat, and the spacecraft is always curving towards the center of the Moon, as in Figure 1 above. The flattening of the Moon for this chart doesn't affect our ability to find the impact point. Another thing to keep in mind is that the vertical scale is greatly exaggerated. This chart is 900 km wide and just 8 km high.

Figure 3: A "flattened" plot of low passes of a spacecraft over the Moon. The area in the green box depicts the values highlighted in green from Figure 2.

Figure 3 allows us to see the areas where the spacecraft is coming close to the surface of the Moon. In particular, the points in the small green box highlight the closest approach visible at this resolution, and the closest point shows a separation of 449 meters above the ground. Given that these two data points are separated by a distance of over 20 km, we need to zoom in and take a closer look.

Figure 4: A "zoomed in" look at the region of the green box from Figure 3. We see that the spacecraft altitude is lower than the terrain altitude at 98.97°. Kaboom!

The figure above shows the zoomed in view. The two red dots are the points from the green box of Figure 3, the same data points highlighted in the ground track file in Figure 2.  What we have done is to make a straight line between these points, and break that line into 100 shorter segments, like the dotted blue line. (This process is called linear interpolation.) For each blue dot we can again look up the terrain altitude and compare it to the spacecraft altitude. Sure enough, in that intervening 20 km between the two red points there was a mountain, about 800 meters tall, and the spacecraft (moving from right to left in this example) strikes it near its top, at around 98.97°. 

How do we know there wasn't another mountain lurking somewhere further to the East? We don't! We have to check. In my code, posted here, I check any time I find a point that is within 3 km of the ground. (I also tried higher thresholds, but 3 km seems to be sufficient to catch all the lurking mountains in my tests so far.)

This is how I have used GMAT to estimate the impact location of the Apollo 16 Particles and Fields Subsatellite, the notorious (in some circles) PFS-2. Now that I have this tool working, I am interested to use it to investigate another Apollo impact. Yes, there is another spacecraft from the Apollo era whose final resting place is unknown...the ascent stage of the Apollo 16 Lunar Module "Orion". As I write these words the 50th anniversary of that mission is fast approaching. Stand by for further updates.

Monday, February 7, 2022

A Reality Check

 What about that Apollo 16 subsatellite?

In this blog I have shown that two Apollo spacecraft were left in orbits that are stable over decades. That’s really surprising and unexpected. Some people have asked if I can simulate an object that is known to have decayed out of orbit, as a reality check, to show that these simulations aren’t out of whack. That’s what we’ll do in this post.

One very notable case is the Apollo 16 Particles and Fields Subsatellite, otherwise known as PFS-2, which decayed out of lunar orbit in 1972 after only 5 weeks in orbit. Weighing just 36 kg, it was jettisoned from the Apollo 16 Service Module not long before the crew left lunar orbit to return to Earth. Originally it was planned to raise the orbit of Apollo 16, so that PFS-2 would remain in orbit for a year. Due to problems during the mission, that orbit change was skipped, and the expected orbital lifetime of PFS-2 was cut down to a few months. PFS-2 was equipped with a transmitter so that it could be tracked, and its data could be sent back to Earth. Only 34 days after it was jettisoned, the transmissions ceased, and PFS-2 impacted the Moon. 

Let’s run a simulation of PFS-2 and see what happens. As with previous simulations we can get the initial conditions from the Mission Report. The Figure 1 shows the data from the report. I believe the report is showing the state of the Command-Service Module (CSM) rather than the PFS-2, but it should be close enough to see if we are in the right ballpark. After converting the parameters to metric and getting them into the right coordinate frame, I get a GMAT script like this one, posted on GitHub.

Figure 1: Showing the initial conditions of PFS-2 from the Mission Report.

For starters, we’ll just record the low point in each revolution, as we have done previously. Figure 2 shows how it looks over time. We see the minimum altitude dropping for several weeks, and then there is a reversal and it starts to rise up again around the middle of May. About a week later the orbit starts to become more eccentric, and the perilune altitude begins dropping again. Sure enough, just 5 weeks after jettison, at the end of May 1972, the low point of the orbit is below the average radius of the altitude...and that is a sure sign that impact has occurred. (The simulator doesn’t check for impact while it is running…it will happily simulate an object that is actually beneath the surface, so we’ll have to look in greater detail to see exactly when and where the impact occurs. I’ll explain how to do that in a future blog post.)

Figure 2: Simulated perilune altitude.

A more detailed analysis of the simulation results gives the location and time of impact, and it comes out as below. Tracking data from the satellite ended shortly after 10:31 PM on May 29th, with an estimated impact at 111° East longitude, and 10° North latitude. This simulation puts the impact about 14 hours later, and about 13 degrees further west. That's not bad! 

Figure 3: Impact times and locations reported by NASA and estimated by simulation

There is another source of information on the PFS-2 initial orbit, at this page. It describes the orbit in a different way, and the parameters don’t completely agree with those in the Mission Report. If we run again with those initial conditions, we get the results labelled “Nominal 2”. This time we get closer to the 1972 estimated impact location and time…impacting about three hours earlier and about 4° more to the west, with the latitude agreeing almost exactly.

In my view, the basic answer is “yes”, these simulations do compare well against reality. We are able to predict the impact of PFS-2 within a few hours of the actual time, and within a few degrees of the estimated location. Considering the uncertainty of the initial conditions, with two different NASA sources that don’t agree, errors of a few hours either way don’t seem too surprising. Having gone through this exercise, I have even greater confidence in the results obtained for Eagle and Snoopy.

By the way, if you are looking for a lunar sleuthing challenge, the actual impact crater of PFS-2 has never been located. This web page states that the original raw PFS-2 tracking data has been preserved, and if you were to obtain that data and fit a simulation to it, I suspect you would be able to map out a very small area where the PFS-2 impact occurred on the surface of the Moon almost 50 years ago. You might be the person to identify the final resting place of the infamous short-lived Apollo subsatellite. Good luck and happy hunting!