Key Takeaways
- VolAnti detects drones by sound, not radio, using four ICS-43434 MEMS microphones in a plus shape about 79 mm corner to corner.
- An ESP32-S3 runs a 2048-point FFT at 16 kHz, producing a frame every 32 ms with roughly 7.8 Hz frequency resolution.
- It looks for a “harmonic comb” — evenly spaced, stable spectral peaks — not for loudness, which separates it from a sound trigger.
- Four independent detection tiers cover arrival, sustained hover, loaded flight and permanently noisy sites; the fastest reports in about 0.23 s.
- The project is open source under Agam Rossen on GitHub, and the author states it is not a life-safety product and can miss aircraft.
VolAnti is an open-source acoustic drone detector that listens for rotor noise instead of radio control links. As of 2026 it pairs four digital MEMS microphones with an ESP32-S3, an e-paper screen and a LoRa radio inside a roughly 91 mm enclosure, then alerts through a buzzer, LED, vibration motor, e-paper and LoRa messages.
Why Acoustic Drone Detection Instead of Radio
Most common drone detection schemes look for radio signals. But if an aircraft uses fiber-optic transmission there is no radio control link to receive, and simply “listening for radio” loses the trail. VolAnti takes a different route: it does not monitor control signals at all. It captures rotor sound with microphones and then asks whether the spectrum contains a stable, evenly spaced harmonic structure.
VolAnti is an acoustic detection project open-sourced by Agam Rossen on GitHub. It packs four digital MEMS microphones, an ESP32-S3, an e-paper display and a LoRa wireless module into an enclosure of about 91 mm. When it detects qualifying sound it raises an alert through a buzzer, a red LED, a vibration motor, the e-paper screen and a LoRa message.
The project draws its boundary up front: the repository defines it as “detection and alerting” and explicitly excludes jamming, spoofing, interception, targeting or any other countermeasure function. The author also warns that it is not a life-safety product, that it can miss detections, and that it must not be the only layer of security.
What Problem It Solves: The Harmonic Comb
Radio detection depends on the target emitting a signal; VolAnti focuses on the acoustic signature produced as rotors turn. Propeller blades cut the air periodically, creating a “harmonic comb” made of a fundamental frequency and its multiples: the spectrum shows peaks at similar intervals, with relatively quiet gaps between them. The project’s judgement is not about whether the sound is loud enough, but whether that set of frequency peaks forms a persistent, stable arrangement.
That is also what separates it from an ordinary sound trigger. Traffic, wind and rain produce broadband noise; the algorithm instead hunts for evenly spaced spectral peaks and watches whether the corresponding frequency stays stable over time. The author describes the detector as a local acoustic alerting device — not radar, and not a replacement for radar.
The project documentation uses a three-blade propeller as an example: the frequency at which blades pass through the air is set jointly by blade count and rotation speed, forming the fundamental, and because real rotor noise is not an ideal single sine wave, energy also appears at integer multiples of that fundamental. For a three-blade prop the detector tracks two harmonic combs at the same time, at 2x and 3x spacing, so that if one is masked by background sound the other can still support a decision.
For the airframe the project targets, the author estimates a hover frequency band of 375–475 Hz; the first rotor fundamentals actually locked onto measured 423 Hz and 471 Hz, and under load in flight the frequency rises to 480–570 Hz. These ranges come from the specific airframe and tests the project targeted and should not be read as parameters shared by all drones.
How VolAnti Alerts You
VolAnti samples sound continuously while running. Every 32 ms the system processes one frame of signal from the four microphones, merges the multichannel data, analyses the spectrum, and then lets four mutually independent detection paths decide whether rotor characteristics are present. If any single path meets its conditions, the device raises the alert.
| Output | Function |
|---|---|
| Buzzer | Rhythmic audible alert |
| LED | Fast red flashing through a light pipe in the enclosure; slow green blink on standby |
| Vibration motor | Haptic notification for whoever is holding the unit |
| E-paper screen | Shows the alert and the time; the image persists after power is removed |
| LoRa module | Sends an 18-byte alert packet to other devices in radio range |
The device also has a mute button: pressing it silences the alert outputs for 10 seconds while detection keeps running underneath. LoRa here carries the alert only; it does no relaying or mesh routing, and each unit still completes its own detection decision independently.
From Sound to Verdict: The Signal Processing
The hardware uses four ICS-43434 digital MEMS microphones arranged in a plus shape, about 79 mm corner to corner. All four channels share a clock and are merged into a single analysis signal. The project documentation explains that across the frequency range of interest this array is roughly one tenth of an acoustic wavelength, so sound arriving from different directions adds largely in phase while the microphones’ own uncorrelated noise does not add the same way. The project measured about 6 dB of signal-to-noise improvement, and the array is close to omnidirectional; the author tried beamforming but found no useful directivity at this size and frequency band, so the array is positioned as a sensitivity design rather than a direction-finding device.
The ESP32-S3 then runs spectral analysis on the sampled data: a 16 kHz sample rate, a 2048-point FFT, updated every 512 samples — roughly one frame every 32 ms, with about 7.8 Hz of frequency resolution. The algorithm continuously estimates the background sound at each frequency bin and subtracts that “noise floor” from the current spectrum; quiet changes take about 6 seconds to learn, while sudden broadband noise takes about 0.8 seconds. The purpose is to make newly appearing steady tones stand out while preventing vehicles, gusts and similar broadband noise from lingering in the background model.
The project also documents the limitation of this adaptive background model: if a rotor sound arrives and then hovers continuously, the fast background model can gradually learn it after roughly 6 seconds, so the first, fast detection path no longer stands out. That is why the project does not rely on a single algorithm but instead sets up multiple detection paths with different timescales and different criteria.
The repository splits detection into four paths, aiming to cover different patterns of sound change. They process the same microphone data but use different background baselines, frequency ranges and required frame counts; whichever confirms first triggers the alert. The parameters below come from the repository’s how-it-works documentation:
| Detection tier | Method (project parameters) | Target case / latency |
|---|---|---|
| Tier 1 — fast comb | Searches 70–2000 Hz for candidate frequencies; 6 consecutive frames, threshold 1.70 | Arrival, approach or change; about 0.23 s |
| Tier 2 — slow comb | Uses a 30-second background baseline; 44 of 63 frames, threshold 1.40 | Sustained hover after arrival; from about 1.4 s |
| Tier 3 — envelope modulation | Analyses 100–650 Hz modulation of the envelope above 3 kHz; 16 of 23 frames | Close range, loaded, high thrust; about 1–3 s |
| Tier 4 — no-noise-floor comb | 64-frame Welch median spectrum; 5 of 8 updates, threshold 30.5 | Long hover in permanently noisy sites; about 5–15 s |
The fast path mainly handles sound that has just appeared or is changing; the slow path uses a longer background timescale so it can observe a source that arrives and then transitions into a hover; the third path does not look for clean low-frequency comb peaks but instead watches whether the broadband envelope above 3 kHz shows periodic modulation; and the fourth path does not depend on a background noise-floor model, targeting long hovers in sites that are never quiet — at the cost of the slowest response.
The project’s comb score is not a simple loudness comparison. It compares the energy on candidate harmonic peaks against the energy in the gaps between them, normalised by the number of harmonics in the band:
score = (energy on the comb teeth − energy in the gaps) / √K, where K is the number of harmonic peaks in the band.
Candidate fundamentals are searched across 70–2000 Hz in 1 Hz steps. A single high-scoring frame is not enough to trigger: the fast path requires the same candidate frequency to win 6 frames in a row with no more than 2% variation. The author uses “the frequency structure stays persistently stable” as the anti-interference condition rather than simply raising the threshold, because a threshold set too high also misses weaker genuine rotor sounds.
Once a detection is confirmed the alert output holds for 5 seconds while the screen shows a countdown; during output the slow accumulators pause so that the device’s own buzzer cannot re-enter the detection chain. The project also pins the fast detection path with golden test vectors: the same audio must produce identical scores in the desktop reference implementation and on the development board, and results on the production PCB match the reference implementation bit for bit.
Hardware and Power
| Module | Configuration |
|---|---|
| MCU | ESP32-S3 |
| Microphones | 4 x ICS-43434 digital MEMS microphones |
| Display | Waveshare 1.54-inch black-and-white e-paper, 200 x 200 |
| Wireless | Ra-01H LoRa module with a spring antenna |
| Battery | 1S 2500 mAh lithium polymer |
| Power management | BQ24074 charging and power path; TPS63020 buck-boost holding 3.3 V |
| Enclosure | Roughly 91 mm box; the full version uses four printed parts |
In the configuration the author recorded, runtime on a single cell is about 18–22 hours. The battery stays even in mains-powered versions: while developing and debugging, the project found that the buzzer, vibration motor and wireless module firing at the same time could cause the supply voltage to sag on USB power, and the battery absorbs that transient load.
The LoRa alert packet is 18 bytes long and carries device identity, detection tier, frequency, score and a sequence number. Note that the operating frequency must be set according to local band regulations in your region; this article makes no additional judgement about wireless regulation in any specific country.
Two Build Routes
Route 1: Breadboard Prototype
The breadboard version needs no custom PCB and no printed enclosure, and it is how the project validated the algorithm early on. The core is an ESP32-S3-DevKitC-1 N16R8 development board plus four I2S microphone modules; the microphones the project lists include the ICS-43434 or the INMP441. Of the e-paper, LED, buzzer, vibration motor and wireless module, some are optional and some can be left unconnected at first.
Route 2: Full Unit
The full version uses a custom four-layer PCB, four printed structural parts, the battery, the e-paper screen and the LoRa module. The author recommends letting the PCB house do the assembly; once the board arrives only a few through-hole parts need hand soldering: the buzzer, the display header, the spring antenna and the optional vibration motor. The enclosure also needs microphone gaskets, a light pipe, speaker mesh and desiccant.
Before final assembly of the full unit, run the power-up checks with the case still open: after connecting USB-C and the battery the device enters LISTENING in about two seconds; send “I” over serial to confirm the state of all four microphones, then tap each microphone opening in turn to check that the corresponding channel responds, and verify the mute button and the display. The author specifically warns that once the case is closed the internal joints are much harder to inspect.
Once verified, assemble in order: the mute button cap, the microphone foam gaskets, the battery cushion and battery, the PCB, the e-paper screen, the light pipe, the speaker mesh and the desiccant, then fix the enclosure. Also confirm the battery plug polarity first, and use neutral-cure silicone around the microphones rather than an acetic-cure material.
How to Read the Project’s Test Records
The README records a test on 6 September 2026: using a hover test rig, in an environment with vehicles passing and people talking nearby, the author recorded Tier 4 triggering at 104.2 m. The author notes that the detector was tuned further after that test to cut false alarms and speed up response. That figure is therefore a single project test result under specific conditions, not a guaranteed value in all environments.
It is important to keep “104.2 m” and “0.23 s” apart: 0.23 s is the latency of the fast detection path, whereas the 104.2 m record came from the fourth, no-noise-floor path, for which the repository quotes a latency of 5–15 seconds. The two numbers describe different detection paths.
The source also records earlier tests. On 13 August 2026, a single 2807-class motor with a 7-inch three-blade propeller was detected at 25–30 m indoors in a quiet environment; that was the far wall of the room at the time, not the range at which detection failed. On 21 August 2026, in open ground with a lightly varying wind and a loaded propeller, the author detected the sound at about 14 m via the fast and envelope paths, with no false alarms recorded that day. The author also notes that a steady close-range hover was sometimes detected intermittently, while fast throttle changes were mostly missed — the slow and no-noise-floor paths were added afterwards.
The record for the first production PCB focuses on real-time behaviour and hardware consistency: with all four detection paths running together, the slowest of 1,938 test frames took 29.4 ms, inside the 32 ms per-frame budget, and after per-channel calibration the four microphones matched within ±1 dB. The project’s test notes also identify wind as a major factor in range; the README’s estimate is roughly 100–200 m in quiet, light-breeze conditions and 15–50 m in windy or noisier sites, with performance affected above 8 m/s of wind. These are the author’s estimates and test records, not a performance guarantee.
How Multiple VolAnti Units Cooperate
A single VolAnti can detect and alert on its own. The project also supports exchanging alerts between units over LoRa: every unit runs the full detector and decides independently from its own local evidence, and LoRa simply forwards the alert to other devices within range. There is no relaying, no mesh routing and no multi-device voting, so an alert is never delayed waiting for confirmation from another unit.
The multi-unit deployment concept in the project documentation is to let units near the perimeter do the listening while units indoors or near people receive the alerts; every node can still raise its own verdict independently. The repository recommends keeping units face-up and parallel to the ground, in a shaded spot away from continuous noise sources, and warns against publicly disclosing deployment locations. LoRa operating frequency must be set to the local band where the device is used; the project does not provide a single frequency for all regions.
Limitations and Safety Boundaries
The VolAnti README states plainly that it is not a life-safety product and that it may miss aircraft. The author also notes that the project is aimed mainly at outdoor use; indoors, certain music, propeller recordings and larger fan-like sounds have caused false alarms. In the author’s view there is still substantial room to improve the software, since current tuning used synthetic audio plus a small number of real recordings, so real-world behaviour across different locations, weather and background sound still needs further evaluation.
The repository also notes that LED behaviour on some flashed devices is unstable — for example staying lit, or flashing red at boot; the author believes this may be a software issue and the investigation is not finished. For anyone planning to reproduce the project these notes matter more than quoting the “maximum detection range” on its own: there is a complete open-source implementation and a set of test records, but it remains an engineering prototype under continuous improvement.
The safety scope is equally explicit: the project performs acoustic detection and alerting only, and does not design or support jamming, spoofing, interception, targeting or similar countermeasures. It welcomes build and test reports, but the README specifically warns against disclosing device deployment locations.
Final Thoughts
VolAnti demonstrates a sensing approach distinct from radio scanning: collect ambient sound with four MEMS microphone channels, then use spectral structure and temporal stability as the basis for a decision. It pulls a sensor array, digital signal processing, embedded control, e-paper display, LoRa communication, power management and 3D-printed structure into one open hardware project.
For electronics and embedded developers, what is worth studying here is not a particular test distance but how it derives detection logic from acoustic features, how it maps detection results onto several alert outputs, and how it validates the design step by step along both the breadboard and the full-PCB routes. When reproducing the project or quoting its data, keep the original test conditions, limitations and safety boundaries alongside the numbers.
Project source: github.com/agamrossen/VolAnti
Have questions about this article? Feel free to contact us at [email protected] — we’re happy to help!
Frequently Asked Questions
How does VolAnti detect a drone without radio?
It listens. Four MEMS microphones capture rotor sound, and the ESP32-S3 looks for a harmonic comb — evenly spaced spectral peaks whose frequency stays stable. Loudness alone never triggers it, which is what separates the detector from a simple sound-activated alarm.
What is a harmonic comb in drone acoustics?
Propeller blades cut the air periodically, producing a fundamental frequency plus integer multiples of it. On a spectrum analyser these appear as peaks at even intervals with quieter gaps between them. VolAnti scores the energy on those peaks against the energy in the gaps.
How fast does VolAnti report a detection?
The fast comb tier reports in about 0.23 seconds, needing the same candidate frequency to win six consecutive 32 ms frames. The slow, envelope and no-noise-floor tiers trade speed for robustness, at roughly 1.4 s, 1–3 s and 5–15 s respectively.
What detection range does VolAnti achieve?
The README estimates about 100–200 m in quiet, light-breeze conditions and 15–50 m in windy or noisy sites, degrading above 8 m/s of wind. The project’s own logged tests recorded 104.2 m on the slowest tier and 25–30 m indoors on an early single-motor rig.
Is VolAnti a counter-drone system?
No. The repository defines it strictly as detection and alerting and explicitly excludes jamming, spoofing, interception and targeting. The author also states it is not a life-safety product, that it can miss aircraft, and that it should never be the only layer of protection.
About Aomway
Aomway is a technology company specializing in drone and FPV equipment, publishing in-depth analyses of motor control, embedded hardware, and open-source robotics projects. With over 15 years of industry experience, Aomway covers the full spectrum from flight controllers and FPV goggles to thermal imaging cameras and long-range datalinks for the global drone community.
