Thursday, 23 February 2012

Playing with MIDI ping pong table

Will and I trying out the sensing and early version of MIDI handling on one half of the table.

Video by Will Nash. Will's site is at

MIDI Table Top Sensing...It's working!

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.

My second iteration used a proper op-amp (An LM358 configured for single supply) which was placed close to the piezo sensor. The circuit was still very sensitive but the "noise" problems thankfully seemed to have gone away. I tried feeding the output of the op-amp to a digital input pin on a PIC but I was finding that the when a pulse was detected the digital input would trigger not just once, but many times over microsecond timescales and this would cause problems for the code (e.g. pin change interrupt fires but the pin state does not seem to have changed)

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.

So by now I had an LM358 and a 555, plus a bunch of caps, diodes and resistors, that I wanted located right up close to the piezo sensor. I decided to make the circular surface mount boards shown in a previous blog post. I suspected at the time they might be a bit over-engineered, but as long as they worked I didn't care.

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)

To work with zero crossing I had to remove the 555 from the circuit (since this masked all the input after the initial wave front triggers the sensor, including the initial zero crossing point). I added an LM339 comparator configured for zero crossing detection (based again on internet research), so the Arduino needed to receive digital inputs from the initial pulse (The Op-amp output) and the zero crossing pulse (the Comparator output). The first zero crossing trigger after the wave front trigger would be the point in time we'd be interested in. With the 555 gone, I was of course back with the issues of the crazy pulse trains that it had been  hiding from me... Double Damn!

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.

With a Schmitt trigger, the zero crossing worked! And it worked even with a long wire between the Piezo sensor and the op-amp, so I could put all the electronics on a single board and for all sensors. Not only that, but the direct Schmitt trigger output was now working just as well for timing as the zero crossing comparator output! Removing the comparator now simplifies the whole thing and halves the number of digital inputs needed to read the sensors. Result!

So, after that long journey I learned quite a lot. If you managed to read this far I hope it helps you too. I would also say never underestimate the value of an oscilloscope - even a  battered old CRT one like mine. For digital stuff a cheap USB storage logic analyser (I used a SCANLOGIC built from a 40 Euro kit) is also invaluable for seeing whats going on in that crazy world of the microsecond timescale.

So, my design now reads 8 piezo sensors (4 for each corner on side of a ping pong table). The sensors are simply wired with screened cable to a central amp box. This has 4 LM358 dual op amps (one channel per sensor) which are now on a 5V dual supply (from a nice board from Futurlec that generates a stable and noise-free bipolar supply from a single input supply). The op amp outputs go through a pair of 74HC14 hex Schmitt trigger inverters and from there to digital inputs of an Arduino Nano.

The Nano uses interrupt on pin change to simply flag the change of pin state, so that a flag can be polled instead of the port input (in case there is a rapid change and a signal is missed). There are two state machines running timing impulses from each side of the table, and the conversion of time-of-arrival information to coordinates is done using the fast approximation approach I described before.

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 8x8 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.

The note mapping scheme described above is (deliberately) the same as that used in the Novation Lanunchpad. Using MIDI-OX to route MIDI inputs to outputs, this means I can use a pair of Launchpads as a handy display to indicate the detected posiiton of a bounce. It also allows me to use a pair of Launchpads in place of the table while testing the MIDI engine on the second Arduino. I can just alternate pressing buttons on each Launchpad and it things there is a rally going on!

Wednesday, 8 February 2012

Digital POV clock working! mostly

Well, without too much pain, its just about working!

Here is how I went about it, which might help you if you want to make one yourself...

When you pick a drive to use, make sure it has four conductors going to the motor ("Y configuration") rather than three ("Delta configuration") if you want to use the TDA5140A/TDA5144 to drive it. The conductors are likely to be on a tiny flexible ribbon going into the motor on the back of the board.

Get yourself a proper Torx driver to take out the screws holding the drive together (you can work around it with other things but you will drive yourself crazy). Remove the PCB from the back, being careful not to damage the ribbon going to the motor. Remove the metal front cover, remembering that there are usually a few screws hidden behind labels. Less brute force, more patience :o)

Remove the head and magnets by taking out screws. Take out the central screw of from the hub and take off the platter. You might be unlucky and have a platter which sits very low to the backplane. You might need to improvise to jack it up a bit to leave space behind from the leds, or you could combine parts from a couple of drives (as I did) to get the best combination. Another thought is to cut windows for the LEDs in the aluminium backplane, but that seems like a lot of effort!

My replacement platter  was cut out of FR4 single sided copper clad board using a 70mm holesaw. A smaller holesaw (19mm I think) was used to cut out the centre, which was then filed to snugly fit the hub of the 2.5" laptop drive. The digits were actually laid out in EAGLE (PCB designer) since it was the only package I had to hand which let you type in rotation angles for characters. This worked OK, but a decent vector drawing package will have more interesting font options. The platter was etched just like a PCB.

It was challenge to fit LEDs and section dividers in the few mm of room behind the platter. My solution was to use SMD components and mount them on flexible kapton copper clad board (awesome stuff) which I picked up on eBay. Just press and peel and etch it as a normal PCB. The finished result, with components on, is only a mm or two in height and can be shaped with scissors and a knife, then glued down in the space under the platter. I made the light dividers from a bit of card cut with a knife and glued to the flexible board.

To index the rotation I used a reflective surface sensor (Osram SFH9202) which detects the passing of  a piece of white paper stuck to the back of the platter. I used a strip of matt black insulation tape to give decent contrast on the rim of the platter (FR4 is a bit shiny).
I was a bit worried that the sensor seemed to be getting hot. I am still not convinced this is right, but looking at the data sheet they do dissipate 80mW, and I tried 3 of them and they all did it, so maybe this is right (it hasn't blown up yet!)

The sensor output is quite "analog" and doesn't, by itself, give a nice sharp switching signal. I should have shopped more carefully since Osram do the same sensor with a built in Schmitt trigger output. Still, I had some CD40106  Schmitt trigger inverter chips so I used one of those to give me a clean logic output and it seems to work fine now.

The main board was designed in EAGLE and etched on SRBP using some cheap toner transfer film from a chinese ebay shop. This film is great! it works better than the much more expensive press'n'peel blue and seems less fussy about your ironing technique (i have none). Another first was to etch this with Hydrochloric Acid and Hydrogen Peroxide mixture rather than Ferric Chloride. It is very fast and resulted in less erosion of tracks under the toner, but it also resulted in a nasty lingering chlorine smell pervading the house.

I really enjoy working with SMDs these days, but I used to be terrified of them. Those tiny surface mount components have many advantages: They tend to be cheaper, your boards can be much smaller and need less drilling, and the result is actually really satisfying. I'd say the most important things are magnification (I use a 10x  loupe) a decent iron with a small tip (e.g. 0.4 or 0.8mm needle tip), fine solder (e.g. 0.015"), tweezers and a flux pen. Most important of all is practice and expecting it to all go wrong at least a couple of times before you get on a roll with it. Then you'll never look back :)

I'll admit I used solder paste for a couple of the components (the LEDs and their resistors, the two tiny resistor networks, the 16MHz resonator for the Atmega328). I used a hot air tool to reflow the paste. Everything else was done with an iron. The LEDs, resistors and small caps are 0805 size.

I have a small stock of M41T100 realtime clock chips in SOIC8 packages (from an ebay bargain) and I used one of these on this project, with a backup battery.

The MCU is an Atmega328 set up with Arduino bootloader. The code is all Arduino stuff. The Arduino drives the LEDs through a ULN2803 transistor array, since these LEDs are powered in groups of 3 and draw something like 30mA each, which would be too much to drive directly from the Arduino digital output pins.

Last but certainly not least, the hard drive motor is driven by a TDA5144. A word of warning - Don't think you can put power to a hard disk motor and it will spin. These are brushless motors and need electronics to make them work. If you want to try any HDD motor project I recommend you invest in a special IC for it. The Philips TDA5140A and TDA5144 have been perfect for the job in my experience (The TDA5140 - without the A - seems more finicky to get working). You can certainly make your own brushless DC motor controller, but that is a project by itself and I prefer to jump in with the fun stuff :)

Something I was glad I did was to add isolation jumpers to the board so I could power up the Arduino stuff without the motor starting, and vice-versa.

Code and EAGLE files can be found here

Wednesday, 1 February 2012

POV Digital Clock on 2.5" HDD Platter

Just starting this project, which again uses a 2.5" laptop drive.

Last year I made a POV "slot" clock on a HDD platter, inspired by other peoples projects I saw online. Around the same time saw an excellent project on YouTube where someone had made a digital POV clock by spinning a set of digit-shaped windows, in front of a row of LEDs. By illuminating each LED when the appropriate digit was in front of it, a row of digits can be displayed... aka a digital clock (

That project used a 3.5" drive and it looked like the digits were actually laser or plasma cut into the metal platter itself. I decided to make an easier version by etching the digits into a piece of FR4 copper clad board to replace the platter. FR4 (the fibreglass PCB backing material) is quite translucent so it should transfer the light nicely from LEDs placed behind it.

So far I just have the platter made. I am using a 2.5" laptop drive and the space behind the platter is very limited, so I will probably place the LEDs on flexible kapton copper-clad sheet and put a row of windows cut in plastic sheet over the top to stop cross-illumination.

I'll spin the disk using the same TDA5144 circuit I used in the previous project but I'm not sure about indexing yet... there is not really space on the platter to cut a slot for a photointerrupter, and a magnet on the disk (for a fixed hall sensor) would need a counterweight and might not fit. I might try an IR reflective sensor here, but need to play with them a bit first as I've not used them before.

Keep ya posted!

POV Fun With 2.5" Hard Disk Drives

I picked up a few faulty laptop drives cheap on ebay to take to bits and use for POV projects. I haven't finished them yet, but have been tinkering over time and will post my progress as I go.

For the first one I wanted to put a row of SMD LEDs on the platter itself (or at least on a bit of PCB replacing the platter). The problem is powering the thing... I still need to play with inductively coupled coils for power transfer, but for now I decided to use batteries.

With CR1216's and 1117 regulator

I started with a couple of CR1216 cells in holders - they balanced pretty well when the disk span up and it didn't vibrate too much. Unfortunately when I built up the rest of the circuit I hit a problem.. the LEDs would start up fine but after a few seconds they had faded down to nothing. Fresh batteries - same thing.

CR1216's are 3V lithium batteries (putting out about 3.3V) so I had a 1117 5V regulator on board to give me 5V for the PIC16F688 and the LEDs. I wondered if the current draw was reducing the battery EMF right down below the drop-out voltage of the reg so basically nothing got through the regulator. However when I removed the regulator from the circuit exactly the same thing happened. I guess CR1216's just don't have the oomph for running these high power LEDs :o(

Then I removed the CR1216 holders and put a couple of LR44 holder in their places. LR44's are alkaline button cells at 1.5V and they are a bit bigger than the CR1216's so I worried a bit about their mass on the spinning disk, but it seemed I could get away with that and they didn't fly off or anything (well, maybe just the once..)

The other concern was the lower voltage. I would get 3V instead of 5V to power the LEDs, so would they light properly? They did :o) However, the 3144 hall-effect switch I was going to use for indexing needs 4.2V minimum so I could not use that. Therefore I am currently able to get some pretty, but not stable, patterns while I wait for some new hall switches to arrive (with 3V minimum supply).

With LR44's and reg removed
Once I have the new hall switch I should be able to index the position of the disk using a magnet fixed below it, then I want to display text on the platter. This is really a test... the PIC doesn't have the memory to do much and the batteries probably wont last that long, but I hope to make another with external power (either with a brush to the back of the platter - there is continuity through the hub which makes that easier - or by inductive coupling)

This clip shows it in action. The data is just a binary counter for something to display, but its pretty

From POV on laptop hdd platter