I thought it was about time to give an update on the MIDI ping pong table sensing stuff. I’ve spent quite a lot of time on it, been through a few iterations of the hardware, and learned a lot! I started this as a total newbie as far as analog electronics go (Op-amps etc) and now I think I have at least grasped a few basic techniques. I’d like to try to share the lessons I learned, but I’ll warn you now that you’ll need to be quite interested in this stuff to get through this post :o)

Going back to the start, my first sensing attempt was to use piezo sensors and an unbuffered inverter (4069) as an amplifier (an idea picked up from Nicholas Collins’ book ‘Handmade Electronics Music’). I fed the amplified signal into a Darlington transistor which I hoped would give be the logic “hard edge” signal I needed for my timing code. The result was very sensitive, however there were a few things going on that I didn’t understand (sometimes the output of the transistor seemed to oscillate without any input). At the time I seemed to be picking up a lot of electrical noise and became convinced the amplifier circuit needed to be closer to the piezo sensor.


At the time I didn’t fully understand the reason for the digital input state flipping about like this and could only assume it was some kind of high frequency harmonic component of the actual vibration being picked up (now I know better… see below). However I needed to do something about it so that my microcontroller code would have a decent length pulse it could detect reliably. I added a 555 circuit configured as a “retriggerable monostable” (this was something I read about online). Basically once the first ON pulse come into the 555, no matter how fleeting, the 555 will hold the output HIGH for a controllable timed period, so all the spurious follow-on pulses are masked and we don’t need to care about them. The output became nice and clear for the interrupt pins on the MCU and worked reliably.


Then I started focusing on the triangulation code and noticed occasional inconsistencies in the sensor timing readings, which I became convinced were due to the differential input levels at which each sensor fired. This  makes sense because the “front” of the sound rippling out over a table top is not a hard vertical edge, but rather a slope, with the vibrational displacement ramping up from zero to to its maximum as the wave passes under the sensor. The level at which the sensor “triggers” will depend on its own sensitivity level, but not all 4 sensors will have exactly the same trigger levels. Now, since the speed of sound in dense wood is very high, a small difference in trigger level might translate to a big difference in the calculated position. Damn!

I was helped here by Matt Waterman, who got in touch with me via my blog and suggested using zero crossing detection as a solution to this. My understanding here is that once the initial wave front passes the sensor and triggers it, the vibrational displacement will reach a positive peak, then fall down to to zero, then reach a negative trough before repeating. At some point the displacement it crosses the “zero” value, and this is a distinct point in time which can be detected without the same sensitivity difference issues (since we’re comparing positive level with negative level, not two different positive levels, this can be detected more accurately). Since the positive wave front should have the same front-to-back width across all the sensors, the zero-crossing time measurement should be just as suitable for my purposes as a hypothetical perfect  measurement of the arrival time of the wave front (becaise we’re working with relative time of arrival at the sensors, not the absolute times of arrival)


After more headscratching, Googling, breadboarding and staring at my old CRT oscilloscope and a USB logic analyzer, I tried putting a Schmitt trigger inverter IC in there and Hey Presto!… a perfect clean pulse.

Now if I’d done this before I would have reached for the Schmitt trigger IC right at the start, but this is all a learning curve, and this was one of the most useful things I learned: When forcing an analog level to a digital level use a Schmitt Trigger! All I’d ever used them for was to make oscillators (like Ray Wilson’s excellent WSG noisebox)

So how does the Schmitt trigger IC help? Well a trace I got from my USB logic analyzer showed what was going on… Think about an analog sine wave being forced to a digital pulse wave. Now, if you simply connected the analog level to a digital pin you’d expect that above a certain threshold the digital level is HIGH and below the threshold the level is LOW right? This is mostly true, but the problem is that round about the threshold level, on the up or down slope, the digital value goes crazy… it flips *really* fast between HIGH and LOW because its in a “grey area” – it really doesn’t know if it should be HIGH or LOW and tiny fluctuations and noise push it one way and the other. This goes on until the input voltage changes enough to get out of this fuzzy “no-mans land” range and we get a stable HIGH or LOW

 However, stick a Schmitt trigger in there and there now there are TWO thresholds – one for the rising level and one for the falling level. In the no-mans land between the two, the output of the Schmitt trigger does not change. The result is a nice clean LOW – HIGH – LOW transition. The grey area is gone.





The Nano drives a set of diagnostic LEDs – 8 green LEDs representing the sensors and 2 red LEDs which light when there is a misread (not all sensors firing together on that side of table). The coordinate is mapped into an 8×8 grid and sent out as MIDI using the following encoding method:

MIDI note = 16 * row + col

where row and col are 0..7

The two sides of the table are split into two different MIDI channels. These are to be fed into a second Arduino which does some processing of the raw notes to create a more interesting set of MIDI notes and controllers based on some “intelligence” about gameplay (e.g a “rally” is made up of notes alternating between 2 sides of the table and finishes when there are 2 bounces on the same side or no bounce for a timeout period). The MIDI output from the second Arduino will be used to drive a synthesizer to create the eventual sound of the game.
