Fat Tire Brakes Get Wireless Upgrade

August 29, 2026 by Bryan Cockfield No comments

At first glance, wireless brakes seem like a recipe for disaster. For something as critical as braking, many bicyclists might prefer a physical connection to their method of safely controlling speed. But there are a number of surprising benefits of electronic or wireless braking systems. For one, they can enable systems like anti-lock braking systems and for another they can eliminate cabling or hydraulics on a bicycle. For these reasons, and just for the thrill of it, [Berm Peak] built a set of wireless brakes for his fat tire bicycle to test out the possibilities.

The system uses a set of ESP32 microcontrollers to handle inputs from the braking lever and outputs to the front and rear brakes, as well as a central control unit and display. The brakes themselves are controlled by actuators from car door locks, which when combined with the springs from the stock calipers work to apply a wide range of braking force to the wheels. These did take a bit of prototyping to get working right, by changing to higher quality calipers, increasing the angle of the actuator, and adding longer levers, but eventually a working braking system started to appear.

But replacing a hydraulic system with an electronic one isn’t where something like this shines. [Berm Peak] was able to add in a number of features impossible in traditional braking systems. Not only does this have an ABS system and the possibility to remotely slow down his children’s bikes when they’re riding, but there’s also a braking equalizer that allows the rider to control how much braking there is at certain positions of the brake lever, and another setting called “derp” which doesn’t engage the brakes at all until a certain threshold has passed. This might end up being the next big trend in mountain biking, unlike airless tires.

Continue reading “Fat Tire Brakes Get Wireless Upgrade” →

Building A Headless Game Boy Emulator

August 28, 2026 by Zoe Skyforest 5 Comments

[Artificial-Age] has built a rather unique way to play old Game Boy games. It’s an emulator, but it doesn’t work in quite the way you might think!

Since the Game Boy is a relatively simple 8-bit machine that runs at a leisurely 4 MHz or so, it is well within the capabilities of an ESP32 microcontroller to emulate. [Artificial-Age] got an ESP32-S3 and programmed it to do just that. However, there’s a twist—there is no screen hooked up to the microcontroller, nor any buttons. Instead, the board is accessed over a WiFi access point that it hosts itself.

One then opens a web browser, which streams the emulated video and audio from the console, while accepting button inputs from your keyboard or touchscreen, depending on the platform you’re viewing the web interface on. ROMs are stored on the ESP32’s flash storage, and can be uploaded via the web interface.

It’s an interesting setup, and one that perhaps doesn’t make obvious sense at first. After all, any modern smartphone can easily emulate a Game Boy, too. However, this setup makes it easy to share the emulator with other people, who can simply check out the WiFi AP and web interface without having to download or or install anything on their own device. We’ve featured some other fun emulation projects lately, too.

Continue reading “Building A Headless Game Boy Emulator” →

Eenk Provides EInk, ESP32 Powered Text Adventures

August 27, 2026 by Tyler August 15 Comments

There’s a niche genre of text adventure that’s halfway between a traditional novel and a videogame. Think Zork if it had an extra few novels worth of words of well-crafted story to go with the action. [t0mg] is a fan of such adventures, and also quite enjoys carrying around his palm-sized ESP32 powered Xteink e-ink reader, so decided to create a project to merge the two interests, called eeink.

The Xteink readers have gotten popular lately because their modest internals and size make them very affordable. Not to mention hackable, since they’re basically an ESP32-C3 e-ink dev board that comes with a nice case and battery. The X4 Pro notably comes with an ESP32-S3 which means a lot more RAM, but this project targets both that and the X3/X4 that use the C3 version. Using the C3 means working within some rather stringent limits, as Xteink didn’t spring for any PSRAM, so [t0mg] had less memory to work with than folks did in the 80s.

This project is specifically focused on adventures using the scripting language ink, and comes with its own IDE called eenky to roll your own choose your own adventure book. It’s all on GitHub under an MIT license, and if you want to see it in action there’s a demo video embedded below.

Speaking of Zork, it wasn’t just the first commercial text adventure; it brought some important technological innovations, too.

Continue reading “Eenk Provides EInk, ESP32 Powered Text Adventures” →

Claude Plays DOOM

August 26, 2026 by Zoe Skyforest 30 Comments

Large language models (LLMs) are generally thought of as machines that accept textual prompts and spit out textual content. However, if you’re creative in the way you interface with them, you can get them to do a wider range of tasks. For example, [Andrea Ricci] figured out how to get one to play DOOM.

For this project, [Andrea] began by porting the game to the SCINTIX P4. It’s a rather interesting device, being a single board designed in the Raspberry Pi CM4/CM5 form factor, but carrying an ESP32-P4 and an ESP32-C6 instead. The game runs on the P4 and is displayed on a 1024×600 MIPI DSI panel, but it’s only stepped through a few frames at a time. These frames are then passed to Claude Sonnet via a WebSockets setup. With only the same information as a human player would get, the LLM has to figure out what it’s looking at, and then respond with movement and fire commands to play the game.

It’s quite interesting to watch the system play—the LLM mostly accurately describes the game world, navigates down corridors, opens doors, and shoots at enemies. There is a bit of work behind the scenes to enable it to see and understand the game world—namely, using a depth fan across the field of view so it can figure out where walls are and how not to bang into them. There’s also an ASCII automap used to allow the system to keep track of where it has already been. But fundamentally, the LLM is playing the game without any other sort of additional assistance.

We’ve seen some other great ways in which AIs have been whipped up to play various games, like Trackmania.

Continue reading “Claude Plays DOOM“ →

At Last, A Gameboy Advance With Decent Audio

August 24, 2026 by Jenny List 2 Comments

Many pieces of consumer electronics are build down to a price, and the corners cut show up in their performance. The Gameboy Advance from Nintendo is no exception: its audio is a PWM stream that sounds awful through the included amplifier. [Cajun Panda] has a fix though, in the form of a replacement audio chain.

It takes the form of a PCB that hooks into the pads of the removed GBA audio chip, and provides a much cleaner audio path with filtering and EQ and a class D audio amplifier. In addition there’s an audio codec and an ESP32 for Bluetooth connectivity, enabled by a long press of a GBA button and configured via a web interface on the ESP. Best of all there is no case modification, this is designed to remain as stock as possible.

Everything can be found in a GitHub repository should you wish to make your own, so if you want to bring your GBA audio up to scratch you know where to go. If you want to make it even better don’t forget, you can always upgrade the screen.

An arm and a hand: on the arm is a chunky blue box, and in the hand is a phone showing a dashboard.

HYDR8 Will Lead You To Water, But Will You Drink?

August 19, 2026 by Kristina Panos 16 Comments

[Ayushmaan] states up front that most of his free time is spent “building things that probably didn’t need to exist”. Well, this one might be an anomaly, because it seems pretty useful to us.

HYDR8, as it says on the tin, is a wearable that knows when it’s time to hydrate. The impetus for this one was something we all chase: the flow state. [Ayushmaan] would sit down, get deep into work, and look up hours later to to find that he had a headache and a full water bottle. Phone reminders were soon swiped away in annoyance.

This wearable is based on a XIAO ESP32-C3. It reads heart rate, oxygenation, skin temperature, and both the ambient temperature and humidity. It also learns your personal resting numbers range.

Taking all of this into consideration, it generates a heat/hydration stress score between 0-100. The thing is, HYDR8 tells you specifically what to do; sometimes it’s ‘drink water’ and other times, it’s ‘find shade’.

The wearable itself, while somewhat chunky, is pretty simple: it only shows the time and a message when it matters. The ESP32 hosts a full dashboard on your phone.

Keep in mind that this is not a medical device, it’s an experiment, a prototype. It can’t measure how hydrated you are. Instead, it measure hydration stress.

If you don’t want to wear anything, here’s a smart straw that uses a tiny turbine flowmeter and a Hall effect sensor to record the volume sipped, and detect whether the sipper is low on fluids. And if you find yourself under the hot lights of a wet bulb event, here’s how to survive it.

Reverse Engineered Grill Controller Gets Open Firmware

August 18, 2026 by Fenix Guthrie 14 Comments

If you are a regular reader, then the odds are you have taken apart an electronic gadget, either for a fix, or simply because your curiosity got the better of you. Once inside, it’s all but impossible to help yourself from doing at least a little reverse engineering. That’s what happened when [PRBS23] took a look inside a MasterBuilt Gravity 800 Grill for a simple wire fix. But one thing led to the next, and now open source firmware for the grill is freely available!

The first order of business in creating the firmware is reverse engineering the original controller. Opening it up immediately reveals an ESP-32 and a well-labeled programming port. The rest of the control board is equally simple, including connectors for four thermistor temperature sensors, lid open/close switch, fan driver, 16 segment LCD, piezo buzzer, and some physical inputs.

The thermistor along with the physical inputs are connected to a 16 pin chip, interfacing with the MCU over a 9600 baud UART connection. [PRBS23] cannot determine an ADC chip meeting these specifications, so the most likely answer is a cheap MCU programmed to act as a simple analog fronted.

The neatly labeled programming header is used to quite easily dump the firmware with the espflash utility. Analyzing this dump reveals a rather strange ADC correction function used by the original firmware. The necessity and overall utility of this function remains unclear, does corrects a maximum of around 40 degrees Fahrenheit.

Most of the other features ended up being at least somewhat easier. The CS1621 segmented display driver is reasonably well documented with datasheets making its implementation far easier. Likewise, the other odds and ends were implemented in a far more normal manner compared to the thermistors.

All this reverse engineering work got tied together into a neat little firmware package. It comes with over the air updates PID controlled temperature, and a real-time web interface. This also isn’t the first time we have seen an IoT device liberated from proprietary firmware, and this remains one of our favorite uses of reverse engineering!