====== Getting Started With A Simple Example ======

===== A Simple Example =====

<WRAP round info 400px right>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.</WRAP>

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. 

<code>G\106:09;</code>

b. Point of Contact (POC) information.

(1) __Number of POCs__. Identifies the number of Points of contact (POC) to be given.

<code>G\POC\N:1;</code>

(2) __POC Name__. Identifies the name of the POC.

<code>G\POC1-1: Wile E. Coyote;</code>

(3) __POC Agency__. Identifies the agency the named POC is associated with.

<code>G\POC2-1:ACME Corp;</code>

(4) __POC Address__. Identifies the agency address.

<code>G\POC3-1:123 Roadrunner Way;</code>

(5) __POC Telephone__. Identifies the named POC contact number.

<code>G\POC4-1:(555)555-5555;</code>

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.

===== Attribute General Syntax and Semantics =====

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__

<code>G\OD:05-11-2009;</code>

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__
<code>G\DSI-2:AIRCRAFT_DATA;</code>

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.

===== A “Measurement” by any Other Name… =====

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.

===== A “Look and Feel” Example =====


===== Attributes for the Look and Feel Example =====


===== Let’s Talk About Bits =====
 

==== Bit Masks ====

==== Transfer Order ====

==== Fragment Order and Concatenation ====