The following VIDF fields describe the UDF ancillary data sets. All are array fields. They are used by the UDF kernel software when obtaining and processing ancillary UDF data and when setting pointers into the UDF data record to the different data types.
NOTE: There are significant differences in the Ancillary Data definitions between UDF V2.1 and UDF V2.2. Changes in this area were the major outcome of the version increase. Under UDF V2.1 there were only two ancillary data set types: array and sensor. In access and in usage the two designations were indistinguishable.
With UDF V2.2 the array ancillary data set type was deprecated and all ancillary data sets which had their type set as array are now treated as having a type of sensor. In addition, two additional ancillary data types were added: preface and general.
The differences between the three UDF V2.2 ancillary data set types is their scope. Preface ancillary data targets all data within a data record and are laid down once per UDF data record. General ancillary data targets all data within a sensor set and are laid down once per sensor set. Sensor ancillary data targets only data from a specific sensor and are laid down once with each occurrence of the sensor. The base storage data word length associated with the three ancillary data type may be different, but is constant within any one designation. Preface and general ancillary data sets support only scalar data. Sensor ancillary data sets support array data, the array length being any value up to the number of measurements associated with a sensor in a particular sensor set.
The order in which the ancillary data sets are listed in the VIDF is the order in which they are laid down in the UDF data records. The first listed preface ancillary data set corresponds to the first data laid down in the preface area, the second to the next data set laid down, and so on. In this way the various types of ancillary data sets can be listed intermixed so long as the relative order of each is preserved.
Data Sets
, this field contains information on how the ancillary data maps to the UDF sensor data. If there are no defined UDF ancillary data sets in this UDF definition then this field is undefined and is entered in the VIDF as a null line.The mapping information is actively used by the UDF kernel software only when: 1) the Ancillary Type field indicates that the ancillary set modifies sensor data; and 2) the UDF Header Record indicates that there are multiple measurements stored in a sensor set under each sensor. The values could either be an array of values (as for scalar or matrix sensors) or multiple scalar measurements.
The UDF kernel software builds a 1-1 correspondence between the sensor data and ancillary data. It uses this field to determine the number of elements in a ancillary data set and how they map to the sensor data. What the Ancillary Mapping values represent are the number of sensor array elements mapped to by each value in an ancillary data set array. If there is only one element in the ancillary sensor set the mapping value should be set to 0 indicating that the one ancillary set value maps to all of the sensor array elements.
The number of elements within a ancillary data is not given directly within the VIDF but is computed by
if (MapVal > 0)
{
Extra = (CurArrayLen % MapVal == 0) ? 0 : 1
N = CurArrayLen/MapVal + Extra
}
else
N = CurArrayLen
where
| MapVal | = | Ancillary Data Set Ancillary Mapping Value |
| CurArrayLen | = | Current Sensor Array Length |
| N | = | Number of Ancillary Data Set Values |
The allows the number of data values associated with an ancillary data set to vary with the length of the returned sensor.
The ancillary mapping field begins with the array designation line: m followed by the input N M. Here N is the total number of entries and should be set to the value given in the Number Of Ancillary Data Sets field and M is the number of entries given on each line. Each of the following N lines begins with the line format s followed by M entries (except the last line which may have less). An optional comment field may be added to the end of each line.
Sample ANCILLARY MAPPING field:m 4 4 /* Ancillary Mapping */ s 0 0 1 2 /* 000-003 */
Consider the following two examples.
An array sensor has a length of 19 and has a sensor ancillary data set associated with it which has an Ancillary Mapping value of 3. Each element in the ancillary data set will then apply to 3 elements in the sensor data array. The first ancillary data value will map to the first 3 array elements, the next ancillary data value to the next 3 array elements and so on. There must then be 7 elements in the ancillary data set with the last ancillary value acting only on the last sensor array element.
A scalar sensor has 12 successive measurements in each sensor set and has a sensor ancillary data set associated with it which has an Ancillary Mapping value of 0. There is then only one ancillary data value in the ancillary data set and this will be applied to each of the 12 sensor measurements. Had the mapping value been set to 1 there would have been 12 values in the ancillary data set, one for each of the 12 measurements.
An array field of length Number Of Ancillary Data Sets, this field holds the bit lengths of the data associated with each of the defined ancillary data sets. If there are no defined UDF ancillary data sets in this UDF definition then this field is undefined and is entered in the VIDF as a null line.
The bit length values can be both positive or negative with the absolute value being the true bit length for the ancillary data set. A positive value indicates that the ancillary data set values are stored as unsigned integers whereas a negative value indicates that they are stored as signed integers.
NOTE: Under UDF V2.1 ancillary data sets can be stored on 1, 2, 4, 8, 16, or 32 bit boundaries. In V2.2 data packing on 1, 2, and 4 bit boundaries has been deprecated and is no longer supported. It is, however, still supported for UDF's with version V2.1 for backwards compatibility.
The most efficient method to use in dealing with non-integral word length data under UDF2.2 is to pack the data into either an 8, 16 or 32 bit data word and then use a VIDF defined algorithm to strip out the individual data word. This allows multiple word lenght data to be packed into a single UDF data word.
With V2.2 the ancillary data sets associated with the three ancillary types may be stored on different byte boundaries, none of which need match the boundary used by the UDF sensor data. Within any one ancillary data type, however, the storage length is fixed. The storage length of each ancillary data type is the bit length which will contain the maximum defined ancillary data bit length for that type.
As an example, if the maximum defined bit length of all of the UDF defined ancillary data sets of a given type is 9, then the base UDF word length for that data is 16 bits. That is, the data is stored in the UDF on 16 bit boundaries.
The UDF kernel software makes use of the bit length fields in determining both the sign bit location in signed data and the number of elements to retrieve from lookup tables which are being used to operate on raw ancillary data. It is also used to determine the storage size used for the different ancillary set types defined in the UDF definition.
The ancillary data bit length field begins with the array designation line: m followed by the input N M. Here N is the total number of entries and should be set to the value given in the Number Of Ancillary Data Sets field and M is the number of entries given on each line. Each of the following N lines begins with the line format b followed by M entries (except the last line which may have less). An optional comment field may be added to the end of each line.
Sample ANCILLARY DATA BIT ENGTH field:m 4 4 /* Ancillary Bit Len */ b 7 -8 5 8 /* 000-003 */
An array field of length Number Of Ancillary Data Sets, this field holds the type indicators associated with each of the defined ancillary data sets. If there are no defined UDF ancillary data sets in this UDF definition then this field is undefined and is entered in the VIDF as a null line.
The ancillary type definitions are listed in the table below.
| ANCILLARY TYPES VALUES | |
|---|---|
| VALUE | DEFINITION |
| 0 | Sensor |
| 1 | Array: Deprecated |
| 2 | General |
| 3 | Preface |
The differences between the three designations is their scope. Preface ancillary data targets all data within a data record and is laid down once per UDF data record. General ancillary data targets all data within a sensor set and is laid down once per sensor set. Sensor ancillary data targets only data from a specific sensor and is laid down once with each occurrence of the sensor. All three designations may be stored on different word length boundaries.
The ancillary data set type field begins with the array designation line: m followed by the input N M. Here N is the total number of entries and should be set to the value given in the Number Of Ancillary Data Sets field and M is the number of entries given on each line. Each of the following N lines begins with the line format b followed by M entries (except the last line which may have less). An optional comment field may be added to the end of each line.
Sample ANCILLARY TYPE field:m 4 4 /* Ancillary Types */ s 0 2 2 3 /* 000-003 */