Field of Invention

[0001] The present invention generally relates to data communications systems, and more particularly to an a priori processor for a trellis encoded digital television signal.

Background

[0002] The Advanced Television Systems Committee (ATSC) standard for Digital Television (DTV) in the United States requires an 8-VSB (Vestigial Sideband Modulation) transmission system which includes Forward Error Correction (FEC) as a means of improving system performance. (United States Advanced Television Systems Committee, "ATSC Digital Television Standard", (document A53.doc), September 16, 1995.) FIG. 1 shows a simplified block diagram of the DTV transmitter and receiver, emphasizing the FEC system. As shown in FIG. 1 , on the transmitter side, the FEC encoding subsystem consists of a Reed-Solomon encoder, followed by a byte interleaver, and a trellis encoder. On the receiver side, there is a corresponding trellis decoder, a byte de-interleaver and a Reed-Solomon decoder.

[0003] The ATSC DTV transmission scheme is not robust enough against Doppler shift and multipath radio interference, and is designed for highly directional fixed antennas, hindering the provision of expanded services to customers utilizing mobile and handheld (M H) devices. To overcome these issues, and create a more robust and more flexible system, among other things, it is possible to add a new layer of FEC coding, and more powerful decoding algorithms to decrease the Threshold of Visibility (TOV). The added layer of FEC coding may require decoding techniques such as iterative (turbo) decoding (see, e.g., C. Berrou et al., "Near Shannon Limit

Error - Correcting Coding and Decoding: Turbo-Codes (1 )", Proceedings of the IEEE International Conference on Communications - ICC'93, May 23-26, 1993, Geneva, Switzerland, pp. 1064-1070; and M. R. Soleymani et al., "Turbo Coding for Satellite and Wireless Communications", Kluwer Academic Publishers, USA, 2002) and trellis decoding algorithms like the MAP decoder described by L.R. Bahl, J. Cocke, F.

Jelinek and J. Raviv, "Optimal Decoding of Linear Codes for Minimizing Symbol Error Rate", IEEE Transactions on Information Theory, Vol. IT-20, No. 2, March 1974, pp. 284-287. [0004] In addition, it is possible to include additional training data, also called a priori or preamble data, in the digital data stream to aid the receiver. However, in order to be backward compatible with the original ATSC DTV standard, the additional training data must be introduced at the transmitter, prior to the legacy ATSC transmitter blocks in FIG. 1. Hence, the training data will be fully encoded by the legacy ATSC transmitter blocks, implying that at the receiver, one needs to first decode the data stream with the legacy ATSC receiver to retrieve the additional training data and further utilize it to aid the mobile reception. The present invention includes an efficient way to take advantage of the additional a priori training data prior to the legacy ATSC decoder blocks in FIG. 1.

Summary

[0005] In accordance with the principles of the invention, an apparatus for decoding received digital data is presented. The received digital data organized in digital symbol blocks of size S, wherein the data stream is encoded at a transmitter by a digital encoder processor that includes a plurality of deterministic digital processing units followed by a trellis encoder. The transmitter adds digital training data bytes to the transmitted data stream prior to the digital encoder processor. The receiver decoding apparatus includes an a priori processor with means for providing a priori information concerning training data bytes to the trellis decoder of the receiver without any feedback from a trellis decoder. The receiver decoding apparatus creates a priori information as the data steam is being received.

[0006] In view of the above, and as will be apparent from reading the detailed description, other embodiments and features are also possible and fall within the principles of the invention.

Brief Description of the Figures

[0007] Some embodiments of apparatus and/or methods in accordance with embodiments of the present invention are now described, by way of example only, and with reference to the accompanying figures in which:

FIG. 1 is a block diagram of a digital television (DTV) system in accordance with the Advanced Television Systems Committee (ATSC) standard for DTV; FIG. 2 illustrates the format of an ATSC-DTV data frame;

FIG. 3 illustrates the format of a Data Field Sync segment in an ATSC-DTV data frame;

FIG. 4 is a block diagram of an exemplary DTV M/H System in accordance with the principles of the current invention;

FIG. 5 shows an exemplary packet structure of a packet block code of code rate R =

K/N in accordance with the principles of the current invention;

FIG. 6 shows a plot of the ATSC interleaver output (horizontal axis, left to right) versus time (vertical axis, top to bottom) for a block of 52 input packets;

FIG. 7 illustrates a maximum a posteriori (MAP) decoder architecture;

FIG. 8 illustrates a metric generator of the MAP decoder of Fig. 7;

FIG. 9 illustrates an a priori processor within the metric generator of FIG. 8 in accordance with the principles of the current invention; and

FIG. 10 illustrates an a priori processor block diagram in accordance with the principles of the current invention.

Description of Embodiments

[0008] FIG. 2 shows the format of an ATSC-DTV data frame as transmitted. Each data frame consists of two data fields, each containing 313 data segments. The first data segment of each data field is a unique synchronizing segment (Data Field Sync) shown in greater detail in FIG. 3 and further discussed below. The remaining 312 data segments of each data field each carries the equivalent data of one 188-byte MPEG-compatible transport packet and its associated FEC overhead.

[0009] Each data segment consists of 832 8-VSB symbols. The first four symbols of each data segment, including the Data Field Sync segments, form a binary pattern and provide segment synchronization. As shown in FIG. 3, the first four 8-VSB symbols of each data segment have values of +5, -5, -5, and +5. This four-symbol data segment sync signal also represents the sync byte of each 188-byte MPEG-compatible transport packet conveyed by each of the 312 data segments in each data field. The remaining 828 symbols of each data segment carry data equivalent to the remaining 187 bytes of a transport packet and its associated FEC overhead.

[0010] FIG. 3 shows a Data Field Sync segment in greater detail. As shown in FIG. 3, each Data Field Sync segment includes several pseudo random (PN) sequences, a VSB mode field and a reserved field of 104 symbols. (Note that the last 12 symbols of the reserved field, labeled PRECODE, are used in trellis coded terrestrial 8-VSB to replicate the last 12 symbols of the previous segment.)

[0011] FIG. 4 shows a simplified block diagram of an exemplary transmitter and receiver for a mobile/handheld (M/H) DTV system, hereby called DTV-M/H. In FIG. 4, an added layer of FEC, exemplified by FEC Encoder 2, may include a packet block code. The FEC Encoder 1 is compatible with the ATSC FEC encoder in FIG. 1 . At the receiver, the Iterative FEC Decoder performs turbo decoding placed onto the transmitted signal via the various FEC encoders of the transmitter. Although a detailed explanation of the Iterative FEC (Turbo) Decoder is not necessary for this invention, one skilled in the art will understand that the Iterative FEC decoder of FIG. 4 may include a maximum a posteriori (MAP) decoding of the ATSC trellis decoder and the added FEC codes within FEC Encoder 2 which will iteratively interact, each decoder sending extrinsic information to the other. Such systems are described in C. Berrou, A. Glavieux and P. Thitimajshima, "Near Shannon Limit Error - Correcting Coding and Decoding: Turbo-Codes (1 )", Proceedings of the IEEE International Conference on Communications - ICC'93, May 23-26, 1993, Geneva, Switzerland, pp. 1064-1070, M. R. Soleymani, Y. Gao and U. Vilaipornsawai, "Turbo Coding for Satellite and Wireless Communications", luwer Academic Publishers, USA, 2002, and previously mentioned L.R. Bahl, J. Cocke, F. Jelinek and J. Raviv, "Optimal Decoding of Linear Codes for Minimizing Symbol Error Rate". In addition, the Iterative FEC Decoder of FIG. 4 will perform a number of iterations M deemed necessary to achieve a desired system performance.

[0012] FIG. 5 shows an exemplary packet structure of a packet block code of rate R=K/N in accordance with the principles of the current invention. The block code is such that for each K packets of data, each with 187 information bytes (assuming MPEG packets), the block code adds N-K parity packets.

[0013] In an exemplary mobile DTV system according to FIG. 4 and FIG. 5, preamble training data segments, also called a priori tracking (APT) packets, may be transmitted in addition to the synchronization data present in the ATSC-DTV data frame described above. This preamble training data, however, is fully encoded by all levels of legacy ATSC FEC coding in the system (FEC encoder 1 ), as well as being interleaved and randomized. The preamble training data is known data which is added to the stream at the level of FEC Encoder 2 and it may or not be fully encoded by FEC Encoder 2. An example of a burst repetitive data structure for transmission of the DTV-M/H data is given in TABLE 1. Observe that the preamble data segments are equivalent to a packet code block of 52 packets or segments.

TABLE 1

[0014] As shown in TABLE 1 , a data burst comprising three data fields, F0, Fl and F2, is repetitively transmitted, each corresponding to 1.5 frame of the legacy ATSC- DTV standard. The aforementioned preamble training data is placed in the first data field F0 as 52 data segments.

[0015] When receiving a data burst such as set forth in TABLE 1, a DTV-M/H receiver will discard the 260 Legacy ATSC data segments in Data Field F0 and process the remaining data including the 52 preamble training data segments. The preamble training data is to be utilized by the DTV-M/H receiver as training data used in order to enhance receiver performance.

[0016] As described above, the FEC Encoder 1 of Figure 4 includes a Reed Solomon (RS) encoder, interleaver, and trellis encoder blocks similar to the blocks of the FEC Encoding Subsystem of the transmitter in Figure 1 . One skilled in the art will appreciate in FIG. 4 that the byte operations of data randomization, Reed-Solomon (RS) encoding and interleaving are deterministic and, although they will modify the preamble training data, the deterministic nature of the preamble training data will be preserved at the output of these three receiver functional blocks. However, the trellis encoding operation, which operates on each dual-bit of a byte, is not deterministic, since it is a function of the trellis state, which is a function of the data stream prior to the preamble. Hence, at the transmitter output, one cannot easily identify the presence of the preamble in the data stream. [0017] One may observe that, for a preamble (termed P) of 52 packets of 187 bytes, the output of the ATSC randomizer in the transmitter side of FIG. 4 is a modified preamble (termed P_R) of 52 packets of 187 bytes, wherein each byte is a randomized version of the corresponding bytes in preamble P, according to the ATSC randomizer and position of the preamble P in the field.

[0018] The output of the ATSC Reed Solomon (RS) encoder present in the FEC Encoder 1 of FIG. 4 is a modified preamble (termed P_RS) of 52 packets of 207 bytes, where the first 187 bytes of each packet of P RS are the same as P R and the last 20 bytes of each packet of P RS are the RS encoder parity bytes associated with each packet of P R, according to the ATSC RS encoder. Since the RS parity bytes also have fixed values, the presence of the RS encoder in FEC Encoder 1 of Figure 4 extends the number of preamble bytes by the RS code rate 207/187, and those bytes are also considered preamble bytes for the purpose of using them as training bytes at the receiver. Since the ATSC byte interleaver contained in the FEC Encoder 1 block of in FIG. 4 is a convolutional interleaver, the block of 52 consecutive preamble training data RS encoded (P_RS) packets of 207 bytes at its input is going to be spread over 103 output packets, in an interleaved order of bytes.

[0019] FIG. 6 shows a plot of the ATSC interleaver output bytes in the horizontal axis, from left to right versus number of packets in time in the vertical axis, from top to bottom, for a block of 52 preamble input packets. The horizontal axis shows the number of output bytes per packet, for a total of 207 bytes. The vertical axis shows the number of each output packet in time, for a total of 103. The black arrows identify the input packet 0 and the input packet 25, as an example of how these packets end up appearing in the output stream. In Figure 6, the white squares belong to all the 52 preamble packets, identifying the positions where they will be present in the output stream. The remaining squares (dark-gray or light gray) are bytes belonging to other blocks of packets before and after the preamble which become interleaved with the preamble.

[0020] One may observe that there is a one-to-one fixed mapping between each preamble input byte and a corresponding byte in the white squares of FIG. 6. For example, the byte 1 (or the 2 ^nd byte) of packet 0 (or the first packet) at the input of the ATSC interleaver will appear as the 2 ^nd byte of the 2 ^nd packet at its output. Also, the 182 ^nd byte of the first packet at the input of the ATSC interleaver will appear as the 207 ^th byte of the 26 ^th packet at its output. Hence, using Figure 6, it is possible to identify with certainty the position and value of each preamble training data byte at the output of the ATSC interleaver in the FEC Encoder 1 block of FIG. 4.

[0021] The ATSC trellis encoder in the FEC Encoder 1 comprises 12 interleaved trellis codes of code rate 2/3, whereby each encoder sequentially receives one byte at a time and transmits one symbol at a time. Each input byte is split in 4 dual-bits, and each dual-bit will be trellis encoded to form a symbol of 3 bits, of which 2 bits are information bits associated with the dual-bit at its input and the third bit is an encoded bit which is a function of the trellis state and previous inputs.

[0022] One may observe that the 3-bit 8-level symbols at the output of the ATSC trellis encoder associated with preamble input bytes are not fixed, since they are a function of the trellis state, which is a function of the previous input stream containing interleaved preamble and other data bytes. However, for each 8-level symbol at the ATSC trellis encoder output associated with a preamble byte, its embedded 2-bit information symbol is fixed and known at its input, and its position in the stream may also be mapped. This is an important concept for the explanation of this invention. For example, in the data block in FIG. 6, there will be 12 consecutive preamble bytes entering the 12 consecutive trellis encoders, such that the 1 ^st dual-bit of the 1 ^st byte will create the 1 ^st output preamble symbol; the 1 ^st dual-bit of the 2 ^nd byte will create the 2 ^nd output preamble symbol and the 2 ^nd dual-bit of the 1 ^st byte will create the 13 ^th output preamble symbol. By inputting the entire data block of FIG. 6, the mapping of all the preamble related symbols at the ATSC trellis encoder output stream may be established with certainty, as well as the fixed 2 information bits or dual-bits that each contains.

[0023] One may observe that if the FEC Encoder 2 in FIG. 4 only includes deterministic processing blocks, e.g., block codes, interleavers and randomizers, the preamble training data may be inserted prior to the FEC Encoder 2 block and still be traced within the encoded data as discussed above.

[0024] FIG. 7 shows a simplified block diagram of a MAP decoder 700. In particular, the metric generator unit 710 consists of the channel metric (m _c ) computation for each 8-VSB input symbol (r), which is given by:

/(2σ ² ) ( 1 ) where k > 1 is the symbol period; <r ² is the noise variance and Cj, for i = 0, 1 ... 7, are the 8 possible TCM symbols. The channel metrics (m _c ) are then stored for a size of two path memory blocks. This path memory block, L _pm , is equivalent to the traceback latency of a Viterbi decoder.

[0025] The metric generator unit also stores the a priori metric (m _apr ) received from a previous iteration for a size of two path memory blocks. The a priori metrics m _apr (k, j) is given by: m apr ^ ^j ) ⁼ - ¹ °g i ^P l ^I k < ²⁾ where k > 1 is the symbol period; log(.) is the logarithm function; P(.) is the probability; Ik is the bit-pair at time k and j= 0, 1 ,2,3, represents the four bit-pair values.

[0026] The metric generator 710 must then send the m _c and m _apr stored values to the corresponding alpha 720 (forward processing) and beta 730 (backward processing) units. The alpha values (am _c and am _apr ) are sent in a first in first out (FIFO) mode, while the beta (bm _c and bm _apr ) values are sent in a last in first out (LIFO) mode. In addition, the metric generator 710 receives a priori information from a previous iteration of the FEC decoder and must send the stored values to the alpha 720 and beta 730 units in a similar fashion. The LLR (log likelihood ratio) 740 unit accepts inputs from the alpha unit 720 and the beta unit 730 and produces soft output values of a symbol decision bit-pair. The MAP controller unit 750 directs the calculations of the metric generator 710, alpha unit 720, beta unit 730, and LLR unit 740 by sending all the necessary control signals.

[0027] FIG. 8 is a block diagram of the metric generator unit 710 shown in Figure 7. The metric generator 710 is mainly composed of 4 sub-units: the noise power estimator 810, the channel metric calculator 820, the channel metric storage RAM 830 and the a priori metric storage RAM 840. The metric generator 710 outputs the alpha and beta channel and a priori metrics to the alpha 720 and beta 730 units, respectively. The noise power estimator 81 0 may use quantizers to estimate the amount of noise in the input symbols and average the noise to obtain an estimate of the power or variance σ . The channel metric calculator 820 performs the calculation in equation 1 . Both RAMs 830, 840 store the channel and a priori metric values for later retrieval. [0028] In one aspect of the invention, an a priori processor block 910 takes advantage of the preamble training data prior to MAP decoding in order to influence the iteration chain of FEC decoding from the very first MAP decoder in the chain, improving the chain's performance. This is opposed to the notion that one would wait to FEC decode the first system iteration, before accessing the preamble training data and generating a priori information associated with this data for the following FEC iteration. Since trellis decoders are prone to generating burst errors, it is desirable to use the preamble training data as soon as possible in the FEC iteration chain. Thus, the present invention includes an apparatus in a receiver for decoding transmitted digital data, wherein the transmitted digital data is organized in digital symbol blocks of size S, wherein the transmitted data stream is encoded by a digital encoder processor comprising a plurality of deterministic digital processing units followed by a trellis encoder, and wherein digital training data bytes are added to the data stream prior to the digital encoder processor.

[0029] As mentioned previously, the preamble training data is fully FEC encoded by FEC Encoder 1 in FIG. 4. However, because it extends for entire segments or packets, the operations of randomization, and RS encoding are deterministic. In addition, because of the placement of the preamble training data is constant within a field structure, as shown in the Field 0 of Table I , the operation of interleaving is also deterministic. This permits the placement of the a priori processor just prior to the metric generator and before FEC decoding because the metric generator is the first block in the FEC decoding chain of a MAP decoder. However, for simplification, one can think of the a priori processor 910 as an added part of the metric generator 710, as shown together in Figure 9.

[0030] The way that the preamble data is processed through the encoding chain results in bytes of each segment being randomized, RS encoded to create more parity bytes, and then convolutional interleaved, as shown in the transmitter side of Figure 1. The convolutional byte interleaving operation spreads the preamble from the end of field F0, as in Table 1 , all the way to the beginning of the next field, Fl . Other examples of data structure would result in a similar spreading of the data. In addition, the dual-bits of each byte will be processed by the 12 trellis encoders of the transmitter of Figure 1, resulting in 8-VSB modulated symbols. Thus, at the receiver of Figure 1, each 8-VSB modulated signal associated with a preamble dual-bit will have a particular deterministic position within the field structure.

[0031] FIG. 10 shows a simplified block diagram of the a priori processor block 910 of FIG. 9. The a priori processor 910 includes a preamble ROM 1010, a preamble processor 1020, and an a priori multiplexer (mux) 1030. The preamble ROM 1010 contains two sets of information: the preamble dual-bit, which is the information bits (VAL) associated with a particular trellis encoded 8-VSB symbol, and the position of such symbol (LOC) in the field structure of Table 1 after the interleaving and trellis encoding operations. The preamble dual-bits or VAL contain the randomized version of the original preamble data and RS encoder parity bits, which as mentioned before, are all deterministic operations. In Figure 10, the control input signals 1040 direct the preamble processor 1020 to read the preamble ROM 1010 contents. The preamble processor 1020 decides, based on the control inputs 1040, internal counters, and by reading the ROM contents, which inputs in the a priori information stream should be replaced. The preamble processor 1020 then creates the a priori information associated with the preamble, to replace that a priori information in the input stream. The preamble processor 1020 can be implemented as a state machine or as a processor unit executing program instructions that performs the operations of the following algorithmic method, which is indicated below for either a state machine procedure or a executable program:

1. Reset a symbol counter (COUNT) and the preamble ROM address (ADDR) at the beginning of Field F0, concurrent with the arrival of a field sync.

2. Compare the counter value (COUNT) with the ROM preamble location (LOC) stored in the ROM address (ADDR).

3. If COUNT = LOC, then:

a. Create a priori information (m _apr _p _r eambie) based on the preamble ROM contents. The preamble processor reads the dual-bit values (VAL) stored in the preamble ROM associated with the location (LOC) stored in the ROM address (ADDR). This particular a priori information

(m _ap r_preambie) which is created by the preamble processor is the correct value of a priori information for the corresponding input symbol in the input symbol stream and shall replace the received a priori information (m _apr ) for the particular symbol. For example, if for a particular location (LOC) the dual-bit VAL is "01 " then the preamble a priori metric (m _apr _preambie) values will be associated with setting P(VAL = '01 ") = 1 and P(VAL = "00") = P(VAL = "10") = P(VAL = "1 1 ") = 0, according to equation 2. For 6-bit unsigned m _apr _p _rea mbie values, this may translate, for example, to = 0 and

r_p _r eamble(V AL=" 10") =

b. Make the mux selector (SEL) of the a priori mux equal to 1 and pass the preamble a priori information to the a priori RAM via the output port of the a priori mux. The preamble a priori information then replaces the a priori information in the received stream, since the preamble a priori information is the correct value of a priori information.

c. Increment the symbol counter (COUNT = COUNT + 1) on every input 8-VSB data symbol. The value of COUNT does not need to increment over the 3 fields of Table 1 , but may stop one symbol after the last symbol position where the interleaved preamble dual-bits will appear, which, in one embodiment, may be somewhere in the first half of the field Fl for the burst data structure in Table 1 (COUNT MAX). This value COUNT MAX is associated with the size of the preamble ROM and therefore its maximum address ADDR MAX.

d. If ADDR < ADDR MAX, increment the preamble ROM address (ADDR = ADDR + 1 ).

e. Return to 1.

Else if COUNT≠ LOC, then:

a. Make the mux selector (SEL) of the a priori mux equal to 0 and pass the a priori information from the previous iteration to the a priori RAM via the output port of the a priori mux.

b. Return to 1.

[0032] Finally, the a priori mux 1030 sends the a priori information from the preamble processor 1020 (m _apr _p _rea mbie) or the previous iteration of the FEC decoder (maprjn) (i.e. a priori input 1060) to the a priori metric RAM 840 of Figure 9 via the output port of the a priori mux 1030 of Figure 10, depending on the choice of the mux selector SEL, according to the method above. For the first metric generator in the iterative FEC chain, the a priori information from the FEC decoder will be set to 0. Note that the calculated a priori information concerning training data is generated by the preamble processor 1020 and is provided to the metric generator unit and thus to the maximum a posteriori (MAP) decoder via the a priori mux of the metric generator without any feedback from a trellis decoder.

[0033] In another embodiment of the invention, the Preamble ROM stores a location bit BIT LOC, instead of the location of the dual-bit (LOC). This location bit exists for each position from the beginning of the preamble until the last position that a preamble dual-bit appears in the stream after interleaving. The value of BIT LOC may be T when the dual-bit position corresponds to a preamble dual-bit and '0' otherwise. When BIT LOC is ' Γ, the value of the dual-bit, VAL, is also stored in the preamble ROM.

[0034] In one embodiment, the a priori processor 910 of Figures 9 and 10 inputs transmitted digital data organized in digital symbol blocks of size S, wherein the transmitted data stream is encoded by a digital encoder processor that includes a plurality of deterministic digital processing units as in the transmitter side of Figure 1 followed by a trellis encoder. In the transmitter of Figure 1 , digital training data bytes are added to the data stream prior to the digital encoder processor. In the receiver, elements of the a priori processor of Figure 10 serve to identify which transmitted trellis symbol positions s within a symbol block (0 < s < S) are associated with the presence of training data bits at the trellis encoder input. The preamble processor 1020 of the a priori processor 910 can serve to provide a one-to-one mapping between each trellis encoded symbol position s within a symbol block (0 < s < S) and the k distinct training data bits which are inputs to the trellis encoder when the corresponding trellis encoded symbol is generated. This one-to one mapping function may be present in the preamble processor 1020 or it may be a separate function such as a lookup table, address decoder, or other memory. The preamble processor 1020 of Figure 10 includes a symbol counter which counts the symbols on each symbol block S and outputs newly generated preamble training data when needed. An output of the preamble processor of Figure 10 outputs a number of L = 2 ^k training data values V(I) for each trellis encoded symbol, wherein 0 < I < L. Here, I is a count of a priori values per symbol. In one embodiment, V(I) = Vo if the symbol counter value s is such that the decimal representation of its corresponding k training bits is equal to I, and wherein V(I) = V] if the symbol counter value is such that the decimal representation of its corresponding k training bits is not equal to I or if there are no training bits associated with the particular trellis coded symbol, where Vo and Vi are

predetermined values. In one embodiment, identification of which trellis symbol positions s within a symbol block (0 < s < S) are associated with the presence of training data bits at the trellis encoder input includes a memory indication, for example a one bit memory set to 1 or 0 for indicating the presence or absence of training data bits respectively for each trellis encoded symbol position s in a symbol block S. This memory indication may be included in the preamble ROM 1010 memory of Figure 10, or may be a separate memory accessible by the preamble processor 1020. Also, the one-to-one mapping between each trellis encoded symbol position and the k distinct training bits can include a memory containing the k training data bits associated with each trellis encoded symbol position s in a symbol block S for which the memory indicates the presence of training data bytes.

[0035] The a priori processor architecture for a MAP decoder for the ATSC-DTV trellis code discussed above takes advantage of the encoded preamble training data present in a mobile ATSC-DTV system to enhance the performance of all MAP decoder iterations in an iterative (turbo) decoding receiver implementation. In one embodiment, this architecture has been implemented in VHDL and utilized in a prototype for a mobile ATSC-DTV receiver. The concepts used in this invention can be extended to other iteratively decoded systems, and data frame and preamble training structures.

[0036] The implementations described herein may be implemented in, for example, a method or process, an apparatus, or a combination of hardware and software or hardware and firmware. Even if only discussed in the context of a single form of implementation, the implementation of features discussed may also be implemented in other forms (for example, an apparatus or a program executed in a computer). An apparatus may be implemented in, for example, appropriate hardware, software, and firmware. The methods may be implemented in, for example, an apparatus such as, for example, a processor, which refers to processing devices in general, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processing devices also include communication devices, such as, for example, computers, cell phones, portable/personal digital assistants ("PDAs"), and other devices that facilitate communication of information between end-users. [0037] Implementations of the various processes and features described herein may be embodied in a variety of different equipment or applications, particularly, for example, equipment or applications associated with data transmission and reception. Examples of equipment include video coders, video decoders, video codecs, web servers, set-top boxes, laptops, personal computers, and other communication devices. As should be clear, the equipment may be mobile and even installed in a mobile vehicle.

[0038] Additionally, the methods may be implemented by instructions being performed by a processor, and such instructions may be stored on a processor- readable medium such as, for example, an integrated circuit, a software carrier or other storage device such as, for example, a hard disk, a compact diskette, a random access memory ("RAM"), a read-only memory ("ROM") or any other magnetic optical, or solid state media. The instructions may form an application program tangibly embodied on a processor-readable medium such as any of the media listed above. As should be clear, a processor may include, as part of the processor unit, a processor-readable medium having, for example, instructions for carrying out a process.