-
#2440
by
alk3997
on 21 Dec, 2011 03:20
-
I may be remembering it wrong, but I seem to recall hearing that the roll rate for the roll program after liftoff changed (increased) beginning with STS-9 (first high-inclination mission)...anyone know what the roll rates were before and after? (And did they change again?)
Thanks.
(Sorry if repeating this.)
My memory must be fading. But, remember the rates are a combined (RSS) of roll, pitch and yaw not to exceed 15 deg / sec (if my memory is still good enough for that number). I don't remember the individual gains changing but that was before my time. The roll did last a lot longer (obviously).
-
#2441
by
alk3997
on 21 Dec, 2011 03:23
-
I all.
I'm getting a bit confused: what's the purpurse of the C&W system when both PASS and SM have fauld detection alarm capabilities? is the C&W something "embedded" in PASS and SM or it is something on its own? If I understand well the C&W system is separated from both PASS and SM.
Thanks a mil
Davide
My memory is better in this area. Don't confuse hardware C&W with fault annunciation in the software. There was a hardware C&W matrix that components could light up. But to confuse matters more, there was also C&W embedded in the software and so a Class 2 or Class 3 alarm was software triggered. A Class 4 (tone) was also software generated by the software and then sent to the audio annunciation unit.
Remember this was the late 1970s when this system was designed and so software was not to be trusted and so a hardware solution was used as well as a software solution.
Also remember SM is part of PASS (SM OPS 2, for instance). PASS and BFS had separate SM functions. But fault detection and annunciation were part of GN&C as well (SSME failures came from GN&C).
Andy
-
#2442
by
elmarko
on 21 Dec, 2011 09:00
-
I think one of the (now publically accessible) training/documents you can download from NASA.gov is a brilliant overview of C&W. If not there then it's on L2 probably
-
#2443
by
sivodave
on 21 Dec, 2011 20:53
-
Also remember SM is part of PASS (SM OPS 2, for instance). PASS and BFS had separate SM functions. But fault detection and annunciation were part of GN&C as well (SSME failures came from GN&C).
Hi Andy! thanks for the clarification...I tripped my fingers on the keyboard
I meant SM and GNC.
I was reading on the SCOM the chapter about the C/W system and I think that now I've got how the whole thing works. Basically there are paramenters that are controlled by hardware only and in case of limit violation, the alarm goes off (like for Class 1 and Class 2 Primary alarms).
Class 2 primary alarms are shown on the C/W annunciation matrix on panel F7 along with aural warnings. The parameters that drive the matrix are 120 and can be set/read via manual inputs on panel R13U.
Class 2 backup alarms are instead triggered by SM software computations but are shown an dedicated display page on the MEDS monitors, and the parameters controlling the alarms can be set/read via SPEC 60 SM TABLE MAINTENANCE page. Regarding these last types of alarms what it gets me a bit confused is the word backup. Why is it called backup? I mean if I've understood well this type of alarms are triggered only by computations of the SM software and don't involve the same parameters that trigger the matrix on panel F7.
Basically it seems to me that the for Class 2 primary and backup alarms there are two different sets of parameters. Especially considering that the Class 2 backup alarms involves also violations of limits from GNC.
Furthermore it looks to me that the paramaters controlling the Class 2 backup alarms can be modified more deeply that the parameters for Class 2 primary alarms.
So bottom line my question is: why Class 2 backup alarms are called "backup"? Backup seems something that is there in case of primary system fails, but in this instance it looks to me that these alarms are quite complementary of Class 2 Primary ones. I mean it seems to me that Class 2 primary and backup alarms go side by side rather then as a emergency plan in case the primary fails.
Where am I right and where wrong?
Thanks very much
Davide
-
#2444
by
wolfpack
on 22 Dec, 2011 16:32
-
What could have been done in a scenario where the ET failed to separate? Would it be possible to extend the OMS burn and carry it into some sort of stable(ish) orbit, thus buying time to work the problem? Did crews train for that sort of thing?
-
#2445
by
Jim
on 22 Dec, 2011 20:11
-
What could have been done in a scenario where the ET failed to separate? Would it be possible to extend the OMS burn and carry it into some sort of stable(ish) orbit, thus buying time to work the problem? Did crews train for that sort of thing?
I believe it was a LOC event.
-
#2446
by
wolfpack
on 22 Dec, 2011 22:00
-
Because OMS doesn't have enough delta-v to raise the perigee of that combined mass high enough? I recall reading studies about orbiting an ET. Would that have been done by extending MECO by a few seconds?
-
#2447
by
alk3997
on 23 Dec, 2011 02:28
-
Also remember SM is part of PASS (SM OPS 2, for instance). PASS and BFS had separate SM functions. But fault detection and annunciation were part of GN&C as well (SSME failures came from GN&C).
Hi Andy! thanks for the clarification...I tripped my fingers on the keyboard I meant SM and GNC.
I was reading on the SCOM the chapter about the C/W system and I think that now I've got how the whole thing works. Basically there are paramenters that are controlled by hardware only and in case of limit violation, the alarm goes off (like for Class 1 and Class 2 Primary alarms).
Class 2 primary alarms are shown on the C/W annunciation matrix on panel F7 along with aural warnings. The parameters that drive the matrix are 120 and can be set/read via manual inputs on panel R13U.
Class 2 backup alarms are instead triggered by SM software computations but are shown an dedicated display page on the MEDS monitors, and the parameters controlling the alarms can be set/read via SPEC 60 SM TABLE MAINTENANCE page. Regarding these last types of alarms what it gets me a bit confused is the word backup. Why is it called backup? I mean if I've understood well this type of alarms are triggered only by computations of the SM software and don't involve the same parameters that trigger the matrix on panel F7.
Basically it seems to me that the for Class 2 primary and backup alarms there are two different sets of parameters. Especially considering that the Class 2 backup alarms involves also violations of limits from GNC.
Furthermore it looks to me that the paramaters controlling the Class 2 backup alarms can be modified more deeply that the parameters for Class 2 primary alarms.
So bottom line my question is: why Class 2 backup alarms are called "backup"? Backup seems something that is there in case of primary system fails, but in this instance it looks to me that these alarms are quite complementary of Class 2 Primary ones. I mean it seems to me that Class 2 primary and backup alarms go side by side rather then as a emergency plan in case the primary fails.
Where am I right and where wrong?
Thanks very much
Davide
Davide, a quick reply right now then more later. It's called backup C&W because it was a backup to the hardware panel. Remember in the late-1970s the whole concept of software doing C&W was new. So the hardware system was primary and the software was the secondary or backup system.
Over the years, the reliance on the software side grew more and more. There were plans for an enhanced C&W but those went away when the decision to end the program in 2010 (actually 2011, of course) was made. The enhanced system would have provided the crew more information based on multiple C&W indications.
Also be careful of confusing the MEDS built-in fault line with the GN&C or SM fault summary displays and message line. The GPC's fault summary displays (SM and GN&C) were the same whether the old MCDS or MEDS displays were used. Those displays were generated by the GPCs and sent to the MCDS/MEDS. The MEDS IDPs could also indicate internal faults and indicate those faults separately from the GPC displays on the MEDS fault line (since the GPC might not "know" about the MEDS faults). I know that's confusing and is one of the reaons the crews were interested in improving the display system onboard the orbiters (more information, less data).
I'm not sure I answered all your questions - let me know if you have more.
Andy
-
#2448
by
alk3997
on 23 Dec, 2011 02:35
-
What could have been done in a scenario where the ET failed to separate? Would it be possible to extend the OMS burn and carry it into some sort of stable(ish) orbit, thus buying time to work the problem? Did crews train for that sort of thing?
Let see...a dry external tank was about 58,000 lbs. So this would be the equivalent of hanging a 58,000 lbs payload over the black-side of the orbiter. The mass would have been well-off the normal cg and been about 1/4 to 1/5 of the total system mass, so I doubt the OMS would have been able to burn optimally.
I'd have to work out how much orbital improvement 23,000 lbs of OMS would have provided with 58,000 lbs of additional mass. Off the top of my head, even if you could get into orbit, you would not have enough to get back out of orbit. That assumes the cg could even be managed. Also the tank would still have residual propellant in it, so the weight figure I used was probably too low, anyway.
Andy
-
#2449
by
Jorge
on 23 Dec, 2011 07:00
-
What could have been done in a scenario where the ET failed to separate? Would it be possible to extend the OMS burn and carry it into some sort of stable(ish) orbit, thus buying time to work the problem? Did crews train for that sort of thing?
Let see...a dry external tank was about 58,000 lbs. So this would be the equivalent of hanging a 58,000 lbs payload over the black-side of the orbiter. The mass would have been well-off the normal cg and been about 1/4 to 1/5 of the total system mass, so I doubt the OMS would have been able to burn optimally.
I'd have to work out how much orbital improvement 23,000 lbs of OMS would have provided with 58,000 lbs of additional mass. Off the top of my head, even if you could get into orbit, you would not have enough to get back out of orbit. That assumes the cg could even be managed. Also the tank would still have residual propellant in it, so the weight figure I used was probably too low, anyway.
Andy
Realistically, this scenario is very remote probability due to the high reliability of the pyros and multiple redundancy. There were no published procedures for it, nor any crew training, nor (to my knowledge) did we ever sim it. Therefore what follows is just informed speculation on my part on what would have been *tried* had this happened.
I'd expect them to go ahead and attempt OMS-2 to buy time. I'd expect high RCS activity during OMS burns due to not being able to trim the OMS gimbals through the c.g.. Probably not much that could be done about it for OMS-2. Once in OPS2, I'd expect GNC to develop and uplink a DAP mass properties update which would improve control response a bit, but attitude control would still be sloppy (and involve high RCS usage).
(If this were to happen on a Hubble mission the crew would be hozed already since OMS-2 nominally uses half the OMS prop and deorbit uses the other half. The higher usage for OMS-2 with the ET attached alone would preclude deorbit. And of course they could not reach ISS.)
I'd expect the flight control team to conclude that a standalone EVA would be highly unlikely to fix the problem and that the only hope for the crew would be safe haven at ISS. In this scenario the orbiter is written off anyway, so the fact that there wouldn't be enough prop for deorbit is not a showstopper.
The big challenge would be prox ops and docking to ISS, since the off-center c.g. would cause increased cross-coupling from translational firings. Control would be sloppy, perhaps to the point of being uncontrollable, and both RCS usage and plume impingement loads on ISS would be increased. In particular, +/-Y axis translation (side-to-side) would couple into -Z translation (toward ISS), even worse than what normally happens using Low Z DAP, requiring frequent braking to prevent excessive closure rate.
-
#2450
by
wolfpack
on 23 Dec, 2011 12:35
-
What could have been done in a scenario where the ET failed to separate? Would it be possible to extend the OMS burn and carry it into some sort of stable(ish) orbit, thus buying time to work the problem? Did crews train for that sort of thing?
Let see...a dry external tank was about 58,000 lbs. So this would be the equivalent of hanging a 58,000 lbs payload over the black-side of the orbiter. The mass would have been well-off the normal cg and been about 1/4 to 1/5 of the total system mass, so I doubt the OMS would have been able to burn optimally.
I'd have to work out how much orbital improvement 23,000 lbs of OMS would have provided with 58,000 lbs of additional mass. Off the top of my head, even if you could get into orbit, you would not have enough to get back out of orbit. That assumes the cg could even be managed. Also the tank would still have residual propellant in it, so the weight figure I used was probably too low, anyway.
Andy
Realistically, this scenario is very remote probability due to the high reliability of the pyros and multiple redundancy. There were no published procedures for it, nor any crew training, nor (to my knowledge) did we ever sim it. Therefore what follows is just informed speculation on my part on what would have been *tried* had this happened.
I'd expect them to go ahead and attempt OMS-2 to buy time. I'd expect high RCS activity during OMS burns due to not being able to trim the OMS gimbals through the c.g.. Probably not much that could be done about it for OMS-2. Once in OPS2, I'd expect GNC to develop and uplink a DAP mass properties update which would improve control response a bit, but attitude control would still be sloppy (and involve high RCS usage).
(If this were to happen on a Hubble mission the crew would be hozed already since OMS-2 nominally uses half the OMS prop and deorbit uses the other half. The higher usage for OMS-2 with the ET attached alone would preclude deorbit. And of course they could not reach ISS.)
I'd expect the flight control team to conclude that a standalone EVA would be highly unlikely to fix the problem and that the only hope for the crew would be safe haven at ISS. In this scenario the orbiter is written off anyway, so the fact that there wouldn't be enough prop for deorbit is not a showstopper.
The big challenge would be prox ops and docking to ISS, since the off-center c.g. would cause increased cross-coupling from translational firings. Control would be sloppy, perhaps to the point of being uncontrollable, and both RCS usage and plume impingement loads on ISS would be increased. In particular, +/-Y axis translation (side-to-side) would couple into -Z translation (toward ISS), even worse than what normally happens using Low Z DAP, requiring frequent braking to prevent excessive closure rate.
Ok. Scary stuff!
How would the plans for intentionally orbiting an ET have worked then? If you extend MECO a bit, you can raise the perigee of a direct ascent Orbit high enough that it won't reenter? But then how to circularize the tank's orbit? I remember reading something about it (probably back when I had L2, need it again. Santa?
-
#2451
by
psloss
on 23 Dec, 2011 13:01
-
Ok. Scary stuff!
How would the plans for intentionally orbiting an ET have worked then? If you extend MECO a bit, you can raise the perigee of a direct ascent Orbit high enough that it won't reenter? But then how to circularize the tank's orbit?
It's in Jorge's answer if you also take into account that you wouldn't know there was an ET sep problem until
after MECO.
Excerpt:
I'd expect them to go ahead and attempt OMS-2 to buy time. I'd expect high RCS activity during OMS burns due to not being able to trim the OMS gimbals through the c.g.. Probably not much that could be done about it for OMS-2. Once in OPS2, I'd expect GNC to develop and uplink a DAP mass properties update which would improve control response a bit, but attitude control would still be sloppy (and involve high RCS usage).
-
#2452
by
CrudBasher
on 23 Dec, 2011 14:34
-
I tried searching for this but didn't find anything.
I noticed when the orbiters started their retirement flow one of the first things removed was the TPS tiles around the windows. Does anyone know why they were removed? Thanks!
-
#2453
by
mjp25
on 26 Dec, 2011 22:03
-
I used the search and actually believe I've read all shuttle Q&A responses and couldn't find an answer to this. Is there an engineering or other reason the shuttle side hatch opens the direction it does? It seems to me that when the orbiter it horizontal, up would be fighting gravity and left would be fighting gravity when the orbiter is vertical. That leaves down (the configuration chosen) or right when the orbiter is horizontal. Anyone know why down was chosen over right? Thanks!
-
#2454
by
Jim
on 26 Dec, 2011 23:49
-
I used the search and actually believe I've read all shuttle Q&A responses and couldn't find an answer to this. Is there an engineering or other reason the shuttle side hatch opens the direction it does? It seems to me that when the orbiter it horizontal, up would be fighting gravity and left would be fighting gravity when the orbiter is vertical. That leaves down (the configuration chosen) or right when the orbiter is horizontal. Anyone know why down was chosen over right? Thanks!
It opens down when the orbiter is horizontal, so the crew doesn't have to fight gravity during a post landing situation.
-
#2455
by
mjp25
on 27 Dec, 2011 12:58
-
I used the search and actually believe I've read all shuttle Q&A responses and couldn't find an answer to this. Is there an engineering or other reason the shuttle side hatch opens the direction it does? It seems to me that when the orbiter it horizontal, up would be fighting gravity and left would be fighting gravity when the orbiter is vertical. That leaves down (the configuration chosen) or right when the orbiter is horizontal. Anyone know why down was chosen over right? Thanks!
It opens down when the orbiter is horizontal, so the crew doesn't have to fight gravity during a post landing situation.
That makes sense. Thanks!
-
#2456
by
parham55
on 27 Dec, 2011 15:10
-
My search skills are lacking. Anyone care to help identify what turbine and/or provide some more context around this turbine blade? By context I mean a larger picture or explanation of this piece installed as ready for flight. Thanks.
Rob
-
#2457
by
Jim
on 27 Dec, 2011 15:35
-
My search skills are lacking. Anyone care to help identify what turbine and/or provide some more context around this turbine blade? By context I mean a larger picture or explanation of this piece installed as ready for flight. Thanks.
Rob
It is a flown turbine blade from an SSME. It is just an artifact that has flown into space. Unlike the patches and flags, this is a piece of operational hardware.
Major General Frank J. Simokaitis was commandant of the Air Force Institute of Technology and commandant of the Defense Institute of Security Assistance Management at Wright-Patterson Air Force Base, Ohio.
Don't know his post USAF career
-
#2458
by
parham55
on 27 Dec, 2011 16:02
-
Thank you, Jim. Is that a whole blade or just a piece? Any way to tell if it is from the fuel or oxidizer turbine? Is the ridged (bottom in the picture) end the portion that would be fit into the hub? Where is the leading edge of the blade?
I had dinner with General Simokaitis last night. Most of the time we were discussing his B-26 flying days. During training he belly landed in Texas after a prop sheered off the crank and the pilot bailed out after saying, "What are you going to do?"
-
#2459
by
kwan3217
on 27 Dec, 2011 16:02
-
The shuttle is famous for its four computers running the primary software simultaneously and a fifth running the backup flight software. Was this redundancy ever used? Did one of the four ever fail or disagree during a flight? Was the backup computer ever engaged as a backup?
I meant SM and GNC.