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…

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…

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…

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…

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…

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…

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.

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-…

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…

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-…

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…

If you want to pull apart a program to see how it ticks, you’re going to need a disassembler. [Ricardo Quesada] has built Regenerator 2000 for just that purpose. It’s a new interactive disassembler for the Commodore 64 platform.

Naturally, Regenerator 2000 is built with full support for the 6502 instruction set, including undocumented op-codes as well. It’s able to automatically create labels and comments and can be paired with the VICE C64 emulator for live debugging. You can do all the usual debug stuff like inspecting registers, stepping through code, and setting breakpoints and watchpoints when you’re trying to figure out how something works. It can even show you sprites, bitmaps, and character sets right in the main window.

Files are on Github if you’re ready to dive in. You might find this tool to be a useful companion to C64 assembly tools we’ve featured previously, as well. If you’re pulling off your own retro development hacks, be sure to notify the tipsline.

[Thanks to Stephen Waters for the tip!]

hackaday.com/2026/03/02/c64-ge…