From the lab

Background

We found an Arduino project called pedalSHIELD which included all the components needed for soldering together an Arduino-controlled guitar effect pedal. It was a perfect way to learn more about digital signal processing and building physical, electronic devices while creating something handy (yes, many of us are savvy musicians) and fun.

We started with the idea of having an audio input, such as a guitar or a synth, and then using an Arduino to do the audio processing and send the digitally altered signal to an analog output, preferably plugged into an amp or a speaker.

The Process

When it comes to hardware development, splitting up the work the same way you do in a software project is challenging. First, you need to get a prototype working before you can try out any of the code you’ve done. Therefore the main focus was to get the hardware working as fast as possible.

One part of the team focused on soldering the components to the circuit board provided with the pedalSHIELD kit. This circuit board was supposed to be paired with an Arduino MEGA board.

Another part of the team started prototyping the circuits with Arduino breadboards and pedalSHIELD UNO, following the examples from the pedalSHIELD Github repository. The goal was to bulletproof the process and get at least one of the examples to run so we could run the signal from an instrument through the circuit and out into an amp and hear the affected signal. The examples in the GitHub repository included many common effects and codes for testing parts of the circuit.

We split up some parts of the circuits on different breadboards to combine them into the full circuit in the end. We then tested the full circuit by uploading Arduino code examples sourced from the pedalSHIELD GitHub (or slightly modified versions of them) and playing guitar and synths through the input, with the output going to a guitar amp.

As a last step, we tested the soldered circuit board pedal with the board switches and a small screen. The LED blinked (as it was supposed to), and we got the small screen to show some output. Nothing (thankfully) blew up on our first try, but we had varying experiences with the sounds for various reasons. Either the bypass switch was connected the wrong way, giving us no sound output from the pedal, or the input stage didn't work because no signal was sent to the Arduino.

The Challenges

Our biggest challenge, in repeat, was to figure out why the signal sounded bad and at which stage the issue occurred. We got the pedal's output working quite early, but there were many issues with the audio input stage (or something in between):

• We learned that the potentiometer that was supposed to control the input gain of the guitar did not do anything when twisting it from 0 to max value.
• We could not get the input stage from the pedalSHIELD circuit diagram to work correctly, so we simplified this circuit a bit which resulted in at least hearing some of the input.
• We had problems with low input volume and high and aliasing noise. It was hard figuring out at which stage in the circuitry this was happening. Some low-pass filters may have been removed when we simplified the circuits.
• There were also some clipping issues when striking the guitar a bit harder, even when using the "clean" example in the GitHub repo. We found some articles online where people had clipping issues with the chip used for amplification.
• Sometimes when moving the breadboards, we could get glitches, so the pedal sounded great for 3 seconds or ended up not sounding at all.

We later found a simplified input circuit that worked quite well when connected to the UNO output stage. This was clearly the best build in terms of audio quality. Still, the prototype board was sensitive, resulting in a noisy output. However, we connected a low pass filter which reduced higher frequencies—hearing that a few essential components resulted in an audible difference were a cool experience.

Result / Key takeaways

A big takeaway is that building hardware devices is tedious and vastly different from prototyping software applications. Working with hardware is much more brutal. Making a fatal mistake might destroy hours of work put into a circuit. This fact can be disheartening and scary for a software developer, who can make many mistakes while developing an application without any dramatic precautions and delays in the project. There is a much bigger emphasis on being 100% sure about a decision because it will be a hassle to fix it later.

There might have been an expectation that we wouldn’t have as many issues as we did with different sections of the circuitry. We were following a set of ready instructions on how to put it together (it seems so straightforward). When things didn’t work correctly after following all the instructions, it was hard to figure out a good way to find the culprit—not having a lot of experience and knowledge about these things.

Working with digital audio signal processing also demands code that is by no means bloated and inefficient. For example, it would only be acceptable for musicians to have up to 5-10 milliseconds of latency processing the audio signal. Low-level programming helps achieve this.

In the eventual next iteration of the project, we would:

• Replace or add components that give a better-sounding result. The chips used for the input/output stage are prone to bad distortion that you might want to avoid (unless it is your acquired taste).
• Add more knobs to control the audio effect more tactilely.
• Build more effects or “multi-effects.” Focus on just the signal processing part of the project.
• Generate a synth sound based on audio input from a guitar/microphone.