Counter-battery radar C2 integration: from detection to fire mission

A counter-battery radar that detects an incoming round but cannot get a target nomination in front of a fires officer before the hostile crew has displaced has accomplished nothing. The detection is real, the point of origin is computed, and the data is correct – yet the engagement window closes while the information sits in an isolated sensor console. The value of counter-battery sensing is realized only when the detection flows, automatically and within seconds, into a command and control system that can fuse it, deconflict it, and turn it into an actionable fire mission. This article walks the full path: from the physics of point-of-origin computation, through acoustic and radar sensor fusion, into the counter-fire tasking workflow that closes the loop.

The counter-fire loop: from detection to fire mission

The counter-fire loop is a tightly time-bounded sensor-to-shooter cycle. Every stage adds latency, and the total budget is set not by the software but by the enemy: a modern shoot-and-scoot artillery or mortar system can fire and displace in two to three minutes. The loop has five discrete stages.

1. Detection. A counter-battery radar or acoustic array detects a firing event – the radar sees the projectile in flight, the acoustic array hears the muzzle blast and shockwave. Detection produces a raw observation: trajectory points for the radar, time-of-arrival differences across microphones for the acoustic system.

2. Point-of-origin computation. The sensor fits a model to the raw observation and extrapolates back to the firing position. This produces a point of origin (POO), and for radar also a predicted point of impact (POI), with an associated uncertainty.

3. Ingest and fusion. The C2 system receives the sensor's detection message, normalizes it, geolocates the POO in a common coordinate frame, and correlates it against any other sensor that observed the same event. Corroborated detections are promoted to higher-confidence tracks.

4. Deconfliction and nomination. The fused track is checked against fire-support coordination measures and the friendly-force picture, then nominated as a candidate target with a recommended munition and effect.

5. Authorization and fire mission. A fires officer reviews the decision-ready nomination and, on approval, the system formats and transmits a digital fire mission to the firing battery. The loop closes when effects are delivered and the originating track is updated with the result.

Stages 1 and 2 happen inside the sensor. Stages 3 through 5 are the integration problem this article addresses – and where a well-architected common operating picture earns its keep.

How point of origin is computed

A counter-battery radar does not see the firing weapon directly. It detects the projectile after launch, during the ascending portion of its trajectory, as the round passes through the radar's surveillance fan. The radar captures a sequence of range, azimuth, and elevation measurements – discrete points along the arc – and fits a ballistic trajectory to them.

The fitted curve is then extrapolated in both directions. Extrapolating backward to where the trajectory intersects the terrain yields the point of origin: the firing position. Extrapolating forward yields the predicted point of impact, which is used to cue warning to units in the impact area. The quality of both extrapolations depends almost entirely on how many trajectory points the radar captured before the round left the beam, and on how closely the assumed ballistic model matches the actual projectile.

This is why weapon classification matters so much. Mortars fire on a high, arcing trajectory that keeps the round in the radar fan for a long, well-sampled arc, and the steep descent makes the back-extrapolation geometrically stable – mortar POO accuracy is excellent. Low-angle gun-artillery rounds present a flatter, shorter arc and a shallow ground-intersection angle, so small fitting errors translate into larger location errors. Rockets fall somewhere between, complicated by motor burn during the observed phase. A counter-fire system must carry the weapon-type estimate alongside the location, because the same circular-error figure means very different things for a mortar versus a howitzer.

Why a single radar is not enough

An emitting radar is a target. The moment a counter-battery radar transmits, it advertises its position to any electronic-support measures receiver in range, and disciplined opponents will attempt to suppress or destroy it. To survive, counter-battery radars operate intermittently – radiating in short windows, cued by other sensors, or cued by the very threat they are meant to detect. Intermittent operation means there will be firing events the radar simply does not see, either because it was silent or because the weapon fired below its horizon. A counter-fire architecture that depends on the radar alone has blind windows by design.

Acoustic and radar sensor fusion

Acoustic gunfire-location systems solve the radar's survivability problem precisely because they are passive. An acoustic array detects the muzzle blast of the firing weapon and, for supersonic projectiles, the ballistic shockwave. By measuring the time difference of arrival of these acoustic events across spatially separated microphones, the system triangulates the source. Because it emits nothing, an acoustic array cannot be located by electronic-support measures and cannot be jammed in the conventional sense – and it detects weapons that fire below the radar horizon.

The trade-off is precision and range. Sound travels slowly and is bent by wind and temperature gradients, so acoustic POO uncertainty is wider than a well-sampled radar solution, and effective range is shorter. Acoustic systems also do not predict point of impact, because they observe the launch, not the flight.

The two sensor types are complementary in exactly the way fusion theory likes. Radar gives precise location and impact prediction but reveals itself by emitting. Acoustic gives survivable, persistent detection but with wider location uncertainty. Fusing them produces a track that is both precise and corroborated, and – critically – keeps producing point-of-origin estimates during the windows when the radar is silent.

In the C2 system, fusion is a correlation problem. Each sensor publishes a detection as a candidate hostile-fire event with a timestamp and an uncertainty region. The fusion engine gates candidates in time and space: two detections of the same firing event must agree to within their combined timing tolerance and their overlapping uncertainty regions. When a radar POO and an acoustic POO correlate, the engine fuses them into a single track – the fused position is the confidence-weighted estimate of the contributing reports, and because two independent methods agree, the combined uncertainty is tighter than either alone. When only the acoustic sensor reports, the engine publishes the acoustic-only estimate with its wider ellipse rather than dropping a real firing event. The principles here are the same weighted-confidence fusion and uncertainty propagation that underpin any multi-source common operating picture.

Integrating the sensor feed into the C2 system

Connecting a counter-battery sensor to a C2 system follows the same adapter pattern as any other sensor source: never let a vendor-specific format propagate past the ingest boundary. The integration uses an adapter that subscribes to the radar's detection output – commonly an ASCA (Artillery Systems Cooperation Activities) message stream, an NFFI feed, or a vendor-specific protocol – and translates each detection into the C2 system's canonical track schema.

The adapter performs four jobs on each detection. It parses the message and extracts the computed POO, the predicted POI where available, the weapon-type estimate, and the time of firing. It geolocates the radar-relative POO into a WGS84 coordinate using the sensor's surveyed position and orientation – an error in the survey of the radar's own location propagates directly into every target it produces, so this step is unforgiving. It attaches an uncertainty ellipse derived from the trajectory-point count and the projectile classification. And it validates the result against physical plausibility ranges before forwarding it, so that a corrupt or spoofed message cannot inject a phantom target into the picture.

The normalized detection is then published to the common operating picture as a hostile-fire track. From that moment it is a first-class object in the C2 system: visible to authorized operators, available to the fusion engine for correlation with acoustic and other sensors, and eligible for the counter-fire workflow. This is also where coordination with adjacent counter-fire assets happens – a shared track database means a corps-level fires cell sees the same hostile-fire tracks as the brigade that owns the sensor.

The counter-fire tasking workflow

Once a fused hostile-fire track exists, the counter-fire workflow turns it into a target. The workflow is deliberately split between what the machine does and what the human decides.

The machine handles deconfliction and nomination. The system checks the fused POO against active fire-support coordination measures – no-fire areas, restricted-fire areas, the coordinated fire line – and against the friendly-force picture to rule out a strike on a friendly position or a protected site. If the location is clear, the system generates a candidate target: a recommended munition and effect appropriate to the estimated weapon type and the target's location, packaged with the supporting evidence (which sensors contributed, the confidence, the firing time). This package is presented to the fires officer as a single decision-ready nomination, not a raw sensor reading that the officer must interpret under time pressure.

The human handles the decision to fire. A fires officer reviews the nomination against the collateral-damage estimate and the rules of engagement, and authorizes – or declines – the mission. This is the one stage that is deliberately not automated. The same discipline that governs digital close air support coordination applies here: the software's job is to compress everything except the human judgment, so that the approval step is the only meaningful delay in the loop.

On authorization, the system formats the approved target into a standard digital call-for-fire and transmits it to the firing battery's fire-direction system. The full chain – detection, fusion, nomination, approval, transmission – is logged with timestamps for after-action review and accreditation evidence, and the originating hostile-fire track is updated with the engagement result so the picture stays coherent. For deeper detail on how the fire-mission message reaches the gun line, see the companion article on artillery fire control integration with C2 systems.

Counter-battery location also feeds the broader emitter and threat picture – the same hostile-fire tracks that drive counter-fire are valuable inputs to RF geolocation and threat correlation at the intelligence layer.