You send a file, but how do you know it arrived intact? In other words, how do you know that it didn’t get cut off, garbled, or changed somehow? Simplistically, you could just add up all the bytes in the file — a checksum — and send that along with the file. You compute the checksum when you know the file is good, and the receiver can compare the checksum to see if they match.

However, a simple addition doesn’t catch certain classes of errors, which is why there are better checksum algorithms that, for example, wrap the carry bit around or otherwise modify files with common errors so they produce different checksums. There are two problems with checksums. First, no matter how much you modify the algorithm, the chances that two files produce the same checksum are pretty high. Especially with common error patterns.

For example, assume a very simple algorithm that simply adds the bytes and discards any carry. If a file contains 0x80, 0x80, those numbers essentially cancel each other out. If you replace them with 0, 0, you’ll get the same checksum. To some degree, using anything other than a second copy of the entire file will have this problem — some corruption goes undetected — but you want to minimize the number of times that happens.

The other problem is that a checksum by itself doesn’t let you correct anything. You know the data is bad, but you don’t know why. If you think about it, the simplest checksum is a parity bit on a byte: odd parity is simply summing all the bits together. If the parity bit doesn’t match, you know the byte is bad, but you don’t know why. Any even number of errors goes undetected, but I am sure one-, three-, five-, or seven-bit errors will get caught.

People invent better error-checking codes by devising schemes that can promise they can detect a certain number of bit flips and, at least in some cases, correct them. One of these is the cyclic redundancy check (CRC). It is easy to think of the CRC as a “strong checksum,” but it actually works differently. What’s more, there isn’t just a single CRC algorithm. You have to select or design a particular algorithm based on your needs. Most people pick a “named” implementation like CCITT or Ethernet and assume it must be the best. It probably isn’t.

A CRC is a checksum in the broad sense: you feed it a message, and it gives you a small value that you append, store, or compare later. But unlike a simple additive checksum, a CRC is based on polynomial division over GF(2), which is a fancy way of saying “divide using XOR instead of carries.” That detail matters. It gives CRCs very strong guarantees against common classes of errors, provided you choose the right polynomial for the job. That’s the key. You must choose the right polynomial.

The Polynomial Machine

A CRC treats your message as a long binary polynomial. For example, the byte stream is interpreted as a sequence of coefficients: each bit is either present or absent. The CRC algorithm divides the message polynomial, after shifting it by the CRC width, by a generator polynomial. The remainder is the CRC.

In normal arithmetic, division involves subtraction and carries. In CRC arithmetic, subtraction is XOR. That is why CRC code often looks like this:

if (crc & topbit)
crc = (crc << 1) ^ poly;
else
crc <<= 1;

That loop is implementing polynomial long division, one bit at a time. The generator polynomial is the magic number. For a 16-bit CRC, the polynomial has degree 16. For a 32-bit CRC, degree 32. You will usually see it written as a hex constant, such as 0x1021 for CRC-16/CCITT or 0x04C11DB7 for the classic Ethernet/ZIP/PNG CRC-32. But the polynomial is not just an arbitrary constant. It determines what error patterns the CRC is guaranteed to detect.

What CRCs Catch

A well-chosen CRC can guarantee detection of all single-bit errors, many multi-bit errors, all burst errors up to a certain length, and a very high percentage of longer random errors. The key metric is Hamming distance, often abbreviated HD. If a CRC has HD=4 for messages up to a certain length, it detects all 1-, 2-, and 3-bit errors in messages of that length.

That last qualifier is important. CRC strength is not just “16-bit CRC good, 32-bit CRC better.” It depends on the maximum message length. A polynomial that is excellent for 32-byte embedded packets may be mediocre for kilobyte-size messages. A polynomial standardized decades ago may be familiar but not optimal.

[Philip Koopman’s] work at Carnegie Mellon is the go-to reference here. [Koopman] and [Chakravarty’s] paper on CRC polynomial selection for embedded networks specifically looked for good CRC polynomials for short embedded messages, and [Koopman’s] “Best CRC Polynomials” tables list polynomials by width and Hamming-distance performance. The important takeaway is that many standard polynomials were chosen for historical reasons, not because they are mathematically best for your packet size.

There are plenty of videos that explain CRC, but if you are going to watch a video, you might as well pick one of the many from [Phil Koopman] himself, like the one below.

Famous Does Not Mean Optimal

Take CRC-16/CCITT, polynomial 0x1021. It is found everywhere: telecom, embedded examples, and bootloaders. It is not a terrible polynomial, but it is not automatically the best 16-bit choice. [Koopman’s] tables include other 16-bit polynomials with better Hamming-distance behavior over useful embedded-message lengths.

Likewise, classic CRC-32 using polynomial 0x04C11DB7 is deeply entrenched because of Ethernet, ZIP, gzip, and PNG. But CRC-32C, the Castagnoli polynomial, is often a better general-purpose choice. It has excellent error detection properties over common message lengths and is also supported by hardware instructions on many CPUs. Intel added CRC32 instructions with SSE4.2, and ARM AArch64 also includes CRC acceleration for CRC-32 and CRC-32C.

Of course, standards matter if you have to meet the standard. But if you are designing a new private protocol between your sensor board and your controller, blindly copying the first CRC-16 example from the Internet is not engineering. Pick a polynomial based on your packet length and your risk model.

The Practical Embedded View

For very small messages, even an 8-bit CRC may be adequate. For moderate packets, a good 16-bit CRC is often enough. For firmware images or large records, 32 bits is more reasonable. The point is not to use the biggest CRC you can tolerate. The point is to choose a CRC width and polynomial that give the desired detection strength for your longest protected message.

Also, remember what a CRC does not do. It is not cryptographic. It does not stop malicious tampering. The point of a CRC is to detect accidental corruption, not protect against sophisticated hacking attempts.

Real-world CRC definitions also include bit reflection, initial value, final XOR value, and sometimes byte order conventions. Two CRCs can use the same polynomial and still produce different answers because those parameters differ. That is a common embedded debugging trap. Someone says “CRC-16,” and both sides implement different CRC-16s. CRC-16/IBM, CRC-16/CCITT-FALSE, CRC-16/XMODEM, CRC-16/KERMIT, and CRC-16/MODBUS are not interchangeable.

If you specify a CRC in a protocol document, include at least the width, the polynomial (which can be represented in different formats, by the way), the initial value, if you use reflection on the input or output, and any value to XOR the output with. It is also a great idea to include the computed checksum for ASCII “123456789” so anyone can compare their algorithm to yours.

If you are working with Linux systems, be sure to look at the cksum program which can use several CRC algorithms or other methods like sha1 and other digest-style methods.

Efficiency

Computing CRCs a bit at a time is compact, but it costs eight loop iterations per byte. In some cases, that’s ok, but for performance, you want a table if you can afford the memory. For a 16-bit CRC, the table is only 512 bytes and can be generated at compile time, if desired.

Many CPUs have CRC peripherals. Use them, but read the fine print to make sure they can handle your desired CRC. It is often a good idea to check a hardware implementation against a known-good software implementation before you send it out into the wild. You can do many CRC tests using an online tool. Of course, there are several out there.

Choosing a CRC Today

For a new embedded protocol, define the maximum length of data you need to check. Then decide how many bits of overhead you can afford. Then head to Koopman’s tables to pick a polynomial with good Hamming-distance performance for that length.

The CRC has been around for a long time. But it isn’t just something you grab off the shelf. You need to plan and understand the ramifications of picking different polynomials.

CRCs aren’t the only game in town. Credit card numbers, for example, use check digits. There are other ways you can identify and, in some cases, zap bit errors, too.

PCBs are traditionally designed with traces laid out to support a circuit full of electronic components. However, they’ve become increasingly popular as a way to produce functional visual artworks. This PCB map from [Jonathan] is a great example.

The PCB was designed as a map of the California East Bay area. The roads are laid out as the top-side copper layer, while the land and roads are used for the top solder mask layer, with the flipped land and roads area making up the solder mask on the bottom side. The map data itself was cribbed from Snazzy Maps. Behind the PCB, [Jonathan] mounted a 64 x 32 RGB LED array, which can be seen glowing through from behind the material. The LEDs are controlled by an ESP32, which grabs location data from [Jonathan’s] family member’s mobile devices over MQTT, and uses it to light their positions on the map. Files are on Github for the curious.

If you’ve got a family that is open to location tracking, and the money to pay for a custom PCB, you could probably recreate this project yourself. We’ve seen some other great PCB maps before, too, like this amazing metro tracker. Video after the break.

Typically, when we think of touch screens, we think of LCDs or OLEDs with a resistive or capacitive sensing layer laid over the top. However, a team from the University of Chicago has developed an entirely different type of touch-sensitive display that uses persistence-of-vision techniques.

The project is called BloomBeacon. It consists of a pair of spinning arms to create a stable round display in mid-air. One arm is covered in LEDs, while the other is covered with capacitive pads for touch sensing purposes.  The trick behind this device is evident in the name—the device uses soft, flexible arms which are hinged and “bloom” upwards as the device spins up to speed. This makes it safe to physically interact with the spinning blades while they’re in motion to create a touch-interactive display. The device can thus display user interface elements like buttons that the viewer can interact with by reaching out and touching them directly.

Normally we’d advise not sticking your fingers in a rotating piece of machinery, but in this case, BloomBeacon was designed specifically to make this safe. Even sticking your fingers or hand right through the spinning arms won’t cause injury.

We’ve featured some other cool POV projects over the years, like this neat volumetric display. Video after the break.

If it’s summer in a warm, humid climate, bugs can be the bane of your existence. A natural solution is to place a passive bug zapper to catch bugs at night. But what if that isn’t fancy enough? [Nicolas Boichat] spices it up with a passive bug zapper that tracks its kill count.

But how exactly do you detect a bug zap? With an antenna, of course! When a bug gets caught, it arcs, creating an electromagnetic pulse. A small loop antenna on the backside of the zapper receives the signal.

It was also in part an experiment to see how good you can “vibe-EE” and, well, mixed results. Claude was able to correctly identify basic concepts of EE needed here, but was largely worthless at making schematics. After some manual circuit doodling, then building, [Nicolas] successfully got an ESP32-C6 to detect the voltage spikes.

Of course, where there’s data, there must be a dashboard. Using existing graphing libraries and a custom PCB, [Nicolas] has the ultimate bug zapping experience.

We’ve covered a similar idea in the past, namely one based on current sensing.

Do you want to go back to an era when Windows was… simpler? Back when things worked, before the AI and the bloat took over your hard drive and RAM space in equal measure? You might like to give Classic 7 a spin (via The Register).

From the drop, we should state that Classic 7 is not Windows 7 at all. Instead, it’s a reskin of Windows 10, specifically, the IoT Enterprise LTSC version. This is a particularly attractive version of Windows 10, as Microsoft has promised long-term support in terms of security updates until 2032. It also strips out annoying consumer-focused bloat like the Xbox gaming overlay and Cortana, and it eliminates forced feature updates that have become the norm in modern Windows installs. Combine all those niceties with the clean and simple feel of the recreated Windows 7 interface, and you have a beautiful operating system that has everything you need and nothing you don’t.

There are, of course, some hurdles to jump over; you’d need to find an appropriate license for this version of Windows and all that jazz. But if you long for the days before Microsoft so cruelly eviscerated the Start Menu and started making everything worse, you might find that Classic 7 is for you.

[Thanks to Stephen Walters for the tip!]

Will your next project be a success? Only time will tell, but if you build [gokux]’s tiny ESP32 fortune cookie, we predict that, at the very least, there won’t be any crumbs involved.

After briefly entertaining the idea of shoving an ESP32 in a standard fortune cookie, [gokux] thought better of it and came up with this instead. Once shaken, this small gadget displays a fortune on its e-paper screen. It can store over 3,000 fortunes and works entirely offline, so you’re never without an oracle.

Inside you’ll find a Seeed Xiao ESP32-S3 Plus and a matching e-paper display board. [gokux] is detecting the shakes with an MPU-6050 accelerometer, and powers everything with a small Li-Po pouch.

If you tire of the fortunes that shake out, the small buttons on the left side will get you into the other modes, which are a dice roller and a coin flipper. Again, you just shake the thing until you get what you want. Be sure to check it out in the video after the break.

Want to know how an MPU-6050 works, and what it looks like under the hood? Yeah, we thought so.

[Jankbu] needed a new computer, but had little interest in purchasing a modern laptop off the shelf. Instead, it was time to build a cyberdeck with a neat modular design to suit his exact needs.

The heart of the build is a Raspberry Pi 5, which provides a good amount of computing power for regular tasks. It’s wrapped up in a 3D-printed enclosure with rail mounts on the back, along with a NOS 450 TKL mechanical keyboard, offering full-travel keys in a compact layout. The 10.1″ IPS touchscreen display is mounted on sliding rails to cover the keyboard when it’s not needed. A smattering of buttons live around the screen, in a manner akin to so many industrial controllers. On either side, the deck has large grab handles, with one side featuring custom horizontal and vertical scroll controls, while the other rocks a trackball.  Power is via NP-F batteries, which are more commonly used to run Sony camcorders.

Unlike so many cyberdecks, [Jankbu] didn’t just build the device to look cool—it also serves a practical purpose. It’s great for running Freecad, and the rail mounts on the rear make it perfect for mounting around the workshop during a job as needed. Files are on Github for those eager to learn more.

What’s fun about this build is that it’s not just a show piece, it’s something that gets used every day. That’s a testament to [Jankbu’s] well-reasoned design, that considered what the device was for before it was put together. We’ve featured plenty of other fantastic cyberdecks in the past, too. Video after the break.