Andrew Cooke | Contents | Latest | RSS | 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

Choochoo Training Diary

Last 100 entries

Surprise Paradox; [Books] Good Author List; [Computing] Efficient queries with grouping in Postgres; [Computing] Automatic Wake (Linux); [Computing] AWS CDK Aspects in Go; [Bike] Adidas Gravel Shoes; [Computing, Horror] Biological Chips; [Books] Weird Lit Recs; [Covid] Extended SIR Models; [Art] York-based Printmaker; [Physics] Quantum Transitions are not Instantaneous; [Computing] AI and Drum Machines; [Computing] Probabilities, Stopping Times, Martingales; bpftrace Intro Article; [Computing] Starlab Systems - Linux Laptops; [Computing] Extended Berkeley Packet Filter; [Green] Mainspring Linear Generator; Better Approach; Rummikub Solver; Chilean Poetry; Felicitations - Empowerment Grant; [Bike] Fixing Spyre Brakes (That Need Constant Adjustment); [Computing, Music] Raspberry Pi Media (Audio) Streamer; [Computing] Amazing Hack To Embed DSL In Python; [Bike] Ruta Del Condor (El Alfalfal); [Bike] Estimating Power On Climbs; [Computing] Applying Azure B2C Authentication To Function Apps; [Bike] Gearing On The Back Of An Envelope; [Computing] Okular and Postscript in OpenSuse; There's a fix!; [Computing] Fail2Ban on OpenSuse Leap 15.3 (NFTables); [Cycling, Computing] Power Calculation and Brakes; [Hardware, Computing] Amazing Pockit Computer; Bullying; How I Am - 3 Years Post Accident, 8+ Years With MS; [USA Politics] In America's Uncivil War Republicans Are The Aggressors; [Programming] Selenium and Python; Better Walking Data; [Bike] How Fast Before Walking More Efficient Than Cycling?; [COVID] Coronavirus And Cycling; [Programming] Docker on OpenSuse; Cadence v Speed; [Bike] Gearing For Real Cyclists; [Programming] React plotting - visx; [Programming] React Leaflet; AliExpress Independent Sellers; Applebaum - Twilight of Democracy; [Politics] Back + US Elections; [Programming,Exercise] Simple Timer Script; [News] 2019: The year revolt went global; [Politics] The world's most-surveilled cities; [Bike] Hope Freehub; [Restaurant] Mama Chau's (Chinese, Providencia); [Politics] Brexit Podcast; [Diary] Pneumonia; [Politics] Britain's Reichstag Fire moment; install cairo; [Programming] GCC Sanitizer Flags; [GPU, Programming] Per-Thread Program Counters; My Bike Accident - Looking Back One Year; [Python] Geographic heights are incredibly easy!; [Cooking] Cookie Recipe; Efficient, Simple, Directed Maximisation of Noisy Function; And for argparse; Bash Completion in Python; [Computing] Configuring Github Jekyll Locally; [Maths, Link] The Napkin Project; You can Masquerade in Firewalld; [Bike] Servicing Budget (Spring) Forks; [Crypto] CIA Internet Comms Failure; [Python] Cute Rate Limiting API; [Causality] Judea Pearl Lecture; [Security, Computing] Chinese Hardware Hack Of Supermicro Boards; SQLAlchemy Joined Table Inheritance and Delete Cascade; [Translation] The Club; [Computing] Super Potato Bruh; [Computing] Extending Jupyter; Further HRM Details; [Computing, Bike] Activities in ch2; [Books, Link] Modern Japanese Lit; What ended up there; [Link, Book] Logic Book; Update - Garmin Express / Connect; Garmin Forerunner 35 v 230; [Link, Politics, Internet] Government Trolls; [Link, Politics] Why identity politics benefits the right more than the left; SSH Forwarding; A Specification For Repeating Events; A Fight for the Soul of Science; [Science, Book, Link] Lost In Math; OpenSuse Leap 15 Network Fixes; Update; [Book] Galileo's Middle Finger; [Bike] Chinese Carbon Rims; [Bike] Servicing Shimano XT Front Hub HB-M8010; [Bike] Aliexpress Cycling Tops; [Computing] Change to ssh handling of multiple identities?; [Bike] Endura Hummvee Lite II; [Computing] Marble Based Logic; [Link, Politics] Sanity Check For Nuclear Launch; [Link, Science] Entropy and Life

© 2006-2017 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