Note: Areas enclosed by dotted lines indicate logical groupings of physical data blocks. Areas enclosed by solid lines indicate physical, defined data blocks.
Below are definitions for the various data elements (gate, cell ray, sweep, volume etc.) and format components (block, descriptor, header, etc.).
Every tape should begin with a file containing one or more comment blocks. The first comment block should contain the ASCII 6-character tape identifier "DORADE" starting in character one or two of the data part of the comment block (the first character can be a new line). This comment block or subsequent comment blocks should also contain a description of the tape format (i.e., something very similar to what you are now reading). If a compression scheme is used, it should be described. The FORTRAN or "C" code used to decompress the data should also be written here.
We recommend that a flag of -999 (for 2- and 4-byte integer entries), -256 (for 1-byte integer entries), or -999.0 (for real entries) be used to denote all entries not applicable, missing data, bad data or deleted data. Positive Doppler velocity is defined as velocity receding from the aircraft.
All blocks (user defined or defined here) begin with four ASCII characters describing the block and then a 32-bit integer giving the length of the block in bytes. The lengths of all blocks or descriptors should be evenly divisible by 4.
All floating point numbers follow the IEEE 32 bit floating point standard. All 4 byte numbers (floats or 32 bit integers) must begin on a boundary that is evenly divisible by 4. The use of place holders should be adopted to accomplish this. All integers should be in "Big Endin" notation (the first byte is the most significant byte).
In general a volume is a file. On a standard 9-track tape or an Exabyte tape, a volume should always begin and end with a volume header. The end is denoted with a file marker. When recording on media with variable physical record lengths, the size of the largest physical record should be documented in the fifth entry in the volume descriptor (bytes 12-15). A volume contains many sweeps of data. It can be a leg (in airborne radar), a sector scan (in ground based radars) or any other user selected block of data. A volume always begins and ends with identical volume headers. A volume may contain data from multiple sensors. For example, the fore and aft radars in ELDORA/ASTRAIA. To define a volume is relatively straight forward for ground based radar, since a well defined scan sequence (either from bottom to top in the PPI mode of from left to right in the RHI mode) is usually in place. This is not the case for an airborne Doppler radar where a typical straight-line leg can last 30 minutes or more. In other flight patterns such as a circular pattern around a hurricane eye wall, it is very difficult to define a "leg" or volume. Therefore, it is the data producer's responsibility to define a block of data which is suitable to work with as a volume.
A mandatory volume header is always the first (and last) record of a volume. It is written whenever there is a change in the radar parameters (e.g., PRT, cell spacing, or calibration) and at the beginning and end of a mission. A user would normally not want to combine data across a mandatory volume header, or else do so with caution. The volume header contains a volume descriptor and as many sensor descriptors as there are different sensors. In large volumes it is acceptable to place multiple, identical intermediate volume headers (there should always be two volume headers with a file mark in between them) in other locations in the volume for redundancy and speed of access. The volume number should remain the same for all intermediate volume headers. Analysis software should be written to process data across intermediate volume headers with ease.
A sensor descriptor is a logical grouping of descriptors that define specifically how the data from a particular sensor is recorded on the media. Many of these sensors will be "radars", and hence a specific sensor descriptor for radars is defined in this document. It is possible, however, that the media may also contain data from other sensors. For example, the ELDORA/ASTRAIA field tapes will contain data from the in-situ measurement system. The data format for each of these other sensors should be described with a unique sensor descriptor.
A sweep record should be considered as a logical means of assembling data that may very well consist of multiple physical records on a computer tape. However, a ray of data should not cross physical boundaries. All sweep records should start on a physical boundary, and the physical records inside of the sweep record should always contain an integer number of data rays. In this way, there is a guarantee that the first four characters of all physical records on the media will have an identifier. The sweep number in the sweep info block should be the sequence number from the beginning of the volume.
The correction factors should be applied to the various parameters before using them. This permits adjustments to the correction factors without having to regenerate the whole tape or dataset. The numbers in this descriptor should be added (mathematically) to the data that is written in the exchange format. Some of the correction factors in this descriptor may not be applicable to all radars.
A data ray will always contain a ray info block and the data from every parameter associated with the radar that created the ray. For moving platform radars, a platform info block has been defined that contains all parameters associated with the calculation of antenna location and pointing angles.