Subsystem #1

Stabilization and Control

The Gambit KH7 Stabilization and Control subsystem provided the capability to point the Gambit camera system tracking mirror at a point on the earth to image the spot on the earth to excellent accuracy and continue the image data gathering as the vehicle moved along its’ orbit. TWO modes of Stabilization and Control operation should be mentioned. The MOST IMPORTANT ONE was in action during imaging, where more precise performance was demanded; part of the time during this activity, the Stabilization subsystem used high thrust valves and fine deadbands. The other mode was in action during the time that imaging was NOT taking place, which was the majority of each 24 hour day. This mode was employed after injection into orbit, and thereafter around the orbit, past tracking stations; it remained in action until imaging was taking place. During this mode, the vehicle utilized coarse deadbands and low thrust valve operation, since accuracy was not as important as during imaging, AND, most importantly, utilized LESS freon control gas per unit time than during imaging. So, the majority of each day the vehicle was on orbit, it was using a minimum amount of freon cold gas per unit time, which was important from an expendables management standpoint; save the expendables to maximize their availability for taking pictures.

The subsystem had Infrared horizon scanners controlling vehicle earth reference, along with rate gyros, gas valves feeding freon cold gas to thrusters and attitude control amplifiers (ACAs), which were configured to provide 3 axis (Pitch, Roll, and Yaw) control when the vehicle needed to be rolled right or left to point the camera tracking mirror for imaging activity, along with pitch and yaw maneuvers when necessary.

One item of interest related to the freon cold gas valves and thrusters is that the Stabilization subsystem schematic showed four thrusters each for the pitch and yaw axes, and eight thrusters for the roll axis, which may give a little more insight into how vehicle maneuvers were performed. The 4 valves defined for Pitch were High +, High – , Low +, and Low –. The 4 valves defined for Yaw were High +, High – , Low +, and Low – . The 8 valves defined for Roll were TWO EACH of High +, High -, Low +, and Low -, with a valve pair likely positioned 180 degrees apart on the 209 bulkhead that, when fired together, torqued the vehicle around the vehicle center of gravity. I had assumed that only the Roll channel had the four High+, High-, Low +, and Low -, and they were needed during imaging activity to roll to point at a spot on the earth as fast as possible, then fire one last valve to stop at the point of interest quickly and not overshoot the aim point. I didn’t think that for pitch and yaw maneuvers that it was necessary to do them and settle quickly as was needed for rolls during imaging, but it appears that the same hardware and logic was employed for maneuvers in all channels.

The IR scanner hardware was part of a gimbaled platform attached to the 209 bulkhead, which was basically the back end of the vehicle, such that if the satellite (OCV) was commanded to roll during mission operations, the roll rotation was basically with reference to the horizon scanners; gimbal action maintained the scanners looking down toward the earth as the rest of the vehicle was rolling.

The (3) axis reference system (TARS) gimbal always tried to stay locked on to the horizon. When required, a roll command signal was sent to the Tars resolvers, which caused firing of the high/and low thrust nozzles to roll the vehicle, as quickly as possible, to point the mirror where needed. When the vehicle rolled, the resolvers would null out the signal, stopping on the angle commanded, and dampen out vehicle perturbations in a VERY short period of time to start imaging with a minimum of smear on each image. The RAGS (Rate Gyro System) used gyro signal information to tell the vehicle alignment, and controlled the rate of change of speed dependent on how great the angle needed. So, when the vehicle (with the tracking mirror inside) rolled to take an image off to the side, the vehicle relation to the Infrared Scanner told how much the vehicle had rolled. Another part of the system was the PREDAC which sent the roll signal and dampening calculations.

I seem to recall that when some of the Stabilization Subsystem engineers talked about how the subsystem worked, they utilized some kind of control theory diagram (Karnaugh type Diagram may have been mentioned) rather than using, as an example, a schematic or block diagram of the subsystem. I have always wondered why the subsystem was called the Stabilization AND Control subsystem, rather than just the Stabilization subsystem. Perhaps the use of a control theory diagram in the design may have led to addition of the word Control to the definition. I don’t recall much about the diagram. There was a graphical layout on it, with, as I recall, position on one axis and rate on another axis. In discussions, Stabilization subsystem engineers would talk about hitting a switching line, which caused a valve to fire to move the vehicle away from a switching line (dead-band?) to a more neutral position.

The IR scanning part of the operation was accomplished by two telescope type devices, one on each side of the scanner platform, looking down below the vehicle, but at a slight angle relative to straight down. One was on the left side, basically at a 90 degrees reference with respect to the line of the center vehicle, i. e., 90 degrees offset from the nominal mission operations velocity vector, and the other one on the right side, basically 270 degrees with respect to the velocity vector. As the telescope type devices rotated, they basically saw an image which part of the time was reporting a cold sky seen and then reporting a warm earth seen. The two scanners were set such that for normal operation, over one rotation, the scanners basically saw a washer type image, and this image, routed to a photocell, then generated a square wave output with the higher output value of the pulse showing the time the scanner sensed warmer earth and the lower amplitude value showing the time the scanner sensed the colder sky.

Each side scanner output was a square wave if transition to earth/sky changes were detected on both heads, indicating the vehicle was probably in a nominal belly down attitude.

One anomaly I recall that produced strange earth/sky readings occurred when, during launch of a vehicle, supposedly, the velocimeter on the Agena booster issued the satellite vehicle separation command too early, which placed the vehicle in a low altitude non-nominal orbit due to the early velocimeter cutoff. During normal launches, it was my understanding that when the velocimeter sensed that the velocity needed for injection into the planned orbit had been achieved, it issued a Separate command to the satellite vehicle, which caused a pyrotechnic to fire and sever bolts in a Marmon clamp holding the Agena to the OCV, freeing the OCV from the Agena booster.

The Agena and OCV were fastened together at the 216 bulkhead, which was the back end measurement of the OCV, which was 18 feet long; 12 inches times 18 feet equals 216 inches.

The square wave outputs of the two scanners were in phase, but during this anomaly, instead of reporting the normal 50 percent amplitude for the pulses, the vehicle telemetry, probably from the POGO revolution 1 tracking station, reported a reading of 70 percent amplitude for earth and 30 percent amplitude for the sky portion of the scanner output. It was deduced the vehicle had been injected to an anomalous orbit due to the early velocimeter cutoff. When the vehicle arrived at the first tracking station on rev 1, tracking data and other observations led to the discovery that the vehicle perigee altitude was approximately 57 miles, and the vehicle would soon reenter the atmosphere due to increased drag at that altitude UNLESS emergency steps were taken to raise the orbit via orbit adjusts. With the IR scanners ‘scope’ angles set for normal operation at around 80 to 100 miles, when the vehicle was quite a bit lower than that, the reduced altitude caused the scopes view to intersect the earth earlier, and report intercepting more earth than sky at the lower altitude.

As I recall, the response to this problem was to generate a command message containing commands for several orbit adjusts spaced out around the orbit. The command message was loaded on rev 2, with the first OA set to occur shortly after fade of the last tracking station on rev 2, followed by several more orbit adjusts on that rev, to add energy to the orbit in order to prevent the vehicle from reentering the atmosphere.

The energy added to the orbit by the revolution 2 OA messages did raise the perigee point, and some mission imaging data was later acquired after recovery from the low perigee condition.

One interesting aspect of this anomaly was that, due to the lower orbit the vehicle was in, the station contact on/off commands, even with two revs worth of ’widening’ at Pogo rev 2 at acquisition and fade for all tracking station contacts led to, as I recall, loading the orbit adjust commands at one of the three stations on revolution 2 using TT&C commands which were actually for one of the other stations. So, the preplanned ‘contact widening’ commands in the padload allowed TT&C visibility and loading during an anomalous time. See a discussion of contact widening in the Command subsystem portion of this history.

The padload command message loaded on the pad prior to liftoff contained commands to turn on the Telemetry, Tracking and Command (TT&C) Subsystems for SCF stations which were in receiving sight of the vehicle as it passed by, allowing the stations to process data from the vehicle and forward the data to the STC for use. Fortunately, all padloads contained station contact commands whose timetags were “widened” by a value (I believe the station contacts were “widened “ an extra 6 minutes on rev 1, 12 minutes on rev 2, and so on) which was increased each rev for a defined time, to allow visibility and commanding should a non-nominal injection cause need for the TT&C components being on, so visibility with the vehicle was available, even for the anomalous orbit. This widening was a standard procedure for all padloads.

In the cases where no square waves were sensed by the IR scanners, or, only one, indicating ONLY one side was seeing the earth/sky transition, the vehicle attitude was NOT good, and it was likely the vehicle had an anomaly, perhaps, but not necessarily in the stabilization subsystem. A vehicle whose IR scanner telemetry data indicated a probable anomaly such as this needed analysis and recovery.

Another anomaly introduced by the scanners occurred during some of the early missions, when, after the vehicle flew over the South Pole cap, and headed toward the North Pole, it was in a non-nominal attitude, due to being fooled by the cold clouds at the South Pole. It would arrive over the next tracking station which was able to track it, and that station would report radar tracking going in and out of lock. This was, generally, an indication of a marginally stable vehicle.

Investigation and analysis, including playback and processing of recorder playback data, led to the deduction that the scanners were fooled by the cold clouds over the South Pole, which caused the vehicle to lose attitude reference and vent freon attitude control gas during valve firing, as it tried to maintain nominal vehicle attitude.

Several things were incorporated to solve the problem. I believe that a switch to a new scanner vendor occurred sometime later in the program. Some customer documentation reported that a switch to Barnes company horizon scanners was done on flight 4.

I also recall that some commands were loaded in the vehicle memory, time tagged to execute as the vehicle approached the South Polar cap. I believe that these commands turned the Attitude Control Amplifiers off, such that no gas could be vented over the pole, and then the Attitude Control Amplifiers (ACAs)s were commanded back on when the vehicle passed over the North edge of the Polar cap, on its way toward the North Pole. So, basically, the vehicle kind of coasted over the pole, with minimum perturbations, with attitude slightly off, and then attitude control regained when the ACAs were then turned back on. This worked.

Another change was to incorporate some logic which disabled valve firings and venting of freon cold gas if both scanners were not seeing earth/sky transitions. This logic would then wait until the scanners had reacquired the earth after random tumbling of the vehicle or other such problem due to some vehicle anomaly. The logic prevented a tumbling vehicle from firing valves to reacquire the earths horizon, and expending all attitude control gas while trying. This logic was called System Horizon Inhibit Transfer logic, (Hor Inh on the Stabilization and Control schematic) and was often referred to as the SHIT box logic in meetings.

I am not sure when the South Pole commanding and horizon inhibit were incorporated into vehicle configurations and timelines. I feel fairly certain that both applications were used later on in the lifetime of the program, perhaps until newer (better) scanners were incorporated.

On one mission, the Stabilization subsystem lost attitude reference periodically, but later regained the reference. One of the theories as to what caused loss of reference was the possibility that during separation of the OCV from the Agena, that, a thermal blanket in the vicinity of the 209 bulkhead was torn loose and could have affected the field of view of the scanners periodically, but long enough to cause loss of attitude reference. I do not recall that the loose blanket piece was firmly determined to be cause of the anomaly; it was one of the items investigated.

On that same 209 bulkhead in addition to the gimbal hardware and Infrared (IR) scanners were the pitch, roll, and yaw control valves and nozzles, along with two hot gas orbit adjust engines thrust chambers. It was a ‘busy’ area of the vehicle during the mission.

I mention the 209 bulkhead area as being a busy area during mission operations, and it was indeed that. As the vehicle rolled to point the payload system at a point on the earth, the roll control valve and nozzles emitted freon gas to roll the vehicle to the needed pointing angle. This angular offset from the nominal “belly down” reference held by the horizon scanner electronics was basically nulled out by valve firings such that when the delta angle was arrived at, valve activity ceased, and camera activity took place with the vehicle control holding the vehicle to a very small rate, to prevent smear on the image taken by the camera system.

The location of the control valves and nozzles on the back of the vehicle on the 209 bulkhead introduced an unplanned effect on the vehicle, namely in adding a slight velocity delta to the vehicle each time the roll valves fired to point the tracking mirror at the point of interest on the earth.

The roll valve output was mainly a torque action to roll the vehicle, but as the freon gas was expended, it expanded not only in the roll axis, but also in ALL directions due to expansion of gas in the near vacuum environment of space. So the expansion of the freon gas PUSHED the vehicle slightly forward along the velocity vector by impinging/pushing forward on the 209 bulkhead. This impulse was small when compared with the roll impulse during the valve firings, but it did affect vehicle position.

This led to strange output when tracking data from stations were used to generate the vehicle ephemeris. Comparing nominal ephemeris predictions with that from the true vehicle ephemeris generated using best fit of tracking data from stations showed strange offset deltas.

Investigation ensued and a comment to the effect that “you guys are really rolling the vehicle at night” led to the discovery that the small delta velocity added to the vehicle was in fact a function of vehicle roll angles and/or valve on time.

So, I believe that logic was added to software processing to account for this additional forward delta velocity incurred with each roll commanded. I believe that code was added to a command assembly software module (GMINT), which added entries in the orbit database (maybe in the Orbit AdJust table, sometimes referred to as the OAJ table,) to add the impingement velocity for each roll. The delta velocity applied with each roll was a function of either roll angle or roll valve firing time.

I think that when yaw reverse was commanded, different logic took over. When the yaw torquers were turned on to rotate the vehicle 180 degrees for upcoming recovery operations, I believe that this was done on a time basis, with torquers on for the time needed to rotate the vehicle 180 degrees, and then the torquers were turned off. I also think that during this time that the electronics knew that the vehicle was yawing, and the pitch orbital rate bias (a nominal 4 degrees per minute causing the vehicle to maintain the belly down attitude each rev) worked such that this pitch rate became components of roll and yaw until the vehicle completed the 180 degree yaw. More about the orbital rate bias later

I also recall that during station contact passes, four key Stabilization and Control subsystem telemetry points monitored were pitch and roll IR computer output (channel 15, sub-comutated points 11 and 12) and pitch and roll torquer motor voltages (channel 15, sub-commutated points 27 and 28), all which in the nominal case should have read about 50 percent bandwidth; if not, then maybe there was an anomaly in the offing. I find it interesting that the first Stabilization subsystem telemetry points monitored for vehicle health were pitch and roll attitude points, and one might infer that perhaps yaw axis readings were deemed not as important?

The design to accomplish the slew and settling activity as the commanded roll angle was approached had some extra logic incorporated in the PREDAC unit, to prevent overshoot past the angle. At the start of the roll to point to a desired angle, I believe that high thrust and coarse dead-bands were commanded, so the roll could be performed at the maximum rate. As the needed roll angle was approached, however, logic switched to, I believe, low thrust, fine dead-bands which allowed the roll activity to fire one last set of thrusters, and stop on the desired angle, at which time the vehicle was ready for imaging. Basically, this was a “get to the angle as quick as possible, stop movement and perform imaging” activity.

MOST SUBSYSTEMS contained an interface to the Telemetry subsystem, to provide subsystem states and temperature, voltage and current data for inclusion into the telemetry downlink, as the vehicle appeared over a tracking station.

FREON COLD GAS EXPENDABLE MONITORING

The amount remaining of the freon cold gas attitude control expendable was tracked very closely during the missions to assure that enough freon gas was available to complete the planned number of days of imaging and have enough freon left to recover the RV successfully and deboost the OCV to have it destroyed on entering the atmosphere so as to not have pieces of space junk for some agency to track . Those responsible for monitoring and reporting the amount of freon control gas left watched two telemetry values, namely, freon temperature and pressure. As I remember, using these two values, they then referenced a graph, which had a series of curves on it, one set being mass versus temperature and another series of curves, being mass versus pressure. The intersection of a curve of a temperature with a curve of a pressure gave the remaining mass of freon cold gas.

I recall that one time, it appeared that the case for having enough freon gas to get to the RV recovery pass after completion of imaging activities was questionable. The person who was on shift covering the Stabilization subsystem noted that using the pressure and temperature values and the pressure/temperature versus mass curves that only ONE telemetry data point value of all samples during the entire station contact, if used, could allow use of one of the curve pairs to declare that enough freon gas was available to complete the mission. The point was likely a wild point, or perhaps an outlier of some kind, perhaps the first value obtained after a loss of telemetry data due to a data dropout. The value may not have been corrupted until it arrived at the ground tracking station, or after arriving in the STC; it could have been a temporary ground data processing and display problem. We will never know whether the value was vehicle generated or ground telemetry data processing introduced.

At any rate, the analysis was challenged, but the Stabilization subsystem analyst stuck to his guns, probably a little nervous until it turned out that there was enough freon control gas to get to the RV recovery tracking station and successfully recover the RV! A gutsy call, but faith in the hardware helped, and, there were not any very good alternatives to continuing on to success. This is one example of the kind of decisions that were made at times; given the limited resources and capabilities, push on!

PNEUUMATICS GAS ANOMALY discussed in Perry History Gambit treatise.

In the Perry History Gambit treatise is seen the text just below, enclosed in quotation marks:

“During separation of the Agena from the orbital control vehicle, a malfunction of the pneumatic system caused a rapid loss of stabilization gas. As a result, the major objective of the solo flight of the OCV— operation of the stabilization subsystem—could not be demonstrated. The OCV was de-boosted before completing any of its’ planned 49 revolutions.”

One interesting personal sidelight related to this anomaly that I was involved with follows. I am quite sure the malfunction was NOT in the hardware; it was a procedural personnel error, as explained below.

Between launches, GE Sunnyvale , California on orbit support personnel would travel to Vandenberg Air Force Base, California, about 250 miles south of our Sunnyvale, California office, to observe prelaunch testing in the Missile Assembly Building (MAB) #8310 of the next Gambit vehicle to be launched. Prior to one launch, three of us from Sunnyvale drove to Vandenberg, and later, met a Vandenberg co-worker for dinner at a restaurant near the base front gate.

One of the three of us from Sunnyvale had transferred from Vandenberg to Sunnyvale, preferring to work flight operations rather than prelaunch testing at Vandenberg. That person and the person from Vandenberg had a loud, long, and heated discussion; the subject was why the person transferred from Vandenberg to Sunnyvale, when the VAFB base personnel were short of cleared workers, requiring them to work long hours.

At a comment “you bailed out on us, when we really needed you” by the VAFB worker, the needling response from the Sunnyvale worker was to the effect that “you didn’t tighten the cap on the freon Shrader valve and all gas was vented to space when the system was activated …”. The VAFB employee had been at the pad when the vehicle freon tank was filled, and answered with a reply, by first asking that none of the three of us should NEVER mention what was said that night, and then stated that “I didn’t touch the valve cap - ____ ____ did, but I took the blame because ___ is a young guy and they would have fired him if they (management?) knew he dealt with putting on the valve cap” or words to that effect. I know that the three other persons present that night are gone, and it is my hope that should anyone (including family and former coworkers of the senior person) not be aware who should have tightened the Shrader valve (sometimes called a Rulon valve), can now be enlightened if they have a chance to read this.

It should be noted that the subject valve cap was similar to ones holding air in car tires, but probably made to more precision specifications to provide confidence that it would not leak in the near vacuum environment of space.

I believe that the freon control gas tank loading was done at the pad, in preparation for launch. The freon tank filling the was accomplished by first closing an Isolation valve, removing a cap from an inlet Fill Valve port, hooking the supply tank to the inlet port and filling the freon tank. When the freon tank was full, the cap was screwed back on to inlet port, but for the filling under discussion, the cap WAS NOT screwed on securely.

The Isolation Valve prevented freon from getting to the control valves; if, as an example, during launch, some vibration occurring as part of the rough launch and ascent environment might cause a valve to chatter open and release freon inside the OCV. This could cause contamination of components and possible electrical shorts, including the Agena, which would still be connected to the OCV. For the mission under discussion, the Fill Valve cap was not screwed on TIGHT ENOUGH, and came loose, allowing the freon to be vented into space out the Fill Valve exit, when the Isolation Valve was commanded open after separation from the Agena, thereby ending the imaging mission before it started due to loss of all of the freon control valve gas.

Another item related to activity at the launch pad may be of interest. Prior to one launch, when the OCV was taken to the launch pad area for mating with the Agena, in preparation for a launch, as the OCV was being taken off a carrier and pulled up the gantry to bolt to the Agena, noises were heard from inside the vehicle which were some kind of debris left in the OCV, which were dropping to the bottom of the OCV. There was always a fear that debris could float around the vehicle when on orbit in a 0 G environment, and cause electrical shorts or worse if one of the particles landed in the wrong spot on vehicle hardware. In Sunnyvale, workers who would work shift supporting mission operations were apprised of the event, and asked to be more alert during station contact passes, in case some debris had caused problems. Fortunately, no problems surfaced; the mission went okay!

I thought that this type of thing only happened years ago, but happened to see a recent report that a similar thing occurred recently on a current program, so time marches on.

I always felt that what I would call “hanger queens” that spent a longer time in ground test, when compared with other vehicles that sailed through ground testing without as many problems, the “hanger queens” experienced less problems on orbit.

UNCAGE YAW GYRO ANOMALY discussed in Perry History Gambit treatise

In the Perry History Gambit treatise is seen the text just below, enclosed in quotation marks:

Its’ effect was to cause loss of yaw reference and a steadily increasing yaw angle. The yaw angle grew at the relatively large rate of 2.5 degrees per hour. Because the vehicle and the cameras were sensitive to yaw angle maneuvers, I do not believe the mission data was usable.

UNCAGE YAW GYRO ANOMALY RECOLLECTIONS

I feel there were some lessons learned in responding to this anomaly; that launch day and part of the next day were long ones, as many personnel were involved in trying to determine what was wrong with the vehicle. Anomaly meetings and extra requests for playback of vehicle telemetry data ensued; very busy Stabilization subsystem personnel finally arrived at the conclusion that the yaw gyro had not uncaged, so an UNCAGE YAW GYRO command was sent to the vehicle and executed.

During this time, personnel were asked to calculate how long the vehicle freon cold gas would last, when, in fact, that was not really an important decision unless the vehicle problem could be diagnosed and corrected. Later, I heard comments from one of the Stabilization subsystem engineers working the problem that they wished they had been left alone to aid in analysis of the problem, rather than DOING freon cold gas calculations. Analysis of telemetry playback data was rampant. It seemed like if one knew what telemetry data was, knew what a Gerber Scanner and Gerber Scale were and how to use them, they were handed a roll or two of paper containing data from a telemetry playback and asked to make it into a more presentable form. Regarding the rolls of paper containing data for analysis using a Gerber Scanner, it appeared that lots of trees were victims that day.

Of course, data from a Cook RTS was the best, because a microwave link between that RTS and the STC allowed transmission of the entire downlink telemetry stream to the STC in Sunnyvale, whereas other stations provided selected data points via the Augie data system, voice reports and even TWX reports, as I recall. Trouble shooting analysts had, for the most part, access to only a limited set of data points, except for data from the Cook tracking station, when the entire downlink data from the was sent to from VAFB to Sunnyvale via the microwave link .

Unfortunately, the Cook tracking station normally had visibility of Gambit vehicles only on revolutions 8, 16, 24 and every 8 revs thereafter due to the orbits the vehicle needed to traverse the earth through in order to maximize image data gathering. On a few missions, I believe the vehicle may have been visible from Cook on a second consecutive rev, such as on Cook rev 9 after also being visible on Cook rev 8, and, later Cook stations in a similar fashion.

Part of the confusion may have been increased by the fact that, unknown to analysts, the vehicle yaw torquers were on, which had the vehicle turning via yaw torquer activity with the vehicle drag increasing and decreasing. Twice a revolution, the nose of the vehicle was pointing 90 degrees from the velocity vector, at which time the cross sectional area of the vehicle was at a maximum, likely causing more valve firings than normal due to the higher drag the vehicle was subject to when yawing away from the velocity vector.

The Stabilization Subsystem schematic shows an input port for the Fly minus (F-) command and an input port for the Uncage Yaw Gyro command; in the schematic, the two inputs are tied together. A diode between the Uncage Yaw Gyro and the common connection point of the two inputs is seen, showing that the F- command could execute by itself, with the diode preventing the Uncage command from executing in that case, no such limiting is seen if the Uncage Gyro command executed. The Fly Minus (F-) command WOULD execute if an Uncage Gyro command was executed.

I recall hearing later that after deciding that the playback data was faulty, another playback of data was requested from the same tracking station for the same time duration. The data was the same as the first playback, and later it was discovered that faulty telemetry reduction (unknown if it was procedural problem or a faulty ground telemetry data reduction hardware or software problem). There were other tracking stations that could have done the second request for playback. A lesson learned was that if data is suspected to be faulty, and the data can be gotten from a second source, that is the avenue to take.

I also heard speculation that a line driver (probably on the 1200 bit data line sending data from a tracking station to the STC) was bad, causing bad data values to be reported. Someone referred to a bad Augie line driver; Augie was the Augmentation Data System used to process telemetry. Again, asking for data playback from anther station would have mitigated this problem. I also heard that the crew on shift at one of the very remote tracking stations was brought back to the station and tasked with obtaining a new set of data, since the first set was confusing. Later, I heard that the RTS crew working our vehicle had also worked some contact passes for another vehicle with an anomaly; this vehicle, because of its’ high altitude and mission, had very long station contacts, and the result was that a VERY tired crew asked to go back to work and provide more data probably SHOULD NOT have been tasked with that assignment!

A lesson learned that day was to NOT just execute one or two commands, UNCAGE YAW GYRO, as an example) without carefully checking the state of the vehicle before and after the execution of a command. In this case, time was of the essence, and maybe the attempted recovery was done too quickly. I do not fault anyone in the decision making seat that day. They likely made the best decision available at the time, based on inputs from others involved in helping in trouble-shooting. More about a typical timeline for handling of a vehicle anomaly requiring some commanding will be detailed later, in a section discussing the handling of anomalies.

At any rate, it was decided to terminate the mission, likely due to abnormal freon cold gas consumption and an ongoing anomaly that was not understood. This preparation for terminating the mission meant deboosting the RV, rather than leaving it in space to be tracked as another piece of space junk and to preclude parts of the RV from reentering the atmosphere later at some unknown place. This required execution of a “Cut and Seal” command, which would cause a knife/bayonet type device to cut the film where it entered the RV, and the bayonet to be imbedded in some material around the entrance of the film port of the RV, making the RV watertight to prevent it from sinking if it was not caught by waiting planes and landed in the ocean. This action precluded any more imaging, as the tension on the film, from the supply reel near the camera to the takeup reel in the RV was irreversibly severed. Loss of film tension was always a worry during missions. Luckily, I can’t recall such a thing happening during the lifetime of the program, except for this unfortunate event.

At any rate, part of preparation for RV deboost was executing the Cut and Seal command, which was done on revolution 16. A short time after that event, one of the Stabilization subsystem engineers who had helped work the problem earlier in the day, and recalled the Uncage Yaw Gyro command had been executed, had gotten off shift, went to bed, woke up from a sleep, sat up, and recalled that the uncage yaw gyro command ALSO commanded an F- (Fly Reverse) command, which had turned the yaw torquers on! He picked up a phone, called the operations area in the STC and told them to turn off the yaw gyro torquers! This was done, but mission operations could not continue due to loss of tension on the film. The RV was deboosted on revolution 34, followed by 49 revs of OCV solo operations, and deboost of the OCV on rev 83.

One interesting nuance of the Stabilization subsystem not well known about was the incorporation of an extra component to the pitch channel electronics. In order to keep the vehicle belly down for the IR scanners to remain locked on the horizon on its’ way around the earth, the vehicle needed to pitch down 4 degrees each minute of the 90 minutes in order to keep the vehicle belly down for the IR scanners to remain locked on the horizon. This was accomplished by a extra resistor in the pitch channel hardware ONLY, and was referred to as the ‘Pitch Rate Orbital Bias Resistor’. After each 90 minutes on orbit, the vehicle would be belly down like it was 90 minutes earlier, only approximately 15 degrees farther west along a line of longitude, due to earth rotation.

Interestingly enough, the on orbit inclination angle for the vehicles launched were never exactly 90 degrees, but were generally in the range of 90 plus or minus 5 degrees, yet the pitch orbital rate 90 degree bias was close enough to the real inclination to keep the vehicle pitching down well enough that further sensing and correction was probably accomplished by the Stabilization electronics.

HITCHUP MODE FOR FIRST 3 VEHICLES

Hitchup was a name coined for a different configuration of the Gambit vehicle employed for the first 3 launches. If one observes a picture of the Gambit vehicle on its’ launch pad, awaiting launch, they would note the Atlas booster attached to the pad, the Agena booster attached to the top of the Atlas, and the Gambit Orbital Control Vehicle attached to the top of the Agena, with the Reentry Vehicle on the very top of the hardware, attached to the OCV. The RV was separated from the OCV at the end of mission imaging operations.

In the hitchup mode, at injection into orbit by the Atlas and Agena boosters, the Agena WAS NOT SEPARATED from the OCV at time of orbit insertion. In the normal (non-Hitchup configuration), at injection into orbit by the Atlas and Agena boosters the Agena WAS SEPARATED from the OCV at time of orbit insertion.

Hitchup mode employed the Agena to provide the attitude control function during imaging operations, with the tracking mirror pointing, basically locked, looking straight down (to nadir) during this mode of imaging operation since the Agena had NO capability to roll to point right or left to image off nadir or to provide imaging capability, which required rolling the vehicle.

Normal (i. e., non-hitchup) configuration employed the Stabilization Subsystem to provide attitude control AND tracking mirror pointing when needed during imaging operations. The liftoff configuration for the normal configuration launch had the Atlas booster providing first stage boost capability, and the Agena providing second stage capability to insert the Orbital Control Vehicle (OCV) into orbit, at which time the Agena would issue a command to separate the Agena from the OCV, After separation, the OCV Stabilization subsystem would be activated and the Agena would fall away from the OCV, the Agena being done with its’ mission.

The hitchup mode of operations were referred to as solo operations and were designed to perform some imaging operations for a defined number of days, then deboost the RV, activate the Stabilization subsystem including enabling use of the freon cold gas, high thrusters, fine deadands, and roll maneuvers, during what might be considered simulated imaging operations. This solo phase, if successful, provided confidence that the Stabilization subsystem could do the mission it was designed to do. I asked myself why the program went through all of the trouble of using the Agena for attitude control for a few launches? Why not use the OCV Stabilization subsystem which was designed for that job? We will never know why, but one could review the history of prior programs and note the problems encountered enroute to arriving at a successful program. As an example, note that the Corona program spent a lot of time getting an RV back on the 13th launch.

I recall seeing a comment in some NRO document accredited to someone high in the program hierarchy who said “just get me ONE picture”, which apparently caused some in the intelligence community, who wanted lots of pictures, to question the comment. Earlier programs may have run into problems where, in attempting to validate some new hardware did not get to do it, as some other piece of new hardware malfunctioned during the test. One could note that perhaps the primary hardware undergoing validation was the Gambit camera system, and not the Gambit vehicle. So, the Agena attitude control subsystem, already proven by use on the Corona program, was employed first to test the camera hardware. Then after successfully taking pictures during the Hitchup mode, the solo portion of the mission using the OCV Stabilization subsystem demonstrated that the Stabilization subsystem could roll the vehicle in minimum time to an aim point, and was likely capable of obtaining good images, but none could be taken during the OCV activity because the film path was severed at the end of Hitchup, prior to RV deboost.

It should also be noted that related to deboosting the RV before the start of the OCV part of the mission, I am wondering how the necessary yaw reverse and pitch down needed before RV separation was accomplished? The OCV Stabilization Subsystem was not activated until after RV separation, so those maneuvers must have been commanded and executed using Agena capability. My first thought was that the Agena did not have that capability, but then I remembered that the Corona vehicles must have performed the necessary commanding and maneuvers to separate the RV when needed, and since Corona used the same basic RV as Gambit, and an Agena for stabilization, it is probable that the RV separation was done as it was done for Corona missions. Perhaps some Corona program person might enlighten us, should they have a chance to read this discussion.

VEHICLE 904 CATASTROPHE AT VANDENBERG

Prior to the first launch, an event on the pad at VAFB may have influenced the hitchup configuration, namely the loss of the Gambit 904 vehicle and most of the hardware attached to it.

During one of my visits to Vandenberg Air Force Base, two of us from the office in Sunnyvale, California 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, 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 Discoverer 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 was unable to provide stability. 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 personnel, some of whom 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 glass from 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 later 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 subsystem 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 high performance pieces of flight qualified hardware in a test scenario if it can be helped. I believe the 904 OCV was designed to check out 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 unless it was absolutely necessary. To the best of my knowledge, the Agena (2nd stage booster) and the Reentry Vehicle WERE flight qualified hardware, and damaged in the 904 incident.

VALVE COVERING WHEN VALVES ENABLED AT VAFB DURING TESTING?

Go to Subsystem 02: Command.