Sometimes you’re looking for a component for a project that you know should exist, but you just cannot find it. Something like a 14-segment LED display, but not just one with a fixed color, instead you want some of that sweet addressable RGB-ness. Unfortunately for [EastMakes], this particular display was nowhere to be found, so he decided to try making his own.

Using addressable SK6805 RGB LEDs with a mere 1.5 x 1.5 footprint as the basis, the layout for these individual LEDs on the PCBs was determined, and a layout created in KiCad. The PCB manufacturing and assembly were straightforward enough — the thing that really makes these displays is the diffuser. Here a few different approaches were tried, including FR4 with translucent segments in the soldermask, and a 3D printed version in both white and black PLA filament.

The FR4 approach using 0.8 mm thin PCBs looked quite all right, with the addition of through vias in the 1 mm version showing how these help to boost overall brightness. The 3D printed version prototypes didn’t look too shabby either, but it would probably help a lot if this diffuser panel also fit around the LEDs to prevent light bleeding between segments.

We’d love to see this type of RGB display being experimented with, as it seems to hold a lot of promise while also definitely being something that ought to exist.

youtube.com/embed/2100sdgQtL4?…

hackaday.com/2026/02/11/design…

Sometimes the simplest objects need some overthinking. This is exactly what [Chris Borge] realized when using his 3D scanner and finding that the included rotation table left quite a bit to be desired — providing him the perfect excuse to build a new one.

One of the main features of a rotation stage is the, well, rotation. This was done in [Chris]’s case with a NEMA 17 stepper motor, perfect for precise rotation of scanning. Hooking up the motor to a basic perf board with an Arduino Nano allows for on the fly adjustments to rotation speed. To really solidify the over-engineering, [Chris] applies his obligatory concrete mix to add some heft to the stage.

While the previous features could be removed/downgraded without much loss, the adjustable grid built into the top adds significant functionality. The grid is based on [Chris]’s past projects, which allows cross compatibility.

We love over-engineering here at Hackaday, especially when adding something new. For more prime overthought design, check out this over engineered egg cracker!

youtube.com/embed/GbyohbWr60A?…

hackaday.com/2026/02/10/scanni…

Airport runways seem pretty simple, just another strip of asphalt or concrete not unlike the roads that our cars drive upon every day. We can even use these same highways as landing strips in a pinch, so you’d assume that the engineering for either isn’t that dissimilar. Of course, you can use a highway for an occasional emergency, but a runway that sees the largest and heaviest airplanes taxi, take off and land on a constant basis is a whole other challenge, as detailed in a recent [Practical Engineering] video and its transcript.

When you consider that an Airbus A380 the take-off weight is up to 550 ton, it’s quite clear what the challenge is for larger airports. Another major issue is that of friction, or lack thereof, as the speeds and kinetic energy behind it are so much higher. One only has to look at not only runway overruns but also when one skids off sideways due issues like hydroplaning and uneven friction. Keeping the surface of a runway as high-friction as possible and intact after hundreds of take-offs, tail-strikes and other events is no small feat.

Of course, the other part of runway engineering is for when things do go wrong and an airplane enters the runway safety areas, or overrun zones. This usually provides some flat and clear space where an airplane can safely bleed off its kinetic energy, with the collapsing surface of the EMAS technology being one of the best demonstrations of how this can be safely and dramatically shortened.

Another aspect not covered here that is part of these overrun zones are frangible structures, such as any localizer antennae of ILS, lighting, etc. Frangible here means that the structure easily collapses when a heavy airplane crashes into it without causing significant damage to the airplane.

It was the failure of such a design process that doomed the crew and passengers of Jeju Air Flight 2216 in December of 2024, when the airplane during an emergency belly landing skidded over the end of the runway. Although there was a lot of open space after the ILS localizer array with just a flimsy wall and further level fields, the ILS array’s base contained a poured concrete base on which the airplane effectively pulverized.

youtube.com/embed/ZJqY1WLX4zA?…

hackaday.com/2026/02/10/the-co…

The door sensor in its new enclosures. (Credit: Dillan Stock)
A common sight in ‘smart homes’, door sensors allow you to detect whether a door is closed or open, enabling the triggering of specific events. Unfortunately, most solutions for these sensors are relatively bulky and hard to miss, making them a bit of a eyesore. This was the case for [Dillan Stock] as well, who decided that he could definitely have a smart home, yet not have warts sticking out on every single doorframe and door. There’s also a video version of the linked blog post.

These door sensors tend to be very simple devices, usually just a magnet and a reed relay, the latter signaling a status change to the wireless transmitter or transceiver. Although [Dillan] had come across recessed door sensors before, like a Z-wave-based unit from Aeotec, this was a very poorly designed product with serious reliability issues.

That’s when [Dillan] realized that he could simply take the PCB from one of the Aqara T1 door sensors that he already had and stuff them into a similar 20 mm diameter form factor as that dodgy sensor unit. Basically this just stuffs the magnet and PCB from an existing wart-style sensor into a recessed form factor, making it a very straightforward hack, that only requires printing the housings for the Aqara T1 sensor and some intimate time between the door and a drill.

youtube.com/embed/XVaGANL2T7o?…

hackaday.com/2026/02/10/making…

When [101 Things] didn’t want to copy Morse code, he decided to build a Pi Pico system to read it for him. On the face of it, this doesn’t seem particularly hard, until you look at the practical considerations. With perfectly timed dots and dashes, it would be trivial. But in real life, you get an audio signal. It has been mangled and mixed with noise and interference as it travels through the air. Then there’s the human on the other end who will rarely send at a constant speed with no errors.

Once you consider that, this becomes quite the project, indeed. The decoder captures audio via the Pi’s analog-to-digital converter. Then it resamples the input, applies an FFT, and converts the output via a complex classification pipeline that includes, among other things, Bayesian decoding. Part of the pipeline makes simple typo corrections. You can see the device do its thing in the video below.

Another issue with the code is that it decodes multiple channels in real time. So looking up spelling corrections, for example, has to be done rapidly. The device can also send code and show stats and graphics on an LCD screen.

If you know the code is arriving at a known speed, you could do something much simpler. The Pico has lots of memory which makes it easy to use complex algorithms. When you are memory-limited, you need different tricks.

youtube.com/embed/rBRf3QOt4wc?…

hackaday.com/2026/02/10/pi-pic…

As popular as the game of chess is, it has one massive flaw. This being that it requires two participants, which can be a challenge. Although playing chess on a computer against an AI has been a thing for many decades, it’s hard to beat physical chess boards that give you all the tactile pleasure of handling and moving pieces, yet merging the two is tricky. You can either tell the player to also move the opponent’s pieces, or use a mechanism to do so yourself, which [Joshua Stanley] recently demonstrated in a video.

There are a few ways that you can go about having the computer move and detect the pieces. Here [Joshua] chose to use Hall magnetic sensors to detect the magnets that are embedded in the 3D printed chess pieces as well as their absence. These sensors are mounted to the back side of a PCB which is also the playing field, thus using the silkscreen for the board markings.

For the electromagnet that moves the chess pieces core x/y kinematics were used to move it underneath the PCB, engaging when moving pieces but otherwise deactivated. This is all controlled by an ESP32 MCU, while the computer runs the open-source Stockfish chess engine. As the human player changes piece positions this is detected by the magnet’s presence, with the change input into Stockfish.

As the demonstration at the end of the video shows, it definitely works, yet some issues remain. Ignoring the mistake with making the near-right corners black instead of white, the pieces are large enough that e.g. moving a knight piece between others pushes them to the side, requiring these to be put back in place.

There is also no way for the computer to detect which piece is placed where, which can be incredibly helpful on some commercial self-playing chess boards like this for new players, as well as to detect invalid moves, but this might be on the list for a potential V2 of this build.

Best part of this build is probably the use of a PCB for the playing field, which would allow you to go pretty crazy with custom designs and colors, especially now that some PCB places are offering multi-color silkscreens that allow for custom graphics.

youtube.com/embed/tLgXvUgsYmw?…

hackaday.com/2026/02/10/buildi…

There are many adapters, dongles, and cables designed for interfacing display standards, and no doubt some of you have them in the glue of your entertainment system or work space. They’re great for standards, but what about something that’s not quite standard? [Stephen] has an arcade cabinet with a CRT that runs at an unusual 336 by 262 pixel resolution. It can be driven as 320 by 240 but doesn’t look great, and even that “standard” resolution isn’t supported by many dongles. He’s shared the story of his path to a unique USB to VGA converter which may have application far beyond this arcade machine.

We follow him on a path of discovery, through RP2040 PIOs, simple resistor ladder DACs, and home-made kernel modules, before he arrives at GUD, a USB display protocol with its own upstreamed Linux kernel driver. It’s designed to be used with a Raspberry PI deriving an LCD or HDMI display, but for his task he implemented the protocol on one of the more expensive STM32 series microcontrollers. The result after several false starts and some fiendish PCB routing is a standalone GUD-based USB-to-VGA converter that delivers perfect 34-bit colour at this unusual resolution, and also presumably others if required. It’s a worthwhile read for the many hints it gives on the subject of driving displays, even if you’re not driving an odd cabinet monitor.

hackaday.com/2026/02/10/the-be…