See the drone before it reaches you.
DroneEAR AI is a software intelligence layer that fuses radio-frequency, acoustic, telemetry, live air-traffic, live Remote ID and human-report signals, applies AI correlation, and raises an explainable alert only when independent sources agree. It makes existing sensors smarter, without new hardware.
The problem
Commercial drones now threaten airports, critical infrastructure, public events and borders. Traditional counter-drone detection relies on expensive, specialised hardware, so wide-area, layered coverage is hard to afford and hard to scale.
Single sensors are noisy. RF alone, acoustics alone or radar alone each generate false alarms, and operators are flooded with unfused, unexplained detections they cannot act on with confidence. Fusion is the answer.
Capabilities
Multi-sensor fusion
RF, acoustic, telemetry, registries and human reports merged into one correlated picture per zone.
Multi-node triangulation
Two or more nodes hearing the same contact cross their bearings into a position. A single node gives a bearing only, and the fusion layer never invents a range it did not measure.
AI correlation
An explainable threat assessment in plain operator language, produced only on escalation.
Live tactical map
Real air traffic from a live ADS-B feed, plotted in real time around the protected site, plus real drones that identify themselves over network Remote ID, worldwide, shown as context and never as a threat.
False-alarm discipline
HIGH requires two independent sensors to agree and an unknown identity. Single blips never alert.
Standards integration path
Two public feeds are live today: ADS-B air traffic, and network Remote ID shown as context. Broadcast Remote ID reception, ASTERIX, U-space and STANAG are the documented integration path into existing command systems, not shipped connectors.
Defensive, on-premise
Detection and early-warning only. On-premise or air-gapped, encrypted and auditable.
Integration with existing systems
DroneEAR is the fusion and AI layer above a customer's sensors. The design ingests events from real detectors and pushes a scored alert into the operator's command system through recognised standards. Being exact about the stage: two public feeds are live today, ADS-B air traffic and network Remote ID (drones that identify themselves, context only). The table below is the integration path a pilot would work through, not a list of finished connectors.
| Domain | Interfaces |
|---|---|
| Identification | Remote ID (ASTM F3411), ADS-B |
| Air / drone traffic | ASTERIX, U-space / UTM |
| Military C2 | STANAG 4586 / 4609, Link 16 / STANAG 5516 |
Where this applies
A small drone creates the same problem for a forward site and for a regional airport: single sensors are noisy, and an operator flooded with unfused alerts cannot act on any of them with confidence. The fusion approach is the same in both domains, which is what makes this a dual-use software layer. So is the stage: everything below is where this would apply, not where it is deployed.
| Setting | What the fusion layer would address |
|---|---|
| Defence and national security | Layered early warning across sites and borders, where wide-area coverage from dedicated hardware alone is hard to afford |
| Airports and airfields | Separating registered traffic on ADS-B and Remote ID from an unregistered contact near an approach path |
| Energy, water and industrial sites | Long perimeters and dispersed assets, where one radar per site does not scale |
| Ports and offshore energy platforms | Large open areas with constant legitimate movement, so the false-alarm rate decides whether an alert is trusted at all. Offshore, a thin link to shore is why the layer runs on site. Maritime sensing is on the roadmap, not built |
| Stadiums and public events | Temporary coverage at short notice, assembled from sensors already on site |
| Prisons and secure facilities | Small, low, short-duration flights that any single sensor class routinely misses |
Privacy, stated up front. Civil sites carry data-protection obligations a military perimeter does not, because RF and acoustic sensing happens around the public. Two things are true of the demonstrator today. It consumes normalised detection events from sensors, meaning a source, a coarse zone, a confidence value, a bearing and a timestamp, rather than audio recordings or raw RF captures, and the only positional data it handles is public ADS-B aircraft telemetry and the public network Remote ID positions of drones that identify themselves. And it has not been assessed against GDPR for any real deployment, because there has not been one. What a real installation must do depends on the sensors a partner brings, and that assessment belongs in the pilot, before anything is switched on.
Civil applicability does not change export control. Dual-use means usable in both domains, which is what places technology inside the rules rather than outside them. Any future supply of technology would be assessed under EU Regulation 2021/821 and national export-control law first.
For partners
We bring the software intelligence layer, the AI correlation, the operator console and the integration engineering. A partner brings real sensors, an accreditation path and a customer channel. EU Defence Innovation (EUDIS) and European Defence Fund calls fund exactly this dual-use software layer.
First step: a pilot at one real site with one or two real sensor types plus the live feeds, to measure the real-world false-alarm rate. Built by a former Army Engineer (Military Technical Academy, Bucharest) who deploys and operates production AI systems on his own infrastructure.
Project stages
Where the project actually is, and what each step requires. Phases 1 and 1.5 are built and running. Everything beyond them needs a partner, real sensors, and a site.
| Stage | Status | What it covers |
|---|---|---|
| Phase 1 Prototype |
BUILT | Multi-source ingestion, fused event stream, two-tier correlation, explainable threat assessment, operator console, live ADS-B and network Remote ID (context only), alerting. Running on simulated threat signals plus live public data. |
| Phase 1.5 Persistence |
BUILT | Durable recorded history of every assessment and alert, surviving restarts. After-action replay of any time window, showing what each source reported, what the rules computed, and why. Operator adjudication of every alert as real, false or unknown, and a report that turns those verdicts into a false-alarm rate. No rate is claimed yet: this is the instrument a pilot needs, built before the pilot rather than after it. |
| Phase 2 Real sensors |
Needs a partner | Integration with real RF, acoustic and radar hardware over the standard interfaces. A pilot at one site to measure the real false-alarm rate, the number that actually matters. The measurement and adjudication tooling for it is already built and running, and an offline replay can measure a partner's recorded detections before any live connection. |
| Phase 3 Learned detection |
Planned | Machine learning on flight patterns and signatures, tuned against real measured data to cut false positives further. |
| Phase 4 Operations |
Planned | Multi-site command picture, role-based operator workflows, accreditation and on-premise or air-gapped deployment. |
| Phase 5 Distributed grid |
Long term | Wide-area and edge sensing across many sites, federated into a single early-warning picture. |
| Extension: Maritime | Planned, needs a partner | The same fusion applied at sea, for ports and offshore energy platforms: AIS for vessels that identify themselves, a partner's marine radar and camera output consumed as third-party events, and structured reports from crews. Nothing maritime is built today. Any function that tracks moving objects would need a new export-control classification before it is built. |