Kenneth M. Cruikshank
Guralp Seismometer

The Geology Department purchased a Guralp Seismometer, mostly as an educational tool to have recordings made in the building, it is not installed in a proper seismic vault, but it does a nice job, even in out noisy urban environment.

It soon became apparent that people liked to see the classical drumplot (as opposed to say, a spectrogram). So I set up a monitor to show the activity. The software provided was not quite what we wanted, so we wrote our own. The task was to write something that shows a traditional drumplot, and could work on a remote computer. The program was also written so that it can put a "screen shot" on our website at regular intervals (see http://seismos.geology.pdx.edu).

Needless to say, there were lots of little issues, mostly dealing with keeping the display properly synced in time (because of the peculiarities of the timer function the program would, over days or weeks, end up either running fast or slow. The answer was to let it be slow, and when it had fallen behind a couple of second to speed up the display for a short time until it had caught up. Do this with a small enough increment of time and the audience is not aware of what is going on.

Filtering was also an issue. We have a very noisy environment, so we wanted to optimize the display for distant earthquakes. If we need to we can use the Guralp Scream! program to produce more precise plots of an event.

For the display, the program requests 6-second packets from the Seismometer control software, unpacks that data stream, then places in on the screen in 'real-time" (i.e., it takes 6 seconds to plot a data packet, even though when we first get it the packet it 6 seconds behind real-time. The program will work across the net if you know the IP address of the Scream! server (this is usually on a computer attached directly to the seismometer).

Since the program is for display, not for logging data, there are several things I just plain ignored. One is missing packets. If we don't get a packet, I simply fill that time with zero's. Since missing packets are rare, it was not worth the time for a display program to try and recover missing packets and fill in the gaps. Partly because it would be 12 seconds before we caught that we were missing a packet, and longer to get it and insert it in the right sequence (the Guralp packet format does allow you go get missing packets).

I did put in the ability to produce a frequency plot, however that turned out to be of little use in displaying for the general public. Too much information! A squiggly line is easy for people to get the idea that the ground is moving (even it it is a plot of voltage, with is related to velocity an not actual displacement).

The program was written in C# using Windows Forms. The stand-along programs were also written in C#, but run from the command line (so they can be easily run from scripts).

The program needs a fair amount of work to be a solid stand-alone program, mostly in the area of error handling. This is where the amount of time it would take me to put in the error handling is considerably more time that I would ever loose from running the program myself and having the odd crash.

There are several programs in this suite. One takes a daily data file and produces a single plot for each component for the day, one routine that will plot a set time window on a single line (to show more detail of an event)

• Generate a GIF "drumplot" from a 24-Hour Guralp File.
• Powershell script to generate all three components given a day, or process every day in a range
• Real-time drumplot display (with optional GIF generation every xx minutes): SeismicDisplay.zip
• From Guralp: Matlab routine to read a GCF file