Open-Source Mid-Drive E-Bike Motor Has Lots Of Promise, And Hyphens

July 18, 2026 by Tyler August No comments

[Pedro Neves] has a mid-drive e-bike, but he doesn’t own it — not truly, since he can’t repair the motor unit. For a hacker to be in that position, there are only two options: crack the old one and make it your own, or build your own from scratch. [Pedro] built his own and is open-sourcing it on his website for everyone to play with. Right now, that’s .step files and a BOM, so you’ll need to watch the design/build video on YouTube below to get the full picture.

His choice of a motor from an old battery-powered angle grinder is both thrifty and environmentally friendly, so we approve. His goal of 25 km/h seems like a reasonable speed limit, but may still be too fast for some countries’ regulations— so do check the local rules if you’re going to build this. Making the most of 3D-printed components is also a choice that makes the project more accessible, but don’t worry — the bearing surfaces are all metal. That includes the clutch bearing that will let you pedal home if the battery dies or the motor craps out. Well, unless the printed plastic axle gives up the ghost, but that got replaced with a CNC version, so it’s all good. Unless you’ve got legs like Hercules, it ought to hold.

If that’s not DIY enough, you could always build the motor yourself. This mid-drive is also part of a larger project [Pedro] is working on for a whole cargo bike, as he details in his video, which is a worthy project we’ve seen other examples of before.

Continue reading “Open-Source Mid-Drive E-Bike Motor Has Lots Of Promise, And Hyphens” →

Write 2D And 3D Games In Modern MoonBASIC

July 18, 2026 by Maya Posch 3 Comments

One of the major strengths of the BASIC programming languages has always been their no-fuss setup and rich set of commands for operations that would take considerably more work in a bare-bones language like C. MoonBASIC continues this legacy with a BASIC variant optimized for both 2D and 3D game development.

Included in the package are Raylib, Box2D, and Jolt, whose functionality is exposed via over 4,200 commands in their respective namespaces. You can also download a whole IDE package based around VS Code, use it on the command line, or add it to an existing VS Code installation.

Continue reading “Write 2D And 3D Games In Modern MoonBASIC” →

Your AI Ham Radio Buddy

July 18, 2026 by Al Williams 4 Comments

AI chatbots are everywhere these days, and they seem to “know” about everything. But while that is a strength, it can sometimes be a weakness because it isn’t laser-focused on one topic. Not so with this Ham-radio-centric chatbot called HamGPT. The service is clearly built on another GPT engine but understands how to retrieve data from common ham radio sources, such as the FCC database, propagation reports, and the like. It didn’t, however, seem to have access to ham radio-related books, magazine articles, or other “static” data that we could tell.

You do have to sign up for an account, which includes providing your callsign and location. There is a free tier that allows a limited number of queries per day, so you can try it to see if it is useful for you without subscribing.

Continue reading “Your AI Ham Radio Buddy” →

Calculator UI Is More Complex Than You Might Think

July 18, 2026 by Donald Papp 16 Comments

Calculators are so ubiquitous and so familiar that they are easy to take for granted in many different ways. [lcamtuf] points out one that has probably never occurred to many of us: the user interface for a calculator is an unexpectedly complex thing.

The internal logic to support sequential inputs and multiple operators in a way that feels intuitive is a complex thing.

Resolving something like 1 + 2 = is pretty straightforward but complexity compounds rapidly after that, with numerous special cases. Let’s imagine one decides to program a simple calculator UI as a weekend project. The development process might look a little like this:

User types in 1 + 2 = and the calculator displays 3. What happens if the user immediately presses -?
No problem, just consider the result of the previous operation as an already-there input. So we’ll have 3 - for this next operation, and wait for more.
Unless we should have treated that - as a negative sign for whatever number is coming next, making it a negative number? No, ignore that. Just treat whatever results from pressing equals as a pre-typed input.
Unless the user hits a number. Because if they hit 2 (for example) then we’ll have a 32 and not a 2 which they probably, definitely don’t expect. So that’s a special case and we should insert a clear if that happens.
Oh, better clear if the user enters a decimal, too.
I’m going to need a coffee…

And that’s just the tip of the iceberg. Imagine trying to figure all this out for the very first time, without the benefits of habit and history to fall back on.

The fact is that supporting the apparently trivial behavior of a simple calculator requires an underlying complex state machine that deals with all kinds of special cases in order to make the UI feel intuitive. And that’s just for a basic four-function calculator; we haven’t even touched on how special keys like % should behave.

We know [lcamtuf] speaks from experience, not just because of their deep knowledge of calculator history but because they rolled their own calculator that uses voltmeters as digit displays and there’s nothing like actually implementing something to make one appreciate it.

ESP32-driven Roulette Wheel Could Have Used A 555, But That Didn’t Have WiFi

July 18, 2026 by Tyler August 4 Comments

Sometimes you see a project and immediately, before going into the details, your mind throws up the old refrain: “coulda used a 555” — well, [Hulk] actually agrees when it comes to his ESP32-based, 3D printed roulette wheel. The first version did use a 555, but then feature creep kicked in and the final project ended up with an ESP32 instead. We’ve all been there.

The roulette wheel circuit is retained from the 555 version, with the ESP32 providing clock pulses instead of the venerable oscillator chip — it uses a pair of decade counters to create the chase effect of the LED around the wheel. With a handsome printed enclosure, [Hulk] could have stopped there, but then he’d have to keep track of scoring and the like manually like some kind of dark age peasant. It’s the 21st century, we have computers to to that for us!

Now, even though the ESP32 is still driving the LED chase via the decade counters, it can keep track of where the “ball” of light lands, and reports that via WiFi or serial. While it would have been an option to run the whole game on the ESP32. [Hulk] just has those values put into an SQL database on a server, which also runs the game front-end via PHP. The resulting web page lets two players make their bets and track their wins and losses over time. You can see that in action in the video embedded below.

Overkill? Sure, but we suspect [Hulk] already had the equipment and experience to make this the fastest way to get a playable game. There are easy ways to serve web content from an ESP32, but the easiest tool to use is always the one in your back pocket, right?

Continue reading “ESP32-driven Roulette Wheel Could Have Used A 555, But That Didn’t Have WiFi” →

Simple Games From A Simpler Time

July 18, 2026 by Elliot Williams 22 Comments

Modern video games are nothing short of amazing. My son and I were playing through the one of the latest Zeldas, which involve a mix of combat and puzzle-solving that’s pretty much the hallmark of the franchise. But the most recent open-world Zelda is simply massive. Made by around 1,000 people at a development expense of $150,000,000, it takes probably 60-80 hours to play through if you’re not rushing, and more if you’re taking it easy. It has layers of game mechanics, and worlds in the sky, on land, and underground. It’s big in every way.

Contrast the games of my youth, which were a lot smaller. Written by a pair of people or maybe a handful, with playtimes in the single-digit hours, and of course fitting in the limited computing resources of the time. But the low-stakes nature of the early phases of the industry meant that software developers could take risks, and many of the games were consequently kinda idiosyncratic in this more innocent time.

I think there’s something to be said for small games. They don’t require a lifestyle commitment just to get through. They can still be fun, without taking all of your time. And honestly, when you’re done with a game quickly, you have more time for other stuff. Granted, some of this spirit lives on in the small indie games of today, but even so, game developers have the big studios’ products in the backs of their minds when they are working on their smaller oeuvres.

We were talking about preserving old games for posterity around Hackaday and on the podcast, and our conversations reminded me of a couple of educational games that, despite their rudimentary graphics, are still pretty good today. Both were electronics related, and both are still playable today thanks to efforts on emulation and software preservation. To get a feel for the 1980’s, give Rocky’s Boots a try. (I like the TRS-80 Color Computer version the best, but that may just be nostalgia.) Most of you grownups out there will get through it in an hour or so.

And if you want a challenge, try Rocky’s harder sequel: Robot Odyssey. If you already have a background in digital circuits, you’ll find it doable. Younger me hit a wall about two-thirds of the way through.

Both of these games stick with me because they taught me something, but also because they were simply quirky in a way that a game can only be when it’s written by a small team of folks who are just having fun programming it. If you pitched “a puzzle game about a raccoon who builds logic circuits to activate robot boots”, the boardroom would look at you like you’re out of your mind. But it’s just exactly the quirkiness and individuality of some of these early games that I cherish the most.

If you find yourself knee-deep in an endless modern game, take a side-quest off into a more naive time, and you’ll appreciate why people are putting efforts into archiving them.

Spidery Drone Goes Near-invisible By Spinning Really, Really Fast

July 18, 2026 by Donald Papp 15 Comments

Researchers demonstrate that something interesting happens when a small drone with a spindly airframe spins at a high speed: it very nearly turns invisible. The spidery device is shown mounted in its launcher in the image above. The dark blur at the rightmost side is an outlet on the wall behind the drone, not motion blur from a moving part.

There’s not much to do about the noise, but a high-speed spin becomes nearly invisible.

It’s called the Phantom Twist, and while we’ve seen single-motor drones that spin around a central axis before, they have always incorporated a wing-like structure or cleverly leverage the magnus effect to generate lift.

There’s not a lot of detail about the Phantom Twist’s hardware design but it appears to use a downward-angled motor for lift, relying on a high-speed control system to maneuver and maintain altitude.

This does away with the need for a wing, at the cost of only being stable while rotating at a high speed. We imagine it is also a touchy design that depends greatly on being balanced just so.

A hand launcher spins the device up before releasing it for flight. The visual effect once it is up and running is pretty striking; see for yourself in the short video, embedded just below.

Continue reading “Spidery Drone Goes Near-invisible By Spinning Really, Really Fast” →