Embossing Precision Ball Joints for a Micromanipulator

[Diffraction Limited] has been working on a largely 3D-printed micropositioner for some time now, and previously reached a resolution of about 50 nanometers. There was still room for improvement, though, and his latest iteration improves the linkage arms by embossing tiny ball joints into them.

The micro-manipulator, which we’ve covered before, uses three sets of parallel rod linkages to move a platform. Each end of each rod rotates on a ball joint. In the previous iteration, the parallel rods were made out of hollow brass tubing with internal chamfers on the ends. The small area of contact between the ball and socket created unnecessary friction, and being hollow made the rods less stiff. [Diffraction Limited] wanted to create spherical ball joints, which could retain more lubricant and distribute force more evenly.

The first step was to cut six lengths of solid two-millimeter brass rod and sand them to equal lengths, then chamfer them with a 3D-printed jig and a utility knife blade. Next, they made two centering sleeves to hold small ball bearings at the ends of the rod being worked on, while an anti-buckling sleeve surrounded the rest of the rod. The whole assembly went between the jaws of a pair of digital calipers, which were zeroed. When one of the jaws was tapped with a hammer, the ball bearings pressed into the ends of the brass rod, creating divots. Since the calipers measured the amount of indentation created, they was able to emboss all six rods equally. The mechanism is designed not to transfer force into the calipers, but he still recommends using a dedicated pair.

In testing, the new ball joints had about a tenth the friction of the old joints. They also switched out the original 3D-printed ball mount for one made out of a circuit board, which was more rigid and precisely manufactured. In the final part of the video, he created an admittedly unnecessary, but useful and fun machine to automatically emboss ball joints with a linear rail, stepper motor, and position sensor.

On such a small scale, a physical ball joint is clearly simpler, but on larger scales it’s also possible to make flexures that mimic a ball joint’s behavior.

youtube.com/embed/NM2KXvRGmpg?…

hackaday.com/2026/03/04/emboss…

Vape-powered Car Isn’t Just Blowing Smoke

Disposable vapes aren’t quite the problem/resource stream they once were, with many jurisdictions moving to ban the absurdly wasteful little devices, but there are still a lot of slightly-smelly lithium batteries in the wild. You might be forgiven for thinking that most of them seem to be in [Chris Doel]’s UK workshop, given that he’s now cruising around what has to be the world’s only vape-powered car.

Technically, anyway; some motorheads might object to calling donor vehicle [Chris] starts with a car, but the venerable G-Wiz has four wheels, four seats, lights and a windscreen, so what more do you want? Horsepower in excess of 17 ponies (12.6 kW)? Top speeds in excess of 50 Mph (80 km/h)? Something other than the dead weight of 20-year-old lead-acid batteries? Well, [Chris] at least fixes that last part.

The conversion is amazingly simple: he just straps his 500 disposable vape battery pack into the back seat– the same one that was powering his shop–into the GWiz, and it’s off to the races. Not quickly, mind you, but with 500 lightly-used lithium cells in the back seat, how fast would you want to go? Hopefully the power bank goes back on the wall after the test drive, or he finds a better mounting solution. To [Chris]’s credit, he did renovate his pack with extra support and insulation, and put all the cells in an insulated aluminum box. Still, the low speed has to count as a safety feature at this point.

Charging isn’t fast either, as [Chris] has made the probably-controversial decision to use USB-C. We usually approve of USB-Cing all the things, but a car might be taking things too far, even one with such a comparatively tiny battery. Perhaps his earlier (equally nicotine-soaked) e-bike project would have been a better fit for USB charging.

Thanks to [Vaughna] for the tip!

youtube.com/embed/HwoZg3BCigU?…

hackaday.com/2026/03/04/vape-p…

FLOSS Weekly Episode 865: Multiplayer Firewall

This week Jonathan chats with Philippe Humeau about Crowdsec! That company created a Web Application Firewall as on Open Source project, and now runs it as a Multiplayer Firewall. What does that mean, and how has it worked out as a business concept? Watch to find out!

• github.com/crowdsecurity/crowd…
• crowdsec.net/feed/
• linkedin.com/company/53443483

youtube.com/embed/cFlhtWiCHNw?…

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or have the guest contact us! Take a look at the schedule here.

play.libsyn.com/embed/episode/…

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Places to follow the FLOSS Weekly Podcast:

• Spotify
• RSS

Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

hackaday.com/2026/03/04/floss-…

Linux Fu: The USB WiFi Dongle Exercise

The TX50U isn’t very Linux-friendly
If you’ve used Linux for a long time, you know that we are spoiled these days. Getting a new piece of hardware back in the day was often a horrible affair, requiring custom kernels and lots of work. Today, it should be easier. The default drivers on most distros cover a lot of ground, kernel modules make adding drivers easier, and dkms can automate the building of modules for specific kernels, even if it isn’t perfect.

So ordering a cheap WiFi dongle to improve your old laptop’s network connection should be easy, right? Obviously, the answer is no or this would be a very short post.

Plug and Pray

The USB dongle in question is a newish TP-Link Archer TX50U. It is probably perfectly serviceable for a Windows computer, and I got a “deal” on it. Plugging it in caused it to show up in the list of USB devices, but no driver attached to it, nor were any lights on the device blinking. Bad sign. Pro tip: lsusb -t will show you what drivers are attached to which devices. If you see a device with no driver, you know you have a problem. Use -tv if you want a little more detail.

The lsusb output shows the devices as a Realtek, so that tells you a little about the chipset inside. Unfortunately, it doesn’t tell you exactly which chip is in use.

Internet to the Rescue?

Note that most devices (including the network card) have drivers since this was taken after the driver install. The fingerprint scanner (port 5 device 3) does not have a driver, however.
My first attempt to install a Realtek driver from GitHub failed because it was for what turned out to be the wrong chipset. But I did find info that the adapter had an RTL8832CU chip inside. Armed with that nugget, I found [morrownr] had several versions, and I picked up the latest one.

Problem solved? Turns out, no. I should have read the documentation, but, of course, I didn’t. So after going through the build, I still had a dead dongle with no driver or blinking lights.

Then I decided to read the file in the repository that tells you what USB IDs the driver supports. According to that file, the code matches several Realtek IDs, an MSI device, one from Sihai Lianzong, and three from TP-Link. All of the TP-Link devices use the 35B2 vendor ID, and the last two of those use device IDs of 0101 and 0102.

Suspiciously, my dongle uses 0103 but with a vendor ID of 37AD. Still, it seemed like it would be worth a shot. I did a recursive grep for 0x0102 and found a table that sets the USB IDs in os_dep/linux/usb_intf.c.

Of course, since I had already installed the driver, I had to change the dkms source, not the download from GitHub. That was, on my system, in /usr/src/rtl8852cu-v1.19.22-103/os_dep_linux/usb_intf.c. I copied the 0x0102 line and changed both IDs so there was now a 0x0103 line, too:
{USB_DEVICE_AND_INTERFACE_INFO(0x37ad, 0x0103, 0xff, 0xff, 0xff), .driver_info = RTL8852C},
/* TP-Link Archer TX50U */
Now it was a simple matter of asking dkms to rebuild and reinstall the driver. Blinking lights were a good sign and, in fact, it worked and worked well.

DKMS

If you haven’t used DKMS much, it is a reasonable system that can rebuild drivers for specific Linux kernels. It basically copies each driver and version to a directory (usually /usr/src) and then has ways to build them against your kernel’s symbols and produce loadable modules.

The system also maintains a build/install state database in /var/lib. A module is “added” to DKMS, then “built” for one or more kernels, and finally “installed” into the corresponding location for use by that kernel. When a new kernel appears, DKMS detects the event — usually via package manager hooks or distribution-specific kernel install triggers — and automatically rebuilds registered modules against the new kernel headers. The system tracks which module versions are associated with which kernels, allowing parallel kernel installations without conflicts. This separation of source registration from per-kernel builds is what allows DKMS to scale cleanly across multiple kernel versions.

If you didn’t use DKMS, you’d have to manually rebuild kernel modules every time you did a kernel update. That would be very inconvenient for things that are important, like video drivers for example.

Of course, not everything is rosy. The NVidia drivers, for example, often depend on something that is prone to change in future Linux kernels. So one day, you get a kernel update, reboot, and you have no screen. DKMS is the first place to check. You’ll probably find it has some errors when building the graphics drivers.

Your choices are to look for a new driver, see if you can patch the old driver, or roll back to a previous working kernel. Sometimes the changes are almost trivial like when an API changes names. Sometimes they are massive changes and you really do want to wait for the next release. So while DKMS helps, it doesn’t solve all problems all the time.

Extras and Thoughts

I skipped over the part of turning off secure boot because I was too lazy to add a signing key to my BIOS. I’ll probably go back and do that later. Probably.

You have to wonder why this is so hard. There is already a way to pass the module options. It seems like you might as well let a user jam a USB ID in. Sure, that wouldn’t have helped for the enumeration case, but it would have been perfectly fine to me if I had just had to put a modprobe or insmod with a parameter to make the card work. Even though I’m set up for rebuilding kernel modules and kernels, many people aren’t, and it seems silly to force them to recompile for a minor change like this.

Of course, another fun answer would be to have vendors actually support their devices for Linux. Wouldn’t that be nice?

You could write your own drivers if you have sufficient documentation or the desire to reverse-engineer the Windows drivers. But it can take a long time. User-space drivers are a little less scary, and some people like using Rust.

What’s your Linux hardware driver nightmare story? We know you have one. Let us hear about it in the comments.

hackaday.com/2026/03/04/linux-…

Success With FreeDOS on a Modern Platform

Last summer we took a look at FreeDOS as part of the Daily Drivers series, and found a faster and more complete successor to the DOS of old. The sojourn into the 16-bit OS wasn’t perfect though, as we couldn’t find drivers for the 2010-era network card on our newly DOS-ified netbook. Here’s [Inkbox] following the same path, and bringing with it a fix for that networking issue.

The video below is an affectionate look at the OS alongside coding a TRON clone in assembler, and it shows a capable environment within the limitations of the 16-bit mode. The modern laptop here can’t emulate a BIOS as it’s UEFI only, and after trying a UEFI-to-BIOS emulator with limited success, he hits on a different approach. With just enough Linux to support QEMU, he has a lightweight and extremely fast x86 BIOS platform with the advantage of legacy emulation of network cards and the like.

The point of Daily Drivers is wherever possible to use real hardware and not an emulator, as it’s trying to be the machine you’d use day to day. But we can see in a world where a BIOS is no longer a thing it becomes ever more necessary to improvise, and this approach is better than just firing up an emulator from a full-fat Linux desktop. If you fancy giving it a try, it seems less pain than the route we took.

You can read our look at FreeDOS 1.4 here.

youtube.com/embed/mwLIgdRj5bI?…

FreeDOS logo: Bas Snabilie for the FreeDOS Project, CC BY 2.5.

hackaday.com/2026/03/04/succes…

New Artemis Plan Returns to Apollo Playbook

In their recent announcement, NASA has made official what pretty much anyone following the Artemis lunar program could have told you years ago — humans won’t be landing on the Moon in 2028.

It was always an ambitious timeline, especially given the scope of the mission. It wouldn’t be enough to revisit the Moon in a spidery lander that could only hold two crew members and a few hundred kilograms of gear like in the 60s. This time, NASA wants to return to the lunar surface with hardware capable of setting up a sustained human presence. That means a new breed of lander that dwarfs anything the agency, or humanity for that matter, has ever tried to place on another celestial body.

Unsurprisingly, developing such vehicles and making sure they’re safe for crewed missions takes time and requires extensive testing. The simple fact is that the landers, being built by SpaceX and Blue Origin, won’t be ready in time to support the original Artemis III landing in 2028. Additionally, development of the new lunar extravehicular activity (EVA) suits by Axiom Space has fallen behind schedule. So even if one of the landers would have been ready to fly in 2028, the crew wouldn’t have the suits they need to actually leave the vehicle and work on the surface.

But while the Artemis spacecraft and EVA suits might be state of the art, NASA’s revised timeline for the program is taking a clear step back in time, hewing closer to the phased approach used during Apollo. This not only provides their various commercial partners with more time to work on their respective contributions, but critically, provides an opportunity to test them in space before committing to a crewed landing.

Artemis II Remains Unchanged

Given its imminent launch, there are no changes planned for the upcoming Artemis II mission. In fact, had there not been delays in getting the Space Launch System (SLS) rocket ready for launch, the mission would have already flown by now. Given how slow the gears of government tend to turn, one wonders if the original plan was to announce these program revisions after the conclusion of the mission. The launch is currently slated for April, but could always slip again if more issues arise.
Artemis II Crew
At any rate, the goals for Artemis II have always been fairly well-aligned with its Apollo counterpart, Apollo 8. Just like the 1968 mission, this flight is designed to test the crew capsule and collect real-world experience while in the vicinity of the Moon, but without the added complexity of attempting a landing. Although now, as it was then, the decision to test the crew capsule without its lander wasn’t made purely out of an abundance of caution.

As originally envisioned, Apollo 8 would have seen both the command and service module (CSM) and the lunar module (LM) tested in low Earth orbit. But due to delays in LM production, it was decided to fly the completed CSM without a lander on a modified mission that would put it into orbit around the Moon. This would give NASA an opportunity to demonstrate the critical translunar injection (TLI) maneuver and gain experience operating the CSM in lunar orbit — tasks which were originally scheduled to be part of the later Apollo 10 mission.

In comparison, Artemis II was always intended to be flown with only the Orion crew capsule. NASA’s goal has been to keep the program relatively agnostic when it came to landers, with the hope being that private industry would furnish an array of vehicles from which the agency could chose depending on the mission parameters. The Orion capsule would simply ferry crews to the vicinity of the Moon, where they would transfer over to the lander — either via directly docking, or by using the Lunar Gateway station as a rallying point.

There’s no lander waiting at the Moon for Artemis II, and the fate of Lunar Gateway is still uncertain. But for now, that’s not important. On this mission, NASA just wants to demonstrate that the Orion capsule can take a crew of four to the Moon and bring them back home safely.

Artemis III Kicks the Tires

For Artemis III, the previous plan was to have the Orion capsule mate up with a modified version of SpaceX’s Starship — known in NASA parlance as the Human Landing System (HLS) — which would then take the crew down to the lunar surface. While the HLS contract did stipulate that SpaceX was to perform an autonomous demonstration landing before Artemis III, the aggressive nature of the overall timeline made no provision for testing the lander with a crew onboard ahead of the actual landing attempt — a risky plan even in the best of circumstances.
Docked CSM and LM during Apollo 9
The newly announced timeline resolves this issue by not only delaying the actual Moon landing until 2028, to take place during Artemis IV, but to change Artemis III into a test flight of the lander from the relative safety of low Earth orbit in 2027. The crew will liftoff from Kennedy Space Center and rendezvous with the lander in orbit. Once docked, the crews will practice maneuvering the mated vehicles and potentially perform an EVA to test Axiom’s space suits.

This new plan closely follows the example of Apollo 9, which saw the CSM and LM tested together in Earth orbit. At this point in the program, the CSM had already been thuroughly tested, but the LM had never flown in space or had a crew onboard. After the two craft docked, the crew performed several demonstrations, such as verifying that the mated craft could be maneuvered with both the CSM and LM propulsion systems.

The two craft then separated, and the LM was flown independently for several hours before once again docking with the CSM. The crew also performed a brief EVA to test the Portable Life Support System (PLSS) which would eventually be used on the lunar surface.
Orion docked to landers from SpaceX and Blue Origin
While the Artemis III and Apollo 9 missions have a lot in common, there’s at least one big difference. At this point, NASA isn’t committing to one particular lander. If Blue Origin gets their hardware flying before SpaceX, that’s what they’ll go with. There’s even a possibility, albeit remote, that they could test both landers during the mission.

Artemis IV Takes a Different Path

After the success of Apollo 9, there was consideration given to making the first landing attempt on the following mission. But key members of NASA such as Director of Flight Operations Christopher C. Kraft felt there was still more to learn about operating the spacecraft in lunar orbit, and it was ultimately decided to make Apollo 10 a dress rehearsal for the actual landing.

The CSM and LM would head to the Moon, separate, and go through the motions of preparing to land. The LM would begin its descent to the lunar surface, but stop at an altitude of 14.4 kilometers (9 miles). After taking pictures of the intended landing site, it would return to the CSM and the crew would prepare for the return trip to Earth. With these maneuvers demonstrated, NASA felt confident enough to schedule the history-making landing for the next mission, Apollo 11.

But this time around, NASA will take that first option. Rather than do a test run out to the Moon with the Orion capsule and attached lander, the plan is to make the first landing attempt on Artemis IV. This is partially because we now have a more complete understanding of orbital rendezvous and related maneuvers in lunar orbit. But also because by this point, SpaceX and Blue Origin should have already completed their autonomous demonstration missions to prove the capabilities of their respective landers.

Entering Uncharted Territory

At this point, the plans for anything beyond Artemis IV are at best speculative. NASA says they will work to increase mission cadence, which includes streamlining SLS operations so the megarocket can be launched at least once per year, and work towards establishing a permanent presence on the Moon. But of course none of that can happen until these early Artemis missions have been successfully executed. Until then it’s all just hypothetical.

While Apollo was an incredible success, one can only follow its example so far. Despite some grand plans, the program petered out once it was clear the Soviet Union was no longer in the game. It cemented NASA’s position as the preeminent space agency, but the dream of exploring the lunar surface and establishing an outpost remained unfulfilled. With China providing a modern space rival, and commercial partners rapidly innovating, perhaps Artemis may be able to succeed where Apollo fell short.

hackaday.com/2026/03/04/new-ar…

Creating an Ultra-Stable Lunar Clock With a Cryogenic Silicon Cavity Laser

Phase-coherent lasers are crucial for many precision tasks, including timekeeping. Here on Earth the most stable optical oscillators are used in e.g. atomic clocks and many ultra-precise scientific measurements, such as gravitational wave detection. Since these optical oscillators use cryogenic silicon cavities, it’s completely logical to take this principle and build a cryogenic silicon cavity laser on the Moon.

In the pre-print article by [Jun Ye] et al., the researchers go through the design parameters and construction details of such a device in one of the permanently shadowed regions (PSRs) of the Moon, as well as the applications for it. This would include the establishment of a very precise lunar clock, optical interferometry and various other scientific and telecommunication applications.

Although these PSRs are briefly called ‘cold’ in the paper’s abstract, this is fortunately quickly corrected, as the right term is ‘well-insulated’. These PSRs on the lunar surface never get to warm up due to the lack of an atmosphere to radiate thermal energy, and the Sun’s warm rays never pierce their darkness either. Thus, with some radiators to shed what little thermal energy the system generates and the typical three layers of thermal shielding it should stay very much cryogenic.

Add to this the natural vacuum on the lunar surface, with PSRs even escaping the solar wind’s particulates, and maintaining a cryogenic, ultra-high vacuum inside the silicon cavity should be a snap, with less noise than on Earth. Whether we’ll see this deployed to the Moon any time soon remains to be seen, but with various manned missions and even Moon colony plans in the charts, this could be just one of the many technologies to be deployed on the lunar surface over the next few decades.

hackaday.com/2026/03/04/creati…

Neither Android nor iOS: DIY Smartphone Runs on ESP32!

You may or may not be reading this on a smartphone, but odds are that even if you aren’t, you own one. Well, possess one, anyway — it’s debatable if the locked-down, one-way relationships we have with our addiction slabs counts as ownership. [LuckyBor], aka [Breezy], on the other hand — fully owns his 4G smartphone, because he made it himself.

OK, sure, it’s only rocking a 4G modem, not 5G. But with an ESP32-S3 for a brain, that’s probably going to provide plenty of bandwidth. It does what you expect from a phone: thanks to its A7682E simcom modem, it can call and text. The OV2640 Arducam module allows it to take pictures, and yes, it surfs the web. It even has features certain flagship phones lack, like a 3.5 mm audio jack, and with its 3.5″ touchscreen, the ability to fit in your pocket. Well, once it gets a case, anyway.

It talks, it texts, it… does not julienne fry, but that’s arguably a good thing.
This is just an alpha version, a brick of layered modules. [LuckyBor] plans on fitting everything into a slimmer form factor with a four-layer PCB that will also include an SD-card adapter, and will open-source the design at that time, both hardware and software. Since [LuckyBor] has also promised the world documentation, we don’t mind waiting a few months.

It’s always good to see another open-source option, and this one has us especially chuffed. Sure, we’ve written about Postmarket OS and other Linux options like Nix, and someone even put the rust-based Redox OS on a phone, but those are still on the same potentially-backdoored commercial hardware. That’s why this project is so great, even if its performance is decidedly weak compared to flagship phones that have as more horsepower as some of our laptops.

We very much hope [LuckyBor] carries through with the aforementioned promise to open source the design.

hackaday.com/2026/03/04/neithe…

Old Desk Phone Gets DOOM Port

Old desk phones are fairly useless these days unless you’re building a corporate PBX in your house. However, they can be fun to hack on, as [0x19] demonstrates by porting DOOM to a Snom 360 office phone.

The Snom 360 is a device from the early VoIP era, with [ox19] laying their hands on some examples from 2005. The initial plan was just to do some telephony with Asterisk, but [ox19] soon realized more was possible. Digging into a firmware image revealed the device ran a Linux kernel on a MIPS chip, so the way forward became obvious.

They set about hacking the phone to run DOOM on its ancient single-color LCD. Doing so was no mean feat. It required compilation of custom firmware, pulling over a better version of BusyBox, and reworking doomgeneric to run on this oddball platform. It also required figuring out how the keyboard was read and the screen was driven to write custom drivers—not at all trivial things on a bespoke phone platform. With all that done, though, [0x19] had a dodgy version of DOOM running slowly on a desk phone on a barely-legible LCD display.

Porting DOOM is generally a task done more for the technical thrill than to actually play the game on terribly limited hardware. We love seeing it done, whether the game is ported to a LEGO brick or a pair of earbuds. If you’re doing your own silly port, don’t hesitate to notify the tipsline—just make sure it’s one we haven’t seen before.

hackaday.com/2026/03/03/old-de…

Inside SKALA: How Chernobyl’s Reactor Was Actually Controlled

Entering SKALA codes during RBMK operation. (Credit: Pripyat-Film studio)
Running a nuclear power plant isn’t an easy task, even with the level of automation available to a 1980s Soviet RBMK reactor. In their continuing efforts to build a full-sized, functional replica of an RBMK control room as at the Chornobyl Nuclear Power Plant – retired in the early 2000s – the [Chornobyl Family] channel has now moved on to the SKALA system.

Previously we saw how they replicated the visually very striking control panel for the reactor core, with its many buttons and status lights. SKALA is essentially the industrial control system, with multiple V-3M processor racks (‘frames’), each with 20k 24-bit words of RAM. Although less powerful than a PDP-11, its task was to gather all the sensor information and process them in real-time, which was done in dedicated racks.

Output from SKALA’s DREG program were also the last messages from the doomed #4 reactor. Unfortunately an industrial control system can only do so much if its operators have opted to disable every single safety feature. By the time the accident unfolded, the hardware was unable to even keep up with the rapid changes, and not all sensor information could even be recorded on the high-speed drum printer or RTA-80 teletypes, leaving gaps in our knowledge of the accident.

(Credit: Chornobyl Family, YouTube)
Setting up a genuine RTA-80 teletype is still one of the goals, but these old systems are not easy to use. Same with the original software that ran on these V-3M computer frames, which was loaded from paper tape (the ‘library’), including the aforementioned DREG program. This process creates executable code that is put on magnetic tapes, with magnetic tape also used for storage.
(Credit: Chornobyl Family, YouTube)
The workings of the SKALA system and its individual programs including KRV, DREG and PRIZMA are explained in the video, each having its own focus on a part of the RBMK reactor’s status and overall health. Interacting with SKALA occurs via a special keyboard, on which the operator enters command codes to change e.g. set points, with parameters encoded in this code.

Using this method, RBMK operators can set and request values, with parameters and any error codes displayed on a dedicated display. There is also the Mnemonic Display for the SKALA system which provides feedback to the operator on the status of the SKALA system, including any faults.

Although to many people the control system of a power plant is just the control room, with its many confusing buttons, switches, lights and displays, there is actually a lot more to it, with systems SKALA and its associated hardware an often overlooked aspect. It’s great to see this kind of knowledge being preserved, and even poured into a physical model that simulates the experience of using the system.

The long-lived nature of nuclear power reactors means that even today 1960s and 1970s-era industrial automation system are still in active use, but once the final reactor goes offline – or is modernized during refurbishing – a lot of the institutional knowledge of these systems tends to vanish and with it a big part of history.

youtube.com/embed/Sjk2B0SzXUU?…

hackaday.com/2026/03/03/inside…

Designing A Pen Clip That Never Bends Out Of Shape

If you’ve ever used a ballpoint pen with a clip on the top, you’ve probably noticed they bend pretty easily. The clip relies on you only bending it a small amount to clip it on to things; bend it too far, and it ends up permanently deformed. [Craighill] decided to develop a pen clip that didn’t suffer this ugly malady.
The wire clip design easily opens wide because the spring wire is not actually deforming much at all. Credit: YouTube video, via screenshot
The problem with regular pen clips comes down to simple materials science. Bend the steel clip a little bit, and the stress in the material remains below the elastic limit—so it springs back to its original shape. Push it too far, though, and you’ll end up getting into the plastic deformation region, where you’ve applied so much stress that the material is permanently deformed.

[Craighill] noted this problem, and contemplated whether a better type of clip was possible. An exploration of carabiner clips served to highlight possible solutions. Some carabiners using elastically-deformed closures that faced the same problem, while others used more complicated spring closures or a nifty bent-wire design. This latter solution seemed perfect for building a non-deforming pen clip. The bent wire is effectively a small spring, which allows it to act as a clip to hold the pen on to something. However, it’s also able to freely rotate out from the pen body, limiting the amount of actual stress put on the material itself, which stops it entering the plastic deformation region that would ruin it.

It’s some neat materials science combined with a pleasant bit of inventing, which we love to see. Sometimes there is joy to be had in contemplating and improving even the simplest of things. Video after the break.

youtube.com/embed/bFDt3lUzVPc?…

youtube.com/embed/3i9FGaakX-Y?…

[Thanks to Keith Olson for the tip!]

hackaday.com/2026/03/03/design…

Exploring Security Vulnerabilities in a Cheapo WiFi Extender

If all you want is just a basic WiFi extender that gets some level of network connectivity to remote parts of your domicile, then it might be tempting to get some of those $5, 300 Mbit extenders off Temu as [Low Level] recently did for a security audit. Naturally, as he shows in the subsequent analysis of its firmware, you really don’t want to stick this thing into your LAN. In this context it is also worrying that the product page claims that over a 100,000 of these have been sold.

Starting the security audit is using $(reboot) as the WiFi password, just to see whether the firmware directly uses this value in a shell without sanitizing. Shockingly, this soft-bricks the device with an infinite reboot loop until a factory reset is performed by long-pressing the reset button. Amusingly, after this the welcome page changed to the ‘Breed web recovery console’ interface, in Chinese.

Here we also see that it uses a Qualcomm Atheros QCA953X SoC, which incidentally is OpenWRT compatible. On this new page you can perform a ‘firmware backup’, making it easy to dump and reverse-engineer the firmware in Ghidra. Based on this code it was easy to determine that full remote access to these devices was available due to a complete lack of sanitization, proving once again that a lack of input sanitization is still the #1 security risk.

In the video it’s explained that it was tried to find and contact a manufacturer about these security issues, but this proved to be basically impossible. This leaves probably thousands of these vulnerable devices scattered around on networks, but on the bright side they could be nice targets for OpenWRT and custom firmware development.

youtube.com/embed/KsiuA5gOl1o?…

hackaday.com/2026/03/03/explor…

The Perfect Cheat’s Racing Bicycle

One of the ongoing rumors and scandals in professional cycle sport concerns “motor doping” — the practice of concealing an electric motor in a bicycle to provide the rider with an unfair advantage. It’s investigated in a video from [Global Cycling Network], in which they talk about the background and then prove its possible by creating a motor doped racing bike.

To do this they’ve recruited a couple of recent graduate engineers, who get to work in a way most of us would be familiar with: prototyping with a set of 18650 cells, some electronics, and electromagnets. It uses what they call a “Magic wheel”, which features magnets embedded in its rim that engage with hidden electromagnets. It gives somewhere just under 20 W boost, which doesn’t sound much, but could deliver those crucial extra seconds in a race.

Perhaps the most interesting part is the section which looks at the history of motor doping with some notable cases mentioned, and the steps taken by cycling competition authorities to detect it. They use infra-red cameras, magnetometers, backscatter detectors, and even X-ray machines, but even these haven’t killed persistent rumors in the sport. It’s a fascinating video we’ve placed below the break, and we thank [Seb] for the tip. Meanwhile the two lads who made the bike are looking for a job, so if any Hackaday readers are hiring, drop them a line.

youtube.com/embed/ZdDHtLP3oEs?…

hackaday.com/2026/03/03/the-pe…

Get Your Green Power On!

Nobody likes power cords, and batteries always need recharging or replacing. What if your device could run on only the power it could gather together by itself from the world around it? It would be almost like free energy, although without breaking the laws of physics.

Hackaday’s 2026 Green-Powered Challenge asks you to show us your devices, contraptions, and hacks that can run on the power they can harvest. Whether it’s heat, light, vibration, or any other source of energy that your device gathers to keep running, we’d like to see it.

The top three entries will receive $150 shopping sprees courtesy of the contest’s sponsor, DigiKey, so get your entry in before April 24, 2026, to be eligible to win.

Honorable Mentions

As always, we have several honorable mention categories to get your creative juices flowing:

• Solar: In terms of self-powered anything, photovoltaic cells are probably the easiest way to go, but yet good light-harvesting designs aren’t exactly trivial either. Let’s see what you can run on just the sun. (Or even room lighting?)
• Anything But PV: Harnessing the light is too easy for you, then? How about piezo-electric power or a heat generator? Show us your best self-powering projects that work even when it’s dark out.
• Least Power: Maybe the smartest way to make your project run forever is to just cut down on the juice. If your project can run on its own primarily because of clever energy savings, it’s eligible for this mention.
• Most Power: How much of a challenge is building a solar-powered desk calculator in 2026? How about pushing it to the other extreme? Let’s see how much power you can consume while still running without batteries or cords. Does your off-grid shack count here? Let’s see it!

Prior Art

We’ve seen a lot of green-powered projects on Hackaday over the years, ranging from a solar-powered web server to a microcontroller powered by a BPW34 photodiode. Will your entry run off the juice harvested by an LED? It’s not inconceivable!

Solar cells only work when the sun shines, though. As long as your body is putting out heat, this Seebeck-effect ring will keep on running. (Matrix vibes notwithstanding!) Or maybe you want to go straight from heat to motion with a Stirling engine. And our favorite environmental-energy-harvester of all has to be the Beverly Clock and its relatives, running on the daily heat cycles and atmospheric pressure changes.

Your Turn

So what’s your energy-harvesting project? Batteries are too easy. Take it to the next level! All you have to do to enter is put your project up on Hackaday.io, pull down the “Submit Project to…” widget on the right, and you’re in. It’s that easy, and we can’t wait to see what you are all up to.

And of course, stay tuned to Hackaday, as we pick from our favorites along the way.

hackaday.com/2026/03/03/get-yo…

A Look Inside the Creative MB-10 MIDI Blaster

Before it became viable to distribute and play music tracks on home computers, the use of FM and Wavetable synthesis was very common, with MIDI Wavetable-based devices like the Roland MT-32 and SC-55 still highly sought after today. The Creative Midi Blaster MB-10 that [Yeo Kheng Meng] reviewed and tore down for an analysis isn’t quite as famous or sought after, but it provides a good example of what Creative Labs was doing at the time in this space.

Released in 1993, it definitely has more of a popular style vibe to it than the utilitarian Roland devices, even if this means highly impractical curves. In the list of features it claims Roland MT-32 emulation, which would have made it quite a bit more useful to the average user, including gamers of the era. Games like DOOM supported these MIDI devices for audio, for example.

In terms of price only the Roland SC-55ST comes close to the MB-10, similarly dropping a screen and a host of features. In terms of features the MB-10 claims far fewer instruments than the SC-55 variants, with even with the slightly higher priced SC-55ST massively outgunning it in raw specs. So would you ever buy the MB-10 back then and consider it a ‘good deal’? If $100 in 1990s money was worth losing full MIDI compatibility for, then it seems the answer was ‘yes’.

During the teardown of the MB-10 we can find an 8051-based Siemens processor that handles the MIDI interfaces and a Dream SAM8905 effects processor. Most of the remaining ICs are ROM chips that contain the firmware and MIDI banks, with the ROM dumps found in this GitHub repository.

The analog output stage includes the venerable TL074CN opamp and TDA1545 DAC, as well as a TDA2822M power amplifier IC. All of which is typical off-the-shelf for the era and also not something where Creative spent big bucks. It also appears that the 20-note polyphony claims on the box are false, as the Dream processor can only do 16 notes, which a quick test confirmed.

Despite being the cheaper option, it seems that most people with the spare cash to splurge on an external MIDI Wavetable device opted for a Roland one. These days it’s correspondingly quite hard to find an MB-10 for sale, unlike Roland MT-32 and SC-55 variants, yet considering software compatibility you really want to just stick with MT-32 and SC-55 compatibility anyway.

hackaday.com/2026/03/03/a-look…

Back to Basics: Hacking on Key Matrixes

A lot of making goes on in this community these days, but sometimes you’ve just gotta do some old fashioned hacking. You might have grabbed an old Speak and Spell that you want to repurpose as an interface for a horrifyingly rude chatbot, or you’ve got a calculator that is going to become the passcode keypad for launching your DIY missiles. You want to work with the original hardware, but you need to figure out how to interface all the buttons yourself.

Thankfully, this is usually an easy job. The vast majority of buttons and keypads and keyboards are all implemented pretty much the same way. Once you know the basics of how to work with them, hooking them up is easy. It’s time to learn about key matrixes!

Wire ‘Em Up

A simple 3 x 3 matrix layout that allows six pins to read nine buttons. The buttons are organized into three rows and three columns. Credit: author
Imagine you have a piece of consumer hardware, like a desk phone or an old control panel or something. You’d like to hook up a microcontroller to read all the buttons. Only, there’s 10, or 20, or 100 buttons… and your microcontroller just doesn’t have that many I/O pins! If you’re only familiar with hooking up a couple of push buttons to a couple of pins on an Arduino with some pull-up resistors, this can feel like an overbearing limitation. However, thankfully—there is a better way!

Enter the key matrix. It’s a very simple way of hooking up more buttons to less I/O pins. Imagine, for example, a nine-digit keypad, arranged in a 3 x 3 square. Assign three pins for columns, and three pins for rows. Each button in the keypad is hooked up to one row pin and one column pin. You can then, for example, energize each row pin in turn with a high output on a microcontroller, and detect whether any of the column pins go high by setting them to inputs. Do this quickly enough, and you can detect the state of all nine buttons with just six pins. In fact, the technique is generalizable—for n pins, you can address (n/2)² buttons. For six pins, that’s nine buttons.
In this diagram, each circle represents a button, which is connected to the pins whose lines intersect within. With this method, it’s possible to address many more buttons with the same amount of I/O pins as a regular row-column layout. Credit: author, inspired by work from Touchscreen1
You can even take it further, if you abandon the concept of a grid-like row-and-column layout. You can instead take six pins, for example, treating each one as its own “row.” You then place a button between it and every other pin, doing the same for each following pin in turn. You can then energize pin 1, while scanning pins 2 through six to see which buttons were pressed, and so on through the rest of the pins. This will net you a higher amount of buttons per pin—(n²-n)/2, in fact. For our six pin example, you could address 15 buttons this way.

When you expect multiple button presses at a time, you should add diodes into the button matrix to prevent current paths taking unexpected directions, and you might be lucky enough to find that your device already has them. There are even more advanced techniques, like Charlieplexing, that can address n² – n switches, but you’re less likely to come across this in the wild except for pin-constrained LED circuits.

These techniques are commonly referred to as multiplexing, and you’ll find it in all sorts of places. Everything from TV remotes to desktop calculators use this sort of technique to address many buttons without requiring lots of individual I/O pins.
Sometimes you’ll find a piece of hardware with neat little test pads that link up with the rows and columns of the keypad matrix. This makes things easy! Credit: author
Once you’re aware of this, it generally becomes straightforward to open up any such piece of hardware and figure out how the buttons work. All you need to do is hunt down the traces that connect from button to button, and slowly map out how they’re all connected. Mapping out the board can be challenging, though, because designers don’t always make the traces easy to follow. While something like a keypad may be logically connected in a grid-type layout, for example, it might not actually look like that on the PCB. The traces might be going every which way, complicating your efforts to figure out what’s connected to what.

A multimeter set to continuity mode is a great tool for this work. It lets you tap around a PCB to figure out which side of each button is connected to which other buttons, allowing you to figure out how the matrix is laid out. For example, if you were working with a phone keypad, you might start by putting a multimeter lead on one of the contacts of the “1” button. You might then find that it’s connected to one side of the buttons for 3, 5, 9, and *. You can then probe the other side of each of those buttons to find out what they’re connected to as well. Put all this data into a spreadsheet, and you’ll eventually see which two pins you need to check to determine the status of any button on the keypad.

Generally, you’ll also find all the traces lead back to some main chip or connector, where you can easily solder on leads to hook up your own microcontroller to read all the buttons. It’s not always this easy—some boards will help you out with accessible test pads, while others will only provide tiny solder points for fine pitch connectors. In a worst case scenario, you might have to scrape solder resist off some traces so you can solder your wires in that way.

Once you’ve got a microcontroller hooked up to your button pads, the hard part is over. You just need to write some simple code to scan the key matrix and detect button presses. You can use a pre-baked library if you so desire, or you can do it yourself. Ultimately, a simple way is to just energize a row with an output I/O pin while setting all the column pins to inputs to see if any buttons are currently pressed, and stepping through the rows from there. You can get fancier about it if you like if things like latency or anti-ghosting are critical to you, but that’s a discussion for another time. With the high clock speeds of modern microcontrollers, it’s trivial to read even a large key matrix at a rapid pace.

youtube.com/embed/Yiq4fkdly04?…

Figuring out how to interface button pads on random hardware is a fun hacking skill to learn, and is accessible for beginners.

It’s worth noting that you might also have to cut some traces going to components of the original circuit, depending on what you’re hacking on. Oftentimes it’s not necessary, particularly if you’re unfussed what happens to any original circuitry on the board. For example, if you do intend to restore the item you’re hacking to original function, it might not be good to be probing the keypad with a 5 V microcontroller when the original hardware all ran at 3.3V. You might hurt the original chips on board if some voltage ends up where you didn’t intend it to go.

If you’ve ever dreamed of turning an air conditioner remote into a secret access panel for your home security system, or making your microwave into a cellular phone, these techniques will serve you well. Go forth, hunt down the matrix, and hack an appliance’s original user interface into the control panel of your dreams.

DK 10x24 - Non è colpa della IA

Dalla Rivoluzione Industriale in poi, il punto non è mai stato se le macchine possano davvero sostituire i lavoratori, ma chi, con le macchine acquisisce potere contrattuale, e chi lo perde...

spreaker.com/episode/dk-10x24-…

Building a Hackerspace Entry System

A hackerspace is a place that generally needs to be accessed by a wide group of people, often at weird and unusual hours. Handing around keys and making sure everything is properly locked up can be messy, too. To make it easy for hackers to get in to [Peter]’s local hackerspace, a simple electronic system was whipped up to grant access.
The combined use of QR code & PIN adds a layer of security.
The basic components of the system are a keypad, a QR code and barcode scanner, a stepper motor, an Arduino Nano, and a Raspberry Pi. The keypad is read by an Arduino Nano, which is also responsible for talking to a stepper motor driver to actuate the lock cylinder.

The system works on the basis of two-factor authentication. Regular users authenticate to enter by presenting a QR code or barcode, and entering a matching PIN number. The system can also be set up for PIN-only entry on a temporary basis.

For example, if the hackerspace is running an event, a simple four-digit pin can allow relatively free access for the duration without compromising long-term security. Actual authentication is handled by the Raspberry Pi, which takes in the scanned barcode and/or PIN, hashes it, and checks it against a backend database which determines if the credentials are valid for entry.

While it’s not technically necessary for a project like this — in fact, you could argue it’s preposterously overkill — we have to take particular note of the machined aluminum enclosure for the keypad. Mere mortals could just run it off on their 3D printers, but if you’ve got access to a CNC router and a suitably chunky piece of aluminum, why not show off a bit?

It’s a nifty system that has served the hackerspace well over some time. We’ve featured some neat access control systems before, too. If you’ve got your own solution to this common problem, don’t hesitate to notify the tipsline!

hackaday.com/2026/03/03/buildi…

DK 10x23 - Un mondo di sbobba

Si scopre che non solo i modelli linguistici generano stronzate by design, ma che i markettari possono suggerirgli quali stronzate generare...

spreaker.com/episode/dk-10x23-…

Building a Dependency-Free GPT on a Custom OS

The construction of a large language model (LLM) depends on many things: banks of GPUs, vast reams of training data, massive amounts of power, and matrix manipulation libraries like Numpy. For models with lower requirements though, it’s possible to do away with all of that, including the software dependencies. As someone who’d already built a full operating system as a C learning project, [Ethan Zhang] was no stranger to intimidating projects, and as an exercise in minimalism, he decided to build a generative pre-trained transformer (GPT) model in the kernel space of his operating system.

As with a number of other small demonstration LLMs, this was inspired by [Andrej Karpathy]’s MicroGPT, specifically by its lack of external dependencies. The first step was to strip away every unnecessary element from MooseOS, the operating system [Ethan] had previously written, including the GUI, most drivers, and the filesystem. All that’s left is the kernel, and KernelGPT runs on this. To get around the lack of a filesystem, the training data was converted into a header to keep it in memory — at only 32,000 words, this was no problem. Like the original MicroGPT, this is trained on a list of names, and predicts new names. Due to some hardware issues, [Ethan] hasn’t yet been able to test this on a physical computer, but it does work in QEMU.

It’s quite impressive to see such a complex piece of software written solely in C, running directly on hardware; for a project which takes the same starting point and goes in the opposite direction, check out this browser-based implementation of MicroGPT. For more on the math behind GPTs, check out this visualization.

youtube.com/embed/i43kzMwv04o?…

hackaday.com/2026/03/03/buildi…