The site controller board

Homebrew Dam Control System Includes All The Bells And Whistles

Over on brushless.zone, we’ve come across an interesting write-up that details the construction of a dam control system. This is actually the second part, in the first, we learn that some friends purchased an old dysfunctional 80 kW dam with the intention of restoring it. One friend was in charge of the business paperwork, one friend the mechanical side of things, and the other was responsible for the electronics — you can probably guess which ones we’re interested in.

The site controller is built around a Nucleo-H753 featuring the STM32H753ZI microcontroller, which was selected due to it being the largest single-core version of the dev board available. This site controller board features a dozen output light switches, sixteen front-panel button inputs, dual 24 V PSU inputs, multiple non-isolated analog inputs, atmospheric pressure and temperature sensors, multiple analog multiplexers, a pair of SSD1309 OLED screens, and an ESP32 for internet connectivity. There’s also fiber optic TX and RX for talking to the valve controller, a trio of isolated hall-effect current sensors for measuring the generator phase current, through current transformers, four contactor outputs (a contactor is a high-current relay), a line voltage ADC, and the cherry on top — an electronic buzzer.

The valve controller has: 48 V input from either the PSU or battery, motor phase output, motor field drive output, 8 kV rated isolation relay, limit switch input, the other side of the optical fiber TX and RX for talking to the site controller board, and connectors for various purposes.

If you’re interested in seeing this dam control system being tested, checkout the video embedded below.

Continue reading “Homebrew Dam Control System Includes All The Bells And Whistles”

Serial And UPDI Handled Together With One Convenient Circuit

Sometimes it’s nice when you can do everything you need to do with just one single port. In this vein, [Nicola Strappazzon] whipped up a circuit to combine serial and UPDI programming in a very convenient way.

As an example, [Nicola] demonstrates the concept using an AVR128DA28 microcontroller. It’s paired with a 4052 multiplexer IC and a CH340 USB-to-serial chip. Everything is wired up such that the 4052 acts as a switch for the signal coming from the CH340. When the RTS flow-control signal is set high, it switches the 4052 to hook up the CH340’s RX and TX pins to the UDPI interface on the AVR microcontroller. Conversely, when the RTS signal is set low, the CH340 is instead hooked up to the serial UART on the microcontroller. From there, it’s a simple matter of configuring avrdude to properly set the RTS pin when attempting to program the attached device.

If you’re working with UPDI devices and you want to be able to talk to them and program them with a minimum of fuss, this project might be useful for you. We’ve looked at dedicated UPDI programmers before, too. If you’re cooking up your own nifty microcontroller hacks, don’t hesitate to let us know on the tipsline.

Segger’s Awkward USB-C Issue With The J-Link Compact Debugger

Theoretically USB-C is a pretty nifty connector, but the reality is that it mostly provides many exciting new ways to make your device not work as expected. With the gory details covered by [Alvaro], the latest to join the party is Segger, with its J-Link BASE Compact MCU debugger displaying the same behavior which we saw back when the Raspberry Pi 4 was released in 2019. Back then so-called e-marked USB-C cables failed to power the SBC, much like how this particular J-Link unit refuses to power up when connected using one of those special USB-C cables.

We covered the issue in great detail back then, discussing how the CC1 and CC1 connections need to be wired up correctly with appropriate resistors in order for the USB-C supply – like a host PC – to provide power to the device. As [Alvaro] discovered through some investigation, this unit made basically the same mistake as the RPi 4B SBC before the corrected design. This involves wiring CC1 and CC2 together and as a result seeing the same <1 kOhm resistance on the active CC line, meaning that to the host device you just hooked up a USB-C audio dongle, which obviously shouldn’t be supplied with power.

Although it’s not easy to tell when this particular J-Link device was produced, the PCB notes its revision as v12.1, so presumably it’s not the first rodeo for this general design, and the product page already shows a different label than for the device that [Alvaro] has. It’s possible that it originally was sloppily converted from a previous micro-USB-powered design where CC lines do not exist and things Just Work™, but it’s still a pretty major oversight from what should be a reputable brand selling a device that costs €400 + VAT, rather than a reputable brand selling a <$100 SBC.

For any in the audience who have one of these USB-C-powered debuggers, does yours work with e-marked cables, and what is the revision and/or purchase date?

Worst Clock Ever Teaches You QR Codes

[WhiskeyTangoHotel] wrote in with his newest clock build — and he did warn us that it was minimalist and maybe less than useful. Indeed, it is nothing more than a super-cheap ESP32-C3 breakout board with an OLED screen and some code. Worse, you can’t even tell the time on it without pointing your cell phone at the QR code it generates. Plot twist: you skip the QR code and check the time on your phone.

But then we got to thinking, and there is actually a lot to learn from here on the software side. This thing pulls the time down from an NTP server, formats it into a nice human-readable string using strftime, throws that string into a QR code that’s generated on the fly, and then pushes the bits out to the screen. All in a handful of lines of code.

As always, the secret is in the libraries and how you use them, and we wanted to check out the QR code generator, but we couldn’t find an exact match for QRCodeGenerator.h. Probably the most popular library is the Arduino QRCode library by [ricmoo]. It’s bundled with Arduino, but labelled version 0.0.1, which we find a little bit modest given how widely it’s used. It also hasn’t been updated in eight years: proof that it just works?

That library drew from [nayuki]’s fantastically documented multi-language QR-Code-generator library, which should have you covered on any platform you can imagine, with additional third-party ports to languages you haven’t even heard of. That’s where we’d go for a non-Arduino project.

What library did [WTH] use? We hope to find out soon, but at least we found a couple good candidates, and it appears to be a version of one or the other.

We’ve seen a lot of projects where the hacker generates a QR code using some online tool, packs the bits into a C header array, and displays that. That’s fine when you only need a single static QR code, but absolutely limiting when you want to make something dynamic. You know, like an unreadable clock.

You will not be surprised to know that this isn’t the first unreadable QR-code clock we’ve featured here. But it’s definitely the smallest and most instructive.

Continue reading “Worst Clock Ever Teaches You QR Codes”

Street with polluted smoggy air

Serious Chemical Threat Sniffer On A Budget

Chemical warfare detection was never supposed to be a hobbyist project. Yet here we are: Air Quality Guardian by [debdoot], the self-proclaimed world’s first open source chemical threat detection system, claims to pack lab-grade sensing into an ESP32-based build for less than $100. Compare that with $10,000+ black-box hardware and you see why this is worth trying at home, even if this project might not have the nut cracked just yet.

Unlike your air monitor from IKEA, the device aims to analyze raw gas sensor resistance – ohm-level data most devices throw away – combined with temporal spikes, humidity correlations, and a database of 35+ signatures. Of course, there is a lot of work to be done here on the calibration side, and we don’t have any chemical warfare agents on hand to test against, so we have no idea how well it works, and we’d expect false positives. Still, the idea of taking a more granular look at the data coming off the sensor may bear some fruit.

(Editor’s note: edited with a hefty dash of skeptical salt.)

Featured Image by Arjun Lama on Unsplash

Hosting A Website On A Disposable Vape

For the past years people have been collecting disposable vapes primarily for their lithium-ion batteries, but as these disposable vapes have begun to incorporate more elaborate electronics, these too have become an interesting target for reusability. To prove the point of how capable these electronics have become, [BogdanTheGeek] decided to turn one of these vapes into a webserver, appropriately called the vapeserver.

While tearing apart some of the fancier adult pacifiers, [Bogdan] discovered that a number of them feature Puya MCUs, which is a name that some of our esteemed readers may recognize from ‘cheapest MCU’ articles. The target vape has a Puya PY32F002B MCU, which comes with a Cortex-M0+ core at 24 MHz, 3 kB SRAM and 24 kB of Flash. All of which now counts as ‘disposable’ in 2025, it would appear.

Even with a fairly perky MCU, running a webserver with these specs would seem to be a fool’s errand. Getting around the limited hardware involved using the uIP TCP/IP stack, and using SLIP (Serial Line Internet Protocol), along with semihosting to create a serial device that the OS can use like one would a modem and create a visible IP address with the webserver.

The URL to the vapeserver is contained in the article and on the GitHub project page, but out of respect for not melting it down with an unintended DDoS, it isn’t linked here. You are of course totally free to replicate the effort on a disposable adult pacifier of your choice, or other compatible MCU.

ESP32 Hosts Functional Minecraft Server

If you haven’t heard of Minecraft, well, we hope you enjoyed your rip-van-winkle nap this past decade or so. For everyone else, you probably at least know that this is a multiplayer, open world game, you may have heard that running a Minecraft server is a good job for maxing out a spare a Raspberry Pi. Which is why we’re hugely impressed that [PortalRunner] managed to squeeze an open world onto an ESP32-C3.

Of course, the trick here is that the MCU isn’t actually running the game — it’s running bareiron, [PortalRunner]’s own C-based Minecraft server implementation. Rewriting the server code in C allows it to be optimized for the ESP32’s hardware, but it also let [PortalRunner] strip his server down to the bare essentials, and tweak everything for performance. For example, instead of the multiple octaves of Perlin noise for terrain generation, with every chunk going into RAM, he’s using the x and z of the corners as seeds for the psudorandom rand() function, and interpolating between them. Instead of caves being generated by a separate algorithm, and stored in memory, in bareiron the underground is just a mirror-image of the world above. Biomes are just tiled, and sit separately from one another.

So yes, what you get from bareiron is simpler than a traditional Minecraft world — items are simplified, crafting is simplified, everything is simplified, but it’s also running on an ESP32, so you’ve got to give it a pass. With 200 ms to load each chunk, it’s playable, but the World’s Smallest Minecraft Server is a bit like a dancing bear: it’s not about how well it dances, but that it dances at all.

This isn’t the first time we’ve seen Minecraft’s server code re-written: some masochist did it in COBOL, but at least that ran on an actual computer, not a microcontroller. Speaking of low performance, you can’t play Minecraft on an SNES, but you can hide the game inside a cartridge, which is almost as good.

Thanks to [CodeAsm] for the tip. Please refer any other dancing bears spotted in the wild to our tips line.

Continue reading “ESP32 Hosts Functional Minecraft Server”