Art Clips

Pam pointed me at an article in the book "The Creative Family" by Amand Blake Soule, called "Art Clips".  The basic concept is that it's a bulldog clip, attached to a board of some kind, which you attach to your wall.  You can then hang up your kid's artwork or whatever from the clips easily.  She suggested that we do this for Jasper's playroom, to hang up his works.  I checked out the article, and then bought some materials.

I decided to make strips, which would be mounted to the wall, each one having bulldog clips mounted on it.  I arranged it so that the screws that hold the bulldog clips secure it to the wall through the wood strips, just to simplify things a bit.  I bought 1x3 pine stock, some finishing washers, ordered some bulldog clips, and dug out some 1 5/8" drywall screws leftover from another project.

The wood strips were painted with the light green we used in Jasper's room

The space I needed to fill was approximately 16' and change.  I was going to put in two 8' lengths, but decided instead to do four 3'6" lengths.  Each one has four holes, drilled at 3" from the end, then every 12", with a 3" gap on the other end.  

The screw goes through a finishing washer, through the back tab of the bulldog clip, then through another finish washer, just to raise it all off of the board a little.  I started the screws into the wood strip, then held it up on the wall 11" down from the ceiling and secured the screws through the wood strip and into the wall behind it.  These are all mounted through some old panelling glued to drywall, so it should be ridiculously secure.  It also will only be holding up some pieces of paper, so I didn't need to worry about getting anchors or to secure these into studs or anything like that.

I mounted the strips with a 6" gap between them, all centered on the wall.  This means that each of the binder clips end up 12" apart from each other.

Add some art, et voila!  We all love the results!

Smörgåsbord 1

Some nights when I head to Interlock, rather than having one single project, or a part of a larger project to work on, I have a bunch of little things I want to get done.  They have the tools and materials I often need to do this.  This past Tuesday was one such night.  I had four things I wanted to work on, and I got all four done!

1: I like to put handles on things.  My favorite handles are from Lowes or Home Depot, and are called "wire drawer pulls" as seen in the image above.  They're relatively inexpensive at about $2, and are simple to install.  Generally they would be put on drawers in a modern kitchen or a clinical-type setting, but I like to put them on everything.  If something is portable, it should have a handle.  I just drilled two small holes in the plastic parts bin seen above, shoved the screws in from behind with some washers, and done!  I've used these handles for portable drive carriers, and other now-more-portable things.

2: Jasper sometimes breaks his toys.  I usually am the one who fixes them.  Above are two wood bolts from his workbench.  The threaded screws came out of the bolt heads.  I just scraped out the glue from the holes, and cleaned up both sides with a rasp and some other things that probably weren't designed for such things.  I added some wood glue, threw them in these clamps, and returned the screws to Jasper in the morning.

3: I had tried to fix my DLP projector a few weeks back.  There was something in the light path making half of the image dim such that if you shook the projector, it would clear up a little. I tore it down, and right between the spinny color wheel and the mirrors in front of the DLP chip is this little mirror tube collimator. The glue holding the four front-surface mirrors to the rectangular metal box had failed, and the mirrors became loose.  A couple weeks back, I had tried gluing it back together with epoxy, and it seemed to work, but a new, harsher shadow was in the projected image.  I needed to get some dental tools, mainly the little mirror tool, to see what was going on.  Sure enough, this little guy was aligned incorrectly.  A bunch of futzing with it later, and it is now fully functional!  

4: I have been building little breakout boards for my stepper motor controller-turned-arduino boards.  I decided that for the animatronic bird project, I wanted to have a way to input joystick data.  I made a small adapter to go from PC Gameport Joystick to the widget.  I followed this project here for the correct circuit -- basically just some pullups on the digital button inputs, and some pulldowns for the analog axis inputs.  I only wired up the first X/Y pair as the widgets only have two analog inputs available.  It was relatively simple to build.  I had built the main breakout board the night before at home, and i made the orange-wire to Gameport connector cable at Interlock.  With help from Nick, providing the old joystick, before I left i had written an auto-scaling display of the current joystick state.  More about this to come in future posts.

All in all, it was a densely packed evening, with four mini-projects completed.  Huzzah!

Converting M4A to MP3

As some of you might know, I now am running a few music streams.  I'll link to the specifics of them at the bottom of this post. One of the problems I've had is that most of my music is in M4A format, ripped/converted through iTunes over the years.  The stream is an MP3 stream, and the streaming software (icecast2 + ices0) requires that the input files not be in M4A format... preferrably MP3.

When I started up the first stream ("Dole Whip" -- Polynesian, Hawaiian, Disneyland Adventureland themed) much of the content I was using was M4A.  I ended up using iTunes to convert the content to MP3.  This became cumbersome to convert, copy out into proper folders without their m4a counterparts, then remove them from the library before iTunes Match decided to do something with it.

I decided that a better way was to just collect everything as M4A or MP3 files, then convert the M4A files over to MP3s through command line stuff.  The first pass at this, I used the following shell script, which worked well.  It requires "bash" (standard shell), "faad" (AAC/M4A decoder), "lame" (MP3 encoder), and "id3" (MP3 metadata tool).

#!/bin/bash
for i in *.m4a; do
        echo "Converting: ${i%.m4a}.mp3"
        faad -o - "$i" | lame - "${i%.m4a}.mp3"
done

This worked well, but I usually get pretty religious about ID3/track metadata being correct. The above has the result of completely stripping out the metadata, resulting in a "naked" MP3 file.

I did notice that running "faad -i track.m4a" will dump out the metadata in a predictable/parsable manner.  Here's an example from its output:

title: Caribbean Blue
artist: Enya
album: Shepherd Moons
genre: New Age
track: 2
totaltracks: 12
disc: 1
totaldiscs: 1
date: 1991
compilation:
tempo: 00000 BPM
tool: iTunes v6.0.1.3, QuickTime 7.0.3

So, I decided to spend a few minutes, and throw together a quick perl script to "do the right thing."  The basic process is:

1. faad -i (songfile).m4a  --  store aside all of the metadata in a hash
2. faad -o -i (songfile).m4a | lame -b 192 - (songfile).mp3  --  convert it to mp3
3. id3 -..... (songfile).mp3  --  add the metadata in to the mp3 file

Pretty straightforward.  I then just wrap this in a shell script to do this for multiple files in a directory, or in a directory in a directory, and a bunch of M4As will be converted to MP3s with all of their clothing intact. 

#!/usr/bin/perl
#
# m4a-2-mp3
#
#       converts m4a files to mp3 files, retaining metadata
#       requires: faad, lame, id3, perl (duh)
#
#       Scott Lawrence 2012  yorgle@gmail.com
#

if ( $infile eq "" ) { printf "No file specified.\n"; exit; }
if ( !-e $infile ) { printf "%s: File doesn't exist.\n", $infile; exit; }

printf "Working on %s\n", $infile;
$info = `faad -i "$infile" 2>&1`;

@lines = split /\n/, $info;
foreach $line ( @lines )
{
        chomp $line;
        $line =~ s/\n\r//g;
        if( -1 != index $line, ":" )
        {
                printf "%s\n", $line;
                ($key, $value) = split /:/, $line; 

                # zot whitespace at beginning and end
                $value =~ s/^\s+//g;
                $value =~ s/\s+$//g;
                $key =~ s/\s+$//g;
                $key =~ s/^\s+//g; 

                #shove it into our hash
                $id3{ $key } = $value;
        }
} 

printf "Track is \"%s\" by \"%s\"\n", $id3{ "title" }, $id3{ "artist" }; 

$mp3file = $infile;
$mp3file =~ s/\.[mM]4[aA]/.mp3/g;
printf "Converting to MP3 file: %s\n", $mp3file; 

$cmd = "faad -o - \"$infile\" | lame -b 192 - \"$mp3file\"";
`$cmd`; 

printf "Adding back in tags\n";
$cmd = sprintf "id3 -t \"%s\" -T \"%s\" -a \"%s\" -A \"%s\" -y \"%s\" -g \"%s\" \"%s\"",
        $id3{ "title" }, $id3{ "track" },
        $id3{ "artist" }, $id3{ "album" },
        $id3{ "date" }, $id3{ "genre" }, $mp3file;
`$cmd`;

And as promised, here's the links of music streams I've got going currently:

• Dole Whip - Polynesian, Hawaiian, Disneyland Adventureland 
• http://dolewhip.dyndns.org:23280/dolewhip
• Tronica - TRON, TRON inspired, and similar music
• http://dolewhip.dyndns.org:23280/tronica
• Mixtapes - All of my mixtape podcast episodes on shuffle
• http://dolewhip.dyndns.org:23280/mixtapes
• Party - Music from my 90's DJ CDs on shuffle.  A 24 hour party!
• http://dolewhip.dyndns.org:23280/party

Vacuum Forming Rig Part 1: Almost A Failure

One of the tools I will need for my Animatronic Avian project is a vacuum forming tool.  To be honest, I've wanted one since I read an article on the web about how to make your own Stormtrooper costume in the late 1990s.  It now seemed like a good time to make one, as I'd like to use it for producing the bird parts, and it seems pretty straightforward, so within a week, I was at Interlock, crafting up a vacuum plate.

The basic design I'm going with for the vacuum plate/box is a small box, with a shopvac connector on the bottom, pegboard as the top, screwed together, and metal foil taped to seal air gaps.  This is sort of a mixture of a few different designs I've found on the net.  The material will go on its own frame, heated by a heat gun, then pushed down onto the vacuum frame, with the shop vac turned on.  The softened material will get sucked in tight against the mold, forming it into that shape.

The basic frame is 12" square.  I cut the pegboard to 12"x12", and I cut a scrap of wood to 12"x14" for the base.  I made this one larger so I could clamp it to a desk to keep it stable.

For the frame of the base, I ripped some 2x4 pieces into 2x2 ish stock.  To make this easier to assemble, I made four of these, cut to 10 1/2" long, and arranged them so that they butt up against the others, as seen in the picture above.  They went together fairly cleanly, but there were some air gaps, but this isn't important as the foil tape will seal it up later.  I specifically wasn't concerned about tolerances on this as I knew the tape would cover it anyway.  The stock is held together using metal brackets, also seen in the above picture.

The baseplate got a 2 1/2" diameter hole in it to accept the shop vac hose.  I would have used a hole cutter to do this, but I didn't have one.  Instead, I drilled a pilot hole and used a scroll saw to cut out the hole.

The frame is then screwed to the baseplate (pre-drilling all holes, of course) and to the pegboard using drywall screws, AKA the "duct tape of screws".

Next comes the foil tape to seal it up. Finally some door weather stripping to act as a good seal with the material frame.

The material frame was made with some 1x2 stock or whatever this was, from the scrap pile.  It was simply drilled and screwed together with more... drywall screws!

The material is taped to the frame (for now... in the future, I'll build a better, less cumbersome way to secure the material.)

Then I heated it with a heat gun.

When it was time, the shop vac went on, and I lowered the framed material down onto the plate.

So... How did it work?

Not great.  It was ridiculously difficult to get the material heated consistently and hot enough.  The heat gun would burn a hole through the material if left in one place, but the material cooled off too quickly if you moved away from it for too long.  I need to build a heater rig to prepare the material.

I attempted to re-heat the material with hopes of getting it hot enough to pull in, while the vacuum was on.  It helped a little, but was quite tricky to work with.  I then removed the foamcore miniature arcade machine, and continued, thinking its height might be an issue.

I overheated some of it, melting through the plastic sheet.  Oops.  But you can clearly see the Duplo blocks, and the stupid Jar-Jar in the plastic.  Unfortunately, Jar-Jar made it unscathed.

One thing I wasn't expecting was the odor of the plastic, especially this green plastic seen above. MAN, does it smell horrible.  When you see people mentioning "work in a well ventilated area" they aren't kidding. The plastic continued to have a foul odor for a few hours after it cooled down. I had to drive home from Interlock with my windows down.

It shows promise, but it's not quite there yet.  I wouldn't call it a success, but I wouldn't call it a failure either.

Note: This post was originally posted to the Interlock project blog.

Prototype Elias Serial Network Node

To simplify saying "Serial networking for the Animatronic Avian project", I've decided to instead just name the software/firmware of the project after the desktop software I've started to make to control it all; "Elias".

I've started to build up what I plan on using for the interface boards for the project.  I start with the exposed DB-15 connector, and wire it up directly to a piece of strip board to hook it in on the FTDI serial network wiring.  I'm building them such that I can plug a bunch of these in directly into each other for debugging, or space them out with long cables between them for long distance testing.  I can also integrate these right into the final devices when that happens.

The prototype I made first is seen in the above image.  The FTDI USB-Serial adapter is on the left.  That is plugged into a 6 pin header on the left side of the middle board.  This hooks up power and serial to the DB-15 widget (Arduino), with a breakout for the four data lines on the connector (D10-D13) to LEDs.  The serial out from the widget goes to the 6 pin header socket on the right.  The board with the green LED on it is the serial terminator.  It simply connects the RX to the TX so that serial data gets sent back through the return.  The LED is just hooked up to power through a resistor, and acts just as a power/connection indicator.

For completeness, here's the backside of water.

The above works well as a simple test rig for now.  Now that I've made this one, I have ideas on how to make the next one better.  Namely, a way to better lay out the data lines to a breakout area.  I will be using a pair of these to hook up to my power box, to be used as a proof-of-concept for the protocol and syncing software.  I also plan on experimenting with using the 5 pin output for the stepper motor, to drive more outputs.  Even if I get that working, I will still use two of these to drive the 8 inputs on the switch box, just because I can.

Now that I made this one, along with preparing the DB-15 plugs, and making the terminator, all of which took about an hour, I should be able to make the next few of them much quicker.

Power Box Rebuild

About two years ago, I threw together a power box with 4 switched outlets.  I had some solid state relays (ssr) from another project that never panned out, so I jammed them onto the sides of a plastic electrical gang box.  It worked quite well, but all of the 110V was exposed on the outside. I never bothered to fix it up.

The first power switching box.

You can see two screws sticking out of the left side.  This is where an Arduino would be mounted.  The terminal block connected up the 4 circuits, plus one auxiliary SSR, as well as the common ground for all of the SSRs.  The four outlets on the left are switched, the two on the right are not, which was perfect for using a power brick for standalone use.

The circuit for this is pretty darn simple.  On the AC side of things, the grounds are tied together, as are the neutrals (white or blue).  This is the taller prong of the outlets.  The hot from the mains cord (black or brown) gets split up to one side of each of the 8 SSRs.  The other side of the SSR goes to the hot pin of the outlets (shorter prong).  Each SSR also has a low-voltage section.  The ones I had were 5v, so I could switch them with TTL inputs.  All of the low voltage "+" sides of the SSRs go to the terminal block, to be connected to an Arduino, parallel port, whatever.  The other sides are all tied together to the ground screw on the terminal block.

You can surely do this cheaper with triacs, cheap relays, etc, but I had these on hand, and decided to just use them.

Exposed wiring.  Not kid or pet friendly.  Also, don't lick it.

Black wires are the hot or switched 110V lines. Red are the 5v TTL lines.

This worked out quite well, but I wanted to be able to switch more outlets, and I had four more SSRs, so I built this secondary box the next year:

It's not pretty, but it works.  Just jam those wires into a breadboard.

Well, this year, I decided that I wanted to upgrade this a little, and make it slightly less hackey.  I found an old power switching box I had resuced from a DIGITAL VAX in the early 90s.  It has 8 outlets on the back, a nice metal chassis that is easily opened, and lots of space for the SSRs.

 First thing I did was gut it.  I had gutted it many years ago, and turned it essentially into a glorified power strip.  This time, I started mounting the SSRs inside the chassis.

Lots of nice screw holes for mounting! It's going to be nice to have all of the 110V enclosed.

Chassis reassembled, wires reconnected!

All of the TTL level coming out through holes in the chassis.

There should be rubber grommets there, but this is temporary, until I build a better connection system.

And the view from the top.

This should work nicely for this year's office lighting decoration, not to mention that it's oodles safer, much more portable, and a lot less fragile!  I'll hopefully be driving this with the electronics/protocol/sequencer system that I'm working on for the Animatronic Avian project, as a sort of stepping stone.   Not to mention that this can be used to control lighting for the final birds too!

Daisy Chaining Serial Connections

As part of the Animatronic Avian project, I need to have a way for the controller software/computer to send synchronized data out through all of the performers on the stage.  Being that I may be using my reflashed stepper motor controllers in this, rather than full-blown Arduino boards (or custom ATmega boards), I need to have a way to network these without using any precious IO pins.

On top of this, it needs to be very lightweight so that I can send data down through all of the performers without using too many resources of the device.

I also want it to be cheap, both with cost of parts for implementation, as well as for system resources in the chip firmware.


The solution I came up with is to use the builtin UART, which usually is set for a standard RS232 connection, but in a cascading daisy chain fashion.  This means that the hardware-assisted UART in each chip, plus one data line down to the next chip is all that's needed to implement this.  The networking stack running on the device is light enough that it should not impact performance of the main usage of the Arduino.

The above diagram shows how four Arduino boards are wired for this.  Basically instead of the TX and RX of a board connected to its host, instead its TX goes to the next device in the chain, and the RX comes from the previous device on the chain.   The actual implementation of this uses my D15-based ATmega widgets, and thus I followed this diagram:

Four wires are needed to hook up each node: power, ground, serial in, serial out.  In the above configuration, the final node does not output to anything.  I had the above working quite well with a simple firmware program.

Before I constructed this, I had no idea if it would even work.  But I spun up five of these, networked together, and it all seems to work perfectly.  Here's a video where I demonstrate it:

The program reads in a character from serial input, if it's a "b", it sends the "b" to the next device immediately, then turns off the LED for 1/4 second.  If it is a number, it will turn off the LED for that many seconds, then subtracts one from that number and sends that new number down to the next node.

So if it got a "6", it will turn off its LED for 6 seconds, then sends a "5" to the next one.  This was the simplest program I could think of to check if this concept would even work.  Turns out, it does!

This diagram shows an updated version which adds a few features which will be helpful for getting the software design debugged.   The reset line is connected to the FTDI header, as well as a jumper to feed the output of the first device or the last device back to the host.  This will enable me to reprogram the first node quickly, without needing to plug the micro into an FTDI interface cable.  This also will let me experiment with adding a "return".  The "return" line takes the output of the final node in the daisy chain, and sends it back to the host.  I may use this as a trigger for a mechanism to continuously send data states to all nodes.  (Once the computer host receives something from the final node, it can send down the next data envelope.)


So the basic idea of how this will be used is as follows.

The host will be playing back an audio track, and looking at a few data tracks.  At any particular timeslice, it will prepare a data envelope of bytes, containing all of the synchronization events for the animatronics.  This includes digital bits to turn LEDs, motors, and solenoids on and off.  There are also analog bytes that will be for controlling servos.  Let's try out a use case to better understand how this will work in practice...

First, the host looks at the data for the current timeslice.  For our example, we will have three animatronic objects on the serial bus, each of which has 5 data bytes associated with it.  The data is prepared and would look something like this:

• 15, 1, 1, 1, 1, 1, 200, 200, 200, 200, 200, 30, 30, 30, 30, 30

The first number is the count of the numbers that follows.  In this case, 15 digits will be included.  This is sent out from the computer host via RS232, 9600 baud.  The first animatronic microcontroller receives this, and will remove the numbers that it needs from the end.  In this case, it will pull off the five "30"s from the end.  It will also reduce the count from 15 to 10.  This will look like this:

• 10, 1, 1, 1, 1, 1, 200, 200, 200, 200, 200

It now sends this modified data envelope to the next device on the bus.  That device will pull off the  five "200"s from the end, and then send down the new envelope.

• 5, 1, 1, 1, 1, 1

The final micro on the list will pull off the five "1"s, the count reduces to 0, and it refrains from sending anything further.

The specifics of the protocol are yet to be worked out.

Also, the specifics of the interconnect are yet to be worked out too.  It'll probably be four pin header for input, four pin socket for output. (+5v, Ground, data, return)

The latency of this will be imperceptible for the use cases I plan to use this for, and it will enable me to have oodles of devices on the serial bus, all controlled by one host computer.  And best of all, no additional hardware (MIDI, DMX, I2C, SPI) is required, and no additional IO pins will be used for it.

Here's the Arduino program if you want to try it out yourself and you have a couple of Arduinos lying around...

/* Cascading Blinker
**
**  2012-December-01  Scott Lawrence  yorgle@gmail.com
**
** A number character when received will turn on the LED for that number of seconds
** It is then decremented then sent out.
**
**  Boring on its own, but it's a test to see if I can cascade RS232 devices.
**
**  Host--->RX(device 0)TX--->RX(device 1)TX--->RX(device 2)TX--->  Etc
*/
const int ledPin = 8; // 13 for standard arduino
void setup() {
  // initialize serial:
  Serial.begin(9600);
 
  // make the pins outputs:
  pinMode(ledPin, OUTPUT);
  digitalWrite( ledPin, LOW );
}
void blinkFor( long ms )
{
  digitalWrite( ledPin, HIGH );
  delay( ms );
  digitalWrite( ledPin, LOW );
}
void loop()
{
  int ch, digit;
  long d = 0;
 
  // wait for something to come in
  if( Serial.available() == 0 ) return;
  // read in a character.
  // If it's within '1' .. '9', set the timer for that number of seconds.
  ch = Serial.read();
  if( ch >='0' && ch <= '9' ) {
    digit = ch - '0';
   
    if( digit > 0 ) {
      d = digit * 1000;
    }
  }
 
  if( ch == 'b' ) {
    // turn off for 1/4 second, send down echo immediately
    Serial.write( 'b' );
    blinkFor( 250 );
  }
 
  if( d > 0 ) {
    // turn on the LED for the requested number of seconds
    blinkFor( d );
    // cascade out our digit, one less than ourselves
    Serial.write( (digit - 1) + '0' );
  }
}

Animatronic Avian 1: Planning and History

Since I was a kid, I was always into Disney Imagineering.  For many years, I always thought that designing and building attractions and such for them was something I would aspire to but never reach.  I always held WED/WDI up on this pedestal, thinking that they were so far above me, and I'm sure that in some areas they are.  Over time, I've come to realize that I can do that stuff too.  I have always wanted to be an "Imagineer", and there's really nothing stopping me from becoming one... Perhaps I won't be working for Disney, but I can do the same stuff.  That's where this project comes into play.

These birds sing words.

Disney introduced The Enchanted Tiki Room in 1963, and it's probably my favorite attraction at Disneyland and The Magic Kingdom.  It's got everything... Great music by the Sherman Brothers, wonderful island-tiki themes, humor, animatronic birds that sing words, flowers that croon... I've wanted to bring this home somehow, and I think that the time is right to make this happen.  It's a really big project and will likely take me years to complete, but I'm sure that it will be a welcome addition to my son's playroom (and/or my office.)

These flowers croon.

The project covers a lot of subprojects.  I'll try to outline here the various subprojects which I will be working on and blogging about here as I work on them. (I will list them here in arbitrary order, as I will be working on and posting about multiple projects simultaneously.)

My goal is to make this as repeatable/reproducible as possible.  The things I make may be one-offs prototypes, but the goal is to make them easy to duplicate.  I won't rely on specific items from stores, other than materials, and many of the parts I will either vacuform, 3D print, or craft.  (Things like the MST3K bots relied on specific parts, which have become difficult to find, turning those components from "cheap old junk" into "collectible, rare, expensive parts".  I hope to avoid this situation.)  I also plan on doing this as inexpensively as possible without it becoming "cheap".  I may offer kits, parts, downloads, templates for the various aspects of the projects in time as well.  All of that will become clear to me while I work on this.

Looking around for items to purchase "out of the box" shows that a simple playback unit might cost $500, a servo controller $300... so that's $800 before you even buy a single material or piece of wire for it. The controller boards I'm going to use are Arduinos, at $22 each, and they will be controlled from my Mac computer, which I already have.  I may consider automating this in the future, which will require further design consideration, but may be accomplishable via a Raspberry Pi $25 and a USB audio device ($5)  I'm going for "in my house" not "industrial", although the concepts are the same.

Project 1: Vacuum Forming Rig

To construct the outer body of the birds in a quickly reproducible fashion, I've decided that it's time to build a simple vacuum forming rig.  I will be building this at Interlock, using some scrap material there, the vacuum there, and their heat gun.  I can build a heating element rig too, but to get started i'll just use a heat gun.  I plan on only making a 12" square working area (or perhaps a little smaller).  I will be using this to make at least the beak of the animatronic bird, but probably also shells for the head and body, onto which feathers or fur can be added.

The idea is that I would make molds of these various parts, and then vacuform plastic sheets over the molds, cut them out, and I will have easily reproducible parts.

Here's a link to a video of something similar to what I want to build.


Project 2: "Walter" Motion Capture Hardware

The most intiuitive (and fun) way to capture the performance to play back on the puppet is to build a puppet motion capture system.  I'm vaguely basing this design on the "Waldo" rig that Jim Henson is demonstrating here.  I may use a lot of PVC and CPVC parts to construct this, and perhaps some 3D printed parts.  I'm not entirely sure yet.  I will likely use simple adjustable resistors/potentiometers at the joints to capture the angular data, hooked up through an Arduino's analog inputs, then recorded on a host computer.  The test app for this will be a simple display that records motion events.

This is the one section of the project where I will likely only be building one, and will do a lot of hacks to get it working for my needs.  If there is demand for it, I can figure out a way to reproduce it but that is not the goal for this section.


Project 3: "Elias" Motion Capture and Replay Software

This software, which I lovingly call "Elias", named after a certain guy who was quite influential, will work with project 2 above.  It will play back an audio file, and log input from the puppet control Arduino in some yet to be defined data format.  It will represent the angular information on the computer's display, while playing the audio.  It will also be able to replay the angular information down through a target Arduino (in the future, embedded inside of each puppet), synchronized with the audio.  This software could easily be re-purposed to control relays to turn on and off lights to make simple light shows and such.  It will handle up to 7 analog tracks, and 7 digital tracks at a sample rate of somewhere around 500-1000 samples per second, capable of going over a 9600 baud connection.  The first version of this will be used to drive my xmas lights this season.


Project 4: Flora Design and Construction

Here's where it starts getting REALLY fun.  To start with, I will build a simple flower, possibly like the second image seen above.  Those flowers have basically one point of articulation; just the mouth open or closed.  I may add a second point, rotation of the entire flower.  The flower petals will be vacuformed and spray painted.  They will likely then be glued together to some sort of plastic armature. The mouth may be actuated via solenoid or something similar.  The rotation, if implemented, will be made by directly mounting the lightweight flower puppet on a servo's control arms.

The goal of this isn't specifically to make an animatronic flower, although that will be one of the products of this, and will be needed for background/fill for my Tiki extravaganza.  Rather, this will be a good way to integrate everything together, without constructing the complete avian, which will take significantly more time and effort to complete.  Get something done quick, get another "win" under my belt, get motivation to follow through with the following item...


Project 5: Avian Design and Construction

Similarly to the flower, this will have a plastic or maybe foam-core skeleton which will hold the electronics and servos.  For all birds, this skeleton will be identical.  I'd love to make four birds, but one will be awesome.  On top of the skeleton, vacuformed skin will be affixed somehow, perhaps using cotter pins like the hood on a remote control car, or perhaps using just Velcro.  These skins will be painted and have feathers glued to them.  I can picture this being made of seven pieces:  left body, right body, belly, lower beak, upper beak. top of head, bottom of head.  I'll have to figure this out further. I'll also have to figure out how to add the articulation points in the skeleton, as well as the best way to affix feathers, or a feather-like skin on them.


At this point, everything will be done, and I should be able to make a tiki bird performance!

Now that I've spelled this all out here, I feel a bit overwhelmed by the whole thing! ... but I have to admit, each item is achievable.  I'm anxious to get to the final product!

Repairing a Digital Camera: Battery Explosion!

I like to collect old pocket computers and gadgets. One of the things I encounter often is exploded batteries.  I recently rescued a Canon Powershot A520, and it seemed to be completely dead, probably due to poor battery contact due to the previous batteries exploding.

I've read stories of other people using watered down vinegar to remove the alkaline, but I instead use just vinegar.  I dip a paper towel in it, and saturate the affected areas.  If you listen closely, you can hear it fizzing.  Ssszszszsszszszs!

After a few saturations and wipes with paper toweling, I had removed most of the alkaline gunk.  From here you can clean it with a baking soda paste, but for this, I just decided to scrape the contacts a bit.

Once it was cleaned up, I put in some old AA batteries and it powered right up!  I dropped in my old 2 gig EyeFi Geo card ($20 from Woot many moons ago), and it worked!  I recharged some high capacity AAs overnight and dropped them in.  Then things started going badly...

It would power on, then immediately turn off.  I tried my second set of rechargables, and the same thing happened.  I re-cleaned the contacts, but that didn't seem to help.  It was at this point that I thought I knew why it had been dropped in the recycle pile.

Then I realized that my AA rechargables put out 1.2v each, rather than the 1.5v of alkalines.  The camera has a requirement printed on it of 3.15 volts.  1.2 plus 1.2 does not equal 3.15.... I found a fresh pair of alkalines and dropped them in, and sure enough, it works perfectly!

As a sidenote, I also set up my computer at home to host the EyeFi software, and it drops the downloaded pictures into a Dropbox directory.  Now, all of the pictures taken with the camera are instantly shared when I'm home. I have no reason to manually sync the card physically now. Yay!

Timer Repair

Our kitchen timer has been acting up recently, and with Thanksgiving quickly approaching, I needed to do something about it.  The push button for the start/stop function has been getting harder and harder to use.  In the past, I've cracked it open and cleaned out the pad underneath the rubberized button membrane, but this time, doing this didn't work. I also  wanted a more permanent fix.

I decided to replace the membrane switch for that function with one of these tactile buttons.  I just had to make sure that the solder pads would line up.  I worked out an orientation in which the solder pads would match the pushbutton pads, as you can see in the next image.

The only issue is that rather than the rubber membrane sitting flush with the board, it now had to accomodate the shape and size of the switch along with the button which extended out quite far.  I used a pair of diagonal cutters to nip away at the rubber from behind to recess the switch into the button itself, Ben Heck style.

You can see this in the top right of the gray membrane.  The two contact pads have been removed, and instead there is the hole, into which the switch recesses.  The hole was made fairly crudely, but it works!

It's been accidentally abused over the years, and as a result, the screws on the bottom no longer hold it together as the plastic has broken enough.  The strip of electrical tape around the base does well to hold it together while still looking super stylish! NOTE: It's not actually very stylish, but rather, functional and should last for many years more to come.  No reason to throw it out, when an hour or so of work will get it fully functional again!

EPROMs part 2: Success!

NOTE: This article was originally posted over at the Interlock blog.

This is a continuation of a previous article.  Quick summary: I tried to build a device for dumping an EPROM via Arduino, and I constructed a device that had no chance of working.  Oops.

This post will continue where that one left off.  I'll walk through some of the process to hopefully get to a solution that works...

To summarize the overall project;  I want to build a device that will illuminate an UV light-erasable ROM (EPROM) device, and also dump out its contents. I will then take the contents, display them as a graphic, and animate them over time as the bits fade away into an erased oblivion.

When we last left this, the above circuit was what I was going to work with.  The Arduino would shift out a 16 bit address, which will be stored in the 74HC595 serial-in, parallel-out shift registers.  Those would output to the address lines of the EPROM device. The 8 data line outputs of the EPROM then are read in directly by the Arduino.  I started to look around for the parts, and I was planning to buy them from Sparkfun.com, for a very reasonable price.  I was all set to place the order, but then I started thinking about other ways to sample the data, and then it hit me...

In the late 1980s, I had an Amiga 1000 computer (see previous post about restoring it).  We used Macintosh SE computers in High School, and as a result, we bought the "AMAX" Macintosh emulation system for the Amiga.  It was a lot easier to carry a floppy or two, rather than a SE or SE/30 in a plastic milk crate, not to mention that MacWrite was a substantially better word processor than TextCraft. ;)

AMAX consisted of software you run that emulated the Mac's hardware, as well as a "cartridge" that plugged into the floppy drive port of the Amiga.  I remember hearing that they went with the floppy drive port because it was the only appropriate port identical on all Amigas that were available at the time. (Amiga 1000, 500, 2000).

The cartridge served two functions. First, it let you plug in a Mac floppy drive right into the Amiga so that you could read and write 800k Mac floppies directly.  There was something about Amiga drives and Mac drives supporting a different number of drive speeds, so full Mac compatibility on the Amiga's drives was directly impossible.  Future versions of AMAX that used an internal card on the Amiga 2000 worked around this issue.  It was possible to make a floppy that supported just the sectors/speeds that were the same on both, but they only stored 272k of content.  But I digress...

The other function of the cartridge was that you needed to plug in Mac roms into it, which the software would read in as it starts.  Rather than storing the ROM on the Amiga, this protected the copyrights or whatever.  But the important thing here is the function.  I had picked up a few AMAX cartridges for $2 apiece at the awesome Active Surplus on Queen Street in Toronto a bunch of years back, so I dug one out.

Left-to-Right, you see: Amiga D23 floppy connector, for connecting it to your Amiga, two 28 pin rom sockets, two 74LS393s, one 74LS165, a resistor, some diodes, a 74LS139, the Mac D19 floppy connector on the bottom, then the Amiga D23 floppy connector for adding additional Amiga floppy drives.

I've started to trace out the circuit, but it became obvious quickly that it was optimized for board layout rather than what I would consider to be a sane arrangements of data lines.  For example the 8 data output lines of the ROMs go into the 74LS165 PISO shift register out of order, so they need to be reshuffled once captured in the host computer.

Instead I decided to desolder the chips!  My guess at the original function is something like: the Amiga issues a clear to the 74LS393 binary counter chips, ganged together to yeield a 16 bit output, rather than two dual-4 bit outputs.  This will reset their 16 bit output value to 0.  The 74LS165 parallel-in, serial-out register then latches the 8 bit output from the ROM, and provides it through shifting to the Amiga via the floppy port.  From there, you need to simply pulse the clock on the '393, and it will increment through every address. Then you just latch and shift in the data. There's also a 74LS139 demultiplexer, which might be responsible for sequencing through those events, or perhaps something to do with the Mac floppy drive. I had a slight mishap and lost the 74LS165, which is okay since I didn't need it for this project anyway.  Regardless, $2 plus some time -- I'm already ahead and I haven't even removed the D23s yet (which are the same size as Amiga RGB Video connectors! Perfect for another project...)

For fun, here's the board with no components on it.

With a slight change in gears I can adapt my design to use the parts I now have in my toolbox thanks to my desoldering tools.  Instead of the Arduino shifting out an address, it will instead do the process described above.  It will first clear the 393s, then alternately cycle between clocking out a pulse to increment their values, and reading in the value directly. Since I'm accessing the ROM data from start to finish, sequentially anyway, this solution works out perfectly.  I also show four LEDs in the above diagram. Three for various status, one for UV illumination.

Here is a close up of a 27C128 part. This one has Pac-Man programmed onto it... of course.  You can see through the quartz window, and down onto the EPROM silicon itself.

Here we see the pins on the Arduino, and how they connect to the shield's bus connections, along with the LEDs.  I could draw this up in a computerey drawing program, but sketching it out in Sharpie on graph paper is just quicker... ;)

Here are the  two 74LS393's.   You can see their connection to the address lines on the ROM, as well as the cascading of the counter, e.g. from 1QD to 2A, and from 2QD to 1A on the second chip.

And the wiring for the 28 pin socket, including the 3 pin (two-way) jumper so that i can use smaller 24 pin parts as well.

About the UV illumination...  The data sheets for the EPROMs show that they should be erased with 253.7 nanometer light, at 15-20 minutes, 2.5cm distance at 15 Watt/seconds per cm^2.  I dont know how to measure this with respect to LEDs, but I'm going to just wing it and see what happens.  The sheet also says that 253.7nm is the optimal wavelength for erasing them, but anything below 400nm should work.  I believe the UV LEDs I have are somewhere between 350nm and 400nm, so it should work.  The other issue is that the LEDs are substantially less powerful, probably a tenth to a hundredth the power. We'll see once we get this going, but I expect it will take on the order of weeks to erase a rom, rather than minutes.

The good thing about this project, in comparison to using EPROMs functionally, is that you want speed of erasure for functional use.  I personally found that my eraser worked on most of the devices I own in about 10 minutes.  I would often have a chip or two in the eraser, while programming and debugging others.  It worked out fairly well.  For this project, it's completely okay if it takes on the order of hours to erase a device.  I'll find out how well it works once I get it going.  I may use more than one LED just to speed it up a little, in case it takes on the order of days instead of minutes or hours.

I started laying out the board at home, wiring in just the LEDs, and figuring out the best layout for the chips.  I used the DIY shield for Arduino from AdaFruit.com as the foundation to build this upon.  I wanted to leave space for possibly using larger chips in the future, so what is the bottom of the board here has space for a few extra data lines if i re-route that red power line.  The '393's are layed out so that the one on the right, which addresses bits A0-A7 has four of its lines directly lined up.  This was to try to make it a little easier to wire up.

I bought some wire wrap wire for address, data, and control lines, and did most of the work of wiring those up one evening at Interlock.  I used red for control (counter clear, clock data cascade lines) as well as eprom address lines.  I used blue for data lines.  In the above pictures you can see how the wires were routed around (there was some more writing on the bottom, obviously.) You can also see how the UV LEDs are mounted with some stiff solid core wire.  I reduced the number of LEDs to two plus the UV LEDs for no real reason at all.  (There is an Arduino underneath there somewhere...)

On the two images above, you can see a jumper on the left of the first image, bottom of the second image... this changes what one pin is used for.  For smaller EPROMs, pin 26 of the 28 pin footprint is used for VCC, powering the chip.  In the larger packages, VCC is moved to pin 28, and pin 26 is used for Address line 13.  It's confusing.  A table that shows all of the pinouts doesn't really help too much, but it was necessary so that I could figure things out for wiring it up.

Next is firmware. I wrote a pretty simple program for the Arduino that simply enables the EPROM, resets the counters, then clocks through the addresses, reads them in and sends that data down through the serial link.  After getting the enable lines wrong (active low, rather than active high), I managed to get it spitting out actual accurate ROM contents.  As you can see in the above, it read out of the ROM (right half) 0xf3, 0x3e, 0x00, and so on.  In a disassembly of Ms PacMan on the left, you can see these bytes in cyan, just to the right of the red numbers 0000, 0001, and so on.

The other half is a simple program that runs on a host computer that simply reads in serial data and logs it out to a file.  That content looks like this:

f33e00ed47c30b23772310fcc9c30e07060708090a0b0c0d0e0f101114f532c038002a804c702c712c20022ec022804c3aaf4e324a503aec4ea73aef4e20033ae187d75f2356ebe9e146234e23e51812 

f33e00ed47c30b23772310fcc9c30e07060708090a0b0c0d0e0f101114f532c038002a804c702c712c20022ec022804c3aaf4e324a503aec4ea73aef4e20033ae187d75f2356ebe9e146234e23e51812 

f33e00ed47c30b23772310fcc9c30e07060708090a0b0c0d0e0f101114f532c038002a804c702c712c20022ec022804c3aaf4e324a503aec4ea73aef4e20033ae187d75f2356ebe9e146234e23e51812

I've now had this running for 12 hours with no change in the bits at all.  I'm thinking that it will require running for upwards of a week or two to have any affect on bits.  I may need to just drop the Arduino and ROM shield into my eraser to get the results I'm looking for... or at least a "control" to prove that the idea has a chance of working from here.

If nothing else, I now have a way to read EPROMS from an Arduino.  Awesome!