Planet Arduino

[Lex] over at Computing: The Details loves to make fun projects. Recently, he’s created a hardware CPU monitor that allows him to see how well his PC is parallelizing compile tasks at a glance. The monitor is built from 14 analog meters, along with some WS2812 RGB LEDs.

Each meter represents a core on [Lex]’s CPU, while the final two meters show memory and swap usage. The meters themselves are low-cost 5 mA devices. Of course, the original milliamps legends wouldn’t do much good, so [Lex] designed and printed graduations that glue over the top. The RGB LED strip is positioned so two LEDs fit under each meter. The LEDs allow a splash of color to draw attention to the current state of the machine. The whole bank going red would sure get our attention!

The system is controlled by an Arduino Mega, with the meters driven using the PWM pins. The only extra part is a 1 K resistor. The Arduino wrangles the LEDs as well. Sadly [Lex] did not include his software. He did describe it though. Basically he’s using a Rust program to call systemstat, obtaining the current CPU utilization data in Linux. A bit of math converts this into pointer values and LED colors. The data is then sent via USB-serial to the Arduino Mega. The software savvy will say it’s pretty easy to replicate, but the hardware only hackers among us might need a bit of help.

This isn’t the first custom meter we’ve seen on Hackaday. Your author’s first project covered by Hackaday was for a meter created using an automotive gauge stepper motor. I didn’t include source code either – but only because [Guy Carpenter]’s Switec X25 library had me covered.

Thanks for the tip, [TubeTime]!

[Anders Nielsen] presents his entry for the 2023 Hackaday Prize: The 65uino. Which as you might be able to guess, is a 6502-based microcomputer wedged into an Arduino Uno form factor (well, almost wedged in, but we’ll let it slide) The premise is simple, older micros are easier to understand, the board can be build up from new-old or salvaged stock, and that’s more chips on boards and less sitting on a dusty shelf. After all, even though the 6502 in its original form is long obsolete, it’s far better to be pushing some electrons around, than sitting there decaying.

From an educational perspective, the first lesson is the hand-soldering of through-hole DIP components and a smattering of straightforward surface mount parts in their supporting roles.  Then on to setting up the cc65 toolchain. To say this is a pure 6502 system is a little misleading, it actually uses the 6507 device variant, which is a die-bond variant of the same device but with only 28 of the pins utilized.

The use of the 6532 RIOT (RAM-I/O-Timer) chip provides two 8-bit ports of GPIO as well as a timer and 128 bytes of SRAM, making the design more compact. There is a socket that will accept a 24 or 28-pin E(E)PROM device, with the extra four pins removable and the PCB snapped off if fitment into a standard ‘Uno case is desirable. Neat!

Full hardware build and PCB design (using KiCAD) are available on the 65uino GitHub page. Just remember folks, with everything minimal 6502 related — some assembly required :D

We see the 6502 a lot, let’s be fair. But why not? Here’s a slightly more practical board with a bit more resources, an absolute beast of a luggable dual-6502 machine, and yet another 6502 verilog implementation ready to be dropped into a spare corner of a FPGA project that needs a little extra.

The HackadayPrize 2023 is Sponsored by:

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!

Quantum computers aren’t quite ready for the home lab, but since there are ways to connect to some over the Internet, you can experiment with them more easily than you might think. [Norbert] decided to interface a giant quantum computer to an ordinary Arduino. Why? Well, that isn’t necessarily clear, but then again, why not? He explains basic quantum computing and shows his setup in the video below.

Using the IBM quantum computer and the open source Qiskit makes it relatively easy, with the Python code he’s using on the PC acting as a link between the Arduino and the IBM computer. Of course, you can also use simulation instead of using the real hardware, and for such a simple project it probably doesn’t matter.

Granted, the demo is pretty trivial, lighting an LED with the state of qubit. But the technique might be useful if you wanted to, say, gather information from the real world into a quantum computer. You have to start somewhere.

We’ve looked at quantum computers before. They tell us it is the next big thing, so we want to be prepared. Qiskit is one of several options available today to make it easier.

[Christofer Hiitti] found himself with the latest Microsoft Flight Simulator on his PC, but the joystick he ordered was still a few weeks out. So he grabbed an Arduino, potentiometers and a button and hacked together what a joke-yoke.

The genius part of this hack is the way [Christopher] used his desk drawer for pitch control. One side of a plastic hinge is attached to a potentiometer inside a drawer, while the other side is taped to the top of the desk. The second pot is taped to the front of the drawer for pitch control and the third pot is the throttle. It works remarkably well, as shown in the demo video below.

The linearity of the drawer mechanism probably isn’t great, but it was good enough for a temporary solution. The Arduino Leonardo he used is based on the ATmega32u4 which has a built-in USB, and with libraries like ArduinoJoystickLibrary the computer interface very simple. When [Christopher]’s real joystick finally arrived he augmented it with a button box built using the joke-yoke components.

We’ve seen There is no doubt that Microsoft Flight Simulator 2020 will spawn a lot of great controller and cockpit builds over the next few years. We’ve already covered a new joystick build, and a 3D printed frame to turn an Xbox controller into a joystick.

Oh, sure, there have been a few cube-shaped PCs over the years, like the G4 and the NeXT cube. But can they really be called cubes when the display and the inputs were all external? We think not.

[ikeji] doesn’t think so either, and has created a cube PC that puts them all to shame. Every input and output is within the cube, including our favorite part — the 48-key ortholinear keyboard, which covers two sides of the cube and must be typed on vertically. (If you’ve ever had wrist pain from typing, you’ll understand why anyone would want to do that.) You can see a gif of [ikeji] typing on it after the break.

Inside the 3D printed cube is a Raspberry Pi 4 and a 5″ LCD. There’s also an Arduino Pro Micro for the keyboard matrix, which is really two 4×6 matrices — one for each half. There’s a 6cm fan to keep things cool, and one panel is devoted to a grille for heat output. Another panel is devoted to vertically mounting the microcontrollers and extending the USB ports.

When we first looked at this project, we thought the tiny cube was a companion macro pad that could be stored inside the main cube. It’s really a test cube for trying everything out, which we think is a great idea and does not preclude its use as a macro pad one of these days. [ikeji] already has plenty of plans for the future, like cassette support, an internal printer, and a battery, among other things. We can’t wait to see the next iteration.

We love a good cyberdeck around here, and it’s interesting to see all the things people are using them for. Here’s a cyberduck that quacks in Python and CircuitPython.

The Arduino platform is one of the most versatile microcontroller boards available, coming in a wide variety of shapes and sizes perfect for everything from blinking a few LEDs to robotics to entire home automation systems. One of its more subtle features is the ability to use its serial libraries to handle keyboard and mouse duties. While this can be used for basic HID implementations, [Nathalis] takes it a step further by using a series of Arduinos as a KVM switch; although admittedly without the video and mouse functionality yet.

To start, an Arduino Uno accepts inputs from a keyboard which handles the incoming serial signals from the keyboard. From there, two Arduino Pro Micros are attached in parallel and receive signals from the Uno to send to their respective computers. The scroll lock key, which doesn’t do much of anything in modern times except upset Excel spreadsheeting, is the toggle switch between the two outputs. Everything is standard USB HID, so it should be compatible with pretty much everything out there. All of the source code and schematics are available in the project’s repository for anyone who wants to play along at home.

Using an Arduino to emulate a USB input device doesn’t have to be all work and no play, the same basic concept can also be used to build custom gaming controllers.

A useful add-on for any computer is a plug-in macro keyboard, a little peripheral that adds those extra useful buttons to automate tasks. [Sayantan Pal] has made one, a handy board with nine programmable keys and a USB connector, but the surprise is that at its heart lies only the ubiquitous ATmega328 that you might find in an Arduino Uno. This isn’t a USB HID keyboard, instead it uses a USB-to-serial chip and appears to the host computer as a serial device. The keys themselves are simple momentary action switches, perhaps a deluxe version could use key switches from the likes of Cherry or similar.

The clever part of this build comes on the host computer, which runs some Python code using the PyAutoGui library. This allows control of the keyboard and mouse, and provides an “in” for the script to link serial and input devices. Full configurability is assured through the Python code, and while that might preclude a non-technical user from gaining its full benefit it’s fair to say that this is not intended to compete with mass-market peripherals. It’s a neat technique for getting the effect of an HID peripheral though, and one to remember for future use even if you might not need it immediately.

More conventional USB keyboards have appeared here in the past, typically using a processor with built-in USB HID support such as the ATmega32u4.

If you’re like most of us, you have about twenty browser tabs open right now. What if there were a way to move through those tabs with a physical interface? That’s what [Zoe] did, and it’s happening with the best laptop ever made.

The hardware for this build is simply an Arduino and a rotary encoder, no problem there. The firmware on the Arduino simply reads the encoder and sends a bit or two of data over the serial port. This build gets interesting when you connect it to a Firefox extension that allows you to get data from a USB or serial port, and there’s a nice API to access tabs. Put all of this together, and you have a knob that will scroll through all your open tabs.

This build gets really good when you consider there’s also a 3D printed mount, meant to attach to a Thinkpad X220, the greatest laptop ever made. At the flick of a knob, you can scroll through all your tabs. It’s handy if you’re reading three or four or five documents simultaneously, or if you’re just editing video and trying to go through your notes at the same time. A great invention, and we’re waiting for this to become a standard device on keyboards and mice. Check out the video below.

If you’ve been hanging around microcontrollers and electronics for a while, you’re surely familiar with the concept of the breakout board. Instead of straining to connect wires and components to ever-shrinking ICs and MCUs, a breakout board makes it easier to interface with the device by essentially making it bigger. The Arduino itself, arguably, is a breakout board of sorts. It takes the ATmega chip, adds the hardware necessary to get it talking to a computer over USB, and brings all the GPIO pins out with easy to manage header pins.

But what if you wanted an even bigger breakout board for the ATmega? Something that really had some leg room. Well, say no more, as [Nick Poole] has you covered with his insane RedBoard Pro Micro-ATX. Combining an ATmega32u4 microcontroller with standard desktop PC hardware is just as ridiculous as you’d hope, but surprisingly does offer a couple tangible benefits.

The RedBoard is a fully compliant micro-ATX board, and will fit in pretty much any PC case you may have laying around in the junk pile. Everything from the stand-off placement to the alignment of the expansion card slots have been designed so it can drop right into the case of your choice.

That’s right, expansion slots. It’s not using PCI, but it does have a variation of the standard Arduino “shield” concept using 28 pin edge connectors. There’s a rear I/O panel with a USB port and ISP header, and you can even add water cooling if you really want (the board supports standard LGA 1151 socket cooling accessories).

While blowing an Arduino up to ATX size isn’t exactly practical, the RedBoard is not without legitimate advantages. Specifically, the vast amount of free space on the PCB allowed [Nick] to add 2Mbits of storage. There was even some consideration to making removable banks of “RAM” with EEPROM chips, but you’ve got to draw the line somewhere. The RedBoard also supports standard ATX power supplies, which will give you plenty of juice for add-on hardware that may be populating the expansion slots.

With as cheap and plentiful as the miniITX and microATX cases are, it’s no surprise people seem intent on cramming hardware into them. We’ve covered a number of attempts to drag other pieces of hardware kicking and screaming into that ubiquitous beige-box form factor.