Earthquake Data Logger

Skill Level: Beginner

December 07, 2010 | 20 comments

Not every project you create is destined for greatness. Or success. Or even completion. Sometimes you watch your lovingly crafted project fly away never to be seen again. Sometimes your project might be a "success" but provide an underwhelming result. This is the story of such a project.

Christchurch, New Zealand - where I live - had a 7.1 magnitude earthquake in early September this year. (And, no, none of my projects caused the earthquake.) While some areas had significant property damage there was no loss of life directly attributed to the earthquake. After an earthquake of this magnitude, smaller  - but still noticeable - aftershocks can continue for weeks or months. As of mid-November there had been over 3000 aftershocks.

Following the main earthquake and aftershocks, GeoNet became a popular destination to find out the magnitude of events and view the images generated from the Seismograph Drums. This is one of the images generated from data recorded from one seismograph drum during the magnitude 4.7 and 4.9 earthquakes I describe later in this post:

One day I started pondering whether it would be possible to use an accelerometer to detect some of the aftershocks when they occurred. I had read about the Quake-Catcher Network project which distributes USB connected accelerometers for detection and research. But, hey, we like to make things ourselves here, don't we?

Unfortunately when the idea first occurred to me I didn't have any accelerometers and by the time I organized delivery most of those three thousand aftershocks had been and gone. This was probably the first sign the project was not to have a huge impact on the world of scientific discovery.

Choosing the Hardware

When deciding on the accelerometer to use I had the choice of an ADXL335 or an ADXL345. I decided to start with the ADXL335 because it's an analog device which means it's easier to hook up and get started with. (The ADXL345 uses SPI or I2C digital signals to communicate and because it's a 3.3V device I'd need to use some form of level conversion to hook it up.) While the ADXL335 can also be powered with 3.3V we only receive information from it so we do not need level conversion. We do, however, need to take this lower maximum voltage into account when interpreting the values received. (You may well think I'm making specific note of this because I forgot to take this into account until I started writing this post, but I couldn't possibly comment.)

An Arduino was my choice of microcontroller platform and it has more than enough analog to digital (ADC) inputs to handle the three axis accelerometer. It also has a 3.3V supply that can supply the small amount of current needed by the ADXL335.

It's always nice when someone has done the work of figuring out how to connect a device and in this case the Wiring project had a page demonstrating how to connect the ADXL335 to a board similar to an Arduino.

Writing the Software

Even better is when you've found someone has written the code you need to both retrieve the data from the device you're using and display the data in a useful manner. In this case the blog post Realtime Graphing of Accelerometer/Gyroscope Data helpfully had code for the Arduino to read the accelerometers and code for Processing to display the readings in real-time on a pretty graph.

I tried out the code and got some nice graphs when I moved the accelerometer around or placed it on a desk and thumped the desktop. Things were going well.

While displaying real-time graphs is nice if you're wanting to look at data immediately, for earthquake detection I was wanting something different. Most of the time the data you're receiving is uninteresting - all it's doing is indicating "no earthquake happening now". This means we want some way to store the data so we can go back and extract just the interesting parts from when an aftershock occurs.

My original plan was to use the WiFly shield to send the accelerometer data to some place "in the cloud" because apparently that's where all the cool kids are sending it these days. (Although the cloud does have its downsides.) Pachube is one web site that specializes in logging data from devices on the "Internet of Things". While I was looking at possible data logger options I also discovered Nimbits which apparently also enables you to run your own instance of their data logger application.

It was at this point I realized I may have a problem. The accelerometer was going to be producing tens of readings per second but - as far as I could tell - none of the cloud-based data loggers supported receiving data at this rate. I considered batching the readings and uploading them once every few minutes but again - as far as I can tell - none of the services support batch upload either. And, even if they did, I would have to deal with the situation of working out how to upload the previous data while still logging the new incoming data.

With reluctance, I decided to take a new approach, as I noted in my project log:

Given the low-ish likelihood of detecting an aftershock and the low likelihood of the building holding the Arduino falling to the ground, in the short term it probably makes sense to just record the data to SD card and retrieve it manually. This is less exciting but will result in something quicker. While there's a definite value in having direct to the web uploading the effort to create the infrastructure to support it is probably not really justifiable at the moment.

The MicroSD shield provided an easy way to record the data as I had already written a simplified wrapper library for the great sdfatlib library for another project. A slightly modified version of this wrapper library will soon be available as the SD library in the next Arduino release. After modifying a few lines of the original code it was now writing the accelerometer readings to a MicroSD card.

Collecting the Data

For power I decided to use a standard nine volt wall wart power supply. If I was really worried about the power going out during a quake I could have looked at some form of battery backup but under the KISS rule I left that for another day.

Here's the complete system wired up in its fancy enclosure:

I wasn't entirely sure where the best place would be to locate the device - originally I just had it sitting on the carpet under my desk but the results from there didn't seem to be very useful. I ended up sitting it on a window sill and just had to hope it didn't get knocked around by other people in the office.

Since I wasn't using the WiFly module I didn't have an easy way to get the current time for each data point I logged. A GPS might have been able to get enough of a lock for a time signal but initially I still wasn't sure how well the device would work. Once again I took the KISS option and just recorded the number of milliseconds since the last reset. (If I was more organized I would have noted the start time somewhere so I could calculate points after that—but apparently I wasn't.)

Once I had everything connected up I left it running until the earth decided to next move. From memory by this stage aftershocks had dropped from many a day to one or two a week.

Eventually a noticeable aftershock occurred and when I was next in the office I took a look at the data. There really wasn't much to see. Even when there was no earthquake the sensors would swing between a couple of values and there were no significant outliers. This was when I decided to try out the window sill as a better option.

Around a week later, early one Sunday morning there was an aftershock followed by another later in the day - around 4.7 and 4.9 in magnitude. I happened to be sitting outside in an armchair at the time and the shocks were noticeable for a number of seconds. (And, yes, I did check it wasn't someone rocking the armchair.) The GeoNet image near the beginning of the post shows how one of their seismographs recorded these particular aftershocks.

Processing the Data

It turns out recording around twenty samples per second generates rather a lot of data. In fact, about five million rows in the log files for around a week's worth of data. Given that your average spreadsheet tops out at a few tens of thousands of rows I needed to find a different way of processing the data. I tried out a few different software packages but didn't have much success.

I ended up using a combination of command line tools (cut, sort and uniq) and Python to produce an initial summary:

Apart from a couple of outliers, my data logger had recorded a range of six values from 401 to 407 in the z-axis for a ~4.9 magnitude quake. Underwhelming, to say the least. Either something wasn't working or my understanding of something was wrong. Time to do some more reading.

After some further reading and some calculations it turns out that each time the value changed by one it represented a fraction less than one percent of the force of gravity. Once I discovered this I then found some sites with more information about the relationship between "peak ground acceleration" and MMI scales. Acceleration of 1-2% of gravity is apparently at the point that shaking is noticeable ("strong motion"). The values I was seeing were consistent with a magnitude of 4.0-4.9, intensity I-IV or 1.4 - 3.9 % of gravity.  

I was successfully detecting earthquakes. The numbers just weren't very impressive.

Displaying the Result

After the massaging the data in a spreadsheet I could graph the results for the most intense period of activity (about 5 seconds) in all their less than awesome glory:

Plot of raw ADC value for each axis over ~5s time (yellow = z, red = y, blue = x)

Plot of relative ADC value for z axis over ~5s time

And there you have it, a successful if underwhelming result!

What Would I Do Differently Next Time?

I'd probably try to get an accelerometer with a narrower range which would mean a higher resolution within that range. The Accelerometer and Gyro Buying Guide has a number of options in the +/-1g or +/-2g range which would (hopefully!) be more than enough for any aftershock. That means smaller movement could be detected.

I'd also take better advantage of the existing range by using the Arduino AREF functionality to restrict the values from 0 to 3.3V thus improving the resolution.

Another option would be to consider a higher-resolution ADC than the inbuilt one but there is a point where (especially since this is all on a breadboard) the increased resolution would obscured by noise.

I'd also work out a way to have a proper time-stamp on each sample.

Your Turn!

Have you ever tried recording a natural phenomenon like earthquakes?

How would you process the large amounts of data a project like this can generate?

I'm not a geologist nor have I developed many data logging projects, do you have suggestions for how to improve this project or writeup?

Got your own story to share about a project with less than spectacular results?

Leave a comment and let us know...