If you spend any time near a gym, you may be familiar with Bluetooth heart rate monitors — a small pack of electronics mounted on a strap round the chest which can relay heart rate data to an external logger or display. We’re pleased to see [Milos Rasic]’s project then, an open-source version of one of those monitors.

The heart rate capture is done by an AD8232, while the Bluetooth part is handled by a Seeed Studio XAIO ESP32 board. Power is provided by a single 3.7 V cell, with a boost converter to push that up to 5 V. The design omits a charge controller to keep things simple, so figuring out how to top off the cell is left as an exercise — no pun intended — for the user. Software is loaded through the Arduino IDE, which raises the possibility that other ESP32 CPUs could be supported with a bit of modification. All in all it’s a surprisingly simple project, and while the manufactured version is cheap enough it’s still very much worth having one that’s open source.

If you’d like to know more about his quest to develop open medical devices, check out the talk [Milos] gave on the intricacies of blood pressure monitoring earlier this year at Hackaday Europe.

Once upon a time, you had to carefully budget your microcontroller’s resources if you wanted to do something as simple as flash a bunch of LEDs. These days, they’re powerful enough to humiliate the game consoles of yesteryear. [alexkid77] demonstrates this well, having the ESP32-P4 run Tomb Raider.

Now, [alexkid77] hasn’t gone so far as to create a PlayStation emulator on the ESP32 or anything quite like that. Instead, this is a port—and not of the original Tomb Raider release, either. [alexkid77] started with OpenLara—the classic game running in an open-source engine. With the ESP32-P4 having two cores running at 400 MHz each, there was plenty of processing power on tap to run the engine with a software renderer at 320×240, which is hardware scaled up to 1024×600 via the Pixel Processing Accelerator (PPA) built into the chip. There’s also stereo audio with an ES8311 codec hooked up, while input is via a USB HID keyboard.

It’s funny to think that it could actually be cheaper and quicker to get Tomb Raider running on an ESP32 and a cheap LCD display versus actually going out to buy a PlayStation and an original game disc. But that’s the way the cookie crumbles in 2026. At least you don’t have to play it on an S3 Verge.

Those who have never lived in a cold climate might romanticize winters around a fire, keeping warm under blankets while snow gently falls outside. While it certainly can be a cozy experience, using a woodstove comes with a number of pitfalls, and when operated improperly can even cause house-destroying chimney fires. Modern stoves operated properly with properly dried wood make this possibility extremely remote, but it’s still worth keeping an eye on. Reddit user [nas886] built a system called Oru which takes a lot of the guesswork out using one of these pieces of heating equipment.

The real danger of a woodstove isn’t necessarily running the fire too hot, although that can be a problem, but running it too cold. Without full combustion of the wood, flammable creosote builds up on the inside of the chimney which eventually can combust. This system uses a probe placed in the stovepipe to monitor the temperature of the exhaust gasses. If it’s too low an ESP32 notifies [nas886] remotely with with a status LED inside a seperate custom-built walnut enclosure so that more wood can quickly be added or airflow increased to bring up the temperature, and in the case that the fire gets too hot the LED changes to a different color and the air can be closed off a bit.

Woodstoves themselves have quite a bit of variability in the size wood they can burn, the amount they can hold at once, their efficiency, and their thermal mass, so this could find utility for anyone from those with tiny stoves that have to be fed constantly to those trying to get all-night burns in massive units, all without having to constantly sit by the fire and monitor it. [nas886] found initial success selling a few of these custom units and plans to put it into further production as well, but the general idea is not too difficult to replicate for most of us here either.

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.

[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.

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.

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.

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.

[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.

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!

Although we personally have yet to see anyone brandishing an old digital point-and-shoot camera, we hear they’re back in vogue. Why, though? People are nostalgic for that image quality. While he certainly could have simply picked up a vintage model somewhere for a likely inflated price, [Arnov Sharma] decided to build his own version and call it the PolyShot.

The core of this project is the Unihiker K10 dev board, which uses an ESP32-S3, a whopping 2 megapixel camera, and a micro SD card to capture photos and display them back on the screen. The tricky part, if you can call it that, is the custom PCB. It’s a simple board with just three buttons: shutter, gallery, and next image. We do like that the position of the battery compartment creates a nice grip.

The biggest difference here is that there is a few-second delay between pressing the shutter button and actually capturing the image, which you can see in the short videos below. So if you’re trying to get a shot of a skink or something equally speedy, we wish you good luck.

In a future iteration, [Arnov] wants to address the issue of image quality, because this project ended up evolving into a more traditional digital camera. He would also improve the battery life, for which the current expectancy is around three hours on a charge. Ultimately, [Arnov] wants to ditch the Unihiker and design everything from the ground up, using an ESP32-S3 module.