| Andrew Cooke | Contents | Latest | RSS | Twitter | Previous | Next


Welcome to my blog, which was once a mailing list of the same name and is still generated by mail. Please reply via the "comment" links.

Always interested in offers/projects/new ideas. Eclectic experience in fields like: numerical computing; Python web; Java enterprise; functional languages; GPGPU; SQL databases; etc. Based in Santiago, Chile; telecommute worldwide. CV; email.

Personal Projects

Lepl parser for Python.

Colorless Green.

Photography around Santiago.

SVG experiment.

Professional Portfolio

Calibration of seismometers.

Data access via web services.

Cache rewrite.

Extending OpenSSH.

C-ORM: docs, API.

Last 100 entries

Small Success With Go!; Re: Quick message - This link is broken; Adding Reverb To The Echo Chamber; Sox Audio Tools; Would This Have Been OK?; Honesty only important economically before institutions develop; Stegangraphy via PS4; OpenCL Mess; More Book Recommendations; Good Explanation of Difference Between Majority + Minority; Musical Chairs - Who's The Privileged White Guy; I can see straight men watching this conversation and laffing; When it's Actually a Source of Indignation and Disgust; Meta Thread Defending POC Causes POC To Close Account; Indigenous People Of Chile; Curry Recipe; Interesting Link On Marginality; A Nuclear Launch Ordered, 1962; More Book Recs (Better Person); It's Nuanced, And I Tried, So Back Off; Marx; The Negative Of Positive; Jenny Holzer Rocks; Huge Article on Cultural Evolution and More; "Ignoring language theory"; Negative Finger Counting; Week 12; Communication Via Telecomm Bids; Finding Suspects Via Relatives' DNA From Non-Crime Databases; Statistics and Information Theory; Ice OK in USA; On The Other Hand; (Current Understanding Of) Chilean Taxes / Contributions; M John Harrison; Playing Games on a Cloud GPU; China Gamifies Real Life; Can't Help Thinking It's Thoughtcrime; Mefi Quotes; Spray Painting Bike Frame; Weeks 10 + 11; Change: No Longer Possible To Merge Metadata; Books on Old Age; Health Tree Maps; MRA - Men's Rights Activists; Writing Good C++14; Risk Assessment - Fukushima; The Future of Advertising and Surveillance; Travelling With Betaferon; I think I know what I dislike so much about Metafilter; Weeks 8 + 9; More; Pastamore - Bad Italian in Vitacura; History Books; Iraq + The (UK) Governing Elite; Answering Some Hard Questions; Pinochet: The Dictator's Shadow; An Outsider's Guide To Julia Packages; Nobody gives a shit; Lepton Decay Irregularity; An Easier Way; Julia's BinDeps (aka How To Install Cairo); Good Example Of Good Police Work (And Anonymity Being Hard); Best Santiago Burgers; Also; Michael Emmerich (Vibrator Translator) Interview (Japanese Books); Clarice Lispector (Brazillian Writer); Books On Evolution; Looks like Ara (Modular Phone) is dead; Index - Translations From Chile; More Emotion in Chilean Wines; Week 7; Aeon Magazine (Science-ish); QM, Deutsch, Constructor Theory; Interesting Talk Transcripts; Interesting Suggestion Of Election Fraud; "Hard" Books; Articles or Papers on depolarizing the US; Textbook for "QM as complex probabilities"; SFO Get Libor Trader (14 years); Why Are There Still So Many Jobs?; Navier Stokes Incomplete; More on Benford; FBI Claimed Vandalism; Architectural Tessellation; Also: Go, Blake's 7; Delusions of Gender (book); Crypto AG DID work with NSA / GCHQ; UNUMS (Universal Number Format); MOOCs (Massive Open Online Courses); Interesting Looking Game; Euler's Theorem for Polynomials; Weeks 3-6; Reddit Comment; Differential Cryptanalysis For Dummies; Japanese Graphic Design; Books To Be Re-Read; And Today I Learned Bugs Need Clear Examples; Factoring a 67 bit prime in your head; Islamic Geometric Art; Useful Julia Backtraces from Tasks; Nothing, however, is lost with less discomfort than that which, when lost, cannot be missed

© 2006-2015 Andrew Cooke (site) / post authors (content).

Calibrating STS2 Sensors

From: andrew cooke <andrew@...>

Date: Sun, 8 Jul 2012 14:07:36 -0400

General Hardware

The sensors used to detect earthquakes are fairly simple, at least at my level of understanding. There are two boxes: the digitizer and the sensor.

The digitizer generates streams of numbers that show the output from the sensor channels (more on those in a minute). It also contains some control electronics that can do things like generate a test signal.

The sensor contains three channels, which work independently. Each channel contains a mass on a spring. When the earth (and the sensor, which is fastened to the earth) moves, the mass bounces up and down on the spring. This generates an electrical signal that the digitizer measures.

The channels are arranged at right angles to each other, and the mass in each channel can only move in one direction. Traditionally, one channel has a mass moving vertically (which I call Z below), another has a mass moving North-South (X), and another East-West (Y).

So when there is an earthquake, the masses inside the sensor channels bounce up and down, and the digitizer records three signals, for motion in X, Y and Z.


The hardware described above has two different kinds of channels - one for horizontal and one for vertical motion. These are different because the mass has to be supported in different ways. And this makes sensors complicated to manufacture.

So someone had the bright idea of rotating the whole sensor so that all the channels were at an angle. They are still at right angles to each other, but they all are on a slope (if you imagine a cube balanced on one corner, then the channels point along the edges of the cube that meet at the corner). I will call these directions U, V and W below.

In this way you can measure movement in 3D, but you only have to make one kind of channel (although you still need three of them to get the full 3D signal).

To make it easy to connect this new kind of sensor to standard digitizers the manufacturers added some extra circuitry that added (and subtracted) the signals for the different channels (which measure movement on a slope) so that the outputs of the sensor (which are connected to the digitizer) show the effective movement in the X, Y and Z directions.

There's a more precise description here that might help explain what is happening.


Calibrating a traditional sensor is pretty easy. The sensor channels are made so that you can send a signal to them that moves the mass. So all you need to do is get the digitizer to send a test signal to each channel and then measure the output from the channel. By comparing the input and output you can work out how well the sensor responds to movement.

And this works just fine. It's what I have been doing recently - writing a program that does this.

But with sensors like the STS2, where the channels are on a slope, things are more difficult. You see, digitizers generate a single test signal. For traditional sensors that works nicely - you can send that signal to all the sensor channels, collect all the outputs from the digitizer, and calibrate all three channels at once. Which saves time.

But if you try doing the same to the STS2 you only see a signal in Z. The X and Y signals are zero. That's because when the same signal is sent to move the masses of all the channels, all the masses move in the same direction at the same time. And because they are arranged in a symmetrical way, the X and Y movements (calculated by the extra bit of electronics I mentioned, that adds and subtracts the different channels) adds up to zero.

This is only a problem when calibrating, of course. In normal use each channel has a different signal, and the sums and differences are not zero (unless, I guess, the earthquake is such that the earth happens to move in exactly a X direction, say, in which case Y and Z will be zero - but even then, that's not a problem, because you still measure what you want).

But for calibrating, life is suddenly more complicated. We cannot calibrate everything at once, like we could with the traditional sensors. What dow we do instead?

The reference I linked to above describes two possible approaches:

  1. You can juggle the calibration signals so that you "fake" a signal in each direction (Z, X and Y) in turn or

  2. You can calibrate the channels separately and use the formula given.

Option 1 is no good for an automated system, since we have only a single signal and no way to change connections. Option 2 sounds great, except that it's so vague that it's not clear at all what you actually need to do.

So below I explain what I think option 2 means. I must emphasise that this is just my own initial thoughts and doesn't represent the opinion of any employer or client of mine.

Calibrating UVW

I will use the following notation: \({\bf a}\) is a vector in XYZ with components \(a_i\); \({\bf a^\prime}\) is a vector in UVW; \({\bf M}\) is a \(3\times 3\) matrix s.t.:

\[{\bf a} = {\bf M} {\bf a}^\prime\] \[{\bf a}^\prime = {\bf M^{-1}} {\bf a}\]

so XYZ and UVW have the same origin (at the sensor centre). Note that \({\bf M}\) is defined as the transformation from UVW to XYZ, to follow the convention in the reference I linked to earlier.

Now, assume that the earth moves with velocity \({\bf a}e^{i\omega t}\). In UVW this is \({\bf M}^{-1}{\bf a}e^{i\omega t}\).

Then the voltage generated internally for each coil is \({\bf K}(\omega){\bf M}^{-1}{\bf a}e^{i\omega t}\) where \({\bf K}(\omega)\) is a diagonal matrix that represents the response of individual sensors at angular frequency \(\omega\) (I will omit \(\omega\) below for clarity).

The output seen by the digitizer is then \({\bf M}{\bf K}{\bf M}^{-1}{\bf a}e^{i\omega t}\), since the sensor internally transforms the signal back to XYZ.

What we need to measure - what the client typically wants - is \[{\bf g} = {\bf M}{\bf K}{\bf M}^{-1}{\bf a}/{\bf a}\] (where division is component-wise). This is the effective response of the sensor in XYZ.

But we cannot do this directly, because if we supply a signal directly to all coils then two components of \({\bf a}\) are zero (as I described in detail above).

Instead, we send a signal \({\bf a^\prime}\) in UVW. We can then measure \[{\bf h} = {\bf M}{\bf K}{\bf a^\prime}\] and, by selecting \[{\bf a^\prime} = {\hat {\bf u}}^\prime\ {\rm or}\ {\hat {\bf v}}^\prime\ {\rm or}\ {\hat {\bf w}}^\prime\] (ie along just one channel at a time) we can isolate the individual components of \({\bf K}\). And since \({\bf M}\) is known exactly, we only need to measure the Z output (from geometry this will always be non-zero).

Now let's expand the expressions above so that we get the explicit values. We will use the summation convention s.t. \(a_j = M_{ij} a^\prime_i\).

Let's call the Z component of \({\bf h}\) when we exite coil \(n\) as \(h^n_3\) (note that \(^n\) is an index, not a power). Then \[h^n_3 = M_{j3} K_{ij} \delta_{in} = M_{n3} k_n\] so we fully determine \(k\).

Then we can calculate \({\bf g}\): \[g_l = M_{kl} K_{jk} M_{ij}^{-1} \delta_{il} = M_{jl} (h^j_3 / M_{j3}) M_{lj}^{-1}\,.\]

Finally, \({\bf M}\) is an orthogonal matrix, so \({\bf M}^{-1} = {\bf M}^T\) and so \(M_{jl} = M^{-1}_{lj}\). Therefore \[g_l = M^2_{jl} h^j_3 / M_{j3}\] where the first term appears to be the matrix of squared values in the reference, the second term is the vector of measured responses in Z when sending a signal to U, V and W, and the third term is a normalization to the three responses which, for a symmetric system like STS2, is the same for all axes.


Comment on this post