Error Detection and Correction·Lesson 1 of 9
Error Detection and Correction
The Problem: Bits Get Corrupted
Everything a computer sends across a network is ultimately a stream of — 0s and 1s. Those bits travel as physical signals: pulses of electricity on a copper wire, flashes of light in a fibre cable, or radio waves through the air. The trouble is that the real world is noisy. Electrical interference, a weakening signal, or a stray burst of static can nudge a signal just enough that the receiver reads a 0 where the sender meant a 1. When that happens, the data has been corrupted.
The one big idea
We can't stop noise from flipping bits, so instead we plan for it. The sender adds a few extra check bits calculated from the data. The receiver redoes the same calculation and compares — if the numbers disagree, it knows something got corrupted along the way.
Like a tamper-evident seal
When a shop ships a parcel, it often adds a packing slip that lists exactly what's inside and seals the box. When you open it, you check the contents against the slip. If they don't match, you know the parcel was damaged or messed with in transit. Error detection works the same way: the extra check bits are the packing slip for your data.
Why Do Bits Go Wrong?
A signal starts out clean but weakens and picks up interference as it travels. Common culprits are electrical noise from nearby motors or power lines, crosstalk (a signal on one wire leaking into a neighbouring wire), a signal fading over a long distance, and sudden spikes like a lightning strike. Any of these can distort the signal enough that the receiver misreads one or more bits.
It helps to picture the simplest possible setup: one sender, one receiver, and a single link between them. Noise can strike anywhere along that link, so every scheme in this topic is really about protecting the data on its trip from one end to the other.
The Core Trick: Redundancy
Every method here relies on one idea: . The sender attaches extra bits that carry no new information of their own — they are calculated purely from the real data. Because both sides know the formula, the receiver can recompute those bits from the data it received and check whether they still match. If they don't, the data changed in transit.
Two Jobs: Detect or Correct
There are two different things you might want to do about errors. The first is error detection: simply find out that the data got corrupted, then usually ask the sender to send it again. The second is error correction: add enough extra bits that the receiver can not only spot the error but also figure out exactly which bit flipped and fix it on its own, without asking for anything to be resent.
Detect is cheaper, correct is smarter
Detecting an error needs only a few extra bits but relies on a resend to actually fix things. Correcting an error needs many more extra bits and more computation, but it avoids the round trip of asking again.
The Main Techniques
Four techniques come up again and again, and they're the sections that make up this topic. Three of them only detect errors; the last one can actually correct them. Here they are at a glance:
Parity Check
Adds a single bit so the count of 1s stays even (or odd). The simplest check of all — catches one flipped bit, but misses many.
Checksum
Adds up the data into a small summary value. The receiver re-adds and compares. Used by the internet's IP, TCP, and UDP protocols.
CRC
Treats the data as one big number and divides it by an agreed value, keeping the remainder as a fingerprint. Very strong — used by Ethernet and Wi-Fi.
Hamming Code
Uses several overlapping parity bits so the receiver can pinpoint the exact bit that flipped and fix it — no resend needed.
The table below lines them up by what job each one does and how strong it is. Notice the trade-off: the further down the list, the more errors it catches, but the more work and extra bits it takes.
| Method | Job | In one line |
|---|---|---|
| Parity check | Detect | One extra bit; catches a single flipped bit |
| Checksum | Detect | Sums the data; catches many errors; runs the internet |
| CRC | Detect | Division-based; excellent at catching bursts of errors |
| Hamming code | Correct | Locates and repairs a single-bit error on its own |
“"Error detection means the network automatically fixes the mistake."”
Why This Matters
Without these checks, a single corrupted bit could turn a bank transfer of 100 into 1,000, or garble a file with no one noticing. Error detection and correction are what let you trust that the web page, message, or download you received is exactly what was sent. Nearly every layer of networking builds in some form of this — which is why interviewers love asking how a receiver knows its data arrived intact.
Q:How does a receiver know that the data it got is corrupted?
A: The sender adds redundant check bits computed from the data (a parity bit, a checksum, or a CRC value). The receiver runs the same computation on the data it received and compares the result. If they disagree, at least one bit changed in transit. Detection schemes stop there and trigger a resend; a correction code like Hamming goes further and repairs the bit itself.
Quick Revision Cheat Sheet
Problem: Noise on the link can flip bits (0 becomes 1 or vice versa)
Core trick: Redundancy — add extra check bits computed from the data
Detection: Find that an error happened, then resend (parity, checksum, CRC)
Correction: Locate and fix the error at the receiver (Hamming code)
Trade-off: Detection needs fewer bits; correction avoids a resend