Sponsor Message:
Military Aviation & Space Forum
My Starred Topics | Profile | New Topic | Forum Index | Help | Search 
My Life With STS-107  
User currently offlinecornutt From United States of America, joined Jan 2013, 338 posts, RR: 0
Posted (2 years 2 weeks 2 days 10 hours ago) and read 8933 times:

In the thread about the tenth anniversary of the Columbia accident, I promised I'd write something about my experiences with that flight. I spent four years working on preparation for that flight on the SPACEHAB Research Double Module project, doing systems development, payload integration, and operations development. And during the flight I was the lead SPACEHAB COMMAND console operator.

Herewith are some of my experiences. As you all know, it's a tale that unfortunately ends in tragedy, but along the way there was comedy, success, failure, adventure, long long hours, sex (none experienced by me, unfortunately), drunkenness, the occasional misdemeanor, and quite a few garlic rolls.

First, a bit of background on me. First: my dad worked on the Mercury-Redstone and Saturn launchers, as a contractor at NASA-Marshall Space Flight Center, and the Army Ballistic Missile Agency before that. I was born in Huntsville, home of MSFC, at a time when the total population of the town was only about 15,000 -- I'm one of the oldest Huntsville natives living here presently. I spend my early childhood years around rockets and space stuff. Wehner von Braun's son Peter was one of my school classmates, as we the children of engineers and managers who worked for MSFC and the big contractors of the Saturn program like Boeing, Douglas, IBM, and North American. However, Dad left the engineering field when President Nixon announced the termination of Saturn V production in 1969. We moved and the space program receded from me. I discovered computers in high school, and after college I went to work for a computer company in South Florida. I never saw myself working in the aerospace business.

That changed in 1988. I had moved to New Jersey to work for Bell Labs, and was hugely disappointed; the post-divestiture Labs was nowhere near living up to its historical reputation. I got an interview with a small contractor that supported the Huntsville Operations Support Center at MSFC. I got heavily involved in designing the control center systems for the International Space Station Payload Operations Integration Center, and in operations development for the Spacelab program. In 1996 that company become a sub to Lockheed Martin, and not liking that situation, I went to another small contractor that was building experiments to fly on the Mir space station. I did software development for that and other projects, and I also managed all of the flight ops and crew training for those experiments.

When that company ran out of money in 1999, after a short stint as a freelancer, I signed on with Boeing to work on the SPACEHAB RDM program. Here's how that deal worked: There was a company called SPACEHAB Incorporated (we usually referred to it as "Inc"), whose CEO was ex-astronaut Mike Lounge. Inc was basically a marketing company for space flight services; they had the idea for pressurized, inhabitable modules that could fly in the payload bay of the Shuttle and be used for a variety of purposes. They had made some money selling logistics flight services to NASA. But around 1998 they had perceived that there was still a market for the type of shorter-duration (compared to going to ISS) payload flights that Spacelab used to do, So they set about constructing the Research Double Module; the "reserach" part was supported by extensive payload services (power, cooling, pressurization, gas supply, vacuum, data, and crew services), and the "double" part came from the fact that the RDM was made of two of the normal Hab modules mounted front to back. The whole arrangement was connected to the Shuttle middeck hatch via a tunnel made in part from leftover Spacelab hardware.

Anyway, Inc was not an engineering company. So the contracted with McDonnell-Douglas to do all of the engineering and technical work -- design the hardware and software, get it built, integrate it, and fly it. McDac assigned that work to its office in Huntsville, where the engineering was done, with the hardware and integration being done at the SPACEHAB Payload Processing Facility (SPPF, pronounced "spiff") in the port area of Cape Canaveral, just south of the entrance to CCAFS.

In 1999, the merger of McDonnell-Douglas with Boeing was proceeding, and when I started with Boeing in April, the SPACEHAB program had just been moved to Boeing's facility in Huntsville. A lot of the Hab program employees were none too happy about it, because the McDonnell-Douglas offices they had vacated were pretty nice, whereas the space they had been moved into was pretty crappy. It was an area in building 48-19, the oldest building of the Boeing complex in Huntsville, that had been sitting empty and disused for a number of years. Additionally, their previous offices had been in the centrally located Cummings Research Park, whereas the Boeing complex is on the outskirts of town, a long drive for some employees, and not conveniently located for running errands during lunch. And further, there was a widespread belief that they their retirements had gotten shafted in the conversion of their McDonnell-Douglas stock to Boeing stock.

I had gotten the interview via the efforts of electrical engineer Dean Hallmark. (I'm going to be naming some names throughout these articles, as I think that the people involved deserve recognition for their efforts.) Dean's wife had been friends with my wife since long before either of them married either of us. Dean knew that I had experience in telemetry and command systems, and payload ops for manned spacecraft. Dean had written the original version of the software for the system that processed the Hab module's telemetry, and he was the master and guru of a diabolical device known as the Data Management Unit, or DMU. The DMU was the telemetry and command formatting unit for the Hab modules; it digitized analog parameters from the subsystems, loaded discrete statuses into data bytes, and built the serial telemetry stream to be sent to the Shuttle's Payload Data Interleaver (PDI). It also handled the command interface, receiving command packets from the Shuttle Payload Signal Processor (PSP) and converting them into pulses and relay clicks.

Everything in the DMU was synchronous. It was driven by a memory table that told it which data to route where when, assisted by what Dean called the "overhead wiring", which was a rat's nest of jumpers that ran from pin to pin across a set of connectors on top of the box. Each bit of data had to be routed to arrive at the output formatter at its allotted time, or else invalid data would be received. One wrong routing bit or counter in the table could mess up the whole telemetry stream, and it was not always obvious where in the table the error was. User payloads could interface to it via serial ports, but it was tricky because the payload could only transmit when it received a clear-to-send pulse from the DMU, and it could only send a certain number of bytes of data on each pulse, and the pulses were not necessarily monotonically spaced. The DMU itself had to be loaded with the correct memory table for the phase of the mission; the Shuttle itself provided varying amounts of downlink bandwidth at different times.

Anyway, my job was going to be to manage the development of a subsystem called the Experiment Data System, for the RDM. The EDS was (and still is) the most sophisticated payload data handling system ever flown on a spacecraft, with capabilities far exceeding the DMU's meager complement of serial interfaces, as well as the Shuttle itself. The program had subcontracted the development of the EDS to a contractor in Colorado. They had built the hardware, but the corresponding software effort had crashed and burned, and that work was now being sent to another sub in Toronto. One of my responsibilities was going to be to manage the system requirements and then work with the sub in Toronto to make sure the software got built and that it did what we wanted it to do.

I'll post the next installment on this thread, in which I'll describe the EDS system a bit, and then I'll talk about some more of the people and about working in the SPPF.

13 replies: All unread, jump to last
User currently offlineAreopagus From United States of America, joined Sep 2001, 1376 posts, RR: 1
Reply 1, posted (2 years 2 weeks 1 day 16 hours ago) and read 8655 times:

An interesting read. Thank you. I'll look forward to reading your future installments. (So in case of a lack of further response, don't take it as a sign of lack of interest or readership).

User currently offlineBEG2IAH From United States of America, joined Apr 2004, 991 posts, RR: 18
Reply 2, posted (2 years 2 weeks 1 day 12 hours ago) and read 8567 times:

Quoting cornutt (Thread starter):
I promised I'd write something about my experiences with that flight.

cornutt, thanks for sharing this story. I'm looking forward to the next one!

FAA killed the purpose of my old signature: Use of approved electronic devices is now permitted.
User currently offlinecornutt From United States of America, joined Jan 2013, 338 posts, RR: 0
Reply 3, posted (2 years 1 week 6 days 7 hours ago) and read 8263 times:

Next installment: Backtracking a bit. I mentioned previously that I joined the SPACEHAB program while the merger of Boeing and McDonnell-Douglas was under way. The business systems had not been transitioned to Boeing yet, the result being that I was of the last employees to be assigned a McDonnell-Douglas clock number, in addition to my Boeing employee number. We were entering our daily time charges by telnetting into an old mainframe application. That only lasted a few months before we were moved over to the Boeing timekeeping system.

I was assigned to the software group, along with Bob Robinson, Margaret Wood, and Dean Hallmark; we also had Mark Mumbleau, an engineer at the SPPF who was the liason and test lead for our group. Tim Tripp was our manager. A few months after I started, Tim was promoted to engineering manager for the program, and Steve Noojin, an engineer from the thermal group, was assigned as our manager. Steve didn't know a lot about software, but he was a good manager and we trained him right.

Now, I promised to say something about the Experiment Data System. It was a pretty cool system. Its purpose was to gather up telemetry from the RDM payloads, route them through the Shuttle and NASA comm systems, and get it distribute to the right experimenter groups at the Mission Control Center (more about which later). Previous systems for interfacing payloads, such as the Shuttle's Payload Data Interleaver and the Spacelab data systems, relied on these synchronous serial interfaces that required special hardware to interface to, and were very timing-sensitive. The EDS, on the other hand, allowed experiments to interface using ordinary Ethernet and TCP/IP protocols. There was an Ethernet network on board the RDM that payloads could plug into. The EDS hardware pieces consisted of:

* The EDS Main Unit, or EDSMU. This was the brains of the onboard half of the system. It handled all of the data management and routing; it buffered up data when downlink channels were not available, and it controlled the other onboard elements of the EDS. It actually contained two redundant units -- there was an A and a B side, each independent except for a few bits of the comm interfaces. Only one side or the other could be powered at a given time, and this was selectable via a switch on the front panel. If the A side failed in flight, the crew could move the switch to the B position, and we could keep operating.

The EDSMU interfaced to the onboard Ethernet. A payload connected to the system by opening a TCP socket to a port number on the EDSMU that we assigned them. After that, all it had to do was write telemetry data to the socket, and that data would come out on the ground side of the system. Similarly, the ground end could send commands (if enabled) to the payload by writing data to the ground end, and when it got onboard, the EDSMU would spit it out of that same port. The EDSMU also provided some standard RS-232 and 422 ports that payloads could use as an alternative to the Ethernet; several payloads (mostly older hardware) used these.

The EDSMU also had the job of recording any data sent for downlink when the downlink channel wasn't available. As you might know, the Shuttle was not in contact with the ground all of the time; most of the time there was a minimum period of about 10 minutes, over the Indian Ocean, where there was no TDRS satellite in range and so comm would be lost during this period. Additionally, for comm channnels which use the Shuttle's Ku-band system, availability was subject to the pointing geometry limitations of the dish antenna, which was a very complex problem. The MCC issued predict times for each orbit for when various comm systems would be available or unavailable. We built timeline files which we sent to the EDSMU to tell it when it needed to record data and when it could downlink in real time. Payloads were none the wiser; they sent data to the EDSMU and whether the EDSMU downlinked in real time or recorded it was transparent to them. Once every 12 hours or so, we dumped all of the recorded data to be processed on the ground. Recording was done to a hard disk in the EDSMU, which was semi-revolutionary at the time, and a huge improvement over the tape-based systems that Spacelab and the Shuttle itself used.

* The EDS-HUB was the hub of the onboard Ethernet. It actually contained hubs for two networks, a 10baseT network and a 100baseT network; these were cross-strapped to form one logical network. The 10baseT side provided 22 physical ports for payload use; the 100baseT provided 11. Physical connection was made by a variety of methods; for most payloads, the twisted pair went to one of the typical Amphenol locking circular connectors, which were available at various places in the module. There were also some spares which were coiled and stowed under the floor. Also, the forward and aft bulkheads each had a panel with five standard RJ-45 jacks, all of which were connected to the 10baseT half of the network. These could be used to connect payloads, but could also be used on an as-needed basis with the Shuttle crew laptops. We did actually wind up doing this once during STS-107.

In addition, the hub distributed timing signals from the Shuttle Master Timing Unit. There were three signals available: GMT and MET time, both in IRIG-B format, and a 1024-khz square wave. The hub provided 12 outputs for each. The hub also provided the GMT and MET signals to the EDSMU, which synchronized its internal time to them; the EDSMU then provided GMT to the Ethernet-connected payloads via Network Time Protocol (NTP).

* The Experiment Interface Unit (EIU) provided additional types of interfaces to payloads that couldn't interface with an Ethernet or a serial interface. The EIU was a small processor box that installed adjacent to the payload that was using it, and interfaced with the EDSMU via the Ethernet. The original idea was that an EIU would be loaded with interface hardware on a mission-specific basis; IIRC there were four slots available in the chassis for interface boards. The original list of offered interfaces included:
-- Discrete (on/off) inputs and outputs. The discrete inputs accepted 0V as "off" and 5V or above as "on"; they were zener-protected against out-of-range voltages. Sampling rates of up to 100 Hz were available. For the outputs, there was a choice of an open-collector logic output, which could be pulled up to 5V or 12V or left open as required, or a dry-contact relay.
-- Analog inputs and outputs. The analog inputs could be configured for 8-bit or 16-bit operation, with sampling rates up to 100 Hz. Several gain setting values were available, and like the discrete inputs, they were zener protected. The analog outputs were configurable for 0 to 10V, -5 to +5V, or -10V to +10V, and were all 16-bit.
-- RS232 serial. Two ports were available on each EIU.
-- Emulation of the Spacelab High Rate Multiplexor (HRM) interface. This was basically an externally clocked (separate clock and data), high-speed serial interface. Our interface could provide the clock if needed, at the same rates that were available on the real HRM, up to 48 MHz. We could also provide a periodic "format" (clear to send) pulse for payloads that needed it, although unlike the real HRM, our emulation was timing-insensitive and would accept data at any time. This was an input-only interface.
-- Emulation of the Spacelab Remote Acquisition Unit (RAU) interface. This was a two-way, medium-speed synchronous serial interface. As it turned out, none of the STS-107 payload customers ordered this, so when we ran into problems with the implementation that would have required a major hardware change, this was abandoned.
-- Emulation of the ISS MIL-STD-1553 payload bus. This was not ordered for STS-107, but we did have a customer who wanted it for the planned second flight of the RDM. I was working on the software for it at the time that STS-107 flew, and it was basically working although it had not been tested for conformance to the ISS interface spec.

The EIU was packaged into a rather odd-looking box that was wedge-shaped at one end. The purpose for that was to be able to fit into a small space at the bottom of a payload rack, where it fit up against the curvature of the exterior wall at the floor level. The wedge end provided clearance for the curved surface. The EIU could also be mounted on either the front or the rear bulkhead. The EDSMU could accommodate interfaces for up to eight EIUs at a time.

The ground half of the system consisted of two units:

* The Experiment Ground Data Assembly (EGDA) was the equivalent of the EDSMU and EDS-HUB on the ground system. It interfaced with the comm interfaces in the MCC to receive the downlink data and send commands. It contained a processing unit which was sort of the mirror image of the EDSMU; what the EDSMU packaged up, the EGDA unpacked, and vice versa. The EGDA connected to the payload user network in the MCC. Experimenters brought in their own equipment which they connected to the net; we then gave them a TCP port number to open a socket to at the EGDA, and through that socket they received anything that the payload sent to the EDSMU socket onboard. And the EGDA, like the EDSMU, also offered RS-232 and RS-422 ports as an alternate means of connection.

The EGDA had two other major jobs. When we dumped recorded data from the EDSMU, it was the EGDA's job to capture the dump, separate the individual payload data streams, and make them available to the payload users. We did this via an FTP service; each payload's data was compiled in a file which was moved to an FTP account for that payload.. Each payload had a user ID and password that they used to FTP the data from the EGDA to their equipment.

The other major job was controlling access to payload commanding. Shuttle missions were pretty carefully planned as to what would happen when; there are all sorts of ways that one payload's operations can interfere with other payloads, or with work that the astronauts are doing. Additionally, one of the command channels had very limited bandwidth, and we had to coordinate the use of it with a secondary program that was also on the STS-107 flight. So we could only allow payload users to send commands to their payloads when authorized. We had two mechanisms for enforcing this: we could enable and disable commanding on a per-port basic, and we could also turn the uplink channel interfaces on and off. The EGDA implemented all of this.

* The EDS Management Interface, or EDSMI, was our console for controlling the whole EDS system. This was an ordinary PC, unlike the other components of the system which were custom assemblies. During the mission planning process, it allowed us to define which payloads were on the flight, which ports and IP addresses they would use, how much bandwidth they would be allowed to use, etc. During the flight, it presented us with a big window that displayed several panes of information. At the top were rows of icons, each representing a payload port. It showed us if the port was enabled, if the payload had a socket connection to it, and the bandwidth being used. Further down, we had a corresponding row of icons representing the experimenter groups' ground equipment. These icons showed us if they were connected, if they were enabled for commanding, and the bandwidth in use. In between the top and bottom panes were a row of icons representing the space-to-ground communications channels; it showed us the routing status of each channel and the bandwidth being used on each channel. There was also an icon showing the onboard data recording disk drive; it showed us the rate at which data was being recorded, and the amount of recording time remaining at the current rate. Over on the right side was a list of internal EDSMU and EIU parameters and the current value of each.

Underneath the row of icons representing the ground equipment, we had a window that graphically represented the availability times of each of the downlink channels, and when recording would take place; a moving bar on this window represented the current time, and each state-change icon on the future side of the bar had a countdown timer showing how long until that event took place. At the very bottom, we had a text window that showed us caution, warning, and advisory messages from the various system elements. We also had a command window that we could open if we needed to send a command to the EDSMU, EGDA, or an EIU. And there were some secondary windows that went with other specific functions. The EDSMI interfaced to the EGDA via a protected port on the Ethernet.

Of the quantities of hardware built:

Three EDSMUs were built, numbered 000, 001, and 002. #001 was designated the flight EDSMU; this was the one actually installed in the RDM. #002 had been used for qualification testing, during which it was subject to mechanical stresses beyond the flight limits, so it was judged not suitable for flight, although it could have flown in a pinch. We used it at the SPPF during the payload integration process for "out of module" testing, in which the payload would test its data and command interfaces on the bench prior to installation in the RDM. #000 was the engineering unit; it was functionally and electrically equivalent to the other two, but was not mechanically constructed to flight standards. It stayed in the development lab in Huntsville.

Three EDS-HUBs were built, also numbered 000, 001, and 002. Similar to the EDSMU, #002 had been used for qual testing and was assigned to out-of-module payload integration. #001 was the flight unit. Boeing never took delivery of #000; it remained at the subcontractor's site in Colorado throughout the program. It is my understanding that it never worked right, although I never worked with myself.

Four EGDAs were built, numbered 001, 002, 003, and 004. 001 and 003 were at the SPPF; #003 was assigned to work with the out-of-module string of bench equipment, and #001 interfaced with the in-module equipment. #002 was assigned to the development lab in Huntsville. #004 was not finished until shortly before the STS-107 flight and was never used very much. #001 and #003 were sent to Houston to be used in the MCC for the flight. We had intended to use #001 as the primary for the flight, but a connector broke on it during pre-launch testing, and although it was repaired before launch, #003 became primary because I had more confidence in that one. As it happened, we wound up having to use both during the flight, something I'll get to in a later installment.

Six EIUs were built. There was an qual unit, numbered #001; it spent some time in the development lab in Huntsville, and then was sent to the SPPF for mechanical checkout of the various mounting options. It had gotten damaged during qual testing and had to be sent back to the subcontractor for a while. After that, it was used with the out-of-module payload testing string. An engineering unit, #000, stayed in Huntsville; like the #000 EDSMU, it was not mechanically constructed to flight standards. We eventually wound up taking all the boards out of it and installing them in a commercial chassis, because it was easier to work with that way, and it allowed us to install a disk drive for development purposes. (The EIU design did not incorporate a disk drive; all storage was in flash memory.) Four production flight EIUs were built, numbered 101, 102, 103, and 104. #103 had fan problems and had to go back to the subcontractor for repairs; as the STS-107 configuration only required three EIUs, #103 was not assigned to the flight and was put into storage when it came back to the SPPF.

We didn't assign serial numbers to the EDSMIs, but basically there were four. Two were at the SPPF; one was in Huntsville. One was sent to the MCC, where it was intended to remain in storage in between RDM flights.

Phew... that's a lot of info. Next time I'll talk about some of the development of the EDS system.

User currently offlinecanoecarrier From United States of America, joined Feb 2004, 2844 posts, RR: 13
Reply 4, posted (2 years 1 week 5 days 15 hours ago) and read 8132 times:

Thanks for two really well thought out and informative posts. I know that this question is off topic so if you feel better answering it via message that would be fine.

Quoting cornutt (Thread starter):
Wehner von Braun's son Peter was one of my school classmates

Did you run into many, or any "Operation Paperclip" scientists while you were doing your work? And, when was the last time you saw them involved in the program. I've read conflicting reports about how long German scientists were involved in the program. Some as late as the late '80s.

The beatings will continue until morale improves
User currently offlinecornutt From United States of America, joined Jan 2013, 338 posts, RR: 0
Reply 5, posted (2 years 1 week 5 days 9 hours ago) and read 8069 times:

Quoting canoecarrier (Reply 4):
Did you run into many, or any "Operation Paperclip" scientists while you were doing your work?

A few. I knew Dr. Ernst Stuhlinger, who was a chief scentist in the Space Sciences Lab at MSFC until about 1995. I knew him through the Von Braun Astronomical Society, a volunteer group which operates a planetarium and observatory in Huntsville. Dr. Stuhlinger was the caretake of the solar telescope. I met a few others once in 1991, at an event at the U.S. Space and Rocket Center. They had taken a trip back to Peenumunde after the fall of the East German government; it was the first time any of them had been back since they surrendered to the American forces in 1945. They had some photos and videos they took, and they talked about the V-2 work and what it was like during the war.

Incidentally, there's a main road through Redstone Arsenal, where MSFC is located, named after General Holger Toftoy -- the head of Operation Paperclip.

User currently offlinejollo From Italy, joined Aug 2011, 253 posts, RR: 0
Reply 6, posted (2 years 1 week 5 days 1 hour ago) and read 8024 times:

Fascinating stuff... at least for a software engineer and aviation enthousiast. Everyone kind of knows that behing every trivial-looking componenent of the Shuttle program there was an astounding amount of work and dedication, but reading about the details really puts into perspecive the overall effort. Thanks for sharing.

I was surprised about the small number of actual examples built for each component: if I understood correctly, most core components were built in only two full-spec examples (the "engineering units" sound like what I would call lab-only prototypes), of which one was "spent" for qualification testing (and, while maybe still operational, not flightworthy). So basically you had just one flightworthy example and it had to work right. Was that an exception due to SpaceHab's "proof of concept" status or was it a kind of norm?

User currently offlinecornutt From United States of America, joined Jan 2013, 338 posts, RR: 0
Reply 7, posted (2 years 1 week 3 days 19 hours ago) and read 7889 times:

Quoting jollo (Reply 6):
So basically you had just one flightworthy example and it had to work right.

Pretty much. There were some spare parts. And yes, you didn't want to fly the qual unit if you could avoid it, since it had been subject to stresses exceeding the design limits during qual testing. With spacecraft, it's common to see only enough units of each subsystem, plus one or two, to satisfy the need for however many examples of the spacecraft were to be built. Back when there were four Shuttles, it was common that at any one time, one of them was unflyable because parts had been "borrowed" from it to put in another one. I mentioned the SPACEHAB Data Management Unit (DMU) in a previous post. Each of the modules needed one to manage its subsystem telemetry and commanding, plus the SPPF had an additional one that was used for brassboard testing outside of the modules. Inc originally bought four of them (if memory serves, they were made by General Dynamics), but at the time I joined the program, one of them was non-functional and had been stripped for parts, since new ones were no longer available. Then, at one point during the early preparations for the RDM, the one in the logistics module failed and had to be sent back to the manufacturer for repair. In order to support an upcoming ISS logistics flight, the SPPF had to take the one out of the RDM and put it in the logistics module. So until the broken unit came back from the repair station, which took several months, we were very limited as to what we could do with the RDM; if it was absolutely essential to run a test inside the RDM, they had to take the brassboard DMU, install it in the RDM, and then pull it back out afterwards.

We were actually fortunate in that we had engineering units of most of the flight hardware that were fully functionally equivalent, for software development purposes. A lot of spacecraft avionics software projects don't have that luxury; they have to use a combination of emulation hardware and software simulations, and they don't really know if their software works until they can run it in a brassboard lab, or in the spacecraft itself. At one point I had to re-design the software for the payload command link that went through the Shuttle Payload Signal Processor (PSP), a comm system which had a lot of unique characteristics and wasn't very transparent to the user. We didn't have access to a PSP in Huntsville or at the SPPF, so we didn't know for sure that that command link was going to work until we were able to try it out during the Shuttle/MCC end-to-end test, a month before the launch. Fortunately, it was a mature and well-documented interface; the JSC people were able to advise me on a couple of things, and during the flight it worked perfectly.

User currently offlinerwessel From United States of America, joined Jan 2007, 2500 posts, RR: 2
Reply 8, posted (2 years 1 week 3 days ago) and read 7797 times:
Support Airliners.net - become a First Class Member!

Quoting cornutt (Reply 7):
Pretty much. There were some spare parts. And yes, you didn't want to fly the qual unit if you could avoid it, since it had been subject to stresses exceeding the design limits during qual testing.

And yet baffling things happen. Hubble's original gyros were leftovers from IUE (and IUE's experience had shown them to not be particularly reliable). And then they had been test run for over 70,000 hours (eight years) before being installed in Hubble. Little wonder two failed in the first year on orbit...

User currently offlinejollo From Italy, joined Aug 2011, 253 posts, RR: 0
Reply 9, posted (2 years 1 week 2 days 13 hours ago) and read 7718 times:

Quoting cornutt (Reply 7):
With spacecraft, it's common to see only enough units of each subsystem, plus one or two, to satisfy the need for however many examples of the spacecraft were to be built.

Weird. Once the R&D, development and qualification are paid for, one would think that the expense to build a few more units should be irrelevant, and surely much less than the cost and trouble of being short one flightworthy example in a pinch.

Quoting rwessel (Reply 8):
And yet baffling things happen.

Wow. Very weird. Any insider information as to *why*?

User currently offlinerwessel From United States of America, joined Jan 2007, 2500 posts, RR: 2
Reply 10, posted (2 years 1 week 2 days 4 hours ago) and read 7664 times:
Support Airliners.net - become a First Class Member!

Quoting jollo (Reply 9):
Quoting rwessel (Reply 8):
And yet baffling things happen.

Wow. Very weird. Any insider information as to *why*?

I wish I knew… The mission/science side of the Hubble team was reportedly pretty baffled too. Why the heck did the spacecraft engineering guys put clapped out gyros on there? Of course, in the grand scheme of things, it pales in comparison to the mirror screw up.

User currently offlineGeezer From United States of America, joined Aug 2010, 1479 posts, RR: 2
Reply 11, posted (1 year 10 months 3 weeks 2 hours ago) and read 6393 times:

I just noticed this thread two spaces up from dropping off the bottom; I read the entire thread shortly after the OP had posted it; I didn't comment then, as I couldn't add anything to the subject; I must say now, I have never before read anything in any post on A.net that was more interesting, as well written, or that indicated such a remarkable memory of such detail; I would like to add my thanks to the O.P. for sharing this remarkable story with us.

In re-reading all of the replies, I remember reading this, which I almost made a reply to.....

Quoting rwessel (Reply 10):
Of course, in the grand scheme of things, it pales in comparison to the mirror screw up.

Thank you rwessel for reminding me;

As some one who has spent many hours, (many years ago), grinding, polishing, and attempting to "figure" a few small telescope mirrors, that's one almost unbelievable story that I never have heard an explanation for.

Stupidity: Doing the same thing over and over and over again and expecting a different result; Albert Einstein
User currently offlinerwessel From United States of America, joined Jan 2007, 2500 posts, RR: 2
Reply 12, posted (1 year 10 months 2 weeks 6 days 4 hours ago) and read 6209 times:
Support Airliners.net - become a First Class Member!

Quoting Geezer (Reply 11):
As some one who has spent many hours, (many years ago), grinding, polishing, and attempting to "figure" a few small telescope mirrors, that's one almost unbelievable story that I never have heard an explanation for.

As near as anyone can tell*, Perkin-Elmer misassembled the interferometer used to measure the mirror shape during grinding, and then nobody every really checked the shape, not even doing the basic refractive-null test that most home telescope builders will perform on the final assembly. IOW, the first time anyone ever tried to look through the whole telescope was when it was on orbit. Not doing the whole system test was justified on budget and time grounds, despite Hubble already being hugely over budget and that doing the test would have been a relative pittance, and that Hubble was delayed for years by for various reasons, not least spending a couple of years in *storage* after Challenger. In fact there were two tests done during rough grinding (way back in 1981) that showed the problem, but they were discarded as being "faulty".

Even better, the backup mirror, ground by Kodak, while never really tested, *was* likely correctly shaped (not to mention on time and on budget, unlike the PE mirror), as it was ground with a more traditional lapping technique. The official story is that it's still in storage and in the shipping crate Kodak put it in, but there are rumors that it got used on an intel satellite.

*The misassembled equipment was found (still incorrectly assembled) in storage during the investigation, and apparently the flaw matches that error exactly. It is speculated that it's the same gear that was used to grind KH-11 mirrors, and was disassembled and reassembled somewhere between grinding the last KH-11 mirror and the Hubble mirror (which was the last thing it was apparently used for). Perhaps when it was being moved between the classified and unclassified facilities at PE.

User currently offlinejollo From Italy, joined Aug 2011, 253 posts, RR: 0
Reply 13, posted (1 year 10 months 1 week 2 hours ago) and read 5694 times:

Quoting cornutt (Reply 3):
Phew... that's a lot of info. Next time I'll talk about some of the development of the EDS system.

Hey, pal, thanks for starting this most interesting thread, now we're waiting eagerly for the next big chunk of it! Don't give up!

Quoting rwessel (Reply 12):
nobody every really checked the shape, not even doing the basic refractive-null test that most home telescope builders will perform on the final assembly. IOW, the first time anyone ever tried to look through the whole telescope was when it was on orbit.

All too credible and quite depressing: the highest technology projects get the cr@ppiest management. Still happening worldwide with no hint that lessons are being learned (sorry, project management is my professional area, this kind of tales make my skin crawl). NASA not being immune isn't a big consolation, though...

Top Of Page
Forum Index

Reply To This Topic My Life With STS-107
No username? Sign up now!

Forgot Password? Be reminded.
Remember me on this computer (uses cookies)
  • Military aviation related posts only!
  • Not military related? Use the other forums
  • No adverts of any kind. This includes web pages.
  • No hostile language or criticizing of others.
  • Do not post copyright protected material.
  • Use relevant and describing topics.
  • Check if your post already been discussed.
  • Check your spelling!
Add Images Add SmiliesPosting Help

Please check your spelling (press "Check Spelling" above)

Similar topics:More similar topics...
STS-107 Columbia posted Fri Sep 8 2006 19:59:04 by Britannia191a
ISS Plans Changing With STS Groundings.. posted Fri Jul 29 2005 22:12:54 by TedTAce
STS:123 Takeoff From My Vantage Point posted Fri May 21 2010 13:41:10 by eksath
My Strange, Short Encounter With Buran In Bahrain posted Sun Sep 23 2007 20:41:45 by Birdwatching
Video: Tour The ISS With Com. Sunita Williams posted Wed Nov 21 2012 07:34:34 by NoUFO
Russia Loses Contact With Its Satellites posted Wed Nov 14 2012 11:26:47 by MadameConcorde
Iraq To Sign $5 Billion Arms Deal With Russia posted Thu Sep 27 2012 14:43:59 by imiakhtar
India To Ink $35B Su-T50 Deal With Russia posted Sat Aug 18 2012 23:41:04 by comorin
My Shuttle Enterprise Photos @ JFK posted Fri May 4 2012 06:43:42 by werdywerd
F-22'S With In 200 Miles Of Iran! posted Fri Apr 27 2012 20:47:14 by Thumper

Sponsor Message:
Printer friendly format