Differences

This shows you the differences between two versions of the page.

--- change_request:cr80 [2014/05/13 12:51] – created bob
+++ change_request:cr80 [2014/05/13 13:04] – bob
@@ Line 1: / Line 1: @@
-| Change Request Number | CR 00xx (To be assigned by CM Manager) |
+===== 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 |
@@ Line 16: / Line 18: @@
 | ::: | 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 ====
+. 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.
+. 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.
+. 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.
+. 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.
+~~DISCUSSION~~
+==== 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:
+. 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).
+. 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.
+. 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?
+. 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?
+. 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:
+P-d\MFW1-12:12 \\
+P-d\MFW2-12:5
+This conveys no more information than the simpler definition
+P-d\MFW2-12:5
+So I expect the specification means something different.
+. In case word length >16 (or >32) bit are used in 16 (32) bit aligned unpacked mode, the placement of the bits is undefined.