RADAR CROSS SECTION
COMMON DATA FORMAT
REVISION 3
01 July, 1994

Download Entire Document
(MS Word, 336KB)
There are minor editorial differences between
the on-line version and the download version.
Table of Contents
  • Revision History
  • Introduction
  • Philosophy
  • Common Data Format
  • Appendix A - Directory Block Example
  • Appendix B - Header Block Example
  • Appendix C - Keyword List for Header Parameters
  • Appendix D - Program CDF Pattern
  • Appendix E - Program CDF Header
  • Appendix F - Existing Site Formats:
    David Taylor Research Center, Santa Cruz
    Holloman AFB RATSCAT/RAMS Format #1 (Monostatic)
    Holloman AFB RATSCAT/RAMS Format #2 (RAMS ASCII)
    Holloman AFB RATSCAT/RAMS Format #3 (RAMS Raw)
    White Sands Missile Range
    Eglin AFB
    NAWCWPNS, Pt. Mugu
    Aberdeen Proving Ground
    Air Force Lab - OSU Format
    Air Force Lab - LINTEK Format
    NAWCWPNS, China Lake
    Naval Ocean Systems Center - Standard
    Naval Ocean Systems Center - Wideband
    Patuxent Naval Air Warfare Center - Tape
    Patuxent Naval Air Warfare Center - Bernoulli
    REVISION HISTORY


    July 1, 1994 - Final Report Revision 3
      1) The keywords IREAL and QREAL were added to the list of allowable keywords for the @DATA and @CALIBRATION sections of the header block to allow for the storage of real I and Q values.
      2) Increased the starting block number value (contained within square brackets []) for each file in the directory from five (5) to six (6) bytes.
      3) Added MEDIA_NAME to the directory block.
      4) Added requirement that the @DIRECTORY BLOCK #1 title line start at byte #1 of the first directory block.
      5) Added requirement that the @HEADER BLOCK #1 title line start at byte #1 of the first header block.
      6) Now allow header parameter strings to exceed eighty (80) characters in length. Although each physical line in the header must still not exceed eighty (80) characters, if more are required for a particular parameter, a line can now be continued by inserting a backslash ("\")<CR><LF> to indicate a line break and continuing on the next line.

    February 1, 1994 - Final Report Revision 2
    During the project to write software to translate data at NAWC China Lake, CA from the elan format to the Common Data Format (CDF), some minor inaccuracies in this document were discovered. There were also some areas where clarification seemed necessary. The revisions are listed below.

    July 16, 1993 - Final Report Revision 1
      1) Allow for an entire "multi-element" frequency table to be stored in a single data record. These elements can be fixed frequencies, step chirps, or any combination of the two. They must, however, be interleaved on an element-by-element basis as opposed to a sample-by-sample basis.
      2) Remove restriction of allowing a maximum of 4 range gates. The list of header keywords now allows for a range to each range gate to be specified or else a range to range gate 1 and a RSS value.
      3) Added a Burst Repitition Factor to the header keyword list.
      4) The size of the starting block number in the directory was increased from 5 bytes (5 digits) to 6 bytes (6 digits). This was done for future growth of storage media.


    June 08, 1993 - Final Report
    The following changes were made to the CDF specification as a result of comments received after review of the preliminary document. The main thrust of the modifications is to make the CDF even more flexible, allowing the writer complete freedom in how the data are stored. This summary is only used to outline the changes made. Details of the new CDF specification are contained in the final report.
      1) Allow the use of IEEE short floating point numbers instead of requiring the use of scaled integers. Remove the scaling factor from the directory block. Add a "pattern" section to the directory block (as we did with INTEGERS) to allow for machine independence. It will be the writer's responsibility to convert into IEEE format if their machine uses a different standard for the representation of floating point numbers.

      2) Allow for the storage of multiple range gates in a single file. If both multiple channels and multiple range gates, format dictates that data are stored as channels followed by range gates. This means the data are written:
      RG(1)CHN(1), RG(1)CHN(2), RG(2)CHN(1), RG(2)CHN(2)...

      3) Allow for an entire step chirp to be stored in a single data record. Still include the restriction of only a single frequency "element" in a data record however.

      4) Allow the user to completely specify the number of dynamic parameters and the number of position variables in each data record. No longer require a single dynamic parameter and three position values in each record.

      5) Define a set of allowable keywords that MUST be used in the @PARAMETERS section of the header. Unique parameters that are not specified must be placed in the @CUSTOMER section with the keyword agreed upon by both parties.

      6) Define a standard for the particular format and units each type of parameter would use. Examples would be:

      AZIMUTH : INTEGER in BAMS
      ELEVATION : INTEGER in BAMS
      ROLL : REAL in DEGREES
      PITCH : REAL in DEGREES
      RCS : REAL in dBsm
      .
      .
      .
      7) The @POSITION, @DATA and @CALIBRATION sections will now list only those variables being stored. It makes no sense placing the entire list of keywords in each section and requiring the writer to "mark" those being used. Each section will also have an allowable list of keywords specified.


    To Table of Contents

    I. INTRODUCTION
    This report is the result of a need by the tri-services RCS Measurement Working Group to standardize the operations of the government-owned RCS ranges in the United States. Because each site was custom designed and built, the format of the output media was optimized for a particular site or customer demands. Additionally, differences in the radar and computer hardware, as well as type and amount of pre-processing performed on the data during collection, lead to differences in the actual format of the collected data. Format differences impact the number of bytes written for each sample, alignment of the bytes in each sample and the type of normalization performed prior to the output of the data. The type of measurements performed at each range also affect what the actual data samples contain. These differences between radar systems create a situation whereby it is very difficult for one site to process data collected at another site. The only feasible method for the various radar ranges to share data was determined to be in a new format which all the sites could read and write. This would prevent each RCS range from having to develop multiple translation algorithms for the other ranges' data. Only a single set of translation routines would be required -- one which converts the new common data format (CDF) into the site's current format, and one which converts a site's current format into the CDF. These two algorithms would be very similar. Enough information and detail of the CDF would be provided to allow each site to develop the translation algorithm in-house or to have a third-party vendor write the necessary software.

    The design of the Common Data Format would first require a thorough understanding of each of the current data formats involved. A study was undertaken to review the operations and formats of all the government RCS ranges. This involved two tasks - a questionnaire and a site survey. The questionnaire was designed to both detail the general capabilities of each facility and to establish the types of data (formats) being produced. The questionnaires were reviewed and follow-up site visits were scheduled to allow for more detailed discussions regarding these two areas. Also, as ideas for the CDF began to form, these were presented to the participants during the site visits to solicit comments and ideas. Many of these inputs were helpful in the final design. These tasks provided a clearer understanding of the data requirements for each radar site. This would be necessary if a common format for all the ranges was to be developed.

    The radar ranges which participated in this study are listed in Table 1. A site visit was conducted at each facility except David Taylor Research Center, Santa Cruz Island. The Carderock location was used for this visit.

    Table 1
    AIR FORCE
  • Eglin AFB
  • Holloman AFB / RATSCAT
  • Holloman AFB / RAMS
  • Wright Patterson AFB
    ARMY
  • Aberdeen Proving Ground
  • White Sands Missile Range
    NAVY
  • David Taylor Research Center, Santa Cruz Island
  • David Taylor Research Center, Carderock
  • NAWCWPNS, China Lake
  • NAWCWPNS, Pt. Mugu
  • Patuxent Naval Air Test Center
  • Naval Ocean Systems Center

    To Table of Contents

    II. PHILOSOPHY
    The design of the Common Data Format (CDF) evolved from a collection of philosophical ideas and goals into a series of rules defining a specification. These rules were intended to provide a rigid framework for implementors to work within when generating a CDF media. In an attempt to provide a high level of flexibility in this structure, which was a primary goal in the design, the CDF was created as a series of "user-defined bins" which need only be described, both in size and content, using the appropriate keywords. A directory block must be the first section on any CDF media. Flexibility is maintained by allowing a variable number of directory blocks, as long as the number of directory blocks is defined and identified in the leading directory block. The same holds true for the header blocks. The CDF structure requires that a header block containing certain variables lead off every data file. Flexibility is maintained again by allowing multiple header blocks. Each header variable must adhere to a strict format. Part of this format is an ASCII identifier, therefore any number of customer-specific parameters can be added in the customer area of the header. The different sections within both the directory and header are separated by the "@" string delimiters. If there is frequency calibration information for the data in a file, these must follow the last header block. The flexibility is maintained by allowing different types of calibration data to be used. The implementor is required to specify, again using appropriate keywords, the type of data being used in the @CALIBRATION list in the header.

    The data section of each file is a collection of data records. These data records contain up to three sub-records which must be written in a specific order and format. Samples within these sub-records are used to store dynamic parameters, target position information and the actual radar data (either raw or processed). Flexibility is maintained by allowing unnecessary sub-records to be omitted and by permitting the included sub-records to be variable in size and content. The sub-records are actually "bins" of a user-defined size which can be filled with user-specified information. The size and content of these bins are defined in the header of each file. The result is that, while adhering to a rigid structure, the CDF can be used to efficiently store a large variety of data types. Table 2 lists all the currently accepted keywords (including units) which can be used to specify the type of data stored in the POSITION and DATA sub-records. Also shown are the choices CALIBRATION data. The appropriate identification strings are written in the @POSITION, @DATA and @CALIBRATION sections of the header.

    The Common Data Format specification is designed to be a rigid framework of user-defined data. This makes it flexible enough to accommodate the largest possible number of radar ranges and existing formats. A single translator program can read all generated CDF media. There is enough configuration information provided in the directory and header blocks to allow for the software to "modify" itself during run-time. This should allow data to be shared between the ranges, which was the goal of the CDF. In the event that this flexible structure breaks down at some later date, there is a version number in the directory which can be utilized to allow for "major" changes to the format in the future.

    Table 2
    ALLOWED KEYWORDS
    @DATA
    KEYWORD CONTENTS FORMAT
    I I in A/D Levels INTEGER
    Q Q in A/D Levels INTEGER
    IREAL I in A/D Levels REAL
    QREAL Q in A/D Levels REAL
    RCS RCS in dBsm REAL
    AMPLITUDE Amplitude REAL
    PHASE Phase in Degrees REAL
    DOPPLER Doppler in kHz REAL
    GAIN Antenna Gain in dBi REAL

    @ POSITION
    KEYWORD CONTENTS FORMAT
    AZIMUTH Azimuth in BAMS INTEGER
    ELEVATION Elevation in BAMS INTEGER
    RANGE Range in Meters REAL
    ROLL Roll in Degrees REAL
    PITCH Pitch in Degrees REAL
    HEADING Heading in Degrees REAL
    TIME Time in Seconds REAL
    INCHES Location in Inches REAL

    @CALIBRATION
    KEYWORD CONTENTS FORMAT
    I I in A/D Levels INTEGER
    Q Q in A/D Levels INTEGER
    IREAL I in A/D Levels REAL
    QREAL Q in A/D Levels REAL
    AMPLITUDE Amplitude REAL
    PHASE Phase in Degrees REAL

    To Table of Contents




  • This temporary RCSweb site developed and hosted by cclogo.gif (450 bytes)CC-Link.
    Updated 11 March 1998 by Roger Davis.