"NASA computer" a misnomer?

[geckzilla]

A lot of people I know use the term "NASA computer" to define exactly what you'd think... a really good computer you'd like to have that can handle anything you throw at it. But every time I hear this I wonder if you'd really want a computer used by NASA. Knowing what I know I don't imagine them as being very powerful or even up to date. But of course I don't actually know. I mean, I'm sure some projects or simulations must require a lot of computing power but on average I don't think astronomy requires more than an average computer. Am I totally wrong on this? Inquiring minds want to know.

[Chris Peterson]

A lot of people I know use the term "NASA computer" to define exactly what you'd think... a really good computer you'd like to have that can handle anything you throw at it. But every time I hear this I wonder if you'd really want a computer used by NASA. Knowing what I know I don't imagine them as being very powerful or even up to date. But of course I don't actually know. I mean, I'm sure some projects or simulations must require a lot of computing power but on average I don't think astronomy requires more than an average computer. Am I totally wrong on this? Inquiring minds want to know.

The vast majority of computers used at NASA are your garden variety Intel machines running Windows, OS X, or some Unix/Linux variant. That's what everybody I know uses for their personal work and most of their research. There are some large processor arrays and other supercomputers used for various numerical simulations. In most cases these are probably not owned by NASA, but by universities or consortiums that NASA is partnered with.

(FWIW, I've never heard the term "NASA computer" used in this way.)

[geckzilla]

Haha, yeah, I guess it's kind of a niche phrase. I decided to ask this because someone from Russia made a statement along the lines of wanting a NASA computer because his USSR computer was too slow. The misconception probably stems from the even wider misconception that NASA has a huge budget.

[Chris Peterson]

Haha, yeah, I guess it's kind of a niche phrase. I decided to ask this because someone from Russia made a statement along the lines of wanting a NASA computer because his USSR computer was too slow. The misconception probably stems from the even wider misconception that NASA has a huge budget.

Probably kind of like "rocket science" as a metaphor for complex science... despite the fact that rocket science is mainly engineering, and the science itself is rather ancient and trivial compared to many more cutting edge disciplines.

[geckzilla]

I'll remember to correct them either to say rocket engineering or move them to an actual complex science such as quantum mechanics, then.

[neufer]

[b][color=#0000FF]Apollo Guidance Computer Invented by MIT Instrumentation Laboratory Manufacturer Raytheon Introduced August 1966 Discontinued July 1975 Processor Discrete IC RTL based Frequency 2.048 MHz Memory 16-bit wordlength, 2048 words RAM (magnetic core memory), 36,864 words ROM (core rope memory) Power consumption 55W:120 Weight 70 lb Dimensions 24x12.5x6.5 inches [/color][/b]

---

<<The Apollo Guidance Computer (AGC) was a digital computer produced for the Apollo program that was installed onboard each Apollo Command Module (CM) and Lunar Module (LM). The AGC provided computation and electronic interfaces for guidance, navigation, and control of the spacecraft. The AGC had a 16-bit word length, with 15 data bits and one parity bit. Most of the software on the AGC was stored in a special read only memory known as core rope memory, fashioned by weaving wires through magnetic cores, though a small amount of read-write core memory was provided.

The Apollo flight computer was the first to use integrated circuits (ICs). While the Block I version used 4,100 ICs, each containing a single 3-input NOR gate, the later Block II version (used in the crewed flights) used 2,800 ICs, each with two 3-input NOR gates. The ICs, from Fairchild Semiconductor, were implemented using resistor-transistor logic (RTL) in a flat-pack. They were connected via wire wrap, and the wiring was then embedded in cast epoxy plastic. The use of a single type of IC (the dual NOR3) throughout the AGC avoided problems that plagued another early IC computer design, the Minuteman II guidance computer, which used a mix of diode-transistor logic and diode logic gates.

The computer had 2048 words of erasable magnetic core memory and 36 kilowords of read-only core rope memory. Both had cycle times of 11.72 micro-seconds. The memory word length was 16 bits: 15 bits of data and 1 odd-parity bit. The CPU-internal 16-bit word format was 14 bits of data, 1 overflow bit, and 1 sign bit (ones' complement representation).

The user interface to the AGC was the DSKY, standing for display and keyboard and usually pronounced dis-key. It had an array of indicator lights, numeric displays and a calculator-style keyboard. Commands were entered numerically, as two-digit numbers: Verb, and Noun. Verb described the type of action to be performed and Noun specified which data were affected by the action specified by the Verb command.

The numerals were displayed via green high-voltage electroluminescent seven segment displays. The segments were driven by electromechanical relays, which limited the display update rate. Three 5-digit signed numbers could also be displayed in octal or decimal, and were typically used to display vectors such as space craft attitude or a required velocity change (delta-V). Although data were stored internally in metric units, they were displayed as United States customary units.

The Command Module had two DSKYs connected to its AGC; one located on the main instrument panel and a second located in the lower equipment bay near a sextant used for aligning the inertial guidance platform. The Lunar Module had a single DSKY for its AGC. A flight director attitude indicator (FDAI), controlled by the AGC, was located above the DSKY on the commander's console and on the LM.

The AGC timing reference came from a 2.048 MHz crystal clock. The clock was divided by two to produce a four-phase 1.024 MHz clock which the AGC used to p erform internal operations. The 1.024 MHz clock was also divided by two to produce a 512 kHz signal called the master frequency; this signal was used to synchronize external Apollo spacecraft systems.

The master frequency was further divided through a scaler, first by five using a ring counter to produce a 102.4 kHz signal. This was then divided by two through 17 successive stages called F1 (51.2 kHz) through F17 (0.78125 Hz). The F10 stage (100 Hz) was fed back into the AGC to increment the real-time clock and other involuntary counters using Pinc. The F17 stage was used to intermittently run the AGC when it was operating in the standby mode.

The AGC had a power-saving mode controlled by a standby allowed switch. This mode turned off the AGC power, except for the 2.048 MHz clock and the scaler. The F17 signal from the scaler turned the AGC power and the AGC back on at 1.28 second intervals. In this mode, the AGC performed essential functions, checked the standby allowed switch, and, if still enabled, turned off the power and went back to sleep until the next F17 signal. In the standby mode, the AGC slept most of the time; therefore it was not awake to perform the Pinc instruction needed to update the AGC's real time clock at 10 ms intervals. To compensate, one of the functions performed by the AGC each time it awoke in the standby mode was to update the real time clock by 1.28 seconds.

The standby mode was designed to reduce power by 5 to 10 W (from 70 W) during midcourse flight when the AGC was not needed. However, in practice, the AGC was left on during all phases of the mission and this feature was never used.

The AGC had a 16-bit read bus and a 16-bit write bus. Data from central registers (A, Q, Z, or LP), or other internal registers could be gated onto the read bus with a control signal. The read bus connected to the write bus through a non-inverting buffer, so any data appearing on the read bus also appeared on the write bus. Other control signals could copy write bus data back into the registers.

AGC software was written in AGC assembly language and stored on rope memory. There was a simple real-time operating system consisting of the Exec, a batch job-scheduling system that could run up to 8 'jobs' at a time using cooperative multi-tasking (each job had to periodically surrender control back to the Exec which then checked if there was any waiting job with higher priority). There was also an interrupt-driven component called the Waitlist which could schedule multiple timer-driven 'tasks'. The tasks were short threads of execution which could reschedule themselves for re-execution on the Waitlist, or could kick off a longer operation by starting a 'job' with the Exec.

The Exec jobs were priority-based. The lowest priority job, called the dummy job, was always present. It did diagnostic checks and controlled a green computer activity light on the DSKY: If the dummy job was running, this meant the computer had nothing better to do, so the light was turned off. The dummy job exited if there was some higher priority job to be done and this was indicated by the computer activity light being illuminated.

The AGC also had a sophisticated software interpreter, developed by MIT, that implemented a virtual machine with more complex and capable pseudo-instructions than the native AGC. They were used when navigational computations of greater precision than 8 bits were required. Interpreted code, which featured double precision scalar and vector arithmetic, even an MXV (matrix × vector) instruction, could be mixed with native AGC code. While the execution time of the pseudo-instructions was increased (due to the need to interpret these instructions at runtime) the interpreter provided many more instructions than AGC natively supported and the memory requirements were much lower than in the case of adding these instructions to the AGC native language (memory capacity was very expensive at the time). The average pseudo-instruction required about 24 ms to execute. The assembler and version control system, named YUL for an early prototype Christmas Computer, enforced proper transitions between native and interpreted code.

A set of interrupt-driven user interface routines called Pinball provided keyboard and display services for the jobs and tasks running on the AGC. A rich set of user-accessible routines were provided to let the operator (astronaut) display the contents of various memory locations in octal or decimal in groups of 1, 2, or 3 registers at a time. Monitor routines were provided so the operator could initiate a task to periodically redisplay the contents of certain memory locations. Jobs could be initiated. The Pinball routines performed the (very rough) equivalent of the UNIX shell.

PGNCS generated unanticipated warnings during Apollo 11's lunar descent, with the AGC showing a 1201 alarm ("Executive overflow - no vacant areas") and a 1202 alarm ("Executive overflow - no core sets"). The cause was a rapid, steady stream of spurious cycle steals from the rendezvous radar, intentionally left on standby during the descent in case it was needed for an abort.

During this part of the approach the processor would normally be almost 85% loaded. The extra 6400 cycle steals per second added the equivalent of 13% load, leaving just enough time for all scheduled tasks to run to completion. Five minutes into the descent Buzz Aldrin gave the computer the command 1668 which instructed it to calculate and display DELTAH (the difference between altitude sensed by the radar and the computed altitude). This added an additional 10% to the processor workload causing executive overflow and a 1202 alarm. After being given the "GO" from Houston Aldrin entered 1668 again and another 1202 alarm occurred. When reporting the second alarm Aldrin added the comment "It appears to come up when we have a 1668 up". Happily for Apollo 11, the AGC software had been designed with priority scheduling. Just as it had been designed to do, the software automatically recovered, deleting lower priority tasks including the 1668 display task, to complete its critical guidance and control tasks. Guidance controller Steve Bales and his support team that included Jack Garman issued several "GO" calls and the landing was successful. For his role, Bales received the US Medal of Freedom on behalf of the entire control center team and the three Apollo astronauts.

The problem was not a programming error in the AGC, nor was it pilot error. It was a peripheral hardware design bug that was already known and documented by Apollo 5 engineers. However because the problem had only occurred once during testing they concluded that it was safer to fly with the existing hardware that they had already tested, than to fly with a newer but largely untested radar system. In the actual hardware, the position of the rendezvous radar was encoded with synchros excited by a different source of 800 Hz AC than the one used by the computer as a timing reference. The two 800 Hz sources were frequency locked but not phase locked, and the small random phase variations made it appear as though the antenna was rapidly "dithering" in position even though it was completely stationary. These phantom movements generated the rapid series of cycle steals.

The computer's other error codes included error 00404, which was shorthand for "IMU orientation unknown". Since the Inertial Measurement Unit device literally told the craft where to go, this has been compared to the HTTP 404 not found or browser navigation error code used on the World Wide Web. However, the later familiar HTTP error code did not originate with the AGC.>>

[Orca]

The main computers on the shuttle had relatively low specs by modern computing standards.

Even after a major computer upgrade in 1991, the primary flight system has a storage capacity of one megabyte and runs at a speed of 1.4 million instructions per second.

The argument is that basic controls for the vehicle don't require large amounts of computing power; reliability of the systems is a more important concern.

It appears to me (from watching video of operations during missions) that the computers used for research and what not are mounted laptops. I am just guessing here but it seems logical. A network of nodes that can be easily replaced would make far more sense than built-in or centralized systems that are powerful when installed but quickly become obsolete.

[neufer]

[b][color=#0000FF]Hugo Gernsback, the Editor of Radio-Electronics, was impressed with the Radio Hat and the June 1949 issue had a two-page article describing the circuitry and construction of the radio. The cover photograph shows a 15-year-old Hope Lange wearing a Lipstick Red hat.[/color][/b]

---

<<The Radio Hat was a portable radio built into a pith helmet that would bring in stations within a 20 mile radius. It was introduced in early 1949 for $7.95 as the "Man-from-Mars Radio Hat." Thanks to a successful publicity campaign, the Radio Hat was sold at stores from coast to coast in the United States.

Radios at this time usually were powered by the AC mains. They used vacuum tubes that had a 6 or 12 volt filament supply that heated the cathode; and a 100 to 300 volt anode (or B+) supply. The technology advances in World War II for mobile radios produced inexpensive low power vacuum tubes. The Radio Hat had an external battery pack that provided 1.5 volts for the filaments and the 22.5 volt B+ supply. These were much safer voltages for use in a hat, especially since the full plate voltage is dropped across the earphone. This technique was commonly used in many simple radios, some having ninety or more volts present across the head or earphones. The battery pack would power the radio for up to 20 hours.

The radio received the AM broadcast band (540 kHz to 1600 kHz) and was tuned by a knob between the two tubes. (Table top or console radio receivers of the day used 5 or 6 tubes to provide better performance.) The loop antenna and the tuning knob were also visible. The hat was available in eight colors: Lipstick Red, Tangerine, Flamingo, Canary Yellow, Chartreuse, Blush Pink, Rose Pink and Tan.

The Radio Hat was manufactured by American Merri-Lei Corporation of Brooklyn N.Y. The company was a leading supplier of party hats, noise makers and other novelty items. Its founder, Victor Hoeflich, had invented a machine to make paper Hawaiian leis while still in high-school (1914), and by 1949 the company shipped millions of leis to Hawaii each year. An inventor and gadgeteer, Hoeflich continued to develop and even sell machinery that manufactured paper novelty items.

In March 1949, Victor Hoeflich held a press conference to introduce the "Man from Mars, Radio Hat". Hoeflich knew a picture would tell the story so he had several teenagers modeling the Radio Hats for the reporters and photographers. Soon pictures and news stories appeared in newspapers coast to coast. The articles typically included a photo of a young lady wearing the hat and a six-paragraph story. The Radio Hat also received widespread coverage in magazines. This included do-it-yourself magazines such as Popular Mechanics, Popular Science, Mechanix Illustrated, and Radio-Electronics. There was also coverage in general-audience magazines such as Life, Time, Newsweek, and The New Yorker.

The Radio Hat was sold in department stores and by mail order. A Van Nuys, California service station chain sold the hats as a promotion item to customers who purchased gasoline. The massive publicity did not lead to lasting sales. Advertisements for the Radio Hat stopped in early 1950. In a 1956 interview, Hoeflich said the company still got orders for the hat even though it was long out of production.>>

[neufer]

Click to play embedded YouTube video.

[Beyond]

Amazing stuff It's easy to see that these guys do not have a day job. Good for them And us too