Every now and then a project comes into the Hackaday feed that has so many levels of wrong about it that you really shouldn’t do it at home, but is amusing enough to feature anyway with a warning. So it is with [ArcaEge]’s Capacitor Alarm Clock, which wakes up its unfortunate owner by blowing up electrolytic capacitors with reverse voltage. If you survive, you’ll certainly be awake!

It’s inspired unsurprisingly by an [ElectroBoom] video, and the premise is simple enough. An ESP32 serves as the clock, and triggers a relay for the alarm, which in turn overloads a suitably low-voltage electrolytic capacitor in a socket. The resulting explosion which appears in a video we’ve placed below the break, wakes the slumberer.

We don’t have to tell you that this is not the safest of hacks, and is presented here only for your entertainment. But it does provide a few points of interest, for example in identifying the difference between capacitors with a vent, and those without.

This isn’t the first time we’ve seen a project based around exploding capacitors, and that one maybe was a don’t-do-this-at-home too.

One of the joys you get to experience whether as a proud parent or pet owner is that a lot of things get left around haphazardly. You could of course pick every piece of discarded clothing, half-destroyed toy and detritus yourself, but as a parent of three children himself [Nathaniel Nifong] opted to use his engineering background to potentially over engineer a wires-suspended robotic claw to do this picking up for him.

What he calls Stringman robots requires an anchoring point at four corners of a room, after which the robotic crane can then scour across the ceiling, identify targets to pick up and move these to predesignated drop-off points. It’s an open source project with the LeRobot-based firmware available on GitHub in addition to build instructions for the physical hardware. There’s also a pilot run of ready to use hardware and kits for those who want to trial it, but aren’t interested in building it themselves via [Nathaniel]’s company website.

The basic idea is that this crane can run for an hour or so and deal with the mess in its room without having to do anything yourself. The process isn’t perfect yet, of course, with the underlying diffusion transformer to implement machine vision requiring more refinement. The gripper itself struggles with objects like books, which can be a concern for parents and bookworms, and of course while the crane is operating the wires will dip down as a potential risk to anyone in the room.

Compared to an overhead crane like a traditional bridge crane this wire-suspension crane is probably more stable, but either is an interesting engineering challenge when applied to a household. Next it would probably also be cool if items could be put away where they belong instead of dropped into a bin, as so far that task will still be left to deal with by the adult humans.

Want to make your own ergonomic mouse but don’t know where to start? Why not try [psudoku]’s Kotinos design?

It’s a scaffold-like fingertip shell that uses the internals of an HSK Pro mouse. Each fingertip gets its own little saddle-shaped nook, and things like hand size and paddle surface can all be configured by modifying the OpenSCAD scripts.

[psudoku]’s unit looks to us as though it was maybe made using multi-jet fusion (MJF) 3D printing, but it should be perfectly printable on hobbyist printers, whether resin- or filament-based.

Comfort of the contact surfaces is left up to the end user, but if your print lacks smoothness and sanding isn’t your jam, you might consider a layer of fabric tape to create a velvet-like surface on a 3D print. That’s a trick we’ve kept in mind ever since seeing it put to good use, cushioning the hardware in a DIY steam deck case.

Is the minimalist scaffold approach to a mouse not your style, or does your hand crave something less lightweight but a little more personalized? You might want to craft a truly custom-fitted mouse, for which clay is the way.

You have to be a pretty big aviation nerd to know about [Willard Ray Custer] and his channel wing concept, but if you are, you’ll be giddy to hear about the semicircular profile of the HopFlyt Cyclone drone’s tandem wings. If you’re not quite that much of a nerd, please keep reading, because it’s a really neat concept that never — er — quite got off the ground.

[Custer]’s idea was pretty simple, and born of a shift in reference frame — he realized that only the relative wind over the wing mattered, not the airspeed of the entire aircraft. The same idea drives every blown-wing short-takeoff-and-landing (STOL) project from the DHC-7 turboprop airliner to the An-72 cargo jet: air from the engines washes over the wings, creating lift. Where [Custer] went further is that rather than blowing air over a straight wing, he wrapped the wing under the propeller in a semicircle to maximize the area of lower pressure — and thus lift — creating the “channel wing” that bears his name.

Theoretically, an aircraft with channel wings and powerful enough engines might be able to do vertical takeoffs just from the blown lift, but none of [Custer]’s prototypes demonstrated that — just excellent short-field capability. The HopFlyt drone would be the same, except that, being a tandem, it has double the channel wings of [Custer]’s more-conventional designs, and it’s also a tilt-wing to boot. In that mode, the added low-speed lift from the channel wing makes transitions easier than they otherwise would be — which isn’t anything to sneeze at, since transitioning from vertical to horizontal flight has always been the real bane of VTOL projects.

They’re claiming a reduced fuel burn of 10% in hover and transition thanks to the extra lift from the channel wings. You can see their prototype in action in the demo video embedded below. We once featured a project that went even further, blowing air across a special hollow wing for propulsion and blown lift. The easiest eVTOL project still starts with a quadcopter, though.

Microsoft has a history of taking accessibility options seriously for gaming controllers, and that trend continues with downloadable thumbstick toppers for Xbox controllers. Being straight from the source, the 3D models should fit as well as can be expected with a minimum of fiddling. Just make sure you select the right controller model, because they are each subtly different.

The toppers themselves come in different styles, and there’s a design to fit a variety of needs, from a thumb cradle to ones intended for more serious adaptations —  the perforated X-shaped topper, for instance, is meant to anchor a custom shape molded overtop it.

Microsoft does offer a remarkably hackable adaptive controller that is meant to make it easy to integrate with other hardware, and we’ve seen it used in some truly awesome ways. But it’s nice to see an easy way to extend and adapt normal thumbsticks on regular controllers, giving people even more options.

We love to see companies offer useful 3D models of their products, saving consumers from having to 3D scan or model things themselves. It’s a form of hacker-friendly hardware design, which we celebrate when we see it, while at the same time wishing it were more common.

Have you benefited from hacker-friendly design and made something useful that wouldn’t exist otherwise? Let us know on the tips line!

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.

There are many ways to deal with keys: a bowl next to the entryway, a junk drawer, or you can just leave them in your pockets and hope you remember to check on Laundry Day. [Inventive Robin] has come up with his own, unique take on the key holder concept: he’s got piano keys to hold his car keys, CNC’d out of some nice hardwoods.

Of course, it’s not just a fake one-octave piano with hooks glued to it; that wouldn’t be quite enough to catch our fancy. There’s a mechanism hidden under the “white” keys– made of maple– that lowers the brass hooks when you press the, er, wooden actuator, so you can retrieve your, uh, lock-openers. Keys, that is. They’re both keys, of different sorts, because English is a wonderful language. In any case, pressing the maple key a second time lifts the brass hook, trapping the likely metal key hanging on it.

The mechanism was carved from acetyl sheet on the same Shapoko CNC machine that handled the wood, and was assembled with purchased metal rods, springs, and some plastic standoffs. It’s very satisfying to watch it work unenclosed, so check out the build video embedded below to see that in action– jump to 4:46 if you don’t want to get the whole design brief.

It’s not the most complex of hacks, but it’s beautifully done inside and out, and [Robin] is clearly happy with the result. It’s nice enough that visitors might want to photograph the key holder, but perhaps have them do it sans keys– those photos could potentially be a security risk.