Summary — What This Chapter Covers

• Why errors happen: interference (wired or wireless) causes data loss, data gain, or data change.
• Why we check: computers need data in an expected format — unexpected data is hard or impossible to interpret correctly.
• Parity check: adds one extra bit per byte so the total number of 1s matches an agreed rule (odd/even). Detects an error but not .
• Parity block & parity byte: parity calculated both horizontally (per byte) and vertically (per bit-column) — this combination can actually the faulty bit.
• Checksum: a calculated value sent alongside data; recalculated by the receiver and compared. Mismatch = error, but no location given.
• Echo check: receiver sends the data straight back to the sender to compare — simple, but not fully reliable (error could occur on the way back too).
• Check digits: one extra digit at the end of a numeric code (ISBN, barcodes) calculated by an algorithm to catch mistyped, missing, extra, or swapped digits.
• Automatic Repeat reQuest (ARQ): a protocol using acknowledgements and timeouts to automatically request re-transmission of corrupted or missing data.

1  Why Errors Occur

Interference is the root cause

Think of data transmission like sending a message by shouting across a windy field versus passing a note by hand. Along the way, things can interfere with the message and change it — that's exactly what happens electronically too.

Wireless technology (radio signals, Wi-Fi, Bluetooth) can be disrupted by:

• Physical barriers — buildings, walls, cars, even your own body standing in the way
• Bad weather — rain, clouds, storms
• Other wireless signals or electromagnetic radiation "talking over" your signal

Wired technology is actually prone to error overall, because physical cables can:

• Get damaged or degrade over time
• Pick up interference from nearby electrical sources
• Suffer from interrupted or intermittent connections, causing data loss

The three ways interference shows up

Why checking even matters

Computers only understand data that arrives in an expected format — an agreed way of arranging data so both sender and receiver interpret it the same way. Dates are a classic example: 13/04/14 could be DD/MM/YY, and 12/31/2020 is clearly MM/DD/YYYY (since there's no 31st month). But what about 04/03/17? Is that 4th March or 3rd April? Without an agreed format and error checking, ambiguous or corrupted data leads to misinterpretation — and in the real world, that can mean wrong dates, wrong amounts, wrong instructions.

2  Parity Check

The core idea

Imagine every byte of data has to arrive with an "ID badge" — one extra bit tacked on called the parity bit. Before anything is sent, the sender and receiver agree on a rule: either every byte must contain an odd number of 1s (odd parity), or every byte must contain an even number of 1s (even parity) — always counting the parity bit itself.

The parity bit's value (0 or 1) is chosen specifically to make that rule true. When the byte arrives, the receiver counts the 1s again. If the count no longer matches the agreed rule, something has changed in transit — an error has been detected.

Worked example — Even parity

Counting the 1s in the byte (not the parity bit yet): 1,1,1,1 = four 1s. Four is already even, so for even parity to hold, the parity bit must be 0 (adding a 1 would push the total to five, an odd number, which breaks the rule).

Worked example — Odd parity

Again, four 1s in the main byte. Four is even — but we need an odd total, so the parity bit must be 1, bringing the total to five 1s (odd). ✓

How an error actually gets caught

Say a byte was sent using ODD parity, with parity bit = 1 and byte 1101011 (five 1s, total 6 including parity bit — wait, that's wrong for odd... let's check a real example from the transmission table below where interference has flipped a bit):

In example #1, six 1s is an even number — but the agreed rule was odd parity, so a mismatch is flagged: an error occurred somewhere in that byte. Notice it doesn't say bit is wrong, only something is wrong.

3  Parity Byte & Block Check

Upgrading parity to actually locate the error

A single parity bit per byte tells you an error happened, but not . The clever fix: apply parity twice — once across each row (byte), and once down each column (bit position). The column parities are collected into an extra row at the bottom called the parity byte, which is calculated before transmission and sent along with the rest of the block.

Now, if a single bit flips, it breaks its row's parity its column's parity. By cross-referencing which row and which column are "wrong," you can pinpoint the exact cell that flipped — like coordinates on a grid.

Mini worked example (using ODD parity)

In this snippet, Byte 3's row parity doesn't add up correctly for odd parity, and the Bit5 column parity byte also flags a mismatch. Cross-referencing points straight at the Byte 3 / Bit 5 cell (highlighted) — it should actually be a 0. Once the exact bit is identified, it can either be automatically corrected, or a retransmission can be requested.

4  Checksum

A checksum works a bit like weighing a parcel before and after it's shipped. Before sending, the sender runs the data through an algorithm to produce a single value — the checksum — and attaches it to the transmission. When the data arrives, the receiver runs the algorithm on the received data and compares its result to the checksum that was sent.

Just like a basic parity check, a checksum tells you the data differs from its original form — but not the difference is.

5  Echo Check

This is the simplest method conceptually: the receiver just sends the data straight back to the sender, like an echo bouncing off a canyon wall. The sender then compares what it gets back to what it originally sent.

If an error is detected, the sender simply retransmits the original data.

6  Check Digits

What they are

A check digit is the last digit tacked onto a numeric code, calculated by a standardised algorithm. It's specifically designed to catch mistakes made when someone (or something) types or scans in a numeric sequence — things like:

• Incorrect digits entered (a "5" typed as an "8")
• Omitted or extra digits (missed one, or added one too many)
• Phonetic errors (numbers that sound alike being mixed up, e.g. "fifteen" vs "fifty")

ISBN book numbers

Every book has a unique ISBN. A standard ISBN might look like 965-448-765-9, where the final digit (9) is the check digit. This digit is deliberately chosen so that when the check digit algorithm is applied to the whole number, the result comes out as a whole number with no remainder. If, after entering the ISBN, the algorithm produces a result with a remainder, the ISBN is flagged as invalid — meaning a digit was probably mistyped somewhere.

Barcodes

Barcodes are made of black and white lines. A scanner shines a laser across them; the black lines absorb the light and the white lines reflect it back into the scanner. The scanner measures the distances between the lines and converts that into a sequence of digits that uniquely identifies the item. Just like ISBNs, the final digit is the check digit, used to validate and authenticate that the barcode was scanned/entered correctly.

7  Automatic Repeat reQuest (ARQ)

ARQ is less about detecting an individual bit error and more about the overall protocol (set of rules) that manages what happens once an error is spotted. Think of it as a conversation with confirmations built in — like texting someone and expecting a "seen" tick, and resending your message automatically if you never get one.

What to Memorise

Concepts Checklist

• I can explain why errors occur in wired and wireless transmission
• I can describe the three outcomes of interference (data loss, gain, change)
• I can calculate a parity bit for a given byte, for both odd and even parity
• I understand why a simple parity check cannot detect every error
• I can explain how a parity block/parity byte pinpoints the exact corrupted bit
• I can describe how a checksum is calculated and used to detect errors
• I can explain how an echo check works and why it's not fully reliable
• I can describe what a check digit is and give real-world examples (ISBN, barcode)
• I can explain the full ARQ process, including acknowledgements and time-outs

Exam Tips & Common Mistakes

• Detecting vs locating: Basic parity checks and checksums only tell you an error occurred, not . Only a parity block/parity byte combination can pinpoint the exact bit. Examiners love testing this distinction.
• Don't forget the parity bit itself when counting: When checking whether parity is odd or even, always count the parity bit as part of the total — a very common slip is only counting the "data" bits.
• Know the parity check's blind spot: If asked "why might an error not be detected using parity," the answer is about an even number of bits changing or bits being swapped/transposed — not just "sometimes it doesn't work."
• Echo check ≠ 100% reliable: A common trap is assuming sending data back confirms it's correct. Remember: the error could occur on the return journey too.
• ARQ terminology: Be ready for either "Automatic Repeat Query" or "Automatic Repeat reQuest" — both appear in past papers and refer to the same thing.
• Check digits are about numeric codes specifically (ISBN, barcodes) — don't confuse them with parity bits, which work on binary data during transmission.
• Use exact terminology in extended answers: "positive/negative acknowledgement," "time-out," "checksum," "parity bit" — mark schemes reward precise vocabulary, not just the right idea in vague words.