Table of Contents|
July 1, 1994 - Final Report Revision 3
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.
2) In Appendix A, Directory Block Example, the @INTEGER PATTERNS and the @REAL PATTERNS sections were modified to reflect the 9 byte ASCII representations described in (1) above.
3) In Appendix A, Directory Block Example, the file listings following the @FILES line were revised to start in column 3, and to reflect the 5 byte "blocks" listing inside the "( )". These both were previously described in the text and do not represent a change.
4) In Table 6, Format Section of Header Block #1, several modifications were made to account for multiple waveform elements. When there are multiple entries required for a description (i.e. Number of frequency steps) because of multiple elements, each entry follows the descriptor, in order, separated by commas. As an example, if there were 5 waveform elements (3 chirps and 2 fix frequencies) in a file, the number of steps line would look like:
July 16, 1993 - Final Report Revision 1
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.
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
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.
To Table of Contents
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.
KEYWORD CONTENTS FORMAT
KEYWORD CONTENTS FORMAT
KEYWORD CONTENTS FORMAT
To Table of Contents