Error detection is only done on messages, not control sequences,
|Transmission Code||Type of checking|
|no Transparency||Transparency installed and operating||Transparency installed but not operating|
VRC = Vertical Redundancy Checking
This can only be used with ascii
since only 7 bits are used leaving the 8th bit free for parity. this bit is
set to make the number of 1s in each character odd, if an even number of 1s
is detected at the receiver then an error has occured. This is ODD parity (some
other services such as prestel use EVEN parity). VRC can be combined with LRC.
LRC = Longitudinal Redundancy Checking
Beginning from, but not including, the leading SOH or STX character the transmitter
keeps a running sum of each character transmitted, the least significant byte
(or two bytes) are added at the end following an ETB, ETX or ITB.
CRC = Cyclic Redundancy Checking
a more sophisticated form of LRC using Polynomial Division instead of subtraction and using the 16 (or 12) bit remainder as the checksum.
Each message must be acknowleged with an ACK before the next message can be
sent. In the case of a sequence of messages, ACK0 and ACK1 are used alternately
as affirmative replies, this allows a running check to ensure that each reply
corresponds to the immediately proceeding message block. (ACK0 is always used
as the affirmative reply to selection or line bid).
Valid responses to a text message are as follows:
|Valid message with good BCC:||ACK0 or ACK1 or WACK|
|message with bad BCC||NAK|
Limited Conversational Mode (LCM)
This allows text message to be used as an acknowledgement for a text message
in the other direction, a station receiving this form of conversational reply
is not permitted to transmit another conversational reply in response.
Possible effects of line errors
1 - The receiving station detects a bad BCC -
action: receiver sends a NAK to request retransmission.
2 - The receiving station looses character sync
action: the receiving station will not detect the end-of-message, if a
SYN is not detected after a 3 second receive timeout it will abandon
the message and attempt to re-synchronize.
many other combinations of corruptions/complete loss of messages/acks are possible and most (but not all) of these can be corrected by the BCC,timeout and alternating ACK mechanisms.