There’s no shortage of cloned Nintendo hardware out there, and most of it is pretty poor. A few are actually pretty interesting though, such as the GB Boy by Gangfeng, which takes real cartridges and thus in many ways should provide the original Game Boy Pocket experience with modern hardware. But as you might imagine, even the best of the clones comes with various technical issues at no additional charge — with this particular unit having a habit of running the game too fast. It’s an issue that [Sharopolis] addresses in a recent video with a partial fix.

As can be seen in the demonstration, it runs games just too fast to make it very usable or fun, hence why it sat in a drawer for a few years after purchasing off AliExpress. This raises the question of what’s wrong with these units, as others report similar issues with this and other ‘GB Boy’ variants.

Fortunately the unit is easy to open, revealing the PCB with a couple of chips on it, one marked KF2001 being the brains of the operation alongside two memory chips. The oscillator marked X1 for the main IC is rated for 5 MHz, whereas a quick look inside the Game Boy Pocket shows that its oscillator runs at 4.1943 MHz, which is a bit of a difference.

Because of how buying components and pricing works, [Sharopolis] ended up with a reel of 100 of replacement oscillators with the right parameters for a drop-in replacement. After swapping the oscillator, the GB Boy now does indeed run games at the right speed, but a new issue has now cropped up in the form of flicker on the display.

In the comments it’s suggested that replacing the cheap capacitors on the GB Boy’s board can help here, but it highlights just how these clone systems keep managing to snatch defeat from the jaws of victory by pairing what looks to be a pretty good IC with either the wrong or sub-par components.

youtube.com/embed/6zuKkyV9Wek?…

hackaday.com/2026/06/04/fixing…

There was a time when a CB radio was a simple affair: a small box with a channel selector, volume, and squelch controls. No longer it seems, because they can now be multi-mode devices that equal the capabilities of amateur radio rigs if not surpass them. [ThatCrazyDcGuy] has one, an Albrecht AE-5900, which has the interesting feature that it can be entirely controlled from its microphone. This led to a web-based interface for the rig, through clever emulation of the microphone.

The communication between rig and microphone is a serial line, for which an FT232 USB-to-serial interface is pressed into service. A USB sound card handles the audio along with some little transformers for isolation, and a USB hub joins everything together. The whole is mounted on perfboard in a small enclosure, and plugged into a Raspberry Pi which acts as a server. This is running a Python script that expose a web front end to control the rig. We like the way this has been done, with minimal intrusion into the radio itself.

Far less so than this CB to 6 meter conversion we featured a while back.

hackaday.com/2026/06/03/web-ba…

Pouring the resulting distillate for testing. (Credit: Lowered Expectations, YouTube)
The propensity of gasoline to ‘go stale’ through the process of oxidation is the reason why gasoline that has been stored for a long period of time is considered to be unusable, as it will no longer combust property. Since this process creates the sludge that you find in the bottom of an old gasoline canister, it follows that you may be able to distill out the still good gasoline. With this reasoning, [Joel] over at the [Lowered Expectations] channel set to work to try out this theory.

As part of his job of maintaining things like pressure washers, he got access to many grades of stale gasoline to experiment with. After a short demonstration of how poorly these grades of stale gasoline burn it’s on to the main distillation event. To the stale gasoline aluminium oxide is added as both a catalyst and to create nucleation sites that will prevent ‘bumping’ where you suddenly get a surge out of the heated flask.

Of course, that this is incredibly dangerous should be obvious, and the lack of PPE on the side of [Joel] is somewhat worrying. On the positive side, he does take it easy with ramping up the temperature on the gasoline to try and find the sweet spot where production seems sufficient. This turned out to start at 70°C in the flask when the condenser began to receive its first load of presumably clean-ish gasoline.

The goal here is of course to approximate the function of the fractionating column (‘distillation tower’) at refineries at smaller scale, which [Joel] appears to be doing correctly with what looks to be a Vigreaux column. Since the base product is gasoline with oxidized contaminants this process is of course quite different, so he goes through the different temperature ranges to see what kind of distillate he gets, up to nearly 200°C before calling it.

Ultimately 880 mL of the initial 1 L was collected, with the various distillates combined for testing. Unfortunately none of the testing is actually covered in the video, but it is mentioned at the end that a second batch of the distillate was used to power his car, so presumably it works.

Suffice it to say that ‘works’ doesn’t mean that it is safe, of course. Heating such stale gasoline produces many highly flammable and combustible substances, along with many that are just downright bad for your health to be exposed to. The plethora of very short-term to all the way to very long-term health effects this may cause should be obvious.

youtube.com/embed/WCzdoeVNp40?…

hackaday.com/2026/06/03/distil…

Solarpunk is all about combining that DIY hacker ethos with sustainability and renewable resources. Our usual PCB manufacturing methods, with their bevy of chemical baths and petrochemical resins aren’t exactly the most sustainable. Digging up some clay and firing it into a circuit board? Very sustainable! And apparently doable, as demonstrated by [Emily Velasco] on Mastadon.

Of course anybody could take a ceramic wafer and call it a circuit board, but that’s only part of what [Emily] did. The ceramic wafer is apparently native clay, which is very cool. Even cooler is that she’s baked the traces into the pottery. While you could conceivably use some sort of conductive glaze for this, what [Emily] did was stamp her desired circuit into the unfired ceramic using a 3D-printed stamp, and then fill the depression with copper powder after the first firing. After that, a second firing is done in a reducing atmosphere to melt/sinter the copper together–it’s not totally clear which is happening here–without burning up.

The results speak for themselves; on the finished demo board, a pair of LEDs blink happily away, driven by the astable oscillator circuit baked right into the clay– and of course the components soldered to it. You’ll have to click through to see it, though.

Given those not-so-sustainable petrochemicals behind our favourite PCBs may be in short supply, this is a timely hack. If it seems familiar, that’s because we featured virtually the same technique last year, but using more-expensive silver powder instead of copper, and a campfire instead of a kiln.

Thanks to [smellsofbikes] for the tip!

hackaday.com/2026/06/03/diy-ce…

Emily Velasco

2026-05-30 03:12:45

Baking

Texas Instruments SA5532A variant of the 5532 op-amp. (Credit: Raimond Spekking, Wikimedia)
First introduced in 1979 by Signetics, the NE5532 was a pretty spiffy dual op-amp for the time with low noise and low distortion. Over the years it has become a standard part that showed up in countless audio products, and has become a so-called jellybean generic component with Texas Instruments (TI) being one of countless manufacturers.

It being such a standard, multi-sourced part makes it thus even more puzzling that TI has now decided to completely overhaul this IC in a way that makes it incompatible with even the original Signetics NE5532. These changes are covered in detail by [Dave] of EEVblog as his mind is pretty much blown at such an incomprehensible change.

The changes entail an entirely different manufacturing process and a big change in specifications, while making no change to the part number. In revision K of the TI datasheet these changes are first seen, with some specifications changed for the better, like a higher unity gain bandwidth by 2 MHz, but a much slower slew rate.

Although the 5532 op-amps are multi-sourced, there are good reasons to just stick with manufacturers like TI, as that means receiving a product change notification (PCN) when anything changes. In the PCN related to this op-amp a change to process node is noted, along with other changes, but no reasoning.

Among the other big changes are a reduction in the supply voltage from 22V to 18V, and a halving of the ESD protection from 2kV to 1kV. Although it might be slightly more efficient on the new process node this way, it clearly comes with a lot of trade-offs that make it an overall worse op-amp, while also being incompatible with the same op-amp from other manufacturers.

In the video [Dave] goes through the datasheets of this jellybean part of other manufacturers, showing that they still have the original 1980s specifications. Only one exception here was the NE5532DR from Shenzhen HuaXuanYang Electronics, whose supply rail voltage is also 18V for some reason, along with a similar internal transistor configuration that reduces the ESD resistance.

In addition to the NE5532 op-amp, it seems that TI also took an ax to the OPA134 op-amp, by removing its offset trim feature and listing the pins as ‘NC’, with a warning to not connect these pins and also worsening other specifications. This makes these similar jellybean parts incompatible, with no change to the part number. Worse is that it continues with the LMH6518, whose changes [Dave] argues might even kill oscilloscopes as they are commonly found in those.

Meanwhile the LM317M also got an overhaul, but here TI opted to give it a new part name, calling it the LM317MQ with at first glance no major degradations in the specifications, but instead some actual improvements. This makes it even more puzzling why TI didn’t give the other ICs a new part number to differentiate them from the jellybean part.

Until there’s some clarification from the side of TI, it might be a good idea to source these jellybean parts from a manufacturer that is not TI, especially when replacing these ICs in older devices.

youtube.com/embed/22ZmmZ67SMY?…

hackaday.com/2026/06/03/texas-…

For those who have never played the hit video games Undertale and Deltarune, the games are partially known for their interesting characters, many of which have eerie, surreal, and expressive designs. One of the more memorable characters from Deltarune is Tenna, a game show host of sorts whose distinguishing feature is an old television as a head, as well as a colorful suit. As a result he’s been the subject of a number of recreations by various cosplayers and makers like [BigRig Creates].

This version of the character was actually inspired by a previous build by [BunnyBii] which used an iPad as the interactive screen/face. Inside the television, though, the actual human found this to be front heavy and limiting in the ways that it could be used interactively, especially since the only way to see the outside world in this version was with a small endoscope and screen. [BigRig Creates]’s version builds on this idea but swaps out the iPad for a Raspberry Pi, allowing for much more customization, and uses a pair of Xreal glasses instead of a screen for the view of the outside world from in the television.

To get the whole costume together, the head is 3D printed with all of the electronics inside, and a game controller integrated into a handheld microphone controls the animations shown on the screen. A vibrant, custom-tailored suit with white gloves rounds out the ensemble, along with a pair of 3D-printed shoe covers since actual yellow shoes were a bit pricy. There were some interesting problems to solve along the way, specifically with regards to power management for all the electronics, but in the end it all seems to have come together quite well. [BigRig Creates] is no stranger to builds with unusual displays, though; one of our favorites was the world’s largest Nintendo 3DS.

youtube.com/embed/KR8yb54V-9g?…

hackaday.com/2026/06/03/deltar…

Previously, I looked at using the Linux video loopback system from the command line. The basic trick was simple enough: capture video from a real camera, process it with something like ffmpeg, and write the result to a fake camera device via the v4l2loopback device. Then a browser, or any camera-enabled software, sees the fake camera as if it were real. This allows you to manipulate video before sending it to the rest of the world.

That works, and for those of us who like command lines, it’s easy enough to execute. But not everyone loves the command line. In the comments, there was another obvious answer: use OBS Studio.

While OBS is excellent, it is also a bit like using a laser to chop a carrot. If you already use OBS, fine. If you only want to crop a webcam, add an effect, mirror an image, or feed a virtual camera, it can feel like a lot. If you must have a GUI, you can try Webcamoid, which sits somewhere between a simple webcam viewer and a full video production system.

Webcamoid gives you a GUI for selecting a camera, applying effects, and sending the result to a virtual camera. Conceptually, it is much closer to the command-line loopback setup from the previous post than to OBS. You are still building a pipeline from input camera to output camera, but now you can do much of it with buttons and menus instead of shell commands.

That’s in theory, of course. Implementing Webcamoid turned out to be quite the exercise. Granted, this probably varies depending on where you install software. If your distro has a clean working copy of Webcamoid and its dependencies, good for you. For everyone else, keep reading.

The Moving Parts

There are two pieces to understand. Webcamoid is the GUI application. It captures video, previews it, applies effects, and can write to a virtual camera. You also need a driver to produce the fake or virtual camera. AkVCam is one of the virtual camera drivers that Webcamoid can use on Linux. It can also use v4l2loopback, as we discussed last time. Both approaches create fake /dev/videoX devices, but their configuration models are different.

With v4l2loopback, the typical setup is command-line oriented:
sudo modprobe v4l2loopback video_nr=10 card_label="Virtual Camera" exclusive_caps=1
Then some program writes frames to /dev/video10. For example, ffmpeg can read from a real webcam and write to the virtual one. Of course, if you want a permanent virtual camera, you can make an entry in /etc/modprobe.d.

AkVCam is more structured. Instead of simply creating a generic loopback device, it uses a configuration file that defines one or more virtual cameras, their input/output relationship, and the formats they support. That sounds like more work, and in a way it is. But it also gives you tighter control over what formats the virtual camera advertises. This sometimes matters more than you might expect.

Install, Remove, Install…

The hard part of Linux webcam work is often not getting video — it’s getting every piece of the chain to agree on width, height, frame rate, and pixel format, along with matching each other’s API expectations.

I tried three different ways to install Webcamoid. First, I used the normal OpenSUSE Tumbleweed repos to install the program. It couldn’t find any cameras. My next stop was a Flatpak version. That worked well, but it is deliberately crippled and won’t even try to drive a virtual camera, directing you to install the regular version instead. Then I tried an AppImage. This seemed to work OK, but the virtual camera would never display anything but a black screen.

Note that the version on AppImageHub is old, and the source project requires payment for prebuilt binaries. I didn’t try either of those options.

I tried a lot of things to make it work. My final answer was to use the AppImage, but I had to build my own version of AkvCam from GitHub.

Even then, at first, the video output was highly pixelated. The culprit was AkVCam using the 640×480 RGB format. Upscaling created a blocky mess.

You can see what a device is doing with:
v4l2-ctl -d /dev/video3 --all
In my case, the virtual output reported:
Width/Height : 640/480
Pixel Format : 'RGB3'
scaling_mode : Fast
aspect_ratio_mode : Ignore
That explains it. “Fast” scaling usually means “not pretty,” and 640×480 is not a great starting point for modern video calls.

The fix was to simplify the AkVCam configuration. Instead of giving the virtual camera a long list of supported formats, I configured it with essentially one useful format. For example, if the pipeline is meant to be 1280×720 at 30 fps, make that the format. Do not give every program in the chain an opportunity to negotiate itself down to postage-stamp resolution.

A minimal AkVCam setup generally defines a capture device, an output device, a connection between them, and formats. In the generated config I was using, the output camera had several formats:
cameras\2\type=output
cameras\2\videonr=3
cameras\2\formats=19, 20, 21, 22, 23, 24
The problem was that format 19 was 640×480. The high-resolution formats were present, but not preferred. Reordering the list might help, but for reliability, using only the desired format is even better.

Webcamoid As A GUI Pipeline

ASCII filter in action.
Once the virtual camera driver is sane, Webcamoid works well. You select the real camera as the source, apply whatever effects you want, and select the AkVCam virtual camera as the output. The receiving application then sees the virtual camera.

Compared to the command-line approach, Webcamoid makes experimentation easier. Want to flip the image, adjust color, crop, blur, or test silly filters? That is all much easier in a GUI than in an ffmpeg or gstreamer filter chain, although I still don’t mind the command line. There’s not much difference between using Webcamoid as a friendly front end or manipulating the image as we did last time.

However, I would not oversell it. Webcamoid is not OBS. It is not really a scene compositor. If you want multiple live sources — say, a screen capture as the main image and your webcam as picture-in-picture — OBS is the obvious GUI tool. With the command line, you can easily do things like this by calling ffmpeg directly.

That’s a Wrap!

If you want a full production environment, OBS is still the right answer. It handles scenes, multiple sources, transitions, screen capture, overlays, and virtual camera output in a single application. But if you liked the command-line loopback idea and wished it had a friendlier face, Webcamoid plus AkVCam is worth a look. It gives you a GUI for the common case: one camera in, effects applied, one virtual camera out. You just need to fight through the installation and configuration with your specific setup. Hopefully, yours will be easier than mine.

As usual, Linux rewards knowing what is happening under the hood. Webcamoid can make the workflow friendlier, but v4l2-ctl is still your friend, and, at least for some people, you’ll need some Linux Fu to get it all working in harmony.

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