I THINK ∴ I'M DANGEROUS

Seismometer Positioning System

Or maybe Seismic Local Positioning System? Or Seismic Triangulating Positioning System?

Using a system of seismometers (or perhaps accelerometers pressed into service as seismometers) that are networked together, it should be possible, with accurate clocks, to analyze input over, say, a 1-second rolling time window for frequency and amplitude to determine the source (epicenter) of the vibration. The time-window and frequency matching helps ensure the observed vibrations are from the same source. The venerable Fourier Transform will be used to determine frequencies and amplitudes.

Amplitude and timing are used to determine distance. Timing is the primary factor for determining distance–assume speed of sound traveling through soft wood (see table below). Amplitude can be used as a sanity check (e.g. the sensor with the greatest amplitude should be closest).

Ultimately, the system will need to be calibrated. The goal is to track foot steps, which should not vary in frequency too much and also follow common pathways to sensors–once the sensors are calibrated.

Speed of Sound in Various Materials

Medium Velocity
(m/s) (ft/s)
Aluminum,
shear - longitudinal wave
3100 - 6400 10200 - 21060
Beryllium 12890 42530
Brass 3475 11400
Brick 4176 13700
Concrete 3200 - 3600 10500 - 11800
Copper 4600 15180
Cork 366 - 518 1200 - 1700
Diamond 12000 39400
Glass 3962 13000
Glass, Pyrex 5640 18500
Gold 3240 10630
Granite 5950 19635
Hardwood 3962 13000
Iron 5130 16830
Lead 1960 - 2160 6430 - 7087
Lucite 2680 8790
Rubber, butyl 1830 6039
Rubber 40 - 150 130 - 492
Silver 3650 12045
Steel 6100 20000
Steel, stainless 5790 19107
Titanium 6070 20031
Wood (hard) 3960 13000
Wood 3300 - 3600 10820 - 11810

Back of Envelope Math

My house is an L-shape, about 50ft by 50ft with a quadrant missing. Assume speed of sound in soft wood to be 3400 m/s (see above table).

If 3 sensors were placed at each corner of the house, the farthest distance a sensor ever could be would be about 70ft or 21 meters. It would take about 6ms for sound to reach from one sensor to the next farthest.

Thus, sub milisecond time resolution is required. The multiplicative inverse gives a rough idea of necessary sampling frequency (regards to Nyquist). 167hz. Given the ready availability of of 1000+ Mhz processors, capable of sampling at or around clock speed (E.G. a Raspberry Pi), fast enough sampling and processing to get satisfactory accuracy should not be a problem.

Desirable Output

Once calculations have been made, the data should be presented via some graphical interface (web based, or a TK canvas) that overlays the calculated vibration epicenters on a map of the house.

The net effect should be a graphical, real-time or near-real-time tracking of foot steps.

Communication Protocol

The higher level bits will be written in Tcl, thus Tcl structures (strings, lists) will be used within the protocol. The combination of seismometer and MCU/Control board will be referred to as a node. There will be 3 (or more) nodes. Each node upon detection of a vibrations above a certain amplitude within a certain frequency range (to be empirically determined) will be transmitted to a central server via TCP. The data transmitted will be a line-delineated (and line-buffered) tcl list consisting of, in order, a time-stamp in microseconds, a list of 2-element lists each consisting of a frequency and corresponding amplitude.

E.G. If node1 sensed at 1455909894376591 microseconds epoch time a 60hz signal at 0.2 amplitude and a 45hz signal at 0.6 amplitude, it would send

  1455909894376591 {60 0.2} {45 0.6}\n

Plan B:

The above method may be too slow. the devices may need to stream raw vibration data directly to the central server via UDP. IP communication induces its own lag, but the devices could perhaps be calibrated to take this into account.

Plan C:

Plan B may also be too slow. Perhaps a hybrid solution? A small C-program continually takes measurements and continually pushes microsecond timestamped data samples to a central server that handles all processing.

E.G. Node 1 would, as fast as possible push out binary data in the form of

  <long unsigned int ts><double sample>

Where long unsigned int ts is the epoch timestamp in microseconds and double sample is the raw data coming off the ADC.

It would then be up to the server to buffer the data from each node into a signal and perform a Fourier Transform to determine frequency and amplitude.