| 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

Bicycle Wheels, Inertia, and Energy; Another Tax Fraud; Google's Borg; A Verion That Redirects To Local HTTP Server; Spanish Accents For Idiots; Aluminium Cans; Advice on Spray Painting; Female View of Online Chat From a Male; UX Reading List; S4 Subgroups - Geometric Interpretation; Fucking Email; The SQM Affair For Idiots; Using Kolmogorov Complexity; Oblique Strategies in bash; Curses Tools; Markov Chain Monte Carlo Without all the Bullshit; Email Para Matias Godoy Mercado; The Penta Affair For Idiots; Example Code To Create numpy Array in C; Good Article on Bias in Graphic Design (NYTimes); Do You Backup github?; Data Mining Books; SimpleDateFormat should be synchronized; British Words; Chinese Govt Intercepts External Web To DDOS github; Numbering Permutations; Teenage Engineering - Low Price Synths; GCHQ Can Do Whatever It Wants; Dublinesque; A Cryptographic SAT Solver; Security Challenges; Word Lists for Crosswords; 3D Printing and Speaker Design; Searchable Snowden Archive; XCode Backdoored; Derived Apps Have Malware (CIA); Rowhammer - Hacking Software Via Hardware (DRAM) Bugs; Immutable SQL Database (Kinda); Tor GPS Tracker; That PyCon Dongle Mess...; ASCII Fluid Dynamics; Brandalism; Table of Shifter, Cassette and Derailleur Compatability; Lenovo Demonstrates How Bad HTTPS Is; Telegraph Owned by HSBC; Smaptop - Sunrise (Music); Equation Group (NSA); UK Torture in NI; And - A Natural Extension To Regexps; This Is The Future Of Religion; The Shazam (Music Matching) Algorithm; Tributes To Lesbian Community From AIDS Survivors; Nice Rust Summary; List of Good Fiction Books; Constructing JSON From Postgres (Part 2); Constructing JSON From Postgres (Part 1); Postgres in Docker; Why Poor Places Are More Diverse; Smart Writing on Graceland; Satire in France; Free Speech in France; MTB Cornering - Where Should We Point Our Thrusters?; Secure Secure Shell; Java Generics over Primitives; 2014 (Charlie Brooker); How I am 7; Neural Nets Applied to Go; Programming, Business, Social Contracts; Distributed Systems for Fun and Profit; XML and Scheme; Internet Radio Stations (Curated List); Solid Data About Placebos; Half of Americans Think Climate Change Is a Sign of the Apocalypse; Saturday Surf Sessions With Juvenile Delinquents; Ssh, tty, stdout and stderr; Feathers falling in a vacuum; Santiago 30m Bike Route; Mapa de Ciclovias en Santiago; How Unreliable is UDP?; SE Santiago 20m Bike Route; Cameron's Rap; Configuring libxml with Eclipse; Reducing Combinatorial Complexity With Occam - AI; Sentidos Comunes (Chilean Online Magazine); Hilary Mantel: The Assassination of Margaret Thatcher - August 6th 1983; NSA Interceptng Gmail During Delivery; General IIR Filters; What's happening with Scala?; Interesting (But Largely Illegible) Typeface; Retiring Essentialism; Poorest in UK, Poorest in N Europe; I Want To Be A Redneck!; Reverse Racism; The Lost Art Of Nomography; IBM Data Center (Photo); Interesting Account Of Gamma Hack; The Most Interesting Audiophile In The World; How did the first world war actually end?; Ky - Restaurant Santiago; The Black Dork Lives!; The UN Requires Unaninmous Decisions; LPIR - Steganography in Practice

© 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