The Eurocontrol Standard Document for Surveillance Data Exchange, Category 240 (henceforth referred to as “CAT-240”) describes the application of ASTERIX to the transmission of rotating radar video.
This document describes the Navtech Radar implementation of CAT-240. It is not intended to replace CAT-240; rather it describes how the standard has been implemented and provides clarification, including details of any assumptions made, any limitations that apply and any Navtech-specific extensions that are provided. It is recommended this document is read in conjunction with CAT-240.
This document is applicable to the development of a client application that receives network radar video in ASTERIX CAT-240 format from a Navtech radar system.
The CAT-240 standard defines messaging fields in terms of (groups of) octets; and, in the case of individual bits, field reference numbers. Such definitions are independent of any particular implementation.
For this document, field layouts are defined in terms more consistent with, and more familiar to, common programming languages such as C or C++.
Message structures are always defined in declaration order. That is, in ascending address order.
Fields sizes are specified using Posix type aliases.
Where multi-byte fields are depicted, the least-significant byte is shown on the right; the most-significant byte is shown on the left.
Where individual bits in a field are significant (that is, bit field types) bit numbers are specified from zero. The least significant bit is always depicted on the right; the most-significant bit on the right.
Note, the depiction of multi-byte fields does not imply endianness. See section 2.3 for more details on byte ordering.
CAT-240 messages are sent as UDP network packets.
The radar may unicast UDP packets to a single client, or multicast UDP packets for receipt by multiple clients.
The IP address and port used by the radar to send CAT-240 message are configurable options. By default, the following address and port are used:
Table 1 - Default IP address and port for CAT-240 data
Supported Message Types
CAT-240 defines two message types:
Video summary messages
Navtech only supports Video messages. This document therefore only specifies Video message requirements.
Video summary messages may be supported in future releases.
Data Framing & Rates
Video data from a Navtech radar is sent on an azimuth-by-azimuth basis. The data for each azimuth is a sequence of bins (range cells), each representing a power level at a distance from the radar. The first value represents the bin closest to the radar.
Each CAT-240 message encapsulates a single azimuth’s worth of data.
The maximum number of bins for each azimuth is a configurable property of the radar.
Radar data may be contoured, meaning the number of bins in each message could change on an azimuth-by-azimuth basis.
The number of CAT-240 messages generated is a factor of:
The number of azimuths sampled per rotation
The rotation rate of the radar
The number of azimuths sampled for each rotation and the rotation rate of the radar depend on the radar model.
For example, a radar may generate 400 azimuths per rotation, and rotate at 4Hz, giving a message rate (or Packet Rate Frequency, PRF) of 1600 messages/sec
All data is sent as Network (that is, Big) endian.
Clients may therefore have to performing byte-swapping on multi-byte words to retrieve data correctly.
A CAT-240 message is illustrated in Figure 1. It consists of five main elements:
A data block, containing basic message details
The video data header, which defines the context of the video data
The video (FFT) data
A time-of-day field
A special-purpose field containing Navtech-specific extended information
Figure 1 - CAT 240 message structure overview
Message Data Block
The message data block defines basic characteristics of the message and the specific configuration of the message.
The structure of the message data block is shown in Figure 2
Figure 2 - Message data block layout
The message category.
Always 240 (0xF0)
The overall message length, including this data block
Feature specifications for this message.
The Feature Specification bit field structure defines which fields are present in the message and, in the case of optional features, which option(s) have been selected.
The feature specification is laid out as shown in Figure 3.
For the Navtech implementation of CAT-240 some fields are mandated. Figure 3 shows the default flag settings. Note, in the cases where bit field values have not been specified these fields will be set according to the supplied video data. See later for more details.
The video header provides the context for the FFT data packaged in the message.
In the Navtech implementation of CAT-240 a video message represents a single azimuth of data.
The video header is structured as shown in Figure 4. CAT-240 field references are provided for cross-reference.
Figure 4 - Video header structure
System Identification Code / System Area Code
Incrementing message counter
Start angle for data, encoded as 1/360 of a degree.
End angle in encoded as 1/360 of a degree.
Size of a bin in femtoseconds.
Defines the resolution (number of bits) for each bin; and whether the data is compressed.
Size of the FFT data, in bytes.
Size of the FFT data, in bins.
Data Source Identifier
The Data Source Identifier provides a unique identifier for the radar source. The Data Source Identifier is a 16-bit field structured as shown in Figure 5.
Figure 5 - Data Source Identifier structure
For Navtech, the values of the SIC/SAC values are set to
System Area Code
System Identifier Code
Start & End Azimuth
A Navtech radar outputs its FFT data on discrete azimuths. The number of azimuths sampled per rotation depends on the radar; and is configurable.
A CAT-240 message requires the azimuth start and end to be specified as an 16-bit angle, with a resolution of 1/360 degree.
Azimuth value = angle in degrees * (216 / 360)
and for extracting the angle:
Angle = value * (360 / 216)
Data is sent on a per-azimuth basis, with the start and end fields determined as follows:
· The end azimuth is set to the angle of the current azimuth.
· The start azimuth is set to the angle of the previous azimuth
Azimuth angle is calculated as follows:
Azimuth angle = azimuth number / (azimuths per rotation / 360)
Similarly, the current azimuth can be calculated from the angle:
Azimuth number = round(angle * (azimuths per rotation / 360))
The number of azimuths in a full rotation is not a defined field in CAT-240. Therefore, this value is provided as part of the Special Purpose field. See XXXXX for more details.
Cell duration defines the size of an FFT bin in femtoseconds.
Cell duration is calculated as follows
Cell duration = bin size in metre / (c / 2)
Where c represents the speed of light (defined as 299, 792, 458 ms-1).
By extension, the range of the range of the radar can be calculated as
Radar range = ((cell duration * fsec) * (c / 2)) * range in bins
Where fsec represents 1 femtosecond in seconds – 10-15 sec.
Range in bins is not part of the CAT-240 standard message, so is included in the Special Purpose field extended data.
If non-contoured data can be assumed, then the range in bins will be the same as the video block cell size.
The resolution field defines two properties of the message
· The resolution of the FFT data, in bits
· Whether the data is compressed
The structure of the resolution/compression field is shown in Figure 6.
Figure 6 - Resolution / Compression field structure
Radar data is never compressed. The MSB of the resolution/compression field will always be zero.
The resolution is defined as an encoded value, as shown in the table below.
Note, for Navtech radars, only 8-bit or 16-bit data will be transmitted.
Encoding, in bits
Data Size In Bins
The number of bins in the message is calculated as
Number of bins = video block size in bytes / resolution in bytes
Where resolution in bytes must be computed from the resolution/compression field value.
The video data block holds the FFT data. It is structured as shown in Figure 7.
CAT-240 frames video data into fixed-sized blocks. The size of each block and the number of blocks depends on the size of the FFT data.
Figure 7 - Video data block structure
The number of blocks in the Video data block
A block of FFT data. The size of the block is determined by the configuration in the video message header.
Video Data Block Size
The framing configuration for an incoming message is specified with two fields:
The feature specification bits low data volume, medium data volume and high data volume define the size of a block (See 3.2.1)
The Block field defines the number of blocks contained in the message.
The block size is defined in the table below. Note, the data volume flags are mutually exclusive; at most one of the fields must be set.
Feature specification field
Block size, N (bytes)
Video data low volume == 1
Video data medium volume == 1
Video data high volume == 1
If the number of bytes in the FFT data is not an exact multiple of the video block size, then the number of video blocks is rounded up. Any unused bytes used to pad the last video block are set to zero.
For extracting FFT data, client applications should use the NB_VB field, as this gives the actual size, in bytes, of the FFT data.
For extracting the Time-of-day (and any other subsequent fields) client applications must use REP * block size to calculate the alignment correctly.
Time-of-day is an absolute time stamp, expressed in UTC. The time-of-day is reset each day at midnight; that is, the time-of-day holds no date information.
Time-of-day is stored as a 24-bit number, interpreted as an integer fixed-point representation, as shown in Figure 8
Figure 8 - Time-of-day encoding
The time-of-day field uses an 8-bit value for the sub-seconds; therefore, time resolution is 1/128 sec – 7.8125 msec.
For a radar sampling 400 azimuths per rotation, at 4Hz, each azimuth message is generated every 625 microseconds. Time-of-day is too low resolution to use for precise azimuth timing. To expedite this, precise azimuth timing, to nanosecond resolution, is supplied in the Special Purpose field.
Special Purpose Field
The Special Purpose Field allows an application to include custom data that is not specified in the ASTERIX standard. This field includes more detailed information describing the format of the data than is supported by the ASTERIX standard.
For Navtech radars, the Special Purpose field is defined in Figure 9.
Figure 9 - Special Purpose field structure
The size of the Special Purpose field, in bytes
UTC seconds since the Unix epoch (01 Jan 1970, 00:00)
Nanosecond resolution field of the timestamp
Azimuths per rotation
Total number of azimuths sampled per rotation
Range in bins
The range of the radar, expressed as a number of bins
Current radar rotation speed, in milli-Hz
Range scaling factor.
Encoded as a IEE 754 binary32 (float)
Range offset of the FFT data, in metres.
Encoded as a IEE 754 binary32 (float)
Radar component health status
Radar Health Status
Radar health status provides information on the current operating status. The field is encoded as a bit field, as shown in Figure 10.
Figure 10 - Radar health status bit field structure
Each bit field is encoded with two bits. The value of the bits indicates the health status of the property, as shown by the table below.
Invalid / unknown
Endianness & Field Layout
Network Endian Encoding
Bit Field Structure Layout
Example Video Message
Below is an example video message with representative values for each field. This message is designed to be used to validate client application decoding.
Field values are given in big endian (network order) and little endian, as well as decimal (when relevant).
The video message is for a radar system producing data as follows:
Rotation rate – 4 Hz
Azimuths per rotation – 400
Radar range in bins – 2856
Radar range in metres – 500m
8-bit (high) resolution, no compression
Special Purpose Field
Encoding an azimuth into a single Video Message will result in a UDP network packet that may exceed the size of the MTU (Maximum Transmission Unit) for the network. A typical value for the MTU is 1500 bytes, which is smaller than a typical azimuth FFT message. If the operating system supports Jumbo Frames the MTU may be as high as 9kB. This may be adequate for typical radar returns, but longer-range radar azimuth data may still exceed this.
The operating system at the sending end will normally split the outgoing packet into fragments that are smaller than the MTU. The operating system at the receiving end will recombine the fragments to rebuild the packet, which is then passed to the receiver. This process of IP fragmentation and recombination is completely transparent to both the sending and receiving applications.
However, at the packet rates associated with typical radar data streams there is a potential problem with typical MTU sizes, which can lead to significant data loss.
The ID field in the IP header in a UDP packet is used by the networking system to recombine fragmented UDP packets. For a typical data rate (PRF) of 1600 messages/sec this ID field will rollover approximately every 41 seconds.
Consider a case where a message is split into 4 fragments by the networking system, but one of those fragments is lost (UDP does not guarantee delivery). The OS will hold the (delivered) three fragments of the packet in a reassembly buffer, waiting for a byte that will never arrive. However, after 41 seconds, the ID field would have wrapped around and a fragment with a ‘correct’ ID will be received. This will complete the packet in the reassembly buffer but will result in a corrupt packet. Furthermore, even though all 4 fragments of the current message were delivered, one of the fragments has now been appropriated for the previous message, meaning the current message is now ‘broken’. This self-propagating problem can lead to the reassembly buffer growing continually. The result is that a small packet loss can cascade into a major data loss and hence loss of radar data.
Fragments are discarded if they are not completed within the Packet Reassembly Timeout. On Windows, this is set at 60 seconds, so PRFs that cause the ID value to wraparound faster than that are susceptible to this problem. On Linux the PRT is configurable; although a balance must be made between the requirements of a lower timeout value for radar distribution, and a higher value that might be necessary for other networking operations.
To minimise this problem, larger video messages can be split into multiple smaller messages, each less than the MTU in size. The receiving client must then re-combine these messages into a single azimuth return.
To illustrate this, the example message of Appendix B will be used.
Given an MTU of 1400, the message will be split into three smaller messages, that each fit completely within the MTU. The messages will be generated as shown in Figure 13. In the figure, fields which do not change between messages are shaded. That is, the fields from the original (un-split) message will be replicated across each of the fragmented messages.
The video block will remain aligned to the (original) block size, so the payload will be the largest whole block size that can be contained within the MTU
The payload size will be constrained by the fixed-sized fields – the message block and video header
The payload size will be further constrained if the message contains a time-of-day and/or special purpose field
Fields such as the time-of-day and special purpose fields are replicated across each fragment message; that is, the time-of-day and any other azimuth-specific data will remain the same for the entire azimuth.