From what I see, I think he's sending the picture over in a straight bitmap.  He mentions that decoding is not done topleft to bottomright, his looping code (on the PC, done in PHP in the code he posted) takes care of that.  He's just using a serial connection, I think..  The Arduino is then displaying that bitmap on the LED grid.  24x16=384pixels.  One pixel per bit, so that's only 48 bytes for the full image, probably passed as just a stream of CHAR or BYTE values, 48 bytes long.  Serial handles that even at slow speeds.

Pretty good framerate.. now you need a way to produce the PNGs downconverted from uncompressed AVI frames... so that on one side you just feed in a video file and on the arduino, the best approximation is mapped on the LED matrix..

Hmm.. interesting, to say the least!  

Among the things I have not yet hooked to the Arduino is the IR camera module from a WII remote, which is supposedly a really nice blob-tracking unit, but needs an external I2C interface and a clock.  Clocks are easy enough (need 25Mhz so software prolly won't do), and the I2C I was going to offload onto my soon-to-arrive TI Launchpad.  I figure that might just be an acceptable use for the little beast, at under five bucks, it'll have earned it's keep if it can support interfacing to that sensor... told ya I could find a better use for a Launchpad than a glue spreader!

Where do you get the little kid to stick inside?

http://news.blogs.cnn.com/2010/12/10/gotta-watch-parliamentary-brawls-toddler-in-toy-machine/?hpt=C2

You could get tricky and use a solonoid or a servo as a striker and a microphone to pick up the resultant sound.. glass will make a notably different sound than plastic I would think.  The other way would be density, but you have no way of knowing the wall thickness, which could make a thick-wall plastic bottle seem by weight to be a glass bottle instead.

Pull out a 'scope and a microphone and see if there's a usable difference in the sounds generated by a striker.  I'd think that glass is going to make that characteristic short-duration "tink", while plastic would be more deadened (tapping my coffee cup and a plastic Iced Tea bottle here) sound.  If so, a little creative coding can probably differentiate the two.  Come to think of it, metal would have it's own particular "clunk" too...

I'm just thinking about how we as humans tell whether it's glass or plastic or whatever.. and one of the first things any of us would do is to tap it, and listen to the sound it makes.  It works for us, so maybe there's a solution in there that Arduino can use too..

Hmm.  Now, you need to add a couple of photosensors to have it stop at each floor... though now that I think about it, you can likely do that by experimenting a little bit in terms of number (or degree) of rotation in the servo which corresponds to the elevator aligning with the floor..

That, and I'm 90% sure I had that exact Fisher Price garage as a kid, four decades back...

At any given flow rate it looks pretty stable, so I would think that varying the fan speed with PWM might be enough, without needing to use some type of feedback sensor.  It would be a build-then-calibrate rather than a build-to-meet-calibration setup, but I just can't see using a ping pong or beach ball as a high-precision indicator.  That being said, PWM ought to give a pretty fine degree of control...

Heheh.. I think I'm going to give this a try, at least a very simple version.. but on a grander scale.  In the basement, I have a standard box fan (110AC), and I've got a couple of inflatable beach balls left over from the summer..  PWM to a Triac (or a pair of SCRs) for the speed control... betcha a box fan could hold a beach ball on an air column several feet high...

AWESOME idea.  I love it.

My only comments:  Remove the tube, it won't be needed.  The pingpong ball can ride an air column just fine... the column pushes the ball back to center.  Remember your middle school science teachers doing this with a vacuum cleaner?  If I remember right, it's bournoulli's (?sp) law in play, air rushing around the curved surface creates a pressure well or something like that; I'm sure you can find the "why" out there on these here interwebs, but skipping theory, it works in practice so the academics aren't strictly necessary.

That, and then color the balls with fluorescent paint and front-light it with either a standard black light or some high-power UV LED's..  I'm already visualizing a spectrum analyzer made with a series of these.... what's the "response time"?  No matter what, the fall rate won't exceed gravity, how fast does a 0%-100%-0% cycle take?

I had been looking at the stats for the blog, which includes the URL's followed to reach the site.. which then showed me two things... I made the Arduino blog the other day with this the project (grinz) and here's the one that I'm kind of proud of:

http://blog.makezine.com/archive/2010/11/real-time_spectrum_analyzer_powered.html

Referenced in Make magazine's blog, too!

I really ought to fix up that amp circuit, huh?  I was thinking of using an op amp instead of beefing up the simple transistor amp, but then it would lose the shine of all being run from a single chip (yes, I know, but let's just play along with the misnomer).  Guess a darlington pair might be the right solution.. the amp "design" was "hey what's laying around in the bin?" and hasn't exactly been designed for ideal operation..

After turkey day, I'll take a shot at the circuit.  Three main design changes, hopefully without much added complexity:

1) increased gain on the microphone for better sensitivity
2) adding a direct-coupled input, for taking in line-level and/or headphone-jack-level input, so it can be "fed" from an audio device or mp3 player
3) maybe some type of filter cap to reduce AC hum

A few changes in code also make sense, maybe beefing up the graphics a bit too, as they are meant to be a light show, not an analytical device... not to mention, the circuit as posted shows the capacitor reversed, etc... "Fritzing" isn't something you just load and get right the first time, methinks..

Circuit is now posted (first Fritzing attempt.. bear with me!) and a second video is going up...

http://blurtime.blogspot.com/2010/11/arduino-spectrum-with-video-out.html

Six resistors, a capacitor, a microphone, and a transistor  (I got six resistors and a microphone....)

[media]http://www.youtube.com/watch?v=6Lt3kTIzNFY[/media]

It doesn't help that the music is coming from a cheap speaker held by hand over a breadboard-mounted microphone either, I'm willing to bet.  Since the amplifier gain is not really where it should be for clean samples, a bit of data noise is also the result.  The fact that it worked at all the first time through is nothing short of a miracle- I'm cleaning up the circuit a bit before I post it also, as it is a total trainwreck on the board (see the pictures in the blog).

As for FPS, I'm going to time it after I do a few tweaks.  Right now, it's actually skipping the first band, due to a large amount of 60hz hum.  I may have to put some filtration in to take some of it out, also it will help if I run from battery rather than a half-wave rectified wall wart, I'm sure.

However, happened upon some hockey game tickets for tonight's game (Boston Bruins v New Jersey Devils).. I'm not a lunatic fan, but I like going to almost any kind of live event, if only to people watch.  It's a good way to reassure yourself that you really AREN'T the biggest freak of nature on the planet.  The Bruins will be getting my attention for the next few hours.. but I'll probably be doing some twiddling with the beastie over the next day or so.

If I had to venture a guess, I'd say it's probably in the 10-12 FPS range.. the Tvout line drawing is actually the big cpu hog...  I find that amazing, as the transformation provides 64-band data, roughly 500Hz per band, to give us 0-32kHz (roughly) on the display in 64 bands, in realtime, in C, on an AVR.  Very impressive, poor little AVR has got to be going flat out!

Incidentally, the code should work if you have another source feeding the Analog input... I used a microphone for this version (plug into TV, set it down, and it displays ambient sound on TV), but a direct-coupled version of course would be much cleaner.  The resistors for the TVout library (one 330ohm, one 1kohm) are the only hardware required other than something feeding the A/D input.  Conversion to whatever source is simply a matter of getting a decent signal to the A/D converter.

I'm considering a circuit that would use PWM to charge a capacitor to feed the aref pin... thereby making aref variable by changing the PWM ratio... giving me a sort of automatic gain control via software, on the analog inputs.  Got any thoughts on the feasibility?  As you know, I'm likely to attempt things that I don't know any better than to try.. and sometimes succeed...

Hmm.. well, converted to AVI and YouTube preferred that.  Here's video of it running, "listening" to a little AC/DC.

Taking forever for the video to be processed by blogger software.  My little Kodak does it's filming in Quicktime MOV's, which for some reason takes forever for vendors to process into post-able format.  For what it's worth, posting the video to YouTube also just in case, they are usually a little better..

After only minor tweaking, a project I had in mind worked on the first try... a (near) Real-time audio spectrum analyzer light show.  The goal was to produce an amusing party display, and isn't intended to be used for any real purposes.. just fun!

There's a lot of room for improvement, feel free to tweak the design- the single-transistor amplifier is barely enough to use, my next version will chain two transistors in a Darlington array to increase the gain.  The Fast Fourier Transformation (FFT) is thanks to a Arduino forum post- 8-bit FFT in C.  Coupled with the TVout library also found here, it's a working design if not optimal!

Link to Project:
http://blurtime.blogspot.com/2010/11/arduino-realtime-audio-spectrum.html

Link to 8bit FFT code in C that made this possible:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1286718155

This was also done for other machines, in fact, I remember clearly writing code for Atari 400 that does color by artifact.  Note that I think it only works for CRT's, I don't think the process would work on an LCD or other screen.  You should be able to experiment to get the effect... the whole idea is spacing vertical, horizontal, or diagonal lines at regular intervals.  You essentially cut your resolution by using two (or more) pixels per "dot", but you gain some basic "color".  To test it for yourself, just write some code for your lib there, and see what "colors" you get using different patterns.  If I remember, it only gave you a palette of half a dozen psuedo-colors, but it was useful when you had nothing else..

I do also think it required that hrez be rather high (320 or more) because it had to do somehow with overscan..

I remember that the base code that I used was from COMPUTE! magazine, if I had to guess, probably 1984-85ish, if that helps..