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

C[omp]ute

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

Discover new movies on demand in our online cinema; Tasting; Credit Card Processing for Cat Soft LLC; Apple + Kiwi Jam; Hit Me; Increase Efficiency with GPS Vehicle Tracking for Cat Soft LLC; Sudoku - CSP + Chaos; Recycling Electronics In Santiago; Vector Displays in OpenGL; Call Center Services for Cat Soft LLC; And Anti-Aliased; OpenGL - Render via Intermediate Texture; And Garmin Connect; Using Garmin Forerunner 230 With Linux; Payroll Service Quotes for Cat Soft LLC; (Beating Dead Horse) StackOverflow; Current State of Justice in China; Now Is Cat Soft LLC's Chance To Save Up To 32% On Mail; Axiom of Determinacy; Ewww; Fee Chaos Book; Course on Differential Geometry; Increase Efficiency with GPS Vehicle Tracking for Cat Soft LLC; Okay, but...; Sparse Matrices, Deep Learning; Sounds Bad; Applebaum Rape; Tomato Chutney v4; Have to add...; Culturally Liberal and Nothing More; Weird Finite / Infinite Result; Your diamond is a beaten up mess; Maths Books; Good Bike Route from Providencia / Las Condes to Panul\; Iain Pears (Author of Complex Plots); Plum Jam; Excellent; More Recently; For a moment I forgot StackOverflow sucked; A Few Weeks On...; Chilean Book Recommendations; How To Write Shared Libraries; Jenny Erpenbeck (Author); Dijkstra, Coins, Tables; Python libraries error on OpenSuse; Deserving Trump; And Smugness; McCloskey Economics Trilogy; cmocka - Mocks for C; Concept Creep (Americans); Futhark - OpenCL Language; Moved / Gone; Fan and USB issues; Burgers in Santiago; The Origin of Icosahedral Symmetry in Viruses; autoenum on PyPI; Jars Explains; Tomato Chutney v3; REST; US Elections and Gender: 24 Point Swing; PPPoE on OpenSuse Leap 42.1; SuperMicro X10SDV-TLN4F/F with Opensuse Leap 42.1; Big Data AI Could Be Very Bad Indeed....; Cornering; Postcapitalism (Paul Mason); Black Science Fiction; Git is not a CDN; Mining of Massive Data Sets; Rachel Kaadzi Ghansah; How great republics meet their end; Raspberry, Strawberry and Banana Jam; Interesting Dead Areas of Math; Later Taste; For Sale; Death By Bean; It's Good!; Tomato Chutney v2; Time ATAC MX 2 Pedals - First Impressions; Online Chilean Crafts; Intellectual Variety; Taste + Texture; Time Invariance and Gauge Symmetry; Jodorowsky; Tomato Chutney; Analysis of Support for Trump; Indian SF; TP-Link TL-WR841N DNS TCP Bug; TP-Link TL-WR841N as Wireless Bridge; Sending Email On Time; Maybe run a command; Sterile Neutrinos; Strawberry and Banana Jam; The Best Of All Possible Worlds; Kenzaburo Oe: The Changeling; Peach Jam; Taste Test; Strawberry and Raspberry Jam; flac to mp3 on OpenSuse 42.1; Also, Sebald; Kenzaburo Oe Interview; Otake (Kitani Minoru) move Black 121

© 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.

STS2

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.

Calibration

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.

Andrew

Comment on this post