User Tools

Site Tools


CR 80

Change Request Number CR 0080 (To be assigned by CM Manager)
TG Task Number (assigned by the CM Manager)
Requester/Email/Phone Christian Rueck
+49 (89) 62 70 79 61
Govt. Sponsor/Email/Phone
Date Submitted 22nd Jan 2014
Relevant Section Number(s) Many
Description Clarify various issues from IRIG106-13 in IRIG 106-15. The issues are listed at the end of this document
Justification Missing specifications may lead to recorder vendors not supporting these features or deviating vendor specific solutions. SW vendors must deal with a potentially unlimited range of recorder vendor interpretations to claim CH10 compliance
Requirement Voting Result Requirement comments due by:
Govt voting on requirements due by:
Results: TBD
Technical Solution Voting Result Comments on technical solution due by:
Govt voting on technical solution due by:
Results: TBD
Log (Date - POC):

1 Secondary header times according chapter 4 binary time

Chapter 10 can use Chapter 4 binary weighted time in secondary headers and within intra packet time stamps. What is the definition for binary weighted time. Is the days component of the time stamp related to the Julian date (like BCD time stamps), the IRIG day of year or something else?

2 Analog data type

1. Page 10-58 (item “Totchan”) states that analog subchannels may be disabled. The packet contains the subchannel's channel specific data words in sequence but leaves out disabled channels. Therefore it is essential to know which subchannels are disabled. The section also states that the TMATS record will contain the subchannel numbers of the active subchannels.

The TMATS specification (page 9-32) states the total number of subchannels (R-x\ACH\N) but it neither includes an attribute for the number of each subchannel nor does it have an indication that one of the defined subchannels is disabled.

The only way I could think of to indicate a disabled subchannel is to leave out the definition of the attributes for some of the indices in the multiple-entry attributes (e.g. defining R-x\ADL-n-m not for all m between 1..8). However this would really be an individual way of doing it and would not help in supporting files from different vendors with different ideas on this.

2. The TMATS attribute for the Analog channels: “Measurement Transfer Order” (R-x\AMTO-n-m on page 9-32) defines the option “Default” (other options: LSB or MSB first). Where is the default defined?

Other similar attributes (like D-x\WFT-y-n-m-e on page 9-63) have a note on it that says “AS SPECIFIED IN TABLE 9-5, WORD TRANSFER ORDER”. This defines a default transfer order in the attribute P-d\F2 (page 9-49). However this is a PCM attribute and is most likely undefined if no PCM is used. Also the analog channel attribute does not refer to this attribute.

3. Analog channel can have audio data inside. In this case they define an Audio format (R-x\AVF-n-m on page 9-33). This format can also be something like “WAV”. Analog subchannels are taking samples of physical values at equidistant times. A WAV format (and most likely also a few of the others) contain meta data (like headers) that is not related to the samples but indicates things like used channels, sample rate, bit length etc. How does this fit in the approach of taking equidistant samples of a physical value? While “sampling” the metadata, no physical values would be sampled.

4. Analog subchannels define a bit mask (R-x\AMSK-n-m on page 9-32). I assume that this always has the length of the data (R-x\ADL-n-m same page). In this case a mask makes only sense if it can be discontinuous (e.g. not always 111111 but also 110111). How are these discontinuous masks handled? Are the 0 bits to be ignored so a mask like 110111 really forms a 5 bit value by shifting the upper two bits one to the right?

3 UART data type

The UART data type can have 7-9 bit data words (defined by TMATS R-x\UCB-n-m). Chapter 10 places the data into the packet byte by byte. This works well as long as the data is 8-bit wide. For all other situations the question arises, if the data is packed or unpacked (in the sense of PCM or analog data packets). Also this would result in filler bits (are they MSB or LSB aligned?). It is also not clearly specified if the parity bit is included in the stored data or not. Assumption is that currently the recorder validates the parity, strips the parity bit and sets the parity error flag in the intra packet header if needed.

I don’t require a 7 or 9 bit mode but as long as this option stays in IRIG 106 it should be specified. I provided this proposal to Anthony Wirtz:

  • Specify parity is not included in stored data.
  • Introduce a mode bit 30 in the channel specific data word to indicate a packed and unpacked mode like for analog data type. Since no padding bits have been defined before it is likely that existing recorder vendors used a packed format (if 7 or 9 bit data words are used at all). Therefore use packed mode as default (i.e. coded as 0). The most reasonable implementation for 7 and 9 bit words with the current definition would have been to sequentially place all data words between the intra packet headers without any spaces. This would result in a possible MSB padding of the last byte.
  • Both modes shall use MSB 0-padding
  • The new definition would be compatible with existing 8 bit implementations. For 7 or 9 bit it would be compatible with the most reasonable implementation under the current definition I could make up. In effect most likely no changes on vendor side are required except to support new formats.

As an alternative always use packed mode but define this. This would avoid the unpacked option with possibly much wasted memory (for 9-bit words). It would also safe the only available reserved bit in the CSDW.

4 PCM data type

I have not yet been able to use the PCM data type due to many available options and often unclear specification. I would suggest that at least the programming handbook provides some more details here. Some unclear issues I have discovered:

1. The PCM channel specific data word has a “sync offset” that is only valid for unpacked mode. Shouldn’t this also be valid for packed mode, because this is also minor frame synchronized? The programming handbook also claims that this is only valid for packed mode (already reported to Paul Ferril for correction).

2. There are contradicting statements about bit alignment. Page 10-33 says “Word unpacking will force the LSB of each word to be aligned on a 16-bit boundary”. 10-34 (section c) says “In unpacked mode, packing is disabled and each data word is padded with the number of filler bits necessary to align the first bit of each word with the next 16-bit boundary in the packet”. The first sentence speaks about the LSB the second about the “first bit” which may be the LSB or MSB depending on the word transfer order defined by P-d\F2.

3. TMATS attribute P-d\D6 (Data direction) allows data to appear in reversed time sequence. What is reversed? Each word, each minor or major frame or the whole stream?

4. Are parity bits included in the recorded data (if P-d\F3 indicated use of parity) and if yes, are they included in the common word length (P-d\F1) or are they on top?

5. P-d\MFW1-n (Word number (minor frame format definition)) says “Word position #n in a minor frame, or for class II systems, the position in the defined frame.”. The variable “n” appears in the attribute name and within its description. Are both the same? If yes, then the attribute is useless because the index of the word “n” is already provided when defining P-d\MFW2-n.

If I have a 5 bit word as word 12, the definition according to the spec would look like this:


This conveys no more information than the simpler definition


So I expect the specification means something different.

6. In case word length >16 (or >32) bit are used in 16 (32) bit aligned unpacked mode, the placement of the bits is undefined.


Christian Rueck, 2014/06/18 02:52, 2014/06/18 02:57

Paul Ferrill had an answer from Jon Morgan of the Datamux committee on 4.5. which implies that the two “n” variables are not the same.

Therefore the text in Chapter 9 should be changed from:

WORD NUMBER P-d\MFW1-n *RO-CH10-PAK* Word position #n in a minor frame, or for class II systems, the position in the defined frame. Word position 1 follows the synchronization pattern. MFS 4.
NUMBER OF BITS IN WORD P-d\MFW2-n *RO-CH10-PAK* The number of bits in word position #n. If default value, do not include. MFS 2.


WORD NUMBER P-d\MFW1-n *RO-CH10-PAK* Word position #n in a minor frame, or for class II systems, the position in the defined frame. Word position 1 follows the synchronization pattern. MFS 4.
NUMBER OF BITS IN WORD P-d\MFW2-n *RO-CH10-PAK* The number of bits in word position defined by P-d\MFW1-n. If default value, do not include. MFS 2.
Christian Rueck, 2014/05/15 02:40

Mark Buckley mailed a comment on 2nd May 2014:

1. The requirements for a secondary absolute time format was from PAX River (~2004) even though the majority of the R&R committee at the time argued against. We stated absolute time for any given RTC value can be synthesized from absolute time provided in the time packet. It is a GOV call to remove PAX River’s requirement. In all honesty the time has come for a Chapter 10 V2 header which has 64 bits for a 10/100/1000 MHz RTC value or IEEE-1588 time value not to mention an increased packet counter value from 256. The 64 bit header value would eliminate the need for a secondary header.

Balazs Bago, 2014/05/18 02:51

Before obsoleting the secondary absolute time format we must think about backward compatibility with the standard. I know one US organization who uses the secondary header already.

Albert Gabaldon, 2014/05/13 14:20

1 - No idea where binary weighted time is specified….

2.1 - I’ll probably start a new CR to add these TMATS mn’s

4.3 - I’m guessing this is grandfathered from the old tape days.

4.4 - Parity in PCM?

Balazs Bago, 2014/05/13 14:16

1 - As of my knowledge nobody uses the Chapter 4 binary weighted 48-bit time format. Recommendation: we shall set obsolete this format (coded as 00) in IRIG106-15.

2.1 - The described method for indicating disabled subchannels is correct, currently there is better way to indicate disabled sub-channels in TMATS.

Recommendation: add two new TMATS mnemonics:

R-x\AMCE-n-m with T or F indicating an enabled or disabled subchannel

R-x\AMCN-n-m with the sub-channel number used in the Analog Packet CSDW

This method shall be extended to all data types allowing sub-channels, as UART, ARINC-429, Message, Ethernet, …

2.2 - Any “Default” reference in TMATS should be used only, if it can be referenced back to any other field, where the default shall be taken. It must be clearly identified - or the “Default” must be stated.

Recommendation: for AMTO MSB first shall be defined as Default.

This and quite a few other items in this CR belongs to the Data Mux committee. There was already a clean-up for removing all “other” and “default” specification from the TMATS. This is one of the few places where this cleanup left the “Default” without stating what it means.

2.3 - The problem is simple: Chapter 10 allows to store analog data only in “RAW” format, the rest (“WAV”, “AC3”, …) can only be specified in TMATS – probably originally used for embedded analog data stream in other type of data. This needs to be written.

2.4 - The bit mask is defined for the analog channels (not only sub-channels) is only a theoretical value, we don’t know any application which would use it – especially not the 111011 type mask. Recommendation: to add a comment to Chapter 9 – do not use it along with Chapter 10 – as it is not allowed there

3 - Recommendation: UART data 5..8 bits shall be padded to 8 bit, 9 bit shall be padded to 16 bits.

4.1 - Recommendation: As the sync offset is very limitedly use, we may consider to obsolete it. It has no significant help to process a packet.

4.2 - To be consistent we recommend to remove the words on Page 10-33: “Word unpacking will force the LSB of each word to be aligned on a 16-bit boundary”.

4.3 - As in some cases above, we shall introduce in Chapter 9 a new general flag – similar to the “*R-CH10* flag - which saying this is obsolete for Chapter 10 usage, e.g.: *O-CH10* or *NOT-CH10*

4.4, 4.5 - Probably the DATA MUX group can answer only this

4.6 - This is a real interoperability case already, which shall be cleared. The use case is Chapter-8 PCM. It has 24-bit Synch word, and 24-bit data words. Chapter 10 defines, how the synch word shall be placed in the packet: in this case split for 2 x 12-bit words. There is no rule otherwise for the data – it is defined only, that shall be padded:

“In unpacked mode, packing is disabled and each data word is padded with the number of filler bits necessary to align the first bit of each word with the next 16-bit boundary in the packet.”

One recorder stores the Chapter-8 data as 8-bit pad + 8-bit data + 16 bit data, the 2 16-bit word stored in different order depending on 16-bit or 32-bit alignment mode is used.

We believe, that at least one software product expects the data split to 2 x 12-bit words + 4 bit zero padding.

Recommendation: as the key idea of the Unpacked mode is to help the software product to access the data simply and efficiently, splitting the words > 16 bits into 2 fragments is in contrary with the target. Leaving the 16 LSB in one word, and padding the N remaining bit to 16 again is the efficient method. In this case an Inter processor can read with one single 32-bit read command the whole 24-bit data + 8-bit pad without further manipulation. So we can add the following text: c. “In unpacked mode, packing is disabled and each data word is padded with the number of filler bits necessary to align the first bit of each word with the next 16-bit boundary in the packet. Padding shall be 0 bits, and added above the MSB. If data word length is >16 bits, the upper 16 bit is padded, the lower 16 bit is stored in original form.”

You could leave a comment if you were logged in.
change_request/cr80.txt · Last modified: 2014/05/13 13:07 by bob

Except where otherwise noted, content on this wiki is licensed under the following license: CC0 1.0 Universal
CC0 1.0 Universal Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki