Build a Wearable, Real-Time Beat Generator
With a microcontroller, several sensors, and two 3D printed sensor boxes, Richard and Shiva built a wearable drumbeat generator. It takes only 700 ms from the initial box hit until the sound is output.
It’s Friday night and you’re hanging with your friends at home. There are no parties tonight and you have seen everything on Netflix already. You’re bored out of your minds. One of your friends pulls out his portable roll-up piano keyboard, and starts making random songs out of boredom. “Let’s make the next big hit, guys!” You all get excited. One of your friends sings along, making the lyrics as she goes. It’s starting to sound like a real song, but it’s missing a beat. You have the perfect idea of the drumbeat that should go along with the song, but all you have around you is two pencils. Luckily, with Drums Anywhere, you now have all you need to drop the beat for your song (see Photo 1)!
Drums Anywhere is an affordable electronic solution to making a great drum beat on short notice. Using two simple 3-D-printed boxes that you can attach to any stick-like object, you can strike any surface to instantly output the sound of drums through your speakers. Using a clap sound for one box and a snare drum sound for the other, Drums Anywhere can output the drum sound you want, even with accurate amplitude corresponding to the force of the hit!
This is an all-new design that costs a fraction of what a drum machine costs, and it brings an intuitive and extensible design to what was once a bulky and static setup. Drums Anywhere uses an Atmel ATmega1284P microcontroller and a variety of sensors and hardware to accomplish its purpose. The project also puts a spotlight on new, accessible technologies such as 3-D printing. This is the first revision of Drums Anywhere, and there is plenty of opportunity to extend this design to include more features, such as more sensors, drum voices, and perhaps a wireless design.
The project stemmed from a desire to make real drum sounds more accessible to all. Drum sets and drum machines are immensely expensive, and usually out of the price range for a regular music enthusiast who enjoys creating drum beats at a short notice. Our project brings together analog circuitry and filters with digital concepts, such as hardware timing, interrupts, and a user-friendly interface. We made a concerted effort to use as inexpensive parts as possible to make this system accessible to all. The system is as simple as possible: the user simply has to plug in speakers, turn on the system, and start drumming.
The ATmega1284P microcontroller has more than enough timing and computing power to keep up with the system to make the drum sounds real time (see Figure 1). We are able to program the microcontroller such that our system is robust and does not trigger multiple plays with one single hit. This is through knowledge of human abilities to repeat a hit to keep our system from unrealistically playing multiple hits in an unacceptable timeframe. This was a trade-off of using the hardware we used, as the likelihood of accidentally triggering unrealistic intervals for drums was greatly increased. We had to add extra complexity using timers to mitigate this issue, but the complexity was still well within the abilities of the microcontroller.
The user interface is one of the most important components of this project. We wanted to make our system as similar to a drum kit as possible. The user simply has to sit down, grab the sticks, and create the beat. When the user powers on the device, some initial setup occurs within the microcontroller, but this takes no more than 5 s. The system uses an industry-standard stereo audio plug, making it easy for the user to plug in any speakers they have, or even headphones if they want to practice alone. Once the user has plugged in some form of speakers, they can attach the boxes to whatever object they have around, including their hands if necessary, turn the system on, and start playing. The system is capable of running from a 9-V battery, making this system extremely portable.
The LCD serves very little functional purpose in this revision of the system, only showing the name of the system, the two voices corresponding to each box, and the microcontroller’s amplitude reading from the analog-to-digital converter corresponding to the most recent hit. However, it is useful for debugging and can be leveraged in future revisions for additional data visualization.
This project requires one sensor system for each drum sound the user wants to output, and it includes the flex sensor system, the microphone system, and a 3-D-printed holder box. The flex sensor system is used to sense a drumstick impact while the microphone is used to calculate the amplitude of the drum hit. The microcontroller software can be modified relatively easily to handle more inputs. The entire system can run on the 5-V VCC supply from the microcontroller, which is stepped down from a 9-V supply. We modified our op-amp circuits based on what gave us the most reliable signal for our use cases, as we will discuss further in this section. Future designs will include a smaller box for more compactness and versatility.
Figure 2 shows the system’s circuitry, including the schematics for all subsystems and how they connect to the microcontroller. For this project, we used a custom target board (available from course materials for Cornell University’s ECE4760).
Our sensor box is a 3-D-printed object that we designed in AutoCAD (see Photo 2). We created the box to be attachable via two 1″ Velcro straps and to have four small holes to handle each of the two wires required by the flex sensor and the microphone. The holes were made such that 26-AWG wire could fit through. We 3-D printed the box using Acrylonitrile butadiene styrene (ABS). ABS is a very strong plastic and is slightly flexible. This means that our box is strong and not rigid enough to break under strong force. The top two holes are spaced exactly to fit the spacing of the flex sensor headers. This enables us to solder the wire on the box surface and leave the flex sensor suspending. This enables the flex sensor a wide range of motion when the box is hit on a surface, and the flex sensor circuit converts the motion to a logic level quickly. The bottom two holes have small wires running through and are soldered to a microphone inside. The microphone is protected and attached to the box by electrical tape. This gives the microphone a small level of shielding against the sound from outside the box, enabling better isolation and making the amplitude readings more correlated to the force of the box rather than the surroundings.
We used a Measurement Specialties LDTM-028K flex sensor as the hit detector. The flex sensor offers us no numerical data and simply serves to inform us when a hit has occurred. As we mentioned before, the flex sensor is suspended within the box, and therefore has space to move around. The circuit that follows uses an op-amp with gain to trigger a large enough rising edge to trigger the microcontroller’s external interrupt. We used a noninverting op-amp configuration to apply gain to our signal. The op-amp has rail voltages of 5 V and ground. The gain for the circuit is given by:
By this equation, our gain for the circuit is 52. For the forces with which we hit the box, this circuit will saturate the op-amp at the top rail voltage and trigger a rising edge strong enough to trigger the microcontroller. After applying this gain, we send the input through a diode, so as to clean the signal of any negative voltages, and removing any voltages under the diode’s turn-on voltage. We then use a capacitor and resistor in parallel to have a peak detector. This peak detector acts as a filter for the signal, preventing multiple external interrupts to be triggered at once.
The microphone circuit is designed to give us a range of input voltage that we can use to correspond to a quantitative impact in the analog-to-digital converter on the microcontroller. We first take the output from the microphone and use a 100-nF capacitor as a DC block, so that we remove any DC from the signal. We then use a voltage divider to add our own DC signal to create a baseline for our sound. Using a 5.1-kΩ resistor and a 10-kΩ resistor, we get a baseline of about 1.7 V, which is added to the AC component from the microphone input. This will be important later in the circuit. From this voltage divider, we input the signal to a noninverting op-amp gain circuit. The gain of the system is 101, as we can see from the equation in the Flex Sensor section. The added capacitor sets the gain of the amplifier to unity under high frequencies, which allows the system to operate correctly for the microcontroller input. After the microphone signal is amplified, we send it through a diode. The 1.7-V step-up from the previous amplification stage is important now, as we know that our diode will be past threshold and will let our signal through reliably. This also helps us to get a cleaner signal input for our microcontroller, only having positive voltage.
FILTER FOR SOUND OUTPUT
In order to clean the output PWM signal from the microcontroller of any noise, we use a passive low-pass filter before we output the signal to the speakers (see Figure 3). We use a filter with time constant RC = 0.001, with a cutoff frequency of roughly 160 Hz. The sounds of a drum are very low in frequency, so this seemingly aggressive cutoff frequency is actually very suitable for our project. The filter shown in Figure 3 attenuates the sound appropriately. We use two of the filters, one for each of the PWM channels used for the sound output.
We wrote the code for this project to maximize modularity and encapsulation in order to allow easy extensions to this system. It also provides a way to isolate errors during debugging.
The code includes initialization of interrupts to capture flex sensor data from the drum boxes. It also enables the use of the microcontroller’s ADC to convert the analog microphone data into a readable amplitude. We code in a formula to translate microphone amplitude into a corresponding volume for the speakers.
Our code files also include the drum sound samples that were transformed from .wav files into C code. And finally, there is code to initialize and run the LCD and have it display a welcome message and amplitude data. We used interrupts instead of polling to capture sensor values with minimum system latency.
Each of our drum sounds are triggered by short external interrupts from our flex sensors to signify that our drum boxes have sensed an impact. Each interrupt service routine takes about 700 ms to run, and thus the drum hit to sound output appears simultaneous. To do this, the interrupt registers are set at initialization so that our drum sounds play on a rising edge from the voltage of the flex sensors (i.e., the flex sensors have been bent enough by an impact on our drum boxes to create a voltage spike similar to a logical 1, close to 5 V). When this happens, we can assume the drum boxes felt a significant impact and we play our drum sound. Competing interrupts are not an issue because interrupts are disabled while each interrupt service routine is still occurring.
We have also debounced our interrupts. The state diagram in Figure 4 depicts our debouncing method for multiple interrupts occurring at the same time. When the system senses an interrupt from the drum boxes and thus plays the drum sound, the microcontroller starts a timer that counts for 20 ms. The system does not accept the interrupts until the end of the 20 ms, a time period much too short for most humans to hit the drum box multiple times, but long enough for us to avoid voltage spikes due to noise during an impact.
We embedded microphones into our drum boxes to determine how loud our output drum sound should be. The stronger the drum box impact, the louder the sound is for the microphone. When a drum box triggers an interrupt for our system, the amplitude from the microphone is read by the system and mapped to a multiplication factor for our sound output described later. To determine a numerical value for the sound’s amplitude, we run the microphone’s analog output into the microcontroller’s onboard ADC. Although the ADC can only read from one port at a time and thus one drum box at a time, we set the ADC read rate at a high sample rate of 10,000 Hz so this is not noticeable to the user at all.
To simulate drum sounds, we use freely distributed drum sounds from across the Internet and Guilherme Kalfelz’s open-source converter, Wav2Code, to convert 8-bit audio sounds into C code that represents time samples of the amplitudes of the .wav file. The C code sound waves are then stored and read in from program memory. Another timer is set up in fast PWM mode to output to our speaker. We modify our PWM wave’s amplitude based on the stored sound waves to output the sound on the speaker according to the following equation.
While the denominator appears to be complex math, it is simply a mathematical model for a bit shift. Shifting the output based on a linear change in the input amplitude actually modifies our amplitude to model human hearing better, as human hearing reacts to logarithmic changes, not linear changes. This makes our drum amplitude changes more realistic. When the sound is finished playing, we use flag variables to signify that the system can resume and not act unpredictably.
Our system performs very well and has extremely low latency. Refer to our demonstration video to hear sample sounds: https://youtu.be/L7uffHvbQMk. As you can see from the oscilloscope trace in Photo 3, the system only takes 700 ms from the initial box hit until the sound starts being output. This includes the time it takes to trigger the external interrupt, switch the analog-to-digital converter to the correct port, perform the analog-to-digital conversion, and begin the sound output. This is well below the threshold at which human hearing can notice a distinct latency in the system, making our system very viable as a product.
The sound output was extremely clear. The boxes and their use of Velcro made for an easy-to-use assembly, and it is very versatile as to the objects it can be attached to. The Velcro we used was extremely sturdy, and sometimes unwieldy, but this would be easy to modify, as the box straps are capable of handling any type of Velcro that is 1″ wide or less. The amplitude response of the system acted as expected, and the system’s ability to display useful information to the user helps make the system more user-friendly. The wires and the soldering of the system are sturdy enough to stand up to the force of the drumming, and the use of computer speakers made it easy for the system to be adjustable for a variety of settings. There are certainly ways to improve the stability of the breadboard set up, but for most use cases we can say that our system performs very well.
FLEX SENSOR PERFORMANCE
The flex sensor and the circuit perform very well (see Photo 4). The flex sensor stays sturdily in the box, as we were able to solder the wire through the holes in the box, and the sensor remained suspended. This led to us having stable, reproducible results for flex sensor input. As you can see in Photo 4a, our raw flex sensor signal can be weak, noisy, and unpredictable. However, using our flex sensor amplification and filtration circuit, we are able to get the signal on the bottom, which produces a 3-V signal that only triggers when the flex sensor hit is hard enough. The 3 V is enough to trigger the microcontroller’s external interrupt reliably, leading to us having a very reliable and clean method of knowing whether the box has been hit or not. The diode in our circuit ensures that we do not have any excessive negative voltages going into the microcontroller. This is especially important because the flex sensor is capable of swinging the voltage either way as it settles, and too much negative voltage can cause major problems with the microcontroller. Our filtration part of the circuit is able to avoid double signals from the flex sensor effectively, as we can see in the bottom trace as well. The flex sensor was able to trigger hit signals for a variety of microphone amplitudes. This ensures that our system did exactly what we planned. We could confirm a hit with the flex sensor, and get variable amplitudes from the microphone.
MICROPHONE PERFORMANCE & ACCURACY
The microphone assembly performed very well for the range of hit forces that our system could be put through. The DC offset gave us a good baseline for the microcontroller to compare to. As we can see in Photo 5a, the microphone’s dynamic range was about 1.7 V, which gives us a good space for converting to digital values and converting them to realistic amplitudes. The microphone was isolated from outside noise well enough to be passable in a variety of environments. When testing the amplitude readings while directing noise directly at the microphone, we did find that the microphone was not as well-isolated as it could be, sometimes creating louder output than expected for the hit as a result. However, this could also be useful as a feature. Getting inaccurate amplitude readings like this required a lot of surrounding noise, and if the user is in an environment as loud as this, maximizing the output might be useful.
As you can see in Photo 5b, the microphone’s amplitude corresponded roughly to the eventual amplitude of the speaker output. The few microphone spikes with no speaker output (before the marked red impact line) are shown to demonstrate that microphone amplitude does not translate to a sound output when the flex sensor does not trigger.
The ABS plastic used to 3-D print the drum boxes were easily able to stand up to the force applied to them when hitting a hard surface, such as a table. This tells us that the boxes are resilient, as a table is the hardest surface that we expect the user to hit the box on. Anything softer, such as someone’s lap or a softer table, will also cause a drum beat, but will not cause as much stress on the box. After putting the assembly together, we found that the box dimensions were excessively large for the hardware we needed to fit inside. A second revision of the design could move the flex sensor higher in the box, making space for the microphone to fit below and enabling us to also solder the microphone through the side of the box, like the flex sensor. This constraint would enable us to cut the length of the box in half, and only require one Velcro strap loop, as opposed to the two we have currently. The boxes are functional, but not optimal.
The system overall performed as we expected it to. The latency of the system was less than a millisecond, and the output of the sound that corresponded to the box hit occurred virtually instantaneously. The output of the amplitude corresponded to the force of the hit in a very natural way. Our use of simple operations in the microcontroller code combined with the reliability of our sensors made for a robust system. The sensor boxes feel sturdy and accomplished their purpose very well. Our project accomplishes its purpose of making drum sounds available anytime, anywhere. This allows anyone, whether they are drummers, music enthusiasts, or anyone who simply wants a drum beat, to simulate the feeling of drumsticks with an inexpensive, simple assembly.
Using small quantities of the required parts, we were able to keep our costs for this system very low, especially during the development stages when we were experimenting with different sensor assemblies. We were able to save money on 3-D printing as well, as Cornell’s Rapid Prototyping Lab printed our boxes for free, since they were for academic purposes. Printing these commercially out of the same material would not be prohibitively expensive, as our box could be printed for $5 in its current form. This cost could be minimized with a redesign as we discussed earlier. With or without the free boxes, however, our project is significantly cheaper than any drum machine in existence, and takes a unique approach to creating real drum sounds at short notice.
One other advantage to our project is the extensibility. We are currently using external interrupts on the microcontroller, of which there are only three on the board. However, we could easily use pin change interrupts for the same purpose, of which the microcontroller has 32. This enables us to add features to the system like enabling a box that you can place on your feet to simulate a bass drum. This easily could be accommodated by the memory of the microcontroller as well, as our current storage of drum sounds does not use more than 10% of the microcontroller’s internal program memory. This would enable us to add many more drum voices and a button-based interface to change the voices corresponding to each box.
We would have liked to clean up our breadboards and use more efficient layouts. Currently, we only use one side of each op-amp PDIP. Consolidating this assembly could halve our number of op-amp PDIPs and let us use one less whiteboard. In addition, our project would be more optimal with a smaller, rearranged box, but this would be an easy fix, as we have a much better idea of how to fit the parts together now.
We would like to thank Cornell University Senior Lecturer Dr. Bruce Land for the use of his lab, his electronic parts, and his version of an Atmel ATmega1284 target board, which was essential for our project. We also thank him for pointing out a simple fix when we were struggling to remember basic concepts. ECE4760 was an excellent class, and we enjoyed it immensely. We would also like to thank ECE4760 teaching assistant Syed Tahmid Mahbub for helping us through the sound output section of the lab, as his advice to use onboard sounds greatly simplified our design and created higher fidelity drum sound output than we would have been able to synthesize. Lastly, we would like to thank Guilherme (William) Kalfelz for the WAV2C program we used to convert our drum sounds into char arrays. His program made our project much easier and it sped up the development process immensely.
Atmel, “ATmega1284: 8-Bit AVR Microcontroller with 128K Bytes In-System Programmable Flash,” www.atmel.com/images/doc8059.pdf
CUI, “CMA-4544PF-W: Electret Condenser Microphone,” 2013, www.cui.com/product/resource/cma-4544pf-w.pdf.
B. Land, ECE4760 Course Website, Cornell University, http://people.ece.cornell.edu/land/courses/ece4760/.
———, “Prototype Board for Atmel Mega644,” 2006, http://people.ece.cornell.edu/land/PROJECTS/ProtoBoard476/.
G. Kalfelz, Wav2Code Library, www.wusik.com/arduino/Libraries/WAV2Code/.
Measurement Specialties, “LDT with Crimps Vibration Sensor/Switch,” LDT0-028K, 2008, www.meas-spec.com/downloads/LDT_Series.pdf.
Texas Instruments, “LMx58-N Low-Power, Dual-Operational Amplifiers,” SNOSBT3I, 2014, www.ti.com/lit/ds/symlink/lm158-n.pdf.
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • MARCH 2016 #308 – Get a PDF of the issueSponsor this Article
Richard Quan is studying toward a Master’s degree in Computer Science at Cornell University, and will be joining American Express in New York after graduation. His interests include automation, systems engineering, security, and software design. He is an executive board member of the IEEE student chapter at Cornell, and has interned at NASA and General Electric.
Shiva Rajagopal is studying toward a Master’s degree in ECE at Cornell University, and will be joining Fitbit in San Francisco after graduation. His interests include firmware engineering, computer networks, computer architecture, and computer security. He has interned at Microsoft and Tesla Motors, and has worked for two summers at the National Youth Science Camp in West Virginia.