PDC Live

Format of Packet 30

If you have read Teletext Transmission Details you will know that Packet 30 holds 40 bytes of data. The first data byte and some of the remaining data bytes are protected by a hamming code which helps recover from receiver errors. When de-hammed in to a 4-bit nibble, the first byte determines the type of the packet:

0 or 1 = Packet 30 type 1 identifies the Television Service Data Packet (TSDP), also sometimes referred to as the Broadcast Service Data Packet (BSDP).
1 or 2 = Packet 30 type 2 identifies a packet containing PDC information.

The bottom bit in these two cases is set to 1 if teletext packets can occur outside the vertical blanking interval (Full Field or Full Channel transmission).

The remaining 39 bytes in the packet have different meanings depending on the type of packet.

PDC Data in Packet 30 Type 0

A TSDP (Television Service Data Packet) is sent every second in Teletext magazine 8, row number 30, type code 0. The 39 bytes that follow the type code carry information about the television service as a whole, including the broadcaster's identity, time zone, time and date. We shall dissect a TSDP to see how this information is formatted. For example, this packet was broadcast on BBC1 at 22:37 BST on 22nd. July, 1996 AD:

    Bytes received            As ASCII   After de-hamming
    15 15 15 EA EA EA 5E 5F   ...jjj^_   0  0  0  F  F  F  3  -
    F6 85 06 13 97 32 38 37   v....287   -  -  -  -  -  -  -  -
    54 E5 73 F4 20 C2 C2 43   Test.BBC   -  -  -  -  -  -  -  -
    31 20 43 45 45 46 C1 58   1.CEEFAX   -  -  -  -  -  -  -  -
    20 20 20 20 20 20 20 20   ........   -  -  -  -  -  -  -  -

Byte 0 = 15

De-hammed = 0

Value 0 identifies this as a TSDP.

Bytes 1 to 6 = 15 15 EA EA EA 5E

De-hammed = 0 0 F F F 3

The next 6 bytes are also hammed and code the magazine, page and sub-page of the Teletext service index page in the convoluted way described for links. The example bytes, read backwards, point to sub-page 3F7F, magazine 1, page 00; that is, page 100, any sub-page.

Bytes 7 to 8 = 5F F6

The next 2 bytes hold the Network Identity Group. This is a code allocated to each broadcaster by the EBU. The code 5F F6 is allocated to BBC1.

Byte 9 = 85

The next byte encodes the time offset from UTC:

bits 0 and 7 are not used, but usually set to 1
bit 6 is 1 if the offset is negative
bits 1 to 5 hold the number of half-hour steps to add to (or subtract from) UTC to get local time.

Thus GMT is coded 81 and BST is coded 85, as in this example.

Bytes 10 to 12 = 06 13 97

The next 3 bytes encode the date as a Modified Julian Day, the number of days elapsed since 1858-11-16 (16 November, 1858 AD). This is represented as a 5-digit BCD number but with 1 added to each of the digits. Adding one to each digit means that there will never be a long run of bits with value zero; the reason advanced for avoiding this is that such a signal might cause the decoder's clock to lose synchronization. In our example, MJD 50286 is coded 06 13 97 - this represents the date 1996-07-22.

Bytes 13 to 15 = 32 38 37

The next 3 bytes hold the time, coded as HH MM SS, again in incremented BCD The time is supposed to be in UTC, with the offset byte telling you how to get local time. BBC1 and BBC2 do it correctly, but C4 and HTV send local time with the offset of 0 hours. The packet above was captured at 32 38 37 or 21:27:26 UTC, 22:27:26 BST.

Bytes 16 to 19 = 54 E5 73 F4

As ASCII = Test

The next 4 bytes contain unidentified text (currently "Test" on BBC1 and BBC2, "PROG" on HTV, and the hammed sequence 4100 on C4).

Bytes 20 to 39 = 20 C2 C2 43 31 20 43 45 45 46 C1 58 20 20 20 20 20 20 20 20

As ASCII = BBC1 CEEFAX

The remaining 20 bytes form a text string which may be used as a magazine identifier. This string typically identifies the television channel name, but it can be different for different magazine numbers (as on Channel 4). Note that these bytes (and indeed all the others) have odd parity.

PDC Data in Packet 30 Type 2

A PDC (Programme Delivery Control) packet is sent every second in Teletext magazine 8, row number 30, type code 2. The 39 bytes that follow the type code carry information about the programme currently being transmitted, together with some unrelated information that is duplicated from the TSDP. The 13 bytes which are exclusively to do with PDC encode the country, network, date and time at which the current programme was originally scheduled to be transmitted, together with some status bits, an indication of the programme's theme and the nature of the analogue soundtrack being broadcast.

The first 6 and last 20 bytes of the packet after the packet type code seem to be the same as those in the TSDP and encode the index page link and the television channel or teletext magazine name. The 13 bytes in between carry the PDC information. All 13 bytes are hammed to protect against reception errors and decode to 13 4-bit nibbles. We shall dissect a PDC packet to see how this information is formatted. You might like to take a moment to review a decoding of some recent packets to get an idea what this information looks like first.

For our example, let us look at the packet transmitted by Channel 4 from 12:31 to 12:55 BST on 26 July 1996.

    Bytes received            As ASCII   After de-hamming
    49 15 15 EA EA EA 5E 15   I..jjj^.   2  0  0  F  F  F  3  0
    49 64 A1 49 2F 5E FD B6   Id!I/^}6   2  4  C  2  7  3  E  D
    D0 D0 15 15 43 68 61 6E   PP..Chan   8  8  0  0  -  -  -  -
    6E E5 EC 20 34 20 54 E5   nel 4 Te   -  -  -  -  -  -  -  -
    EC E5 76 E9 73 E9 EF 6E   levision   -  -  -  -  -  -  -  -

The first byte, 49, de-hams to 2 and identifies this as a PDC packet. We won't examine the next 6 bytes or the last 20 bytes further since they are not related to PDC. See above for a description of these bytes. The 13 hammed bytes in between are the ones that matter to PDC. In this example they de-ham to the following sequence:

    0 2 4 C 2 7 3 E D 8 8 0 0

If we write them in binary, then reverse the bits in each nibble we get:

       0    2    4    C    2    7    3    E    D    8    8    0    0  hex
    0000 0010 0100 1100 0010 0111 0011 1110 1101 1000 1000 0000 0000  binary
    0000 0100 0010 0011 0100 1110 1100 0111 1011 0001 0001 0000 0000  reversed

Now with different grouping, we can see some useful information revealed:

   #1 #2 #3  #4 #5 #6   #7 #8    #9  #10   #11    #12   #13   #14       #15
   00  0  0  01  0  0 0010 00 11010 0111 01100 011110  1100 010001 00000000
    0  0  0   1  0  0    2  0    26    7    12     30    12     17        0
  LCI UF PRF PCS MI - CNI0 CNI2 day month hour minute  CNI1   CNI3      PTY

I have numbered the bit groups #1..#15 and given them some more helpful names underneath. The capital-letter names are in the EBU (now ETSI) specification.

The first value (#1) is the PDC Label Channel Identifier (LCI). PDC supports four streams of information, so that programme information can be overlapped or nested. Channel 4 does not use this facility, and #1 is always 0 on Channel 4. On BBC2, which does use streams, this value often changes between 0 and 1 or 2 when a new programme begins.
#2 is the Label Update Flag (LUF). If set, it indicates that this packet is intended to update the memories of a VCR. BBC2 always use LUF=0.
#3 is the Prepare to Record Flag (PRF) which is set to 1 for a few seconds whenever a new programme is about to begin. The programme has not yet started while PRF is set. Once it has started, PRF returns to 0.
BBC2 use PRF, but I haven't seen it on Channel 4 yet.
#4, #5 and #6 are together called the Programme Control Status (PCS):
- #4 reports on the type of analogue sound carrier:
  - 00=undefined
  - 01=mono
  - 10=stereo
  - 11=dual sound
  In the UK, this value should always be 01 for mono. Broadcasters don't seem to have a clue about this; I have seen 00 from Channel 4, 10 from BBC2 and 11 from Channel 5!
- #5 is the Mode Indicator (MI). If MI is 0, the programme will start 30 seconds after the PRF flag was first set. In this mode, there should be exactly 30 packets sent with PRF set to 1. If MI is 1, there is no guarantee that the programme will begin at a specific time; there could be any number of packets with PRF set to 1 before the programme begins.
  BBC2 always use MI=0 and set PRF in advance. Unfortunately, because my decoder misses a lot of packets, I don't always get to see any packets with the PRF flag set so I can't check that there are always 30.
- bit #6 is still reserved for future use.
#7, #8, #13 and #14 form the 16-bit Country and Network Identifier (CNI). For no adequately explained reason, the 16-bit field is formed by taking the groups in the order #7 #13 #8 #14. In our example this gives CNI=0010 1100 00 010001 or 0x2C11. 2C is the code for the UK; 11 is allocated to Channel 4.
The next four values (#9 to #12) represent the month, day and local time of the current programme start, 26 7 12 30 or 26th. July, 12:30 BST in this case. Certain impossible values (such as month=15) have special meaning:
- 00/15 28:63 Continuation
- 00/15 29:63 Interruption (INT)
- 00/15 30:63 Recording Inhibit/Terminate (RI/T)
- 00/15 31:63 Timer control (TC)
- 31/15 31:63 No PIL; use PTY
#13 and #14 are part of the CNI mentioned earlier.
The last value, #15, is the Programme Type Indicator (PTY). Values are defined that mark programmes intended for a particular audience (adult, children, gardeners, motorists etc.) or of a particular nature (music, light entertainment, drama). Broadcasters can also make up new values for this code to identify programmes that form part of a particular series. Channel 4 have defined code 81 for Brookside, 82 for Brookside Omnibus and 83 for the 7pm News. Apart from that, this field is not used by Channel 4 or BBC2 and is always zero.

Please let me know if you have any ideas or information that might help explain the remaining unknowns. Thanks to everyone who has already sent me their speculations and useful tidbits of information. In particular, I would like to thank Jim Main for his very detailed descriptions of the PDC packet format.

This page was created on 22 July 1996. It was last updated 05 September 1998.
Please send comments to Robin O'Leary pdc at ro dot nu