Linux in the Rugged Field

Traditionally, seismologists have used laboratory-based Sun computers to analyze data recorded in the field. But the advent of inexpensive Intel-based laptops and Linux has allowed us to take workstations out of the lab and into the field. This has involved the routine porting of code across OS platforms as well as kernel level development. After a year of hard work, scientists affiliated with the PASSCAL Instrument Center have been using Linux as a portable workstation for seismic studies from Missouri to Massachusetts and from Micronesia to Tanzania.

Contrary to the implications of our name, we are not a group dedicated to or affiliated with the Pascal programming language. PASSCAL, or the Program for Array Seismic Studies of the Continental Lithosphere, is a member program of IRIS (the Incorporated Research Institutions for Seismology), which is a consortium of 90 U.S. universities (there are a number of affiliate members, both foreign and domestic). We have been located at Columbia University's Lamont-Doherty Earth Observatory since 1989, while a second instrument center was established at Stanford University in 1992.

Kobe Earthquake Seismic Data Displayed on a Linux System

In seismology, it is common for a scientist to run an experiment requiring the use of many expensive instruments for a relatively short period of time. Having individual scientists spend hundreds of thousands of dollars on equipment, only to have it collect dust on a shelf for 80% of its life, makes little sense in this era of fiscal belt-tightening. In addition, few scientists have the time to master and integrate equipment from a variety of manufacturers into a reliable data acquisition system.

PASSCAL Team Member Bob Busby in Pakistan

Therefore, the PASSCAL Instrument Center was organized to service the seismic community—providing a powerful and flexible portable instrument along with expertise that can only be obtained via experience. We supply logistic and technical support, provide for system integration and maintenance, and deliver comprehensive feedback to the manufacturers. Since experiments are returning from the field with Terra-Bytes of data, an extensive suite of programs have been developed to assist the seismologists with the acquisition and archiving of data and for assuring data quality. The popularity of this program has grown to the point that experiment scheduling for 1997 is currently underway.

Historically PASSCAL experiments have utilized two separate computer systems, one for data acquisition and one for data analysis. The data acquisition system (DAS) is comprised of a series of weather-tight grey boxes (CPU, SCSI disks, batteries), peripherals (solar panels, GPS receiver), and a hand terminal with an LCD touch-screen to program the DAS and retrieve data. A standard Sparcstation running SunOS, which may or may not be located anywhere near the seismic station, is used for data analysis and quality assurance.

The portable aspect of the PASSCAL instrument explains the program's popularity, at the same time it also introduces logistic difficulties. Investigators frequently erect stations in remote locations, making access difficult and/or expensive. Hence station visits are infrequent, with users allowing the DAS to run for months before they return for data retrieval. Retrieval is accomplished by copying to tape (or spare disk), which is then brought back to the lab for quality control, data analysis and archiving. Detecting problems with the instrument at this stage requires a return trip. (At one of our stations in Micronesia, there is only one flight a week to the island. You fly in, work for 4 hours, wait a week, fly back, check your data, and, if there were any problems, fly back a week later.)

In November of 1993, I installed Linux at home simply to have a operating environment similar to the one I used at work. I got X up and running and discovered the XView libraries sitting there serendipitously on my hard disk. One major piece of code for which I was responsible uses X (via XView) for displaying seismic traces, and approximately 17 milliseconds later I decided to port this program to Linux, just so I could work at home.

One day I dragged my PC into work to show everyone what Linux could do. A member of our team remarked that if we could run this on a portable computer, we could actually look at the raw data and perform spectral analyses of the data in the field, while there is still time to correct mistakes. That led to the thought that if we had a computer with X-windows in the field, we could even write some user-friendly and powerful software to program the DAS, instead of using the hand-terminal.

At the time we were actually experiencing a dilemma concerning the programming of the DAS's. Epson manufactures the hand terminal, which runs a simple basic program and interfaces to the DAS via a serial port. This hand terminal is fairly user-friendly: Just point with your finger and push. The problem is that only rudimentary diagnoses can be made with the hand terminal. There is a DOS-based alternative to this program that is more powerful (i.e. has many options), but “user friendly” is not a phrase we use to describe it.

Since many of our users only perform field work every few years, and many are novice grad students, user friendliness is of utmost importance to guarantee data integrity. The idea of combining the power of the DOS program with the ease of use of the hand terminal into a beautiful X-windows program was compelling.

With a dream and a need, we did what many of you have done: We went looking for money. Selling the laptop idea was actually quite easy; selling Linux was another matter. Since all of our existing code was written to run under SunOS and X Windows we did not even entertain the idea of porting our code to MS-Windows or OS2.

However I was not actually sold on Linux, myself. My first PC-Unix experience was with Interactive Unix, back when it was owned by Kodak. I really had no objection to going with them again (or SCO, or whomever). We investigated the alternatives, and as many of you have also discovered: chances are good that Linux provides better support than the other PC-Unixes for any given piece of hardware. After demonstrating that to ourselves and our boss, we went with Linux.

We purchased our first two laptops in early 1994, primarily to study the feasibility of running Linux laptops in the field. When my co-workers Paul Friberg and John Webber and I began porting major pieces of our code, we hit our first bottleneck in very short time: SCSI. All of our data is acquired and stored on SCSI devices, and much of our code required data just to be tested. Our quick-fix was to purchase a docking station and install a SCSI adapter here. Obviously this was neither a permanent nor portable solution, but it was enough to get us started.

We looked into PCMCIA SCSI, but no support existed at that time. We reasoned that with the infancy of the technology, support could not be expected immediately, but would be coming along shortly. Foolishly, we decided to wait for it while proceeding with the development of all the other code we would need.

Because we are also heavily entrenched in Tcl/Tk, we decided to write a Tcl/Tk-based replacement for the hand terminal. We managed to combine the hand terminal's point-and-click ease of use with the functionality of the DOS program. The BLT extensions to Tcl/Tk made this program downright fancy.

We also wrote a program to display seismic data in real time, allowing users to examine the background signal of the seismometer before walking away and leaving it for a few months. (The alternative has always been to acquire data to disk, run some data conversion programs, load up the data into the viewer, make changes to the instrument and repeat the procedure. This, of course, assumes that you have a workstation near the seismometer.) The new option of acquiring and displaying in real-time while making adjustments can easily save time and effort.

At this point we had assembled a sizeable suite of programs, and all that remained was getting the data. Again we asked around the net, but no-one knew of a Linux supported PCMCIA SCSI card. Gennady Pratusevich, our engineer, decided to write a driver for Linux, and we decided to go with the Trantor/Adaptec card. Since most of the other Adaptec cards were well-supported, we figured that Adaptec would provide us with the programming information. We were quite wrong.

We started searching around for SCSI cards from companies that would supply us with programming information. We found a small producer of such cards in Colorado, initially he seemed interested in Linux, but he never got back to us again. We considered developing our own card when some Linux newsgroup wisdom indicated that the New Media Bus Toaster used the AIC6360 chipset. This is the same chipset used by the Adaptec 1522 board. We purchased a Bus Toaster and, armed with the source code for the Adaptec 1522 driver, David Hind's PCMCIA code, and a few assorted manuals, Pratusevich managed to create a fully functional SCSI driver. With the subsequent introduction of loadable SCSI modules, the real power of PCMCIA was realized, allowing us to swap disks on the fly. We were finally ready for prime time.

I would like to point out here that if we had chosen an operating system that did not release the source code, this would have been the tragic end of our story.

Last December we attended the fall meeting of the American Geophysical Union in San Francisco, having just taken delivery of 5 additional laptops. Usually we have our Sun Sparcstations on prominent display, but this year they were hidden behind our Linux laptops (as if a full-sized workstation could hide behind a 7-pound laptop). Linux was a hit, and everyone wanted one.

The second week of January saw us shipping four laptops into the field. Preliminary reports are encouraging. The laptops work and are making life easier for our users. The people using these machines are not Linux experts, but the machines are easy enough to use that people would rather utilize these than any currently available DOS alternative.

We did not originally expect Linux to be the way to go for us. Obviously porting to a Sparc laptop would have required much less work, but they are prohibitively expensive. We also looked into Solaris for PC's, but the minimal volume of hardware that Solaris supports turned us away. If any of you are trying to convince your supervisors to go with Linux, first sell the idea of Unix, and then have them compare Linux to Solaris and the like. The best decision becomes obvious at this point.