1、 CEA Standard Joint EIA/CVCC Recommended Practice for Teletext: North American Basic Teletext Specification (NABTS) CEA-516 S-2013 May 1988 NOTICE Consumer Electronics Association (CEA) Standards, Bulletins and other technical publications are designed to serve the public interest through eliminatin
2、g misunderstandings between manufacturers and purchasers, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for his particular need. Existence of such Standards, Bulletins and other technical publ
3、ications shall not in any respect preclude any member or nonmember of CEA from manufacturing or selling products not conforming to such Standards, Bulletins or other technical publications, nor shall the existence of such Standards, Bulletins and other technical publications preclude their voluntary
4、 use by those other than CEA members, whether the standard is to be used either domestically or internationally. Standards, Bulletins and other technical publications are adopted by CEA in accordance with the American National Standards Institute (ANSI) patent policy. By such action, CEA does not as
5、sume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the Standard, Bulletin or other technical publication. This document does not purport to address all safety problems associated with its use or all applicable regulatory requirements. It is the res
6、ponsibility of the user of this document to establish appropriate safety and health practices and to determine the applicability of regulatory limitations before its use. This document is copyrighted by the Consumer Electronics Association (CEA) and may not be reproduced, in whole or part, without w
7、ritten permission. Federal copyright law prohibits unauthorized reproduction of this document by any means. Organizations may obtain permission to reproduce a limited number of copies by entering into a license agreement. Requests to reproduce text, data, charts, figures or other material should be
8、made to CEA. (Formulated under the cognizance of the CEA R4.3 Television Data Systems Subcommittee.) Published by CONSUMER ELECTRONICS ASSOCIATION 2013 Technology the Packet Prefix, the Data Block and the optional Suffix. The structure of the Data Packet is illustrated in Figure 6. 3.2 PACKET PREFIX
9、 3.2.1 Structure of the Packet Prefix The Packet Prefix shall immediately follow the Synchronization Sequence specified in 2.2. The Packet Pref1x consists of five bytes in the following order: Pl,P2,P3,CI,PS where Pl,P2,P3 = Packet Address bytes CI = Continuity Index Byte PS = Packet Structure Byte
10、3.2.2 Coding of the Packet Prefix Bytes All the bytes of the Packet Prefix are Hamming encoded. In these bytes, bits 7, 5, 3 and 1 provide protection for the informat1on bits 8, 6, 4. and 2, and also maintain odd parity over the Hamming byte. The Hamming encoding and decoding for each byte are shown
11、 in Figure 7. This method of data protection allows the correction of all single-bit errors, and the detection of all two-bit errors in each byte. 3.2.3 Packet Address (P) The first three bytes of the Packet Prefix, PI, P2 and P3, define the Packet Address, P, with PI being the most significant byte
12、. Each byte contains four information bits, which define a hexadecimal digit (0 through F) .There are 4096 possible Packet Addresses. The Packet Address is identical to the Data Channel number. These Packet Addresses may be used by more than one service and are not sufficient as a means of identifyi
13、ng teletext data, see 4.2.2. 3.2.4 Continuity Index (CI) The Continuity Index is the fourth Hamming-encoded byte of the Packet Prefix. The value or number of the continuity Index sequences from 0 to 15. It increments by one each time a Data Packet is transmitted within a given Data channel unless th
14、e Data Packet is a Synchronizing Packet as def1ned in 3.2.5. If the Data Packet is a synchronizing Packet, then the Continuity Index may not be related to the continuity Index of the preceding Data Packet in the Data Channel. Page 6 CEA 516 The Continuity Index is used to detect the loss of a Data P
15、acket in a Data Group due to transmission or other errors. 3.2.5 Packet Structure Byte (PS The Packet Structure Byte is the fifth and last byte of the Packet Prefix. This byte specifies the type of Data Packet, whether the Data Packet is full, and the length of the Suffix. Bit b2 specifies the type
16、of Data Packet. Specifically, b2=1 indicates that the packet is a Synchronizing Packet, which starts a Data Group, see 4.1; and b2=O indicates that e packet is a Standard Packet, which is part of a Data Group. Bit b4 specifies whether the Data Packet is full. Specifically, b4=O indicates that the Da
17、ta Packet is full of useful data, and b4=1 indicates that the Data Packet is not completely full of useful data. The last Data Packet in a Data Group is not necessarily indicated by b4 = 1. Bits b6 and b8 specify the length of the suffix, which is described in 3.4. 3.3 DATA BLOCK The Data Block cons
18、ists of the group of bytes that follow the Packet Prefix and precede the Suffix, if any. The Data Block may be full or not full of useful data in accordance with bit b4 of the Packet Structure Byte specified in 3.2.5. The length of the Data Block depends on the length of the Suffix, and can have val
19、ues of zero, 26, 27 or 28 bytes. All bytes within Data Blocks belonging to Data Group Type zero, see 4.2.2, shall be transmitted with odd parity. Some bytes are Hamming-encoded, as described in 3.2.2, and the Hamming code was chosen to provide odd parity. The other bytes shall be transmitted with th
20、e most significant bit, b8, in each byte used for odd parity. 3.4 SUFFIX The Suffix consists of one or more bytes, which may be used by the receiver to either detect or detect and correct transmission errors in the Data Block. The Suffix, if present, shall be placed at the end of the Data Packet fol
21、lowing the Data Block. Even if the Data Block is not full of useful information, the Suffix, if present, shall be positioned at the end of the Data Packet as shown in Figure 6. The length of the Suffix is indicated by bits b8 and b6 of the Packet Structure Byte (see 3.2.5). Note that the maximum len
22、gth of the Data Block is reduced by the number of Suffix bytes. The error-protection schemes specified by bits b8 and b6 of PS shall be: CEA 516 Page 7 b8 b6 length format 0 0 0 no Suffix 0 1 1 byte longitudinal parity- check byte 1 0 2 byte last byte shall be longitudinal parity check , second to l
23、ast byte is subject to further study. An error- protection byte based on a hamming code is under consideration.* 1 1 28 bytes reserved for future standardization. The longitudinal parity-check byte represents the parity of the Data Block plus Suffix, and it shall be odd. This means that the result o
24、f combining all bytes in the Data Block and Suffix, using EXCLUSIVE OR operat1ons, shall be a byte consisting of all ones. The longitudinal parity-check byte and the individual byte-parity bits together form a product code that allows correction of all single-bit errors and detection of all two-bit
25、errors and many multiple-bit errors over the Data Block and Suffix. The bit combination 1,1 indicates that the entire contents of the Data Packet following the Packet Prefix is used for error protection information. Service providers may concatenate more than one such Data Packet to provide more pow
26、erful error-protection capabilities. The single or concatenated 1,1 Data Packets terminate and protect a Bundle, that is, a number of previously transmitted Data Blocks. The first Bundle starts with and includes the Data Block in the Synchronizing Packet. Service providers may add additional Bundles
27、 with 1,1 Data Packets as required. The method of error protection is reserved for future standardization. For Data Block plus Suffix lengths of 28 bytes, the parity of each Suffix byte shall be odd. Note that the continuity Index shall be maintained across all Data Packets includ1ng the 1,1 Data Pa
28、cket, see 3.2.4. * “Design Considerations for Maximizing the Performance of the Canadian Broadcast Telidon System“, Dr M. Sablatash, Dr B. C. Mortimer and Prof M. Moore, Proc Hetel- con 83, Athens Aug 24-26, 1983. Page 8 CEA 516 4. DATA GROUP 4.1 STRUCTURE OF THE DATA GROUP The broadcast data are or
29、ganized into logical units called Data Groups. A Data Group is composed of an integral number of Data Blocks that are transported in Data Packets characterized by a given value of the same Packet Address. The beginning of a Data Group is indicated by a synchronizing Packet for which b2 of the Packet
30、 Structure Byte is 1 (see 3.2.5) . Each Data Group is divided into two parts: a Data Group Header and Data Group Data. The structure of the Data Group is illustrated in Figure 8. 4.2 DATA GROUP HEADER 4.2.1 Structure of the Data Group Header The Data Group Header is always located just Packet Struct
31、ure Byte of a synchronizing Packet. Group Header consists of eight Hamming-encoded shown below and in Figure 9: GT,GC,GR,Sl,S2,Fl,F2,GN where GT = Data Group Type GC = Data Group Continuity GR = Data Group Repetition SI, S2 = Data Group Size F1, F2 = Final Non- Zero Block Size GN = Data Group Networ
32、k Routing 4.2.2 Data Group Type (GT) This byte specifies different classes of processing in the receiving equipment. A value of zero designates the method of transmission used for broadcast teletext services. A value of 15 is reserved for private use by the service provider and will never be standar
33、dized. All other values are reserved for future standardization. 4.2.3 Data Group continuity (GC) The value of this byte may be incremented by one from 0 to 15 each time a Data Group of the same Data Group Type is transmitted within a given Data Channel. This byte may be used to detect the loss of a
34、 Data Group. 4.2.4 Data Group Repetition (GR) This byte may be used to number a Data Group from O to 15 when the same Data Group is sent more than once. A value of zero means that the Data Group will not be repeated. A non-zero value means that the receiver should expect the Data Group to be repeate
35、d. 4.2.5 Data Group Size (S1, S2) These two bytes are to be concatenated, with S1 being the most significant byte, to produce a number from O through 255, which is the number of Data Blocks in the Data Group following the Data Block in the Synchronizing Packet. This total includes any Data Blocks of
36、 zero length that occur with a 28-byte Suffix. 4.2.6 Final Non-Zero Block size (Fl, F2 CEA 516 Page 9 These two bytes are to be concatenated, with Fl being the most significant byte, to produce a number from O through 255. This number is the number of bytes contained in the Final Non-Zero Data Block
37、 of the Data Group. Note that the Final Non-Zero Block size for teletext should never be out- side the range 1 through 28 bytes. Note also that the Final Non-Zero Data Block may not be in the last Data Packet of a Data Group since Data Packets containing zero-length Data Blocks and 28-byte Suffixes
38、may follow the Final Non-Zero Data Block. If the Final Non-Zero Data Block is not full then the service provider shall add extra bytes to fill the Data Packet. If the Packet Structure Byte indicates that the Suffix length of the final Data Packet is one or two bytes, then these Suffixes shall be pla
39、ced at the end of the Data Packet following the extra bytes. Parity and any error correction appropriate to the Suffix shall apply to the extra bytes. 4.2.7 Data Group Network Routing (GN) This byte, under control of the teletext service provider, is used to specify different ways of routing the Dat
40、a Group through the broadcast network. GN can take values from O to 15. 4.3 DATA GROUP DATA The Data Group Data is of variable length the Data Group Header. If the Data Group Type (see 4.2.2) is zero then the Data Group Data relates to broadcast teletext and is defined by the remainder of this docum
41、ent. In broadcast teletext, the Data Group Data consists of Records. Records are described in the next chapter. 5.TELETEXT RECORD 5.1 STRUCTURE OF THE TELETEXT RECORD In broadcast teletext, for which GT = 0, a Data Group contains only one Teletext Record. For the remainder of this document, GT will
42、be assumed to be equal to zero and a Teletext Record will be referred to simply as “Record“. A Record is made up of two parts, a Record Header and Record Data. The Record Header immediately follows the Data Group Header and is defined in 5.2. The Record Data may be presentation data or application d
43、ata, see 5.3. The end of a Record is also the end of a Data Group so that the last byte of the former is also the last byte of the latter. 5.2 RECORD HEADER 5.2.1 Structure of the Record Header The Record Header identifies the Record and contains information about the Record. This information may be
44、 used by a receiver to select a Record for acquisition and possible presentation. The Record Header always follows the Data Group Header (see 4.2). It consists of five Hamming-encoded bytes, followed by a variable number of Hamming-encoded optional bytes in the following order: RT,RD,Al,A2,A3, A4,A5
45、,A6,A7,A8,A9, L1,L2 , Y. , HE. Page 10 CEA 516 where RT = Record Type RD = Record Header Designator A1 A2,A3 = Record Address A4,A5,A6,A7,A8,A9 = optional Record Address Extension L1, L2 = optional Record Link Y = optional Classification Sequence HE = optional Header Extension Field(s) The structure
46、 of the Record Header is illustrated in Figure 10 A Record in a given Data Channel is uniquely identified by its Record Address, Record Link and Version Number, which is contained in the Classification Sequence. Information about the Record, and about the presence of related Records, is conveyed by
47、the Record Type, Record Link, Classification Sequence and Header Extension Field. 5.2.2 Record Type (RT) 5.2.2.1 Number of Record Types The Record Type is the first byte in the Record Header. This Hamming-encoded byte has four information bits that specify one of 16 different types of Records number
48、ed O through 15. The Record Type is not an attribute that is used to uniquely identify a Record. 5.2.2.2 Record Type 0 Record Type 0 identifies Presentation Records typically used in cyclic teletext applications. A Presentation Record contains presentation layer code conforming to the NAPLPS and int
49、ended for display. 5.2.2.3 Record Type 1 Record Type 1 identifies Presentation Records typically used in non-cyclic teletext applications such as capt1oning. 5.2.2.4 Record Type 2 Record Type 2 identifies an Application Record that contains control and other non-presentation information such as date and time, see 7.2. 5.2.2.5 Record Type 3 Record Type 3 identifies Presentation Records that are given priority by the receiver. If a receiver is looking for any Records in a Data Channel then it shall examine all Records of Record Type 3 in that Data Channel. The following Recor
