Passive Acoustic Drone Detector

The ReSpeaker-class 4-mic USB array enumerates on the Pi 5 as a standard USB Audio Class device, no vendor drivers needed, which is exactly why I picked this class of hardware. The chain runs at the documented 16 kHz maximum sample rate of the ReSpeaker Mic Array v2.0 (XMOS XVF-3000); no vendor 48 kHz raw four-channel firmware was found for this board, so 16 kHz is the honest operating point, giving an 8 kHz Nyquist that covers the rotor comb band. Some firmware variants expose 6 channels (4 mics + 2 playback loopback), I capture 4 and ignore the loopback pair.

ENUMERATE AND CAPTURE ALL FOUR CHANNELS

$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 1: ArrayUAC10 [ReSpeaker 4 Mic Array (UAC1.0)], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
$ arecord -D hw:1,0 -f S32_LE -r 16000 -c 4 -d 10 capture_test.wav
Recording WAVE 'capture_test.wav' : Signed 32 bit Little Endian, Rate 16000 Hz, Channels 4

What can go wrong: the card index is not stable across reboots: hw:1,0 can become hw:2,0 if something else grabs card 1. I verify by listing /dev/snd/by-id/ and referencing the device by name in the detector config instead of by number.

Before any DSP, I need to know all four mics are alive, unswapped, and at sane levels. A dead or swapped channel does not break capture, it silently poisons beamforming later, which is much worse. I inspect the test WAV channel by channel in Python with scipy.io.wavfile, tapping each mic while recording so the channel map is proven, not assumed.

CHANNEL HEALTH CHECK (PYTHON)

import numpy as np
from scipy.io import wavfile

sr, data = wavfile.read("capture_test.wav")
print(sr, data.shape)            # expect 16000 (160000, 4)
for ch in range(data.shape[1]):
    x = data[:, ch].astype(np.float64)
    rms = np.sqrt(np.mean(x**2))
    print(f"ch{ch}: rms={rms:12.1f}  peak={np.abs(x).max():12.0f}")

How I verified: each channel shows a clear RMS spike at the moment I tapped its mic, and no channel sits at digital zero. The tap map gets written into the config as the channel-to-geometry assignment, step 08 depends on it.

Beamforming is the reason this array exists, and it only works if all four mics sample from the same clock. On this class of array they do, one shared ADC stream, but I verify it empirically anyway, because a firmware quirk here would invalidate every azimuth the node ever reports. The test: play a tone from a speaker at a known position, record all channels, and cross-correlate each against channel 0.

INTER-CHANNEL DELAY CHECK (PYTHON)

import numpy as np
from scipy.signal import correlate

x = data[:, :4].astype(np.float64)   # tone recorded on all 4 channels
ref = x[:, 0]
for ch in range(1, 4):
    c = correlate(x[:, ch], ref, mode="full")
    lag = np.argmax(np.abs(c)) - (len(ref) - 1)
    print(f"ch{ch} vs ch0: {lag:+d} samples = {lag / 16.0:+.3f} ms")

How I verified: the lags come out small, stable across repeats, and consistent with the array geometry, a circular array tens of millimetres across can only produce delays of a few samples at 16 kHz. A lag that jumps around between recordings would mean resampling or clock drift, and the array would go back.

Bench WAV files prove the hardware; the field node needs a stream. I use sounddevice (PortAudio) with a callback that does the absolute minimum: copy the block into a queue, and a worker thread that consumes blocks, assembles ~1-second analysis windows, and runs the DSP. This split matters: if the classifier ever runs inside the audio callback, a slow frame stalls the stream and ALSA starts dropping audio.

STREAMING CAPTURE (PYTHON, SOUNDDEVICE)

import queue
import sounddevice as sd

q = queue.Queue()

def callback(indata, frames, time, status):
    if status:
        print(status)          # input overflows surface here - never ignore
    q.put(indata.copy())       # hand off; DSP happens in the worker thread

stream = sd.InputStream(device="ReSpeaker", channels=4, samplerate=16000,
                        blocksize=4096, dtype="float32", callback=callback)
stream.start()

What can go wrong: input overflow status lines mean the worker fell behind and audio was lost mid-window. I treat any overflow as a measurement-destroying event: the run is marked invalid rather than silently analysed with gaps.

Detection lives in the frequency domain. Each analysis window gets a Hann-windowed STFT (scipy.signal.stft, 4096-point FFT for ~3.9 Hz bins at 16 kHz) and the magnitude goes to dB. The critical extra is a per-bin noise floor tracked with a slow rolling median: quiet-room thresholds are useless outdoors, where wind and distant traffic raise the low-frequency floor by tens of dB. Every later stage works on signal-above-floor, not absolute level.

STFT + NOISE FLOOR (PYTHON)

from scipy.signal import stft

f, t, Z = stft(window_mono, fs=16000, window="hann",
               nperseg=4096, noverlap=3072)
S = 20 * np.log10(np.abs(Z) + 1e-9)      # magnitude spectrogram, dB
band = (f >= 50) & (f <= 2000)           # rotor band of interest
floor = np.median(S_history[band], axis=1)   # slow per-bin rolling median
Sn = S[band] - floor[:, None]            # signal-above-floor, dB

How I verified: with a recorded drone fly-past, the comb stands out of Sn clearly even in sections where wind has raised the raw floor, while on raw dB the same harmonics are buried. I keep a debug plot of floor vs. signal for every test run.

Rotor detection looks for the comb: a candidate fundamental in the ~100-500 Hz band, then evenly spaced peaks at 2x, 3x, 4x... that persist across consecutive windows. Persistence is the discriminator, a single-frame peak is not enough, and rotors hold their speed for seconds while birdsong chirps come and go in tens of milliseconds. Peaks come from scipy.signal.find_peaks with a height set relative to the noise floor and a minimum spacing so one wide peak cannot count as two harmonics. The ~100-500 Hz candidate band, the 9 dB threshold, and the persistence settings are engineering choices tuned on my own drones, not universal drone signatures.

COMB SCORING (PYTHON)

from scipy.signal import find_peaks

peaks, props = find_peaks(Sn_mean, height=9, distance=4)  # 9 dB above floor

def comb_score(f0_bin, peaks, max_harmonic=8, tol=1):
    """Count how many multiples of f0 have a peak within +/- tol bins."""
    hits = 0
    for k in range(2, max_harmonic + 1):
        if np.any(np.abs(peaks - k * f0_bin) <= tol):
            hits += 1
    return hits

# candidates: peaks whose bin lands in the ~100-500 Hz fundamental band
candidates = [b for b in peaks if 26 <= b <= 128]   # 3.9 Hz/bin at 16 kHz
best = max(candidates, key=lambda b: comb_score(b, peaks))

What can go wrong: a 50/60 Hz mains hum and its harmonics form a beautiful comb too. Mains sits below the drone band and its spacing is fixed, so it is excluded by the candidate range, but I logged it as a deliberate negative case during bench testing rather than trusting the math.

Comb detections become feature vectors: fundamental frequency, number of visible harmonics, comb persistence time, harmonic-to-noise ratio, and occupied bandwidth. Birds fail on persistence and spacing; distant fixed-wing aircraft sit below the drone band and fail on fundamental range; helicopters are a genuinely hard case and get their own label for now. I started with hand-set thresholds to establish a baseline, then trained a small SVM (scikit-learn) on recordings of my own drones plus negative samples, park ambience, traffic, birds, and a lawnmower, the classic false friend.

SVM TRAINING (PYTHON, SCIKIT-LEARN)

from sklearn.svm import SVC
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.model_selection import cross_val_score

clf = make_pipeline(StandardScaler(),
                    SVC(kernel="rbf", class_weight="balanced"))
scores = cross_val_score(clf, X, y, cv=5, scoring="f1_macro")
print("CV f1_macro:", scores.mean(), "+/-", scores.std())
clf.fit(X, y)

What can go wrong: a small, self-recorded dataset overfits easily, and cross-validation on adjacent windows of the same flight leaks. I split by recording session, not by window, so the model is always tested on flights it has never heard. If the SVM's false-alarm rate will not come down, the escape hatch is a compact spectrogram CNN exported to ONNX, the Pi 5 has the headroom for either.

With four mics in a measured geometry, azimuth falls out of the phase differences between channels. I use GCC-PHAT (generalized cross-correlation with phase transform) to estimate time delays between mic pairs; PHAT weighting whitens the spectrum, which keeps one loud harmonic from dominating the vote the way it would in plain cross-correlation. GCC-PHAT still degrades on strongly tonal (narrowband) sources and in strong multipath, which is why the bearing uses the full harmonic comb through SRP-PHAT integration rather than a single peak. SRP-PHAT then scans candidate azimuths, applies the theoretical per-mic delays for each candidate, and picks the direction that maximizes steered energy.

GCC-PHAT DELAY ESTIMATE (PYTHON)

def gcc_phat(sig, ref, fs, max_tau):
    """Time delay of sig relative to ref, PHAT-weighted.

    max_tau is the geometry-derived maximum inter-mic delay (measured mic
    spacing divided by the speed of sound). The correlation search is
    restricted to [-max_tau, +max_tau] BEFORE the peak pick, so an
    out-of-window sidelobe can never win; no assert after the fact."""
    n = sig.size + ref.size
    SIG = np.fft.rfft(sig, n=n)
    REF = np.fft.rfft(ref, n=n)
    R = SIG * np.conj(REF)
    R /= np.abs(R) + 1e-15              # PHAT whitening
    cc = np.fft.irfft(R, n=n)
    shift = n // 2
    cc = np.concatenate((cc[-shift:], cc[:shift]))
    max_lag = int(round(max_tau * fs))
    window = cc[shift - max_lag : shift + max_lag + 1]
    tau = (np.argmax(window) - max_lag) / fs
    return tau

DoA is computed only on windows where the classifier says "drone", which keeps the polar plot clean. The tracker draws azimuth against time on a polar display (matplotlib on the dev laptop; a lightweight web dashboard for the field node), with the comb fundamental alongside, that is the view in the bench photo, locked on the harmonic comb containing the strong ~660 Hz spectral line from one of my quads.

How I verified: a speaker playing a recorded drone track at known azimuths on the bench (0, 45, 90... degrees by protractor) must land on the matching spokes of the polar plot. This test is also what caught a left/right channel swap (see Troubleshooting below).

Detections are published over MQTT as signed JSON events (node ID, timestamp, azimuth, comb fundamental, confidence, signature) using the same Ed25519 signing discipline as the rest of the fleet, a detection the common operating picture cannot attribute to a specific node is noise, not data. The broker feeds the multi-domain common operating picture, where this node's acoustic tracks fuse with the passive radar node's RF tracks, two sensors whose sensing front ends are passive (their MQTT uplinks still transmit over the network). The simulation sibling of that fusion logic is the counter-drone sensor fusion simulator.

SIGNED DETECTION EVENT (PYTHON, PAHO + PYNACL)

import json, time
import paho.mqtt.client as mqtt
from nacl.signing import SigningKey

event = {"node": "acoustic-01", "ts": time.time(),
         "azimuth_deg": az, "fundamental_hz": f0, "confidence": conf}
payload = json.dumps(event, sort_keys=True).encode()
event["sig"] = SigningKey(open("node.key", "rb").read()) \
    .sign(payload).signature.hex()

client = mqtt.Client()
client.connect("broker.homelab", 1883)
client.publish("cop/detections/acoustic-01", json.dumps(event))

What can go wrong: the broker will be down at exactly the wrong moment, that is the DDIL reality the whole program is built around. When publish() fails, events are appended to a local SQLite outbox and replayed in order on reconnect, following the same store-and-forward pattern as the other field nodes. Clock skew also matters: the Pi has no RTC, so timestamps are only trustworthy after NTP sync, which the service waits for at boot.

A bench script is not a sensor. The detector runs as a systemd service so it survives reboots and crashes, mounts read-only where it can (high-endurance storage still dislikes power cuts), and waits for time sync before trusting its own timestamps. The field kit is the IP65 box with cable glands and a USB-C PD power bank; the array mounts through the lid on standoffs with a foam windscreen over the mics.

SYSTEMD UNIT (/etc/systemd/system/acoustic-detector.service)

[Unit]
Description=Passive acoustic drone detector
After=sound.target network-online.target time-sync.target
Wants=network-online.target

[Service]
ExecStart=/usr/bin/python3 /opt/acoustic/detector.py
WorkingDirectory=/opt/acoustic
Restart=always
RestartSec=5
User=acoustic

[Install]
WantedBy=multi-user.target

How I verified: systemctl enable --now, then deliberate abuse, kill -9 the process (service restarts in 5 s), pull the network (events pile up in the outbox), yank power mid-run (node comes back up and resumes without manual SSH). A field node that needs babysitting is not finished.