Collecting Data and Deer Ticks

June 14th, 2013

These past three days I've been out in the field retrieving data from the OIINK standalone stations. We recovered data from 21 stations, which coincidentally was about the number of ticks I had to pick off my body throughout the three days. Another day in the life of a Midwest field seismologist. Despite our country's wealth of cellular networks, the current location of our array lies in an area with mediocre cell service at best. Thus, the stations that cannot be relied upon to provide real time telemetry data are left to themselves to record their data all alone. How depressing it must be for the standalone DASes, only getting attention once every couple of months. For the other interns who are reading this, our stations are almost identical to the ones we set up during orientation. Same setup, same equipment, and similar procedures.

The general process for recovering data from a station is relatively simple if nothing is awry. You head to the station, record the status of the instruments, check to make sure the masses are aligned correctly, dump all the data to the disk, remove the disk or disks and replace them with empty ones, and ensure the new disks are recording properly. This only takes about 20-30 minutes if everything looks okay. However that isn't always the case, as I'm sure you can imagine. The most common problem is for one of the mass channels to be off-center. For those readers that haven't worked with such instruments, the masses that move when the ground shakes are controlled by electronics that send pulses of electricity to keep the mass in the center. These pulses are translated into the amplitude of ground motion. There are three separate channels that measure different components of motion, vertical, east-west, and north-south. There is a standard voltage range which represents the mass being "centered" and everything working correctly. If the mass voltages are outside this range, a centering command needs to be sent to the sensor to realign the masses into the correct positions. This is done automatically every five days, and can be sent remotely via telemetry for many stations, but has to be done manually for the standalone stations. Sometimes the auto-centering command sent every five days works, and other times it isn't enough. There is a whole slew of reasons why the masses can get off center on both the hardware and software sides.

A few of our stations ended up having dead channels that were unfixable within the time frame of this servicing run. The sensors were not recognizing where the center was supposed to be, and would instead just slide themselves along the whole range of voltages only to return to their original position. As I had been told many times, there are so many things that can go wrong in field seismology, and I was definitely able to see first hand quite a few of them! Although it takes longer when you have to open up the actual sensor vault to check the level and check if the mass balance is a hardware issue, I enjoyed the experience of having to troubleshoot a little bit. Below is a nifty little picture of one of the trouble-maker stations that we tried to open up and fix.

Considering we were recovering raw data from our stations, I figured this is probably a good time to detail the data set I am working with a little bit. I've given bits and pieces of the past couple of weeks, but I don't know if I've outlined the data set in specifics. The OIINK Flexible Array experiment has already been going for a couple of years now. I am jumping into the project somewhat in the middle, although the conclusions on the data are far from being reached. Data has been collected continuously as the array is moved to different locations in the Midwest. The specific data I am working with for my P-Wave tomography project is new 2013 data from the array. It is 100% raw, and hasn't been looked at by anyone other than my mentor, Dr. Pavlis, and myself. We take the raw waveform data directly from our real time telemetry computer or from the flash cards we collect on service runs like the one I just returned from. In fact, the data we just recovered this week will soon be on my computer screen for processing. Or maybe in the next couple of weeks, as I still have a couple hundred events to process first. All of this raw data is taken and organized into an antelope database where it can be pulled into different applications for easier viewing and processing on my end. Everything I do is run within the database structure. When I make my P-wave arrival picks, they are plugged directly into the working database. This makes it easy to manage, as I don't have to worry about file paths once everything is set up, although it does require me to go through the database structure for absolutely everything. If I want to edit a single waveform, I have to go find it in the database. Thankfully, databases make sorting the data really really easy.

As I shared in my last blog, I'm enjoying working with the raw data despite its complexities. I've had to learn how to work with the database structure, although it is getting easier and easier as I continue my work. And it is always nice to have the person who built the database working down the hall. This past week has brought the whole data set full circle for me, as I've seen exactly where my data is coming from and helped to collect some of it. To me, that's important to know, as it helps remind me that I'm not just staring at random squiggles on a screen. Those squiggles were collected as a result of the hard work of installation and collection teams, who probably picked a few ticks off themselves as well.