hdcp.wp [hdcp protocol]

1.0 PURPOSE

The purpose of this document is to describe a protocol for data communications between computer-based equipment. This protocol supports multi-drop half-duplex communications. It is primarily designed for use with microprocessor-based equipment with relatively small amounts of data and program storage capability, and no mass storage device. It has been designed so that it can be implemented either as part of a larger software package or using a dedicated microprocessor to handle the bus protocol.

2.0 FUNCTIONAL DESCRIPTION

HDCP is designed to serve as one layer of a multi-layer communications system. The lowest layer would be the actual physical link, specified by the number of wires, the voltage levels, the data rate, etc. HDCP would be the next level. It is a data link control protocol (DLC), meaning that it takes care of sending a packet of data from one unit to another without errors. The interpretation of that data is left to the third level. It could be control data for a device, or message data to be sent over the air through a link.

2.1 Functions of HDCP

The basic functions of HDCP are to:

1. Establish and terminate a connection between two communicating equipments.

2. Assure message integrity through error detection, requests for retransmission, and positive or negative acknowledgements.

3. Identify source and destination equipment through polling.

2.2 Goals

The primary goals of this protocol are:

1. To have minimal overhead on short messages without losing flexibility.

2. The ability to be implemented on small microprocessor-based controllers with a minimal amount of additional PROM or RAM.

3. Independence of the protocol from the contents of the data stream.

4. Independence from the type of data link (serial asynchronous, serial synchronous, or parallel).

5. The ability to implement the protocol in a dedicated microprocessor which would not need to know about the contents of the messages.

6. Usefulness for both remote control and communications applications.

3.0 OPERATIONAL DESCRIPTION

A multi-drop link consists of one or more masters and one or more slaves. The methods for determining which master has control of the link are a hardware function and not part of this protocol. The slaves each have a unique 8-bit identification number (ident) which serves as an address in the protocol. A slave only responds to messages with its ident, and it includes its ident in the response.

Communications under HDCP are basically half-duplex. A master and a slave cannot talk at the same time. When the master sends the slave a message, it must wait for a reply before continuing. A timer can be used to enable the master to proceed after a period of time if a slave does not reply. A full-duplex link is recommended for HDCP, even though the communications are only half-duplex. This avoids problems of link lock-up.

3.1 General Operation

Normally the master will poll its slaves at regular intervals for status updates. A polling sequence is initiated when the master sends one of the slaves a polling message. This message has two flag bits to indicate whether the slave should report back messages the slave has waiting. One of the flags is for urgent data messages (fault conditions, etc.) and the other is for non-urgent data messages. Slaves typically use such data messages to report status changes. If neither flag bit was set in the polling message, or if there was no message pending at the slave, the slave returns an ACK to the master.

If one of the flags is set, to indicate that the slave should return a status report, and if the slave has a report pending, it will send a data message to the master with the report in the data field of the message. If the master receives this message correctly, he will send an acknowledge (ACK) message to the slave, then can poll the next slave in the sequence. If there was an error in the data message received from the slave, the master will send the slave a negative acknowledge (NAK) message, and the slave will repeat the data message.

If the master has a message for one of the slaves, it sends a data message to the slave. If the message was received without errors, the slave sends back an ACK message; otherwise it sends back a NAK. If a NAK was returned, the master will repeat the data message. When the ACK is received, the master may choose to immediately poll the slave for a status update, or he may wait until the next polling sequence. This ACK or NAK from the slave only indicates that the message was received without errors by the slave to which it was directed. It does not reflect on the validity of the data (command) received; it only indicates that the packet was received without error.

The protocol provides a short data message for one-byte messages which must be processed with minimum overhead. Examples are keyline or scan commands. The single data byte is sent in the message header, reducing the overhead of count and check bytes for a data portion. They are treated the same as any other data message by the protocol, and are responded to with an ACK or a NAK.

A broadcast mode is provided to send a message to all slaves simultaneously. Ident number 0 is used for this purpose. The slaves do not send any reply to a broadcast message, but on the next polling cycle a bit is set in the slave's ACK to indicate that the broadcast message was received. Broadcast mode should be used with care, because of the limited ability to ensure that messages were received correctly.

A subprotocol is used for situations which require very low overhead. The subprotocol uses messages with no headers or error detection, usually single character messages. The subprotocol can only be used with a single slave, and ties up the link while it is in use. It is used for situations, such as CW keying, in which speed is the overriding concern. During an escape message sequence, the path between the master and the designated slave will exhibit much activity with lesser overhead, suspending a normal poll sequence.

4.0 INTERFACES

The HDCP communications may be handled either with a software module or with a dedicated processor. In either case the interfaces to the rest of the system are fairly simple. Typically, at either the master or the slave, the HDCP module is told the ident number of the slave. The receive portion will then signal the main software when a valid message has been received. The message will be placed in a buffer which has an associated counter.

The following sections detail the use of HDCP for information transfer. The message types and their formats will be presented, followed by examples of their use. Then considerations for serial link synchronization will be discussed.

5.0 MESSAGES

5.1 Character Description

All data in this protocol is sent in 8-bit characters. It is up to the implementor whether the data is sent serial asynchronous, serial synchronous, or parallel.

5.1.1 Message Type

The message type is the first HDCP character of all messages. This value identifies the message being sent, to guide the decoding of the message header, and data portion, if any.

5.1.2 Ident

The ident is the second character of all messages. The ident is an 8-bit binary number which uniquely identifies the slave. This implies that, from a software point of view, 255 slaves (numbered 1‑255) can be addressed by a master. When a master sends a message to a slave, the ident field contains the ident of the addressed slave. Only the slave which is addressed by the master should reply. (The slave must have a way to permit the ident to be programmed by the user). When a slave sends a message to the master, the ident field contains the ident number of the slave. Identification number 0 is reserved for broadcast mode. All slaves on the bus should act on data messages with ident 0 but none should send any reply.

5.1.3 Count

A character used in a data message is the count. The count gives the length of the data portion of the data message, and does not include the count of header characters. It also does not include the CRC characters which terminate the data. Since this count is 8 bits in length, the maximum message length in this protocol is 255 characters. A count of 0 is illegal.

5.1.4 Checksum Character

Every header has a checksum character at the end for error checking. The checksum character (CKSUM) is defined as having each bit of the character equal to the Modulo‑2 sums of the corresponding bits of the three other characters making up the header. It can also be thought of as even vertical parity. It can easily be computed by exclusive-Or-ing the first two characters together, then exclusive-Or-ing the result with the third character. Before transmission of a message, a unit will calculate the exclusive-Or of the header bytes less the checksum byte, and store the result as the outgoing checksum. A receiving unit will verify the header by exclusive-Or-ing all header bytes, including the checksum byte. The result will be zero if the header was received correctly.

5.1.5 CRC Character

Data messages have two Cyclic Redundancy Check characters at the end, for error checking. These CRC characters are calculated using the standard CRC-CCITT algorithm. The high order byte of the CRC precedes the low order byte in the message. Before transmission of a data message, a unit will calculate the CRC of the data portion, and store the result as the outgoing CRC. A receiving unit will verify the data by computing the CRC on the data portion, including the two byte CRC word. That result will be zero if the data portion was received correctly.

5.2 Message Types

1. Data Messages. Data messages carry user data between masters and slaves. The originator must wait for a reply (i.e. ACK) before sending another message. The data field (packet) is interpreted according to the rules of the data packet protocol involved. Data messages for each data protocol have similar appearance (header with count byte, data field, CRC bytes). The type byte value in the header indicates which data packet protocol is involved.

2. Short Data Messages. Short data messages are used to send short messages where maximum efficiency is critical. A single data byte is sent without the overhead of a count byte and CRC bytes. The data byte is interpreted according to the rules of the data packet protocol involved. Short data messages for each data protocol have similar appearance (header with data byte). The type byte value in the header indicates which data packet protocol is involved.

3. Acknowledge Messages. The Acknowledge message (ACK) is the reply to successfully received data and short data messages. It is also used to reply to polling messages and escape messages.

4. Negative Acknowledge Message. The Negative Acknowledge message (NAK) is used to indicate to the sender that a data message was received in error.

5. Polling Message. The polling message is used as a way for the master to poll the slaves for status changes. This message type is never sent by slaves.

6. Escape Message. The escape message is used to put the slave into the subprotocol, which is used for special situations (such as CW keying) when the normal protocol will not provide fast enough response. The escape message is also used by a slave to signal the master that it should get out of the subprotocol.

5.3 Message Formats

The following section describes in detail the message types used in HDCP.

5.3.1 Notation

Each message is divided into several fields. A field is a group of one or more characters. The following notation is used to describe the message fields:

Field (length): description of field, where:

Field = the name of the field.

length = the length of the field in bytes.

5.3.2 Data Messages

Data messages carry user data between masters and slaves. The originator must wait for a reply (ACK or NAK) before sending another message. The format of these messages is:

TYPE

IDENT

COUNT

CKSUM

DATA

CRC

where:

TYPE(1): The message type identifier. The value indicates to which protocol the data field (packet) is encoded. Possible hexadecimal values are:

01: HRRCP data messages

07: Special Products protocol data messages

09: HARCP data messages

0B: HESP data messages

0D: AT protocol data messages

0F: MFR protocol data messages

11: IMC or HMRCP data messages

13: HTSCP data messages

15: HAARCP data messages

IDENT(1): The identification number of the slave device.

COUNT(1): The byte count of the data portion of the message.

CKSUM(1): The checksum on the header portion of the message (TYPE through COUNT).

DATA(COUNT): The message data field. There are no restrictions on the contents of the data field except that it must contain the number of 8-bit bytes specified in the COUNT field.

CRC(2): The Cyclic Redundancy Check bytes on the data portion of the message.

5.3.3 Short Data Messages

Short data messages are used to send short messages where maximum efficiency is critical. Applications may include keyline data, continuous tuning changes, and channel scanning data. The format of these messages is:

TYPE

IDENT

DATA

CKSUM

where:

TYPE(1): The message type identifier. The value indicates to which protocol the data byte is encoded. Possible hexadecimal values are:

02: HRRCP short data messages

08: Special Products protocol short data messages

0A: HARCP short data messages

0E: reserved

10: reserved

0C: HESP short data messages

12: HMRCP short data messages

14: HTSCP short data messages

16: HAARCP short data messages

IDENT(1): The identification number of the slave device.

DATA(1): A single byte of data. This byte can have any value.

CKSUM(1): The checksum on the header (TYPE through DATA).

5.3.4 Acknowledge Messages

The Acknowledge message (ACK) is the reply to successfully received data and short data messages. It is also used to reply to polling messages and escape messages. The format is:

ACKTYPE

IDENT

FLAG1

CKSUM

where:

ACKTYPE(1): The message type identifier. It has a value of 03 (hexadecimal).

IDENT(1): The ident number of the slave.

FLAG1(1): A zero byte from masters to slaves. From slaves to masters, a flag byte with the following flag bits:

Bit 0: Urgent message pending. Set (1) if an urgent message is pending. Typically used for notifying the master of fault conditions.

Bit 1: Set (1) if a non-urgent message is pending.

Bit 2: Set (1) if a broadcast mode message was received correctly.

Bit 3: Set (1) if the slave is busy. This can be used by devices to tell the master when they are ready to accept more data.

Bits 4‑7: Not used (must be 0).

CKSUM(1): The checksum on the header (ACKTYPE through NUM).

5.3.5 Negative Acknowledge Message

The Negative Acknowledge message (NAK) is used to indicate to the sender that a data message was received in error. The error was detected by a check of the CRC bytes following the data

packet. The format is:

NAKTYPE

IDENT

FLAG1

CKSUM

where:

NAKTYPE(1): The message type identifier. It has a value of 04 (hexadecimal).

IDENT(1): The ident number of the slave.

FLAG1(1): A zero byte from masters to slaves. From slaves to masters, a flag byte with the following flag bits:

Bit 0: Urgent message pending. Set (1) if an urgent message is pending. Typically used for notifying the master of fault conditions.

Bit 1: Set (1) if a non-urgent message is pending.

Bit 2: Set (1) if a broadcast mode message was received correctly.

Bit 3: Set (1) if the slave is busy.

Bits 4‑7: Not used (must be 0).

CKSUM(1): The checksum on the header (NACKTYPE through NUM).

5.3.6 Polling Message

The polling message is used as a way for the master to poll the slaves for messages (e.g.,status changes). This message type is never sent by slaves. The format is:

POLLTYPE

IDENT

FLAG2

CKSUM

where:

POLLTYPE(1): The message type identifier. It has a value of 05 (hexadecimal).

IDENT(1): The identification number of the slave device.

FLAG2(1): A flag byte. The bits are assigned as follows:

Bit 0: Set(1) if the slave should return urgent messages.

Bit 1: Set (1) if the slave should return non-urgent messages.

Bit 2: Set (1) if the slave should report its current operating status.

Bit 3: Set (1) if the slave should report its equipment type number. The equipment type is a one-byte number which identifies the type of hardware used in the slave. Certain masters may use this information to find out what the system hardware configuration is when the master is powered up.

Bits 4‑7: Not used (must be 0).

CKSUM(1): The checksum on the header (POLLTYPE through FLAGS).

5.3.7 Escape Message

The escape message is used to put the slave into the subprotocol, which is used for special situations (such as CW keying) when the normal protocol will not provide fast enough response. The escape message is also used by a slave to signal the master that it should get out of the subprotocol. The message format is:

ESCTYPE

IDENT

CODE

CKSUM

where:

ESCTYPE(1): The message type identifier for the escape message. It has a value of 06 (hexadecimal).

IDENT(1): The identification number of the slave device.

CODE(1): Not currently used (should be 0).

CKSUM(1): The checksum on the header (ESCTYPE through CODE).

5.4 Message Sequences

5.4.1 Conventions

The following examples show the typical use of the message types. The conventions for message use are few and simple:

1. The destination unit for a data message must reply with an ACK or NAK to the originator to close out that transaction. The ACK indicates that the message was received without error. A NAK indicates erroneous data (CRC failure) received in a data message.

2. The slave which receives a poll message must respond either with a ACK; or, if the poll's flag bits requested waiting messages and the slave has waiting messages, the slave should respond with a data message.

3. If a slave cannot verify correct header reception(by CKSUM test), the ident byte may be corrupted and no response should be made to the master.

4. A slave cannot source a data message to the master unless requested by a poll.

The sequences which consist of a related set of messages sent between a master and a slave are commonly called "transactions". The defined transactions are:

1. Master polls slave, slave returns ACK.

2. Master polls slave, slave sends data, master responds with ACK.

3. Master sends data to slave, slave responds with ACK.

Broadcast messages, which all slaves obey but none ACK, are a special case of transaction (3). Situations where poor data message reception causes a NAK response to sender are special cases of transactions (2) or (3).

In the following examples, the message transactions between master and slave are shown as:

master: POLL(ident=03, no flag bits)

slave #03: ACK(ident=03, no flag bits)

for the master polling unit number 3, which replies with an ACK; and

master: DATA(ident=04,data)

slave #04: ACK(ident=04,no flag bits)

for the master sending data to unit number 4, which replies with an ACK.

5.4.2 Sequential Poll

Typically the master polls all slaves on a round-robin basis. If the flag byte in these polls is such as to request no messages from the slaves, they will respond with ACK, flag bits set to indicate any messages waiting. The master can note pending messages and repoll immediately, or on the next cycle, for messages to be returned from the slave.

master: POLL(ident=03,no flag bits)

slave #03: ACK(ident=03,no flag bits)

master: POLL(ident=04,no flag bits)

slave #04: ACK(ident=04,no flag bits)

master: POLL(ident=05,no flag bits)

slave #05: ACK(ident=05,flag bits=non-urgent message waiting)

master: POLL(ident=05,flag bits=send non-urgent msgs, send urgent msgs)

slave #05: DATA(ident=05,data)

master: ACK(ident=05,no flag bits)

The above polling allows the master to keep track of the slaves by their responses to poll. If a slave were to fail to respond to several polls, this fault condition probably would be noted at a system level, and that slave may be

declared "dead". Masters must be able to recover from not getting any response from slave(s). The slave may be defective, or the transmission may be garbled to the point where the slave cannot verify the header of the poll.

5.4.3 Poll for Messages

Note that in the example in Sec. 5.4.2, since the polls had no bits set to request messages from the slave, two polls were required to get the waiting message from unit 05. For links with slow baud rates, or slaves whose status changes infrequently, (such as radios in full remote control, which cannot change status except from master's commands), always polling for messages can be used:

master: POLL(ident=04,flag bits=send non-urgent msgs, send urgent msgs)

slave #04: ACK(ident=04,no flag bits)

master: POLL(ident=05,flag bits=send non-urgent msgs, send urgent msgs)

slave #05: DATA(ident=05,data)

master: ACK(ident=05,no flag bits)

master: POLL(ident=06,flag bits=send non-urgent msgs, send urgent msgs)

slave #06: ACK(ident=06,no flag bits)

That is, a slave with messages waiting will respond with them, else respond with ACK. Either way, the slave responds to the master. Note that the master sends the slave an ACK in response to the slave's data message.

5.4.4 Use of NAK

A data message, on which a unit cannot verify data portion CRC, must be responded to with NAK to the originator. The originator then must re-transmit the message. Only if the originator receives an ACK can it "discard" the last message it sent. Otherwise, it may need the message, to re-transmit it.

master: DATA(ident=08,data)

slave #08: NAK(ident=08,no flag bits)

master: DATA(ident=08,data)

slave #08: NAK(ident=08,no flag bits)

master: DATA(ident=08,data)

slave #08: ACK(ident=08,no flag bits)

Masters usually will maintain a counter, to suspend such sequences of data messages and/or NAKs to/from slaves (after some maximum count) so that a bad data path to slave(s) does not tie up the system.

5.4.5 Complete Status Report

The simplest means to get a complete status report from a slave is to set the "report complete status" flag bit in a poll message sent out to the slave. The slave will construct a data message describing its complete status (data of the appropriate protocol), for transmission to the master at a later time.

master: POLL(ident=05,flag bits=report complete)

slave #05: ACK(ident=05,flag bits=non-urgent message waiting)

master: POLL(ident=05,flag bits=send non-urgent msg)

slave #05: DATA(ident=05,data)

master: ACK(ident=05,no flag bits)

Note that the slave responded to the first poll with a flag bit in its ACK showing that the data message with the status report was waiting. The master then polled for the message and received the complete status report.

For most slaves, the process of constructing a status report is so rapid that TWO poll/response transactions as shown above are not needed. The master can poll with 3 flag bits set: report complete, send non-urgent messages, send urgent messages. The receiving slave will note the report complete flag bit, build the data message, then note the message requested bits, and send out the data message. The result is:

master: POLL(ident=05,flag bits=report complete, send non-urgent msg)

slave #05: DATA(ident=05,data)

master: ACK(ident=05,no flag bits)

which has the same results as the previous sequence, but requires less time. The frequency of complete status requests to units is left up to each system's needs. One typical method is to poll units sequentially, with message request flag bits set. Then, every N polls, also set the report complete bit to force the slave to report all.

6.0 SYNCHRONIZATION

A method is required to insure that the destination unit is synchronized to the originator's data stream, so that each has the same interpretation of the bits and bytes in that stream. Both byte and message framing must be established.

6.1 Byte Framing

The method of byte framing depends on the type of link employed. The byte framing procedures for asynchronous, synchronous, and parallel data links are given below.

6.1.1 Asynchronous Links

Byte framing on asynchronous links is usually handled by the Universal Asynchronous Receive Transmit (UART). To ensure the UART will be able to synchronize correctly with the bit stream. it is customary to regularly send either an all 1's character (hexadecimal FF) or a mark (1) state for at least 10 bit times. This condition is met by the synchronization sequence used to establish message framing, as in section 6.2.1.

6.1.2 Synchronous Links

A synchronous link uses a sequence of 2 or more SYNC characters to establish synchronization.

6.1.3 Parallel Links

Byte framing is inherent on 8-bit parallel links. On other widths it is up to the implementor to ensure that proper framing is achieved.

6.2 Message Framing

Message framing is achieved when a unit finds a valid message type value (01 through 14 hexadecimal) following a synchronization sequence or the end of the previous message. It is confirmed when the checksum on the header is verified.

If a unit gets out of synchronization with the protocol (for example, when a slave is powered up) it must be given a way to regain synchronization. With a reasonable header size it is always possible that the unit could find a header sequence in the data field of a data message (aliasing). Therefore it is recommended that:

1. Each message from master to slave or from slave to master be started with a synchronization sequence. This is especially important on noisy lines.

2. The slaves should maintain synchronization even though the received message is not for that slave. In other words, a slave will receive a header, which shows the message is a data message for another unit. That slave should still "count off" the data portion of the message, as received, to aid in resuming sync sequence search.

6.2.1 Asynchronous Links

The standard synchronization sequence for asynchronous HDCP links uses two synchronization characters. The first is the all 1's character (hexadecimal FF) needed for byte synchronization, and the second is a hexadecimal F5. Equipment should be able to handle as many sequential FF's as possible, with the sequence FF, F5 signalling the start of a new header.

byte ¹ FF

and ¹ F5 byte = F5

┌────────────┐ ┌────────────┐ ┌─────────────┐

│ wait for ├─────>│ wait for ├─────>│ wait for │

│ received │<─────┤ received │ │ header │

│ byte │ │ byte │ │ │

│ │<┐ │ │<┐ │ │

└────────┬───┘ │ └────────┬───┘ │ └─────────────┘

└─────┘ └─────┘

byte ¹ FF byte = FF byte = FF

7.0 ERROR RECOVERY

The basic means of error recovery under this protocol is simply to repeat the message. Header checksums are used to ensure that only the one addressed slave will respond to a message. Data field CRCs are used to detect errors so that the originator can be asked to repeat the message.

7.1 Checksum Verification

If a master does not verify the header checksum, it can either ignore the message or send a NAK to the slave (here assuming a data response came from the polled slave - bad checksum means the received ident and message type values cannot be believed, so a NAK may not be appropriate). The master could simply repoll. If a slave does not verify the header checksum, it must not reply to the master. This keeps slaves from interfering with message traffic if the ident was received in error.

7.2 CRC Verification

If a unit receiving a data message does not verify the received CRC, it should send a NAK to the sender, so the sender will repeat the message. There should be a limit to the number of times this can occur, to keep from tying up the link.

7.3 Message Repetition

If a master does not receive a reply to a polling message or a data message within a certain length of time, it should repeat the message. The required time interval depends upon the maximum message length and the baud rate on the link. Transmission delays possible on the link(s) involved (landline, microwave, etc) and interfaces should be considered. If a message is repeated more than two or three times without a reply the master may want to declare the slave dead. This keeps a dead slave from tying up the link, and allows the master to inform the user of the loss of communication.

8.0 THE SUB-PROTOCOL

Special provisions have been made to provide a sub-protocol with minimal overhead for special situations like CW keying. This sub-protocol can only be used with one slave at a time, and it ties up the link until HDCP is reentered. It also requires a full-duplex link if the slave must be able to terminate the sub-protocol.

The sub-protocol is entered when the master sends the slave an escape message. When the slave responds with an ACK, both the master and the slave enter the sub-protocol. Thereafter, both units stay in the sub-protocol until the master sends the slave a termination character. (This is not the same as the ESCTYPE character. On asynchronous links it is the same as the second synchronization character, which is hexadecimal F5.) At this point, both units revert to the normal HDCP protocol, and usually the master will poll the slave for status.

A slave may initiate a termination of the sub-protocol by sending the master an escape message. This is done asynchronously from the master's data stream. When the master receives this escape message it polls the slave. This terminates the sub-protocol.

When the link is in the sub-protocol a single character comprises the entire message. For example, for CW keying one character would key the transmitter and another would unkey it. The interpretation of the characters is left to the next higher level of protocol.

9.0 MESSAGE TYPE SUMMARY

01: HRRCP data messages

02: HRRCP short data messages

03: ACK

04: NAK

05: POLL

06: ESCAPE

07: Special Products protocol data messages

08: Special Products protocol short data messages

09: HARCP data messages

0A: HARCP short data messages

0B: HESP data messages

0C: HESP short data messages

0D: AT protocol data messages

0E: -- reserved

0F: MFR protocol data messages

10: -- reserved

11: IMC or HMRCP data messages

12: HMRCP short data messages

13: HTSCP data messages

14: HTSCP short data messages

15: HAARCP data messages

16: HAARCP short data messages

10.0 CRC CALCULATION

The CRC characters for the data message are calculated using the CRC algorithm described below. These two characters are appended to the end of the data message.

Consider the data message (without the CRC characters) as a block of coefficients of a polynomial. The Most Significant Bit of the first character received in the message is the coefficient of the highest order term in the polynomial. The Least Significant Bit of the last character received is the coefficient of the term which has an exponent equal to 16. The 16 lower order terms are assumed to be zero. When this polynomial is divided by the CRC Generator Polynomial, the remainder that results is taken as the Block Check Character (BCC). This BCC is a 16-bit word that is appended to the end of the data message as two CRC characters, Most Significant Byte first. The resulting "polynomial", represented by the data message and the BCC, will yield a zero remainder when divided by the generator polynomial.

The CRC Generator Polynomial G(x) is:

G(x) = x16 + x12 + x5 + x0

When the CRC computation is performed on the received message, the two CRC characters are included in the computation as an addition to the polynomial represented by the data message. Therefore, if the CRC computation for the received data message and the received CRC characters yields a result of zero, then it is assumed that the message has been received correctly.

10.1 Coding Example

The following is an example pseudo-code section for CRC calculation of a message. It assumes the message has been stored in an array called Character with the number of bytes in a variable called Charactercount. The results are stored in Crchigh and Crclow, which should be initialized to zero before starting the calculation.

/* CRC check */

DO i = 0 TO (Character_count - 1)

scratch2 = Character(i) XOR Crc_high

scratch3 = scratch2 divided by 16

scratch2 = scratch2 XOR scratch3

scratch1 = scratch2 multiplied by 16

scratch1 = scratch1 XOR Crc_low

scratch3 = scratch2 divided by 8

Crc_high = scratch3 XOR scratch1

scratch3 = scratch2 multiplied by 32

Crc_low = scratch3 XOR scratch2

END

10.2 CRC Examples

The following strings of hexadecimal bytes have had CRC values calculated, and may be used for testing of CRC algorithms. The CRC bytes are shown in the order that they would be appended to the data packet.

4 bytes: CB 88 C1 27 CRC = 4E A0

6 bytes: AD 16 A7 01 AF 00 CRC = E7 9F

8 bytes: C1 29 C9 03 CD 03 AB 00 CRC = 03 4E