Archive for April, 2007

Making Googly Eyes, Part 1: Reverse Engineering

Monday, April 2nd, 2007

Back in mid-February, I wanted to demonstrate motor control with the LogoChip to class, but it’s hard to see what a motor is doing unless it’s geared down and attached to something. I decided to make googly eyes that could look around, and here’s how I went about it.

Motorized googly eyes

CD Read Sled

Although the motion of each individual eye is rotary (right to left; these can’t look up and down), to synchronize their actions, I needed linear motion.

Digression: Predator species have eyes on the front of their face, to triangulate the distance to their target. Prey have eyes on the sides of their heads, to keep the widest possible view of their surroundings and watch out for predators. Predators’ eyes generally move in synchronization. Of course, they may look slightly inward when watching a nearby object (binocular convergence; think of looking cross-eyed at your nose); but for a simple model like this, two eyes always looking in exactly the same direction is adequate.

I figured my best shot was something from a dead CD-ROM drive, so I went down to examine my stash. What I call the read sled assemblies looked the most promising–they’re the ones that move the read head in and out along the radius of the disc to find the right position to play. The tray motors might also work, but the trays have a good 5″ range of motion. The ∼2″ range of the read sled seemed much more useful.

Several of the assemblies I examined used a stepper motor, but I wanted to demonstrate a simple DC motor, so I kept looking. Finally I came across this one, which had a DC motor (on the underside), a nice geartrain, and an optical encoder (the faint grey circle between the green PCB and the medium black gear) to determine the position of the sled.

CD-ROM drive read sled assembly

The motor was mounted from the back side, and the optical disk was press-fitted to its shaft.

CD-ROM drive read sled assembly, reverse

Reverse-Engineering the Optical Assembly

I was interested in trying to reuse the optical assembly so that I too (well, my program) would know where the sled was, so I desoldered the flex pcb ribbon cable and set about figuring out the connections on the PC board.

Optointerruptor and interface PCB

The larger black rectangle that overlaps the optical disk was obviously an optointerruptor–one side has an LED and the other side some kind of optical sensor. When a hole in the disk passes between them, light is transmitted; when a bar passes between, the light is interrupted, and the receiver can tell the difference.

The two smaller black rectangles (southwest of the screw head) are surface-mount resistors, reading “181″ (180Ω) and “752″ (7.5KΩ). I could visually follow some of the traces (the light green lines) on the board, but I got lost with exactly what happens underneath the resistors.

I assigned numbers to the five solder pads from the cable, arbitrarily numbering from the outer edge of the board. (In retrospect, that was incorrect–the pad to the left in this photo is shaped differently than the others; that makes it pin number 1. Ah well.) Then I made this table (actually edited here on my blog–all the notes have been sitting around for six weeks, and it’s only the narrative that I’m adding later) describing where each pin went, to the best of my visual acuity.

Pin Connection
1 motor black wire
2 motor red wire
3 interruptor
4 interruptor end of 7.5KΩ resistor
5 both resistors

Pins 1 and 2 obviously run to the motor, and it was pretty clear that they didn’t have any connections to pins 3-5. So I used my ohmmeter to measure the resistance in each direction between each pair of pins out of 3-5. I got this:

4 → 3: 50KΩ
3 → 4: ∞
5 → 3: 40KΩ
3 → 5: ∞
5 → 4: 7.5KΩ
4 → 5: 7.5KΩ

It was obvious that pins 4 and 5 were connected directly via the 7.5KΩ resistor. It was also apparent that there were diodes from pin 4 to 3 and from pin 5 to 3. That gave rise to this diagram:

CD read sled connection diagram, reverse-engineered

Which made a lot more sense once I redrew it like this:

CD read sled connection diagram, redrawn

Pin 5 is the supply voltage, pin 3 the ground, and pin 4 the readout of the voltage divider between the 7.5KΩ resistor and the photosensitive diode. Voila!

Using the Optical Encoder

A 180Ω current-limiting resistor with a 5V supply would give ∼24mA of current through the LED, and that seemed a little high. I’m guessing that part of the circuit ran on 3.3V, making the LED current ∼14mA–a more reasonable value.

I wanted to shoot for 15mA, so 4.3V / 15mA ≅ 290Ω, of which 180Ω was already in the circuit, leaving 110Ω to add. I had a 120Ω resistor in my bin, so 4.3V / (180Ω + 120Ω) ≅ 14mA, which was close enough. I used the 120Ω resistor to wire pin 5 to the 5V supply, placing it in series with both diodes. (I figured its impact on the 7.5KΩ resistor and photodiode whould be negligible.)

Turning the encoder wheel very slowly and carefully and reading the voltage at pin 4 yielded a minimum voltage of .77V and a peak of 3.4V. (Alas, I don’t remember which was when the light was blocked and which when it was passed . . . probably the photodiode conducted and pulled it down to .77V when light was passing . . . but I don’t know that I really care.)

I didn’t really want to have to use an A/D converter input and deal with a 10-bit numeric value when all I needed to know was whether the light was blocked or passing. But I wasn’t wild about feeding a continuously varying analog voltage into a TTL input–it tends to make them overheat. Happily, the PIC datasheet (p. 102) revealed that pin A4 has a Schmitt trigger input, and my problem was solved.

A Schmitt trigger has hysteresis–the input signal has to rise above a certain point (the “high-water mark”) before it reads high, then fall below a lower point (the “low-water mark”) before it reads low. It’s intended for reading digital values from analog signals, it was exactly what I needed, and it worked exactly as desired. I fed the optointerruptor signal into A4 and got clean, predictable digital results.

Next Steps

That’s probably long enough for one post. Next: Building the eyeball assembly and programming the motor.

Piezo Elements for Percussive Input

Sunday, April 1st, 2007

Harry Partch and Piezo Instruments

Lauren Hirsh, a WSU percussion student, WSU Internet radio goddess, and all-’round CRATEL regular, is involved in a performance of Harry Partch compositions this spring. Partch composed for new instruments he created, and the percussion department is attempting to build at least one or two of them for the concert. Lauren is taking on the task of building one, I believe the boo.

The boo is a marimba-like instrument made from tuned bamboo tubes arranged in six ranks. Rather than try to reproduce the tonal qualities of the original instrument through physical means, consideration is being given to building an input interface and using electronic reproduction of the boo sounds. In other words, Lauren wants to build a synthesizer keyboard shaped like a marimba. And several of us involved in CRATEL are intrigued by the challenge.

Tom McGuire has done all the work so far. He got a piezo element and hooked it up to the LogoChip. When you strike it, it generates a voltage; he’s working on capturing the voltage in a capacitor until the LogoChip can come along and poll it. The capacitor doesn’t have a drain resistor; he’ll turn the LogoChip port into an output at 0V after he’s read it, to drain it manually. In other words, he’s making a piezoacoustic version of the CCD camera. Brilliant!

Here’s a picture Tom sent of the element attached to a PVC faux bamboo tube:

Tom McGuire's piezo element interfacing


Tom has a few piezo elements, but maybe not enough for the whole instrument (even though Lauren only wants to construct a couple of ranks). But tonight, I mentioned the situation to my friend Joel, and he rooted around to bring out four boards with a dozen piezo elements each, which he’d be happy to donate as long as they don’t all get used up.

Piezo board, back

Each piezo has a rubber-covered button stuck onto the front–Joel thinks they may have come from an ATM or some other heavy-duty input system. It doesn’t feel like they can be removed easily, and I don’t know whether that will prevent them from being useful.

Piezo element, knob on front

Worse, they’re a bit corroded, and trying to remove the silicone that holds down the wire tends to rip the foil right off the back. I don’t know if there’s enough salvageable here or not, but I wanted to post the pictures to let Tom have a look.

Piezo element, back, torn

One I haven’t torn yet:

Piezo element, back

LED Gloves

Sunday, April 1st, 2007


Steve Wilson is a graduate student involved in WSU’s CRATEL (Center for Research in Art, Technology, Education, and Learning) program, and his video synthesizer was sponsored for further development in last year’s BETA (Bridging Entrepreneurship, Technology, and the Arts) competition.

One of Steve’s challenges for his video synth, and an interest in general, is creating expressive interfaces to electronic instruments. He describes it in a post to the Technology: Art and Sound by Design class mailing list. Basically, it comes down to the idea that acoustic instruments offer an immense amount of control over the sound that comes out through physical manipulation, and electronic instruments tend to offer much less control, and through mechanisms mainly like knobs and sliders.

While brainstorming with Steve about his synth, several of us came up with the idea of an interface like a plasma globe, which you control by moving your fingers over the surface. A cheap videocamera inside could watch what was happening and control the action.

Apparently a group of engineering students have been working on the globe subproject for six months without much progress to report. Although their difficulties seem to be mainly lack of organization and lack of time, others of us had talked about how clear an image might be obtainable on the camera with the globe lighted from the inside or outside.

Finally it occurred to me (while driving home from work) that gloves with LEDs on the fingertips would make lighted spots that should be very easy to see from the inside of the globe. Different colored LEDs on different fingers would allow the driver software to identify the different fingers; and pressing the LED against a translucent surface will produce a sharper point than holding it further away, so it might even be possible to determine approximately how near a fingertip is to the globe’s surface. And if made properly, the glove could be worn without impeding other use of the hand–just adding lights for the globe.

Time to prototype.


I was hoping to find a cheap lycra glove to make something like the original Dataglove. (Yes, I have a Dataglove system. No, you can’t play with it.) What I found instead was certainly cheap, but knit cotton instead of lycra. Heck, for 96¢, it was good enough.

When I put the gloves on, I could feel that they’d been assembled somewhat sloppily. Inside-out, it was easy to see that there was a lot of extra fabric inside the fingers outside the stitching:

Fingers need to be trimmed

So I trimmed it a little closer and more evenly around the fingertips, for better fit and comfort.

Fingers trimmed


I wanted to use surface-mount technology (SMT) LEDs, so they’d fit flat against the glove surface. The ones in my stockpile are out of broken digital office phones, used to light up beside the line appearance and feature buttons.

I wanted to be sure I knew the polarity before I started attaching things and soldering them together, so I tested first with my meter. The LEDs actually lit with the small amount of current it supplies, which was kind of cool. Curiously, the green LEDs have the anode on the end with the cut corner, and the red LEDs have the cathode on the end with the cut corner. On each LED that I identified, I marked the anode end with the color of the LED. (The ones on this sheet are tinted to indicate their color, but the ones I’d already removed weren’t.)

The phone flex-PCB has a 300Ω resistor in series with each LED, so I tried out a couple there on the strip. Nice and bright.

Testing an SMT LED

Soldering the LEDs

My plan was to solder wire the LEDs, then sew the wire through the glove to the back side, where I wanted to attach a battery holder. I got out some fine wire, scraped off the enamel insulation, wrapped it around the fly leads on the LED, and soldered it up.

Soldering the SMT LEDs


After I had both wires soldered to the LED, I threaded one at a time through a needle, held the LED about where I thought I wanted it on the fingertip, and started sewing. The goal was to get the wire from the tip of the finger to the back of the hand without leaving any large loops that might snag on anything, and without reducing the stretchiness of the glove. The latter factor called for a zig-zag stitch, which with a single thread looks like a running pattern of slash marks.

LED on second finger

Once I got the wire stitched around to the back side, I followed along the back of the finger and then curved toward the center of the back of the hand.

Stitching from the back of the finger toward the battery

Glue for Protection

I needed something to protect the LEDs on the fingertips so they wouldn’t snag. When the wires were safely stitched around out of the way, I got out the hot glue gun, put on the glove, put a dot of molten glue over the LED, and pressed the glue into a perfectly-shaped dimple in a USB serial connecter that I lifted from the CRATEL lab. It soaked into the fabric a bit, adhered very well, and made a nice smooth bubble over the LED.

Glue bubble over LED

Well, mostly nice and smooth. Hot glue tends to stretch like pizza cheese, and I made a little boo-boo.

Battery Holder

For now, I settled on prototyping just two fingers, because I have only two colors of SMT LEDs, and because it seemed like enough for a proof of concept. I steered the appropriate wires onto the same paths and ran them up to where I wanted the battery holder.

Back-side stitching for two fingers

Then I clipped the wires short, scraped the ends, folded the glove over to get room to work, and wrapped the wires around the leads of a surface-mount coin-cell holder salvaged from a PC motherboard.

Soldering battery holder

I soldered them on, then folded the battery holder leads underneath so they wouldn’t poke through the glove and scratch up the hand. Laid back out, it looked like this.

Back of glove with battery holder attached

The Lights

I didn’t bother with a switch on the prototype–just pop in the coin cell and the LEDs come on. And because I’m using an old, small battery, I didn’t bother with current-limiting resistors–the internal resistance of the battery seems to be enough to limit the current to the LEDs.

Lighted fingers

Due to the idiosyncracies of my digital camera, the green LED on the index finger doesn’t look very green in this picture, but it really is. It’s a lot dimmer than the red LED, though; and I’m not sure why that is. Before going beyond a prototype, I’d want to pick current-limiting resistors to more closely calibrate the brightness of the different LEDs.

I don’t have a translucent globe to use, but I borrowed a hemispherical Tupperware bowl from my friend Lawrence’s daughters. (Don’t ask my why the girls have their own set of Tupperware–I really don’t know.) It works well enough to demonstrate the idea:

LED fingers through Tupperware

You can clearly see where the red LED is touching the bowl. Now all we need is a videocamera, some fancy software to track the lights, and an interface to a video synth. :-)

Seriously, all of those things are Steve’s domain. I just wanted to see whether I could throw together a working glove, and I think this’ll do.

Oh–and when you want to shut it off, you take out the battery and drop it into the thumb.