ch9_handbook:getting_started
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| ch9_handbook:getting_started [2014/08/11 14:11] – bob | ch9_handbook:getting_started [2014/08/11 14:27] (current) – bob | ||
|---|---|---|---|
| Line 14: | Line 14: | ||
| So without further adieu, let’s look at an extremely simple TMATS 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. | ||
| + | |||
| + | < | ||
| + | |||
| + | b. Point of Contact (POC) information. | ||
| + | |||
| + | (1) __Number of POCs__. Identifies the number of Points of contact (POC) to be given. | ||
| + | |||
| + | < | ||
| + | |||
| + | (2) __POC Name__. Identifies the name of the POC. | ||
| + | |||
| + | < | ||
| + | |||
| + | (3) __POC Agency__. Identifies the agency the named POC is associated with. | ||
| + | |||
| + | < | ||
| + | |||
| + | (4) __POC Address__. Identifies the agency address. | ||
| + | |||
| + | < | ||
| + | |||
| + | (5) __POC Telephone__. Identifies the named POC contact number. | ||
| + | |||
| + | < | ||
| + | |||
| + | Now, that wasn't so bad, was it? Well, unfortunately, | ||
| + | |||
| + | ===== 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__ | ||
| + | |||
| + | < | ||
| + | |||
| + | 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__ | ||
| + | < | ||
| + | |||
| + | 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, | ||
| + | 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, | ||
| + | |||
| + | 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, | ||
| + | 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, | ||
| + | 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 ==== | ||
| + | |||
ch9_handbook/getting_started.1407784288.txt.gz · Last modified: 2014/08/11 14:11 by bob
