We stopped talking about detection range

Every counter-UAS conversation starts the same way. Someone asks how far it detects. Someone answers in metres. The number gets written down, and everyone acts as though something has been settled.

Nothing has been settled. We spent a few weeks building our own product argument around a range figure before realising the figure was answering the wrong question. Fixing the question changed what we were building.

Here’s the arithmetic that did it.

Range is a proxy for time

A vehicle-mounted detector exists to give the people inside enough warning to do something, so the unit that matters operationally is seconds, not metres. At a detection distance of 150 m:

Look at what happens to the marginal value of range. Going from 100 m to 150 m is a 50% improvement, the kind of thing that could take months of work on the array, enclosure and classifier. Against a target closing at 100 km/h, it buys 1.8 seconds. Against something faster, less.

Two seconds is not nothing, but it is not the step change that “50% more range” sounds like on a slide.

How the engagement actually goes

The table assumes something that almost never happens: a drone appears at 150 m and flies in a straight line toward a vehicle at full speed.

Watch enough footage and that picture falls apart. An FPV operator is flying through a camera with a narrow field of view and no depth perception. They have to find the target, work out its heading, get into position relative to it, fight whatever the wind is doing, and set up an approach. Against a moving vehicle that can mean several attempts.

The dive is the last few seconds of an engagement that has already been running for a while. The drone is usually audible for far longer than the terminal geometry suggests: not 5.4 seconds, but sometimes even tens of seconds.

That changes what the detector is for. If the exposure window were really 5.4 seconds, the design problem would be raw sensitivity: hear it as far out as possible, because you only get one look. If the window is usually much longer, sensitivity stops being the binding constraint. You get many looks at the same target, from changing bearings and throttle settings. What matters is whether you can say something confident across all of them.

The terminal numbers still matter, because sometimes you do get the worst case: a drone that comes over a treeline already committed. We design against those numbers as a floor. But the floor is not the typical case, and building the entire product around it produces the wrong product.

The detection problem is changing

The threat we designed Falcon around is the one-way attack FPV: a cheap airframe flown directly into a vehicle by an operator watching through its camera.

One of the obvious ways to look for a drone is to look for its radio activity. If the aircraft and operator are communicating over RF, that gives a detector something to find. Fibre-optic FPVs change that. The drone stays connected to its operator through a physical tether, and the signal a passive RF detector would normally depend on may simply not be there.

The drone itself has not disappeared. Its motors still turn, its propellers still move air, it still produces sound, and it is still a physical object that can be seen.

That is the gap Falcon is built around: detect the aircraft itself rather than depend on what it happens to be transmitting. Acoustic sensing provides the first warning and a bearing. Visual sensing corroborates that detection and helps determine what is actually there. Both operate passively, and neither requires the target to cooperate by emitting a detectable control signal.

That matters most for fibre-optic threats, but it gives the system a more general property: Falcon does not have to care what communication link the drone is using.

What the thing is, and who it’s for

The one-way FPV has changed what a road looks like in Ukraine, and the pattern is exportable.

So the users we build for are anyone in a vehicle that could be a target and currently gets no warning at all. Military and convoy crews first, because that’s where the problem is worst, but also logistics and aid convoys, utility fleets, border and police vehicles, and anyone moving valuable cargo through places where the threat has arrived ahead of the doctrine for handling it.

The design constraints follow from that list. It has to be cheap enough to put on many vehicles rather than one. It has to install in minutes without a technician. It cannot assume infrastructure, because the vehicles that need it most are often furthest from any.

That’s why Falcon runs entirely on its own:

• Fully passiveFalcon observes the aircraft itself and transmits nothing of its own.
• Fully offlineNo cloud, no server, no network dependency. Every model runs on the vehicle, so it works in a valley, in a tunnel, under jamming, and where infrastructure has been destroyed.
• No batteries to manageFalcon runs directly from the vehicle, with nothing separate to charge or swap.
• Minutes to installA mounted head, a cable, a display. No drilling and no permanent modification.
• Stacked AI models on cheap edge hardwareInstead of one large neural network doing everything, the system uses a chain of increasingly expensive AI models, each running only on what the model before it flagged. That’s what makes real-time inference possible on hardware that costs less than the mount it sits on.

Modularity is architecture, not marketing

Falcon 1 is built in modules that arrive in order, and the first one is a complete product on its own.

That first module is acoustic, and the hardware is built and on a vehicle: a passive microphone array on a roof-mounted head, an edge computer, a driver-facing display with bearing and an audible alert, and the power and mounting hardware to install the whole thing in a few minutes. The signal processing and classifier work runs against field recordings we’re collecting now.

The audio module is designed to hear, decide and warn on its own. Every module after it makes the warning better. A customer can buy the base system, field it, and add capability later without replacing what they already own.

The second module is visual: a long-focal-length camera on a pan-tilt head, cued by the acoustic bearing. It’s designed and specified, and we are currently building it. Passive RF can come later where it is useful, but Falcon’s core sensing architecture cannot depend on RF being present, because increasingly it may not be.

That ordering is the reason this post exists, because working out what the visual module is for turned out to be harder than working out how to build it.

Where the seconds actually go

We design against the floor anyway.

The obvious architecture, and the one we started with, is a chain: hear something, work out roughly where it is, point the camera there, search, confirm, alert.

Budget that chain honestly and it looks like this:

• Acoustic detection and classification1.0 – 2.0 s
• Slew the camera to the acoustic bearing, depending on how far it has to travel0.6 – 2.0 s
• Search in elevation, because a planar array doesn’t give a usable vertical angle~0.5 s
• Run the visual detector on what it finds~0.2 s

Time to confirmed visual identification 2.3 – 4.7 s

Against a drone that has been circling for half a minute, that’s fine, and there’s time to do it several times over. Against the worst-case 5.4 second dive it’s tight. Against anything faster it doesn’t close at all.

We could treat the tight case as a performance problem and grind it down. Faster servos, tighter loops, a smaller search window. All of that is worth doing, and we’re doing it. But it exposed a structural error that no amount of grinding fixes.

If the warning waits until the end of that chain, the system’s usefulness in the worst case is hostage to its slowest and most failure-prone stage: a mechanical search that might not find anything, in weather, at night, against a target that may be a grey dot on a grey sky.

The fix is to stop the chain being a chain

The alert doesn’t wait. The audible and on-screen warning fires on the acoustic detection, whether or not the camera ever finds anything. Everything downstream runs in parallel and upgrades the alert in place rather than gating it. The state goes from POSSIBLE to CONFIRMED. It does not go from silence to alert.

This sounds like a small architectural detail. It’s probably the most important decision in the product, because it means the camera is no longer in the warning path at all. And once it isn’t, you have to ask what the camera is actually for.

What the camera is for

The camera does not produce range or warning time. It exists to stop the system lying to you.

Go back to the long exposure window. If a drone is audible for tens of seconds before it commits, then so is everything else, all day, for as long as the vehicle is running. A passive acoustic detector on a vehicle roof hears the vehicle itself, the road, the weather, and every other machine within earshot. Some of that is rotating machinery, and rotating machinery is what the classifier is looking for.

Acoustic analysis gets you a long way against that. It does not get you all the way.

So the camera’s job is to resolve the ambiguity the microphones cannot, fast enough that the operator’s trust survives contact with a real environment. Classification, corroboration, and a recorded frame so somebody can check later what actually happened. Those are the deliverables.

There’s a design consequence that falls directly out of this, and it’s the reason the reframe was worth the effort. The camera should start slewing on the first, lowest-confidence acoustic bearing available, not on a confirmed classification. Waiting for the classifier puts the slew and the classification in series, which is affordable during a long loiter and unaffordable during a dive.

A wasted slew costs nothing. A late slew costs the confirmation.

Keeping the far end open

Once the camera stopped being a warning device and became a confirmation device, something else followed: a confirmed track is worth more to a machine than it is to a person.

A driver who gets a bearing and a warning tone can take cover, change speed, or break line of sight. That’s the job, and it’s most of the value. But the same output, bearing, elevation, classification, confidence and a timestamped track, is exactly what any downstream system would need. Jammers. Directional effectors. Kinetic interceptors. A second vehicle’s display. A fleet log that tells somebody a week later where and when the contacts happened.

So Falcon’s output is a documented message on a standard interface rather than something buried inside our own code. Anything that can subscribe to it can use it. If a customer already fields an effector, Falcon slots in underneath it rather than competing with it, and integration becomes a schema conversation rather than a partnership negotiation.

Our focus today is the sensing layer, because that’s where the hard unsolved problem is. Where the stack goes from there is a question we’re keeping open on purpose. We don’t know what the effector layer looks like in three years. We do know that a sensor with a closed output is worth less than one with an open one.