Memory 01
Beginnings
I came to Sunnyvale, California in late November 1962, and attained program access in March 1963. I was assigned to learn the command subsystem on the satellite, known as the Orbital Control Vehicle (OCV) and, after reviewing all general program documents that were available, I concentrated on the command subsystem documentation and schematics in great detail. I will describe the function of the command subsystem later in this treatise, along with the other vehicle subsystems.
I traveled to the GE factory in Valley Forge, Pennsylvania (where the satellite was designed, built and tested prior to shipment to VAFB for further testing and eventual launch), to interface with design, test, and system personnel to further my training.
I also traveled to Vandenberg Air Force Base (VAFB), California, to interface with our resident test personnel there in the Missile Assembly Building (MAB) # 8310. During prelaunch testing there, I experienced my first look at telemetry from the satellite. This proved very useful after launch, as all vehicle subsystem engineers supporting systems on orbit worked to become familiar with the vehicle health telemetry from their subsystems before seeing the data from the satellite after launch.
A short explanation of vehicle health telemetry for readers not familiar with satellite operations is in order. As an example, when one drives an automobile, they should monitor readings showing the state or value of such things as temperature, gas gauge readings, oil pressure, transmission state such as high, low, reverse and park, along with RPM or tachometer readings on some automobiles, battery performance, and so on.
These are examples of vehicle state and level readings, similar to ones of a satellite vehicle, which were sent down from the satellite vehicle via a telemetry transmission link, and made available to on orbit support personnel to monitor the performance of their respective subsystems.
Stabilization and Control freon and Orbit Adjust propellant subsystem gas readings were among the most important expendables managed and monitored closely on orbit, along with battery voltage, as with these expendables used up over time, the mission needed to be terminated prior to running out of expendables, if possible. Another key expendable monitored and managed judiciously was, of course, the film record on which mission data in the form of pictures taken by the onboard camera payload subsystem were forwarded. This film was moved from a supply reel to a take-up reel during imaging, with the take-up reel being in the reentry vehicle, which was separated from the satellite vehicle (OCV) at the appropriate time at the end of mission operations.
Normally, the reentry vehicle would be separated from the OCV and de-boosted back into the atmosphere for recovery by aircraft snagging the parachute to which the RV was attached, with water recovery as a backup retrieval mode in the event the RV was not captured by specially equipped airplanes. I believe that over the life of the program, the water recovery option was not employed at the end of any missions, or in jargon of the time, none of our RVs “got wet”.
Upon completion of recovery of the RV containing the mission film data, if there was not some problem with the OCV that precluded doing so, then the OCV portion would be de-boosted back down towards earth where it would be burned up on reentry into the atmosphere, with any pieces surviving reentry hitting an ocean area surface of the earth, so the pieces would sink and not be available for any nation to retrieve and study to gain insight into the vehicle and its functioning.
Another reason for de-boosting the OCV portion of the satellite into an ocean area was to prevent the pieces which survived reentry back into the atmosphere from coming down to earth over a land mass and hitting something, or, even worse, have the re-entering hardware treated as a missile attack on some country, friendly, or unfriendly.
As with automobiles, it was not wise to continue the mission too long, use up key expendables, such as attitude control gas, then have the vehicle in an unstable attitude, tumbling randomly when this happened, giving little hope of a controlled de-boost of the vehicle. The same kind of thing could occur if battery power was expended; no power meant no ability to terminate the mission via a controlled de-boost. One needed power to open orbit adjust valves to slow the vehicle down slightly to cause it to reenter the atmosphere! Similar things happen if a driver lets a car run out of gas or battery; control and usefulness of the car is terminated!
When we subsystem and system engineers and our managers traveled from Sunnyvale to VAFB for training and to observe prelaunch testing, usually 2 or more Sunnyvale personnel drove or flew down the coast to VAFB.
During one of my visits, two of us drove down, and during our last day at VAFB, we decided to go down to the blockhouse at the SLC 4 pad, where a simulated launch procedure was being conducted, to observe the simulated launch from the blockhouse near the launch pad. My co-worker from Sunnyvale wanted to stay and observe the entire simulated countdown, but we decided to leave the blockhouse early in order to drive north toward the San Francisco Bay area in daylight, rather than driving after dark.
This proved to be a good decision, because after we left the blockhouse and pad, a huge problem developed at the pad. On the pad, all attached together, were an Atlas booster, Agena 2nd stage booster and the satellite, consisting of the Orbital Control Vehicle, with a Discover reentry capsule (similar to those also used on the Corona satellite program also flying at that time) at the top of the stacked boosters and OCV. The Atlas booster developed a hole in the side, and at that point, the booster contained only air to provide stability. With the air venting out, the Atlas booster bent in half, and the Agena, OCV and Discoverer capsule came crashing down on the pad!! The reentry vehicle, hit the pad first, followed by the OCV, and then the Agena, still all bolted together. This OCV was a non-flight qualified satellite, named 904, and this anomaly thereafter was referred to as the 904 accident.
With the crash, debris was scattered all over the pad, some of which was classified hardware contained inside the OCV, which was then scattered on the pad. This presented a security problem, because in the blockhouse were contractor people supporting the Atlas and Agena boosters, who did not have program access and knowledge of what the payload sensor was doing to acquire mission data. So, the cameras showing scenes on the pad during the simulated countdown were turned off, people were basically locked in the blockhouse and could not leave until personnel with program access went out and removed all of the classified hardware debris from the pad, including, as I heard later, vacuuming the entire pad to pick up ALL debris from the accident. This included pieces of the payload sensor, where one look would have told viewers what the sensor was designed to do.
So, had we chosen to stay at the pad rather than driving North to Sunnyvale, near the San Francisco Bay area, we would have been locked in the blockhouse for several hours, and it was related to me that all the people in the blockhouse got home VERY late that night, many having missed dinner due to inability to leave the blockhouse until the pad cleanup was done.
I am fairly certain that OCV 904 was NOT a flight qualified vehicle; I do not recall that it had undergone thermal vacuum and vibration testing as was required for all other satellite vehicles before launch. I believe that the payload sensor contained inside the OCV which was destroyed on the pad was, in fact, flight qualified hardware, and, I heard later that the hardware was one with extra attention given to the camera subsystem to obtain the best data possible, as the sensor contractor (EKC) felt that for the first launch it was most important to lead with their best product, to try to gain confidence in the new system lest it be cancelled as some other programs had been due to bad performance. The mirrors in the camera system were ground to great precision, to allow the best possible image to be transferred through the mirror system to the film. So, given the history of other programs, it likely behooved the camera contractor (EKC) to lead off with their best possible product on the first flight vehicle.
This disagrees with some released program history, which said that the payload sensor was not a flight qualified sensor. Perhaps someone from EKC, the sensor contractor, can enlighten history with the correct version.
So, a sad LESSON LEARNED was to not risk a high performance piece of flight qualified hardware in a simulated test scenario if it can be helped. I believe the 904 OCV was designed to check out of the ground handling equipment, cabling, test procedures and such without risking a flight qualified piece of hardware. It is likely that other programs probably learned from this tragic accident and took extra precautions to not put prime hardware in harms way during prelaunch testing. To the best of my knowledge, the Agena (2nd stage booster) and Reentry Vehicle WERE flight qualified hardware, and damaged in the 904 incident.