IRIG106wiki

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:

To:

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.

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?

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:

10.6.2.2. 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.”