[Nick] does a lot of custom work with vacuum tubes. So much so that he builds his own vacuum tubes of various shapes, sizes, and functions right on his own workbench. While the theory of vacuum tubes is pretty straightforward, at least to those of us who haven’t only been exposed to semiconductors, producing them requires some specialized equipment. A simple vacuum won’t get you all the way there, and the complexity of the setup that’s needed certainly calls for some automation.

The vacuum system that [Nick] uses involves three sections separated by high-vacuum valves in order to achieve the pressures required for vacuum tube construction. There’s a rough vacuum section driven by one pump, a high vacuum section driven by a second pump, and a third section called the evac port where the tube is connected. Each second must be prepared properly before the next section can be engaged or disengaged. An Arduino Pro is tasked with all of this, chosen for its large amount of ADC inputs for the instrumentation monitoring the pressures in each section, as well as the digital I/O to control the valves and switches on the system.

The control system is built into a 19-inch equipment rack with custom faceplates which outline the operation of the vacuum system. A set of addressable LEDs provide the status of the various parts of the system, and mechanical keyboard switches are used to control everything, including one which functions as an emergency stop. The automation provided by the Arduino reduces the chances for any mistakes to be caused by human error, allows the human operator to focus on other tasks like forming the glass, and can also react much faster to any potentially damaging situations such as the high-pressure pump being exposed to atmospheric pressure.

[Nick] might look a little familiar to some of us as well. If you can’t quite place him, he did a talk at Hackaday Supercon 2022 detailing all of the intricacies of building one’s own vacuum tubes. Since getting into the somewhat niche field of constructing vacuum tubes, he’s gone on to produce all kinds of specialty devices and his YouTube channel is definitely worth a watch.

Thanks to [M] for the tip!

You might think that making your own electronic games would require some kind of LCD, but lately, [Mirko Pavleski] has been making his using inexpensive 8X8 WS2812B LED panels. This lets even a modest microcontroller easily control a 64-pixel “screen.” In this case, [Mirko] uses an Arduino Nano, 3 switches, and a buzzer along with some 3D printed components to make a good-looking game. You can see it in action in the video below.

The WS2812B panels are easy to use since the devices have a simple protocol where you only talk to the first LED. You send pulses to determine each LED’s color. The first LED changes color and then starts repeating what you send to the next LED, which, of course, does the same thing. When you pause a bit, the array decides you are done, and the next train of pulses will start back at the first LED.

It looks like the project is based on a German project from [Bernd Albrecht], but our German isn’t up to snuff, and machine translation always leaves something to be desired. Another developer added a play against the computer mode. This is a simple program and would be easy to port to the microcontroller of your choice. [Mirko]’s execution of it looks like it could be a commercial product. If you made one as a gift, we bet no one would guess you built it yourself.

Of course, you could play a real robot. You could probably repurpose this hardware for many different games, too.

Dash cameras are handy as they provide a video recording of interactions on the road. However, their utility comes from the fact that they are always recording while driving. This always-on means power draw. [Kuzysk] took it upon himself to cut that power draw by a factor of almost 70x.

He found his existing dash cam from MiVue consumed 3.5mA in idle which works out to be a whole amp-hour every 12 days. The custom version takes just 50uA which means it will draw an amp-hour in two years. The brains of the chip are formed by an ATmega328 and an LM2596M, which is a simple step-down regulator. Interestingly, [Kuzysk] purchased clones and original chips and found that the cheaper clones had a lower switching frequency but a much lower power draw. Programming an Arduino bootloader onto the board is fairly straightforward and [Kuzysk] kindly provides his code. It can detect the ACC voltage that’s on when the engine is on and is powered by a permanent 12v connection to the battery.

Overall it’s a straightforward hack that goes through rolling your own Arduino, optimizing for low power, and putting it all together into a polished project. Perhaps for the next version, he can use the ATmega to control a cheaper camera and make it smart.

Thanks to [Microchip makes] and [Abe] for the tip!

[Emily Velasco] has an internet provider that provides sub-par connectivity. Instead of repeatedly refreshing a browser tab to test if the network is up, [Emily] decided to create an internet status monitor by embedding indicator lights in a cat skull…for some reason.

The electronics are straightforward, with the complete parts list consisting of an Arduino Nano 33 IoT device connected to a pair of RGB LEDs and 50 Ohm resistors. The Nano attempts to connect to a known site (in this case, the Google landing page) every two seconds and sets the LEDs to green if it succeeds or red if it fails.

The cat skull is thankfully a replica, 3D printed by one of [Emily]’s Twitter acquaintances, and the whole project was housed in a domed security camera enclosure. [Emily] mounts the LEDs into the skull to create a “brain in a jar” effect.

The source is available on GitHub for those wanting to take a look. We’ve featured internet connectivity status indicators in the form of traffic lights here before, as well as various network status monitors and videoconferencing indicator lights.

When you want a backpack that turns heads and gets people talking, you can get ahead of the conversation with a talking backpack. [Nina] created a rucksack with the legendary babbler itself, the infamous Furby.

Believe it or not, no actual Furbies were sacrificed in the making of this backpack. The build uses an Arduino Nano, two servos, and a DFPlayer Mini for audio. A 3D printed faceplate is used for the iconic eyes and face. The code is fairly simple, waiting for a random delay and then triggering one of four effects. It can play a sound or blink and does its best to move the mouth while the sound is playing thanks to the handy busy line coming off the sound module. A unicorn children’s backpack offered a furry shell to stuff the electronics inside. A custom PCB makes the whole thing just a little neater internally.

Perhaps next [Nina] can integrate voice recognition so that the backpack can answer simple questions like an Alexa-powered Furby we’ve seen before.

While it can be straightforward to distill water to high purity, this is rarely the best method for producing water for useful purposes. Even drinking water typically needs certain minerals in it, plants may need a certain pH, and wastewater systems have a whole host of other qualities that need to be measured. Measuring water quality is a surprisingly complex endeavor as a result and often involves a wide array of sensors, much like this water quality meter from [RowlesGroupResearch].

The water quality meters that they are putting to use are typically set up in remote locations, without power, and are targeting natural bodies of water and also wastewater treatment plants. Temperature and pH are simple enough to measure and grasp, but this device also includes sensors for total dissolved solids (TDS) and turbidity which are both methods for measuring various amounts and types of particles suspended in the water. The build is based around an Arduino so that it is easy for others to replicate, and is housed in a waterproof box with a large battery, and includes data logging to an SD card in order to make it easy to deploy in remote, outdoor settings and to gather the data at a later time.

The build log for this device also goes into detail about all of the steps needed to set this up from scratch, as well as a comprehensive bill of materials. This could be useful in plenty of professional settings such as community wastewater treatment facilities but also in situations where it’s believed that industrial activity may be impacting a natural body of water. For a water quality meter more focused on drinking water, though, we’d recommend this build that is trained on its own neural network.

Integrated circuits, chipsets, memory modules, and all kinds of other transistor-based technology continues to get smaller, cheaper, and more energy efficient as time moves on. Not only are the components themselves smaller, but their supporting infrastructure is as well. Computers like the Raspberry Pi are about the size of a credit card and have computing power on the order of full-sized PCs from a few decades ago. The Arduino is no exception to this trend, either, and this new dev board called the Epi 32U4 might be the smallest ATmega platform we’ve seen so far.

As the name suggests, the board is based around the ATmega32U4 which is somewhat unique among Atmel chips in that it includes support for USB within the chip itself rather than relying on external translating circuitry. This makes it an excellent choice for any project which involves sending keyboard, mouse, or other peripheral information to a computer. This goes a few steps further with eliminating “bloat” compared to other boards, too. There’s no on-board voltage regulator, no LEDs except for a single one on pin 13, and even the pins and screw terminals are hemispherical rather than through-hole to save space.

One of the other features this board boasts over other small form factor boards is on-board USB-C, which is definitely a perk as more and more devices switch away from the various forms of older USB-type plugs. The project’s specifications are also available on this GitHub page for anyone that wants to produce their own. And, if you don’t have a 32U4 on hand and still want to build a keyboard project, it’s possible to get some other Arduinos to support these features but it’ll take a little more work.

Thanks to [Rasmus L] for the tip!

Jenny did an Ask Hackaday article earlier this month, all about the quest for a cheap computer-based audio mixer. The first attempt didn’t go so well, with a problem that many of us are familiar with: Linux applications really doesn’t like using multiple audio devices at the same time. Jenny ran into this issue, and didn’t come across a way to merge the soundcards in a single application.

I’ve fought this problem for a while, probably 10 years now. My first collision with this was an attempt to record a piano with three mics, using a couple different USB pre-amps. And of course, just like Jenny, I was quickly frustrated by the problem that my recording software would only see one interface at a time. The easy solution is to buy an interface with more channels. The Tascam US-4x4HR is a great four channel input/output audio interface, and the Behringer U-PHORIA line goes all the way up to eight mic pre-amps, expandable to 16 with a second DAC that can send audio over ADAT. But those are semi-pro interfaces, with price tags to match.

But what about Jenny’s idea, of cobbling multiple super cheap interfaces together? Well yes, that’s possible too. I’ll show you how, but first, let’s talk about how we’re going to control this software mixer monster. Yes, you can just use a mouse or keyboard, but the challenge was to build a mixing desk, and to me, that means physical faders and mute buttons. Now, there are pre-built solutions, with the Behringer X-touch being a popular solution. But again, we’re way above the price-point Jenny set for this problem. So, let’s do what we do best here at Hackaday, and build our own.

The Physical Goods

What we need is a microcontroller that has native USB client support, multiple digital I/O pins, and some analog inputs. I went with the Arduino MKRZero for the small size, decent price, and the fact that it’s actually in stock at Mouser. The other items we’ll need are some faders and buttons. I went for the full-sized 100 mm faders, and some LED toggle buttons made by Adafruit. The incidentals, like wire and resistors, was sourced from the local parts bin in the corner.

My first thought was to design and 3D print the panel, but after doing the layout on a scrap piece of plywood, the resulting size proved a bit too large for my printer. So we’re going retro, and making a “wood-grain” mixing desk. This would be a great project for a CNC router, but as I’m not part of that particular cool club yet, it was a drill press, table saw, and oscillating tool to the rescue. The results aren’t quite as pretty as I wanted, but maybe we’ll get a Mark II of this project one day.

The wiring is relatively straightforward, with a current limiting resistor to protect the LEDs inside the buttons, and a pullup resistor to prevent the digital pin from floating when the button isn’t pushed. Now, that pullup might not be necessary, as I later learned that the Arduino has built-in pullup on its digital pins. And also of note, a 10 Ω resistor is *not* a good choice for a pullup. As Al eloquently put it, that’s a “pull way up resistor”. 10 kΩ is the better choice.

And to finish the build, we’ll need a sketch to run on the Arduino. Thankfully, there’s already a great library for exactly what we want to do: Control Surface. There’s a bunch of ways to set this up, but my sketch is pretty trivial:

#include <Control_Surface.h>
USBMIDI_Interface midi;

CCButtonLatching button1 {11, {MIDI_CC::General_Purpose_Controller_1, CHANNEL_1}, };
CCButtonLatching button2 {10, {MIDI_CC::General_Purpose_Controller_2, CHANNEL_1}, };
CCButtonLatching button3 {9, {MIDI_CC::General_Purpose_Controller_3, CHANNEL_1}, };
CCButtonLatching button4 {8, {MIDI_CC::General_Purpose_Controller_4, CHANNEL_1}, };
CCButtonLatching button5 {7, {MIDI_CC::General_Purpose_Controller_5, CHANNEL_1}, };
CCButtonLatching button6 {6, {MIDI_CC::General_Purpose_Controller_6, CHANNEL_1}, };
  
CCPotentiometer volumePotentiometers[] {
  {A0, {MIDI_CC::Sound_Controller_1, CHANNEL_1} },
  {A1, {MIDI_CC::Sound_Controller_2, CHANNEL_1} },
  {A2, {MIDI_CC::Sound_Controller_3, CHANNEL_1} },
  {A3, {MIDI_CC::Sound_Controller_4, CHANNEL_1} },
  {A4, {MIDI_CC::Sound_Controller_5, CHANNEL_1} },
  {A5, {MIDI_CC::Sound_Controller_6, CHANNEL_1} },
};
void setup() {
    Control_Surface.begin();
}
void loop() {
    Control_Surface.loop();
}

Pipewire to the Rescue

And now on to the meat and potatoes of this project. How do we convince an application to see inputs from multiple devices, and actually do some mixing? The problem here is de-sync. Each device runs on a different clock source, and so the bitstream from each may wander and go out of sync. That’s a serious enough problem that older sound solutions didn’t implement much in the way of card combining. Not long ago, the process of resampling those audio streams to get them to properly sync would have been a very CPU intensive procedure. But these days we all have multi-core behemoths, practical super-computers compared to 20 years ago.

So when Wim Taymans wrote Pipewire, he took a different approach. We have enough cycles to resample, so Pipewire will transparently do so when needed. Pipewire sees all your audio interfaces at once, and implements both the Jack and Pulseaudio APIs. Different distros handle this a bit differently, but generally you need the Pipewire packages, as well as the pipewire-jack and pipewire-pulseaudio packages to get that working.

And here’s the secret: The Jack routing tools work with Pipewire. The big three options are qjackctl, carla, and qpwgraph, though note that qpwgraph is actually Pipewire native. So even if an application can only select a single device at a time, if that app uses the Jack, Pulseaudio, or Pipewire API, you can use one of those routing control programs to arbitrary connect inputs and outputs.

So let’s start with the simplest solution: jack_mixer. Launch the application, and then using your preferred routing controllers, take the MIDI output from our Arduino control surface, and connect it into jack_mixer‘s MIDI input. In jack_mixer, add a new input channel, and give it an appropriate name. Let’s call it “tape deck”, since I have a USB tape deck I’m testing this with. Now the controller magic kicks in: hit the “learn” button for the volume control, and wiggle the first fader on that controller. Then follow with the mute button, and save the new channel. We’ll want to add an output channel, too. Feel free to assign one of your faders to this one, too.

And finally, back to the routing program, and connect your tape deck’s output to jack_mixer input, and route jack_mixer‘s output to your speakers. Play a tape, and enjoy the full control you have over volume and muting! Want to add a Youtube video to the mix? Start the video playing, and just use the routing controller to disconnect it from your speakers, and feed it into a second channel on jack_mixer. Repeat with each of those five cheap and nasty sound cards. Profit!

You Want More?

There’s one more application to mention here. Instead of using jack_mixer, we can use Ardour to do the heavy lifting. To set it up this way, there are two primary Ardour settings, found under preferences: Under the monitoring tab make sure “Record monitoring handled by” is set to Ardour, and the “auto Input does talkback” option is checked. Then add your tracks, set the track input to the appropriate input hardware, and the track output to the master bus. Make sure the master bus is routed to where you want it, and you should be able to live mix with Ardour, too.

This gives you all sorts of goodies to play with, in the form of plugins. Want a compressor or EQ on a sound source? No problem. Want to autotune a source? X42 has a plugin that does that. And of course, Ardour brings recording, looping, and all sorts of other options to the party.

Ardour supports our custom mixing interface, too. Also under preferences, look for the Control Surfaces tab, and make sure General MIDI is checked. Then highlight that and click the “Show Protocol Settings” button. Incoming MIDI should be set to our Arduino device. You can then use the Ctrl + Middle Click shortcut on the channel faders and mute buttons, to put them in learn mode. Wiggle a control to assign it to that task. Or alternatively you can add a .map file to Ardour’s midi_maps directory. Mine looks like this:

 
  <?xml version="1.0" encoding="UTF-8"?>
<ArdourMIDIBindings version="1.1.0" name="Arduino Mapping">
  <Binding channel="1" ctl="16" uri="/route/mute B1"/>
  <Binding channel="1" ctl="70" uri="/route/gain B1"/>
  <Binding channel="1" ctl="17" uri="/route/mute B2"/>
  <Binding channel="1" ctl="71" uri="/route/gain B2"/>
  <Binding channel="1" ctl="18" uri="/route/mute B3"/>
  <Binding channel="1" ctl="72" uri="/route/gain B3"/>
  <Binding channel="1" ctl="19" uri="/route/mute B4"/>
  <Binding channel="1" ctl="73" uri="/route/gain B4"/>
  <Binding channel="1" ctl="80" uri="/route/mute B5"/>
  <Binding channel="1" ctl="74" uri="/route/gain B5"/>
  <Binding channel="1" ctl="81" uri="/route/mute B6"/>
  <Binding channel="1" ctl="75" uri="/route/gain B6"/>
</ArdourMIDIBindings>

The Caveats

Now before you get too excited, and go sink a bunch of money and/or time into a Linux audio setup, there are some things you should know. First is latency. It’s really challenging to get a Pipewire system set up to achieve really low latency, particularly when you’re using USB-based hardware. It’s possible, and work is ongoing on the topic. But so far the best I’ve managed to run stable is a 22 millisecond round-trip measurement — and that took a lot of fiddling with the Pipewire config files to avoid garbled audio. That’s just about usable for self monitoring and live music, and for playing anything pre-recorded, that’s perfectly fine.

The second thing to know is that this was awesome. It’s a bit concerning how much fun it is to combine some decent audio hardware with the amazing free tools that are available. Want to auto-tune your voice for your next Zoom meeting? Easy. Build a tiny MIDI keyboard into your desk? Just a microcontroller and some soldering away. The sky’s the limit. And the future is bright, too. Tools like Pipewire and Ardour are under very active development, and the realtime kernel patches are just about to make it over the finish line. Go nuts, create cool stuff, and then be sure to tell us about it!

Camera shutter speed is an essential adjustment in photography – along with the aperture, the shutter moderates the amount of light entering the camera. Older cameras (and some newer ones) use mechanical shutters that creep out-of-spec over the years, so [Dean Segovis] built a handy shutter speed tester.

With just a handful of basic components, this project is a great one for beginners to sink their teeth into. The tester is based around a photoresistor that measures light from another source (a flashlight) that travels through the camera body. When the shutter on the camera is released, the shutter speed can be measured and displayed on the OLED screen. An Arduino naturally handles all the computational duties. The whole thing can be easily assembled on a breadboard in just a couple of minutes.

The original project by [hiroshootsfilm] is over on Project Hub, however [Dean] takes a deeper dive with some code troubleshooting, as well as trying out a variety of old film cameras with the breadboard tester. His testing revealed that the photoresistor was better able to detect shutter speed when the camera lens was removed, which is a hot tip for anyone else that wants to try this.

While it’s not surprising that these older cameras are having trouble with their mechanical shutters, this little tester would be an invaluable tool when it comes time to start tweaking shutter mechanisms. The full video is after the break and more details are scribbled down here, but make sure to check out the follow-up video where [Dean] prints a neat enclosure for the electronics.

If this project has brought out the shutterbug in you, make sure to check out this brain transplant for a Polaroid 100-series Packfilm camera that we covered way back in 2011.

If you are running video around your home theater, you probably use HDMI. If you are running it in a professional studio, however, you are probably using SDI, Serial Digital Interface. [Chris Brown] looks at SDI and shows a cheap SDI signal generator for an Arduino.

On the face of it, SDI isn’t that hard. In fact, [Chris] calls it “dead simple.” The problem is the bit rate which can be as high as 1.485 Gbps for the HD-SDI standard. Even for a super fast processor, this is a bit much, so [Chris] turned to the Arduino MKR Vidor 4000. Why? Because it has an FPGA onboard. Alas, the FPGA can’t do more than about 200 MHz, but that’s fast enough to drive an external Semtech GS296t2 serializer which is made to drive SDI signals.

The resulting project contains the Arduino, the serializer, a custom PCB, and both FPGA and microcontroller code. While the total cost of the project was a little under $200, that’s still better than the $350 to $2000 for a commercial SDI signal generator.

If you want to play along, the files are out on GitHub. We used the Vidor back in 2018 when it first came out. If you need a quick start on FPGAs, there’s always our boot camp.