Power It With Sodium (But Please Don’t)

October 1, 2026 by Al Williams 9 Comments

[Applied Science] has a new demo of an old 1970s patent for a portable generator that is both interesting and terrifying. The generator uses sodium and water, which, if you remember your old chemistry classes, will combust spontaneously. Turns out, though, it won’t if you draw power from it fast enough. Don’t draw enough power? BOOM, apparently. Check it out in the video below.

Of course, lithium-ion batteries might catch fire, too, but this looks a lot more likely. The patent made some wild claims about how much you could draw from the device, but the video shows that practical results are somewhat less.

Continue reading “Power It With Sodium (But Please Don’t)” →

A Mechanical Radio, Sort Of

October 1, 2026 by Al Williams 26 Comments

[The Mike Stuff] has an interesting proposition. He asserts that ancient people like the Greeks could have built a form of radio that was purely mechanical. We aren’t sure we agree, but even if it were possible, we are sure it would have sounded awful. You can see the details in the video below.

The idea is that you can compress air with a waterwheel, blow it through a rotating disk with slots in it, and a valve to amplitude modulate the airflow through the disk. Horns like an old gramophone speaker would amplify the signal at both ends. The demodulation is straightforward and doesn’t even require power, like compressed air.

Continue reading “A Mechanical Radio, Sort Of” →

The FPGA Chronicles: Exploring The Tang Nano 20K

September 28, 2026 by Al Williams 36 Comments

FPGAs used to be mysterious, expensive devices, but these days you can buy surprisingly capable boards for very little money. Some years ago, I did an FPGA Bootcamp over on Hackaday.io. Much of that material still applies, but the hardware is dated. So I decided it was time to update it, using the inexpensive Tang Nano 20K and its GOWIN GW2AR-18 FPGA as the main platform, with perhaps a few excursions into other FPGAs.

History and Motivation

Once upon a time, if you wanted to have a custom IC, you went with a wheelbarrow full of money to a semiconductor company. However, some smart person at a semiconductor fab eventually realized they could make a chip with a lot of uncommitted blocks on it and then, for a custom chip, only design the wiring that connected them together. This still required a wheelbarrow full of money, but it was a smaller wheelbarrow.

Then one day, someone realized they could do the same thing but make the electrical connections between the blocks configurable. Maybe have fuses you can blow, or use EEPROM or RAM cells to remember which blocks are connected to which. It is complicated, sure, but then you can make many of these chips and sell them to people who could, in theory, make their own custom chips without your help.

When do you need an FPGA? A classic classroom exercise for an FPGA, for example, is a traffic light because it shows off how to do state machines, which are important for some kinds of FPGA designs. But other than as a learning example, why would you do this? Even a simple 8-bit CPU can handle a traffic light.

Suppose instead that you have hundreds of digital sensors on a rocket, and any one of them must raise an alarm within a few microseconds. A processor has to sample inputs in groups, service interrupts, or rely on extra hardware. An FPGA can simply implement the equivalent of one enormous OR gate. It watches every input continuously, and unrelated logic elsewhere in the FPGA does not steal execution time from it. Can you do it with a microcontroller? Probably, but not easily. For some classes of problems, an FPGA is the better answer.

Of course, you can also build a CPU on your FPGA and some FPGAs have CPUs in the same package. This is often a sweet spot because then things that are easy to do in software, you do in software. Things that are easier to do in hardware, you do in the FPGA.

Continue reading “The FPGA Chronicles: Exploring The Tang Nano 20K” →

Hackaday Links: September 27, 2026

September 27, 2026 by Al Williams 7 Comments

It isn’t quite hailing frequencies open, but researchers from Harvard claim they’ve picked up a radio signal directly from a nearby exoplanet. Before you get too excited, planets in our solar system also emit RF, so no one credible is claiming these are extraterrestrial reruns of their version of I Love Lucy, but it is the first time they’ve localized a radio signal to an exoplanet, in this case, Beta Pictoris B.

Speaking of space, the asteroid formerly known as 1981 EC26 is now sporting a new moniker: (14331) Alyankovic. If you think that sounds like (Weird) Al Yankovic, you aren’t wrong. The Tucson Star reports that, thanks to the efforts of several planetary scientists who are also Weird Al fans, the International Astronomical Union made the name official. Apparently, another asteroid now bears a name in honor of Weird Al’s predecessor, Tom Lehrer.

If you follow open mobile phone software, you probably know the name postmarketOS, a Linux distribution based on Alpine aimed at mobile phones and tablets. Well, now you can forget it. The project announced a name change, so we’re now talking about Nura. Why Nura? According to the team, it is a shortened form of Nuraghe, some granite structures in Sardinia that are over 5,000 years old. The FAQ mentions that postmarketOS was hard to remember. We aren’t sure Nura is that much more memorable. Perhaps they should have pivoted to Phonz OS.

Continue reading “Hackaday Links: September 27, 2026” →

Hackaday Podcast Episode 388: RAM-Swapping On Raspberry Pi, Raindrops On Radar, And A Fine Mesh

September 25, 2026 by Al Williams 1 Comment

This week, Hackaday Editors Elliot Williams and Al Williams had a lot to talk about. From advice for a young hacker to using a laser to break into a microcontroller, there was plenty to cover from the week in Hackaday.

From the “Point/Counter Point” department, there were dueling posts about how big a deal it is for Raspberry Pi to lock out RAM chip swapping. Ever want to do interactive debugging in MicroPython? For intellectual exercise, there’s the physics of raindrops becoming a radar antenna. If you are a history buff, there was even news about World War I codebreaking.

For the can’t-miss articles, the big news was the issues with LoRa mesh communities possibly clashing with the FCC rules and how to make your computer take dictation.

Check out the links if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download an MP3 created with ultra premium ones and zeros.

Continue reading “Hackaday Podcast Episode 388: RAM-Swapping On Raspberry Pi, Raindrops On Radar, And A Fine Mesh” →

World War I Coded Message Appears Cracked, Finally

September 20, 2026 by Al Williams 13 Comments

When you think of wartime cryptography, you probably think of World War II and Enigma, although there were other famous codes used during that war. But in fact, there have been codes used through wars and in peacetime for much longer. Even the Romans used codes. Of course, World War I, or The Great War, as it would have been known, had its share of codes and, as you might expect, most of these have been broken long ago. Most of them. But apparently an AI model, GPT-6 Astra, recently cracked one that was previously undeciphered.

If you aren’t up on century-old cryptography, the ADFGVX cipher appeared in 1918. It began as ADFGX, but after a few months grew an extra letter — and a larger grid. The letters were chosen because their Morse-code patterns were relatively easy to distinguish: A, D, F, G, V, and X.

The original ADFGX version used a 5×5 grid containing the alphabet, usually merging I and J. The later ADFGVX version expanded this to 6×6, making room for all the letters and the digits as well.

Continue reading “World War I Coded Message Appears Cracked, Finally” →

Emulating Memory Access: How Hard Can It Be?

September 19, 2026 by Al Williams 5 Comments

There are so many things we approximate to make life simple. Wires, for example, have no resistance or other strange effects. Crystal oscillators output their exact frequency. But surely our model of how a computer stores and loads memory is accurate, right? You put data in a particular location and, later, you take it out. The [FEX-Emu] developers have a different perspective. Once you have caches and, perhaps, multiple CPUs, it isn’t that easy.

The basic problem is this: if one CPU (or, more accurately, bus master) writes to a location, will another CPU have access to the new value? X86’s Total Store Ordering model gives programmers strong guarantees about when loads and stores become visible, while ARM deliberately uses a weaker memory model that permits considerably more reordering for performance and efficiency.

An emulator can, in theory, compensate by translating ordinary x86 memory operations into ARM acquire/release operations, but doing that for nearly every memory reference can be expensive. Newer ARM extensions such as LRCPC help considerably, while Apple took a more direct approach by adding an x86-compatible TSO mode to Apple Silicon. That lets ordinary loads and stores behave the way translated x86 code expects with comparatively little overhead.

Continue reading “Emulating Memory Access: How Hard Can It Be?” →