A note about XML: This handbook uses the original syntax of TMATS which was developed before XML was in general use. Since then, an XML version of TMATS has been published. The development of the XML version took a “transliteration” approach. That is, for the most part, there is a one-to-one mapping between the keywords in both syntaxes. Appendix A discusses the differences in more detail. But for now, this document will focus on the concepts and basic functionality provided by both.
If you are reading this, then you probably have some idea what the Telemetry Attributes Transfer Standard (TMATS) is; but let’s cover the basics, just in case. Let’s start with “telemetry,“ which is the process of remotely collecting data. The normal application of TMATS is for telemetry being transmitted using a radio signal from a test vehicle to a ground station where people are using the data to monitor what’s happening on the vehicle. As the word “attributes” implies, TMATS is used to describe this signal.
At a very basic level, the two main things to describe are the signal characteristics and the details necessary to decipher the digitally encoded data being carried by that signal. The description of a particular signal is provided using a set of attributes – in the form of code name:value pairs – in an ASCII text file.
So without further adieu, let’s look at an extremely simple TMATS file.
a. RCC IRIG 106 Revision Level. Identifies the RCC IRIG 106 version of TMATS used to generate the file. The format to describe a Revision Level is 106-xx, with xx as the last two digits of the year.
G\106:09;
b. Point of Contact (POC) information.
(1) Number of POCs. Identifies the number of Points of contact (POC) to be given.
G\POC\N:1;
(2) POC Name. Identifies the name of the POC.
G\POC1-1: Wile E. Coyote;
(3) POC Agency. Identifies the agency the named POC is associated with.
G\POC2-1:ACME Corp;
(4) POC Address. Identifies the agency address.
G\POC3-1:123 Roadrunner Way;
(5) POC Telephone. Identifies the named POC contact number.
G\POC4-1:(555)555-5555;
Now, that wasn't so bad, was it? Well, unfortunately, this example is not very useful because it does not actually describe anything … but it’s a start.
Before we consider a more meaningful example, let's get a general idea of what TMATS should look like. Each TMATS attribute consists of a unique code name and a data item. The code name appears first, delimited by a colon. The data item follows, delimited by a semicolon. Thus, an attribute appears as A:B; - where “A” is the code name and “B” is the data item.
There are two basic types of attribute code names: single entry and multiple entry. Single entry attributes are those for which there is only one code name and one data item. Multiple entry attributes have multiple indexed code names and data items, each of which corresponds to an index number. These attribute types allow for lists of like items, such as measurements.
a. Single Entry Example
G\OD:05-11-2009;
The code name is “G\OD” which is “Origination Date”.
The data item is “05-11-2009” which indicates May 11, 2009.
b. Multiple Entry Example
G\DSI-2:AIRCRAFT_DATA;
The code name is “G\DSI-2” which is “Data Source ID’.
The index “2” specifies that this is the second data source ID.
The data item is “Aircraft Data” which is the identification of this data source.
Numeric values for data items may be either integer or decimal. Scientific notation is allowed only for those attributes specifically defined for its use. For alphanumeric data items, including keywords, either upper or lower case is allowed; TMATS is not case sensitive. Semicolons are not allowed in any data item, including comments. Leading, trailing, and embedded blanks are assumed to be intentional and must be accounted for if they appear within code names or data items. Carriage return (CR) and line feed (LF) may be used to improve readability.
You might not believe the number of person years that have been spent discussing the definition of “measurement.” Other words that are related, or possibly mean the same thing depending on who you ask, are: measurand, sample, parameter, and derived measurement. So let’s look at the basic process to illustrate.
For this example, assume some raw phenomenon exists such as temperature, pressure or velocity. You can also talk about discrete settings such as weight on wheels or other settings or values that are not necessarily physical phenomena. But let’s start with just real world things that we tend to measure. A sensor is placed somewhere to “measure” this phenomenon. Most sensors are analog devices that “measure” the phenomenon and produce a voltage output (actually, millivolt output). An analog to digital converter (ADC) translates this voltage into a set of discrete bits. Usually, these bits are the ones that are telemetered. These bits are then converted using some algorithm into engineering units (EU) such as degrees Fahrenheit or furlongs per fortnight. The EU data is what engineers like to examine. Now consider that there isn’t just one sample of each item, but rather a series of samples over time.
So there are essentially four things involved here: the raw phenomenon, the voltage output of the sensor, the raw digitized data value, and the EU data. Well, there is something of a fifth thing in the sense that values of different phenomena might be used to “derive” another “measurement.” For example, a series of position and time samples might be used to derive velocity. Then the sixth thing is the full set of samples of a given phenomenon over time. Which of these is a measurement, sample, parameter, measurand, etc.?
A related terminology issue is the concept of “raw” data. Sticking our neck out a little, we’ll say that this usually implies the non-EU digitized bits that are telemetered. But the term can be moved in either direction. That is, someone might refer to the “raw signal” meaning the voltage output of the sensor or, as used above, the “raw phenomenon.” Or, occasionally, the initial EU data might be considered “raw” since the ultimate analysis is usually presented in some form derived from these low level measurements. To add to the confusion, there are some people that talk about “generations” of data, implying that the initial digitized sensor output is a different generation from the EU or derived calculations.
In practice, the words measurement, measurand, sample, and parameter are often used interchangeably. The use of the term “raw” is probably sensitive to context. However, there are people and systems that make subtle distinctions between these words, so one must be careful. This handbook will use the word “measurement” for all of these words, and the word “raw” will not be used in this document.