There are three classes of data within a UDF definition, not all of which
need to be present. These are known as: Status (or Mode) Data,
Sensor data, and Ancillary Data. All are equally
accessible. The only real differences are in the timing used and
in its internal usage within the UDF kernel.
Each measurement in a UDF definition is identified by its class and a
location value. Common terminology is to identify a measurand as
Sensor 4 data or Mode 2 data or Ancillary Set 5 Data. It is this
terminology which is used when identifying data within the UDF routines.
That means that it is necessary to have some kind of dictionary between the
above terminology and the measurand represented. This feature is
performed by both the VIDF and PIDF files associated with a UDF definition.
Three fields within the VIDF, the Sensor
Descriptions field, the Status Byte
Descriptions field, and the Ancillary
Data Set Descriptions field, provide one road-map for Sensor, Status,
and Ancillary data respectively. As an example: in the VIDF associated
with the UDF definition IMLQLOOK (IMAGE LENA Quick Look Housekeeping data),
you find that Sensor 8 data corresponds to the HVPS MCP Start Command data
and that UDF Sensor 9 corresponds to the HVPS MCP Stop Command data.
Almost all UDF-based programs present measurement choices in terms of
the physical names found in the VIDF file. This is done by interfacing
with the PIDF file which contains not only the name road-map but also
pointers to algorithms associated with the measurands used to convert the
raw data to physical units. In short an actual user need have no knowledge
of the class or location of a measurand or even that such nuances exist.
Status data has already been alluded to in the initial discussion
on the Header File. This is slowly varying
data which generally represents some aspect of the state of the experiment.
Within the UDF this class of data data can be used to select between various
scaling values that are used in algorithms that convert the raw telemetry
data to physical units. An instrument may have multiple algorithms for
compressing its 18 bit data to 8 bits. The current compression mode is
returned and stored in the UDF as a Status measurement. This allows
the UDF algorithm software to use this value to automatically select
between the different decompression tables which would be stored in the
VIDF file and to use.
Sensor data is the standard form for UDF data measurements. Sensor
data is identified as either scalar, array, (often referred to as
vector UDF documents) or matrix data. Each measurement stored
as sensor data has a start time, measurement duration, and dead time
associated with it. Sensor data cannot be mixed within a VIDF derived
algorithm. There are two reasons for this: timing and availability.
Sensor data within the same data records do not have to have overlap
in time (same start and stop time), and neither do all of the defined
sensors within a given UDF definition need to be returned within a given
data record.
Ancillary Data is similar to Sensor with the exception
that it lacks some of the timing fields. Unlike Sensor data
any subset of the defined Ancillary Data can be used in a
VIDF derived algorithm. The corollary to this is that all of the
Ancillary data defined under a UDF definition must be present
in each UDF Data record.
There are three classes of Ancillary Data: preface ancillary data,
general ancillary data, and sensor ancillary data. Preface Ancillary Data
occur once per UDF data record, are valid for the entire time span covered
by the data record and can only be scalar data. General Ancillary Data
occur once per sensor set, are valid for
the time span covered by the sensor set, and are restricted to be scalar
measurements. Note: there is no difference between Preface Ancillary
Data and General Ancillary data if a UDF data record consists of only a single
sensor set. Sensor Ancillary Data are associated with the individual
measurements within the UDF Data Record, are valid only for the one
instance of the measurement they are associated with, and can be an
array of values if the sensor they are associated with is an array of
values.