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!
Wednesday, December 26, 2012
Thursday, December 13, 2012
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!
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!
Sunday, December 9, 2012
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).
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:
- faad -i (songfile).m4a -- store aside all of the metadata in a hash
- faad -o -i (songfile).m4a | lame -b 192 - (songfile).mp3 -- convert it to mp3
- 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
- Tronica - TRON, TRON inspired, and similar music
- Mixtapes - All of my mixtape podcast episodes on shuffle
- Party - Music from my 90's DJ CDs on shuffle. A 24 hour party!
Friday, December 7, 2012
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.
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.
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.
Thursday, December 6, 2012
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.
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.
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.
Tuesday, December 4, 2012
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.
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.
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:
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.
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!
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!
Sunday, December 2, 2012
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:
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:
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.
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...
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' );
}
}
Subscribe to:
Posts (Atom)