---
service: "Publicasta"
schema_version: "1.0"
article_id: 568
title: "VolAnti Brings Open-Source Acoustic Detection to Fibre-Optic FPV Drones"
language: "en"
default_language: "en"
canonical_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv?lang=en"
json_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.json?lang=en"
api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/volanti_open_source_acoustic_detector_fiber_optic_fpv?lang=en"
channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar"
channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles"
search_url: "https://publicasta.com/api/public/v1/search"
documentation_url: "https://publicasta.com/api-docs#reading-publicasta"
openapi_url: "https://publicasta.com/api-docs/openapi.json"
published_at: "2026-09-09T13:55:01+00:00"
updated_at: "2026-09-09T13:55:01+00:00"
translations:
  - language: "ar"
    html_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv?lang=ar"
    markdown_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.md?lang=ar"
    json_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.json?lang=ar"
  - language: "de"
    html_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv?lang=de"
    markdown_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.md?lang=de"
    json_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.json?lang=de"
  - language: "en"
    html_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv?lang=en"
    markdown_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.md?lang=en"
    json_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.json?lang=en"
  - language: "es"
    html_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv?lang=es"
    markdown_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.md?lang=es"
    json_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.json?lang=es"
  - language: "fr"
    html_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv?lang=fr"
    markdown_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.md?lang=fr"
    json_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.json?lang=fr"
  - language: "pl"
    html_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv?lang=pl"
    markdown_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.md?lang=pl"
    json_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.json?lang=pl"
  - language: "ru"
    html_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv?lang=ru"
    markdown_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.md?lang=ru"
    json_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.json?lang=ru"
  - language: "zh"
    html_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv?lang=zh"
    markdown_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.md?lang=zh"
    json_url: "https://publicasta.com/open_source_radar/volanti_open_source_acoustic_detector_fiber_optic_fpv.json?lang=zh"
---

# VolAnti Brings Open-Source Acoustic Detection to Fibre-Optic FPV Drones

> VolAnti is a compact ESP32-S3 detector that listens for rotor harmonics instead of radio emissions. Its early test is promising, but the project is best understood as a transparent warning device—not a finished counter-drone system.

VolAnti appeared on Hacker News on September 9, 2026, with a proposition that is easy to summarize and harder to dismiss: if a drone has stopped talking over radio, listen to its propellers instead. The open hardware project uses four MEMS microphones, an ESP32-S3, an e-paper display and a LoRa radio to detect the structured sound of a multirotor and distribute an alert.

 ![A compact open-source acoustic drone detector prototype on a workbench with a distant quadcopter blurred in the background.](https://publicasta.com/storage/projects/10/pages/568/2026/09/c00c135c-ad9f-407b-bb46-e0951d4fe0a4.webp)

 That is a more focused idea than the phrase “acoustic drone detector” might suggest. VolAnti is not trying to identify every aircraft, produce a radar-like track or replace a layered counter-UAS installation. It is a local early-warning device for a narrow but important gap in radio-centric systems. The repository describes it as detection and alerting only, explicitly excluding jamming, interception, targeting and other countermeasures.

 The project is worth watching because it puts the entire chain in public: hardware files, firmware, enclosure models, test audio, documentation and a browser simulator. It is also worth treating cautiously. One successful test at 104.2 metres is evidence that the design can work in a particular setting, not evidence of reliable coverage in a different climate, landscape or threat environment.

 ## The problem VolAnti is actually solving

 Many consumer and professional drone detectors begin by looking for an electromagnetic signature. A radio-controlled aircraft usually has a control link, a video transmitter or a remote-identification broadcast. A receiver can scan for those signals, classify them and sometimes estimate the aircraft or operator’s location. That approach has a clear boundary: it needs something in the air to receive.

 A fibre-optic FPV aircraft changes the boundary. Its operator sends control information and receives video through a physical fibre rather than a conventional radio link. The aircraft can therefore be radio-silent during the part of the flight where a radio scanner would normally look for evidence. That does not make the aircraft acoustically silent. Motors, propellers, vibration and the movement of air remain physical signals.

 VolAnti’s central insight is to look for the regular structure inside that sound rather than for an arbitrary loudness threshold. A rotating propeller produces a blade-passage frequency. A three-blade propeller turning at a given rate produces a fundamental associated with three blade passages per revolution, with energy at multiples of that frequency as well. In a spectrum, those peaks form a comb: repeated teeth separated by a relatively consistent interval.

 The exact acoustic signature depends on the propeller, motor, load, speed, frame, distance, wind and surrounding surfaces. The important point is not that every drone produces one identical sound. It is that rotor noise contains a periodic feature that broadband environmental noise does not usually preserve in the same way. VolAnti tries to score that regularity.

 This is why the project is not simply a microphone connected to a volume meter. A volume meter would be defeated by traffic, machinery, voices or a door slam. A detector that asks whether the spectrum has evenly spaced rotor-like components has a more useful question to ask, although it still has to contend with many sounds that can imitate parts of the pattern.

 ## What is in the box

 The full design fits a roughly 91-millimetre enclosure. Its processing core is an ESP32-S3, a practical choice for a low-cost embedded signal-processing project: it has enough computing capacity for the stated workload, is widely available and has a mature development ecosystem. The sensor array uses four ICS-43434 MEMS microphones arranged in a plus-shaped layout.

 The microphones are not being used as a full acoustic-camera system. The repository says the array is primarily a sensitivity device rather than a direction finder. At the project’s operating frequencies and physical spacing, the four streams can be combined to improve signal-to-noise performance while retaining nearly omnidirectional coverage. Beamforming was considered, but the small array does not provide enough spacing to make it a useful solution for the intended role.

 The other parts are deliberately ordinary. A small e-paper panel shows alerts and timestamps, with the advantage that the last message remains visible after power is removed. A beeper, red LED and vibration motor provide different forms of local notification. An Ra-01H LoRa module sends a compact alert packet to other units. The system does not use a central server or require a network connection for the detector itself to make a decision.

 The power design is more thoughtful than the bill of materials might imply. VolAnti uses USB-C input, a BQ24074 charger with power-path management, a TPS63020 buck-boost converter and a 1S 2500 mAh lithium-polymer cell. The project reports roughly 18 to 22 hours on one charge. The battery is also retained in units that run from mains power because the simultaneous activation of the beeper, vibration motor and radio caused a brownout during bring-up when the board relied on USB power alone.

 That detail is a good example of the value of publishing engineering failures. A schematic can show that a power rail exists; it does not show that an alert event can make the device restart. For a warning instrument, the failure mode matters more than the elegance of the circuit.

 ## The signal-processing pipeline

 The detector takes a new audio frame every 32 milliseconds. According to the project documentation, it samples at 16 kHz and uses a 2048-point FFT over 512-sample frames. The FFT turns a short slice of microphone data into frequency-domain information that can be compared with candidate rotor rates.

 First, VolAnti maintains an adaptive picture of the normal acoustic floor. Quiet background sounds are learned over several seconds, while loud broadband events are incorporated more quickly. The purpose is to avoid treating the permanent noise of a site as a new threat every time the detector starts listening. This is useful in a real environment, but it introduces a familiar problem: a sound that remains present for long enough can become part of the baseline.

 The project addresses that problem with several detector tiers. The fast comb detector compares energy at the teeth of a candidate harmonic pattern with energy in the gaps. It searches candidate rates from 70 to 2000 Hz and keeps the best normalized score. The key is the contrast between the teeth and the gaps, not just the absolute strength of the signal.

 A single high score is not sufficient. The same candidate rate must remain the winner for six consecutive frames within a two-percent tolerance. That persistence check is meant to reject transient noise. Rotor speed can change, particularly while an aircraft approaches or changes thrust, so the firmware uses more than one way to estimate whether the acoustic structure is holding.

 The four detection tiers reflect different flight and noise situations:

 - The fast comb detector is intended for an approaching or changing aircraft, with the repository reporting a latency of about 0.23 seconds in its stated test conditions.
- A slow-comb detector uses a longer adaptive floor for an aircraft that arrives and then hovers, with a reported response of roughly 1.4 to 4 seconds.
- An envelope-based detector looks for broadband modulation associated with loaded, close, high-thrust flight and is listed at about 1 to 3 seconds.
- A no-floor comb detector uses a two-second Welch spectrum and whitening for a long hover in a location where the ordinary floor has already learned too much; its listed response is about 5 to 15 seconds.

 The architecture makes a sensible engineering trade. A detector tuned only for changes in sound can catch an arriving aircraft but lose it once the aircraft settles into a steady hover. A detector tuned only for a stable pattern can be slow when the aircraft is approaching. Running several specialized tests over the same spectrum lets the system respond to different acoustic histories without pretending that one threshold fits every scene.

 The project also says that the first tier is pinned by golden test vectors. The same test audio should produce the same result on a laptop and on the embedded board, down to the reported score. That kind of reproducibility is more valuable than a polished dashboard when other people need to inspect or improve a signal-processing system.

 ## What the first field result shows—and what it does not

 The headline result is a test dated September 6, 2026. A test rig using four 2807-class motors and seven-inch three-blade propellers hovered 104.2 metres away on a brick-walled street. The repository says there was light wind, passing traffic and people talking near the detector. The no-floor detector fired at that distance, while the project reports that the cars did not trigger an alert.

 This is a useful demonstration for two reasons. First, it uses a rig intended to match the motor and propeller class of the aircraft the design was built to address, rather than an unspecified toy drone. Second, it tests the detector against the kind of competing sound that matters in practice. An algorithm that works only in a quiet field has limited value as an alarm.

 The result is still a single measured point. It does not establish a universal 104-metre detection radius. Acoustic range changes dramatically with wind direction and speed, temperature, terrain, walls, vegetation, motor condition and the orientation of the aircraft. The repository itself gives a broad expectation: about 100 to 200 metres in still, quiet conditions, but 15 to 50 metres at a breezy or noisy site, with performance degraded above 8 metres per second of wind. Those are project estimates, not an independent certification.

 The earlier tests described by the project are similarly bounded. An August 21 open-ground test detected loaded propellers at 14 metres in changing wind without false alarms during that session. On August 28, a production board reportedly matched the reference output on golden vectors, with the slowest frame taking 29.4 milliseconds against a 32-millisecond processing budget over 1,938 frames. That says something about implementation timing and repeatability. It says less about long-duration operation in a new location.

 The repository also reports no false alarms in its field sessions so far. “So far” is the important part. False-alarm rates are not a property of the circuit alone; they belong to a site, a mounting position, a weather pattern and a maintenance routine. A road, roof, factory, rail line or construction site will each introduce different confusers. Public build reports from those environments would be more informative than another controlled hover.

 ## Why the LoRa design is deliberately simple

 Each VolAnti unit decides locally. When it detects a candidate, it sends an 18-byte packet containing identity, detector tier, rate, score and sequence information. Other units hear that packet directly. The repository emphasizes that there is no relay and no mesh routing, and that the system does not wait for a second unit to vote before sounding its own alarm.

 That choice follows from the purpose of the device. A network can improve coverage and move an alarm indoors, but requiring consensus can add delay or turn a single failed radio link into a missed warning. Local detection also means a unit can continue to function if the rest of the installation is down. The trade-off is that the system does not fuse observations into a shared track or calculate a location. It spreads alerts; it does not create a sensor network with centralized inference.

 Radio configuration is a deployment issue, not a universal setting. The documentation identifies 868 MHz for the UK and EU and 915 MHz for the United States, subject to the local allocation and applicable regulations. The frequency must be selected for the country where the unit is used. That is a small but important reminder that “open hardware” does not remove radio compliance from the project.

 A multi-unit installation also changes the practical problem. A perimeter node may hear an aircraft first, while an indoor node is placed where people can react to the warning. But coverage cannot be inferred from a simple circle on a map. Buildings and terrain shape sound, background noise varies by time of day, and the detector’s own assumptions may behave differently at each site. The documentation recommends treating placement, power, service intervals and coverage calculations as part of deployment rather than as an afterthought.

 ## Who should try it

 VolAnti is a strong candidate for makers who want to learn about embedded DSP, microphone arrays, open hardware and reproducible testing. The repository provides two build paths. A breadboard version uses a development board and microphone breakouts, with no custom PCB required beyond ordinary wiring and headers. The project estimates roughly £35 to £45 and an evening for that route.

 The full unit uses an assembled four-layer board, a printed enclosure and a small amount of final soldering and mechanical assembly. The stated parts estimate is about £50 to £80, with the published design intended to make the device portable and easier to deploy than a bench prototype. These prices will vary with shipping, component availability, fabrication region and whether a builder already has tools.

 It is also a useful project for researchers and maintainers who want real-world data. The contribution guide asks for build reports that include the firmware version, sound source, distance at which detection did and did not occur, wind and false alarms. That request is exactly what the project needs. A negative result from a noisy site can reveal more than a second success under similar conditions.

 A small institution might use it as an experimental warning layer around a property, but only after its own testing and legal review. The project’s open documentation makes inspection and repair possible; it does not turn an inexpensive prototype into a life-safety product. If a missed aircraft could cause serious harm, VolAnti should be treated as one input among other independent sensors and procedures, not as the sole basis for a protective decision.

 ## Who should wait

 Anyone looking for a certified detection system should wait. VolAnti is young, has a small public development history and presents project-authored measurements rather than a third-party performance evaluation. Its licensing is split across the repository: hardware is under CERN Open Hardware Licence Version 2.0 Weakly Reciprocal, firmware under Apache-2.0 and documentation under CC BY-SA 4.0. That is a reasonable structure for an open hardware project, but users still need to understand which licence applies to which artifact and review the complete licence files before redistributing a modified design.

 Anyone expecting direction finding should also wait or choose a different class of system. Four microphones in this enclosure improve sensitivity, but the repository explicitly does not present the array as a precise bearing estimator. The LoRa link shares alerts among units; it does not triangulate the aircraft. A buyer who needs a map, classification confidence, range estimation or integration with an existing command system will need additional sensors and software.

 The same caution applies to threat classification. VolAnti listens for rotor-like periodicity. It does not prove that the sound came from a particular airframe, identify a payload or distinguish every drone from every mechanical confuser. The project’s scope is deliberately narrow. That narrowness is a strength for a buildable prototype, but it should not be inflated into capabilities that the repository does not claim.

 ## The project’s most interesting open-source contribution

 The interesting part is not only the finished box. It is the way the project makes a testable argument from the microphone capsule to the alarm output. The hardware files expose the physical assumptions. The firmware exposes the frame timing and detector logic. The test audio lets others examine the algorithm. The golden vectors create a reference for future changes. The simulator makes the processing chain easier to understand before a builder has ordered a PCB.

 That is a better pattern for hardware projects with safety implications than publishing a short video and a parts list. A video can show that a particular unit detected a particular aircraft. It cannot show how the unit behaves when the wind changes, when a detector learns a hover into its floor or when a power spike occurs at the same instant as an alarm. A reproducible audio corpus and explicit thresholds at least give the community something concrete to challenge.

 The project also sets a boundary that is unusually clear for a dual-use design. The scope states that VolAnti detects and alerts, and will not include jamming, spoofing, interception, targeting or other countermeasures. That does not eliminate the risks associated with deployment, but it keeps the public repository focused on passive sensing and warning. For an open project in a sensitive area, scope discipline is part of the engineering.

 There is a broader lesson here for open-source infrastructure. When a familiar detection method fails because an adversary or technology has changed the channel, a useful response may be to look for a different physical signal rather than to make the original receiver more elaborate. VolAnti does that with sound. Its success will depend less on the novelty of the idea than on the next phase of evidence: varied sites, weather, aircraft, mounting conditions, long unattended runs and honest reports of misses.

 ## A sensible way to evaluate it

 A careful builder should begin with the repository’s breadboard path and supplied test material. Confirm that the board can reproduce the reference behavior before interpreting a live experiment. Then test ordinary background sounds at the intended site, including the sounds that will be present at the time the detector is expected to work. Measure both detection distance and non-detection distance; a claim that an aircraft was heard at one point is not a coverage map.

 Next, vary one factor at a time where possible: wind, aircraft orientation, hover versus approach, propeller condition, mounting height and nearby obstacles. Record the detector tier, response time, score and environmental conditions. Keep the results separate from the repository’s original numbers so that local measurements are not mistaken for upstream specifications.

 For more than one unit, test the LoRa path independently from the acoustic path. A device that hears correctly but fails to alert another unit has a communications problem; a device that broadcasts every local false alarm has a site or algorithm problem. The two failure modes need different fixes.

 Finally, keep the human procedure simple. The output is an alert, not an automated decision. Operators need to know what the signal means, what it does not mean, how to silence a nuisance alarm without stopping detection and what other evidence is required before taking any consequential action. The e-paper display and multiple local outputs help with that operational clarity, but no interface can compensate for an untested deployment assumption.

 ## Verdict

 VolAnti is one of the more compelling open hardware projects to surface in the current open-source radar because it connects a clear real-world gap with an understandable, repairable design. It is compact, inexpensive by the standards of specialized sensing equipment and unusually open about its algorithms, test vectors, power failure and limitations. The 104.2-metre demonstration is a meaningful result, especially because it took place with traffic and people nearby.

 It is not proof that a few microphones can replace radar, radio monitoring or professional counter-UAS equipment. The detector can miss aircraft, acoustic range can collapse in wind and noise, and the public evidence is still narrow. The right advice is therefore conditional: build it if you want to study the problem, contribute field data or add a passive warning layer that you can independently validate. Do not treat the current repository as a certified perimeter, a targeting aid or a guarantee that a quiet radio spectrum means a quiet sky.

 The next useful release will not necessarily be the one with the cleverest new classifier. It will be the one backed by more diverse recordings, documented false alarms, repeatable field protocols and clear answers about maintenance. That is where an open-source experiment becomes infrastructure people can responsibly rely on.