This Is Not Your Father’s FORTRAN

October 26, 2015 by Rud Merriam 111 Comments

I learned to program FORTRAN IV in the spring of 1968 while working as an engineering technician in water resources. One of the engineers knew of my interest in computers and asked if I would like to learn FORTRAN. He needed to calculate the biological oxygen demand in streams but didn’t have any interest in programming. I jumped at the chance.

This was the days of big iron when the term computer meant a room full of heavily air-conditioned equipment. The State University of New York at Buffalo had an IBM 704 but they soon upgraded to a CDC 6400. To help pay for it they were inviting people to attend a seminar on FORTRAN so they could use the system. My job was with a small State of NY office and getting approval for me to attend was surprisingly easy.

Off I went for 6 weeks of training on one night a week. I still have my black “A Guide to Fortran IV Programming” by [Daniel McCracken]. For years, this was the FORTRAN bible, commonly referred to as just “McCracken”.

The programming went well and somewhere out there is a very old paper with a reference to the results it generated about the Chadakoin River flowing through Jamestown, NY.

This is FORTRAN’s strength – scientific calculations. It’s name says it: FORmula TRANslation.

Origins and FORTRAN IV

[John W. Backus] suggested to IBM a language to replace assembly language. Development began in 1953 for the IBM 704 and the project reached fruition in 1957. Not only was it the first general purpose high-level language, just beating out COBOL and LISP, but its compiler optimized the code since it needed to compete head-on with assembly language. It was the C compiler of its day in that regard.

That was not the only reason it attained success. Reducing the number of punched cards needed for a program by a factor of 20 over assembly helped considerably.

In those days, you needed to use a key punch to create a deck of punch cards. To be really good you had to know how to create a programming card that would let you skip through the fields on a FORTRAN card, or how to edit a card by duplicating it and holding one of the cards in place while you typed in new characters. Because of my fascination with computers I’d taken a key punching and automation machines class in high school so I was all set.

Continue reading “This Is Not Your Father’s FORTRAN” →

Don’t Look Now, Nothing Will Happen –Zeno Of Elea

October 26, 2015 by Brandon Dunson 53 Comments

The Greek philosopher [Zeno of Elea] proposed that an arrow in flight was in fact not in motion and its visible movement is only an illusion. A simple example of this is to glance at an arrow in flight, doing this causes our mind to store a snapshot of a motionless arrow. [Zeno] further defended this argument by stating that if an object has to travel a finite distance to reach a destination then the finite distance can be divided in half and the object must first reach this halfway point before arriving at the destination. This process can be repeated an infinite number of times, creating an infinite number of points that the object must occupy before reaching the destination thus it can never arrive at the destination.

Whoa, that’s a bit heavy. Let’s take a second here to think about this and never arrive at the conclusion, shall we?

So what does a fancy mathematics parlor trick have to do with the fact that we have all seen an arrow arrive at its destination? Recent experiments conducted at Cornell University have in fact verified the Zeno Effect. Researchers were able to achieve this by having atoms suspended between lasers in temperatures ~1 nano degree above absolute zero so that the atoms arrange themselves in a lattice formation. As per usual in quantum mechanics when observed, the atoms had an equal possibility of being anywhere within the space of the lattice. However, when they were observed at high enough frequencies the atoms remain motionless, bringing the quantum evolution to a halt.

Killed By A Machine: The Therac-25

October 26, 2015 by Adam Fabio 158 Comments

The Therac-25 was not a device anyone was happy to see. It was a radiation therapy machine. In layman’s terms it was a “cancer zapper”; a linear accelerator with a human as its target. Using X-rays or a beam of electrons, radiation therapy machines kill cancerous tissue, even deep inside the body. These room-sized medical devices would always cause some collateral damage to healthy tissue around the tumors. As with chemotherapy, the hope is that the net effect heals the patient more than it harms them. For six unfortunate patients in 1986 and 1987, the Therac-25 did the unthinkable: it exposed them to massive overdoses of radiation, killing four and leaving two others with lifelong injuries. During the investigation, it was determined that the root cause of the problem was twofold. Firstly, the software controlling the machine contained bugs which proved to be fatal. Secondly, the design of the machine relied on the controlling computer alone for safety. There were no hardware interlocks or supervisory circuits to ensure that software bugs couldn’t result in catastrophic failures.

The case of the Therac-25 has become one of the most well-known killer software bugs in history. Several universities use the case as a cautionary tale of what can go wrong, and how investigations can be lead astray. Much of this is due to the work of [Nancy Leveson], a software safety expert who exhaustively researched the incidents and resulting lawsuits. Much of the information published about the Therac (including this article) is based upon her research and 1993 paper with [Clark Turner] entitled “An Investigation of the Therac-25 Accidents”. [Nancy] has since published updated information in a second paper which is also included in her book.

Continue reading “Killed By A Machine: The Therac-25” →

Atmel Introduces Rad Hard Microcontrollers

October 23, 2015 by Brian Benchoff 88 Comments

The Internet is full of extremely clever people, and most of the time they don’t realize how stupid they actually are. Every time there’s a rocket launch, there’s usually a few cubesats tucked away under a fairing. These cubesats were designed and built by university students around the globe, so whenever a few of these cubesats go up, Internet armchair EEs inevitably cut these students down: “That microcontroller isn’t going to last in space. There’s too much radiation. It’ll be dead in a day,” they say. This argument disregards the fact that iPods work for months aboard the space station, Thinkpads work for years, and the fact that putting commercial-grade microcontrollers in low earth orbit has been done thousands of times before with mountains of data to back up the practice.

For every problem, imagined or not, there’s a solution. Now, finally, Atmel has released a rad tolerant AVR for space applications. It’s the ATmegaS128, the space-grade version of the ‘mega128. This chip is in a 64-lead ceramic package, has all the features you would expect from the ATmega128 and is, like any ‘mega128, Arduino compatible.

Atmel has an oddly large space-rated rad-hard portfolio, with space-grade FPGAs, memories, communications ICs, ASICs, memories, and now microcontrollers in their lineup.

While microcontrollers that aren’t radiation tolerant have gone up in cubesats and larger commercial birds over the years, the commercial-grade stuff is usually reserved for low Earth orbit stuff. For venturing more than a few hundred miles above the Earth, into the range of GPS satellites and to geosynchronous orbit 25,000 miles above, radiation shielding is needed.

Will you ever need a space-grade, rad-hard Arduino? Probably not. This new announcement is rather cool, though, and we can’t wait for the first space grade Arduino clone to show up in the Hackaday tips line.

Kids And Hacking: The One Hour Egg Drop

October 23, 2015 by Al Williams 24 Comments

In the last Hacking and Kids post, I talked about an activity you can do with kids when you don’t have a lot of time or resources. The key idea was to have fun and learn a little bit about open and closed loop control. One of the things I usually briefly mention when I do that is the idea of a design trade: Why, for example, a robot might use wheels instead of legs, or treads instead of wheels.

Engineers and makers perform trades like this all the time. Suppose you are building a data logging system. You want precise samples, large storage capacity, and many channels. But you also want a low cost and low power drain. You might also want high reliability. All of these requirements will lead to different trades. A hard drive would provide a lot of space, but is more expensive, less reliable, larger, and more power hungry than, say, an SD card. So there isn’t a right choice. It depends on which of the factors are most important for this particular design. A data logger in a well-powered rack might be well served to have a terrabyte hard drive, while a battery powered logger in a matchbox that will be up on the side of a mountain might be better off with an SD card.

We can all relate to that example, but it is pretty boring to a kid. You probably can’t get them to design a data logger, anyway. But if I have about an hour and a little prep time, I have a different way to get the same point across. It is a modified version of the classic “egg drop”, but it is simple enough to do in an hour with very little preparation time.

Continue reading “Kids And Hacking: The One Hour Egg Drop” →

An Improvement To Floating Point Numbers

October 22, 2015 by Brian Benchoff 168 Comments

On February 25, 1991, during the eve of the of an Iraqi invasion of Saudi Arabia, a Scud missile fired from Iraqi positions hit a US Army barracks in Dhahran, Saudi Arabia. A defense was available – Patriot missiles had intercepted Iraqi Scuds earlier in the year, but not on this day.

The computer controlling the Patriot missile in Dhahran had been operating for over 100 hours when it was launched. The internal clock of this computer was multiplied by 1/10th, and then shoved into a 24-bit register. The binary representation of 1/10th is non-terminating, and after chopping this down to 24 bits, a small error was introduced. This error increased slightly every second, and after 100 hours, the system clock of the Patriot missile system was 0.34 seconds off.

A Scud missile travels at about 1,600 meters per second. In one third of a second, it travels half a kilometer, and well outside the “range gate” that the Patriot tracked. On February 25, 1991, a Patriot missile would fail to intercept a Scud launched at a US Army barracks, killing 28 and wounding 100 others. It was the first time a floating point error had killed a person, and it certainly won’t be the last.

Continue reading “An Improvement To Floating Point Numbers” →

Nomograms: Complex Analog Calculators Simple For Everyone

October 21, 2015 by Kristina Panos 29 Comments

In the late 1800s, a railway engineer named Philbert Maurice d’Ocagne was part of a group of men faced with the task of expanding the French rail system. Before a single rail could be laid, the intended path had to be laid out and the terrain made level. This type of engineering involves a lot of cut and fill calculations, which determine where dirt must be added or removed. The goal of earthwork is to create a gentle grade and to minimize the work needed to create embankments.

In the course of the project, d’Ocagne came up with an elegant, reusable solution to quickly solve these critical calculations. Most impressively, he did it with little more than a pen, some paper, and a straightedge. By developing and using a method which he called nomography, d’Ocagne was able to perform all the necessary calculations that made the gentle curves and slopes of the French railway possible.

Continue reading “Nomograms: Complex Analog Calculators Simple For Everyone” →