Geolocation by aeroplane sound Doppler shift

GM4AJK

Senior Member.
For those MBers that like the geolocation exercises here's a rather fancy technique I just saw on a YouTube video:

External Quote:
This video examines the amount of location information carried by inaudible background sounds, using the Doppler effect to locate a reference recording within ~100m, and only needing (in some cases) less 1-min of audio. This video raises awareness of these capabilities and closes by discussing preventative measures one could take.

Methodology: Aircraft position, altitude, and velocity data were sourced from ADS-B data and filtered in Python using ICAO type-code classification for propeller vs jet types. For each candidate location on a 200m grid, the closest point of approach (CPA) and sound propagation delay were computed from 3D slant distance, using a digital elevation model (DEM).

Doppler curve spectrogram measurements constrained each event's velocity and CPA slant distance. Candidates were then filtered by the 920-second offset between two flyovers, plus a silence constraint. The exact Doppler curve each candidate would hear was modelled, using emission-time radial velocity from interpolated ADS-B data.

Modelled doppler curves were scored against the observed spectrogram using a locked two-event scoring method. This corrected for measurement error on CPA time & fundamental frequency, while preserving the purely physics-derived temporal offset between the two events.

The pipeline was repeated again for a single 1-min clip of known time, US-wide search, and again, successfully scored the true location 1st.

Lastly, preventative measures were assessed, including rationale behind why common signal processing fixes fail (high-pass filtering, drowning out, and phone call compression/noise reduction).

This video is an educational demonstration of acoustics, signal processing, and data analysis using publicly available data. No code or tools are being released.

That last comment, "No code or tools are being released"... sounds very much like a challenge ;)


 
It's a cool "I wish I had thought of that" idea. And I think it would be pretty easy for an AI agent to implement once the idea is described. I'll let it have a bash at putting it in Sitrec.
That would be interesting and useful.

Additionally, remember all those "New Jersey Drone" videos? Well, using this technique would probably allow for much better evidence, when matched with the flight, that it's actually a plane, as it's said to be.
 
It's already done the basic spectral analysis (sitrec already had one), and identified flyover curves.

1793664700679.png
 
Attached is the AI's discussion of how the Sitrec implementation of colsto's idea works.

Codex GPT-6-Astra Ultra, used about 20% of a week's tokens, so it nominally cost $10.

Its time breakdown

Session time breakdown

Recorded work spans approximately 8 hours 2 minutes, from 15:40 to 23:42 PST on November 2, through completion of the illustrated guide. This includes pauses and overlapping work; it is not continuous computation.

Approximate elapsed time by phase
  • 15:40–16:45 — 1h 05m: Studying the source material, obtaining data, and developing the initial addon and spectrogram.
  • 16:45–18:12 — 1h 27m: Archive searches, audio measurements, and initial location attempts.
  • 18:12–22:34 — 4h 22m: Multiple-agent review, accuracy investigation, browser delays, and testing.
  • 22:34–23:22 — 48m: Correcting the brightness scoring, optimizing performance, completing the successful countrywide search, and producing output images and the infographic.
  • 23:22–23:42 — 20m: Committing the implementation and private records, creating the illustrated guide, and interaction gaps.

Measured long-running jobs
  • Original coarse search: 15m 15s
  • Corrected coarse search and terrain refinement: 18m 24s
  • Browser single-flyover search: 9m 36s
  • Countrywide run before a cache-related crash: about 5m
  • Final successful countrywide search: 10m 07s
  • Full test suite: 31m 01s

These main jobs total approximately 89 minutes. Additional recorded preparation, validation, and a stopped baseline run account for roughly another 11 minutes. This is an incomplete inventory, and some jobs overlapped other work.

Main avoidable detours
  • Initially optimizing trace error instead of spectrogram brightness.
  • A manually measured trace following interference.
  • Measurement bounds that were too restrictive.
  • A cache-key collision that forced a search restart.

Builds generally took only 3–4 seconds. I cannot reliably divide the remaining elapsed time into coding, reasoning, user interaction, and idle time.
 

Attachments

Back
Top