ewiles@netxcom.UUCP (Edwin Wiles) (09/30/88)
Reprogramming:
Yes, the shuttle was held for the weather to actually 'worsen'.
The winds at the 30 thousand foot level were not as strong as
was expected, and were not comming from the right direction.
Seems that flight control data is built into the program to
compensate for the expected winds, and nature simply didn't
coooperate right away.
Why isn't it set up to read the data in?
a) EXTREMELY LIMITED MEMORY!!! Anyone nowadays can go into
a store and purchase more computing power and memory than
all five of the Shuttle computers combined.
b) MAN RATING. Anything that changes, and has to do with
a manned space shot, must be 'man rated'. This is a very
expensive and time consuming process. Thus, if they had
changed the software, they would have had to go through
the man rating process.
Why don't they upgrade? See "MAN RATING". Not to mention
the fact that all the systems are set up to work with the
existing computer design. You'd probably have to redesign
nearly everything.
FLAME PLUME:
Yes, I saw it to, and nearly died of fright! However, when
informed of the plume's existence at a post-launch conference,
a NASA spokesman indicated that such lights had been seen a
number of times before, and had always turned out to be some
sort of reflection. NOT an actual flame. [Pers'naly, I'm
still suspicious, but NASA knows it's neck is on the chopping
block. One more serious screwup and we won't *have* a space
program, *at* *all*.]
CANCELED HOLD AT T-31 SECS:
Apparently the launch sequencer is set up to abort if anything
is out of parameters at T-31 seconds. The program that monitors
the cabin air pressure and O2 content showed a discrepancy in
the O2 content. The possibility of this discrepancy showing up
had been discussed quite some time before the launch. The program
had not been constructed to take the effects of the crew's pressure
suits into account. When that was confirmed as being the reason
for the potential hold, it was overriden by the controlers before
it had a chance to stop the launch. Why wasn't the program
rewritten? See "MAN RATING", above.
SOMETHING I HAVEN'T SEEN MENTIONED YET:
The crew boarding was delayed for aproximatly 30 Mins due to
a simple 5A fuse burning out in the Commander's suit cooling
fan. Seem's they had some trouble locating a replacement.
Most of this information was garnered from NASA Select programming, and
from ABC News coverage of the flight (Good Job, ABC!).
--
...!hadron\ "Who?... Me?... WHAT opinions?!?" | Edwin Wiles
...!sundc\ Schedule: (n.) An ever changing | NetExpress Comm., Inc.
...!pyrdc\ nightmare. | 1953 Gallows Rd. Suite 300
...!uunet!netxcom!ewiles | Vienna, VA 22180phil@titan.rice.edu (William LeFebvre) (10/04/88)
In article <981@netxcom.UUCP> ewiles@netxcom.UUCP (Edwin Wiles) writes: >Reprogramming: > Seems that flight control data is built into the program to > compensate for the expected winds, and nature simply didn't > coooperate right away. > > Why isn't it set up to read the data in? As I have said before, it's not that simple. > a) EXTREMELY LIMITED MEMORY!!! Anyone nowadays can go into > a store and purchase more computing power and memory than > all five of the Shuttle computers combined. At the time the on-board computers were designed and built, this was not the case. IC and other computer technology has literally exploded in the past 5 years. The first shuttle was launched in 1981? Right? 81 or 82. How easy was it to buy a Sun-like workstation at that point in time? Not very. How easy was it to buy 1 megabyte memory boards then? Not very. The point being that since the shuttle program "got off the ground" many advances have been made in computer-related technologies. > b) MAN RATING. Anything that changes, and has to do with > a manned space shot, must be 'man rated'. This is a very > expensive and time consuming process. Thus, if they had > changed the software, they would have had to go through > the man rating process. What is this "man rating" you are talking about? Do you mean safe enough to trust a human's life to? NASA takes that very seriously. It is extremly difficult to make any changes to the on-board flight software. Almost impossible, in fact. Would you trust *your* life to someone else's running computer program? > Why don't they upgrade? See "MAN RATING". Not to mention > the fact that all the systems are set up to work with the > existing computer design. You'd probably have to redesign > nearly everything. An upgrade is, in fact, in the works. I don't know all that it includes, but I have heard that it will include going to static RAM (and more than 208K half-words as well). >FLAME PLUME: > [Pers'naly, I'm > still suspicious, but NASA knows it's neck is on the chopping > block. One more serious screwup and we won't *have* a space > program, *at* *all*.] But NASA couldn't care less about the crew's safety, right? :-) >CANCELED HOLD AT T-31 SECS: > > Apparently the launch sequencer is set up to abort if anything > is out of parameters at T-31 seconds. The program that monitors > the cabin air pressure and O2 content showed a discrepancy in > the O2 content. The possibility of this discrepancy showing up > had been discussed quite some time before the launch. The program > had not been constructed to take the effects of the crew's pressure > suits into account. When that was confirmed as being the reason > for the potential hold, it was overriden by the controlers before > it had a chance to stop the launch. Why wasn't the program > rewritten? See "MAN RATING", above. [ Lord give me patience! ] I will try to be nice, okay? There was a great deal of discussion before launch that the O2 level in the cabin was close to the limit, but not yet over it. They discussed the problem and decided (with the crews' consent, I might add) that it was not serious enough to stop the launch. The on-board computers monitor many different discrete values, such as the air's O2 content. There are constants in the program that delineate the range in which each value should be to be considered "nominal". If one of those values goes out of range (either too high or too low), the computers issue a warning. When the ground launch sequencer takes over, if it sees such a warning, it will stop the countdown at T-31 seconds. This is what almost happened. The computers indicated (at around 70 seconds if I recall) that there was a problem, and the launch controllers anticipated a hold at T-31. So why can't these constant limits be changed? Edwin Wiles would have us believe that they were hard coded into the program and changing one would requre rewriting the program, thus requiring it to be recertified (or re-"man rated" as he puts it). This is simply not true. I wish Mr. Wiles would give the designers and programmers more credit than that. These values can be changed through something the controllers call a TMBU (I have no idea what that acronym stands for). It requires sending a command up from Mission Control in Houston. The next obvious question is then "if they knew ahead of time that the alarm might go off, then why not change the upper limit"? Well, they have done pre-launch TMBUs in the past and they have had a few (a *very* few, but a few) bad experiences with them--- that is, there was a mistake in the uplinked TMBU and it caused more problems than it fixed. During the 2.5 year hiatus, they polled all the mission control disciplines and asked "are there any pre-launch TMBUs that you really need to do"? Everyone said "No, I guess not." So they decided "no more TMBUs after a certain point in the countdown." Basically, they don't trust the procedure. That is why they did not do it this time. Yes the alarm might go off, but they already know to override it. Why take the chance on a TMBU when you don't need to? The controllers on the ground can still see the actual O2 level and they can tell if it gets way too far out of nominal (in other words, the computer warning is not the only data that the ground controllers see). > The crew boarding was delayed for aproximatly 30 Mins due to > a simple 5A fuse burning out in the Commander's suit cooling > fan. Seem's they had some trouble locating a replacement. [ Lord, I think I need some more of that patience. ] There were no available replacement fuses on the shuttle. One had to be sent up from the ground. BY DESIGN, nothing important is close to the launch pad---they probably had to send one out from the VAB, 3 miles away. They didn't necessarily have "trouble locating a replacement", they just had a long way to go to get it out to the pad. William LeFebvre Department of Computer Science Rice University <phil@Rice.edu>
klr@hadron.UUCP (Kurt L. Reisler) (10/04/88)
In article <1952@kalliope.rice.edu> phil@Rice.edu (William LeFebvre) writes: >In article <981@netxcom.UUCP> ewiles@netxcom.UUCP (Edwin Wiles) writes: [large portion of "dialog" deleted :-)] > >> The crew boarding was delayed for aproximatly 30 Mins due to >> a simple 5A fuse burning out in the Commander's suit cooling >> fan. Seem's they had some trouble locating a replacement. > >There were no available replacement fuses on the shuttle. One had to be >sent up from the ground. BY DESIGN, nothing important is close to the >launch pad---they probably had to send one out from the VAB, 3 miles away. >They didn't necessarily have "trouble locating a replacement", they just >had a long way to go to get it out to the pad. Actually, from what I gathered while watching NASA Select, the fuses were being kept in a technition's car at one of the roadblocks outside of the safety zone. Once it was determined that the problem was a blown fuse (by that time 2 blown fuses) they were sent for and replaced, with no loss of time in the countdown. One thing I am curious about however. What was done with (to) the pilot of that private plane that buzzed the pad about 2 hours before the launch? NASA Select carried a portion of the CapComm dialog informing the personel in the "White Room" not to be concerned about the noise of the security aircraft as they chased a private plane out of the restricted airspace. They then cut to the view from a chase plane (helecopter?) that was on the intruder's tail, the registration numbers on the tail were clearly visible.
dave@viper.Lynx.MN.Org (David Messer) (10/05/88)
In article <1952@kalliope.rice.edu> phil@Rice.edu (William LeFebvre) writes: >In article <981@netxcom.UUCP> ewiles@netxcom.UUCP (Edwin Wiles) writes: >> a) EXTREMELY LIMITED MEMORY!!! Anyone nowadays can go into >> a store and purchase more computing power and memory than >> all five of the Shuttle computers combined. > >At the time the on-board computers were designed and built, this was not >the case. Another thing is that there weren't any VLSI chips that were "Space-Rated" when the shuttle was designed. Try building a computer, with strict power and heat limits, when all you can use is small and medium-scale ICs. >There were no available replacement fuses on the shuttle. One had to be >sent up from the ground. BY DESIGN, nothing important is close to the >launch pad---they probably had to send one out from the VAB, 3 miles away. Are you saying that NASA was worried that an accident on the pad would wipe-out their supply of fuses? What were the astronauts supposed to do if a fuse blew when they were on orbit -- ask for one to be sent from the VAB? This does seem to be a case of poor contingency planning -- like the time they didn't have a wrench when they needed it. -- If you can't convince | David Messer - (dave@Lynx.MN.Org) them, confuse them. | Lynx Data Systems -- Harry S Truman | | amdahl --!bungia!viper!dave | hpda / Copyright 1988 David Messer -- All Rights Reserved This work may be freely copied. Any restrictions on redistribution of this work are prohibited.
dave@sun.soe (Dave Goldblatt) (10/05/88)
From article <786@hadron.UUCP>, by klr@hadron.UUCP (Kurt L. Reisler): > One thing I am curious about however. What was done with (to) the > pilot of that private plane that buzzed the pad about 2 hours before > the launch? NASA Select carried a portion of the CapComm dialog > informing the personel in the "White Room" not to be concerned about > the noise of the security aircraft as they chased a private plane out > of the restricted airspace. They then cut to the view from a chase > plane (helecopter?) that was on the intruder's tail, the registration > numbers on the tail were clearly visible. From the conversations I heard, NASA ordered the chase planes to force down the intruder and have him arrested. They are most certainly _not_ amused when you fly in their restricted airspace. Nor, for that matter, is the military. At the minimum the pilot will lose his license. Jail terms have been among punishments handed down as well. Serves 'im right.. -dg- -- Internet: dave@sun.soe.clarkson.edu or: dave@clutx.clarkson.edu BITNET: dave@CLUTX.Bitnet uucp: {rpics, gould}!clutx!dave Matrix: Dave Goldblatt @ 1:260/360 ICBM: If you don't know, I ain't telling.
phil@titan.rice.edu (William LeFebvre) (10/05/88)
In article <1468@viper.Lynx.MN.Org> dave@viper.Lynx.MN.Org (David Messer) writes: >In article <1952@kalliope.rice.edu> phil@Rice.edu (William LeFebvre) writes: > >There were no available replacement fuses on the shuttle. One had to be > >sent up from the ground. BY DESIGN, nothing important is close to the > >launch pad---they probably had to send one out from the VAB, 3 miles away. > >Are you saying that NASA was worried that an accident on the >pad would wipe-out their supply of fuses? Well, not really. I have the impression that they only bring stuff into "the perimeter" that needs to be there. There isn't much in the way of extras. I heard that not only did they replace the fuses that were blown, but they stowed extras on board. Since this is the first flight that they've ever used these suits, I think someone just plain forgot that there should be some extras on board. I suspect that there are extra fuses stowed on board for other things, but as long as they were on the ground they figured it was worth waiting so as not to use extras designated for other purposes. But then, this is all speculation. >This does seem to be a case of poor contingency planning -- I'll agree with you there. There should have been extras on board. But even if there were, they may have wanted to wait anyway to replenish the on-board stock. What I wonder about more than the lack of spare fuses is why did the fuses blow in the first place? A fuse doesn't just blow for no good reason. Sounds to me like some other minor problem needs to be fixed. William LeFebvre Department of Computer Science Rice University <phil@Rice.edu>
seven@ftp.COM (Benjamin Levy) (10/06/88)
> Once it was determined that the problem was a blown fuse (by that time > 2 blown fuses) they were sent for and replaced, with no loss of time > in the countdown. There have been several mentions of fuses blowing. But no one has said what caused the fuses to blow. Does anyone know what happened? I would doubt that the problem was a freak event, since two suits had fuses fail. It seems to me that a fuse blowing usually means that something else failed and the fuse was sacrificed to save the rest of the system. -- ---Ben Levy FTP Software Inc. <seven@ftp.com> ------------------------------------------------------------------- Member of the International Amoeba Society: "United We Stand, Divided We Multiply"