Taiko Synth - Phase 9 - Waveforms

Until now, the taiko drum pad was a simple piece of masonite on a stack of packing foam with some mouse mats on top. A single strike resulted in multiple signals and I suspected it was because of either the masonite resonating, or all the pieces bouncing up and down. I needed some instrumentation.

The first step was to tie the drum pad together in an attempt to hold all the pieces together. I cut a circular base from plywood, then used a hacksaw to cut the foam to match. The foam looks terribly jagged - I think it needed some kind of hot-wire cutter for that. I got some 1/4" shock-cord (at REI, this is what they call this bungee cord) and cord-stoppers (clips used to close up back-packs, etc), then I cut holes in the drum head, foam, and base through which to thread the shock-cord. The hardest part was punching holes in the foam and threading the cord through it. The drill won't cut; the foam just got all wrapped around the bit! Forcing a 1/4" rod through the foam worked pretty well, although it was sill nearly impossible to thread the shock cord through the foam. Once the shock cord was threaded and cinched up, I glued some 2x2s to the base so it didn't rock back and forth on the shock-cord and cord-stoppers underneath. I used Gorilla Glue, which is really strange stuff, attach the 2x2s. As it hardens it foams up like polyurethane and can be a big mess if you use too much. The last step was to attach the mouse mats to the top surface of the masonite with silicone rubber glue.

After all that, it was time to hook it up. I connected a mini stereo plug to the drum and plugged that into the input jack of a laptop running XOscope. This is a pretty neat program. The controls are pretty intuitive, but I'm not going to be able to get any useful amplitude data until I figure out some kind of calibration work-flow. The other thing I didn't do which I should have done was to put some protection on the inputs - I could have damaged the PC's audio circuit - or worse. Note to self: next time be more careful!


Here's a trace of a hard DON strike. Right click and open the graph a new tab to enbiggen it sufficiently. The green trace it the drum head and the blue trace is the rim. You can see that the green trace is clipped, but what I was looking for was how long it resonated for. This way I could know when to start listening for the next strike. The graph shows that the signal took about 75 mS to settle down.

The other thing we can determine is that the resonant frequency is 4/0.02125, or 188 Hz

What I see there is that the drum head needs more damping. I want a single bounce - like when you push down on the fender of your car to see if the shocks are shot.


Below is a plot of a softer strike; one that 's not clipped. From it we can obtain the damping coefficient Tau, or the time it takes for the sine wave component to decay to 0.27 times its origin amplitude. It looks like Tau is about 0.017 Seconds.

The other thing I see in this plot is cross-talk. Striking the center of the drum results in a signal on the rim sensors. Cross talk's roughly (0.25/3.5)*100% or 7% and that's not too bad.


Tapping on the rim shows a quite different crosstalk story. Here the cross talk is (0.5/1.2)*100% or 42%. Something will need to be done to improve this. I think I many need to cut a slot in the foam to separate the rim from the drum pad center, but I'm concerned that the remaining foam will be too thin to support the rim. Maybe the foam will need to be replaced by a stiffer elastomer.


From this base-line data, I'll be able to see if changes I make to the construction of the drum pad improve or worsen its performance.

Ardunino-based AA Battery Tester

I've been a big believer in buying products that use AA rather than proprietary batteries. One advantage of AA batteries is that if you use up all your rechargeable AAs when traveling, you can alway find alkaline batteries in a convenience store. Also, if all you devices use AAs, you only need one charger.

On the other hand, a disadvantage of AAs is that because of NiMH technology, and the shape of the cells, their total energy density is less than Li-ion batteries.

When using NiMH cells, a problem with I've encountered occurs when one of the four cells in the pack is bad. With a fully charged pack in my camera, I've been out of power after only five pictures because of one bad cell. Even if all all cells are good, it's best to match cells with similar characteristics. This was the purpose of this project. Yes, one can buy a battery tester, but its so much more fun to do it yourself!

My goal was not just to test the batteries as a set of four, but to get discharge data from each cell. I've seen some projects in which the battery pack is tested by connecting a power resistor and a clock to the terminals. The idea is that the when the battery is discharged, the clock stops, and you can make a calculation of battery capacity from that. There are two problems with this. One is that the battery isn't discharging at constant current, so you can't accurately compare your results to the battery's capacity rating. The other problem is that fully discharging an NiMH battery below 1 volt per cell will damage it. If you test in this manner, each subsequent test will result in worse performance.

The first step in the project was to do a little research on NiMH Batteries. I found a good reference in Sanyo's Twicell battery manual. Here are some of the more useful facts about NiMH batteries.

If you discharge the battery below 1V/cell, the cell can undergo a polarity reversal (!). This would cause the battery (a battery is a group of cells) voltage to drop suddenly. To give the cells a margin of safety, I limited discharge to 1.1V/cell.

The typical test discharge rate (It) is defined as the current at which the battery would be drained in one hour. Thus, a 2800 mAh (milliAmp-hours) battery can be drained at 2.8 amps. That would dissipate if a lot of power! I decided limit battery drain to 1 amp - a nice even number.

Here's the circuit:

The schematic is a little hard to read in the blog. You can right click it and open it in a new tab to enbiggen it.

Here are the circuit details.

Current is drained through an LM317 three-terminal voltage regulator. It's configured for constant current mode with eight 10 Ohm 1/2 Watt resistors. Since full discharge current passes through these resistors, they must be big enough to dissipate that power. Increasingly higher rates of discharge can be selected as each of the switches are closed.

S1           => 1.2 Volts / (10 Ohms / 2) = 0.24 Amps
S1 + S2      => 1.2 Volts / (10 Ohms / 4) = 0.48 Amps
S1 + S2 + S3 => 1.2 Volts / (10 Ohms / 8) = 0.96 Amps

I only used the maximum discharge rate because any less results in a long test time. At the lowest setting, a full discharge can take ten hours.

One curious thing you may notice about the circuit is 1 ohm, 10 watt resistor. That's there because of the possibility of the maximum battery voltage exceeding 5 volts. Rather than attempting to measure the voltage of all 4 cells directly, the voltage is dropped 1 volt when draining the cells at 1 amp. In this way, the Arduino's maximum analog input is not exceeded. It does make calculation of the cell four's voltage a little strange-looking, though.

VB1 = A0
VB2 = A1 - A0
VB3 = A2 - A1
VB4 = A3 - A2 + (It * 1)

To convert these values to voltages and perform the calculations I imported a floating point library. In this way I was able perform the calculations and format the output directly to so that could be used by a plotting program such as GnuPlot. To use the tester I charged the batteries using the same charger that I travel with. I transferred the batteries from the charger to the tester. The tester was plugged into a laptop running a Putty terminal which logged all the output to a file. When "g" was typed at the keyboard, D7 went high, closing the relay and discharging the cells. If any cell reached less than 4.1 Volts, D7 would go low, stopping the test. From the saved data, a discharge profile could be plotted:

Several problems were encountered with the first version of the battery tester. The first was heat. I didn't expect that I'd need a very large heat sink on the LM317 since it was only dissipating four watts. I was wrong. My rule of thumb is that if a component is so hot that you can't hold your thumb on it, the component needs more cooling. I first tried adding a small 5 volt fan to the heat sink, powering it off the laptop's USB port. This cooled the LM317 sufficiently but made an annoying sound I suspected it was causing electrical noise that was making the battery readings erratic. I clamped ferrites on USB cable, but that didn't improved the accuracy of the measurements, so I removed the small heatsink, and installed the big heatsink you see in the photo. That took care of the temperature, but the measurements were still unstable. It turns out the source of the problem was the instability of the 5 volts supplied from the laptop via USB. A check of the Arduino's Vref pin showed that the voltage was varying all over the place. The solution was to use an external power supply to power up the Arduino, so the Arduino's regulator could provide a stable Vref.

I've not done anything with this project recently, so I wanted to document everything. When I'm ready to start again, I won't have to start from scratch!

Taiko Synth Now on Git Hub

I promise I won't post anymore long strings of code within the blog.

You can retrieve the code for this project at:

https://github.com/umeda/taiyouden/tree/master/Projects/Taiko_MIDI

Taiko Synth - Phase 8 - Two Channels

On a taiko drum, in addition to striking the head (ドン) you need to be able to play rim shots (カラ). To make a rim, I cut a gap into the masonite. The rim needed to be as wide as a piezo sensor. I used GE silicone adhesive to fasten the piezo sensors to the drum head and rim, then wired each set in parallel (observing polarity) and then to a connector on the rim. I had to change the Arduino/nunchuck interface a little to handle two channels efficiently. That may be the subject of a later post.

In this new configuration, I seem to have trouble with single hits being detected as multiple. Reducing the number of sensors on the head helped. Also increasing the padding on the head of the drum helped. I bought a bunch of mouse mats for that purpose. Still, I think either the masonite board is resonating, or, more likely the board is bouncing up and down on the foam. The best fix I can think of for this is to glue them together, but if I do that, I will no longer have access to the underside of the head, so making changes is going to be difficult.

Anyway, here's the result:

Taiko Synth - Phase 7 - Basic Improvements

The volume is now proportional to the hit - although I do need to scale it for better dynamic range. Initially I did the scaling like I would in any software application:

outputValue = inputValue * maxOutput / maxInput

The problem is that Arduino only deals with 16 bit integer math. Anything over 32767 is a negative number. By multiplying first, it went over that value so I was seeing negative volume values when I hit the drum hard. Since maxOutput and maxInput are constants with a ratio of about 5, I re-wrote the formula as follows:

outputValue = inputValue / 5

More work needs to be done on scaling; the detection threshold needs to be lower, a peak indicator LED is needed, and I want to be able to use the nunchuck to adjust the sensitivity. The nunchuck is running out of controls, so I'll try to use the accelerometers.


I'm now running the synthesizer software on an HP 1000 mini running Ubuntu 10.04 LTS off of a bootable flash drive.The latency isn't as bad as before. The little netbook works pretty well. I read that there's a low-latency Linux kernel, so I may try that for fun some day.

I changed the synthesizer software is to FluidSynth (http://sourceforge.net/projects/fluidsynth/). FluidSynth needs a soundfont. It can use the General MIDI instruments which include Taiko (channel 117) and a bird (channel 123 - not so useful, but fun).

Here's where I got the sound font: http://packages.debian.org/search?keywords=fluid-soundfont-gm

Once installed, here's how to start everything.

./ttymidi -s /dev/ttyUSB0&
aconnect -i
aconnect -o
aconnect 129:0 a28:0
fluidsynth -c0 -r0 -r22050 -l -a alsa -o audio.alsa.device=plughw:0 FluidR3_GM.sf2

If you are troubleshooting, there's a -v parameter for verbose, that's helpful.



I installed Jack, a GUI device connector, and experimented with that, but I think it's easier to use Aconnect.

Here's a demo of the results:

How to Make a Decent Splice

Sometimes you need to shorten an existing cable by removing a section and reconnecting the two ends. Other times you might need to lengthen a cable by adding one or more sections. If you're doing this to a multi conductor cable, it's best to use the "Western Union" splice my grandfather taught me. This type of splice won't short-out (the condition in which conductors touch) if the insulation on your joint fails.

You will want to strip two to three times as much of the outer insulation as you normally would. On one end cut the red wire short, and the white wire long. On the other end cut the red wire long and the white wire short. Cut some heat-shrink tubing to go over the inner conductors. Also cut a larger piece to go over the whole thing, slide it over one or the other of the pieces of cable, and slide it well out of the way. Don't forget to do this, because after you've made the connection, you won't get be able to do get the heat-shrink onto the cable. Now cut some smaller heat-shrink tubing for the inner conductors and slide them over each of the longer wires. Make sure these are far away from the joint so the heat from soldering won't shrink them and prevent them from fitting over the joint.

Twist the wires together facing each other such that the joint isn't much thicker than the original wire. If you twist them facing the same direction (like a zipper), you might not be able to get the heat shrink over them, and if you do, the tubing will look like a python that's swallowed a pig. If the conductor is going to poke through the heat-shrink and cause a short, it's going to be where it's stretched thin over the big solder blob.

Like this:



Not like this:

Apply heat, then solder to the joints. After the joints have cooled, slide the heat shrink over them and apply heat. After that's cooled down, slide the large heat-shrink over the whole thing and apply heat to complete the job.

Time Lapse Photography - Phase 1

The first step was to get the hardware ready.

To find the power, focus and shutter switches on this old camera, I disassembled it screw-by-screw. I only shocked myself once on the flash capacitor. I thought I'd never get the camera back together. It might have been better to have ground away the buttons with my Dremel tool. The nice thing about this camera is that when connected to and external 3.3 v power supply it never goes to sleep. This way it doesn't lose settings like "no flash" and the lens does not have to be extended for each frame. If make a 10 minute movie, that would be 18,000 frames. I'd guess that's pretty much the life of that mechanism. Now I wonder about the shutter and focus mechanism. How long will it last?

To use the camera, first touch the two "on" button wires together.
To focus, hold the brown and blue wire together.
To snap a frame, touch the white wire to the brown and blue.


This is the board with four relays that I made. It'll control the camera with one relay to spare. I made it generic as possible. I think the Arduino could probably have driven the relays, but I used some 2N2222 transistors anyway. The funny thing about these relays is that they have polarity. I thought maybe they had an internal protection diode, but when I ohmed it out, it was about 120 ohms both ways. I read up on this type of relay, and I think the armature may have a magnet on it to reduce the current requirement. The bad thing about that is if you wire it backwards, the armature is repelled, and the relay won't close. The other thing generic about this board is that I kept the PWM pins in reserve using only the pure digital I/O pins. The pin numbers are going to be numbered funny in the firmware, but this way all the analog outputs are available if needed.