Nearly all drone detection listens for the control link between the pilot and the aircraft. A fibre-optic FPV drone doesn't have one. The video comes down a glass thread and the control goes up it, and the radio spectrum stays completely silent. You can point the best RF detector in the world at one and get nothing back.What it can't hide is four propellers. This is a 91 mm box that listens for them.

What a propeller sounds like

Nearly all drone detection listens for the control link between the pilot and the aircraft. A fibre-optic FPV drone doesn't have one. The video comes down a glass thread and the control goes up it, and the radio spectrum stays completely silent. You can point the best RF detector in the world at one and get nothing back.

What it can't hide is four propellers. This is a 91 mm box that listens for them.

Four microphones, and why I didn't beamform

There are four ICS-43434 MEMS microphones, one near each corner of the board, all running off a single I2S clock so their samples line up. Then they're just added together.

I expected to beamform them and steer a lobe around the sky. I ran the numbers first and it was a waste of time. The array is 79 mm corner to corner, and at 450 Hz a wavelength of sound is about 760 mm. The array is a tenth of a wavelength across, which means to a 450 Hz sound it is effectively a single point. There is nothing to steer.

Summing them still buys something: about 6 dB of signal-to-noise for free, because the drone arrives at all four mics correlated and the electrical noise doesn't. And staying omnidirectional turns out to be what you actually want, because the thing can come from any direction and you don't get to choose.

The board is 84 x 84 mm, four layers, ENIG. ESP32-S3-WROOM-1-N16R8, an Ra-01H LoRa module, a BQ24074 power-path charger, a TPS63020 buck-boost for a single 3V3 rail, a WS2812B, a buzzer, motor pads, an e-paper header, USB-C and a JST-PH battery connector. JLCPCB assembles everything except four through-hole parts.

Four detectors, because a hovering drone erases itself

This is the part that took the longest and it's the part I'd tell someone else about first.

Every 32 milliseconds the ESP32-S3 takes a 2048-point FFT of the summed audio at 16 kHz. It subtracts a per-bin adaptive noise floor, which learns quiet steady things over about six seconds and loud sudden ones in under one, so a lorry going past can't park itself in the noise model. Then it scores a comb for every candidate blade rate from 70 to 2000 Hz in 1 Hz steps: energy on the teeth, minus energy in the gaps, normalised. The winning rate has to win six frames in a row, within 2 %, before anything happens.

That works beautifully for a drone flying in. It fails completely for a drone that arrives and stops.

Because a hovering drone is a steady sound. And a steady sound is exactly what an adaptive noise floor is designed to learn. After about one time constant, roughly six seconds, the drone has been absorbed into the detector's own idea of silence and it vanishes off the screen while still hovering there.

I spent a while trying to make the floor smarter. The answer turned out to be dumber: run more detectors. There are four now, on the same spectrum, with different memories. A fast one that catches arrivals in 0.23 seconds. A slow one with a 30 second floor that catches an arrival that then settles. A near-field one for something close and loud. And one with no floor at all, whitened across frequency on a two-second Welch spectrum, which takes 5 to 15 seconds to make up its mind and is the most sensitive of the lot.

All four run on every frame. The worst frame measured 29.4 ms against the 32 ms budget across 1938 frames, with no overruns.

The box

Four printed parts in black PETG, no supports needed. The lid has 45 degree cones behind each microphone aperture so sound reaches the bottom-ported mics through the board. There's a light pipe over the RGB LED, a grille cloth behind...