CFAR Detection: CA vs OS vs GO/SO, Explained

A radar detector has one job: decide, for every range-Doppler cell, whether there is a target in it. The naive approach — compare the cell's power against a fixed threshold — fails immediately in the real world, because the background is not constant. Thermal noise varies with gain settings, clutter varies with terrain and weather, and interference comes and goes. Set the fixed threshold low enough to catch small targets and the false alarms bury your tracker; set it high enough to silence the false alarms and the small targets vanish.

CFAR — Constant False Alarm Rate — detection solves this by making the threshold adaptive: each cell is compared against an estimate of its own local background, scaled so the probability of a false alarm stays fixed no matter how the background moves. This post walks through how the estimator works, where the classic cell-averaging version breaks, and how the OS and GO/SO variants trade against it — ending with what actually matters when you put CFAR on an FPGA.

The CFAR window: CUT, guard cells, reference cells

CFAR processes one cell at a time — the cell under test (CUT). Immediately around it sit a few guard cells, excluded from the background estimate so that energy from a real target in the CUT doesn't leak into its own noise estimate and suppress its own detection. Beyond the guards stretch the reference cells — the leading and lagging windows whose contents are the raw material for the background estimate. The whole assembly slides across the range profile, re-deciding at every position.

CA-CFAR (cell averaging) uses the mean of all reference cells as the background estimate, then multiplies it by a threshold factor α chosen for the desired false-alarm probability. For a square-law detector in exponentially distributed noise the relationship is closed-form: α = N(P_fa^(−1/N) − 1) for N reference cells. That closed form is the quiet superpower of CA-CFAR — you dial in a false-alarm rate analytically, and in homogeneous noise it is essentially optimal.

Where cell averaging breaks

CA-CFAR's assumption is that the reference cells are statistically identical to the CUT's background. Two common situations violate it. At a clutter edge — the transition from clear air into rain or from sea into land — the window straddles two different backgrounds. Entering the clutter, the average is dragged down by the clear-side cells, the threshold sits too low, and false alarms spike. Leaving it, the threshold sits too high and real targets just inside the edge are lost.

The second failure is target masking. If a second strong target sits in the reference window of the first, it inflates the average and can push the threshold above the first target's return entirely. Two ships close together, a formation of aircraft, a target near a discrete clutter spike — the pair detection problem is the rule in dense scenes, not the exception.

The variants: GO, SO, and OS

The classic fixes keep the window structure and change the statistic. GO-CFAR (greatest-of) computes the leading and lagging means separately and takes the larger — conservative at clutter edges, which suppresses the false-alarm spike, at the cost of extra masking when the interferer is on one side. SO-CFAR (smallest-of) takes the smaller mean — better for closely spaced targets, worse at edges. OS-CFAR (order statistic) abandons the mean entirely: it sorts the reference cells and uses the k-th ranked value (k around 3N/4 is the common choice). Because a few strong interferers barely move a rank statistic, OS-CFAR tolerates up to N−k interfering targets in the window for a modest CFAR loss — typically a fraction of a dB to ~1 dB against CA in clean noise.

CFAR on an FPGA

CA-family CFARs are nearly free in fabric: the window mean is a running sum — add the cell entering the window, subtract the one leaving — so each range bin costs two adds regardless of window size, and the threshold multiply is one DSP slice. GO/SO just split the sum in two and add a comparator. The engineering content is in the plumbing: latency-deterministic pipelining so detections align with the data that produced them, correct behavior at the edges of the range swath, and a threshold factor α that is runtime-programmable so operators can trade P_fa against sensitivity without a new bitstream.

OS-CFAR is where implementations earn their keep. A full sort per output bin is wasteful; practical designs maintain a running sorted window — insert the entering cell, retire the leaving one — or use compact sorting networks when the window is short. The cost is real but bounded, and it buys the multi-target robustness that dense scenes demand. Our CFAR cores implement CA, OS, and GO/SO variants behind one interface, with configurable guard and reference depths, programmable threshold scaling, and verification harnesses that replay recorded and synthetic scenes against a bit-true model.