-
#2180 by psloss on 19 Aug, 2011 19:12
-
FWIW, winds approaching the HAC were 070 at 8 knots gusting to 13, which was pretty much a straight crosswind, and they performed the crosswind landing performance DTO (DTO 805). On final, they were updated to 070 at 7 gusting to 11.
-
#2181 by mtakala24 on 19 Aug, 2011 20:50
-
landing replay on youtube:
at 14min 44s mark.
although not shot from a good angle; the actual landing only from HUD camera. -
#2182 by psloss on 19 Aug, 2011 21:35
-
landing replay on youtube:
Also some excerpts of the live landing coverage I posted on L2; you can find that from the mission tag:
at 14min 44s mark.
although not shot from a good angle; the actual landing only from HUD camera.
http://forum.nasaspaceflight.com/index.php?action=tags&tags=STS-91
-
#2183 by STS-85 on 20 Aug, 2011 01:59
-
It didn't look like PIO.. more like just trying to make such a soft landing he brought it off the ground ever so slightly.. I didn't think it was major problem, or even a minor problem.. just noticed it and was wondering how/why it happened.
-
#2184 by vsrinivas on 20 Aug, 2011 21:09
-
Hi,
I saw a post earlier in this thread asking about source code for PASS. While its dramatically unlikely we'll see that anytime soon, there is a small consolation prize -- the Approach and Landing Test System Software Design Specification _is_ available. It is a 1580 page PDF with complete flowcharts (1977 style flowcharts, with every conditional expression present) of the FCOS and some really interesting stuff on GPC redundancy.
Link here: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19770075091_1977075091.pdf
The document only covers the system software, not flight software, sadly. But it is still a great document.
-
#2185 by Zpoxy on 21 Aug, 2011 00:17
-
Regarding Columbia, I was under the impression that the black chine areas were actually paint and not tiles. When Columbia arrived at KSC, and rolled over, the chine area wasnt black, however on rollout, it was. I was always told that it was due to engineers thinking that that area might experience more heat and it was treated with a black "paint".
I could be totally wrong, but just something I read somewhere.....
Please correct me if I am wrong.
Thanks!!
Partially correct. The black areas on the wing gloves were actually the original white tiles painted with a black thermal coating. We were told at the time it was to prevent the potential freezing of hydraulic lines in the mid fuselage. -
#2186 by alexw on 21 Aug, 2011 02:33
-
I saw a post earlier in this thread asking about source code for PASS. While its dramatically unlikely we'll see that anytime soon, there is a small consolation prize -- the Approach and Landing Test System Software Design Specification _is_ available. It is a 1580 page PDF with complete flowcharts (1977 style flowcharts, with every conditional expression present) of the FCOS and some really interesting stuff on GPC redundancy.
It's enormous. Any particularly interesting or revealing bits you've found thus far?
Link here: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19770075091_1977075091.pdf
The document only covers the system software, not flight software, sadly. But it is still a great document.
-Alex -
#2187 by alk3997 on 21 Aug, 2011 02:59
-
I saw a post earlier in this thread asking about source code for PASS. While its dramatically unlikely we'll see that anytime soon, there is a small consolation prize -- the Approach and Landing Test System Software Design Specification _is_ available. It is a 1580 page PDF with complete flowcharts (1977 style flowcharts, with every conditional expression present) of the FCOS and some really interesting stuff on GPC redundancy.
It's enormous. Any particularly interesting or revealing bits you've found thus far?
Link here: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19770075091_1977075091.pdf
The document only covers the system software, not flight software, sadly. But it is still a great document.
-Alex
Keep in mind many of the details changed before the first orbital flight. I was always impressed that my colleagues were able to get a redundant set working for ALT, which was almost a decade before I got there.
And, SSW (system software) is part of FSW (flight software) as was GN&C (guidance navigation & control), VU (vehicle utility) and SM (systems management). I believe the SSW folks would be upset to not be counted as FSW. They were amazing folks who did amazing things with very little software! They also had the ability to analyze GPC anomalies with amazing detail (when one of the very few GPC anomalies occurred).
Andy -
#2188 by alk3997 on 21 Aug, 2011 03:10
-
Opinions may vary, but I'd call it significantly different. The GPC status matrix was in front of the pilot instead of CDR, the fuel cell purge controls were on the upper front panel, the left and right overhead panels of switches were completely missing, panel R1 has three steam gauges on it, there is a ?backup? 'artificial horizon' on the fwd panels, most of the steam gauges are missing off the upper front panel....
By my comment, I meant that I could take someone trained on the later original orbital cockpit and put them in Enterprise's original cockpit and they would be able to fly approach and landing without almost any training. The stick is in the same place, the CRTs are the same vintage and location, the keyboards are in the same place, the electromechanical entry/landing tapes are the same, the ADI the same, the HSI the same, and the landing phase lights are the same place they were with Columbia's first flight. Yes, a few things are moved about and a lot is missing, but the basic layout design is the same. Most of what you mention as missing was missing because it wasn't needed yet (ascent or orbital items).
There was also an earlier question on the Enterprise (OV-101) differences. While Enterprise had fuel cells, they were different than the orbital system,
"The Electrical Power System (EPS) includes three fuel cells to provide electrical power for OV-101; however, high pressure bottles of gaseous oxygen and hydrogen will replace cryogenics for the fuel cell supply. Sufficient gaseous oxygen and hydrogen will be carried to allow for 208 minutes of EPS operation at the presently baselined power profile (59.9 kilowatt hours)."
Andy -
#2189 by vsrinivas on 21 Aug, 2011 05:31
-
It's enormous. Any particularly interesting or revealing bits you've found thus far?
-Alex
Depends on what you're looking for -- section 3.1.1.4 (FPMDISP) looks more or less like its analogue in any modern operating system, which is pretty cool!
Section 3.1.2 has a nice description of timers and events in the system. The design of TQEs (timer queue events) looks like something you'd see in software today. There was a watchdog timer -- not called that then, I suppose? Timers were interesting in that they were associated with Processes, so they were removed if a process was cancelled.
Section 3.1.3.3 describes a routine that is often subtle -- FPMSIGNAL -- set an event, allow it to wake sleeping processes, and then reset it. The Event Evaluator logic is pretty clever, more complex than most systems use today. It could probably be used to filter types of events coming in on a common event variable?
The GPC Synchronization flowcharts seem to be incomplete (marked "to be provided"); that's really unfortunate, GPC sync would have been one of the most difficult challenges for any operating system, even now. I wonder if there is a later version of this document that covers them, but probably not. The Approach and Landing tests themselves were Feb 1977 - Oct 1977. Maybe the GPC synchronization work wasn't available till later?
I mostly do operating systems work these days; from a modern perspective, this work seems heroic. On paper, there are flowcharts of every routine, every supervisor call, callers, and conditions worked out. All in 1977 (and earlier).
If you're familiar with modern avionics operating systems, particular ARINC653 compliant ones, you'll see a lot that is familiar; this work is a bit of a forerunner then.
The document doesn't have anything on stuff I wanted to see most, namely how the DAPs worked, though... :\. That would be elsewhere...Keep in mind many of the details changed before the first orbital flight. I was always impressed that my colleagues were able to get a redundant set working for ALT, which was almost a decade before I got there.
And, SSW (system software) is part of FSW (flight software) as was GN&C (guidance navigation & control), VU (vehicle utility) and SM (systems management). I believe the SSW folks would be upset to not be counted as FSW. They were amazing folks who did amazing things with very little software! They also had the ability to analyze GPC anomalies with amazing detail (when one of the very few GPC anomalies occurred).
Andy
Did many details of the FCOS change between ALT and the orbiter flights?
Sorry, didn't mean to slight them! I'm used to 'flight software' not covering system software; however it'd be very rare in a modern design for system software to be developed afresh for a project.
Would be pretty great to have some of them share memories of ALT or shuttle work
Thanks,
-- vs -
#2190 by alk3997 on 21 Aug, 2011 15:20
-
Yes, many of the details continued to change between ALT and OFT (orbital flight tests - STS-1 through STS-4). The ALT FCOS was good enough to handle take-off from the ground on the 747, separating from the 747, approach & landing and then post-landing shutdown. It wasn't ready for orbital flights yet, which included OPS overlays and a lot longer run time, among other major items. So, yes, there was much to go and other changes even after OFT - GPS caused changes, for instance.
Keep in mind the idea of just *having* four flight computers and a digital databus on an aerospace vehicle was very new in the late 1970s and early 1980s. The idea of synchronizing them in this scheme was even more unusual. It would have been impossible to create a finished product for ALT. The Shuttle's flight computer system really did push the state-of-the-art at the time.
The FCOS operating system was first created in the 1970s and maintained throughout the next thirty years of flights. BOS for BFS was also also created specifically for the Shuttle program.
While you may not do that now for cost reasons, we had the advantage that if there was a question about the O/S, the people just down the hall knew everything about your O/S. You didn't have to go far for an answer.
You might also want to read this, if you haven't already...
http://klabs.org/DEI/Processor/shuttle/shuttle_primary_computer_system.pdf
Some of it was a little dated, such as the quality metrics which were even better towards the middle-to-end of the program and the company name, of course. But, there are some good factoids in that paper.
And, yes, GPC sync was definitely working for ALT. Watch the NASA video on the ALT flights ("Go For Sep") and you'll see GPC 2 being voted out of the redundant set right after separation on the first ALT free flight. Can't be voted out if you don't have a synchronization scheme. Just don't consider the document you found to be a final version of (well) anything. When the program ended we were flying OI-34 - lots of time for changes.
Besides the operating system we also maintained (and modified) the compiler, as well. One stop shopping...
Andy -
#2191 by vsrinivas on 21 Aug, 2011 18:07
-
You might also want to read this, if you haven't already...
http://klabs.org/DEI/Processor/shuttle/shuttle_primary_computer_system.pdf
Some of it was a little dated, such as the quality metrics which were even better towards the middle-to-end of the program and the company name, of course. But, there are some good factoids in that paper.
Yep, it was an interesting read! I'd actually had some questions about it though...
The article described a high-priority process that would be scheduled every 40 mS; the process would switch on cycle # to determine what to do.
Is there any reason it was designed that way? Rather than having each subset of things to do in a separate cyclic process executed at its true rate?
Also, I seem to remember hearing that the RCS jets couldn't be commanded at 40 mS, there was some problem with pressure waves in the feed lines or something to that effect that required them to be commanded at 80mS; was the high-priority process constrained to only command the RCS jets every other cycle?
Something I was wondering about, how did the system report when a cyclic process couldn't be run at its scheduled time? I suspect there'll be an answer in the ALT FCOS, but I haven't found it yet...And, yes, GPC sync was definitely working for ALT. Watch the NASA video on the ALT flights ("Go For Sep") and you'll see GPC 2 being voted out of the redundant set right after separation on the first ALT free flight. Can't be voted out if you don't have a synchronization scheme. Just don't consider the document you found to be a final version of (well) anything. When the program ended we were flying OI-34 - lots of time for changes.
I'd never seen that video before; thanks very much!
-
#2192 by Jorge on 21 Aug, 2011 20:08
-
Also, I seem to remember hearing that the RCS jets couldn't be commanded at 40 mS, there was some problem with pressure waves in the feed lines or something to that effect that required them to be commanded at 80mS; was the high-priority process constrained to only command the RCS jets every other cycle?
The constraint was in the DAP rather than the high-frequency executive. To respect the 80 ms limitation, the DAP was only scheduled to run every other HFE cycle. -
#2193 by alk3997 on 21 Aug, 2011 20:32
-
Remember PASS was designed to handle processes asynchronously unlike BFS which was synchronous and had definite scheduling. In PASS, processes were handled in a priority manner so that the high priority items would run and we made sure there was enough margin to handle all of those processes. If we didn't have time to handle a high priority process, a GPC cycle overrun error would be annunicated. Again, though there was much done to make sure we didn't get those "errors" (although there were some circumstances that one would occur and it was analyzed to death when they happened). BTW, in all of those cases the delayed process would complete in the next cycle and the system was designed that way.
-
#2194 by vsrinivas on 21 Aug, 2011 20:51
-
Also, I seem to remember hearing that the RCS jets couldn't be commanded at 40 mS, there was some problem with pressure waves in the feed lines or something to that effect that required them to be commanded at 80mS; was the high-priority process constrained to only command the RCS jets every other cycle?
The constraint was in the DAP rather than the high-frequency executive. To respect the 80 ms limitation, the DAP was only scheduled to run every other HFE cycle.
Sorry, the DAP was a separate process? The klabs document only listed the high frequency executive, the guidance process (160 ms), navigation, and keyboards/displays, though they did say there were many more.
-
#2195 by alk3997 on 21 Aug, 2011 20:58
-
Everything was a separate process (or multiple processes) in one way or another. Remember they had to fit in their chunks of time, so you had different processes for different activities such as sequencers. Very complicated and required a real-time O/S to handle it 100% (or at least many many 9s) reliably.
This reference is probably a much higher level than you want but it provides an overview of the computing power on the vehicles,
http://www.nasa.gov/mission_pages/shuttle/flyout/flyfeature_shuttlecomputers.html
Andy -
#2196 by Jorge on 22 Aug, 2011 00:24
-
Everything was a separate process (or multiple processes) in one way or another. Remember they had to fit in their chunks of time, so you had different processes for different activities such as sequencers. Very complicated and required a real-time O/S to handle it 100% (or at least many many 9s) reliably.
This reference is probably a much higher level than you want but it provides an overview of the computing power on the vehicles,
http://www.nasa.gov/mission_pages/shuttle/flyout/flyfeature_shuttlecomputers.html
Andy
Right, as I understood it, the system SW had the HFE, MFE, and LFE, and all the application SW processes ran at an integer multiple of one of those three executives. -
#2197 by alk3997 on 22 Aug, 2011 01:37
-
Everything was a separate process (or multiple processes) in one way or another. Remember they had to fit in their chunks of time, so you had different processes for different activities such as sequencers. Very complicated and required a real-time O/S to handle it 100% (or at least many many 9s) reliably.
This reference is probably a much higher level than you want but it provides an overview of the computing power on the vehicles,
http://www.nasa.gov/mission_pages/shuttle/flyout/flyfeature_shuttlecomputers.html
Andy
Right, as I understood it, the system SW had the HFE, MFE, and LFE, and all the application SW processes ran at an integer multiple of one of those three executives.
Yes. LFE was for the lowest priority items, such as display updates. Of course we're talking about GN&C OPS modes - SM & VU had different processes. I have to admit I never really understood how the OPS 9 (ground) processes were scheduled (didn't really need to).
Andy -
#2198 by Mark Dave on 22 Aug, 2011 12:24
-
What was the purpose of the black markings on the SRB nose cones and frustum seen in the later half of the 80s and early to mid 90s? For example This is what they look like now http://upload.wikimedia.org/wikipedia/commons/e/ed/STS-135_SRB_right_and_left_forward_assemblies.jpg compared to back in the decades prior http://enterfiringroom.ksc.nasa.gov/Images/Gallery/STS26R.jpg http://www.friends-partners.org/mwade/graphics/s/sts.jpg
-
#2199 by Jim on 22 Aug, 2011 12:37
-
Camera tracking, to help differentiate the boosters.
