DDL: Data Description Language
Purpose
One of RXTE's innovations is its flexibility in selecting and packaging raw data for telemetry, as reflected in the hundreds of different instrument configurations. To describe these configurations in a compact, comprehensive and comprehensible manner, the Data Description Language (DDL) was devised by Arnold Rots of the RXTE GOF. Specifically, DDL serves three purposes:
-
To enumerate the selection criteria used by the on-board electronics.
To describe the structure of the data in the file.
To convey the meaning of the data.
DDL was devised ab initio as a flexible language extensible to other missions. Its flexibility and terseness do, however, make it easier to gain an understanding by specific example rather than by general exposition.
A typical string of DDL is a concatenation of tokens (denoted by single letters) with assigned values (enclosed in square brackets). For example, the TDDES2 keyword in science array files is used to describe the data in the second column. In the case of the SB_500us_50_249_2s PCA configuration, the value of TDDES2 is a DDL string which looks like this:
These tokens have values enclosed in square brackets and are concatenated with DDL's & symbol which means AND.
Let's look at the token values:
It should be clear from this example that the meaning of a particular DDL string depends on context to some extent. We could associate the token D[0~4] with PCU0-4 because the file contains RXTE PCA data. In fact, this information is contained in the TDDES keyword, the value in this case being O[XTE] & I[PCA] (O and I are the Observatory and Instrument tokens, respectively).
When used for TDDES keywords, DDL enumerates and describes selection criteria as used by the on-board electronics. When used for science event data - specifically for the TEVTB2 keyword - DDL describes how the data are structured in the file. Although DDL does not change meaning with usage, it is advisable to bear this distinction in mind when looking at a DDL string.
In general, when DDL is used for event words, each token corresponds to pieces of the event word template. The size (in bits) of each piece follows the token, enclosed in curly brackets. For example, D[0:4]{3} means that three bits are used to identify one of the five PCU (i.e., 000 for PCU0, 001 for PCU1, 010 for PCU2 etc). In this way, event word templates can be straightforwardly built up from various tokens. However, there are two necessary additions which complicate the template somewhat and which require additional explanation: M-tokens ("markers") and Z-tokens ("enumerators").
In the context of RXTE event words, M-tokens can be thought of as prefixes which distinguish alternative DDL strings. Thus the TEVTB2 keyword may consist of several alternative DDL strings, each prefixed by an M-token. By examining the M-token of a given row, software can tell which alternative event word template describes the structure of the row.
M-tokens work like this. The M-token M[127]{8} means: The first 8 bits are used as a marker: if its value is 127 (01111111), then the immediately following template is the one that applies to the row. Similarly, the M-token M[4]{8} means: The first 8 bits are used as a marker: if its value is 4 (00000100), then the immediately following template is the one that applies to the row. By convention, the first marker in a string identifies a valid event. Its form is M[1]{1}, and, unlike the others in the string, it begins with 1. In practice, when software encounters a 1 in the very first bit of a row, it assumes the "event" template and doesn't interpret the rest of the string as a marker.
Now let's look at an example - the TEVTB2 keyword for the E_1us_1M_0_1s configuration. For clarity, the M-tokens are emboldened and rearranged on the page to be at the beginning of each line:
The way Z-tokens are used is simple. In general:
Basic Syntax: DDL for TDDES Keywords
D[0~4] & E[X1L^X1R^X2L^X2R^X3L^X3R] & C[50~249] & T[0.0;0.00048828125;4096]
It has four tokens:
DDL For Science Event Data
(M[1]{1},D[0:4]{3},T[0.0:0.00390625;9.5367431640625e-07]{12})
(M[127]{8},S[One5]{5},S[FirstFlag]{1},S[SpillFlag]{1},S[Zero1]{1})
(M[1]{8},S[LostEvents0]{8})
(M[2]{8},S[LostEvents1]{8})
(M[4]{8},S[Zero]{7},S[Spillage]{1})^
(M[8]{8},S[Zero]{5},S[ModeSpecific]{3})
The meaning should now be clear, but please note the following, additional points about M-tokens:
D[0:4]{3},E[X1L^X1R^X2L^X2R^X3L^X3R]{6}
where, say, 100100000 would mean an event occurred in the X1L anode of PCU4. But given that there are 30 possible combinations of PCU and anode, using a total of nine bits is perhaps excessive. The purpose of Z-tokens is to enumerate these 30 combinations in a systematic way, making it easier for software to identify anode and PCU combinations - and saving disk space.
Z[A0, A1, A2... AN-1]{M}
means that M bits are reserved in the template to enumerate a list of N items, where N is not greater than 2**M. In our example, the list items are the thirty combinations of PCU and anode:
Z[D[0]&E[X1L],D[0]&E[X1R],D[0]&E[X2L],D[0]&E[X2R],D[0]&E[X3L],D[0]&E[X3R],
D[1]&E[X1L],D[1]&E[X1R],D[1]&E[X2L],D[1]&E[X2R],D[1]&E[X3L],D[1]&E[X3R],
D[2]&E[X1L],D[2]&E[X1R],D[2]&E[X2L],D[2]&E[X2R],D[2]&E[X3L],D[2]&E[X3R],
D[3]&E[X1L],D[3]&E[X1R],D[3]&E[X2L],D[3]&E[X2R],D[3]&E[X3L],D[3]&E[X3R],
D[4]&E[X1L],D[4]&E[X1R],D[4]&E[X2L],D[4]&E[X2R],D[4]&E[X3L],D[4]&E[X3R]]
{5}
The ABC of XTE is written and maintained by the RXTE GOF. Please email xtehelp@athena.gsfc.nasa.gov if you have any questions or comments. This particular page was last modified on Friday, 19-Jun-1998 17:59:41 EDT.
If you have a question about RXTE, please send email to one of our
help desks.