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.

A pacemaker is implanted to send signals that regulate a patient’s heartbeat, and to do that, you need power. That means they require battery changes, and when the device in question happens to be inside your chest, that means surgery. Sometimes as often as every five years. [Alex Music] writing in Spectrum notes that researchers have a new paper discussing a possible alternative: a tiny patch stuck to the outside of the chest that uses ultrasound to pace the heart rhythm.

Rats, pigs, and human heart cell samples have all responded to the system. You might wonder how ultrasound could make your heart beat, but the new pacemaker relies on gene therapy to sensitize your heart cells to the high-frequency waves. The therapy is delivered by a simple injection.

In addition to the chest patch, the patient would need a data and power module that they could keep in their pocket. The gene therapy doesn’t alter your DNA but introduces RNA to make heart cells produce a sound-sensitive protein in the cell’s ion channels. When stimulated, the ion channels admit calcium, which causes the heart to beat.

Pacemakers are nothing less than a modern technological marvel. Maybe if this catches on, cheap junked pacemakers will show up on the surplus market. They could be useful.

We were excited to see [Z0hn]’s project about 3D printing a custom watch from scratch — both because it was an exciting idea, and because the pictures looked great. While we still liked the project, we quickly realized it wasn’t really printing a watch so much as it was printing a case that holds an off-the-shelf movement. But it still looked great.

Many homebrew watches are cool and fine to wear to your next hackerspace board meeting. But this watch wouldn’t raise an eyebrow out among the normal public. Conventional watches use press-fit backs, tiny screws, or make the back screw into the housing. None of those are great for 3D printing, so this watch uses a bayonet connector, which is easy to create, robust, and reliable.

The watch looks easy to modify, so if you don’t like, for example, the unusual crown placement, you can change it. The movement is a Miyota 8N24 and, of course, the crystal is off-the-shelf, too.

While not exactly a printed watch, it was still pretty cool, and there are lessons to be learned here if you want to pull off the same feat. Or just go full on hacker. You could, too, try your hand with an open source movement.

We are fans of macro pads and especially homebrew ones. The Apna Dost project by [np_vishwakarma] ticks most of our boxes. In addition to a few buttons, there’s an encoder, an OLED display, and it runs QMK firmware. Plus, it looks good, too.

We like that the system uses an RP2040. It is possible you have everything you need to put one of these together right now. We would wish for a few more keys, but it wouldn’t be hard to add them, either.

Perhaps we would have laid it out so the OLED could more easily label the macro keys, but — again — you could do that easily if you wanted to build your own. We did like that encoder could serve multiple purposes.

It always ticks us off when cheap macro pads you buy don’t use QMK or some other reasonable firmware. This one does, though, so it should be very easy to modify and customize.

We converted an old conference badge to a QMK macro pad of sorts. If you want a real deep dive on a much larger macro pad, that’s out there, too.

When you think of a computer, you probably don’t think of a tube full of motors and mechanics. However, as [Our Own Devices] shows, the Bendix AN5841 API Computer, an air position indicator computer, is exactly that. Using mechanical integrators and data from other analog systems on an airplane to provide key flight data to a pilot. You can see the video below.

These devices were made for military aircraft, including the B-29. It is odd that speed data can be derived from a pump that balances pressures using a fan. The video does a good job of explaining exactly how that works.

The way engineers used mechanics to convert physical measurements into analog computations is nothing short of amazing. You have to wonder how you dream up this kind of stuff. Perhaps mechanical engineers wonder the same thing about electronics. But we sort of doubt it.

We are glad our computer doesn’t have any flexible shafts or rotating disks to do math. But we do love looking at ones that did. Some analog computers used voltages instead of mechanics. This video made us think of the M13A1 ballistic computer and, of course, the Norden.

What counts as portable is somewhat a matter of opinion, especially over the years. [Helge Fykse] has a portable spy radio of Swedish origin. For its time, it was considered very portable, crammed into a good-sized suitcase.

You can see the large crystal that sets the transmit frequency and a key to send Morse code. The receiver has a VFO, so it was more agile. Based on the regenerative knob, it appears the receiver was of the regenerative type. The suitcase had its own battery, and with tubes, it could probably put out some kind of signal if connected to anything metal, like bedsprings, a clothesline, or anything. There was a lightbulb to let you see when you were transmitting maximum power.

Speaking of tubes, there were five inside, two for the transmitter and three for the receiver. The radio had storage for spare tubes, and the agent could maintain the radio in the field.

You not only get a peek inside the suitcase, but a look at the schematic. The radio is a model of simplicity, but we are certain it did its job.

We love looking at exotic spy gear, especially radios.

An old algebra teacher used to say, “You have to take what you know and use it to get what you don’t know.” You might say the same thing about converting analog signals into digital. Computers know how to count and keep time. [Eric Explains] has a video purporting to explain “every type of analog-to-digital converter.” We aren’t sure he got every possible method, but there’s still a lot of information in the video, which you can see below.

From the flash ADC, using a ton of comparators to the successive approximation converter, which essentially plays a game of hi/lo, guessing the answer and figuring out if the real answer is higher or lower.

Those are pretty common, but the video also covers things like the Wilkinson ADC and other more exotic techniques. Each method, of course, has its advantages and disadvantages. For example, the flash ADC is fast, but requires a lot of components and power.

Sometimes, the method you use depends on how you are building. For example, you probably wouldn’t use a charge system on a breadboard since precision capacitors are finicky. But on an integrated circuit, capacitors made with photolithography may not be very precise, but the ratio between capacitors is super precise, making that a common technique in that domain.

Even if you never need to design your own converter, understanding the different architectures will let you make a better selection among alternatives. Then again, you can design your own. We’ve seen most of these architectures in past projects.