While for most people Pluto is the most distant planet in the Solar System, things get a lot more fuzzy once you pass Neptune and enter the realm of trans-Neptunian objects (TNOs). Pluto is probably the most well-known of these, but there are at least a dozen more of such dwarf planets among the TNOs, including 90377 Sedna.

This obviously invites the notion of sending an exploration mission to Sedna, much as was done with Pluto and a range of other TNOs through the New Horizons spacecraft. How practical this would be is investigated in a recent study by [Elena Ancona] and colleagues.

The focus is here on advanced propulsion methods, including nuclear propulsion and solar sails. Although it’s definitely possible to use a similar mission profile as with the New Horizons mission, this would make it another long-duration mission. Rather than a decades-long mission, using a minimally-equipped solar sail spacecraft could knock this down to about seven years, whereas the proposed Direct Fusion Drive (DFD) could do this in ten, but with a much larger payload and the ability do an orbital insertion which would obviously get much more science done.

As for the motivation for a mission to Sedna, its highly eccentric orbit that takes it past the heliopause means that it spends relatively little time being exposed to the Sun’s rays, which should have left much of the surface material intact that was present during the early formation of the Solar System. With our explorations of the Solar System taking us ever further beyond the means of traditional means of space travel, a mission to Sedna might not only expand our horizons, but also provide a tantalizing way to bring much more of the Solar System including the Kuiper belt within easy reach.

There is always the promise of using more computing power for a single task. Your computer has multiple CPUs now, surely. Your video card has even more. Your computer is probably networked to a slew of other computers. But how do you write software to take advantage of that? There are many complex systems, of course, but there’s also Chapel.

Chapel is a reasonably simple programming language, but it supports parallelism in various forms. The run time controls how computers — whatever that means — communicate with one another. You can have code running on your local CPUs, your GPU, and other processing elements over the network without much work on your part.

What’s it look like? Here’s a simple distributed program from the project’s homepage:

// print a message per compute node
coforall loc in Locales do
  on loc do
    writeln("Hello from locale ", loc.id);

// print a message per core per compute node
coforall loc in Locales do
  on loc do
    coforall tid in 0..<here.maxTaskPar do
       writeln("Hello from task ", tid, " on locale ", loc.id);

As you might guess, Locales is an array of locale objects that each describe some computing resource. The coforall statement splits a loop up to run on different locales or CPUs. You can even write GPU kernels:

coforall (gpu, row) in zip(here.gpus, localRowStart..) do on gpu {

You can try it in your browser, but for best results, you really want to download it or run it in a container. The license is Apache 2.0, so you can even contribute if you want to. If you want to really do distributed work, be sure to grab the package built for GASNet or Slurm.

While it is something new to learn, you might find it easier and more generally applicable than something like CUDA.

If the idea of reading a physical book sounds like hard work, [Nick Bild’s] latest project, the PageParrot, might be for you. While AI gets a lot of flak these days, one thing modern multimodal models do exceptionally well is image interpretation, and PageParrot demonstrates just how accessible that’s become.

[Nick] demonstrates quite clearly how little code is needed to get from those cryptic black and white glyphs to sounds the average human can understand, specifically a paltry 80 lines of Python. Admittedly, many of those lines are pulling in libraries, and some are just blank, so functionally speaking, it’s even shorter than that. Of course, the whole application is mostly glue code, stitching together other people’s hard work, but it’s still instructive and fun to play with.

The hardware required is a Raspberry Pi Zero 2 W, a camera (in this case, a USB webcam), and something to hold it above the book. Any Pi with the ability to connect to a camera should also work, however, with just a little configuration.

On the software side, [Nick] pulls in the CV2 library (which is the interface to OpenCV) to handle the camera interfacing, programming it to full HD resolution. Google’s GenAI is used to interface the Gemini 2.5 Flash LLM via an API endpoint. This takes a captured image and a trivial prompt, and returns the whole page of text, quick as a flash.

Finally, the script hands that text over to Piper, which turns that into a speech file in WAV format. This can then be played to an audio device with a call out to the console aplay tool. It’s all very simple at this level of abstraction.

Yes, we know it’s essentially just doing the same thing OCR software has been doing for decades. Still, the AI version is remarkably low-effort and surprisingly accurate, especially when handling unusual layouts that confound traditional OCR algorithms. Extensions to this tool would be trivial; for example, adjusting the prompt to ask it to translate the text to a different language could open up a whole new world to some people.

If you want to play along at home, then head on over to the PageParrot GitHub page and download the script.

If this setup feels familiar, you’d be quite correct. We covered something similar a couple of years back, which used Tesseract OCR, feeding text to Festvox’s CMU Flite tool. Whilst we’re talking about text-to-speech, here’s a fun ESP32-based software phoneme synthesiser to recreate that distinctive 1980s Speak & Spell voice.

If you are anything like us, last time you went bowling, you thought more about how the ball came back to you than actually knocking down the pin. Perhaps you even wondered what it would be like to be a bowling ball making its way back through mysterious and hidden machines. [Wren] and [Erik Beck] did as well, so they set out to make a bowling ball camera to find out.

At the heart of the contraption is an Insta360 X5 camera nestled between water-jet cut metal plates. Because each lens of the camera has a 200 degree field of view, anything in the overlap of the two lenses simply does not appear, so the two metal plates likewise, do not appear. This does leave a somewhat noticeable seam down the middle of the footage, but overall worked out very well. To prevent vibrations in the bowling ball, it can only be rolled along the plate line, making said seam appear in all the footage. Because the stabilization is happening purely digitally, and the camera itself is spinning with the ball, motion blur became an issue immediately. Fortunately increasing the shutter speed fixed the issue, along with an increase in ISO to compensate for the decreased exposure.

The outer shell was made of two acrylic or polycarbonate domes, with the former providing better optics, and the latter better strength. Unfortunately, clear half-domes can only be formed in certain sizes, and the closest to the standard bowling ball size of 8.5 inches was 8 inches. This led to many challenges come filming, resulting in neither the pin-side pickup nor the bowler side pickup being able to grip the ball. The pin side was solved using a simple foot, but the bowler side proved more challenging. After many attempts with cardboard shimming, the team finally just gave it a push with a regular sized bowling ball pushed in afterward.

The footage turned out brilliantly, and we would love to see a V2 of a correct diameter. Now, this is not the first time we have covered strange bowling engineering, make sure to read this piece on pins with strings next!

What if you build a clock that displayed the time not just on its own, but in its shadows as well? [Lewis] from [DIY Machines] has done just that, with a nifty 3D-printed shadow clock build.

The clock itself has a hollow rim inside which are the two hands which actually display the time. The hands appear to almost float inside the clock, a tricky visual effect of the design which instantly catches the eye. The trick is simple—the minute hand is physically attached to the outer rotor, which sets its position. Meanwhile, the floating hour hand pivots freely around the center of the clock, with a secret magnet within. This magnet is attracted to a complementary magnet in the hour rotor—as that rotor turns, the hour hand points at the magnets inside.

So far, it’s already a cool clock. The bonus feature is that [Lewis] realized this design could show an even larger clockface on the wall behind, merely by using its shadows. Thus, the clock features an LED light source which can project the clock’s shadows into a much larger display than the desktop timepiece itself.

As for the electronics, it’s straightforward stuff. An ESP8266 devboard runs the show, turning stepper motors and controlling addressable LEDs to make the clock do its thing. It also queries a network time server in order to ensure the displayed time is always accurate to the second.

We’ve featured some other excellent clocks over the years, like this incredible thermochromic build. Video after the break.

Running DOOM on ARM? Old hat. Running Doom (2016) on an ARM SBC? Well, that’s a bit more interesting, and [Interfacing Linux] shows us how with this handy guide, and in a video embedded below.

The ARM SBC in question is the Radxa Orion O6, which claims to be the world’s first open source ARMv9 motherboard. It has a 12-core ARM9.2 SoC from Cix, and crucially for gaming, a PCIe x16 slot to fit a graphics card. There’s onboard graphics in the SoC, of course, but that’s only going to cut it for old DOOM, not Doom (2016).

Obviously there is no ARMv9 build of this nine-year-old classic. Thus, a certain degree of hacking is required. An x86 emulation layer called FEX is used to run Steam, which includes the Proton compatibility layer to sit between the Linux system and the Windows system calls the games are making.

So, again: Windows games, running via a compatibility layer on a Linux system running on an x86 emulator, running on another Linux system, running on ARM hardware. Yeah, we’d call that a hack, and just possibly cursed. The amazing thing is that it works. As long as you use a PCI 3.0 graphics card, anyway; apparently newer ones don’t work, or at least not the one [Interfacing Linux] had to try. (Some report better luck with newer NVIDIA cards.) Which is a pity, because every game tested is GPU-throttled on this system. Considering the CPU should be handling all the emulation, that just goes to show how GPU-heavy even 10-year-old games are.

[Interfacing Linux] seems to enjoy running things where they should not; we just wrote up their SteamOS console.

This isn’t the first time a Radxa board has shown up on Hackaday either, but they don’t seem to be nearly as popular as the fruit-flavoured competition for the sort of projects we usually see. If you’ve got a good project using one of these powerful ARM boards– or anything else, don’t hesitate to send us a tip!

How would you go about identifying usable land that suits your building tastes? [Scott Sexton] was specifically looking for land that’s not too steep to build on, and realized that existing resources didn’t easily offer him this information. He thus dived into the world of GIS to try and solve this issue for himself.

[Scott] hoped that USGS maps might provide the information he needed, but found they lacked grade information, only presenting elevation and topographic data instead. From past experience reading such maps, he knew that seeing a lot of topographical lines close together tended to indicate steeper areas, but wasn’t sure on how to actually get the computer to parse this and spit out the information on steepness and grade that he wanted.

Ultimately, he set about downloading USGS elevation data in three-meter resolution. He then applied some calculus to determine the rate of change of the slope across areas of the data in order to mathematically find what he was looking for. Namely, flatter areas that would be more suitable for future construction. He then took the work even further, tweaking the output of his tools and automating until he could quickly and readily generate usability maps of areas of interest. He was even able to sanity-check his work by verifying that it correctly identified roads as obviously flat areas.

If you’ve ever tinkered with GIS work, [Scott’s] usability project may be of some interest. We’ve also seen amusing examples of what can go wrong when digital mapping data is used without sanity checks. Meanwhile, if you’ve got your own GIS hacks on the go, don’t hesitate to notify us via the tipsline!

Like the rest of us, 8-bit hardware is not getting any newer, and failed ROMs are just a fact of life. Of course you can’t call up Commadore corporation for replacement parts anymore, so something is needed. [Peirs Rocks] wasn’t satisfied with the existing options, so he came up with the Software Defined Retro ROM to serve as a drop-in replacement for 2364, 2332, and 2316 ROM chips.

Physically, the Software Defined Retro ROM is a PCB that matches the footprint of the original ROM chip, and holds an STM32F4 family microcontroller with a number of extra pins facing upwards. Some of those pins are for programming, so you can flash the board in-situ without removing it from the system using a Pi Pico. The others pins are jumpers for image selection or chip configuration. Depending which STM32 you use, you can have upto 16 ROM images on the board, at whatever chip select behaviour you require. The ROM’s chip select lines could be configured at the factory to answer to HIGH or LOW, and this board can handle either with a jumper swap.

The documentation on the GitHub is very well done, for which we applaud [Piers]. Instructions and demos are also available in the video embedded below. We could certainly see this hack becoming popular in the retrocomputer community, especially as everything ages and memories continue to, uh, y’know. What were we talking about, again?

Oh, right, ROMs. You might think an mask ROM would last a very long time, but it’s been a very long time since some of these were made. Best to dump them while you still can. If the chip is really far gone electrically, you might try decoding a photograph of the die.

Sometimes a write-up of a piece of retrocomputing hardware goes way beyond the hardware itself and into the industry that spawned it, and thus it is with [OldVCR]’s resurrection of a Blasto arcade board from 1978. It charts the history of Gremlin Industries, a largely forgotten American pioneer in the world of arcade games, and though it’s a long read it’s well worth it.

The board itself uses an Intel 8080, and is fairly typical of microcomputer systems from the late 1970s. Wiring it up requires a bit of detective work, particularly around triggering the 8080’s reset, but eventually it’s up and playing with a pair of Atari joysticks. The 8080 is a CPU we rarely see here.

The history of the company is fascinating, well researched, and entertaining. What started as an electronics business moved into wall games, early coin-op electronic games, and thence into the arcade segment with an 8080 based system that’s the precursor of the one here. They even released a rather impressive computer system based on the same hardware, but since it was built into a full-sized desk it didn’t sell well. For those of us new to Gremlin Industries the surprise comes at the end, they were bought by Sega and became that company’s American operation. In that sense they never went away, as their successor is very much still with us. Meanwhile if you have an interest in the 8080, we have been there for you.

If you’re a regular GitHub user you’ll be familiar with the website’s graphical calendar display of activity as a grid. For some of you it will show a hive of activity, while for others it will be a bit spotty. If you’re proud of your graph though, you’ll want to show it off to the world, and that’s where [HarryHighPants]’ Git Contributions E-Ink Display comes in. It’s a small desktop appliance with a persistent display, that shows the current version of your GitHub graph.

At its heart is an all-in-one board with the display and an ESP32 on the back, with a small Li-Po cell. It’s all put in a smart 3D printed case. The software is the real trick, with a handy web interface from which you can configure your GitHub details.

It’s a simple enough project, but it joins a growing collection which use an ESP32 as a static information display. The chip is capable of more though, as shown by this much more configurable device.

It’s always clock time at Hackaday, and this time we have an interesting hack of a clock by [danjovic]– the CIS4, a Cistercian digital clock.

The Cistertians, in case you weren’t paying close attention to European holy orders during the 13th to 15th centuries were the group of monks you’d most likely have found us in. They were the hackers of the middle ages, establishing monestaries across western Europe that were chock full of hacks– including their own numeral system. Cistercian numerals were much more efficient (in spaces and penstrokes) than the Roman numerals they replaced, and even the “Arabic” numerals that replaced them. A single glyph could record anything from 1 to 9,999. (The Europeans hadn’t yet cottoned on to zero.)

Depending how you wanted to count time, a single glyph could be used; it looks like [danjovic] is using the thousands and hundreds portions of the glyph for hours and the tens and ones for minutes. This is all accomplished with a 4×4 neopixel matrix, run by an Attiny85 Digispark with a DS3231 RTC module keeping time. A slight simplification is required to reduce the glyphs to 4×4, but we don’t think the monks would mind. For those of us who don’t wear tonsures, an easy read mode scrolls the time in Arabic numerals. (Which still aren’t super easy,with only 4×4 LEDs to display them. See the demo video embedded below and try and guess the time.)

One nice quality of life feature is an LDR for ambient light detection, to automatically adjust the neopixels’ brightness. The hackiest part, which we thought was really clever, is the enclosure: it’s a cheap LED ceiling light. This provides a diffuser, housing and mounting hardware with decent design for no effort. A 3D-printed mask sits between the diffuser and the LEDs and doubles as a PCB holder. All very elegant.

[danjovic] did include a buzzer in the design, but does say if its been programed to sound off for matins, nones and vespers. In any case, at least it’s easier to read than his binary-coded-octal clock that we featured a few years back. This isn’t our first look at this number system,so evidently people can read them with practice.

Have you made or seen a cool clock? Send us a tip. We always have time for clocks.

Gaming on a Nintendo DS can bring back great memories of long car trips from the past. But looking back, we remember wishing to play more than the DS could ever hope to handle. [fami] looks into the SuperCard DSTWO in her recent video, a solution to our past sorrows.

Able to play anything from the very games designed for the DS to emulated PS1 games, the DSTWO is more than capable of surpassing the abilities of the DS itself. More impressively, all games are run directly from the cartridge itself rather than on the DS’s hardware. While this emulated console within a handheld is impressive, it is far from simple to get running.

The DSTWO runs with an Ingenic JZ4732 as the CPU, completely different from any native architecture of the DS. Pair this with the unhelpful SDK made for the cartridge, and the aging hardware is held together by the community development behind any improvements. This is aided by the CPU similarities of another widely modded game console, the Dingoo A320.

When not having a fit, and after going through hours of troubleshooting, you might find the DSTWO running a game of SimCity 2000 or even Spyro the Dragon inside a DS. Even with the difficulties of use, the fact that these games run at all is impressive. If you want to try the DSTWO emulation yourself, check out the forums.

This is far from the only example of extreme care going into emulation. Here at Hackaday, we have covered similarly impressive projects such as this completely DIY handheld made for any retro game emulation you throw at it.

Thanks to DjBiohazard for the tip!

EFI from cables is something every ham loves to hate. What if you modulated, that, though, using an ordinary cable as an antenna? If you used something ubiquitous like a video cable, you might have a very interesting exploit– which is exactly what [Xieyang Sun] and their colleagues have done with TEMPEST-LoRa, a technique to encode LoRa packets into video files.

The concept is pretty simple: a specially-constructed video file contains information to be broadcast via LoRa– the graphics card and the video cable serve as the Tx, and the Rx is any LoRa module. Either VGA or HDMI cables can be used, though the images to create the LoRa signal are obviously going to differ in each case. The only restriction is that the display resolution must be 1080×1920@60Hz, and the video has to play fullscreen. Fullscreen video might make this technique easy to spot if used in an exploit, but on the other hand, the display does not have to be turned on at the time of transmission. If employed by blackhats, one imagines syncing this to power management so the video plays whenever the screen blanks. 

According to the pre-print, a maximum transmission distance of 81.7m was achieved, and at 21.6 kbps. That’s not blazing fast, sure, but transmission out of a totally air-gapped machine even at dialup speeds is impressive. Code is on the GitHub under an MIT license, though [Xieyang Sun] and the team are white hats, so they point out that it’s provided for academic use. There is a demo video, but as it is on bilbili we don’t have an easy way to embed it. The work has been accepted to the ACM Conference on Computer and Communications Security (2025), so if you’re at the event in Taiwan be sure to check it out. 

We’ve seen similar hacks before, like this one that uses an ethernet cable as an antenna. Getting away from RF, others have used fan noise, or even the once-ubiquitous HDD light. (And here we thought casemakers were just cheaping out when they left those off– no, it’s security!)

Thanks to [Xieyang Sun] for the tip! We’ll be checking the tips line for word from you, just as soon as we finish wrapping ferrites around all our cables.

[Ryan] of [Fat Lip Collective] has been on a streak of using 3D printing for his car mod projects. From spark plug adapters to exhaust pipes to dash panels, his CAD skills and additive manufacturing tech have played a number of roles in his process.

Most recently, [Ryan] has embarked on a mission to equip an ’80s-era Toyota KE70 Corolla with a turbo engine. The main question there being how to fit the engine back into the car once he’s inserted a salvaged turbo into the exhaust line.

There is a non-trivial amount of stuff that needs to be packed in with the rest of the engine and finding a working configuration that doesn’t get in the way of anything else requires some trial and error. Furthermore, the alignment of the many twisting and turning pieces of schedule 40 pipe that will direct gasses where they need to go needs to be pretty precise.

Juggling all of this would be tedious, time consuming, and error prone if it were not for [Ryan’s] mighty 3D printer. He printed a set of the different elbows and reducers modeled on the schedule 40 pipe that he would likely be using. He added degree markers for easy reference later and flat sections at the ends of each piece so they could be bolted to each other. With this kit of parts in hand, he was able to mock up different arrangements, re-configuring them as he considered the position of other nearby components.

The project is still ongoing. but we’re looking forward to seeing [Ryan] roaring around in his souped-up Corolla soon. In the meantime you can go deeper on ways of adding turbo to vehicles from the ’90s, the innovation of the Mercedes Formula 1 split turbo engine, and see the evolution of a 3D-printed pulsejet turbocharger.

Thanks to [Ryan Ralph] (not the same Ryan) for tipping us off.

These days ‘AI’ is everywhere, including in software development. Coming hot on the heels of approaches like eXtreme Programming and Pair Programming, there’s now a new kind of pair programming in town in the form of an LLM that’s been digesting millions of lines of code. Purportedly designed to help developers program faster and more efficiently, these ‘AI programming assistants’ have primarily led to heated debate and some interesting studies.

In the case of [Jj], their undiluted feelings towards programming assistants like GitHub Copilot burn as brightly as the fire of a thousand Suns, and not a happy kind of fire.

Whether it’s Copilot or ChatGPT or some other chatbot that may or may not be integrated into your IDE, the frustration with what often feels like StackOverflow-powered-autocomplete is something that many of us can likely sympathize with. Although [Jj] lists a few positives of using an LLM trained on codebases and documentation, their overall view is that using Copilot degrades a programmer, mostly because of how it takes critical thinking skills out of the loop.

Regardless of whether you agree with [Jj] or not, the research so far on using LLMs with software development and other tasks strongly suggests that they’re not a net positive for one’s mental faculties. It’s also important to note that at the end of the day it’s still you, the fleshy bag of mostly salty water, who has to justify the code during code review and when something catches on fire in production. Your ‘copilot’ meanwhile gets off easy.

Here’s a clever hack. Simple, elegant, and eminently cost-effective: using an SMD capacitor to hold your flash media in place!

This is a hack that can pretty much be summed up with just the image at the top of the page — a carefully placed SMD capacitor soldered to a routed tab makes for an extremely cost effective locking mechanism for the nearby SD card slot. There’s just enough flexibility to easily move the capacitor when its time to insert or eject your media.

It’s worth noting that the capacitor in this example doesn’t even appear to be electrically connected to anything. But there’s also no reason you couldn’t position one of the capacitors in your existing bill of materials (BOM). This form of mechanical support will be much cheaper than special purpose clips or mounts. Not a big deal for low-volume projects, but if you’re going high-volume this is definitely something to keep in mind.

If you’re just getting started with SMD capacitors then one of the first things to learn is how to solder them. Also, if you’re hoping to salvage them then try to look for newer equipment which is more likely to have SMD components than through-hole. If you’re planning to use your capacitors for… “capacitance” (how quaint), you can start by learning the basics. And if you want to know everything you can learn about the history of capacitors, too.

Thanks to [JohnU] for writing in to let us know about this one. Have your own natty hacks? Let us know on the tipsline!

You could use a little pocket-sized Pez dispenser if you’re a humble, reserved person. Or, you could follow the example of [Backhaul Studios], and build a dangerously powerful blaster that shoots Pez fast enough to shatter them into pieces. Just don’t aim it at your own mouth.

As the video explains, Pez is really the perfect candy for this application. It’s compact, hard, and already designed to be dispensed via a magazine. It’s thus not a big stretch to set it up to be fired out of a pistol-like blaster. The build is of the flywheel type, where a pair of counter-rotating wheels fling the candy out at great speed. The wheels themselves are spun up to high speed with a pair of small brushless motors, running off hobby speed controllers and lithium-ion batteries. A simple trigger mechanism dispenses the rectangular candies into the wheel mechanism, sending them flying out of the blaster at will. It’s all 3D-printed, designed specifically for the purpose of high-speed candy delivery.

The video goes into great detail on the design, from the development of the TPU treads on the flywheels and other details that helped improve the effectiveness of the design. The final build shoots Pez fast enough that they practically detonate upon hitting a surface.

We’ve featured some innovative work in this space from [Backhaul Studios] before—the condiment cannon was really quite something. Video after the break.

So-called artificial intelligence (AI) is all the rage right now between your grandma asking ChatGPT how to code in Python or influencers making videos without having to hire extras, but one growing concern is where the power is going to come from for the data centers. The MIT Technology Review team did a deep dive on what the current situation is and whether AI is going to kill us all (with carbon emissions).

Probably of most interest to you, dear hacker, is how they came up with their numbers. With no agreed upon methods and different companies doing different types of processing there were a number of assumptions baked into their estimates. Given the lack of information for closed-source models, Open Source models were used as the benchmark for energy usage and extrapolated for the industry as a whole. Unsurprisingly, larger models have a larger energy usage footprint.

While data center power usage remained roughly the same from 2005 to 2017 as increases in efficiency offset the increase in online services, data centers doubled their energy consumption by 2023 from those earlier numbers. The power running into those data centers is 48% more carbon intensive than the US average already, and expected to rise as new data centers push for increased fossil fuel usage, like Meta in Louisiana or the X data center found to be using methane generators in violation of the Clean Air Act.

Technology Review did find “researchers estimate that if data centers cut their electricity use by roughly half for just a few hours during the year, it will allow utilities to handle some additional 76 gigawatts of new demand.” This would mean either reallocating requests to servers in other geographic regions or just slowing down responses for the 80-90 hours a year when the grid is at its highest loads.

If you’re interested in just where a lot of the US-based data centers are, check out this map from NREL. Still not sure how these LLMs even work? Here’s an explainer for you.

Mjolnir, also known as Thor’s hammer, is a discerning thing, at least if you believe the modern Marvel canon. [alemanjir] decided to build a semi-functional replica that makes judgement calls of its own, though they’re perhaps a little less thought-out than the storied hammer of legend.

The build consists of a 3D-printed hammer prop, inside of which is a Raspberry Pi Pico microcontroller running the show. It’s hooked up to a MPR121 touch sensor that detects when someone grips the handle of the hammer. At this point, the Pico makes a pseudorandom “worthiness check” as to whether the holder is righteous enough to wield the hammer. If they are pure of heart, it unlocks a magnet which frees the hammer from whatever metallic surface it might be stuck to. [alemanjir] also included a little additional functionality, with the hammer playing various sounds when swung thanks to a speaker and a ADXL345 accelerometer secreted inside.

One wonders whether the electromagnet inside is strong enough to hold out against an unworthy person lifting it from the ground. While it’s perhaps not as powerful or as decisive as the mythical object, it’s nonetheless a fun learning project that likely taught [alemanja] some useful basics of embedded development.

We’ve featured some terrifying takes of the Mjolnir prop before, too, like this shockingly high voltage version. Video after the break.