After frame synchronization, individual measurands are identified according to the frame location. Hardware architectures differ in how they equate and maintain the data/definition relationship. For example, a unique tag may be appended to each raw measurand or data word in what may be called a data flow architecture. This tag remains with the data word unless it is changed; i.e., EU converted, processed, or its bits manipulated. Another scheme rearranges measurands into a new format that is more appropriate for data manipulation, such as sorting the frame into arrays where each array is one or more instances of a single measurand. Another scheme maintains a current value table (CVT), including all or only those measurands of interest.

The decommutator also identifies and extracts embedded asynchronous data stream (EADS) words. Words for each EADS are re-serialized and sent to separate hardware decommutators along with clocks, or if data rates permit, to a general-purpose embedded processor or workstation as contiguous bytes for software decommutation algorithms. All words in the same EADS stream have an identical tag or name. Thus, a major frame may have multiple EADS streams, each destined for an independent decommutator. The IRIG-106 specification calls out a maximum of two EADS streams, although some applications require even more. Analogous to sub-subframes, an EADS stream may itself have EADS stream(s).

Other features often found in hardware decommutators include the ability to support words of different lengths, multiple CRC and parity checking types, and selectable data alignment (MSB/LSB) on a per word basis.

Applications such as monitoring multiple stage rockets or testing multiple systems on one aircraft require changing the set of measurands being monitored. That means the contents of the entire frame will change significantly, if not completely. You could use a single large frame covering all measurands. However, the spectrum required to transmit this larger number of words is too large. Instead, formats are changed as each stage is jettisoned or test points fluctuate. The change occurs on the value of a specific measurand. A multi-format decom will switch to a new format either on the next word or next frame without loss of data. To achieve such a rapid response, the decommutator contains all the possible frame definitions in memory. The IRIG-106 Standard specifies a maximum of 16 formats. Only a few formats are typically used in aircraft flight test and rocket launches. Still, over a hundred formats may be used by a few satellites to accommodate relatively low data rates and multiple modes of operation. Fortunately, data rates are slow and could be accommodated by software decommutation.

The advent of faster general-purpose front-end processors and computers offers a way to provide real-time software decommutation, but at slower data rates than a dedicated hardware decom. Software decommutation offers the advantage of handling the most complex formats and memory required to support instant switching between hundreds of frame formats.

Today’s ground station management software includes a graphical user interface (GUI) to define telemetry stream decommutation content as in the database. Instant feedback occurs when data entry errors are detected (e.g., audible and visual feedback if the words entered for a minor frame contain more bits than what is defined for the frame). To aid in data entry, tools automatically create dummy measurand names, or for a super-commutated frame, create multiple instances of measurands automatically based on frequency, etc.

Flight test programs often deploy multiple airborne and ground systems. Each system has unique data structures to define commutation and decommutation frame layout plus the governing attributes of the data acquisition devices or the ground displays. Each system may use independent databases. And each requires that redundant data be entered in a unique format.

Personnel at large ground stations generally develop their own capability to convert one database format to another. The alternative is manual reentry and testing of each database. Limiting a test program to a single hardware suite is not always possible, which can be quite cumbersome as programs may last many years, precluding use of newer technology. Similar hurdles exist if unique test resources are only available at distant test facilities, each with different equipment (e.g., major differences in operating climates, threat simulators, munition test areas, etc).

To eliminate the tedious task of database re-entry, ground station manufacturers have developed their own set of translators to support their equipment. A few have built this capability around a general-purpose relational database (RDBMS) such as Oracle or Microsoft Access. Recently, IRIG-106 included the definition of the TeleMetry Attributes Transfer Standard (TMATS), an intermediate common format that each ground and airborne system can use for data transfer. Today, a superset of the TMATS specification is required to encompass all the attributes of the airborne and ground systems.