[2.2.1–2] Why errors occur; check methods

Why transmitted data can contain errors and how we detect them

Whenever data moves between devices - across a copper cable, fibre optic link, or a wireless channel - it can be altered unintentionally. This corruption may be as small as a single flipped bit or as large as a whole block of bytes being changed or lost. Because many applications depend on accuracy (e.g. banking transactions, medical records, examination results), systems include error detection techniques to discover when received data does not match what was sent. This page explains why errors occur and describes three syllabus techniques: parity (odd and even), checksum, and echo check.

How errors happen during transmission

Errors are usually random or burst changes to bits introduced by the transmission medium or by poor timing between sender and receiver. Some common sources are listed below. Understanding causes helps you select suitable error detection methods.

  • Electrical noise: sudden spikes or dips in voltage on copper lines can flip a bit from 0 to 1 or from 1 to 0.
  • Attenuation: signals weaken with distance; if amplification or repeaters are not configured correctly, edges blur and bits may be misread.
  • Interference and cross-talk: nearby cables or radio transmitters can inject energy into a channel, distorting symbols.
  • Wireless multipath and fading: reflections and obstacles cause symbols to overlap or drop, particularly in mobile links.
  • Timing mismatches: sender and receiver clocks drift, leading to sampling the line too early or too late.
  • Collisions and buffer overflow: in shared media, frames may collide; when buffers are full, bytes can be dropped.
  • Software or hardware faults: faulty drivers, misconfigured network cards, or damaged connectors introduce errors.

Because these problems cannot be eliminated entirely, protocols implement error detection so that receivers can identify corrupted data and request a retransmission when appropriate.

Key idea: detect vs correct

The syllabus methods here focus on error detection, not on correction. Detection techniques add extra information so the receiver can check integrity. If an error is detected, the usual response is to discard the data and ask for it to be resent. More advanced codes (e.g. Hamming codes) can correct some errors automatically, but they are beyond this benchmark.

Parity checks (odd and even)

A parity bit is a single extra bit added to each byte or character to make the total number of 1 bits either even (even parity) or odd (odd parity). The receiver recalculates the parity and compares it with the received parity bit. If they do not match, an error is detected.

How parity is applied

  1. Count the 1s in the data bits.
  2. Under even parity, set the parity bit so that the grand total of 1s (data + parity bit) is even. Under odd parity, set it so the total is odd.
  3. Transmit the data bits plus the parity bit.
  4. At the receiver: recount and compare with the parity rule. If the rule is broken, flag an error.

Worked parity examples

Data byte: 10110010 has four 1s. Under even parity, the parity bit is 0 to keep the total even. Transmitted: data 10110010 + parity 0. Receiver counts four 1s; rule satisfied, so no error is detected.

Data byte: 01101100 has four 1s. Under odd parity, parity bit is 1 to make five total. Transmitted: data 01101100 + parity 1. Suppose noise flips the third bit: received data 01001100 still has three 1s + parity 1 = four 1s, which is even, but we expected odd. Mismatch indicates an error.

Data byte: 11001001 with even parity bit 0 gives an even total. If two data bits flip during transmission (e.g. 10001000), the number of 1s may still be even. The receiver sees even parity and does not detect the error. This is a known limitation: simple parity cannot detect an even number of bit errors.

Strengths and limitations of parity
  • Strength: only one extra bit per byte, very low overhead.
  • Detects: all single-bit errors, and any odd-numbered total of bit errors.
  • Limitations: cannot locate which bit is wrong; misses errors where an even number of bits change; does not protect against lost or reordered bytes.

Checksum

A checksum provides stronger detection by computing a numerical summary of a block of data at the sender and sending that summary alongside the data. The receiver recomputes the summary and compares. If they differ, an error is signalled. There are various checksum algorithms; a simple approach for teaching is to sum all bytes and keep, for example, the lowest 8 bits (modulo 256). Some systems also use the ones’ complement of the sum.

How a simple 8-bit checksum works

  1. Split the message into bytes. Example three bytes: 01010101 (85), 00001111 (15), 11110000 (240).
  2. Add the values: 85 + 15 + 240 = 340.
  3. Keep the low 8 bits: 340 mod 256 = 84. In binary: 01010100.
  4. Transmit the data followed by checksum 01010100.
  5. Receiver repeats the sum on received bytes and compares results.

Worked checksum scenarios

Sender sum = 340 → checksum 01010100. Receiver obtains the same three bytes, repeats the sum, gets 340, and the same checksum. Integrity passes; data accepted.

Suppose a bit flips in the second byte from 00001111 (15) to 00001101 (13). New sum = 85 + 13 + 240 = 338; 338 mod 256 = 82 → 01010010. This does not match the transmitted checksum 01010100; the receiver detects an error.

If two different bytes change in opposite directions such that their numerical changes cancel out, the simple sum may produce the same remainder. For instance, +2 on one byte and -2 on another can keep the mod-256 total unchanged. Basic checksums reduce this risk by including more structure (e.g. adding carries, ones’ complement) but no checksum is perfect.

Strengths and limitations of checksums
  • Strength: detects many more error patterns than single-bit parity, including many multi-bit errors and some bursts.
  • Flexible: can be computed over whole packets, not just single bytes.
  • Limitations: certain patterns can go undetected; stronger alternatives like CRC exist, but checksum remains common due to simplicity and speed.

Echo check

An echo check involves the receiver immediately sending back exactly what it received, so the sender can compare the echoed data with the original. If they differ, an error is assumed and the sender can retransmit. Echo checks are simple and useful on basic links (e.g. some legacy serial communications), but they use extra time and bandwidth because every message travels twice.

Echo check process

  1. Sender transmits a block of data.
  2. Receiver sends back the same block unchanged as the echo.
  3. Sender compares the echo to its original copy.
  4. If there is any difference, sender flags an error and resends if required.

Echo check scenarios

Sender transmits 01011010 10011100. Receiver echoes exactly the same bits. Sender compares and finds a match, so it assumes the message was received correctly.

If one or more bits are corrupted on the way to the receiver, the echo will contain those errors and not match the sender's stored original. The mismatch reveals a problem and the sender can retransmit.

It is possible for the forward transmission to be correct, but the echo becomes corrupted on the way back. The sender will still detect a mismatch and request a resend. This makes echo checks reliable for detection but potentially inefficient because a clean forward message can still trigger retransmission.

Comparing parity, checksum, and echo check

Method Extra data sent Detects Misses Typical use Overhead
Parity (odd/even) 1 bit per byte/character All single-bit errors; any odd number of flipped bits Even-numbered multi-bit errors; cannot locate error Legacy serial links, basic memory checks Very low
Checksum Several bits/bytes per block (e.g. 1 byte or 2 bytes) Many multi-bit and burst errors, depending on algorithm Certain offsetting changes; weaker than CRC Transport protocols, file transfer, simple packet integrity Low to moderate
Echo check Entire message duplicated on return path Any corruption that alters the echoed data None specific, but wastes bandwidth; can flag a clean forward as bad if echo corrupted Simple links, testing, interactive terminals High in time and bandwidth

Deep Dive: Why even-numbered errors escape parity

Parity only tests the parity of the total count of 1s. If two bits flip, the count changes by ±2, which does not alter whether the count is odd or even. Therefore, the parity rule can still appear correct when a genuine error has occurred. This is why parity is useful for quick checks but is not sufficient alone for high-reliability systems.

Protocol response to detection

Detection is only useful if the system reacts. Common responses include:

  • Automatic repeat request (ARQ): the receiver discards the bad packet and asks for a retransmission.
  • Negative acknowledgements (NAKs): receiver explicitly reports failure.
  • Timeouts: sender resends if no acknowledgement arrives within a set time.

These actions are outside the scope of the detection methods themselves but explain how detection techniques help ensure data integrity in real networks.

Terminology

  • Error detection: techniques that reveal data has been corrupted.
  • Parity bit: an extra bit set to maintain even or odd count of 1s.
  • Checksum: a value computed from data used to check integrity on receipt.
  • Echo check: receiver sends data back to sender for direct comparison.
  • Burst error: a series of adjacent bits corrupted by a short disturbance.
  • Noise: unwanted electrical or radio energy that interferes with the signal.
  • Attenuation: loss of signal strength over distance.

 Key Takeaways

  • Transmission errors arise from noise, attenuation, interference, timing issues, and device faults, so detection is essential.
  • Parity adds one bit per byte to enforce even or odd totals of 1s; it detects any odd number of flipped bits but misses even-numbered errors.
  • Checksums summarise a whole block so they detect many multi-bit and burst errors with modest overhead.
  • Echo checks compare the receiver's echo to the sender's original, detecting mismatches but at the cost of extra time and bandwidth.
  • Error detection must be paired with a protocol response such as retransmission to ensure correct delivery.
  • No single method is perfect; choice depends on reliability needs and overhead constraints.