ALT Flights and GPC ...

rk wrote:
I recall reading somewhere about a GPC fault on the first ALT flight.
But I'm not sure and was chatting about this with a friend. A search
turned up nothing, perhaps we are old and have bad memories? Or the
correct report is sitting nearby hiding in plain sight?

--
rk, Just an OldEngineer
"The number of people having any connection with the project must be
restricted in an almost vicious manner. Use a small number of good
people." -- Kelly Johnson, as quoted in _Skunk Works_



Space shuttle orbiter approach and landing test evaluation report.
Captive-active flight test summary - Sep 1, 1977
http://ntrs.nasa.gov/archive/nasa/ca...1978002256.pdf

Shuttle ALT Captive-Active Flight 1A - June 17, 1977.

General Purpose Computer 3 failed during preflight checks. Section 6.6,
Page 6-10 (PDF page 71).



Rusty

Rusty wrote:

Space shuttle orbiter approach and landing test evaluation report.
Captive-active flight test summary - Sep 1, 1977
http://ntrs.nasa.gov/archive/nasa/ca...1978002256.pdf

Shuttle ALT Captive-Active Flight 1A - June 17, 1977.

General Purpose Computer 3 failed during preflight checks. Section 6.6,
Page 6-10 (PDF page 71).



There's no real point in even voting on who's the most valuable SSH
contributor of the year any more, is there? :-)

Pat

rk wrote:


Oh, and whilst I have the hood up, for STS-9, I think I heard this
during a talk, again, the time of year to chase down these little
items, wasn't there two GPCs that had trouble? Particles in the IC
packages' cavities? Again, from memory, but trying to track these
things down.

I started a presentation on avionics redundancy about a year ago and
picking it up again now. So your help is appreciated.


STS-9 SSVEO IFA List
GPC 1 failure caused by metal-particle-induced short circuit - Page 16
http://www.jsc.nasa.gov/news/columbia/anomaly/STS9.pdf


STS-9 MISSION REPORT
http://members.aol.com/WSNTWOYOU/STS9MR.HTM

http://members.aol.com/WSNTWOYOU/mainmr.htm

"GPC-1 And GPC-2 Failed - At 342:11:10:21 G.m.t., during computer
reconfiguration for entry, GPC-1, (OPS 2) failed. Shortly thereafter at
342:11:16:45 G.m.t., GPC-2 (OPS 2) also failed. All attempts to bring
GPC-1 back on line were unsuccessful. A ground review of GPC-2 memory
dump indicated some memory alterations had occurred. However, GPC-2 was
reinitialized in OPS 3 and was used in the redundant set with GPC-3 and
GPC-4 for entry and landing. At Orbiter nose wheel touchdown
(342:11:16:45 G.m.t.) GPC-2 again failed."


Rusty

rk wrote:
Wow.

Mucho thanks.

And there got to be an award here someplace. OM, can use some help
here. Perhaps a rusty trinket awarded to whomever responds with the
appropriate .pdf before rusty?

-- rk

Wait, there's more.

Space Shuttle In-Flight Anomaly Database for STS-1 Through STS-107
http://www.jsc.nasa.gov/news/columbia/anomaly/


STS-66 / FLIGHT 66 MISSION REPORT

GPC4 MMU-1 interface problem - page 9
http://www.jsc.nasa.gov/news/columbia/anomaly/STS66.pdf

http://members.aol.com/WSNTWOYOU/STS66MR.HTM

During a systems management (SM) checkpoint from general purpose
computer (GPC) 4 to mass memory unit (MMU) 1 at 315:13:26 G.m.t.
(07:20:26 MET), two error messages (I/O ERROR MMU 1 and S60 CHECKPT
FAIL) were annunciated. The checkpoint was unsuccessful. During
troubleshooting, all further transactions between GPC 4 and MMU 1
failed. Successful transactions were performed between GPC 1 and MMU 1.
This interface problem between GPC 4 and MMU 1 was believed to be due
to a failure of the GPC 4 bus control element (BCE) 18 transmitter
and/or receiver. A software dump of GPC 4 was performed, and analysis
of the dumped data supported the BCE 18 failure and indicated no other
problem with GPC 4. A verification of GPC 4 as a redundant guidance,
navigation and control GPC was performed at 316:18:30 G.m.t. (09:01:30
MET).

The SM function was moved from GPC 4 to GPC 3. GPC 4 was then placed in
the redundant set with GPC 1 at 316:19:13 G.m.t. (09:02:13 MET) to
determine whether the problem that the GPC 4 interface had with MMU 1
also affected GPC 4 communications on the flight critical (FC) 8 data
bus. The test confirmed that GPC 4 communications on FC8 were nominal,
isolating the problem to the GPC 4 BCE 18 interface with MMU 1. The
condition did not impact entry procedures.


STS-51 / FLIGHT 57 MISSION REPORT

http://members.aol.com/WSNTWOYOU/STS57MR.HTM

The crew completed all stowage requirements and prepared the vehicle
for entry and landing. The payload bay doors were closed and general
purpose computers (GPCs) 1 and 2 were transitioned to OPS 3. However,
during the redundant set expansion to include GPCs 3 and 4, GPC 3
failed to sync at 264:06:17 G.m.t. (08:18:32 MET). An initial program
load (IPL) of GPC 3 was accomplished and the GPC was successfully
brought into the redundant set. This GPC 3 failure-to-sync was
initially thought to be explained by Operations (OPS) Note 42433;
however, subsequent analysis removed this condition as a possible
explanation. No explanation is currently known.


STS-32

Backup Flight System GPC errors - Page 15
http://www.jsc.nasa.gov/news/columbia/anomaly/STS32.pdf

Deorbit delayed 24h due to fog at landing site, then postponed to the
next orbit because of a computer (GPC#5) failure.


STS-41D
Launch on Jun 25 postponed by 24h due to a GPC fault.

GPC-5 failed - Page 2
http://www.jsc.nasa.gov/news/columbi...aly/STS41D.pdf


Rusty

I recollect in a simulation shortly before STS-1, the
entire redundant set crashed. I think it was an abort sim.
Does anybody remember the details of that?

-- Joe D.

"Joe D." wrote in message
.. .
I recollect in a simulation shortly before STS-1, the
entire redundant set crashed. I think it was an abort sim.
Does anybody remember the details of that?

You may be thinking of the first launch attempt where the computers didn't
synch up and they had to abort.



-- Joe D.

"Greg D. Moore (Strider)" wrote in message
nk.net...

"Joe D." wrote in message
.. .
I recollect in a simulation shortly before STS-1, the
entire redundant set crashed. I think it was an abort sim.
Does anybody remember the details of that?

You may be thinking of the first launch attempt where the computers didn't
synch up and they had to abort.


No there was a sim not long before STS-1 (which used essentially
the GPC PASS flight software) where they were doing an abort and
it exposed a software problem that crashed the entire
redundant quad -- a big X on every screen.

I recall some comment about John Young being upset, since the
software was supposedly flight ready and they weren't that far
from launch.

I can't remember if the simulator had the fifth GPC with
BFS (Backup Flight Software) running or not.

I can't find any info on it, but I'm positive I remember that.

-- Joe D.

Joe D. wrote:

I recall some comment about John Young being upset, since the
software was supposedly flight ready and they weren't that far
from launch.


If that would have been me, there would have been a big yellow puddle on
the floor and a resignation letter on someone's desk inside of five minutes.

Pat

On Fri, 30 Dec 2005 16:59:36 GMT, "Greg D. Moore \(Strider\)"
wrote:


"Joe D." wrote in message
. ..
I recollect in a simulation shortly before STS-1, the
entire redundant set crashed. I think it was an abort sim.
Does anybody remember the details of that?

You may be thinking of the first launch attempt where the computers didn't
synch up and they had to abort.

It was just before STS-2.

See: " The Space Shuttle Primary Computer System," Communications of
the ACM, September 1984 Volume 27 Number 9, p. 886.

http://klabs.org/DEI/Processor/shutt...ter_system.pdf

"rk" wrote in message
...

It was just before STS-2.

See: " The Space Shuttle Primary Computer System," Communications of
the ACM, September 1984 Volume 27 Number 9, p. 886.

http://klabs.org/DEI/Processor/shutt...ter_system.pdf

Rk, thanks for the info. It turns out John Young wasn't involved. Summary
(as told by Jack Clemons, manager of avionics flight software at IBM):

STS-2 delayed at last minute due to fuel spill damaging tiles, so
crew (Engle & Truly) returned to Houston for more simulation.

They were doing a TAL abort, and upon OMS fuel dump
all four GPCs locked up, indicated on the cockpit displays as
a big 'X" on each screen.

Clemons said "the crew was rather upset, and they went off to
lunch."

Cause was an error in a software routine used for OMS fuel
dump (essentially firing the OMS engines). In the abort sim,
two OMS dumps were done, and after the first, counters in
the software routine were not properly reset. The second
time an uninitialized counter was used to calculate a GOTO
which resulted in jumping into non-executable code
(I assume data), resulting in a CPU spin.

-- Joe D.