Radar Scan Conversion - A Brief Tutorial

SPx Radar Scan Conversion

A quick summary of the process and the problems.

What is radar scan conversion?

Radar scan conversion involves the transformation of data in a polar range-azimuth format to Cartesian x-y format for display. The data is in range-azimuth format because it is supplied by a radar that provides a set of samples (the radar return) for a specific bearing angle (azimuth) of the radar. As the radar antenna rotates, the azimuth changes and new data sets are generated for different azimuths. In the case of a rotating search radar, the azimuth increases steadily around a full 360 degrees of rotation.

How does the conversion work?

How does the conversion work?

Converting from range-azimuth to x-y is simple trigonometry. A sample at a range R and azimuth A contributes to a display point X,Y where X = R.Sin(A) and Y = R.Cos(A). Alternatively, a screen point X,Y is derived from a radar sample at R = SQRT(X*X + Y*Y) and A = ATAN(Y/X).

In practice, however, there is not a one-to-one correspondence of radar samples to screen pixels, so the conversion process (whether forwards from polar to Cartesian, or reverse from Cartesian to polar) needs to combine a number of data points to derive an output.

Although the basic concepts of radar scan conversion are easily understood, an implementation needs to consider problems of resolution conversion (more display pixels than input samples, or more input samples than display pixel), spokes, holes, accuracy, performance, fade simulation, view control, trail retention, underlay mixing, overlay graphics etc.

Forward or Reverse Processing

Scan converters have historically been classified as either forward or reverse. In a forward scan converter the incoming range-azimuth data is converted to corresponding display pixels using the basic trigonometric formula above. However, without any further processing this would generate "holes" or "spokes" in the display at longer ranges. Consider that the radar is being displayed with its centre in the middle of a window of size 1000 x 1000 pixels. Then the radar range is 500 pixels and the circumference of the circle is about 3140 pixels (2 x Pi * 500). Now if there are 1000 returns provided by the radar per 360 degrees, it is evident that there are too few input values to fill the pixels around the edge of the display. The problem can be solved with "hole-filling" algorithms that attempt to in-fill the missing data.

The reverse scan-conversion process solves the spoke/hole problem by tackling the problem from the other direction. In the reverse method each screen pixel is mapped back to a data sample in the polar source. This ensures that every display pixel is filled with the closest radar sample for that screen point. There are no holes and spokes with this method; however, there is another problem. With the reverse method, there is no guarantee that a sample from the input polar data actually gets displayed. If there are a number of polar samples that would map to the same screen pixel, then the reverse method will select only the nearest polar sample, possibly missing a more significant data point.

Practical implementations of both forward and reverse scan converters solve the missing data problems in their own way, ensuring that data is presented correctly, without overlooking any.


It might sound obvious to say that the scan conversion process should be accurate, but in a real-time process that is processing many millions of pixels per second, the transformation between polar and cartesian may trade accuracy for performance. This has been especially true when the conversion process is implemented in hardware, and therefore uses limited precision arithmetic, or even approximation tables. Modern software-based approaches are able to exploit the floating-point performance of processors, offering accuracy without compromising speed. Accuracy is typically tested by injecting a single sample target into the polar-store then examining the position of the scan-converted data in the output. By comparing the theoretical position with the actual display data (centroid and bounding box, since one input sample may generate multiple display pixels) the conversion accuracy can be measured and quantified. A vendor will typically supply this data on request.

Scan Conversion Architecture

Where does the scan conversion occur relative to the display and the original polar radar video? If the polar radar video is received at each display client and presented directly into the display, then scan-conversion occurs at that point. This is the most common architecture and provides the most flexibility in the presentation of the radar to the user.

In other situations it may be possible to separate the scan conversion from the display client. When this occurs, the scan conversion can be pushed back into a server to deliver bitmap data, probably over a network, to client displays. This server-based scan conversion architecture has some benefits, centralising all radar signal and display processing into one location, reducing the workload on the clients displays.

The best architecture for a given situation is dependent on a number of factors, including the number of radars, consoles, radar bandwidth, PRFs etc.

Display Presentation

The scan-converted radar picture presents information to a display that an operator will use to make decisions. In addition to the most recently scan-converted data, historical video is often presented. This is a "faded" form of the data that initially appeared as new. By displaying several scans worth of video, for example, it becomes possible to identify targets by the trails that they leave.

Historical data can be presented by reducing the intensity of radar video with time, allowing it to fade to the background. This process is a simulation of the phosphor decay that occurred with the original display tubes. The fading process can be either "real-time" which means that the radar data is reduced in intensity at regular time intervals, irrespective of the incoming azimuth data, or else may be sweep-based. In sweep-based fading the intensity of the video is only changed when the radar sweep revisits an azimuth. This allows the display to be updated with the largest of the new data and the faded historical data.

Some situations, notably those associated with a fast radar that refreshes the display quickly, do not need or desire historical data. In this situation, the display shows only current radar video.

A feature of some modern scan converters is the ability to display data in different colours, for example showing new data in one colour and old data in another.

Combining Radar and Graphics

Although the principal role of a radar scan converter is to convert the polar format data into display data, the capabilty to combine the radar video with graphics data is often included in the scope of the scan converter. The requirement is to support the presentation of the radar video with underlay maps and overlay symbology, in which the underlay components are semi-transparently blended with the radar, and the overlays are opaque to both. Hardware scan converters employ a number of innovative techniques for combining the radar picture with the graphics, sometimes providing the graphics frame store as an integral part of the scan-converter, and sometimes accepting an external graphics input for mixing with the radar. The output is then a combination of the underlay, radar and overlay layers.

In a software-based scan converter using standard processors and graphics cards the problem remains the same. The challenge is to accomplish the real-time video mixing in the standard hardware and graphics architectures. Advances in graphics architectures in recent years have produced significant improvements in performance. Modern graphics processor units (GPUs) are sophisticated processors in their own right, offering multiple cores and pipelines and supporting their own graphics languages to run code within the GPU itself. This architecture, combined with optimised drivers for high-speed colour blits and alpha copies, enables software-based video keying at very high speeds. This means that graphics comprising underlay and overlays can be seemlessly fused with radar, or other sensor video, to create a composite display that even surpasses the display capabilities of some dedicated hardware scan converters.