Subsystem #2

Command

The Command Subsystem contained a Command Programmer unit, command decoders, and relay boxes, with relays open or closed at command execution time to control various vehicle functions, and probably some units that I have forgotten about.

A key element of the Command subsystem was a crystal controlled oscillator, providing various timing pulses used in various ways throughout the Orbital Control Vehicle (OCV); this oscillator was in a temperature controlled oven, to assure that the crystal output was maintained to a close tolerance, so that pulses generated by the oscillator were of a constant frequency.

One other important part of the Command Subsystem was vehicle clock circuitry. which counted 2000 pulses in 2000 milliseconds to provide a reference for comparison with vehicle time tags stored in slots of the command memory and provide a time at which to output command function bits to task the vehicle to perform imaging operations at the necessary time.

See a later treatise on a problem with the clock oscillator and its’ hardware, under CLOCK OSCILLATOR OVEN FAILURE ANOMALY.

In discussing the Gambit Command Subsystem, I will first discuss the Command Programmer unit, and readers should take note of the technology utilized in the unit, allowing readers to compare the technology of the 1960s with current technology. Of note is that the memory storage available to store uplinked command data for storage and readout later was only 200 memory locations, 50 locations each in 4 delay lines.

The Command Subsystem Programmer unit was composed of 4 magnetostrictive delay lines providing memory storage, each capable of storing fifty commands in the line, with each command being 37 bits long, with 40 bits of storage taken up for each command stored for execution. A full memory was 200 commands, fifty commands in each of the 4 delay lines. The lines were loaded, when needed, by selecting, as an example, delay Line 3 to load; they could be loaded in any order, as will be explained later in command load building, loading and execution considerations.

This Programmer memory was where commands sent to the vehicle from the ground were stored to read out to decoders later and control the various subsystems on the vehicle, including the payload sensor. One 37 bit command, including two parity bits, could be stored in each location. One of the fields stored was a 23 bit clock time, and, command logic used this time tag to compare with a vehicle clock (which was also implemented in a delay line), and when the command time field matched the clock time, hardware logic extracted the function bit portion (minus the 23 bit clock time field, 2 parity bit fields and a 3 bit command type field) of the command to send to decoders for execution. I not sure how the last 3 bits of each 40 bit long command were used, but these 3 bits may have been used during loading, by setting up to 8 states, to denote, as examples, word stored in slot, empty slot that could be loaded if needed, slot being loaded but not all 37 bits of command loaded in slot yet, and, all slots full. See STORED PROGRAM COMMAND FORMATS in an upcoming treatise for more exact command definitions.

Telemetry status for commands loaded was not good, in my estimation. The downlinked value was line full or not full. During loading problems, it would have been better if telemetry would have reported the number of commands loaded in a delay line, so operators would know that all of the commands sent to the vehicle were in fact available to execute. A line report of less than full could mean that 1 or up to 49 commands were loaded in the line capable of holding 50 commands.

The delay lines circulated the 1s and 0s in the form of a twist or no twists, and of the 2000 bits, only 1 bit was accessible to or from the delay line EACH circulation. For placing command data in a memory slot (loading a command received from the ground through the tracking subsystem), or for retrieving command bit data from the memory for output of the command pattern to a decoder for execution, I believe the same circuitry was used. This meant that if a delay line was addressed for loading, readout of command data from THAT delay line and the other three delay lines was not possible.

Basically, the delay line had one bistate logic gate (two states of output, where all data was moved in and out of the line; the other 1999 bits were TWISTS IN A WIRE FOR A ONE, and NO TWISTS FOR A ZERO! This is a change of energy state, electrical to mechanical (an electrical 1 or 0 value changed to a twist or no twist during readin) and mechanical to electrical (a twist or no twist changed to a 1 or 0 logic value during readout). Think of a circus merry go round with 2000 children on it, white shirts being a 0 and blue shirts being a 1. Each circulation you could pull one child off and replace them with the other color if it was desire to change the ‘state’ of that seat on the merry go round from a 0 to a 1 or 1 to a 0. See DELAY LINE INPUT/OUTPUT diagram and discussion later in this treatise.

Some people referred to the delay lines as 'vibrating wires'. As I recall, if you opened the chassis they were in, what was there were wires looped around some ceramic standoffs!

On read out of command data from a delay line, I believe it was sent to a decoder via 3 lines, a 1 or 0 (pulse or no pulse) on one line, the second line with clock pulses, one for each 1 or 0, and a third line was low until it was time to say "the bits just sent down the line to the parallel shift register now need to be executed".

Rather than parallel data transfers, I believe the transfer of data was via serial transfers; parallel data transfers would have taken many more wires to send data from one end of the vehicle to the other end for execution, and the weight penalty associated with parallel data transfers made parallel data architecture undesirable. Three wires sending data in a serial fashion sufficed, and was much more efficient, weight-wise, than having 40 wires to handle command data, including larger connectors holding the wires. The desire was to keep weight at a minimum to allow more weight in the form of several mission critical expendables aboard the satellite.

These mission essential expendables were freon attitude control gas, batteries (no solar arrays), orbit adjust engine hydrazine and oxidizer, and film. We didn't have a big booster to place a vehicle in orbit with a lot of heavy components; what was wanted to be maximized on board were the 4 mission essential expendables mentioned just above, and keep the weight of all other vehicle parts as light as possible.

Before coming to work on the satellite program, I had taken a Packard Bell 250 computer programming course; it used delay lines, so I was familiar with that kind of memory and how it worked.

Now, many years later, note that the amount of memory in which satellite control commands could be stored for later execution was ONLY 200 (50 per delay line times 4 delay lines) slots/locations and the storage media was a delay line. Another section describing the tracking subsystem on the satellite will describe the means by which commands sent uplink to be loaded into the command subsystem memory were processed by extracting the individual command bits (1 or 0) from within the tracking data pulses. This command bit detection and extraction from the tracking pulses ALSO utilized a delay line in its’ implementation. The chief part of this processing was in a unit called the Pulse Position Demodulator (PPD).

One might ask what made use of magneto-strictive delay lines a viable and accepted option for use in early satellite hardware? The decision to use such technology was made before my arrival on the program, but one might speculate that the approach may have had a couple of redeeming features that made it look to be a desirable option. They were because of weight and power considerations, as we have discussed before as the probable reason for choosing a method of implementation, i.e., the mission critical expendables. Task the boosters with lifting into orbit extra freon attitude control gas and orbit adjust fuel, larger capacity or more batteries and more film, and NOT on other hardware if possible.

Power requirements for the memory may have been small, making it a good viable candidate for use. The delay lines were not heavy, again making them a good choice to save weight for putting more mission expendables on board the vehicle to allow for longer missions. I believe the command programmer unit which contained the delay line memory had been utilized on the KH6 Samos Program, so it was probably considered as a space qualified unit, and more readily available than if another memory unit had to be built and, perhaps, qualified for use in space. I have no history related to how the unit performed on KH6.

One other item of note was that near the end of the G program, I heard that there were ONLY two vendors of space qualified delay lines still in business; one was shutting down their production due to lack of orders for the lines, and the second one was considering the same action. The memory for the follow-on KH8 G3 and the KH9 H programs utilized biax core memory. Was the transition to biax core memory storage on the later programs due to lack of vendors for delay lines or upgrade to newer technology for KH8 and KH9?

I supported KH8 and KH9 and some technical customer types were not particularly happy with the amount of power utilized by the Programmable Memory Units (PMUs) due to periodic memory refresh write cycles required on those units. In fact, some time during one of these satellite programs, a switch was made from biax core memory to plated wire memory, which, supposedly, used less power, but the plated wire memory failed during one mission! My discussion of delay line memory was to show what kind of technology we worked with sixty years ago, and made it work. Enforcing the delay line use option, the section on the tracking subsystem also details use of a delay line! Now, many years later, newer technology options obviously exist, but the option used back there was made to work. See a discussion of the tracking subsystem Pulse Position Demodulator (PPD) which is discussed just below, and in the Tracking Subsystem section. It, too, was implemented using a delay line. The memory available on the large Control Data Corporation (CDC) 3600/3800/3804 computers that were used for all orbit ephemeris calculations and imaging message generation was initially, as I recall, ONLY 16 K memory, and later increased to 32K size. I believe that sometime during the program that a fixed head hard drive was added to the computer processing configuration, to provide more storage capability for computations. Cell phones now in use as I write this have more memory than our computing capability had back in those days. There were also magnetic tape drives available for use in computing, so that helped some; software could write computational results to a magnetic tape, and later access the data if need be. This was slow, as a lot of time was spent spinning tape to find a file with the data of interest. The point to consider is that the computers of that time were not as robust as those today, but we managed to use what was available and gather data of value for users.

STORED PROGRAM COMMAND FORMATS

Commands were 37 bits long, stored in 40 bit long slots in 1 of the 4 programmer delay lines, with each delay line capable of storing up to 50 stored program commands for execution when the time bits (1 thru 23) matched the vehicle clock time for readout/execution.

6 of 8 types were single stored program commands (SSPC) formats, with the 37 bit command stored for execution in one 40 bit long memory slot.

2 of 8 types were double stored program commands (DSPC) formats, with TWO 37 bit command bit patterns stored in two 40 bit long memory slots. I believe that one of the two DSPC types defined in bits 25 to 27 of the first word of the DSPC handled the secure word type DSPC, and the second DSPC type handled the command patterns needed for defining long variable fields such as roll angle, film speed and other functions that could not be handled by only a bit or two.

FOR DSPCs, the word following the first 37 bits of the command and stored in the NEXT slot in the delay line was the second half of the DSPC, and contained, except for parity bits 24 and 37, fields defining command functions or crypto key patterns. It was in these type of commands that needed longer fields for variables like roll angles, film speed and such were defined. Also, secure commands (Film Cut and Seal, RV Separate, and Orbit Adjust Engines On) discussed in other parts of this treatise required a secure match on the key contained in the second half of a DSPC, in order to execute the Secure function bits in the first half of the DSPC. These crypto secure word keys were contained in the second word of the DSPC in a command message load. I think this secure pattern was compared with a corresponding secure pattern contained in a secure "plug" containing secure words that was inserted in a port in the command subsystem. The two patterns had to match or the secure commands (Cut and Seal, RV Separate or Orbit Adjust Engine(s) On) were NOT executed.

For these DSPC commands, the field definition for the second word was:

SECURE COMMAND IMPLEMENTATION AND USE required extra handling for certain commands that would be catastrophic to the mission, if executed accidentally. These secure commands (Film Cut and Seal, RV Separate, and Orbit Adjust Engines On) required a secure match on the key contained in the second half of a Double Stored Program Command (DSPC), made up of TWO 37 bit patterns, in order to execute the secure function bits in the first half of the DSPC. These crypto secure words were stored on a magnetic tape kept in a special crypto level safe, and were taken from the safe for all secure loads and read in to the message generation computer as part of the data needed to generate a message needing secure keys. For other messages such as an imaging message load, no crypto data was required.

My involvement in a NO COMMAND FOR 1 ENGINE BURN scenario was probably due to lack of memory on our message generation CDC 38XXcomputer, and led me to modify the command database in a tight timeline to produce an OA message that worked but probably shouldn’t have been created. Basically what was done was to modify the data for Orbit Adjust Engine 2

The Command Subsystem contained an interface to the Tracking Subsystem, through which commands sent from the ground were routed from the Tracking Subsystem to the Command Subsystem for execution in real time, or for storage and later execution.

It also contained interfaces to various other subsystems, necessary at command execution time to route command data to other subsystems as needed to control vehicle functions.

An fairly late program addition was a Power Sequencer, whose basic function was to apply power to logic gates and other components in a controlled manner, to preclude spurious outputs of logic gates and other units when it was necessary to power units up in order to process command data, as an example. I believe that on some of the early missions that, the vehicle experienced Electro Magnetic Interference (EMI) problems that allowed spurious commands to execute, and, as I recall, at least once, one of the memory delay lines was mysteriously erased! It is my recollection that less of that activity was seen after the addition of the Power Sequencer unit.

One interesting and sometimes confusing item that I recall was that one unit of the Command Subsystem was built and furnished by another department of GE; the implementation of the logic in that unit utilized NEGATIVE logic. The rest of the units utilized POSITIVE logic, and so if one forgot that difference, in tracing signals using schematics, and traced a signal into that unit, they likely came up with a faulty result of their signal tracing.

PULSE POSITION DEMODULATOR INTERFACE – DELAY LINE – 1, 0 AND S’s

The Command Subsystem received commands intended for it from the Pulse Position Demodulator (PPD) in the Tracking Subsystem, which ALSO utilized a magnetostrictive delay line, similar to that used in the Command Programmer memory. Implementation of this function for tracking data generation employed a delay line with two taps spaced 26 microseconds apart on the delay line, leading to output of ranging/tracking data uplinked in the form of 2 “goalpost type” pulses 26 microseconds apart modulating a carrier. This goalpost type signature received at the vehicle was (as I understand it) then used to modulate another higher frequency carrier, which was transmitted back to the ground, where the goal post signature and time of receipt was used along with the transmission time of the originally transmitted pulse. The time difference divided by 2 gave, I believe, the distance to the vehicle, i. e., 1 point of ranging data was the result.

Three other taps on the PPD delay time gave commanding information. Between the 26 microsecond taps were taps at 5, 11, and 19 microseconds from the left hand tracking “goalpost”, which provided 1, 0 or S (at respectively, 5, 11, and 19 microseconds) command information. With the detection of the 26 microsecond “goalposts” by sensing twist energy at the 0 and 26 microsecond taps, indicating a valid pair, logic then looked for energy from one of the other delay line taps at 5, 11 or 19 microseconds; “twist” energy at tap 5 indicated a command bit 1 value was sent uplink, tap 11 indicated a command bit 0 value was sent, tap 19 indicated NO command bit was sent uplink, instead an S pulse was sent, which would be seen all the time if no command was going on. If more than 1 of the commanding taps (5, 11 or 19) had twist energy, then I believe that the return was filled with an S pulse, probably denoting a commanding error of some kind, at which the response would be to send S pulses rather than command data bits 1 or 0. I believe that the stopping commanding and sending S pulses may have been trying to prevent another transmitter from taking control of the command link. S pulses would likely prevent anyone from doing that. There was always a fear that another (rogue?) transmitter of higher power might be able to take control.

I wondered if the PPD logic involving insertion of command data in the form of 1’s and 0’s into the tracking envelope was unique to the Gambit hardware or employed on other programs. I believe it was used on other programs based on a sheet I found in my archives which looks like it could have been from an SCF Orientation Course class handout. See the “Radar Pulse Relationships” page just below.

Other programs use of similar tracking (0 and 26 microseconds apart tracking pulses) and commanding hardware (5, 11 and 19 microsecond offset 1, 0 and S command data pulses) could cause problems if vehicles from two different programs were receiving tracking and commanding data at the same time. This could happen if two vehicles were being handled by a station with redundant hardware, with one vehicle being serviced by the A side of a station and the other vehicle being handled by the redundant B side of the station. This interference could be overcome by having 1, 0 and S pulse taps set to, as an example, 7. 13 and 21 microseconds on a second program.

A program that I worked on many years after Gambit employed similar “1, 0 and S” command hardware.

SPOOFS AND REJECTS

Ground commanding software incorporated logic to handle command loading, including when non nominal commanding was taking place. Non nominal command loading could be for several reasons, with one of the prime ones being a marginal link between the vehicle and the ground. Normal command loading would send a command, look for an accept from the vehicle, and, when received, send the next command and continue the “send-accept” routine until the last command in the block has been accepted.

If, after a command was sent, and instead of an accept, a reject was returned from the vehicle, the command would be sent again, and, if rejected, tried again for up to a certain (and controllable) number of times, at which time command would halt and await ground operator intervention. If a command was sent and NO reject was returned after a (probably controllable) time, commanding would be halted, awaiting ground personnel intervention. In the case where a command was sent, and before the time that an accept or reject was supposed to be received, one was received, a SPOOF condition was declared to the ground operators, and, likely, commanding halted. These are only a few of the cases that might be encountered, they represent a few cases that I remember.

I do recall that on at least one occasion, commands were sent without regard to accept or reject information, particularly to a vehicle with whom ground contact was intermittent. Several blocks of commands may have contained the same commands repeated with slightly different readout timetags, with the hope being that one of the command blocks would be received, stored and executed correctly; it was worth a try in a dire situation, perhaps?

701/702 – 125/126 COMMANDING HARDWARE CONSOLES AT ALL STATIONS

Another set of command related hardware used during commanding were the 701 and 702 consoles that were ground hardware that sent commands to the vehicle from tracking stations. The consoles would read punched paper tapes (I believe the tape format was 9 tracks wide, with track 1 or 9 being a parity bit for the other 8 bits in those tracks) and sent 7 bit realtime or 37 bit stored program commands to the vehicle. I believe these consoles were built by GE and delivered to all tracking stations for use. Operators could send Real-Time commands by entering the Real-Time command number and number of times to send it, then directing the commands to be sent. This capability could be used when the EKC personnel needed to be able to move the platen to a Point of Best Focus (PBF). This could be done two ways; they could have a paper tape generated with the number of realtime commands to be sent, or merely have the realtime command number and number of times to transmit set on the commanding console at the tracking station, followed by transmittal of the commands, hence there was no need for a paper tape to be generated and used if the realtime commanding option was used.

In the normal case, the generation of a paper tape containing the number of realtime commands was probably more acceptable, albeit more time consuming and laborious than merely having someone at tracking station enter the realtime command number and the number of times to send it. This method was probably more prone to problems if the wrong command number or number of transmissions of the command was dialed on the commanding console. The paper tape was checked by various people before use and provided a much more controlled event. It would not be positive to dial up a large number of commands to send, which could drive the platen (where the image was put on the film) away from a useful point of best focus. Such a thing could not happen with a paper tape containing a desired number of commands to be sent to drive the platen to a desired point of best focus.

I recall hearing about an incident which scared a person manning the Station Operator Console (SOC) at one of the remote tracking stations. Unbeknown to the operator manning the SOC console, another operator in another room which the operator on the SOC was not cleared to enter was tasked with entering the command number and number of times to transmit the command and hit the transmit button on the 125/701 commanding console at the tracking station.

The SOC operator observed command activity on his SOC and thought that some rogue person, perhaps from an unfriendly nation, was trying to take control of the vehicle command link! The SOC operator did not want to be known for losing control of a vehicle to an adversary on his watch!!

An incident related to me by a coworker was that, prior to the first launch, in supplying engineering support for this hardware for GE, he had gone to the tracking stations, to provide training on the consoles, and help RTS personnel set up the consoles. He related an incident while at the New Boston, New Hampshire (BOSS) station; when he was explaining how the consoles sent command data uplink by injecting command bits between tracking data “goalposts”, a BOSS station worker said “you are out of your mind trying to send command data in the middle of tracking data. That will NEVER work”. History has shown that lots of command data was sent to vehicles over the years using a similar implementation.

I also recall hearing that later in the G program, that GE support engineers went to the tracking stations, made some kind of upgrade to the consoles, and replaced the brass tags on the 701 and 702 consoles with new brass tags renaming the 701 and 702 to being 125 and 126 consoles. After that, some critic said, “you guys replaced the brass nameplates and charged the government a lot of money for it”. I do not know what update was performed on the consoles.

I believe the 126/702 consoles were employed prior to RTS acquisition to set up the accept/reject commanding interface prior to vehicle acquisition and the 125/701 console was employed during the realtime station contact to load command messages.

SELECTIVE ERASE COMMAND

Was a technique developed to prevent a command already loaded in the OCV command memory from executing without having to erase the entire memory delay line, when it was determined that ONLY that command should NOT execute. For purpose of this discussion, let us assume it is known that a command stored in memory delay line 4 in slot 37 should be blocked from executing. Picking one of the other 3 delay lines to erase was done by selecting a line which could be erased and reloaded easiest, generally one which contained commands timetagged to execute several revs from the current rev.

A 1 block message was generated for that delay line, forcing a Selective Erase command to be the first command in the block of commands; then, added were the commands that were in the line that was erased; then the new 1 block message was loaded before the bad command executed. The timetag field of the Selective Erase command was set EXACTLY equal to the timetag of the command it was desired to block execution of, which then occurred due to priority logic invoked by the command readout logic onboard where if there are two commands IN DIFFERENT delay lines with the same execute timetag, the one in the LOWEST line/memory slot would execute, tying up the 200 millisecond readout time in doing so, and the other command was blocked by the execute priority. The 200 millisecond time being usurped to extract the command from memory means that by the time that was done, the vehicle clock will have increased by 200 milliseconds (1 clock tick) and the timetag of the blocked command will then be 1 clock tick earlier, hence the command will not be executed. The function bits of the Selective Erase were, as I recall, a “no op” Timer Reset command.

I believe this was a late add to the program; as I recall, a senior engineer from the factory came West to support an imminent Gambit launch, discussed this Selective Erase capability, pointed out how it could prove useful, and stated that it had been tested back at the factory in Valley Forge. I believe it was utilized over the life of the program.

TIMER RESET COMMAND

This was a useful command; the best use of it may have been when the onboard tape recorder was on to record selected vehicle telemetry data when not sending downlink, i. e., recording between stations and playing the recorder data back at the next tracking station, including during imaging operations. The Timer Reset command would keep the recorder on, gathering more data for analysis when the recorder was played back downlink. I believe that, early in missions, Stabilization Subsystem personnel liked to analyze recorded data, to see how their hardware was performing. One time one of the Stabilization Subsystem engineers commented that each vehicles’ hardware was a little different, kind of like having a mind of its’ own. Some would go a longer time before firing valves and those that did expended less freon cold gas than others.

CATASTROPHIC COMMANDS NEEDED SECURE KEY- OA, SEP, CUT & SEAL

A few commands were dangerous if executed when not planned; they were catastrophic in that instance, and could cause termination of the mission imaging operations. They were the Cut and Seal command, which severed the film at entrance to the RV, and loss of tension on the film meant that no more imaging operations were possible. A second one was the RV Separate command which, if randomly executed, would attempt to separate the RV from the OCV without severing bolts that held the RV to the OCV. The third command in this category was the Orbit Adjust Engines On command, which would cause an uncontrolled orbit adjust to occur, and, a long one without an OA Engines OFF command to stop the engine burn. Normal OA command messages for orbit maintenance contained OA Engines OFF command and an OA Engines ON command, with the time between the ON and OFF command being computed by orbit maintenance software, to add just enough energy to the orbit to raise perigee or move the perigee to give better access to areas needing to be imaged.

See an upcoming section titled SECURE COMMANDING TLC for more detailed information on secure commands implementaton, use, handling and other information which will be all one ever needs to know about that subject.

It should be noted that the OA Engines OFF command was ALWAYS loaded in the onboard memory before the OA Engines ON command, as a safety procedure that also was done with other commands with ON and OFF states. The reason for loading off commands before on commands was that in many cases, if the on command was loaded, and, before the off command was loaded, the uplink command link to the vehicle was lost, the on command would execute and do harm if it allowed some component to stay on, and, cause overheating or burning out of some component, such as a power amplifier, which was not supposed to be left on for more time than needed.

As the number of days of mission imaging operations increased from a day or two to more, the perigee point of the orbit tended to “walk North”, and it was necessary to perform orbit adjusts to move perigee (which was the point on the orbit closest to the earth) back South over the area of interest for imaging operations. This movement of perigee North was the result of the equatorial bulge of the earth at the equator due to centrifugal force (earth rotation?); for orbits such as those flown by KH7, KH8 and KH9 satellites, the walk was about 4 degrees latitude per day toward the North. The best resolution results during imaging were near perigee, due to the range to the desired ground image being best the closest to the scene as possible.

Hence an orbit adjust by execution of the secure OA Engines on command was necessary to move perigee point back South. So, on missions that lasted longer than a couple of days, orbit adjusts were on the mission profile, to move the orbits’ perigee point back South.

The normal orbit adjust command message to handle this included a secure orbit adjust engine ON command and an orbit adjust engine OFF command, with the timetags on the two commands to be executed being computed by the orbit maintenance software.

Worth mentioning is another loading procedure similar to the procedure defining that any Off command should be uplinked and loaded in the onboard command programmer memory BEFORE its’ associated On command. This procedure was invoked when generating a new message for loading a new command message at the upcoming primary load station, with, for instance, a backup load station on the next rev available in the OLD command message to be replaced. Before erasing the delay line containing the old backup station contact commands, the procedure was to erase and reload another delay line with a message block containing the commands for the backup load station.

If, during loading of the new message at the new primary load station (generally 2 or 3 revs past the old primary load station, likely defined on the mission profile), uplink command loading was lost due to some link problem, and the delay line containing the old backup station contacts had been erased and not reloaded, then that station would not see downlink data from the vehicle, since no Telemetry, Tracking and Command (TT&C) commands were in vehicle onboard memory, having been erased and not reloaded at the preceding station.

I believe that the Lifeboat backup subsystem was able to send commands to turn on the primary vehicle TT&C subsystems by sending a secure KIK/ZEKE 32 command pair; once turned on, normal command functions were available. This was helpful if the ground had lost uplink contact with onboard TT&C units. One way this could happen if a memory delay line were erased or randomly erased due to EMI, so station contact commands needed were gone.

CLOCK OSCILLATOR OVEN FAILURE ANOMALY

The Command Subsystem contained a crystal controlled oscillator whose chief output was timing pulses for the vehicle clock which needed to be very constant so that the vehicle clock did not drift with respect to the ground system timing.

To keep the timing constant, the crystal controlled oscillator was in a temperature controlled oven, which made the oscillator output to be of constant frequency. For this one vehicle, the temperature control logic failed. I believe that the anomaly was observed on downlink telemetry, which did not show the normal heater on and heater off cycling seen on earlier vehicles. With that, the concern was that the vehicle clock would speed up or slow down, and this would affect command execution times, making it hard to obtain accurate imaging data which would be taken too early or too late, so the image would be of another point on the earth, instead of the desired point.

There was also a concern that storage and readout of command data from the command memory could be wrong; remember that 2000 pulses were used in accessing command data. What if the pulse repetition rate slowed down or sped up (giving 1999 or 2001 pulses in the 200 millisecond command extraction and execution time? One less bit or one extra bit would mean that an improper bit pattern could be executed.

Fortunately, the clock drift was not large and did not affect imaging data acquisition but might have if the mission had been longer. It should be noted that clock correlation calculations which determined ground system time versus onboard vehicle time offset value could probably have aided in overcoming the problem.

PADLOAD WIDENING

After an “orbit picking” computer program study run presented the best orbit to be used to maximize the imaging data gathered, a detailed mission profile was built, and one of the things it defined was the RTS stations available for contact use after launch. The Padload message created prior to launch contained commands to control (turn on at acquisition and off at station fade) the TT&C (Telemetry, Tracking & Command) hardware units to provide uplink and downlink communication for each of these stations that would be in view of the satellite as it passed by the station.

In the event of an non nominal launch, where the vehicle was placed in a different orbit than planned, the normal TT&C commands would turn on at the predicted acquisition of signals, when the vehicle appeared over the horizon. In the general case, this would be when the ground tracking system antenna would be at a 0 degree elevation angle, expecting to track the vehicle as it rose above the horizon.

But, in the event of an off nominal launch, the vehicle orbit could be such that the vehicle could arrive in view of the tracking station EARLIER or LATER than predicted acquisition time.

So, for the padload message only, I think that the timetags on the station contact TT&C ON and OFF commands were “widened” by turning the TT&C components ON 6 minutes EARLIER than the predicted acquisition time for all rev 1 station contacts, and turning the TT&C components OFF 6 minutes LATER than the predicted rev 1 station contact fade times. The “widening” on rev 2 station contacts was 12 minutes on the acquisition and fade side, 18 minutes on rev 3, and six minutes more for each of the subsequent revs for all contacts in the padload.

In the Stabilization Subsystem section of this document, note that an anomaly discussed detailed the fact that contact “widening” allowed contact with the vehicle when it was sorely needed when the vehicle appeared at a tracking station in a very low orbit on rev 1!

ECHO CHECK

This was a procedure invoked at the time of transmission of commands from a tracking station to the vehicle. As I understood the function, during transmission of a command at the RTS, at the transmitting antenna, an RF probe intercepted the transmission on the uplink signal to the vehicle and recorded it. In the event there was a suspicion that an improper command was sent to the vehicle, analysts could request an echo check playback, and see the bit pattern transmitted. If the correct pattern was transmitted, analysis looked elsewhere for source of a problem. I reviewed echo check data a few times and never found a bad transmission.

NEWLY GENERATED MESSAGES TO RTS AND BACK

Once a command message was generated in Sunnyvale by executing the command generation software, a paper tape was produced for transmission to and use by the tracking station where the command message was to be uplinked to the vehicle. I believe the paper tape was 9 tracks wide, with track 9 being a parity bit for bits 1 through 8.

The tape was taken to a comm center, or, perhaps to a “bird buffer” area, where it was processed for transmission by ENCRYPTING the data on the tape, then the tape transmitted to the RTS, where DECRYPTION took place, followed by punching a paper tape. That tape was ENCRYPTED and sent back to the STC in Sunnyvale, where it was DECRYPTED, a new tape was punched and compared with the original tape. This comparison was done by placing the two tapes on top of each other, aligning sprocket holes, then holding the two tapes up to a light to verify that the holes in both tapes were in EXACTLY identical positions on the two tapes!! This compare procedure could get stressful if the message needed to be blessed as ok to allow the station to be ready to transmit the commands to the vehicle. I do not think that this comparison procedure was ever automated before the end of the program; it should have been.

ALL SUBSYSTEMS contained an interface to the Telemetry subsystem, to provide subsystem states and temperature, voltage and current data for inclusion into the telemetry downlink stream for ground reporting.

HITCHUP MODE FOR FIRST 3 VEHICLES

See Stabilization & Control Subsystem section for Hitchup info.

EXPENDABLES MANAGEMENT

I have mentioned management of onboard expendables in several sections of this document. Basically, careful control over the usage of onboard expendables was done to provide as much of them as possible for use during mission imaging activities. The four expendables were the Stabilization subsystem freon cold gas, batteries onboard, orbit adjust engines hydrazine and nitrogen fuel, and the onboard payload film. The goal was to save all expendables possible for use during imaging operations.

In addition to the onboard expendables, where possible, vehicle hardware weight was minimized; as an example, making units 5 or 10 pounds lighter) allowed for 5 or 10 pounds more of one of the onboard expendables, which could be used for additional mission imaging.

Before readers proceed to an upcoming related section, titled VERY LITTLE REDUNDANCY, try to guess how discussion of this Expendables Management section is linked to the Redundancy discussion. When readers get to that section, I think they will see the two sections could be closely related.

LATE RETROFITS

Worth mentioning are some hardware retrofits that I believe may have been done at Vandenberg rather than at the factory in Valley Forge, Pennsylvania, where most were normally done before shipment of the OCV to VAFB. I believe that the addition of total vehicle current to the downlink telemetry channel 3-13 (using an unused spare channel, maybe?) was a field retrofit that added a valuable tool for use by on orbit vehicle support personnel at anomaly time and during preparation of post flight reports.

This 3-13 channel was normally most important at anomaly time, as it reported most vehicle activity; vehicle maneuvers of any kind caused valve firing reports, door opening and closing were seen, pyrotechnic firings were seen, as well as payload activity including film movement, supply and takeup film reel movement, and camera mirror movements.

If the 3-13 total current data was from a Cook station or from a tape recorded at a tracking station and flown to Sunnyvale, then the 3-13 channel data in its continuous analog form was available, but if he data was from a remote station other than Cook, then only periodic samples were available due to the maximum of 1200 bits/second line transmission rate from all tracking stations.

See the RV section of this document for a case where the telemetry channel 3-13 total current data was used to show that a backup pyrotechnic squib did not fire during separation of an RV from the OCV. It was particularly useful in cases where the vehicle radiated its’ downlink telemetry stream to the Cook tracking station. A microwave link from the Cook tracking station to the STC in Sunnyvale allowed the FULL downlink telemetry stream to be received from VAFB in Sunnyvale in near realtime and processed through ground stations for use by analysts.

Other tracking stations were, I feel, more limited in what data they could quickly send to the STC; data available during a station contact other than Cook for the most part consisted of Augie data provided by the Augmentation Data System telemetry processing software (probably on the 1200 bit lines between RTS’s and the STC), voice reports, reporting groups defined in an Orbital Requirements Document, Station Operator Console (SOC) meter reports and TWX data via a message center. See in the Telemetry subsystem processing and reporting section of that history a sample of Augie Mode data printer output for a station contact using data received from the tracking station via the 1200 bit data line.

Another late add which was likely done at the East Coast factory before the vehicle was shipped to VAFB was the addition of a 3 bit counter to the onboard telemetry tape recorder telemetry, which I personally found of great use when trying to analyze tape recorder playback data downlinked and routed to the STC for analysts use. The counter would increment one count each time the recorder was turned back on after being turned off at the prior recorded segment of data.

Prior to addition of the counter to the recorder playback stream, one had to find a change of value of some recorded telemetry point and then review the command list to determine when the telemetry value of that point should have changed, using the time of execution of that command to arrive at times on other values reported during that record segment. I spent a lot of time viewing tape recorder playback data, and found it MUCH easier to time annotate data when the 3 bit counter (cycling from 0 through 7 each time the recorder turned off and back on) was imbedded in the recorder data.

USE OF COOK TRACKING STATION AT A VEHICLE ANOMALY TIME

On more than one occasion, certain vehicle anomalies led to an interesting timeline of activity when vehicle hardware analysts wished to have a command message generated containing a series of commands designed to troubleshoot the anomaly when they were loaded and executed by the command subsystem. One of the first things that was determined was when the NEXT Cook tracking station was scheduled? The Cook tracking station was normally visible to the G vehicle only twice a day, on rev 8 and every 8 revs thereafter.

So, as I recall, if a Cook station contact was coming up, the goal then was to get the command message generated for loading at Cook or at a station before Cook, if possible, but several things had to happen before that happened. Normally, troubleshooting analysts would arrive at what the sequence of troubleshooting commands should be, generate paperwork defining the sequence on what I believe was called an Opsgram, then get the Opsgram approved and signed by the appropriate people and, finally the message would be generated.

There were some things that could slow down the message generation process, however. As examples:

Was the Cook station available at the time needed, or did another programs’ vehicle have the time scheduled for a station contact? If so, sometimes, negotiations between the two programs likely ensued, with the need for a station to troubleshoot an anomaly sometimes winning the negotiation quite easily. The other program might need the same favor on another time when they were experiencing an anomaly.

Did the sequence of commands needing execution ask for a command not in the current command data base? The list of database commands was limited due lack of memory storage on the CDC computers on which the command generation software was resident. This meant that it was necessary to add a new command to the database, or, modify an existing command bit pattern to the needed new configuration. Modifying an existing command pattern was risky; what if that command was called out for use in another sequence of commands where the old command definition was needed? Modifying or adding a new command to the database took time to assure the command was correct for the new intended use, and perhaps the acquisition time of the next Cook RTS pass was too close to prepare a message and get it loaded for execution at Cook.

I seem to recall an event when two command generation workers were perusing a list of commands in the generation software database, one reading the command descriptor from the new Opsgram (official name of osgram may have been Government form Modification Transmittal Memorand or MTM for short) and the other one trying to find an existing command matching the Opsgram descriptor in the command database. They thought they finally found one and selected it for use in the new message to be generated. The command data base listing was printed out on wide paper, which allowed 120 (may have even been 132) characters on a line.

Part way through the generation cycle someone noted that very near the 120th column for the command they planned on using was a state defined that was NOT wanted; I believe it was some state related to Stabilization Subsystem torquers which would have been a harmful state to allow to be set. So, I believe the message generation was stopped. I do not recall what happened after, but whatever it was it was probably NOT positive. Limited memory available precluded having more commands defined certainly contributed to this event!

VERY LITTLE REDUNDACY

The Gambit vehicle had almost no redundant hardware to switch to in the event of an anomaly.

I think that one time the gambit bay heaters didn’t turn off and a runaway heater was reported. It was switched out of use, in favor of a good backup heater.

The RV subsystem section of this document describes an anomaly wherein a redundant pyrotechnic squib failed to fire to separate the RV from the OCV at RV deboost time. Fortunately, the primary pyrotechnic circuit DID execute successfully, saving the day!

I believe that one of the main reasons for lack of redundancy may have been the weight penalty that would have been incurred in adding redundant(backup) hardware to the Gambit vehicle. Backup hardware addition would add not only a duplicate of some primary hardware components, but there would be a need to add cabling to use the redundant hardware. This could include power, and, perhaps input and output signal routing, in addition to a telemetry reporting interface.

These interfaces all add weight and complexity to the vehicle. Another large change would be in adding of switchover relays to switch a failed component out and switch a good backup component in its’ place, likely requiring addition to the command repertoire and, perhaps, new relays in a relay box to make it all work.

If one cannot overcome a failure on the vehicle and switch to a backup unit that could not be on the vehicle due to weight limitation on what the boosters could inject into orbit, then one must look at what can be done on the ground to enhance the probability of less failures on orbit.

Selection of higher reliability parts (if available, and likely more expensive) for use in building the OCV would have enhanced the chances of not having a failure occur, but, I don’t know if that action was taken. Way back in time, someone discussed the procedure for ordering and testing incoming parts with me. There appeared to be more than one level of parts that one could order, and the incoming quality control checking was different depending on how the parts were to be utilized. As an example, one could order 100 resistors for use, and on arrival, do a detailed inspection of all 100 of the resistors, or do a detailed inspection of a randomly picked set of 10 resistors for inspection, i.e., only check 10 % of the incoming lot. One might use the 10% sampling technique on parts ordered for use in an item such as a refrigerator, TV, or automobile, as it is much easier to replace parts on those items, but probably NOT on a satellite 80 miles in space!

Rigid and thorough quality control procedures also should provide a better product, too. In some old NRO documents, I noted that my employer was faulted for poor quality control on products delivered for the program, and did, I believe, improve quality control. I never was aware of that quality control issue until recently, and never heard any of my coworkers on the West Coast mention it, either. On reflection, I think it was better that the on orbit support crew did not know of the QC issue.

My only thought is that we took what was launched and worked hard to use the vehicle to get important data to users asking for it. I believe that is what all the Gambit on orbit crew tried to do.

Having worked on Request For Proposals (RFPs) for later systems, I would love to see the RFP for the Gambit vehicle to see if it mentioned weight limitations, redundancy requirements and a myriad of other related items such as a power bogey.

      
            
209 BULKHEAD HARDWARE
GIMBAL PLATFORM, IR SCANNERS, FREON GAS, Pitch, Roll,
Yaw VALVES and THRUSTERS, OA ENGINES, 
GYROS (IRU) 
FREON TANK AND OA HYDRAZINE AND N2O4 TANKS ON BACKSIDE? 
 	
DEFINITIONS FOR LAYMEN

STATION PASS RELATED PARAMETERS – STATION ACQ, MID PASS AND FADE
CONES, OBSCURA, LINKS, ACQUISITION REPORTS 
	LOCK, PAINT
	CONICAL SCAN, PASS
	UPLINK, DOWNLINK
GROUND TRACE, INCLINATION, Q
	PERIGEE, APOGEE, PERIOD
	VELOCITY VECTOR, DEBOOST, MARMON CLAMP 
	YAW REVERSE, PITCHDOWN/PITCHUP 
	CRAB, STEREO, STRIP 
	 
STATION PASS RELATED PARAMETERS – STATION ACQ, MID PASS AND FADE
	CONES, OBSCURA, LINKS, ACQUISITION REPORTS
	LOCK, PAINT
	CONICAL SCAN, PASS
UPLINK, DOWNLINK
GROUND TRACE, INCLINATION, Q 
PERIGEE, APOGEE, PERIOD
	VELOCITY VECTOR, DEBOOST, MARMON CLAMP 
YAW REVERSE, PITCHDOWN/PITCHUP
	CRAB, STEREO, STRIP  

LAUNCH TRAJECTORY AND REASONS FOR

DATA LINES AND MALFUNCTIONS THERETO
See RV Subsystem section for discussion of data line problems.

TLM PROCESSING AND REPORTING 

GROUND CONTROL SOFTWARE

ON ORBIT TIMELINES – PUSH TO SHORTEN 
	
FOURTH SHIFT AND ITS’ IMPORTANCE
	MCD, BFE, CLOCK CORREATION AND DAILY REPORT

MISSION PROFILE GENERATION

TOOLS PRELAUNCH EXECUTION TO PICK ORBIT

RTS’S FULFILLING UNIQUE NEEDS
	
POST FLIGHT REPORTS – 5 AND 30 DAY 

SECURITY NEEDS AND HANDICAPS

COMPUTER SYSTEMS

CONTINGENCY PLANS IF POWER LOST IN STC

GROUND STATIONS – RTS, SCF AND VAN

COMMUNICATIONS 

MESSAGE PRINTING AND DISTRIBUTION

RTS TLM TAPES – COURIER & HAND CARRY 	

ANOMALIES – TO WALNUT AND TIKI ROOMS

FIRST AUGIE TLM DATA

CREW CROSS FERTILIZATION VS SAME SHIFT

CARDS TO ENT BY MISTAKE

GENERAL ANOMALIES 

	Hung up in a Delay Line
 
	BATTERY LOST
	9.28 VS 4.47 SECONDS PADLOAD 			TIME ERROR
	DOOR BLOWN OPEN-BAD 					THERMAL STATE
	COMPUTER PREARM
	Clock Oscillator Oven Failure

PREPRESS BRIEFING AND OTHER 
	GROUPS ATTENDING
	SUBJECTS
	PASS PLAN APPROVAL
	PASS PLAN CONTENTS AND SAMPLE

SUPPORTING GROUPS

201 EFFECT 

209 BULKHEAD

209 BULKHEAD HARDWARE 
	GIMBAL PLATFORM, IR 			SCANNERS, FREON GAS, Pitch, Roll, 	Yaw VALVES and THRUSTERS, OA 	ENGINES, GYROS (IRU) 
FREON TANK AND OA HELIUM, 	HYDRAZINE AND N2O4 TANKS ON 	BACKSIDE? 
 	
1963-1965 PRELAUCH EFFORT INCLUDING REHS

1965-1967 PRELAUNCH EFFORT INCLUDING REHS 

REHEARSALS
	REHEARSAL CONDUCTION
	ANOMALIES TO TEST SYSTEM AND PROCS


=========================================


COMMAND SUBSYSTEM
	1, 0 AND S’S – PPD – DELAY LINE
	COMMAND INFO BETWEEN TKG 			PULSES
	125/126 – 701/702 COMMANDING 			HARDWARE
		TAPE OR DIAL TYPE AND 					NUMBER
		BOSS STATION COMMENT
		RELAY BOX, DECODERS
	SELECTIVE ERASE 
	SPOOFS AND REJECTS
	POWER SEQUENCER AND TUROFF 			TIMER
	SSPC/VSPC COMMANDS ALSO 				RTCS
	CERTAIN COMMANDS 				NEEDED KEY
	4 DELAY LINE MEMORY 2K EACH 			50 X 40
		I/O TO MAGNETOSTRICTIVE 				WIRE
		DOWN TO 1 VENDOR AT 						PROGRAM END
		VENDOR STOPPING 							PRODUCTION
	OFF CMDS LOADED BEFORE ON 			CMDS				
	ECHO CHECK
	PAPER TAPE MESSAGE TO RTS 				AND BACK
	
TELEMETRY SUBSYSTEM	
	PAM/FM, CONTINUOUS, AND COMMUTATED
	3-13 GOOD ADD FOR TROUBLESHOOTERS
	TAPE RECORDER AND PLAYED BACK
		PB CONFUSING SO 3 BIT COUNTER 
	MULTIPLEXERS, SCOs 
	TRANSMITTERS

TRACKING SUBSYSTEM
	1, 0 AND S PULSES – PPD – DELAY LINE 
		BETWEEN 26 US TRACKING GOALPOSTS
	1 & 0s TO COMMAND SUBSYSTEM
	UPCONVERTERS TO RETURN TKG 			PULSES
	RECEIVER AND TRANSMITTER

POWER/THERMAL SUBSYSTEM
HEATERS AND BATTERIES – PASSIVE THERMAL CONTROL VIA 	PAINT?
EAGLE PICHER BATTERY 	SUPPLIER
	SQUIBS/ETC – HARD TO TEST 				PRELAUNCH
		SCR USED TO FIRE – HI 						CURRENT SCRs

MECHANICAL SUBSYSTEM
	DOOR LIM SWITCH VS POTENTIOMETER
	HARD TO TEST IN 1 G AND NOT 			HURT HW
	PEOPLE PLAYING GRAVITY AT 				VAFB
	OUTER DOOR & INNER DOOR
	OUTER DOOR ANOMALY – PYRO CHANGE
	MAGNETOMETER BOOM CONTROL/PROTECT	

SENSOR SUBSYSTEMS (2)
	PRIMARY GAMBIT AND SECONDARY SIC

OA SUBSYSTEM
(SECURE COMMANDS TLC (Took Lots of Care)    


	2 ENGINES - HYDRAZINE AND 				N2O4
	ENGINES ON VIA SECURE 					COMMANDS
	THRUST ALIGNED THRU VEH CG - 			HARD

	SQUIBS/ETC – HARD TO TEST PRELAUNCH
		SCR USED TO FIRE – HI CURRENT SCRs

SECURE PLUG - PRELAUNCH MSG 
	TO VERIFY SECURE WORDS FROM
	CRYPTO TAPE MATCHED SECURE
	PLUG VALUES-ALL 3 PROGRAMS?
DEFAULT PATTERN JUMPER UNTIL 	REAL PLUG INSERTED LATE IN 	VAFB TEST CYCLE ?

RV SUBSYSTEM 
	ADAPTER, SEP, ROCKET & RCVRY 			PROGRMR
	SECURE COMMANDS CUT/SEAL 			AND SEP
	DETAILED TIMELINE THEN ANOMALY ONE
		SCARY
	TRAWLERS TO 18 THEN 34
	YAW REVERSE – PITCH DOWN 				FIRST

	LIFEBOAT BACKUP
	RCC C119 OILCAKE REPORTS EVENT #S
	1 OF 2 SETS OF SQUIBS DIDN’T 				FIRE
		PROVEN BY 3-13 TOTAL CURRENT 
	RV DRAWING RED/BLACK LINES
	NO OCV DOWNLINK AFTER RETRO 		ONCE
	SEPARATION PLUNGERS WITH 				SPRINGS
	TLM VERIFY AND TIPOFF RATE
	RECORD THRU IONIZATION 					BLACKOUT 
		AREA AND PLAYBACK LATER 
	MISSING RV BEACON TURNOFF WRENCH
	BEACON ON WHOOPING TO EAST?
	BALANCING AT VAFB FOR SPIN 			CONTROL
	WEIGHT IN BOTTOM, BBS TAPED 			IN
	SOME RVS REFLOWN
	RECOVERY AIDS 
		WHOOPING BEACON TO DF, 				LIGHT, DYE,	ORANGE CHUTE
		SIGNAL STRENGTH/DIRECTION 			HELPED
		SINK PLUG 40 -0/+32 HOURS 					THEN SUNK	
RECOVERY TIMELINE 
		HARDWARE/SOFTWARE
		NOMINAL AND NON-NOMINAL EVENTS
		DEBOOST COMMANDS/ETC 
		BLACKOUT AND PLAYBACK
		RCC/OILCAKE FUNCTIONS & REPORTING

LIFEBOAT SUBSYSTEM-BACKUP RECOVERY USE
COULD OPEN PRIMARY COMMAND LINK VIA KIKZEKE 32
	ZEKE, KIK ZEKE, GAS, TIMER
		KIK/ZEKE 31 SECURE COMMAND STARTS RV DEBOOST TIMER 	
		0 AND 5400 SECS THEN 90 SECS USE
	3 AXIS MAGNETOMETERS REQUIRED 
	PRIMARY GAS DISABLED
	OCV DEBOOST AFTER RV SEP ?
	DESIGNED TO CAPTURE AND 				DEBOOST TUMBLING VEHICLE

HITCHUP MODE FOR FIRST 3 	VEHICLES
	LIMITATION INCURRED NADIR ONLY
	POST RV RCVRY, FLEW A NEW MISSION 
		BATTERY AND GAS SAVED FOR SOLO 
		CHECK OF OCV 3 AXIS STAB
		CHECK OF OCV DEBOOST

EXPENDABLES MANAGEMENT TREATISE
	BATTERY POWER, ATT CNTRL GAS
	OA PROPELLANT – PROB NOT AS IMPORTANT
	RECORDING MEDIA

FIELD RETROFITS

VERY LITTLE REDUNDANCY

209 BULKHEAD HARDWARE
GIMBAL PLATFORM, IR SCANNERS, FREON GAS, Pitch, Roll, YAW VALVES 
AND THRUSTERS, OA ENGINES, 
GYROS (IRU) 
FREON TANK AND OA HYDRAZINE AND N2O4 TANKS ON BACKSIDE? 
 	
LAUNCH TRAJECTORY AND REASONS FOR
	POLAR ORBIT– METHOD
	VELOCIMETER, MARMON CLAMP
	SKIN TRAK - FIRST ALERT ON ORBIT
		4 PIECES REPORTED BUT OK LATER
		GOOD ORBIT PREDICT GRAPHS/TABLES
		COMMENT BY GENERAL
	ATLAS AND AGENA BOOSTERS 
	PADLOAD WIDENING FOR BAD INJECTION 

DATA LINES AND MALFUNCTIONS THERETO
		COULD BE TAP ADDED & NOT DETECTED
		TRAWLER CUT LINE 5 PLACES ON THURS
		EXPENDABLES GONE IF NOT FIXED ASAP
		ALSO SINGLE BREAK AT LEAST ONCE	

TLM PROCESSING AND REPORTING
	AUGIE (MODES), VOICE, STRIP CHARTS
	SOC CONSOLE, ORD GROUPS
	RTS GND STA DECOM & REPORT POSTPASS
		ONLY AT ANOMALY TIME?

GROUND COMMAND AND CONTROL SOFTWARE
	GENIE TOSP TMPGP GMINT GCONTACT
		GCOMMAND – FIRST VERSION
	TPREP TPAT TMOP AND??? – LATER VERSION
	DECK LISTINGS USED AND REVIEWED
	ALTER MODE
	MESSAGES TO RTS’s RETURNED & CHECKED
	IRT 2 9 11 AND RUNNUM	

ON ORBIT TIMELINES – PUSH TO SHORTEN 
TIMELINE CRUNCH

FOURTH SHIFT AND ITS’ 	
	IMPORTANCE
		MCD, BFE, BEST FIT 				CLOCK AND 						DAILY REPORT

PREPRESS BRIEFING AND OTHER - ATTENDEES

MISSION PROFILE GENERATION
	MANUAL GEN – LOAD STAs & SPANs PICKED
	RUN DECKS WITH SPANS SET DURING REHS
		BAD INJECTION RUINED PROFILE/DECKS
	LOAD DECK – SAMPLE
	MISSION PROFILE – SAMPLE

DAY IN LIFE USING MISSFION PROFILE
	MESSAGE UPDATES HARD W/ANOMALY

TOOLS PRELAUNCH EXECUTION
 	PI SEARCH INPUT AND RESULTS
	RESULT PICKED ORBIT FOR NEXT MISSION
	THEN FULL NEW DECK FOR NEXT USE	
	ONE HIGH PRI MAYBE FROM OTHER ORG
	AND MAYBE AFTER 1965

RTS’S FULFILLING UNIQUE NEEDS
	COOK, POGO, HULA

SPECIAL PAYLOAD ISSUES
	CORN EXERCISES - SKETCH
		SLEEPING GND SUPPORT, PLANE SEEN
	SNOW EVENTS
		MANUAL DOWN N STOPS ON FEW IDs
	SPECIAL COLOR/UTB HANDLING
	 	GOOD GLUE
		FINE/COARSE TLM USED TO SCHEDULE
	PLATEN PBF FINE/COARSE TLM
		VIA RTC AND SPC
		RTCS FROM STATION PANICKED SO
	DAILY WX CARDS - LAT/LON/REV SAMPLE
	ALGORITHM SAMPLE 
	MINI OAs
	PET TEAM
	CLOCK TIME ON EDGE
	OAs FOR PERIGEE LOCATION CORRECTION
	INPUT CARDS 80 COLUMNS
		FIELDS AND DESCRIPTIONS

POST FLIGHT REPORTS – 5 AND 30 DAY 

SECURITY NEEDS AND HANDICAPS

COMPUTER SYSTEMS
	SST AND AMT WITH CORRECTOR DECK
		91 VERSUS FEW LEGAL ONES
	BIRD BUFFER, 160A AND OTHERS
	COMPUTER DOWN & SWITCHING SYSTEMS
		MAINTENANCE AND COMPUTER PROB
	CLEANING AREA WHEN GIVING UP SYSTEM
	UNCLEARED OPERATORS EARLY ON 
		THEN LIST 2
		LTAB CORRS BUT NOT USED
		CDC160 PRINTED OUTPUT
	TAPE DRIVES AND LATER REMOVABLE DISK
	CARD PUNCH INCIDENT BROKEN BELT
	PRIIORITY ON COMPUTERS 
		OTHER PROGRAMS AND CALL TO PENTAGO N 

CONTINGENCY PLANS IF POWER LOST IN STC
	SIMULATED TO PALO ALTO, ALMOST TO LA
	NEXT SHIFT WAS TO REPORT TO MOFFETT 
	ADVANCED MAN TO LA ONCE, STAFF CAR
	BACKUP POWER GENERATORS EARLY

GROUND STATIONS – RTS, SCF AND VAN
	MICROWAVE LINK FROM VAFB

COMMUNICATIONS 
	BACK LINE, TROPO SCATTER, 1200/2400 BIT DATA LINES, TTY 

MESSAGE PRINTING AND DISTRIBUTION
	DATA HANDLERS, DECOLLATE 6 PART
	160A PRINTER FROM SO TAPE, NOT ON SYS2X
	1ST 2 TO TA, 1 TO 10A

TAPES – COURIER HAND CARRY 	
	ARMED SURVEILLANCE
	ALSO USED PO BOX FOR ALL DOCS
		USING REGISTERED MAIL
		PO BREAKIN 
		PO BOX LOCATION CHANGED 

ANOMALIES – TO WALNUT AND TIKI

FIRST AUGIE-NOT ROBUST 1ST FEW FLIGHTS

HANGER QUEENS VS CLEAN TEST CYCLE
	VAFB DROP TEST, BB’S HEARD

CREW CROSS FERTILIZATION VS SAME SHIFT

CARDS TO ENT BY MISTAKE

GENERAL ANOMALIES
	CONTACT PROBLEM MEANT LEFT 
		STATION WITH DOWNLINK ON		
		OVER BAD AREAS
	BATTERY LOST
	9.28 VS 4.47 PADLOAD TIME ERROR
	DOOR BLOWN OPEN BAD THERMAL STATE

PREPASS BRIEFING 
	GROUPS ATTENDING
	SUBJECTS
	PASS PLAN APPROVAL
	PASS PLAN CONTENTS AND SAMPLE
	STATION BRIEF BEFORE VEHICLE ACQ

SUPPORTING GROUPS

201 EFFECT

1962-1965 PRELAUNCH EFFORT INCLUDING REHS

1965-1967 PRELAUNCH EFFORT INCLUDING REHS

NETWORK

REHEARSALS
	REHEARSAL CONDUCTION
	ANOMALIES TO TEST SYSTEM AND PROCS

Go to Subsystem 03: Telemetry.