Robotic Hand

Hello! It’s been a while since I’ve written here but I just completed an intensive project with my friend/roommate/classmate for my CPET-253 class, and wanted to share.

Plan:

For this project, our goal was to use an MSP430 microcontroller, and 5 components from a provided list to create something unique with real-world applications.

The options for components include:
a. State Machines
b. Speakers
c. Hardware Interrupts
d. Timer Interrupts
e. SPI – LCD
f. Bluetooth
g. IR sensing
h. Ultrasonic Sensing
i. Servos
j. Analog to Digital Converters
k. Any additional sensor items from the lab kits

We wanted to find a project idea that suited our skillsets, so considering I have experience with hardware electronics and my friend has experience writing code, we decided on something that would integrate custom hardware with software. After some pondering, we decided to make a robotic hand. The components we picked were state machines, speakers, hardware interrupts, SPI-LCD, and servos. The state machine would serve as the structure of the code, the speaker would play sounds for different gestures, the hardware interrupts would identify when buttons are pressed, the LCD would display a name for gestures, and the servos would move the fingers. Below is a simple sketch of the idea.

As shown above, the hand would use strings as “tendons” which would wrap on spools spun by the servos. The fingers would open back up with elastic on the backs of them. The MSP430 is also connected to a button panel with 5 buttons (one for each finger), a speaker, and an LCD.

3D-Printing:

Our first step was finding a suitable way to make the hand. Since creating it from scratch would be very time-intensive and difficult, we decided to 3D-print it using RIT’s 3D-printing service for students in the Student Hall for Exploration and Development (SHED). We found an Instructables article with 3D files for an articulable hand that used machine screws for the joints. Since each part was a separate .stl file, we combined them using a free software called Meshmixer. All of the parts printed successfully thanks to our slicer settings, including a 1 layer raft and light supports. We used PLA filament on a Pruscia i3 MK3. Once the parts were printed, I labeled them all and we began the process of cleaning them up. Removing the supports and raft was easy, but due to the orientation of some of the parts, the rounded parts were a bit “steppy” due to having significant overhang. To fix this we dedicated a few hours to carefully sanding and filing every joint until the steps were smoothed.

Mechanical Construction:

Constructing the hand was arguably the most fun and easy part of the process. One difficulty we encountered was that the design called for metric machine screws, which are less common in the US. However, after a bit of back and forth between Lowes and Home Depot and 50 or so dollars, we had all the machine screws we needed (some slightly longer because we couldn’t find the exact sizes the design called for, but this was easily solved with some filing and sawing). As we put the fingers together, we checked how smoothly the joints bent, and sanded or filed any material that needed to be removed. To further ease the joint movement, I used a pencil to coat all the joints with a thin layer of graphite for lubrication. We avoided oil-based lubricants since they can sometimes degrade plastics. Once the hand was fully constructed we tried feeding some string we had bought at Home Depot through the loops on the fingers, only to realize that the string was too thick to fit. This was frustrating because it meant we would need to find new thinner string, and at this point, we were working on a time crunch so we were unable to go out and buy more. Luckily, I remembered that I happened to have a sewing kit in my room with a spool of black thread. The thread was not super durable, but it seemed strong enough for this application. Additionally, the black color complemented the orange 3D-printed hand nicely. Once the string was threaded through, we were able to do simple tests on the hand’s mechanical functionality.

Below is a video of the hand being opened and closed using the sewing thread.

One issue we found was that when the hand was opened too quickly or forcefully, the thumb could end up stuck in an overextended position. To fix this I added a small plate that limited the thumb’s extension. This allowed the thumb to still fully open while preventing overextension. Another modification I made to the hand was adding copper wire around the bottom of the metacarpals. This allowed the thread to move over a smooth rounded surface, rather than riding over the nuts and getting caught or abraded. One more change we made to the hand was adding additional holes to the base for the tendon threads in the front. The reason for this change was to improve the angle of the thread pulling the thumb. Since the design had an opposable thumb, it would swivel in and out when the thumb moved. Having the thumb tendon thread go through a hole in the center of the base meant that the thread’s angle was closer to vertical than horizontal. Because of this, the thumb was getting pulled down more than horizontally towards the palm. Making its tendon go through a hole across the thumb greatly improved this issue. Below is a very simplified diagram showing how the new holes for the tendons allowed better angles for the thumb tendon.

Now that the hand’s movement seemed smooth enough, I needed to find a suitable enclosure to attach the hand to, that would contain the servos. I found a perfect one sitting around, which originally contained a cheap stereo pair of iHome portable speakers. It was a black rectangular box made of plastic, with a removable front cover and a black felt-coated interior. To attach the hand, I first copied its tendon holes in the base into the top of the enclosure. I then glued the hand to the top of the enclosure, with the tendon threads going through the lined-up holes, and into the enclosure.

At this point, we had tendons on the front and back of the hand, with the ones on the back just going through one central hole in the wrist connection. I planned to then have elastic connected to these threads inside of the enclosure so that when a finger was released the elastic would straighten the finger back out by pulling the tendon threads on the back of the hand. I managed to get two of these elastics properly connected when I realized that having thread tendons running through channels on the back of the hand created way too much friction. To make the elastic strong enough to straighten the fingers back out, it would need to be tightened beyond what the small servos we had could handle. Seeing this limitation, as well as the low amount of room left in the enclosure, I decided to scrap the idea of tendon threads on the back of the hand. Instead, I cut out small strips of elastic and glued a separate piece on the back of each joint. This solved the friction problem, making it so that the elastic could be less strong, in turn reducing the eventual load on the servos.

The new elastic method, with a separate strip for each knuckle

Now it was time for the project to become serious – I was finally ready to install the servos. One thing I had to figure out to make the servos work was how to have them pull on the threads. To do this, I first considered the servos we had to work with. They take a PWM input, and the pulse width determines their position. Since they have a maximum travel of 180 degrees, I decided that rather than a spool I could simply use a cam as shown below.

With the cam system as opposed to a spool, construction of the servo arms became much simpler. This solution worked well because the servos came with attachable cam arms, to which I only had to add a piece of twisted copper wire for the thread to attach to. Now that I knew how I wanted to connect the threads to the servos, I needed to find a way to arrange the servos in the enclosure without them interfering with each other. To accomplish this I first considered the clearance I needed in the X-Y plane.

The servos were arranged in three consecutive rows, the first and second rows consisting of two servos and the last one consisting of one. This allowed them all to turn a full 180 degrees and pull on the threads without hitting each other.

However, after considering the X-Y clearance, I realized that there was an issue. Having identical cams on each servo would lead to thread colliding with the cams in front of them. To solve this issue I considered the clearance in the Z plane.

I found that by having each consecutive row increase the cam height, I could solve the issue of threads colliding with any cams in front of them.

Now that I had a plan, it was time to work on installing the servos. I went one by one, from thumb to pinky, testing clearances on each cam, and shortening or lengthening the cams to adjust the travel of threads for each finger. This meant that I could perfect the distance of travel for each finger, while also avoiding any clearance issues.

Here is a short video of the middle finger servo being tested with some sample code my friend wrote.

After some fiddling and adjustments, I had all 5 servos installed with their cams and threads connected. To keep the servo wires out of the way of the cams, I ran them in between the servos below the cams and used strips of paper to keep them in the bottom left corner of the enclosure as seen below.

The copper wire at the top serves as a further reduction of friction, since the holes the threads originally ran along have sharp edges and might cause tearing.

Electronics

The next step after installing all the servos and getting the mechanical parts working was to deal with all the electronics hardware. First, I wanted a way to connect all the servos to the MSP430 without needing a ton of wires connecting each servo’s power and ground to it. To deal with this, I used pin headers and a piece of perfboard to connect all the power rails. By doing this, I only needed to connect one power and one ground wire to the MSP430 for all of the servos. Since I was socketing the servo connectors, I also soldered a socketed jumper for each servo’s PWM pin to the perfboard.

Above is the perfboard with all 5 pin headers (one for each servo), a PWM socketed jumper for each connection, and a power connection next to the pinky connector. I labeled each finger to simplify the process of connecting everything. This saved a lot of time since I knew which wires came from which servo.

To connect the PWM pins accordingly, I followed a pinout guide made by my friend:

The next step after this was to build the control interface. This would consist of 5 momentary buttons on a surface, each corresponding to a finger. Since my friend used the internal pull-up resistors for these inputs, I made the buttons active low. One other addition I made was adding a 0.1uF capacitor in parallel with each button. The purpose of this was to debounce the buttons, since bouncing on button contacts often causes problems with hardware interrupts. Below is a sketch of the schematic of the controller, followed by an image of the completed controller.

The base of the controller is made of corkboard since it is soft, easy to glue to, aesthetically pleasing, and easy to cut. There are two layers of corkboard to increase stiffness, in case the controller is used off of a tabletop.

One of the changes that was made to our original plan was the use of the LCD. After reconsidering the amount of time left and how much effort SPI communication in the MSP430 takes to set up, we decided to drop that component and replace it. After careful consideration of our options, we decided on timer interrupts as our fifth component. This decision will be further explained in the software section of this post. Part of this change was implementing a “display” mode, which would display different gestures one after another. To enter this mode, we decided to implement a rocking toggle switch. The switch connects port 6 pin 0 (as seen in the pinout) to ground when active, and uses one of the MSP430’s built-in pull-up resistors. Rocker switches are less prone to bouncing, but to play it safe I included a 0.1uF capacitor in parallel.

The speaker for this design was a small piezoelectric buzzer, to which I soldered some socketed jumpers. Below are the buzzer and rocker switch attached to the enclosure:

The final hardware change to make was finding a way to attach the MSP430 to the enclosure. Since drilling holes and using standoffs would be a bit time-consuming, I came up with an alternative. The MSP430 attaches to the chassis we use in class via socketed pin headers, which makes a secure but easy-to-disconnect attachment method. Since I have a large stock of pin headers, I decided to use them. I bent the pin headers 90 degrees, socketed them into the MSP430, and glued the exposed bottoms to the enclosure as shown below.

This attachment method worked great because it held the MSP430 to the enclosure securely, but made it very easy to remove. I’ll probably be using this approach for future microcontroller projects due to the ease and speed of putting it together.

Code

My friend did most of the writing of the code, but still had me check it every so often and provide feedback. Doing this throughout the writing of the code was very helpful because when the time came to debug, I already had a good grasp on the structure of it. We originally started this project by creating a state transition diagram for the state machine, which is shown below.

This format for the state machine allowed interactivity (controlling with the button pad) as well as active response from the microcontroller (in the form of sound and LCD display) depending on the detected gesture.

After some structuring of sample code and discussing, my friend and I decided to restructure this. The first change, as already mentioned in the hardware section, was removing the LCD. This is partly because SPI involves lots of registers and time to set up, but mainly because we didn’t want to use the robot chassis for this project. It felt unnecessary to include it only for the sake of the LCD, especially considering that without it we could make the whole arm a standalone unit besides the control pad. However, this put us in the position of needing to select a new component to fulfill our requirement of five. After some careful consideration, we decided to use timer interrupts. I had the idea of having two “modes” for the arm – active, and display. Active mode would allow interactive use of the buttons to control the arm, and display mode would cycle through different gestures, accompanied by sounds playing. The reason for this idea was that we could use timer interrupts as a way of timing the gestures for display mode. It also meant that since display mode would use the speaker, we could remove gesture detection from active mode, making the coding process a lot easier.

The very first piece of code that was put to use was a simple servo test. It used the MSP430’s timers in PWM mode, and functions to move each finger up and down. Each function would update the corresponding CCR for each finger, updating the pulse width for that pin output.

Starting with just one function, we tested various values for the maximum and minimum pulse widths. Eventually, we landed on two values that gave us a full 180-degree rotation on all servos. These values were then defined as constants that could be included in the function calls.

Once we had this tested, my friend proceeded to structure the state machine and functions while I built the electronics and mechanics. Our new state machine had three states: Active, Display, and Fingers.

Active State

This state’s purpose was to move the fingers back up when their respective buttons were released, as well as transitioning to the other two states. Entry housekeeping sets the MSP430’s onboard LED to green to indicate the state, enables interrupts for the button inputs, and disables the timer used for the Display state. If an interrupt is detected, indicating a button press, the state would be updated to Fingers. If the rocker switch was used to select Display mode, the state would update accordingly. I’ll further discuss the reason for our use of the boolean “isSwitch” later on in the functions section.

Display State

The Display state’s purpose was to cycle through various gestures and to play sounds corresponding to the gestures. In entry housekeeping, the LED color is updated to purple, interrupts for finger buttons are disabled, the gesture variable is reset to 0, and the Display mode timer is set to continuous mode. This timer would use interrupts to update the gesture value, which will be explained later in the functions section.

In the first gesture (a “rock on” sign), the fingers are updated one by one, and after a one-second delay, it plays an alternating half-step interval on the speaker.

The second gesture is a thumbs-up, and similarly updates the fingers, waits one second for them to move, and then plays a tune. This one plays an arpeggiated C-major chord once and then again up an octave, making a pleasant chime sound.

The third and final gesture is an “ok” sign. It updates the fingers one by one, waits a second, and then plays a C-note twice (the first one being much shorter than the second), and then does the same up an octave.

Finally, the Display state checks for the rocker switch being set back to Active mode. When this is detected, it sets isSwitch low again, and sets the state to Active.

Fingers State

This state is the simplest. It is entered any time a hardware interrupt is detected on the finger buttons. When fingers is entered, it sets wasInterrupt to 0, sets the LED color to red, and goes back to Active state. The actual moving of the fingers occurs in the IRQ handler, which will be discussed later in the functions section.

Functions

The first custom function written was Interrupt_Init(). Its purpose is to initialize all the interrupts by setting corresponding registers to the correct values. For the hardware interrupts, it enables them on the pins shown in the pinout. It then sets the edge select for active low buttons, clears flags, and selects port 6 as the input. Then it sets the timerA2 registers to interrupt every time the timer rolls over, clears flags, and sets the NVIC source as timerA2.

The fingerInit() function plays the role of resetting the hand. This simply raises all fingers one by one, with a 500ms delay in between each.

The Playnote() function is used to play sounds on the buzzer speaker, with a value for pitch and note length. TimerA3 is used for this, at 50% pulse width. To make it easier to play the correct frequencies for notes, we used constant declarations for 3 octaves. This way, when calling the Playnote() function, we could just do Playnote(LC, 1) instead of Playnote(0x1664,1). This made the process of making sounds for Display mode a lot faster and easier. The note length uses an if else statement to delay various lengths (for quarter notes, half notes, and whole notes).

This function is the IRQ handler for port 6 interrupts. It serves the purpose of closing fingers when their corresponding buttons are pressed, as well as updating isSwitch when the rocker switch is enabled. The switch statement checks which button the interrupt occurred on, and then the corresponding finger up function is called. The reason for isSwitch being used is that we had trouble directly changing states by checking the value on P6.0. Because of this and running low on time, I had the idea to just use a hardware interrupt for the rocker switch since it was our only consistently working way of checking its position. Since we can’t directly use an interrupt to switch states, I had it instead update a boolean called isSwitch that represents the state of the rocker switch.

The final custom function was the IRQ handler for timerA2 interrupts. TimerA2 rolls over every third of a second at its maximum period, which is way too often for our robot to have time to switch gestures. To fix this, we had the function increment a count variable every time the timer rolled over. After 20 of these increments, the IRQ handler would increment our gesture value. This would signal the Display state to move on to the next gesture in the sequence. At the end of the IRQ handler, it would clear any flags, allowing the function to be called again on the next timer rollover.

Once this code was all written, we were able to move on to testing the full functionality of the hand. The only changes made after this point that haven’t already been mentioned were fixing small errors in the code. Some of these include accidentally setting the wrong registers in port initializations (causing two fingers to not move), or calling fingerInit() at the beginning of the Active state (causing fingers to open every time the state machine left the Fingers state).

Demo

Conclusion/Closing Thoughts

This project felt like a great success overall. I had many concerns about encountering issues with the mechanics and code that we wouldn’t be able to fix in time, but we managed to have everything working for the day of our presentation. However, throughout the process of making this project, I learned a lot and have thought of a few improvements I would make in a future redesign.

Mechanical Improvements

One of the first struggles we encountered in this project was the smoothness of 3D prints. While the hand worked very smoothly after lots of sanding and filing, there are some changes I would make to the way we printed parts to reduce the cleanup time. Many of the hand pieces were oriented to minimize the need for supports, but in this process I neglected to consider overhang on the areas that needed to be smoothest – the joints. Many of the pieces printed with the joint aligned with the vertical axis had lots of layer “stepping” on the undersides, requiring more cleanup. Next time, I would make sure to align all the parts to have the joints flat on the print bed, meaning that any supports would go on flat parts rather than the rounded joints. This would probably result in cleaner prints, meaning less time spent sanding and filing.

Another mechanical change I would make is using fishing line instead of sewing thread. While I chose sewing thread out of necessity, it did break a few times during testing (as well as right before our presentation which was terrifying). It was also very hard to work with since it was so thin and would often unravel. Fishing line would be more durable, smoother, and a bit thicker and therefore easier to work with. I would also spend more time making sure that the holes for the threads that go through the wrist connection are smoother, or have more copper wire lining them to provide a smooth surface for the threads to slide over.

One final mechanical adjustment I would make is using larger servo motors with more rigid cams. Since we need to return these servos to the lab, I didn’t want to damage the provided servo arms at all, meaning the cams I made with them were relatively flimsy, being dependent on copper wire pressure fit through holes in the arms. Next time I would consider first doing the math to find the necessary travel distance for each thread, and then design 3D-printable cams. One of the downsides of copper wire on the cams was that the ends of the cams were a bit sharp, and if a thread slipped over the end of them it could sometimes break.

Electronic Improvements

One consistent issue faced with the electronics on this project was wires being disconnected. I didn’t want to solder to the MSP430’s pin headers for obvious reasons, so I used socketed jumper wires exclusively. However, these can sometimes be loose and come undone. In a future rendition of this project, I would use pin sockets soldered to perfboard. This way all socketed pins would be held together mechanically, greatly reducing the likelihood of them becoming disconnected.

Another change I would make to the electronics is adding decoupling caps to the servo board. Since the servos all share power rails from just two pins on the microcontroller, the voltage might sag a bit under higher load. The servos might also be introducing some noise to the power rails, which could be detrimental to the performance of future features such as analog to digital conversion. Decoupling caps would help make up for this, supplying current when the servos draw more current. I think a 100uF electrolytic cap for voltage sag, and a 0.1uF ceramic capacitor on each servo’s connector for noise would do the trick.

One final electronic adjustment that I would make is changing the input method for active mode. The buttons we used take a relatively high amount of force to actuate, making it slightly more difficult to use the hand. I would replace them with either buttons that take less force to press, or an analog input that senses finger position continuously rather than only detecting fully open or closed. This would take significant work changing hardware as well as software around, and I’m not entirely sure if the MSP430 has enough ADCs to accomplish this without some sort of multiplexing.

Code Improvements

I found our resulting code for this project to be deeply satisfactory, giving us the full functionality that we hoped to display. However, we did make some compromises for the sake of time.

One of these such sacrifices was eliminating gesture detection, which I think was a very cool feature concept that we could learn a lot from implementing. My thoughts for how this would be implemented would require a change in how fingers are opened and closed. Instead of having the IRQ handler directly call the finger closing functions, I would have it update a 5-bit binary number representing the states of each finger. This 5-bit binary number could then be used in a switch statement, with cases for various gestures such as a thumbs-up, ok-sign, etc.

Another change to the code that I would consider implementing relates to my ideas for the control input electronics – using flex sensors on a glove, pressure sensors, or potentiometers mounted on joints as an analog input for finger position. This would entail using the MSP430’s ADCs to convert the analog voltages to discrete digital values. I think that this could work well in the form of a 1D array of five finger position values. The values could then be converted to CCR values, and used in the finger up and finger down function calls. One benefit of this method is that gesture detection could still be implemented. The 1D 5 value array of finger positions could be checked against thresholds for “open” and “closed”, and this could be used to update a 5-bit binary representation of which fingers are closed. By doing this, the code would still be able to detect various gestures from continuous finger position inputs rather than just binary ones.

ThunderTune Video (Maker Faire Rochester 2022)

Back at it again!

Hey there! It’s been quite a while since I’ve posted here on my blog. Though I haven’t really posted updates for a while, that doesn’t mean I haven’t worked on any projects! Currently the paraphonic string synthesizer is still in progress, but it sure is close to finally making sounds! I have hooked up all of the PCBs from JLCPCB but found that a couple of the ICs I used for the keying circuit are faulty. Once I replace them with working ones, I think we’ll finally be hearing the synth make some noise! It won’t have any filtering or VCA action, but it will be capable of being tuned up and playing a few notes.

In terms of other projects, I’ve worked on a few. One thing I’ve experimented a bit with is video synthesis. Video synthesis is just like audio synthesis, but creating video signals instead of audio! There are two main types – pure video synthesis, which is creating the video signal completely from scratch, and video synthesis using camera feedback or preexisting video signals. The first kind, pure video synthesis, often appears in the form of repeating patterns or lines. The secondary kind usually has visible video signals in the form of videos or images, which are then put through effects and sometimes mixed with pure video synthesis. The second method is much more approachable, since it can be easier to have an existing video signal to alter rather than make one from scratch. An excellent way to get started with video synthesis is simple camera feedback! This is simpler than it might sound – all you need is a camera and a monitor! You can then just point the camera at the monitor while having its signal shown on the monitor. This can create beautiful patterns, and when set up at the right angle it can keep going forever!

Some examples from just video feedback:

I do find that I have an uncanny ability to make huge plans for projects, and get then let them sit on the backburner for ages when I get tired of building them. Because of this, most of my more successful projects have been relatively short term or smaller. With the paraphonic synthesizer, my hope is to work past this struggle with larger projects. The synth is my largest electronics project to date, and therefore is quite a challenge when it comes to dedication.

Speaking of larger scale projects, I have an interesting one also in the works! My high school offers the IB program, which is essentially fancy AP with extra mandatory courses. One of the extra courses is called the extended essay. This project is a 2 year long process of writing a research paper. For most students, the EE tends to be based on research of history or works of literature. However, I chose to take an approach closer to my personal interests. For my extended essay, I’m designing and building an audio spectrum analyzer.

What the heck is a spectrum analyzer??

A spectrum analyzer can be thought of as a tool for understanding the frequency buildup of an audio signal. It appears like a bar graph, with each bar representing a range of audio frequencies, and the height of each bar representing the volume/intensity of that frequency band.

Pocket 10-band audio spectrum analyzer - YouTube — Credit: https://www.youtube.com/watch?v=vWpC5PtNE6E

Here is an example. As you can see, there are 10 bars here (each one representing a range of frequencies), and each bar shows the intensity of that frequency range. The first bars represent lower frequencies (bass), the middle4 ones represent middle range frequencies (mids), and the last ones represent higher frequencies (highs). The human hearing ranges from about 20Hz to about 20kHz. Therefore, most spectrum analyzers represent frequencies from throughout that range.

For my extended essay, I am designing one of these from scratch, with 10 bands and each band having 20 LEDs to represent the levels. To accomplish this, each bar needs to only receive a signal from the frequencies it represents. To do that, I will be using a bandpass filter for each one, which essentially only passes through a specific band of frequencies. Then, the filtered signal for each bar will be run into a circuit that allows its intensity to be displayed as a bar of LEDs. Luckily, there is an IC that is specifically designed for that application! The LM3915 takes in an audio signal, and controls 10 LEDs to represent the intensity of that audio signal. Since each band has 20 LEDs, they will each require 2 LM3915s. At the moment I have successfully prototyped one bar module, and am working on soldering that design on protoboard to finalize it. The next step after that will be to solder the other 9 bar modules, and mount them together. Then finally, the filters can be built, the case can be designed and used, and the project will be finished! Of course after that comes writing the paper about my process and experience.

Anyways, I’ll probably make a dedicated post for each of these, along with another post later describing some other projects I’ve worked on since I last posted.

ROM Sample Player

Intro

This project was a small experiment I did back in November based around some ROM (Read Only Memory) ICs I had. I originally recovered them from various electronics, with the hope of hearing the samples stored inside. A sample is a short audio clip, such as a piano note or alternately a drum sound like a snare or a cymbal.

Some info about ROMs

ROMs are used for many applications but have the overall function of storing some kind of digital data that can be recalled. Most ROMs have multiple addresses, each one holding 8 bits of data. An address can be thought of as an individual place where a small amount of information is held. By telling the ROM which address you want to read from, it becomes very effective as a way to find specific data. The addresses are each represented by their own binary number, and can store any binary value from 0 to 255.

So how can something like audio be represented as a number?

When it comes to storing something like analog audio as digital data, something called an ADC (Analog to Digital Converter) is used. What this does is covert a voltage to a binary value that represents it. For example, if the ADC can convert any value from 0V-5V, 0V will be converted to a 0, and 5V will be converted into 255. Any voltage in between will be some number between those two extremes. Since we are limited here by the values we can store as binary, our data will not be 100% accurate compared to the actual voltage it represents. For example, if a voltage is in between two binary values, the ADC will have to round it to whatever value it is closest to. This means that if we were to try converting the binary data back into an analog voltage, it would become rounded up or down rather than being exactly accurate. Audio is just a changing voltage, meaning that if it is converted into binary and then back into a voltage, it would lose smaller changes or details. How accurately a voltage can be stored and recreated is called the bit depth. In our case our bit depth is 8 bits, meaning that we can only represent 256 possible voltages and have to round any in between. Since an audio sample will have many different voltages, we are also limited by the number of voltages we can store. This is determined by how many addresses our ROM has, since each address holds a different value. In the case of these ROMs, we have 256 addresses, which are also represented as 8 bits. Since we can only store 256 different voltages, we have to compromise by limiting the rate of voltages we convert and store. The rate at which audio is converted to binary is called the sample rate.

With all these limitations in mind, we know that the audio stored in our ROM will not fully represent the original sound, but will rather be an approximation.

Well now that we know how the audio is stored as binary, how do we turn it back into sound?

This is luckily a relatively simple job. Each consecutive stored voltage in the ROM has an address, and the addresses are numbered in the order they appear in the sample. This means that to get the data out in the correct order, all we need to do is count through each address one by one. To accomplish this, we can use the SN74HC161N, which is just a binary counter. Since we have 8 bits of addresses and each counter only counts 4 bits, we can chain two together resulting in a total of 8 bits being counted. To tell them to count however, we need to input a clock signal. Each time this clock signal is on, the counters just count up by one. In this case, I used a CD40106BE, which is a hex Schmitt trigger inverter. Woah, what the heck is that? I know, it sounds intimidating. For this application, all we need to know is that by using just a capacitor and resistor we can make a square wave. A square wave goes from off to on repeatedly at a certain rate. To change the rate, we can change the resistor value by using a potentiometer AKA a variable resistor. Now that we can count through each address of the ROM, what do we do with the binary it’s spitting out? We use what’s called a DAC (Digital to Analog Converter). It does what its name suggests – whatever binary value is put into it, it outputs a corresponding voltage. Therefore if we connect it directly to the data coming from the ROM, we can now get actual audio coming out! All we need to do afterwards is put a small amplifier since the audio coming out of the DAC is pretty quiet.

Let’s build it!

Since this project is more of a fun experiment than anything, I’ll be using a breadboard. A breadboard is just a way to temporarily set up electrical circuits so I can easily make changes. Conveniently, most 8 bit ROMs like the one I want to get sound out of have relatively the same pinouts (a fancy name for the arrangement of the chip’s pins). We just need to connect power, ground, and a few other pins to let the ROM know we want to read from it. Then, we can set up our clock made from the CD40106BE IC, and connect it to the two binary counters. To tell the counters when to start counting, I just attach a button to their reset pins, meaning they start counting from 0 every time I push the button. The outputs of the counters can be hooked up to the address inputs of the ROM, and the data outputs of the ROM can be connected to our DAC. After a few tweaks and the addition of an amplifier on the output, we can hook it up to an amplifier and try it out!

The finished circuit
The top right IC is the clock generator, the two below it are the binary counters, the big one below those is the ROM, and the ones to its left are the DAC and amplifier. The green protoboard in the bottom right is a simple board that allows me to power the breadboard from a micro USB cable.

Here you can see the circuit playing a snare sample. When I turn the little blue trimpot (trimming potentiometer), I’m manually adjusting the clock speed, in turn changing the pitch and quality of the sample’s playback.

Sneak peeks at in-progress projects

Hey all! I haven’t posted in a little bit so I thought I would do a quick one just to cover some projects I’m working on.

Paraphonic String Synthesizer

One main project that has been in progress, is a paraphonic string synthesizer inspired by the Crumar Multiman and Solina String Ensemble. The basis of it is that there are 12 oscillators (one for each note in an octave), and their frequencies are divided for lower octaves. Currently I have completed the oscillators and frequency dividers, and also a circuit to allow the keys to control the turning on of notes. The big part that I now need to complete is to connect the 48 notes to the keying circuit, and the physical keys to it too. This will take care of the biggest electrical challenge, leaving the task of creating various preset filters for different instrument sounds (Brass, viola, violin, etc), an overall VCF and VCA controlled by separate envelope generators, and a simple interface to allow the player to create and mix different notes. The last step of course will be, other than testing and troubleshooting, building a case for the synth and making it look relatively nice. Once finished I have a person in mind that I will be sending it to, who hopefully will enjoy it and make music with it.

Guitar Pedals:

I am also working on some experiments for guitar pedals. One that I have made some good progress on is a fast digital delay, using shift registers to delay the binary audio data before converting it back into analog. The clock speed for the circuit will be variable, making each successive delay more “bitcrushed.” Besides this design, I am also brainstorming a guitar pedal that I hope to send to a youtuber that usually focuses on drawing but is learning guitar. For this an idea of mine is a PT2399 based reverb, which would probably be similar in design to the Synthrotek Verb module. These guitar pedals are mostly on the backburner since I want to focus on the paraphonic string synthesizer. However, whenever I am unable to work on the synth due to parts not having arrived yet I can dedicate some time to these ideas.

Anyways, I can’t guarantee a post about finished projects any time soon, but you can expect more updates on my progress! I plan to start making posts on this blog more focused on progress updates rather than waiting until I finish a project to write a long post. This will be the first of many less formal posts documenting progress. Don’t worry though, I still plan to make a big post for every finished project!

Some pictures:

DSO-138 Oscilloscope Module

Intro

What I’ve found to be a very useful module in a modular synth setup is an oscilloscope. Woah, big word! What on earth does that do? An oscilloscope essentially just lets you see voltages over time. What that means is if you have an oscillator creating a waveform, you can use an oscilloscope to see it! This can be very useful for debugging patches, making your modular synth look more like the controls of a spaceship, and some other things. An oscilloscope can be a pretty complicated piece of kit and because of that, good ones can cost upwards of $300. Luckily there exists a very affordable and open-source oscilloscope that can be bought as a kit for as little as $10, or fully assembled for $15! It’s called the DSO-138, and is popular among those starting out with electronics. Of course I was a user of it too before I got a better quality oscilloscope. Since I no longer use my DSO-138 as often, I decided to make it into a synth module!

Planning

As I’ve said before on here, my modules are 15cm tall and a multiple of 3.25cm wide. I was hoping to make this module only 7.5cm wide, but the DSO-138 is 11.7cm wide. That being said, the screen module which is on a separate board is less that 7.5cm wide, and the main board is exactly 7.5cm wide! This sounds perfect, right? The downside is that rotating the main board while keeping the screen’s board level is tricky. The two boards connect with a 40 pin connector. I decided that my best bet would be desoldering the original connector, and reconnecting it to the screen via wires. Unfortunately, I ended up struggling a bit with desoldering the connector, which led to the screen’s board being damaged. However! The screen connects to its board via many small solder pads. Since the nice large ones on the main board had been damaged, I decided I’d have to give soldering to the small pads a shot. After that the rest of the module should be fairly straightforward to do. It would be a case of just removing the buttons and switches from the main board to place them closer to the panel, and to make it compatible with eurorack power standards.

Time to build it!

Here is the connection from the screen to its board. The larger pins toward the bottom of the picture are what connect to the main board.

Here you can see the result of tons of time doing very precise soldering! I was able to, by using very fine wire, solder to each individual solder pad and connect them to the main board. This process took me about 3 hours, only because of the tiny pads.

Next up is the panel. As usual I’m using single sided blank PCBs, and sanding the surface before painting them black.

Here you can see the panel with the buttons and switches installed, along with the main board which is not yet connected.

For the power, the DSO-138 runs on 9V DC, so it was a simple case of using a 7809 voltage regulator to regulate the voltage of the power supply from 12V to the suitable 9V. When it comes to heat generation, the DSO-138 uses very little current so the 7809 getting hot is luckily not a concern at all.

The Finished Project

Here’s the finished thing! It is a little messy, but I’m satisfied with the result.

In this quick demo video you can see it being used to visualize the outputs of my VCO module.

Modular Synth Case!

Since I created my very first modular synth module, I knew I wanted a case. Modules are usually just a panel with a circuit on its back, and can be annoying to use outside of a case. A case allows them to be held in place, meaning cables can be easily plugged in, buttons can be easily pressed, and the whole thing looks more refined.

Finding a suitable enclosure

The first step to this project would be finding a container that roughly fits the size of my modules, and that would be easy to drill into for attaching rails. I’ve seen cases made out of various Ikea furniture. Sadly though, I have no unused Ikea furniture to repurpose or a close by Ikea to buy some from. Since this wasn’t an option, I wanted to see if I could find any different suitable enclosures for a case. My synth modules are 15×7.5cm. Having two stacked vertically translates to a height of 30cm, which happens to be barely under a foot. Since the height of the case would be most important, I used this measurement to guide my choice of enclosure. Searching for some time, I eventually found a wine box being used to hold books. The box had a 1’x1.5′ inside. Perfect!

Starting the build:

For a modular synth case, modules require a rail at the top and bottom that they can screw into. The easiest way to make rails, I decided, would be to have wood trim used and to use threaded inserts for installing modules. A threaded insert, being a metal insert with a threaded hole, means that I can install and uninstall modules as much as I like without worrying about the wood weakening from being screwed into repeatedly. After finding some 1″x1″ and 1″x0.5″ wooden trim and cutting it to size, I headed to my local hardware store for some threaded inserts and matching machine screws.

For the threaded inserts, it’s a simple case of drilling holes, and super gluing or epoxying the inserts in. However, the inserts I bought had round tabs and had to be cut down to a slimmer state before being used in the case. If I had kept the round tabs, the inserts would have overlapped and led to a messier and less than ideal finished product.

Now that I had the main parts of a modular case, I added some accessories to make the case a bit nicer.

On the top of the case, I added a handle recovered from a broken guitar amp.

To the bottom, I glued on some rubber feet to avoid scratching the case or any surface I set it on.

On the left side, I added an AC jack and a power switch which I connected to my power supply inside the case.

Finished already?

Yup! Looks like I have the case all finished and looking good! I have yet to install threaded inserts for the whole rails, but I plan on doing that once I finish some more modules.

About the power supply, I plan on making a new one and making a post showing the process. Until then you can expect some more modules to be posted about!

Those with a keen eye will notice that I’ve redone the appearance of the 3340 VCO module! The copper coating oxidized a bit too much so I removed it and painted the panel.

Buffered Multiple

Introduction to the project:

What the heck is it, and why build it?

So, when using a modular synthesizer, it can often be important to split a single signal/voltage into multiple outputs. An example of when this would be useful is when controlling multiple oscillators with one pitch CV (control voltage) source. Depending on the CV source and the designs of the oscillators, the inputs could all just be wired in parallel to the one CV output. However, more often than not, having one signal or voltage split to multiple modules can mean a drop in voltage. In this situation, a buffered multiple is perfect. It takes one input, and has multiple outputs that follow the input’s voltage. What is ideal about this type of module is that it draws no current from the inputs, and can handle relatively high loads on the outputs. The buffered multiple can be used for DC voltages, or AC audio signals.

My Design:

For my version of a buffered multiple, I decided that I would like it to have 3 outputs per input, and four separate inputs. This means a total of 16 jacks, 4 inputs and 12 outputs. Since this is a simpler module that requires only jacks, no large knobs, I chose a smaller panel than the one used for my VCO. This panel is just as tall, but half as wide, making the dimensions 3.75cm by 15cm.

Planning the layout, along with some preliminary IC placing

For my circuit design, the idea is very simple. A basic buffer can be easily made by using an op amp (operational amplifier) with the output connected to the inverting input. This creates a voltage follower, which outputs the same voltage applied to the noninverting input without drawing any considerable current from the voltage source. Since each input has 3 outputs, each 3 op amp buffers will have their inputs connected. Also, on each of the outputs, I added a 180 ohm resistor as a current limiting precaution. This means that in the case of a short circuit on the outputs, the resistors will protect the op amps from being overloaded and possibly blown.

The Build:

With most circuits I make that use ICs, I like to put sockets to use so that if I need to, I can easily replace the ICs in use. However, at the time of making this, I had just run out. I decided to go ahead with the circuit, using MC33079P op amps. Taking about 45 minutes to solder up the circuit, I decided it was time to connect it to the front panel and give it a test. Due to the proto board getting a bit crowded, I ended up running some of the resistors over the ICs.

A lesson in forethought:

Welp… I kinda messed up there. Turns out in my excitement to complete the soldering, I made the fatal error of forgetting the pinout of the ICs I was soldering. For most DIP (Dual in-line package) ICs, the positive voltage connects to the top right pin, and the negative supply voltage to the bottom left pin. However, with DIP14 op amps, the sides are flipped, with positive supply voltage on the left and negative supply voltage on the right. Thanks to this and my rushing, I was a genius and connected the supply pins to the wrong supply voltages. Upon plugging it in to the power supply, I promptly saw and smelled some lovely magic smoke. Whoops!

Round Two!

This time around, I made sure to get some IC sockets delivered first, and also to try to keep the proto board much neater.

First connecting the supply voltage rails, making sure to start with them so I don’t mess up again!

The soldering, with all connections made neater and more orderly

Here you can see the IC sockets I chose to use, and that I moved the power connector to the top of the proto board, leaving more room for components and soldering.

Now that I had finished all the soldering, it was a simple case of connecting all the wires to the jacks, and giving it a test!

The Finished Product:

It works, yay!! All outputs follow their respective input voltages, and no significant current is drawn by the inputs!

A fun mod for any guitar pedals

I recently discovered a fun and easy mod for guitar pedals that can be done with pretty much any pedal. I thought of this basic idea when learning about resonance in synthesizers.

To put it simply, resonance is feeding the output of an active filter (a filter that uses power as opposed to a passive one, which requires no power source) back into itself. This means that each time the signal passes through, the filter keeps affecting it, accentuating the frequencies allowed to pass through the filter. This leads to the signal sounding more harmonic and tonal. Controlling the amount of resonance limits how much of the signal gets fed back into the filter. When turned up high, it can start to oscillate, sounding like a squealing whose frequency is dependent on the cutoff of the filter. This is pretty much what feedback with a guitar or microphone is. The audio signal feeds back into the guitar or microphone from the speaker over and over again, creating a relatively high pitched sound. Though usually unpleasant, feedback can make a guitar sound more aggressive or intense.

My simple modification for these guitar pedals is a form of resonance or feedback. The mod allows the player to make their guitar signal feed back into the pedal’s input from its output. This loop can create a resonance or feedback sound, and when the signal’s loop is attenuated, letting less signal back into the pedal, the amount of feedback is controlled. For some pedals such as distortion, the sound becomes squealy and harsh, making sound almost like the guitar is screaming. With some pedals such as a reverb or delay, it can function as an ambient hum or droning sound. The beauty of this modification is how simple it is, and how it can be added to any guitar pedal. I’m sure people have done this before and written about it, but I haven’t seen it mentioned anywhere before. If you feel scared about ruining a guitar pedal on your first try modifying it, I recommend trying this mod. Below is a simple (and very makeshift) circuit diagram for the modification.

CEM3340 VCO – My first proper synth module!!

Introduction to the project:

What the heck is it, and why build it?

Having been a huge fan of youtuber and musician Look Mum No Computer (Sam Battle), I’ve always been inspired to build some of his modular synth modules. On his website and Patreon, Sam has schematics for various modules that are very versatile and well designed. I decided to build his VCO module with additional PWM functionality. VCO stands for “Voltage Controlled Oscillator.” That means it creates a basic audio wave, and you can control its pitch by putting a voltage into it. PWM stands for “Pulse Width Modulation,” which is simply the ability to modulate or change the width of the square wave’s duty cycle. That just means that the square wave output can change the amount of time it stays high or low. While this concept is useful for powering things such as lights and motors, it also changes the sound of the square wave, making it musically useful. For a better explanation of what the heck PWM is, I’d recommend checking out this video by Afrotechmods. The 3340 VCO is a perfect starter module because of its multiple outputs for various waveforms and 1v/oct tracking meaning that it’ll stay in tune.

About two and a half years ago, before I was knowledgeable or experienced enough with electronics, I made an effort to build this module. Suffice it to say, I wasn’t really sure what I was doing, and didn’t end up succeeding. Recently when opening up a broken Simmons SDS7, I realized it contained 5 CEM3340 chips, the original and now rare component that was the source of sound for many legendary synthesizers. It was used in the Prophet synthesizers, the Oberheim OB-SX, the Roland Jupiter-6, and many more. This also happened to be the chip at the core of Sam Battle’s VCO module. I decided that I felt ready to build this module, as I had gained lots of experience and knowledge since my last attempt.

The build:

Materials!

First of course, I needed all of the components from Sam Battle’s plans for the module. This was easy, since all components were common values, and the only unusual one was the chip which I had 5 of already. The tough part for me to figure out was the panel that I would use for the module.

To find panels, I would need to know what size I would want it to be. Sam uses 10cm x 20cm aluminum panels which is his own modular synth format called Kosmo. Used in commercial modular synths, there is a format called Eurorack. However, Eurorack is a bit smaller than I like, and doesn’t use very round values. I decided that since Sam’s format is a bit too big, I would choose a middle ground – 7.5cm x 15cm. I now knew what size panels to look for.
Having tried using aluminum in the past, I knew that it can be hard to cut and difficult to drill into. I wanted a softer material. I was set on using ABS plastic panels for a while, but once I cut ones to size I realized an issue. Despite being great for drilling and cutting, the ABS was not sturdy enough to stay rigid when cables were plugged into the jacks. This means that I’d be ending up with a kind of floppy synth setup, which is not ideal. Guess what? Time for the middle ground again!! After talking to people on the discord server for the r/synthesizers reddit community, I found a perfect material that would be rigid enough but not too hard for drilling and cutting. That material was blank PCBs (circuit boards). I bought a pack of 5 or so 15cm x 20cm panels, and cut one into two 7.5cm x 15cm panels.
Perfect! We have all the materials we need to get started!

Soldering!

Above is the stripboard layout Sam has on his website. This is what I followed for the most part for my project. The only difference is along with some added capacitors for stability, I also added a 5k potentiometer in series with the tuning potentiometer as a fine tuning control. For the most part, soldering up the circuit was very straight forward. The only parts that took some tweaking was the layout, since I prefer using protoboard over stripboard. This means each hole isn’t connected to any others, and therefore needs to be manually soldered more. This does mean more work, but also means more control over layout and more space efficient circuits.

Hooking it all up!

After a quick drilling and labeling session, I could hook up all the jacks and potentiometers and give it a test!! Luckily, it worked wonderfully! I didn’t have a chance to paint over the bare copper on the panel, but I might keep it unpainted. I’m kind of fond of the slightly oxidized copper.

The finished product!!

Here’s what it looks like! The copper has oxidized much more than expected, so I plan to paint the panels to avoid this issue.

A quick video demo:

RT-Ramblings