Every time your laptop reads RAM, an ESP32 pulls a firmware image off flash, or a LoRa sensor packet survives a noisy rooftop in Quezon City, some form of error correction is quietly fixing bits that arrived wrong. The idea behind all of it started with one engineer, one unreliable machine, and a string of ruined weekends.
A relay computer that gave up on weekends
In the late 1940s, Richard Hamming was a mathematician at Bell Labs. He had access to one of the lab's electromechanical relay computers, but only for low-priority work, which in practice meant jobs that ran unattended over the weekend.
The machine could already detect certain errors. Its input and internal checks would notice when something did not add up. During the week, an operator would see the alarm, fix the problem and restart the job. On weekends, with nobody watching, the machine did the only thing it was designed to do: it dropped the failed job and moved to the next one in the queue.
Hamming would come in on Monday to find his work abandoned. After this happened more than once, he asked the question that changed computing: if a machine can tell that an error happened, why can it not work out where it happened and fix it?
His answer was published in 1950 in the Bell System Technical Journal as "Error Detecting and Error Correcting Codes." It is one of the founding papers of coding theory, and it is a large part of why Hamming later received the Turing Award.
How a Hamming code finds the flipped bit
Simple parity was already well known. Add one extra bit so the total number of 1s is even, and if a single bit flips, the count comes out odd. That tells you something went wrong, but not what.
Hamming's trick was to use several parity bits, each covering a different, overlapping subset of the data. The classic version is Hamming(7,4): 4 data bits plus 3 check bits, 7 bits total.
- The check bits sit at positions 1, 2 and 4 (the powers of two).
- Each check bit covers every position whose binary number has that bit set.
- When a word is read back, you recompute the three checks. The pattern of which ones fail, read as a binary number, is the position of the flipped bit.
If check bits 1 and 4 fail but 2 passes, that is binary 101, position 5. Flip bit 5 back and the data is correct. No retransmission, no human, no lost weekend.
Three extra bits to protect four is expensive, but the overhead drops fast as words get longer. Add one more overall parity bit and you get SECDED: single-error correction, double-error detection. That extended form is the basis of classic ECC memory, where 64 data bits travel with 8 check bits and a server can shrug off a bit flipped by a cosmic ray.
Where error correction shows up in IoT and embedded systems
Hamming codes themselves are the simplest member of a large family, but the thinking runs through almost every layer of a connected device.
Flash storage. NAND flash wears out and leaks charge over time, so bit errors are expected, not exceptional. Controllers use stronger descendants such as BCH and LDPC codes, but the principle is Hamming's: store extra check bits and repair on read.
Wireless links. LoRa lets you pick a coding rate from 4/5 to 4/8, literally trading airtime for redundancy so packets survive interference and distance. Wi-Fi, Bluetooth and cellular all use forward error correction for the same reason. In the Philippines, where devices often sit in humid enclosures, on rooftops or at the edge of coverage, that margin is the difference between a sensor that reports and one that goes silent.
Firmware and OTA updates. CRCs and hashes do not correct errors, but they apply the detection half of the same idea: never boot an image you cannot verify. A good OTA design checks before it switches partitions, and keeps the old image when the check fails.
Harsh environments. Industrial and automotive microcontrollers increasingly ship with ECC on internal SRAM and flash, because electrical noise, heat and radiation all flip bits in the field that never flip on the bench.
The lesson for anyone building devices
Hamming did not make the relay computer more reliable. He accepted that it would fail and designed around the failure. That is still the right mindset for IoT: assume bits will flip, links will drop and power will sag, then build detection and recovery into the hardware, firmware and protocol from the start.
If you are building a connected product, thesis prototype or sensor network and want that reliability designed in rather than debugged in the field, talk to our engineers or look at our IoT and embedded development services.
Originally published at fluidwire.com.
