Log in

No account? Create an account
More xmas light thoughts - brad's life — LiveJournal [entries|archive|friends|userinfo]
Brad Fitzpatrick

[ website | bradfitz.com ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

More xmas light thoughts [Nov. 26th, 2003|12:34 pm]
Brad Fitzpatrick
Yeah, using a parallel port to drive the xmas light grid would be much easier. Thanks for all the recommendations. And the parapin library makes it easy.

So, I can get a 74LS74 TTL component which has two D-flip-flops for like $0.60.... need then like 45 of those. That doesn't cost much. Will also need a transistor for each flip-flop too... ideally I could find a TTL component with both a flip-flop and transitor in it.

Guess I need to run constant power down both the bottom and right sides to power the flip-flops, and then a separate power down the bottom which I turn on and off for the single pixel that's lit at a time. I wish I had a good tool to draw a schematic with.

Haven't thought about packaging at all.... it's all going to get wet. If I have ~25 of these TTL components every 6 inches down the side, maybe I can drown them in epoxy blobs? I'd prefer to do that than run a ton of wires from the base. This all needs to take apart well and connect in pieces.

My calculations about bandwidth before were totally wrong. I'm basically scanning a single dot over the 54*40 grid and conditionally lighting it at every location.... so that's 54*40 = 2160 locations... each location will take a write from the parallel port to setup the signal (with clock low), then another to bring clock high, then another two to optionally light/unlight the pixel.... so that's, what? 8640 signal changes per screen? And the parallel port can do like 11 Mbps (more than USB 1.0, I recall?) with 12 in/out pins? So 1 Mbps for a single pin? Um, should be plenty fast.

Man, I've been re-reading my college electronics book. Things are slowly coming back, but I really don't know what I'm doing. I suppose I should go pick up some parts and start tinkering with a small-scale version.

[User Picture]From: edm
2003-11-27 10:59 am (UTC)
I'm not sure how you get to needing 2048 8-bit latches. IIRC you were doing something like a 40 * 56 light grid. Using 8-bit latches (which should be something like a quarter each in quantity) it seems to me that you'd need 40*56/8 = 280 latches. 280 * 0.25 = $70. Okay, it's not zero, but $70 doesn't seem _that_ high to me for a good result, especially since it'd allow the rest of your scan rate to be slower (eg, updates only on change) hence simplifying a bunch of other things.

But hey, it's your light grid and your house. If you want to refresh it every 40th of a second with 40 times the voltage and rely on it "averaging out the same" that'll probably be okay too. You'll definitely need long persistence lights though; anything that switches off quickly will tend to flicker. And if you have long persistence lights, you'll probably find that you can't do any rapid movements without "smudging" -- slideshow style changes would probably work best in that context, rather than animation. The latches and short persistence lights approach should let you do reasonable animation, and with a relatively low data rate providing the program driving it does frame to frame update optimisations.

(Reply) (Parent) (Thread)
[User Picture]From: brad
2003-11-27 01:57 pm (UTC)
We investigated using 8 bit and 16 bit shift registers (with serial shift in/out and parallel out) but the wiring would've been hell to do by hand. We even found components that could drive 8-16 20mA lamps, without extra line drivers/transitors, but that's a shitload of soldering and wire runs, not to mention somehow encasing all those components throughout the grid. With the wire grid approach we only have to wire 2048 * 2 connections, then some work on two sides.

I don't think flickering will be a problem. In fact, it's looking like grayscale will even be possible, since it'll be refreshing so often. But we'll see I guess.
(Reply) (Parent) (Thread)