Computers and digital sensors have allowed for the collection and aggregation of data barely possible to imagine to anyone in the instrumentation scene even sixty years ago. Before that, things like weather stations, seismometers, level sensors, and basically any other way of gathering real data about the world would have been performed with an analog device recording the information on some sort of spool of paper. This was much more tedious but the one thing going for these types of devices was their aesthetic. [mircemk] is back to bring some of that design inspiration to a digital barometric display.

The barometer is based around an Arduino Arduino Nano and a relatively large I2C display to display the captured data. It also uses a BME 280 pressure sensor board, but the technical details of this project are not the focal point here. Instead, [mircemk] has put his effort in recreating the old analog barographs, which display barometric data on a spool of paper over time, on the I2C display. As the device measures atmospheric pressure, it adds a bar to the graph, displaying the data over time much as the old analog device would have.

We’ve discussed plenty of times around here that old analog meters and instrumentation like this recreation of a VU meter are an excellent way of getting a more antique aesthetic than is typically offered by digital replacements. Adding in a little bit of style to a project like this can go a long way, or you can simply restore the original antique instead.

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!

We’re not sure if there’s any single characteristic that qualifies someone as a hacker. After all, we’re a pretty eclectic bunch, with skills that range all over the map, and what one person feels is trivial, others would look upon as black magic. But there’s one thing we’re sure of: if you find yourself reading the original POST code for the PC-XT motherboard just to get a keyboard working, you’re pretty much our kind of people.

That was the position [Anders Nielsen] found himself in as work progresses on his “PC-XT from Scratch” project, which seeks to build a working mid-80s vintage IBM Model 5160 using as many period-correct parts as possible. The first installment of the series featured the delicate process of bringing the motherboard up, lest the magic smoke was released. After seeing some life out of the old board, [Anders] needed a little IO, specifically video and keyboard. The video side of the equation was relatively trivial, with an early-90s VGA card from eBay — not exactly period correct, but good enough to get something to display.

The keyboard was another matter entirely. It’s not too much of a chore to find a keyboard that’ll talk to a PC-AT, but the PC-XT had an entirely different protocol, not to mention that chunky 5-pin DIN connector. As with many things, the solution involved building an adapter out of an Arduino, but the process was not exactly low-friction. First, there was the question of dealing with the open-collector outputs on the keyboard, which required code changes. Next, [Anders] broke out the oscilloscope to check waveforms, and found a weird 9-Hz square wave on top of the keyboard clock signal. That ended up being a sign that the keyboard was stuck in a manufacturing test mode, according to a read-through of the power on self-test (POST) source code. A tiny tweak of the Arduino code got everything working.

We’ve got to say that we’re loving this deep dive into the internals of a piece of computer history. [Anders] teased the next step, which will use an empty ROM socket on an old network card to load some assembly code onto the XT. We’re very much looking forward to that exploit.

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.

The mechanical keyboard community is a vibrant, if not fanatical, group of enthusiasts determined to find as many possible ways of assembling, building, and using as many high-quality keyboards as possible. With so many dedicated participants, most things that can be done with a keyboard already have been done. So when something as unique as this split keyboard that also doubles as a mouse pops up, we take notice.

The keyboard is a custom build from [Taliyah Huang] which uses a pair of Arduinos, one in each half of the keyboard, to communicate key and mouse information to a third Arduino which is plugged in to her laptop. The right-hand half of the keyboard also includes the circuitry from an optical mouse, which gets powered up when the caps lock button is held down. When activated, this allows the keyboard to be used as a mouse directly. It also includes support for most Mac gestures as well, making it just as useful as a trackpad.

While there were some problems with the design, including being slightly too tall to be ergonomic and taking nearly 24 hours of soldering to complete, the prototype device is an interesting one especially since it allows for full control of a computer without needing a dedicated mouse. For other unique mechanical keyboard concepts, we recently featured this build which takes design and functionality cues from the Commodore 64.

That big grandfather clock in the library might be an impressive piece of mechanical ingenuity, and an even better example of fine cabinetry, but we’d expect that the accuracy of a pendulum timepiece would be limited to a sizable fraction of a minute per day. Unless, of course, you work at CERN and built  “the most accurate pendulum clock on the planet.”

While we’re in no position to judge [Daniel Valuch]’s claim, we’re certainly inclined to believe him, mainly because the 1950s-era Czechoslovakian pendulum clock his project was based on, the Elektročas HH3, was built specifically as a master clock for labs, power plants, and broadcast use. The pendulum of this mid-century beauty is made of the alloy invar, selected for its exceptionally low coefficient of thermal expansion. This ensures the pendulum doesn’t change length with temperature, but it still only brings the clock into the 0.1 second/day range.

Clearly that’s not good enough for a clock at CERN, the European Laboratory for Nuclear Research, where [Daniel] works as an RF engineer. With access to a 10-MHz timebase from a cesium fountain atomic clock — no less a clock than the one that’s used to define the SI second, by the way — [Daniel] looked for ways to sync the clock up to it. Now, we know what you’re thinking — he must have used some kind of PLL to give an electromagnetic “kick” to the bob to trim the pendulum’s period. Good guess on the PLL, but the trimming method is a little cruder — [Daniel] uses a stepper motor attached to the clock’s frame to pay out or retract a length of fine chain into a cardboard dish attached to the pendulum’s rod. The change in mass changes the pendulum’s center of gravity, which changes its effective length, and allows the clock to be tuned a couple of seconds per day.

It seems like [Daniel] is claiming that his chain-corrected clock won’t drift more than a second from the cesium clock for 158 million years. Again, we’ll take his word for it, but it’s a wonderfully ad hoc approach to tuning the clock, and we appreciate its simplicity.

It looks like an ordinary toolbox, but when you open up the Arduino Launch Control System, you’ll find a safe method for triggering model rocket launches. The system uses two separate power supplies. Both must be on for a successful launch and one requires a key. To trigger a 10-second countdown, the operator must hold down two buttons. Releasing either button will stop the countdown.

Besides safety, the controller tracks mission elapsed time and can read weather information from a few sensors. A good-looking build and we like the idea of building inside a toolbox for this sort of thing.

Towards the end of the post, there are some ideas for improving the build, like using a consolidated weather sensor, using a larger screen, and a bigger, more capable controller. It seems like more I/O would be useful,

Model rocketry isn’t as rigorous as launching a crew, but there were a few things that could improve the overall system safety. For example, the launch buttons could provide both normally open and normally closed contacts to guard against switch failure. In other words, if you see both inputs from one switch on or off for more than a tiny moment during switching, you can assume the switch has failed and put the system in a fail-safe mode. Of course, a switch failure in the off position isn’t a hazard, just an inconvenience. But a switch failure in the active position could allow an inadvertent launch. Granted, it would require something jamming the remaining switch for the entire 10-second countdown, but still. Arduinos are pretty reliable, but for a real rocket system, you’d probably have redundancy, and the software would do periodic checks to guard against things like memory corruption.  For example, NASA has a relatively succinct list of requirements. But some of this is overkill for a model rocket launcher.

We’ve seen many takes on this kind of project. Of course, like everything else these days, you can just use your smartphone.