Tremor: detecting small earthquakes

Spotting easy-to-miss earthquakes with multi-station signal processing—no large models required.

Comment

Inspiration

Small earthquakes can be easy to miss at an individual seismic station. We wanted to explore whether public sensor data and lightweight signal processing could recover more of these events without large models or expensive hardware.

Tremor is our response to AdaHack’s CompSoc Challenge 7: an earthquake detector with evidence you can inspect, rather than just an unexplained alert.

What it does

Tremor analyses public BGS/EIDA seismic waveforms and combines triggers from multiple stations into candidate events.

The interactive demo lets you:

  • Browse historical earthquake cases grouped by which methods detected them.
  • Compare three detection methods on the same signal window.
  • Inspect waveforms, STA/LTA scores, station locations and trigger timing.
  • Replay recorded detections or fetch recent BGS waveform data.

An accompanying notebook explains the complete workflow with real signals, equations and evaluation results.

How we built it

We use Python and ObsPy to read 100 Hz vertical-component miniSEED recordings. We process continuous segments separately, remove trends, taper the edges and apply a 2–15 Hz band-pass filter. We preserve gaps rather than inventing missing samples.

All three methods use classic STA/LTA, which compares short-term signal energy with the longer-term background:

$$ R(t)=\frac{\mathrm{STA}(t)}{\mathrm{LTA}(t)} $$

Our windows are 1 second and 30 seconds. We compare:

  1. Single-station STA/LTA: an individual detector at EAB, selected using training dates.
  2. Standard multi-station trigger: ObsPy’s existing coincidence trigger, combining overlapping station triggers.
  3. Travel-time-constrained association: our method for grouping triggers using station distances and a separate strength gate.

Our association first collects low-threshold onsets and merges short gaps. Starting with the strongest remaining trigger, it builds groups with at most one trigger per station. Every station pair must satisfy a distance-dependent timing bound:

$$ |t_i-t_j|\leq\min\left(65\ \mathrm{s},\frac{d_{ij}}{3\ \mathrm{km/s}}+8\ \mathrm{s}\right) $$

We then retain members with a peak STA/LTA ratio of at least 12 and require at least two members. This preserves earlier onsets while requiring strong support.

The frontend uses JavaScript and Leaflet to connect detections with their signals and station locations.

Results

We select thresholds on separate validation dates and compare detections against the official earthquake catalogue using predicted P/S arrival times and one-to-one matching.

In a 187-hour retrospective audit containing 26 catalogue events:

Method Catalogue events detected Continuous-week candidates/day
Single-station STA/LTA 17/26 28.9
Standard multi-station trigger 21/26 32.9
Travel-time-constrained association 21/26 22.4

Our association recovered four events missed by the single-station baseline, without losing any of its matched events.

Compared with standard multi-station triggering, it achieved the same overall catalogue recall with approximately 32% fewer candidates to review. The two network methods detected different event sets: our method gained three events and lost three.

These results are retrospective because missed-event analysis informed station expansion. Unmatched candidates remain candidates for review, not confirmed new earthquakes or verified false alarms.

Challenges and lessons

Station coverage mattered as much as detector complexity. Missing data, waveform boundaries and travel-time differences could all make a real event appear to be a missed detection.

We also explored continuous scoring, weak-label logistic ranking, clustering and positive-only geometric models. They did not provide a consistent advantage over the selected threshold-based approach. Clustering helped organise candidates, but could not establish earthquake/noise labels.

A key lesson was to distinguish detecting more catalogue events from producing more alerts. We therefore report recall alongside the candidate review workload.

Low-compute design

Tremor uses CPU-based signal processing without large models.

Across 21 local scans on an ARM64 Mac, processing took a median of 0.35 seconds per hour of waveform data, with approximately 477 MB peak process memory. This includes local file reading, preprocessing, all three detectors and catalogue matching, excluding network transfer, startup and plotting.

What’s next

We would like to review unmatched candidates, evaluate on fresh dates and measure performance on smaller hardware. For now, Tremor provides a working local demo and a reproducible explanation of how lightweight multi-station detection can recover small, easy-to-miss events.

Built With

Share this project:

Updates