We wrote up a video about speeding up Arduino code, specifically by avoiding DigitalWrite. Now, the fact that DigitalWrite is slow as dirt is long known. Indeed, a quick search pulls up a Hackaday article from 2010 demonstrating that it’s fifty times slower than toggling the pin directly using the native pin registers, but this is still one of those facts that gets periodically rediscovered from generation to generation. How can this be new again?

First off, sometimes you just don’t need the speed. When you’re just blinking LEDs on a human timescale, the general-purpose Arduino functions are good enough. I’ve written loads of useful firmware that fits this description. When the timing requirements aren’t tight, slow as dirt can be fast enough.

But eventually you’ll want to build a project where the old slow-speed pin toggling just won’t cut it. Maybe it’s a large LED matrix, or maybe it’s a motor-control application where the loop time really matters. Or maybe it’s driving something like audio or video that just needs more bits per second. One way out is clever coding, maybe falling back to assembly language primitives, but I would claim that the right way is almost always to use the hardware peripherals that the chipmakers gave you.

For instance, in the end of the video linked above, the hacker wants to drive a large shift register string that’s lighting up an LED matrix. That’s exactly what SPI is for, and coming to this realization makes the project work with timing to spare, and in just a few lines of code. That is the way.

Which brings me to the double-edged sword that the Arduino’s abstraction creates. By abstracting away the chips’ hardware peripherals, it makes code more portable and certainly more accessible to beginners, who don’t want to learn about SPI and I2C and I2S and DMA just yet. But by hiding the inner workings of the chips in “user friendly” libraries, it blinds new users to the useful applications of these same hardware peripherals that clever chip-design engineers have poured their sweat and brains into making do just exactly what we need.

This isn’t really meant to be a rant against Arduino, though. Everyone has to start somewhere, and the abstractions are great for getting your feet wet. And because everything’s open source anyway, nothing stops you from digging deeper into the datasheet. You just have to know that you need to. And that’s why we write up videos like this every five years or so, to show the next crop of new hackers that there’s a lot to gain underneath the abstractions.

Some readers may recall building a line-following robot during their school days. Involving some IR LEDs, perhaps a bit of LEGO, and plenty of trial-and-error, it was fun on a tiny scale. Now imagine that—but rideable. That’s exactly what [Austin Blake] did, scaling up a classroom robotics staple into a full-size vehicle you can actually sit on.

The robot uses a whopping 32 IR sensors to follow a black line across a concrete workshop floor, adjusting its path using a steering motor salvaged from a power wheelchair. An Arduino Mega Pro Mini handles the logic, sending PWM signals to a DIY servo. The chassis consists of a modified Crazy Cart, selected for its absurdly tight turning radius. With each prototype iteration, [Blake] improved sensor precision and motor control, turning a bumpy ride into a smooth glide.

The IR sensor array, which on the palm-sized vehicle consisted of just a handful of components, evolved into a PCB-backed bar nearly 0.5 meters wide. Potentiometer tuning was a fiddly affair, but worth it. Crashes? Sure. But the kind that makes you grin like your teenage self. If it looks like fun, you could either build one yourself, or upgrade a similar LEGO project.

Here’s something fun. Our hacker [Willow Cunningham] has sent us a copy of his homework. This is his final project for the “ECE 574: Cluster Computing” course at the University of Maine, Orono.

It was enjoyable going through the process of having a good look at everything in this project. The project is a “cluster” of 5x Raspberry Pi Pico microcontrollers — with one head node as the leader and four compute nodes that work on tasks. The software for the both types of node is written in C. The head node is connected to a workstation via USB 1.1 allowing the system to be controlled with a Python script.

The cluster is configured to process an embarrassingly parallel image convolution. The input image is copied into the head node via USB which then divvies it up and distributes it to n compute nodes via I²C, one node at a time. Results are given for n = {1,2,4} compute nodes.

It turns out that the work of distributing the data dwarfs the compute by three orders of magnitude. The result is that the whole system gets slower the more nodes we add. But we’re not going to hold that against anyone. This was a fascinating investigation and we were impressed by [Willow]’s technical chops. This was a complicated project with diverse hardware and software challenges and he’s done a great job making it all work and in the best scientific tradition.

It was fun reading his journal in which he chronicled his progress and frustrations during the project. His final report in IEEE format was created using LaTeX and Overleaf, at only six pages it is an easy and interesting read.

For anyone interested in cluster tech be sure to check out the 256-core RISC-V megacluster and a RISC-V supercluster for very low cost.

The hack we have for you today is among our most favorite types of hack: a good, honest, simple, and well documented implementation that meets a real need. Our hacker [Solo Pilot] has sent in a link to their basement monitor.

The documentation is quite good. It’s terse but comprehensive with links to related information. It covers the background, requirements, hardware design, sensors, email and SMS alerts, software details, and even has some credits at the end.

Implementing this project would be a good activity for someone who has already made an LED flash and wants to take their skills to the next level by sourcing and assembling the hardware and then configuring, compiling, deploying, and testing the software for this real-world project.

To make this project work you will need to know your way around the Arduino IDE in order to build the software from the src.zip file included with the documentation (hint: extract the files from src.zip into a directory called AHT20_BMP280 before opening AHT20_BMP280.ino and make sure you add necessary boards and libraries).

One feature of the basement monitor that we would like to see is a periodic “everything’s okay” signal from the device, just so we can confirm that the reason we’re not getting an alarm about flooding in the basement is because there is no flood, and not because the battery ran dead or the WiFi went offline.

If you’ve recently started on your journey into where electronics meets software a project such as this one is a really great place to go next. And of course once you are proficient with the ESP8266 there are a thousand such projects here at Hackaday that you can cut your teeth on. Such as this clock and this fault injection device.

A terrarium is a little piece of the living world captured in a small enclosure you can pop on your desk or coffee table at home. If you want to keep it as alive as possible, though, you might like to implement some controls. That’s precisely what [yotitote] did with their smart terrarium build.

At the heart of the build is an ESP32 microcontroller. It’s armed with temperature and humidity sensors to detect the state of the atmosphere within the terrarium itself. However, it’s not just a mere monitor. It’s able to influence conditions by activating an ultrasonic fogger to increase humidity (which slightly impacts temperature in turn). There are also LED strips, which the ESP32 controls in order to try and aid the growth of plants within, and a small OLED screen to keep an eye on the vital signs.

It’s a simple project, but one that serves as a basic starting point that could be readily expanded as needed. It wouldn’t take much to adapt this further, such as by adding heating elements for precise temperature control, or more advanced lighting systems. These could be particularly useful if you intend your terrarium to support, perhaps, reptiles, in addition to tropical plant life.

Indeed, we’ve seen similar work before, using a Raspberry Pi to create a positive environment to keep geckos alive! Meanwhile, if you’re cooking up your own advanced terrarium at home, don’t hesitate to let us know.

Plywood is an interesting material: made up of many layers of thin wood plys, it can be built up into elegantly curved shapes. Do you need to limit it to just wood, though? [Zach of All Trades] has proved you do not, when he embedded a light guide, LEDs, microcontrollers and touch sensors into a quarter inch (about six millimeter) plywood layup in the video embedded below.

He’s using custom flexible PCBs, each hosting upto 3 LEDs and the low-cost PY32 microcontroller. The PY32 drives the RGB LEDs and handles capacitive touch sensing within the layup. In the video, he goes through his failed prototypes and what he learned: use epoxy, not wood glue, and while clear PET might be nice and bendy, acrylic is going to hold together better and cuts easier with a CO2 laser.

The wood was sourced from a couple of sources, but the easiest was apparently skateboard kits– skateboards are plywood, and there’s a market of people who DIY their decks. The vacuum bag setup [Zach] used looks like an essential tool to hold together the layers of wood and plastic as the epoxy cures. To make the bends work [Zach] needed a combination of soaking and steaming the maple, before putting it into a two-part 3D printed mold. The same mold bends the acrylic, which is pre-heated in an oven.

Ultimately it didn’t quite come together, but after some epoxy pour touch-up he’s left with a fun and decorative headphone stand. [Zach] has other projects in mind with this technique, and its got our brains percolating as well. Imagine incorporating strain gauges to drive the LEDs so you could see loading in real time, or a sound-reactive speaker housing. The sky’s the limit now that the technique is out there, and we look forward to see what people make of it.

The last time we heard from [Zach of All Trades] he was comparing ten cent micro-controllers; it looks like the PY32 came out on top. Oddly enough, this seems to be the first hack we have featuring it. If you’ve done something neat with ten cent micros (or more expensive ones) or know someone who did, don’t forget to let us know! We love tips. [Zach] sent in the tip about this video, and his reward is gratitude worth its weight in gold.

As the saying goes, modern problems require modern solutions. When the modern problem is that your smart light is being hijacked by the neighbors, [Wjen]’s modern solution is to reverse engineer and replace the mainboard.

The light in question is a Phillips Hue Ambiance, and [Wjen]’s excellently-documented six part series takes us through the process of creating a replacement light driver. It’s a good read, including reverse-engineering the PWM functions to get the lights to dim exactly like stock, and a dive into the Zigbee protocol so his rebuild light could still talk to the Philips Hue hub. The firmware [Wjen] wrote for the ESP32C6 he chose to use for this project is on GitHub, with the PCB in a second repo.

We want to applaud [Wjen] for his excellent documentation and open-sourcing (the firmware and PCB are under GPL v3). Not only do we get enough information to replicate this project perfectly if we so choose, but by writing out his design process, [Wjen] gives everyone reading a good head start in doing something similar with other hardware. Even if you’re scratching your head wondering why a light switch isn’t good enough anymore, you have to appreciate what [Wjen] is offering the community.

We’ve covered domestic brain transplants in the past — which is easier in this sort of light than the close confines of a smart bulb. If you’re still wondering why not just use a light switch, perhaps you’d rather hack the light to run doom instead.

Before you go, can we just take a moment to appreciate how bizarre the world has become that we have a DOOM-capable computer to run fancy light fixture? If you’re using what might have been a decent workstation in days of yore to perform a painfully mundane task, let us know on the tips line.

The RP2350 has a few advantages over its predecessor, one of which is the ability to load firmware remotely via UART, as [Thomas Pfilser] has documented on his blog and in the video below.

[Thomas] had a project that needed more PWM than the RP2350 could provide, and hit upon the idea of using a second RP2350 as a port expander. Now, one could hard-code this, but dealing with two sets of firmware on one board can be annoying. That’s where the UART bootloader comes in: it will allow [Thomas] to program the port-expander RP2350 using the main microcontroller. Thus he only has to worry about one firmware, speeding up development.

There are limits to this technique: for one, your code must fit into the RP2350’s RAM– but the chip has 512 kB. While 640 kB should be enough for anyone, 512 kB is plenty for the port-expander [Thomas] is working on. The second drawback is that your device now has a boot time of a second or so, since the UART connection is not exactly high-bandwidth. Third, using UART on the same pins as the bootloader within the program is a bit tricky, though [Thomas] found a solution that may soon be in the SDK.

[Thomas] also wanted to be able to perform this trick remotely, which isn’t exactly UART’s forte. RS-485 comes to the rescue, via TI’s THVD1450. That worked reliably at the 10m cable length used for the test. [Thomas] sees no reason it could not work over much longer distances. ([Thomas] suggests up to 100 m, but the baud rate is fairly low, so we wouldn’t be surprised if you could push it quite a bit further than that. The standard is good out to a kilometer, after all.) For all the wrinkles and links to tips and solutions, plus of course [Thomas]’s code, check out the blog. If you want to listen to the information, you can check out the video below.

We’re grateful to [Thomas] for letting us know about his project via the tip line, like we are to everyone who drops us a tip. Hint, hint.

Given that it is the new chip on the block, we haven’t seen too many hacks with the RP2350 yet, but they’re starting to trickle in. While a UART bootloader is a nice feature to have, it can also introduce a security risk, which is always something to keep in mind.

Today we are happy to present a web-based GUI for making a web-based GUI! If you’re a programmer then web front-end development might not be your bag. But a web-based graphical user interface (GUI) for administration and reporting for your microcontroller device can look very professional and be super useful. The Mongoose Wizard can help you develop a device dashboard for your ESP32-based project.

In this article (and associated video) the Mongoose developers run you through how to get started with their technology. They help you get your development environment set up, create your dashboard layout, add a dashboard page, add a device settings page, add an over-the-air (OTA) firmware update page, build and test the firmware, and attach the user-interface controls to the hardware. The generated firmware includes an embedded web server for serving your dashboard and delivering its REST interface, pretty handy.

You will find no end of ESP32-based projects here at Hackaday which you could potentially integrate with Mongoose. We think the OTA support is an excellent feature to have, but of course there are other ways of supporting that functionality.

Thanks to [Toly] for this tip.

Morse code can be daunting to learn when you’re new to the game, particularly if you need it to pass your desired radio license. However, these days, there are a great many tools to aid in the learning process. A good example is the Morse Master from [Arnov Sharma].

The Morse Master is a translator for Morse code, which works in two ways. You can access it via a web app, and type in regular letters which it then flashes out as code on its in-built LEDs. Alternatively, you can enter Morse manually using the physical key, and the results will be displayed on the web app. The Morse key itself is built into the enclosure using 3D printed components paired with a Cherry-style keyboard switch. It’s perhaps not the ideal solution for fast keying, with its limited rebound, but it’s a quick and easy way to make a functional key for practice purposes. If you want to go faster, though, you might want to upgrade to something more capable. We’d also love to see a buzzer added, since Morse is very much intended as an auditory method of communication.

We’ve seen some other great Morse code trainers before, too. If you’ve trained yourself in this method of communication, don’t hesitate to share your own learning tips below.

Recently [Glen Akins] reported on Bluesky that the Zigbee-based sensor he had made for his garden’s rear gate was still going strong after a Summer and Winter on the original 2450 lithium coin cell. The construction plans and design for the unit are detailed in a blog post. At the core is the MS88SF2 SoM by Minew, which features a Nordic Semiconductor nRF52840 SoC that provides the Zigbee RF feature as well as the usual MCU shenanigans.

Previously [Glen] had created a similar system that featured buttons to turn the garden lights on or off, as nobody likes stumbling blindly through a dark garden after returning home. Rather than having to fumble around for a button, the system should detect when said rear gate is opened. This would send a notification to [Glen]’s phone as well as activate the garden lights if it’s dark outside.

Although using a reed relay switch seemed like an obvious solution to replace the buttons, holding it closed turned out to require too much power. After looking at a few commercial examples, he settled for a Hall effect sensor solution with the Ti DRV5032FB in a TO-92 package.

Whereas the average person would just have put in a PIR sensor-based solution, this Zigbee solution does come with a lot more smart home creds, and does not require fumbling around with a smartphone or yelling at a voice assistant to turn the garden lights on.

A quadrature encoder provides a way to let hardware read movement (and direction) of a shaft, and they can be simple, effective, and inexpensive devices. But [Paulo Marques] observed that when it comes to reading motor speeds with them, what works best at high speeds doesn’t work at low speeds, and vice versa. His solution? PicoEncoder is a library providing a lightweight and robust method of using the Programmable I/O (PIO) hardware on the RP2040 to get better results, even (or especially) from cheap encoders, and do it efficiently.

The output of a quadrature encoder is typically two square waves that are out of phase with one another. This data says whether a shaft is moving, and in what direction. When used to measure something like a motor shaft, one can also estimate rotation speed. Count how many steps come from the encoder over a period of time, and use that as the basis to calculate something like revolutions per minute.

[Paulo] points out that one issue with this basic method is that the quality depends a lot on how much data one has to work with. But the slower a motor turns, the less data one gets. To work around this, one can use a different calculation optimized for low speeds, but there’s really no single solution that handles high and low speeds well.

Another issue is that readings at the “edges” of step transitions can have a lot of noise. This can be ignored and assumed to average out, but it’s a source of inaccuracy that gets worse at slower speeds. Finally, while an ideal encoder has individual phases that are exactly 50% duty cycle and exactly 90 degrees out of phase with one another. This is almost never actually the case with cheaper encoders. Again, a source of inaccuracy.

[Paulo]’s solution was to roll his own method with the RP2040’s PIO, using a hybrid approach to effect a “sub-step” quadrature encoder. Compared to simple step counting, PicoEncoder more carefully tracks transitions to avoid problems with noise, and even accounts for phase size differences present in a particular encoder. The result is a much more accurate calculation of motor speed and position without any delays. Most of the work is done by the PIO of the RP2040, which does the low-level work of counting steps and tracking transitions without any CPU time involved. Try it out the next time you need to read a quadrature encoder for a motor!

The PIO is one of the more interesting pieces of functionality in the RP2040 and it’s great to see it used in a such a clever way. As our own Elliot Williams put it when he evaluated the RP2040, the PIO promises never having to bit-bang a solution again.

The Star Trek tricorder was a good example of a McGuffin. It did anything needed to support the plot or, in some cases, couldn’t do things also in support of the plot. We know [SirGalaxy] was thinking about the tricorder when he named the Tinycorder, but the little device has a number of well-defined features. You can see a brief video of it working below the break.

The portable device has a tiny ESP32 and a battery. The 400×240 display is handy, but has low power consumption. In addition to the sensors built into the ESP32, the Tinycorder has an AS7341 light sensor, an air quality sensor, and a weather sensor. An odd combination, but like its namesake, it can do lots of unrelated things.

The whole thing goes together in a two-part printed case. This is one of those projects where you might not want an exact copy, but you very well might use it as a base to build your own firmware. Even [SirGalaxy] has plans for future developments, such as adding a buzzer and a battery indicator.

This physically reminded us of those ubiquitous component testers. That another multi-purpose tester that started simple and gets more features through software.