mike@uc780.umd.edu (02/28/91)
John, Feel free to post more info from that article, like specifics perhaps on the processor itself. I have been wanting to get more info on this subject for some time (personal curiosity) ever since I heard they were finally going to scrap the peice-of-ancient-history AP101B's with something that wasn't at least quite so ancient technologically speaking. Mike Santangelo Academic Computing UMUC
jfw@ksr.com (John F. Woods) (02/28/91)
The Electronic Engineering Times for 25 February 1991 has an article about
the new shuttle computers which are scheduled to fly on Discovery "next week."
The new AP101S computers use static-RAM memory and Schottky logic, replacing
the old core-memory AP101B computers. A summary of the differences:
Memory First
Memory tech- CPU Size, Shuttle
Computer size nology Speed Weight Power MTBF Flight
AP101S 128Kx2 Radiation 1.2 Mips 1 box, 550W 20,000+ hrs. 3/91 STS-39
32-bit resistant 10x9x18'
words CMOS SRAM 64 pounds
AP101B 104Kx1 Ferrite 0.4 Mips 2 boxes, 650W 5,200 hrs. 4/81 STS-1
32-bit cores 10x8x19'
words 120 pounds
(I'm suspicious of the size figures; I'd expect them to be the same size,
and I have quite carefully preserved the single-tick foot unit indicator,
even though the box obviously does not dwarf the technicians next to it in
the front page photo... :-)
To improve the radiation resistance of the "radiation resistant" SRAMs,
they use 25 check-bits for each 16-bit halfword, and a background task
scrubs out soft ECC errors from all of memory every two seconds.
The article also includes a sidebar on complaints by IBM about how silly
NASA is about specifications and obsolete component qualification methods.shafer@skipper.dfrf.nasa.gov (Mary Shafer) (02/28/91)
In article <27FEB91.17144348@uc780.umd.edu> mike@uc780.umd.edu writes:
Feel free to post more info from that article, like specifics perhaps
on the processor itself. I have been wanting to get more info on this
subject for some time (personal curiosity) ever since I heard they were
finally going to scrap the peice-of-ancient-history AP101B's with
something that wasn't at least quite so ancient technologically speaking.
Some people who worked on the F-8 DFBW phase II, with the AP-101s,
think that these are a piece of something else entirely.
(Phase I used Apollo computers, salvaged from returned capsules.
When Dave Scott left Dryden, one of the presentations was "his"
Apollo computer.)
--
Mary Shafer shafer@skipper.dfrf.nasa.gov ames!skipper.dfrf.nasa.gov!shafer
NASA Ames Dryden Flight Research Facility, Edwards, CA
Of course I don't speak for NASA
"A MiG at your six is better than no MiG at all"--Unknown US fighter pilotphil@eecs.nwu.edu (William LeFebvre) (03/05/91)
In article <2352@ksr.com>, jfw@ksr.com (John F. Woods) writes: |> The Electronic Engineering Times for 25 February 1991 has an article about |> the new shuttle computers which are scheduled to fly on Discovery "next week." |> The new AP101S computers use static-RAM memory and Schottky logic, replacing |> the old core-memory AP101B computers. Does the article say if the RAM is battery-backed or otherwise anything in place to make the memory non-volatile? One standard procedure is "freeze-drying" a GPC (general purpose computer), which relies on the memory being non-volatile. I'm curious if they are going to scrap that procedure or not. Freeze-drying consists of loading the re-entry software into a GPC and turning the GPC off. That way if the tape drives that contain the software both break, at least they have one computer to get them home again. Thanks for the summary! My wife will be most interested in it. William LeFebvre Computing Facilities Manager and Analyst Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
jfw@ksr.com (John F. Woods) (03/05/91)
phil@eecs.nwu.edu (William LeFebvre) writes: >In article <2352@ksr.com>, jfw@ksr.com (John F. Woods) writes: >|>The Electronic Engineering Times for 25 February 1991 has an article about >|>the new shuttle computers which are scheduled to fly on Discovery "next week." >|>The new AP101S computers use static-RAM memory and Schottky logic, replacing >|>the old core-memory AP101B computers. >Does the article say if the RAM is battery-backed or otherwise anything >in place to make the memory non-volatile? One standard procedure is >"freeze-drying" a GPC (general purpose computer), which relies on the >memory being non-volatile. The article specifically mentions leaving several flight routines in "battery-backed SRAM", avoiding having to load them off of tape in-flight. The article doesn't say whether all the SRAM is battery-backed or just some choice piece, though.
jdeitch@umiami.ir.miami.edu (Jonathan Deitch) (03/05/91)
phil@eecs.nwu.edu (William LeFebvre) writes: > In article <2352@ksr.com>, jfw@ksr.com (John F. Woods) writes: > |> The Electronic Engineering Times for 25 February 1991 has an article about > |> the new shuttle computers which are scheduled to fly on Discovery "next week." > |> The new AP101S computers use static-RAM memory and Schottky logic, replacing > |> the old core-memory AP101B computers. > > Does the article say if the RAM is battery-backed or otherwise anything > in place to make the memory non-volatile? One standard procedure is > "freeze-drying" a GPC (general purpose computer), which relies on the > memory being non-volatile. I'm curious if they are going to scrap that > procedure or not. Freeze-drying consists of loading the re-entry software > into a GPC and turning the GPC off. That way if the tape drives that > contain the software both break, at least they have one computer to > get them home again. > > Thanks for the summary! My wife will be most interested in it. > > William LeFebvre > Computing Facilities Manager and Analyst > Department of Electrical Engineering and Computer Science > Northwestern University > <phil@eecs.nwu.edu> Static RAM memory, I believe, is non volatile memory. - Jonathan ------------------------------------------------------------------- Internet : jdeitch@umiami.miami.edu "Good musicians execute their music but bad ones Voice : (305) - 284 - 6482 murder it !!! "
jdeitch@umiami.ir.miami.edu (Jonathan Deitch) (03/06/91)
Sorry folks,
Static Ram is NOT non volatile. It simply doesn't need refreshing.
When the power goes off, so does the data.
There might be hope, though. Radio Electronics magazine recently
had an article about standard CMOS with little ferric capacitors
etched right onto the chip to keep the logic gates intact when the
power is removed. According to the article, it can keep data safe
for up to one year. If this technology is successful, it could be
the next version of the flight computer.
-------------------------------------------------------------------
Internet : jdeitch@umiami.miami.edu "Good musicians execute
their music but bad ones
Voice : (305) - 284 - 6482 murder it !!! "sking@nowhere.uucp (Steven King) (03/06/91)
In article <1991Mar5.013344.7971@umiami.ir.miami.edu> jdeitch@umiami.ir.miami.edu (Jonathan Deitch) writes: >phil@eecs.nwu.edu (William LeFebvre) writes: >> In article <2352@ksr.com>, jfw@ksr.com (John F. Woods) writes: >> |> The Electronic Engineering Times for 25 February 1991 has an article about >> |> the new shuttle computers which are scheduled to fly on Discovery "next week." >> |> The new AP101S computers use static-RAM memory and Schottky logic, replacing >> |> the old core-memory AP101B computers. >> >> Does the article say if the RAM is battery-backed or otherwise anything >> in place to make the memory non-volatile? One standard procedure is > >Static RAM memory, I believe, is non volatile memory. > No, static ram simply doesnt require the refresh cycle that dynamic ram requires. It is still volatile -- you'll lose the contents if it loses power. While its encouraging that NASA is finally moving beyond core memory for the shuttle ( welcome to the 90's ), why use writeable memory for program storage? As their code is extremely stable, it shouldnt be any problem to put everything they use into masked roms without any great penalty in weight or size ( mask roms have much better density than static rams ) with it all non volatile, non writeable. With the 230 lbs they saved they could put a couple hundred meg disk array on each CPU and... Ooops! A technology must be atleast 10 years old before they trust it on the shuttle... The sidebar to the article was atleast as interesting as the article; It concerned the testimony of Dr Lewis Branscom to the House Science, Technology and Space Committee. [ ... ] "I was startled to discover that NASA did not allow any hardware to fly that was not previously flown--we sold them 1968 technology" said Branscom. "I was even more shocked that NASA declined to give an MTBF [mean time between failure] for each of the five [general purpose computers that IBM sold NASA]. They would not give us a spec, but instead a goal. I believe it was 1,640 hours. We at IBM doubled that for internal guidence and peace of mind." said Branscom. In contrast, he noted that "the mean time between failure for a $2,000 computer for your home carries a commercial spec of 10,000 hours." [ ... ] ( and is a lot more powerfull as well ) -- Look Ma! No .sig! ..!cs.utexas.edu!ut-emx!nowhere!sking
henry@zoo.toronto.edu (Henry Spencer) (03/06/91)
In article <1991Mar5.013344.7971@umiami.ir.miami.edu> jdeitch@umiami.ir.miami.edu (Jonathan Deitch) writes: >Static RAM memory, I believe, is non volatile memory. No. "Static" and "dynamic" refer to irrelevant details of the memory technology; both are volatile unless battery backup or something similar is done. (Static memory *is* more amenable to battery backup.) -- "But this *is* the simplified version | Henry Spencer @ U of Toronto Zoology for the general public." -S. Harris | henry@zoo.toronto.edu utzoo!henry
mike@UC780.UMD.EDU (Mike Santangelo) (03/07/91)
In article <1991Mar5.013344.7971@umiami.ir.miami.edu>, jdeitch@umiami.ir.miami.edu (Jonathan Deitch) writes: >phil@eecs.nwu.edu (William LeFebvre) writes: >> In article <2352@ksr.com>, jfw@ksr.com (John F. Woods) writes: >> |> The Electronic Engineering Times for 25 February 1991 has an article about >> |> the new shuttle computers which are scheduled to fly on Discovery "next week." >> |> The new AP101S computers use static-RAM memory and Schottky logic, replacing >> |> the old core-memory AP101B computers. >> >> Does the article say if the RAM is battery-backed or otherwise anything >> in place to make the memory non-volatile? One standard procedure is >> "freeze-drying" a GPC (general purpose computer), which relies on the >> memory being non-volatile. I'm curious if they are going to scrap that >> procedure or not. Freeze-drying consists of loading the re-entry software >> into a GPC and turning the GPC off. That way if the tape drives that >> contain the software both break, at least they have one computer to >> get them home again. >> >> Thanks for the summary! My wife will be most interested in it. >> >> William LeFebvre >> Computing Facilities Manager and Analyst >> Department of Electrical Engineering and Computer Science >> Northwestern University >> <phil@eecs.nwu.edu> > >Static RAM memory, I believe, is non volatile memory. > >- Jonathan >------------------------------------------------------------------- >Internet : jdeitch@umiami.miami.edu "Good musicians execute > their music but bad ones >Voice : (305) - 284 - 6482 murder it !!! " Nope, sorry, STATIC RAM is quite volatile. It just doesn't need to be refreshed every so many milliseconds like Dynamic RAM. If you remove power to it though, data goes away. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Michael F. Santangelo + Inet: mike@uc780.umd.edu VMS / UNIX Systems + mike@socrates.umd.edu Academic Computing UMUC + Bnet: MIKE@UC780 (The University of Maryland, + MIKE@UMUC (not visited often) University College) +<Your clever net-phrase here>
jwl@garnet.berkeley.edu (James Wilbur Lewis) (03/07/91)
In article <1991Mar06.063034.12021@nowhere.uucp> sking@nowhere.uucp (Steven King) writes: > > With the 230 lbs they saved they could put a couple hundred meg disk > array on each CPU and... ...watch their data get turned into a worthless pile of iron oxide if the spacecraft changes attitude while the drives are spinning! -- Jim Lewis
jdeitch@umiami.ir.miami.edu (Jonathan Deitch) (03/07/91)
jwl@garnet.berkeley.edu (James Wilbur Lewis) writes: > In article <1991Mar06.063034.12021@nowhere.uucp> sking@nowhere.uucp (Steven King) writes: >> >> With the 230 lbs they saved they could put a couple hundred meg disk >> array on each CPU and... > > ....watch their data get turned into a worthless pile of iron oxide if > the spacecraft changes attitude while the drives are spinning! > > -- Jim Lewis Hmm. Never thought of that. I'm still in the dark ages (using an Apple II) so I've not much firsthand experience with hard drives but I understand they are incredibly finicky and it seems perfectly plausible that not only would an attitude change wreck the drives but the vibrations of liftoff probably wouldn't do much good either. Anyway, since we're discussing technology too new for NASA, what about optical drives - a CD-ROM drive (apart from being slow) would be perfect for a non changing program like the STS uses. - Jonathan (yes the person responsible for non-volative S-RAM !!) ------------------------------------------------------------------- Internet : jdeitch@umiami.miami.edu "Good musicians execute their music but bad ones Voice : (305) - 284 - 6482 murder it !!! "
session@uncw.UUCP (Zack C. Sessions) (03/08/91)
jwl@garnet.berkeley.edu (James Wilbur Lewis) writes: >In article <1991Mar06.063034.12021@nowhere.uucp> sking@nowhere.uucp (Steven King) writes: >> >> With the 230 lbs they saved they could put a couple hundred meg disk >> array on each CPU and... >...watch their data get turned into a worthless pile of iron oxide if >the spacecraft changes attitude while the drives are spinning! >-- Jim Lewis I have heard of a "military spec" for hard drives which when adhered to guarentees hard disks which can be mounted in any attitude (upside down or whatever) and can withstand shock of several Gs with no adverse effects. Of course, I would have guessed that onthe Shuttle, they would be using solid state "drives". Zack Sessions session@uncw.UUCP
joefish@disk.uucp (joefish) (03/08/91)
In article <1991Mar5.201242.7993@umiami.ir.miami.edu> jdeitch@umiami.ir.miami.edu (Jonathan Deitch) writes: >Sorry folks, > >Static Ram is NOT non volatile. It simply doesn't need refreshing. > >When the power goes off, so does the data. > >There might be hope, though. Radio Electronics magazine recently >had an article about standard CMOS with little ferric capacitors >etched right onto the chip to keep the logic gates intact when the >power is removed. According to the article, it can keep data safe >for up to one year. If this technology is successful, it could be >the next version of the flight computer. >------------------------------------------------------------------- >Internet : jdeitch@umiami.miami.edu "Good musicians execute > their music but bad ones >Voice : (305) - 284 - 6482 murder it !!! " Non-volatile RAM is in large supply now. It is used extensively in portable computers, and even as non-volatile RAM-disks on portables instead of floppy drives. I don't know if it would be better than battery powered backup RAM or not, and it would certainly cost more. There are several kinds of chips that are non-volatile, such as electronically eraseable eprom and UV eraseable EPROM, but the design of the system and the long lead time needed to develop the required reliability may prevent some of the newer chips from being used. Joe Fischer joefish@disk.UUCP
gregc@cimage.com (Greg Cronau) (03/09/91)
In article <1991Mar5.013344.7971@umiami.ir.miami.edu> jdeitch@umiami.ir.miami.edu (Jonathan Deitch) writes: >phil@eecs.nwu.edu (William LeFebvre) writes: >> In article <2352@ksr.com>, jfw@ksr.com (John F. Woods) writes: >> |> The Electronic Engineering Times for 25 February 1991 has an article about >> |> the new shuttle computers which are scheduled to fly on Discovery >> |> The new AP101S computers use static-RAM memory and Schottky logic >> >> Does the article say if the RAM is battery-backed or otherwise anything >> in place to make the memory non-volatile? One standard procedure is >> "freeze-drying" a GPC (general purpose computer), which relies on the > >Static RAM memory, I believe, is non volatile memory. > >- Jonathan Argh. Non-volatile, when referring to computer memory, refers to storage media that can maintain the stored data in the absence of power. Core planes, rom, prom, eprom, eeprom, and bubble memory are non-volatile. Random-Access-Memory(RAM) comes in 2 flavors: dynamic and static. Dynamic memory requires an occaisional memory refresh pulse to maintian the stored data. If the refresh is lost, the data is lost. Static memory, OTOH, can maintain it's data without any kind of refresh mechanism. Both types require the continual presence of electrical power, however small, to maintain data. gregc@cimage.com
gregc@cimage.com (Greg Cronau) (03/09/91)
In article <1991Mar06.063034.12021@nowhere.uucp> sking@nowhere.uucp (Steven King) writes: > > While its encouraging that NASA is finally moving beyond core memory > for the shuttle ( welcome to the 90's ), why use writeable memory for You mean: Welcome to the 70's! :-) gregc@cimage.com
gregc@cimage.com (Greg Cronau) (03/09/91)
In article <1991Mar7.010752.10632@agate.berkeley.edu> jwl@garnet.berkeley.edu (James Wilbur Lewis) writes: >In article <1991Mar06.063034.12021@nowhere.uucp> sking@nowhere.uucp (Steven King) writes: >> >> With the 230 lbs they saved they could put a couple hundred meg disk >> array on each CPU and... > >...watch their data get turned into a worthless pile of iron oxide if >the spacecraft changes attitude while the drives are spinning! > >-- Jim Lewis Actually, no. I have moved hard drives through several axies of rotation while working on them to no ill effect. I would *not* recommend this be done on a regular basis, however. Modern, small radius platers with light weight winchester head technology should not be adversly affected. I doubt that very much engineering work would be required to rate a drive for an environment in which it would have to survive axis re-orientation while operating. Most 3.5" harddrives that are used in laptops have to able to handle this. HOWEVER, I would be much more worried about the effects of launch and re-entry vibrations on the drive. THAT would be the killer. The bottom line is that harddrives are only useful in situations where you will be *writing* alot of new data. The control program for the shuttle is only *read* during flight, never written. A read only tape drive can be made much more rugged than a hard drive. gregc@cimage.com
sysmgr@KING.ENG.UMD.EDU (Doug Mohney) (03/10/91)
In article <1991Mar9.044834.27802@cimage.com>, gregc@cimage.com (Greg Cronau) writes: >done on a regular basis, however. Modern, small radius platers with light >weight winchester head technology should not be adversly affected. I doubt >that very much engineering work would be required to rate a drive for an >environment in which it would have to survive axis re-orientation while >operating. Most 3.5" harddrives that are used in laptops have to able to >handle this. Yah, but most 3.5" hard drives are not in the process of being used whilst being moved around (ie: You don't use a laptop on a rollercoster). Of course, some brilliance will make the next generation of hard drives without (many) moving parts in the next 2 years and they'll get retrofitted to the shuttle follow-on in oh, 2030 :-) > The bottom line is that harddrives are only useful in situations where >you will be *writing* alot of new data. The control program for the >shuttle is only *read* during flight, never written. A read only tape drive >can be made much more rugged than a hard drive. Ick. Tape is slow. I like the CD-ROM idea better. Reform may be dying in the Soviet Union, but we have the right to introduce it to the DECUS Board of Directors. -- > SYSMGR@CADLAB.ENG.UMD.EDU < --
shafer@skipper.dfrf.nasa.gov (Mary Shafer) (03/10/91)
In article <1991Mar9.044834.27802@cimage.com> gregc@cimage.com (Greg Cronau) writes: > The bottom line is that harddrives are only useful in situations where >you will be *writing* alot of new data. The control program for the >shuttle is only *read* during flight, never written. A read only tape drive >can be made much more rugged than a hard drive. Well, then, hard drives are in a lot of trouble and will probably never fly. We were using a read-only tape drive in the F-15 HIDEC (Highly Integrated Digital Engine Control) when we were doing one phase of a trajectory control program. We ended up aborting a lot of trajectory guidance flights when the miserable tape drive died as we tried to load the trajectory guidance code and checkpoints shortly after takeoff. We weren't doing anything like high-g maneuvering, either. Just taxi, takeoff, and try to load on climbout. Fortunately we had contingency flight cards and could do other test points. The Shuttle flight control system is another matter entirely. -- Mary Shafer shafer@skipper.dfrf.nasa.gov ames!skipper.dfrf.nasa.gov!shafer NASA Ames Dryden Flight Research Facility, Edwards, CA Of course I don't speak for NASA "A MiG at your six is better than no MiG at all"--Unknown US fighter pilot
amichiel@rodan.acs.syr.edu (Allen J Michielsen) (03/11/91)
In article <SHAFER.91Mar9103052> shafer@skipper.dfrf.nasa.gov (Mary Shafer) >In article <1991Mar9.044834.27802@cimage.com> gregc@cimage.com (Greg Cronau) >> The bottom line is that harddrives are only useful in situations where >>you will be *writing* alot of new data. The control program for the >>shuttle is only *read* during flight, never written. A read only tape drive >>can be made much more rugged than a hard drive. I don't have proof positive, but would wager sums of money that the shuttle 'system' is NOT read only, else nasa would have certainly done 'rom' work. A MAJOR defect of tape systems in interactive systems like flight controls is the search/seek/acquire time. When the shuttle is traveling mach 3 and it yaws slightly or is determined to be off course slightly, a several second delay while the appropriate correction program/data is loaded could be tragic. The same can be said about the prefromance problem if all data is out together, and miles of tape needs to be fast forwarded as the shuttle transitions between major segments of it's mission (1. ignition, 2. launch, 3. clear tower, 4. roll 5. etc....) >We were using a read-only tape drive in the F-15 HIDEC (Highly >Integrated Digital Engine Control) when we were doing one phase of a >trajectory control program. We ended up aborting a lot of trajectory >guidance flights when the miserable tape drive died as we tried to >load the trajectory guidance code and checkpoints shortly after >takeoff. We weren't doing anything like high-g maneuvering, either. >Just taxi, takeoff, and try to load on climbout. As hard drive technology improves, density increases, head size decreases, amplifier/noise improves, shock/temp stability improves, all of whiich we see every day, EVENTUALLY, they (nasa/contractors) will probably be able to make drives that have enough head fly space & 'stuff' like density, speed, etc, that will make them reliable enough for the demanding rigors of space flight or sim. I've heard it flung around about portable drives and stuff, but this is like comparing a skateboard to a porsche. Ask a few people who were using computers during the world series earthquakes. The reports I've seen put the computer damage in the millions, and that wasn't just water damage or stuff either... I have yet to see anybody using a portable that was moving in 3 axis, vibrating 'inc' at multiple frequencies and accelerating and decelerating through multiple planes simultaneously. Mary's story provides a indication just how rugged and demanding data i/o services need to be for hostile enviroments AND what happens EVEN when the hostile environment is planned for. I wish Mary was able to provide a bit more info in regards to the flight/data system. Such as how much tape storage and other data storage was required for the system described. And possibly a indication of how long a period of time during which the biggest portion of this was to be done. I suspect that even this system had to have compromises made, and experienced a forced reduction of desired data. Further that these limits efectively lengthened the total time (number of flights) required to complete everything desired. The shear amount of data for even 1 flight handled would astound most people in both volume and time. al -- Al. Michielsen, Mechanical & Aerospace Engineering, Syracuse University InterNet: amichiel@rodan.acs.syr.edu amichiel@sunrise.acs.syr.edu Bitnet: AMICHIEL@SUNRISE
yamauchi@cs.rochester.edu (Brian Yamauchi) (03/11/91)
In article <1991Mar10.164459.5216@rodan.acs.syr.edu> amichiel@rodan.acs.syr.edu (Allen J Michielsen) writes: >As hard drive technology improves, density increases, head size decreases, >amplifier/noise improves, shock/temp stability improves, all of whiich we >see every day, EVENTUALLY, they (nasa/contractors) will probably be able to >make drives that have enough head fly space & 'stuff' like density, speed, >etc, that will make them reliable enough for the demanding rigors of space >flight or sim. I've heard it flung around about portable drives and stuff, >but this is like comparing a skateboard to a porsche. >I have yet to see anybody using a portable that was >moving in 3 axis, vibrating 'inc' at multiple frequencies and accelerating >and decelerating through multiple planes simultaneously. I recall that a GRID portable computer (with hard drive) *was* flown on a shuttle flight. I also seem to remember that it had more computing power and memory than *all* of the shuttle's onboard computers... I believe it was used for plotting the shuttle's position and trajectory. Does anyone have the details? -- _______________________________________________________________________________ Brian Yamauchi University of Rochester yamauchi@cs.rochester.edu Department of Computer Science _______________________________________________________________________________
sking@nowhere.uucp (Steven King) (03/11/91)
In article <1991Mar10.164459.5216@rodan.acs.syr.edu> amichiel@rodan.acs.syr.edu (Allen J Michielsen) writes: >In article <SHAFER.91Mar9103052> shafer@skipper.dfrf.nasa.gov (Mary Shafer) >>In article <1991Mar9.044834.27802@cimage.com> gregc@cimage.com (Greg Cronau) >>> The bottom line is that harddrives are only useful in situations where >>>you will be *writing* alot of new data. The control program for the >>>shuttle is only *read* during flight, never written. A read only tape drive >>>can be made much more rugged than a hard drive. > > I don't have proof positive, but would wager sums of money that the shuttle >'system' is NOT read only, else nasa would have certainly done 'rom' work. >A MAJOR defect of tape systems in interactive systems like flight controls >is the search/seek/acquire time. When the shuttle is traveling mach 3 and >it yaws slightly or is determined to be off course slightly, a several second >delay while the appropriate correction program/data is loaded could be tragic. >The same can be said about the prefromance problem if all data is out together, >and miles of tape needs to be fast forwarded as the shuttle transitions between >major segments of it's mission (1. ignition, 2. launch, 3. clear tower, 4. roll >5. etc....) > This is precisely what the AP101B required. Again quoting from the article in the E E Times; "we've always underestimated memory requirements in the shuttle program" Littleton [ manager at JSC Orbiter Avionics Systems office ] said. "We had a concern for transition from orbiter ascent-type software to re-entry software in the case we might need a transatlantic abort". As a result of the new computer-data organization, NASA will use the extra memory to place in SRAM many of the flight routines that previously were off-line -- resident on tape drives that required them to be loaded into system memory on demand. Now these commands could be at the ready in battery backed SRAM, boosting the flexibility of the shuttle mission. It would be interesting to see some of this software. Some early 70's fortran code no doubt... -- Look Ma! No .sig! ..!cs.utexas.edu!ut-emx!nowhere!sking
roberts@CMR.NCSL.NIST.GOV (John Roberts) (03/12/91)
>From: cabp10@vaxa.strath.ac.uk (Theora Jones, In Person!) >Newsgroups: sci.space.shuttle >Subject: Re: New (!?!?!?!) Shuttle Computers >Date: 7 Mar 91 14:23:11 GMT > Excuse me for my ignorance in this matter, but I'm still a student and I find >it completely unbelievable that NASA are using technology that even 'toy' >home computers no longer use... > Core memories???? I was under the impression they went out about the same time >as gas street lights and computers that took up a whole building just to add >two numbers ! "Went out" of what? Went out of *fashion*??? You feel the Shuttle computers must have the newest technology, the shiniest chrome, the biggest tailfins, just to *impress* people? [Note 1]. I'd say a much better criterion is the question of what it takes to do the needed job. For the Shuttle flight control system, I gather that the actual processing requirements are fairly low - what's really critical is reliability. Part of the assurance of reliability is having a good "track record", particularly in the specific expected mode of operation. The inevitable result is that systems with the highest reliability requirements tend to use considerably older technology than systems that are only concerned with performance. The situation is extreme in the case of the Shuttle, because a reliable system had to be specified back in the 1970s, and having found a system that works, there had to be considerable incentive to find a replacement, because of the effort in verifying compatibility. Magnetic memory has a longer history than semiconductor memory, and has features that recommend it for high-reliability space applications. It's interesting that semiconductor memory reliability has advanced to the point that it can be considered as a valid replacement for core for this purpose. Regarding the new computers, I suspect it was the longer MTBF rather than the faster operation that prompted the change. > Magnetic Tape???? what about disks????? even floppies, with up to 20MB on a >single 3.5" provide a sturdier, more convenient answer.. and how about the >DATAPac technology? 100MB and more hard disks, especially suited to being >roughed around? Relatively few storage media have actually disappeared from use. Often, the different technologies develop application niches for which they offer better performance for price than other technologies. Disk drives are for random access, high throughput and fairly low access latency, and are good where intermixed reading and writing are desired. Magnetic tapes are for serial access, moderate data rate, usually reading *or* writing but not both, low price, and massive quantities of data. Archiving and loading software are often better served by tape. Just as an example, we recently obtained a tape drive that uses 8mm video tapes. Now we can go to local stores and buy a cartridge about the size of a standard audio cassette, which costs about $5.00 and will store about 2.3 gigabytes of data. I don't know of any disk technology that comes anywhere close in price/capacity. Similarly, the application for which the Shuttle uses its tape drive sounds like one of those better handled by tape. > I would be looking at, AT THE LEAST, radiation hardened datapacs, storing the >flight programs (with 3 backups,each one oriented a different way so that a >sharp manuver that might just crash the heads on one will only move them on >another) Right now, the Shuttle computers are not reliant on any mechanical storage media during use. Do you propose to change this? Can you think of a reason to justify the increased risk if the nonmechanical storage for runtime use already does a completely satisfactory job? Given that we don't want a failure of any one processor or processor-disk assembly to bring down the whole system, do you want 15 separate disk drives, or just the one set with an extremely complex safety interlock mechanism? >I would expect radiation hardened processors, of an industry sstandard >type (80x86, or 680x0 series) Why - so high school students can write the Shuttle flight programs? This is a very highly specialized software package, with all sorts of constraints that do not apply to most other software. It makes sense to build a computer to run the particular intended application, and making special- purpose computers out of standard bit-slice components is a long-established industry standard. Also, there may be operational constraints we do not know about. For example, if pipelined instruction fetch were deemed undesirable, this would eliminate most of the latest commercial microprocessors from consideration. >for easy replacement, and a well tested and >trusted product. I hope you don't think they would just buy one off the shelf and stick it in without at least weeks of intensive testing. Remember the stakes if the system fails at the wrong time. >As has been suggested by someone else already, EAROMS or just >straight ROMS can be used for holding much of the non changing code in memory >during a flight. They tend to be slower than RAM, and at least EAROMs are probably less reliable than RAM - certainly fewer write cycles. > as for RAM needs, if in 1991, the leading manufacturers of semiconductors can >put upwards of 10^6 transistors on a chip, but can't make radiation resistant >store, then we shouldn't be puttin people into space, we should be putting them >into the space inside some peoples heads, to find the technology we need!!!! Remember that "radiation resistant" does not mean the same thing as "radiation proof". I'm sure radiation resistant DRAM exists, even though static RAM is likely to be more resistant. (Static RAM also tends to be faster.) But I think you're missing the point of the choice of static RAM: it's much simpler to use in a real-time system. Considerable research has been done in recent years on how to make computer programs more reliable. It's almost impossible to eliminate all bugs in a complex control system, but with great effort the effect can be minimized. It has been remarked that the Shuttle control software is one of the most nearly perfect large pieces of code ever written. Part of this is due to the effort to make it as nearly deterministic as possible. For instance, I believe branches are forbidden, and probably also interrupts. DRAM requires frequent periodic refresh, "independent" of the state of execution. This can be done externally via a DRAM controller, but since this forces wait states on the processor at unpredictable times, it would not be acceptable for this use. The alternative is to perform refresh every few milliseconds under processor control, so every part of the code must include provisions for the refresh. Also remember that you have several processors running in lock-step mode, so the refreshes must not throw off synchronization, and yet you want as few single points of failure as possible, so an external clock periodically polled is probably not acceptable. In short, I presume the designers felt that DRAM was not worth the additional trouble compared to static RAM at this time. There's no guarantee that this will always be the case. >Theora Jones Strathclyde University, SCOTLAND || " I can fly higher than an >CABP10@uk.ac.strath.vaxa (somewhere on JANET) || Eagle, with you as the >CABP10%vaxa.strath.ac.uk (elsewhere, hopefully) || wind beneath my wings " >CABP10%vaxa.strath.ac.uk@ukacrl (just might work)|| 8:-) 1990 >WE SUPPORTED DESERT STORM ! KUWAIT IS NOW FREE ! || "Lets be MAWS!" [Note 1]: What's latest and most fashionable is not always the best guide for selection of an item for a specific application. For instance, in comparison to analog display watches, digital display watches are at least as accurate, usually more durable, generally easier to read, and considerably cheaper - and yet many people would rather die than be caught wearing a digital display watch (unless it reads "SPORTS WATCH" in big letters, and can calculate multiple lap intervals, etc.), because the analog display watches are all the fashion rage now. I suppose they do make better jewelry, but for the most part the digital displays are the superior choice for the basic function of telling time. Similarly for circuit designs, we sometimes still use the venerable 555 timer and 74120 digital pulse synchronizer. They were both designed more than 20 years ago, and yet for some applications they're still a very good choice. John Roberts roberts@cmr.ncsl.nist.gov
phil@eecs.nwu.edu (William LeFebvre) (03/12/91)
In article <1991Mar06.063034.12021@nowhere.uucp>, sking@nowhere.uucp (Steven King) writes: |> While its encouraging that NASA is finally moving beyond core memory |> for the shuttle ( welcome to the 90's ), why use writeable memory for |> program storage? As their code is extremely stable, it shouldnt be any |> problem to put everything they use into masked roms without any great |> penalty in weight or size ( mask roms have much better density than |> static rams ) with it all non volatile, non writeable. They load different parts of the software for different phases of flight. The 101-B (and 101-S) computer are not capable of addressing much more than 125K words, so they are constrained in that regard. The software is just too large to have all of it loaded in at the same time. And since it isn't all needed at the same time...... At the very least there are separate programs for ascent, orbit, and reentry. I am fairly confident that there are several parts of the ascent software that get loaded in at various phases of ascent. I'll check with my wife later today if I think of it. She would know, or at least would be able to look it up. William LeFebvre Computing Facilities Manager and Analyst Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
phil@eecs.nwu.edu (William LeFebvre) (03/12/91)
In article <00945591.AE398080@KING.ENG.UMD.EDU>, sysmgr@KING.ENG.UMD.EDU (Doug Mohney) writes: |> > The bottom line is that harddrives are only useful in situations where |> >you will be *writing* alot of new data. The control program for the |> >shuttle is only *read* during flight, never written. A read only tape drive |> >can be made much more rugged than a hard drive. |> |> Ick. Tape is slow. I like the CD-ROM idea better. A tape drive is what they use now. It has the advantage of being a "proven" and "well established" technology. Would you trust YOUR life to a CD-ROM drive? I might. Would you trust YOUR life to dynamic ram? I certainly would not. William LeFebvre Computing Facilities Manager and Analyst Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
phil@eecs.nwu.edu (William LeFebvre) (03/12/91)
In article <YAMAUCHI.91Mar10135135@heron.cs.rochester.edu>, yamauchi@cs.rochester.edu (Brian Yamauchi) writes: |> I recall that a GRID portable computer (with hard drive) *was* flown |> on a shuttle flight. I also seem to remember that it had more |> computing power and memory than *all* of the shuttle's onboard |> computers... A modified GRID is standard equipment on every shuttle flight. It is used by the crew to determine orbital position. It is informational ONLY. It does not actually control anything. I think it is only there to make the crew feel better: it is not used in any of the standard operating procedures. Its display is basically a duplicate of the big- screen map in mission control. A GRID, for those who don't know, is a laptop '386 machine. It is convection cooled. NASA modified it by taking out the builtin modem (not very useful in orbit) and adding a cooling fan in its place--- convection cooling doesn't work too well in orbit. William LeFebvre Computing Facilities Manager and Analyst Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
phil@eecs.nwu.edu (William LeFebvre) (03/12/91)
In article <1991Mar10.210059.26743@nowhere.uucp>, sking@nowhere.uucp (Steven King) writes: |> It would be interesting to see some of this software. Some early 70's |> fortran code no doubt... Nope. I've seen some. It's IBM assembly language. I'm not sure about its origins---it may have originally been generated by a compiler. But the assembly code itself has been modified (dare I say "hacked on") quite a bit thru the years. I'll try to get more details this evening. William LeFebvre Computing Facilities Manager and Analyst Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
roberts@CMR.NCSL.NIST.GOV (John Roberts) (03/12/91)
>From: dil@mace.cc.purdue.edu (Perry G Ramsey) >Newsgroups: sci.space.shuttle >Subject: Re: New (!?!?!?!) Shuttle Computers >To be a little more fair, they have a very complex vehicle. It is >important to make sure that changes don't affect the system in unexpected >ways, so it takes a lot of integration engineering and testing to do that. Good point. >Besides the fact that NASA is supposed to be pushing technology if their >existence is to have any value to the taxpayers. The state of the Shuttle GPC >indicates pretty clearly that the current >NASA (at least the manned space side) is scared to death of anything new. >That, though, is the ultimate state of any hidebound bureaucracy: it's >better not to make a mistake than not to accomplish anything. That's what Congress consistently tells them with respect to manned spaceflight, so it's hard to blame them for taking that attitude. NASA does push computer technology on the ground, and (I believe) in flight control systems for experimental aircraft such as the X-29. But the Shuttle is not primarily intended as a testbed for flight control systems - it does push technology in several areas (such as the SSME design), but is also supposed to serve as an operational system. In this context, I think they can perhaps be forgiven for not trying to use the very latest technology in *every* aspect of the Shuttle. >Perry G. Ramsey Department of Earth and Atmospheric Sciences >dil@mace.cc.purdue.edu *** IMAGINE YOUR LOGO HERE ****** John Roberts roberts@cmr.ncsl.nist.gov
sysmgr@KING.ENG.UMD.EDU (Doug Mohney) (03/12/91)
In article <YAMAUCHI.91Mar10135135@heron.cs.rochester.edu>, yamauchi@cs.rochester.edu (Brian Yamauchi) writes: >I recall that a GRID portable computer (with hard drive) *was* flown >on a shuttle flight. I also seem to remember that it had more >computing power and memory than *all* of the shuttle's onboard >computers... Sure. But not open on someone's lap chuggin' away upon launch :-) > >I believe it was used for plotting the shuttle's position and >trajectory. Does anyone have the details? Reform may be dying in the Soviet Union, but we have the right to introduce it to the DECUS Board of Directors. -- > SYSMGR@CADLAB.ENG.UMD.EDU < --
jfw@ksr.com (John F. Woods) (03/12/91)
roberts@CMR.NCSL.NIST.GOV (John Roberts) writes: >"Went out" of what? Went out of *fashion*??? You feel the Shuttle computers >must have the newest technology, the shiniest chrome, the biggest tailfins, >just to *impress* people? Oh, come on now. I think the Shuttle would look GREAT with tailfins! :-) [Although it might not look like it, I'm actually agreeing with John Roberts here, just looking at the questions from a slightly different viewpoint] >>I would expect radiation hardened processors, of an industry sstandard >>type (80x86, or 680x0 series) >Why - so high school students can write the Shuttle flight programs? >This is a very highly specialized software package, with all sorts of >constraints that do not apply to most other software. It makes sense to build >a computer to run the particular intended application, and making special- >purpose computers out of standard bit-slice components is a long-established >industry standard. Well, as I understand it, the AP-101 architecture is pretty much a small IBM 360, which was pretty "standard" when it was designed. NASA now has a huge stack of assembly-language (or near-assembly-language) software which is extremely thoroughly debugged -- not "well, gee, it ran ok twice in a row" but debugged as in hundreds of suspicious software engineers can't find any more problems. That is NOT the kind of investment you throw away just so that Flight Simulator will run on the flight system... :-) >>As has been suggested by someone else already, EAROMS or just >>straight ROMS can be used for holding much of the non changing code in memory >>during a flight. >They tend to be slower than RAM, and ... EAROMs [have] fewer write cycles. ROMs aren't all that slow (they're faster than the cores that got replaced). However, battery-backed-up SRAM (as is indeed found in the AP-101S) is faster, and certainly more flexible -- you can recover the address space used by the launch program! (:-) An EPROM-based semiconductor-"disk" might make sense, but as you point out, tape drives now have capacities far in excess of a reasonable semiconductor disk system. >>as for RAM needs, if in 1991, the leading manufacturers of semiconductors can >>put upwards of 10^6 transistors on a chip, but can't make radiation resistant >>store, then ... >Remember that "radiation resistant" does not mean the same thing as "radiation >proof". I'm sure radiation resistant DRAM exists, even though static RAM is >likely to be more resistant. (Static RAM also tends to be faster.) But I think >you're missing the point of the choice of static RAM: it's much simpler to >use in a real-time system. DRAM refresh isn't really all that tough a problem, and can be made as deterministic as you like if the DRAMS are fast enough. I think it is more likely that the key is the battery backup -- DRAM refresh consumes power at the same rate as normal use, whereas SRAMs frequently have power-down modes consuming fractional microwatts (this, though, depends on whether the memory "scrubbing" is performed when the system is powered down; if it is, then the SRAMs probably aren't being put into low-power mode...); and, of course, SRAMs are generally more radiation resistant as you mention.
bdietz@sdcc13.ucsd.edu (Jack Dietz) (03/12/91)
As I recall from the very early flights and a dog-eared copy of the Space Shuttle Operator's Manual, the original shuttle programs were written in Very High-level Shuttle Instruction Code (VHSIC). This came up during those T-00:31 launch aborts when the announcers were trying to cover programmers frantically debugging on national television... Also, in the instructions from the SSOM, several times during the launch sequence the instructions tell the commander to punch in a command to load another software package. [OPS] 105, for example, loaded the package used between T-19 minutes and T-5 minutes, I believe. A suggestion: If the instruction space is limited to 128K words or so, bank switching sounds like an answer -- copying the routines directly to ROM images with an added instruction to switch banks at the end of each. Howabout a milspec SPARC processor? (just kidding) Actually, the XT-370 computers which IBM made for a while used a 68000 with the microcode replaced to run 370 programs on an expander card. Perhaps NASA could convince a couple of companies to update that chip in a radiation-hardened manner? -- The Army Axiom: | Jack Dietz (bdietz@ucsd.edu) Any order that can be misunderstood | Looking Forward to a Future has been misunderstood. | without Bellamyites -- Segal's Law: | Jack Dietz A man with one watch always knows what time it is. | (bdietz@ucsd.edu) A man with two watches is never sure. | Engineer-To-Be
pjs@euclid.jpl.nasa.gov (Peter Scott) (03/13/91)
In article <2601@ksr.com>, jfw@ksr.com (John F. Woods) writes: > roberts@CMR.NCSL.NIST.GOV (John Roberts) writes: > >"Went out" of what? Went out of *fashion*??? You feel the Shuttle computers > >must have the newest technology, the shiniest chrome, the biggest tailfins, > >just to *impress* people? > > Oh, come on now. I think the Shuttle would look GREAT with tailfins! :-) Hey, Dyna-Soar had tailfins... -- This is news. This is your | Peter Scott, NASA/JPL/Caltech brain on news. Any questions? | (pjs@euclid.jpl.nasa.gov)
lou@caber.valid.com (Louis K. Scheffer) (03/13/91)
A hard disk drive would probably work OK on the shuttle, although perhaps not during launch. Hard disk drives are surprisingly rugged while running. When operating, the air bearing is quite stiff, and keeps the head off the surface very easily. The bearings are quite strong, so the most likely limiting factor would be the servos that keep the head on track. These servos have a few hundred hertz of bandwidth and about 10 Gs of acceleration, so they can handle many Gs at low frequencies. Maneuvers are probably OK, but the vibrations of launch probably would not be. NASA used to use standard commercial disc drives (from HP) in the Kuiper(?) observatory, which is the plane they fly with the infrared telescope. The drives had to cope with vibration, reduced atmospheric pressure (a problem for most hard disks), gyroscopic effects, temperature variations, etc. These were about 1975 vintage drives, though, which had large disk-to-head clearances, and these drives also retracted the heads when not in use. I don't know what they use now. Optical drives should be better still, since the head to disc spacing can be so large (1 mm) and does not depend on air bearings.
mlc@aten.cca.rok.com (Michael L. Cook) (03/13/91)
According to the recent PBS NOVA series on the Soviet space program, the Soviets are using the same booster to launch current manned flights as they used for Gagarin's first flight. They have much the same concerns for safety, upgrades as we do. Inertia for using what works is very strong, and not just in the space program. Michael Cook Internet: mlc%gva.decnet@consrt.rok.com "Post no bills"
colwell@omews1.intel.com (Robert Colwell) (03/14/91)
In article <1991Mar7.010752.10632@agate.berkeley.edu> jwl@garnet.berkeley.edu (James Wilbur Lewis) writes: >In article <1991Mar06.063034.12021@nowhere.uucp> sking@nowhere.uucp (Steven King) writes: >> >> With the 230 lbs they saved they could put a couple hundred meg disk >> array on each CPU and... > >...watch their data get turned into a worthless pile of iron oxide if >the spacecraft changes attitude while the drives are spinning! In the "for what it's worth" category, I submit the following. In the early 80's somebody bought a Perq graphics workstation for use in pursuing his dream of winning the America's Cup sailing prize. At the time we figured he was doing some kind of graphical modelling of the hull or something. Turns out the guy had the whole machine, Winchester disk and all, mounted in a gimbal in the boat itself, and he was using the computer to help plan race strategies in real time. Given all the elaborate precautions we had to take to even move a machine on a flat floor (head locking screws etc.) our jaws dropped when we heard about this. He claimed it worked just fine. Of course, if we tried to apply his "technology" to the shuttle I suspect it's not his technical acumen we'd want, it's his luck. Bob Colwell colwell@mipon2.intel.com 503-696-4550 Intel Corp. JF1-19 5200 NE Elam Young Parkway Hillsboro, Oregon 97124
henry@zoo.toronto.edu (Henry Spencer) (03/14/91)
In article <1991Mar13.084501@aten.cca.rok.com> MLC%GVA.DECNET@CONSRT.ROK.COM writes: >the Soviets are using the same booster to launch current manned flights >as they used for Gagarin's first flight. They have much the same concerns >for safety, upgrades as we do. Inertia for using what works is very strong, >and not just in the space program. I think you're confusing continued use of the same basic design with upgrading its innards. Yes, the A booster is still in use. In fact, it goes further: ignoring some variations in upper stages, the launcher used for Soyuz today is the same one that launched Sputnik 1. It's the only mass-produced launcher on Earth. However, the Soviets have upgraded their spacecraft repeatedly, and presumably (although there is little information available) have done the same for the launcher. Contrast this to the US, which regularly throws out old basic designs in favor of a clean sheet of paper, but then balks at doing minor upgrades during their operational lifetime. -- "But this *is* the simplified version | Henry Spencer @ U of Toronto Zoology for the general public." -S. Harris | henry@zoo.toronto.edu utzoo!henry
amichiel@rodan.acs.syr.edu (Allen J Michielsen) (03/14/91)
In article <> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <1991Mar13.084501@aten.cca> MLC%GVA.DECNET@CONSRT.ROK.COM writes: >>the Soviets are using the same booster to launch current manned flights >>as they used for Gagarin's first flight. They have much the same concerns >>for safety, upgrades as we do. Inertia for using what works is very strong, >>and not just in the space program. >upgrading its innards. Yes, the A booster is still in use. In fact, it >goes further: ignoring some variations in upper stages, the launcher >used for Soyuz today is the same one that launched Sputnik 1. It's the >However, the Soviets have upgraded their spacecraft repeatedly, and I think you can go a step farther. In terribly generic terms, the actual launcher is kinda a big roman candle and the 'smarts' are generally more confined around the capsule, from which any control I/O is kinda routed. Further, the soviet design philosophy has been to keep all the 'smarts' possible on the ground and to actually launch very 'spartan' equipment. Therefore, the soviets could well make great strides in computer upgrades for the system without making (virtually) ANY modifications (at least ones we could see) to either the capsule or launch vechicle. I saw some film of the inside of the soviet lunar module recently. The voice over suggested it looked like a 19'th century steam engine, but I thougt it looked much like the control room of a WWII submarine. The pilot stood in front of about 10 large steel handles, assumeably pulling handles to operate positioning jets.... Even in 1970 I don't think I could have been convinced to ride in this.... al -- Al. Michielsen, Mechanical & Aerospace Engineering, Syracuse University InterNet: amichiel@rodan.acs.syr.edu amichiel@sunrise.acs.syr.edu Bitnet: AMICHIEL@SUNRISE
msjohnso@daisy.WichitaKS.NCR.COM (Mark Johnson) (03/18/91)
In article <1991Mar9.044834.27802@cimage.com> gregc@dgsi.UUCP (Greg Cronau/10000) writes: > The bottom line is that harddrives are only useful in situations where >you will be *writing* alot of new data. The control program for the >shuttle is only *read* during flight, never written. A read only tape drive >can be made much more rugged than a hard drive. I wonder if they've considered using CD-ROM as a storage medium for the control programs. It's rugged, the drives can be lighter than tapes, the media is not alterable except by drastic accident on-board, etc. Well, maybe someday.... -- Mark Johnson On the air: WB9QLR/0 USnail: NCR Peripheral Products Division E-mail: Mark.Johnson@Wichita.NCR.COM 3718 N. Rock Rd. Voice: (316) 636-8189 [V+ 654-8189] Wichita, KS 67226 On the flying field: NAR 14025/AMA 290233
eagle@garfield.catt.ncsu.edu (Daniel L'Hommedieu) (03/19/91)
msjohnso@daisy.WichitaKS.NCR.COM (Mark Johnson) writes: >I wonder if they've considered using CD-ROM as a storage medium for the control >programs. It's rugged, the drives can be lighter than tapes, the media is >not alterable except by drastic accident on-board, etc. Have you ever used a CD player? I don't think a CD-ROM is a viable alternative, as it is very easy to "skip" a CD player (for instance, just tap or hit the desk near a CD player and listen to it skip). I should think that the g-forces and vibrations experienced during launch would be too harsh for the CD-ROM drive. >Well, maybe someday.... >Mark Johnson Daniel Name: Daniel C. L'Hommedieu III Snail: NCSU Box 21531/Raleigh/NC/27607 INet: eagle@catt.ncsu.edu Prodigy ID: bccj33d Tel:919 737 6143 "Atheism's too easy--there's nothing to it." --unknown CTFTW: Is equal opportunity enhanced through quotas?
jadahlin@acsu.buffalo.edu (jason a dahlin) (03/19/91)
eagle@garfield.catt.ncsu.edu (Daniel L'Hommedieu) writes: >msjohnso@daisy.WichitaKS.NCR.COM (Mark Johnson) writes: >>I wonder if they've considered using CD-ROM as a storage medium for the control >>programs. It's rugged, the drives can be lighter than tapes, the media is >>not alterable except by drastic accident on-board, etc. >Have you ever used a CD player? I don't think a CD-ROM is a viable >alternative, as it is very easy to "skip" a CD player (for instance, >just tap or hit the desk near a CD player and listen to it skip). I >should think that the g-forces and vibrations experienced during launch >would be too harsh for the CD-ROM drive. I would think that they could manage a sufficient anti-role mechanism to counteract this. They already have cheap ones in most good discmans. My question is this... does anyone know if cd-rom is effected by magnets or magnetic forces? papa sm00sh -- jadahlin@acsu.buffalo.edu v285raag@ubvms.cc.buffalo.edu
morgan@spectra.com (Mike Morgan) (03/20/91)
In article <1991Mar18.231328.24932@ncsu.edu> eagle@garfield.catt.ncsu.edu (Daniel L'Hommedieu) writes: >msjohnso@daisy.WichitaKS.NCR.COM (Mark Johnson) writes: >>I wonder if they've considered using CD-ROM as a storage medium for the control >>programs. It's rugged, the drives can be lighter than tapes, the media is >>not alterable except by drastic accident on-board, etc. > >Have you ever used a CD player? I don't think a CD-ROM is a viable >alternative, as it is very easy to "skip" a CD player (for instance, >just tap or hit the desk near a CD player and listen to it skip). I >should think that the g-forces and vibrations experienced during launch >would be too harsh for the CD-ROM drive. > >>Well, maybe someday.... And that some day is today. Already companies such as Hewelett Packard and Meridian Data already produce CD-ROM publishing systems. I believe manuals for Boeing Jets are one such application. The big problem is not the skip that occurs on many of the poorly made musical CD players, but the seek and retrieve time required by the CD-ROM drives. Also, the inability to record reduces their desirability. However, I would not be surprised if they become standard fare on future missions.
shafer@skipper.dfrf.nasa.gov (Mary Shafer) (03/21/91)
In article <66172@eerie.acsu.Buffalo.EDU> jadahlin@acsu.buffalo.edu (jason a dahlin) writes:
[In response to a bunch of stuff about CD-ROM and skipping]
My question is this... does anyone know if cd-rom is effected by magnets or
magnetic forces?
I don't know about magnets, although I'd expect the answer to be "No".
However, according to Norman Bushnell (Feedback, New Scientist, 23
Feb) CDs outgas.
"If the discs are stored under low pressure, gas will seep out of the
plastics materials used in making them. The gas forms bubbles in the
plastics which make it impossible for the laser in the player to read
the disc.
"`It happened mainly with early discs,' says Bushnell. `But you can
still have a CD that plays perfectly, take it on a plane journey in
your baggage and find afterwards that it no longer plays. Not a lot
of people know that. It's not something the record companies like to
talk about.' Surprise, surprise."
Since the baggage holds of most modern airliners are kept at about
6,000 to 8,000 ft pressure altitude, this implies it doesn't take much
of a delta-P to do the trick.
--
Mary Shafer shafer@skipper.dfrf.nasa.gov ames!skipper.dfrf.nasa.gov!shafer
NASA Ames Dryden Flight Research Facility, Edwards, CA
Of course I don't speak for NASA
"A MiG at your six is better than no MiG at all"--Unknown US fighter piloterics@sco.COM (eric smith) (03/27/91)
eagle@garfield.catt.ncsu.edu (Daniel L'Hommedieu) writes: >Have you ever used a CD player? I don't think a CD-ROM is a viable >alternative, as it is very easy to "skip" a CD player (for instance, >just tap or hit the desk near a CD player and listen to it skip). I >should think that the g-forces and vibrations experienced during launch >would be too harsh for the CD-ROM drive. Well I have a CD player in my car. It's only skipped twice in a year and a half of constant use, both times during very heavy jolts while going over railroad tracks. Eric