Jim Harvey and I got together at the space 2/16 to test and install the first 6 columns’ worth of latch boards. First step was to test them. That was a very good idea, since there were some bad traces I’d forgotten to fix. It would have been really annoying to discover the problems only after the boards were soldered into the display!
I made up a sort of ‘bed of nails’ tester that allows an Arduino to power and drive the inputs to the latch, and connects LEDs to its outputs to see the results. I needed 7 data bits in (for the 7 LEDs in the latched column), a clock, and of course power and ground. Trying to simplify the connections to the Arduino, I chose to use D0-D7 for the 8 data bits, since they’re all on one header. Since Do/D1 are the serial I/O pins, I can’t use serial I/O while using this tester. Setting those pins as output does allow them to be used for normal I/O, though.
I laid the board out by starting with the latch board layout and putting pads to solder the ‘nails’ to as wires or rectangles on another layer. When they looked like they were in reasonable places, I deleted the normal top and pad layers that made up the real board.
The first oops was that I pictured the LEDs on the non-foil side of the board, but laid the solder pads out so the foil was on top. Fine, so the LEDs will sit up in the air. I figured bending all the pins (0.025″ square pins salvaged from some old wire wrap board) would be a hassle, and I was right. I got them pretty close, and Jim H lapped them on some emery paper and got their tips a little closer to coplanar.
Second oops was when I realized we’d need a handle to press the tester down on the board under test. I bent a little acrylic handle and epoxied it on, but located it where it was 
convenient instead of where it needed to be: You have to put pressure at sort of the geographic center of all the pins, not over where I glued the handle on. Shoulda seen that one coming. We ended up just pressing on the board with fingers to try to make all 17 contacts at once. Here’s Jim trying to do that (and ignoring the handle).
The arbitrary test pattern code did 2 cycles of cylon 1 LED-at-a-time sweeps, followed by 2 cycles of alternate LEDs on. The latter was a test that the latch actually latched, as I wrote the data, kicked the clock, then wrote zeros of data before sleeping. The code didn’t work first try, as I’d reordered a couple of pins as a tradeoff in the PCB layout but forgot to do it in the code. Here’s a clip of what it looks like with the final code and when you actually get all the contacts to make on a good board: LatchTester1
Of course all the boards didn’t work first try. (That’s why we test!) We found a few bad (reflowed!) solder joints, which I fixed using solder-loaded braid to apply solder. Jim found some hairline disconnects in some traces by inspecting very closely. We soldered fine wires across those, and finally got all the boards working. Time to install!
Jim had made a little jig he hoped would help hold the boards in place while we soldered their big pads to the LED 
anodes. It turned out we could hold them quite well with one just clothes pin (which Jim had cleverly brought along), so we ended up doing that. Here’s the first board soldered in place:
We hooked it up with the latch tester code and sure enough, the first column of LEDs in the display danced the tester dance. Encouraged, I put the other 5 boards in. Here’s a picture of soldering in the data bus that provides parallel data to all the boards. Yes, it’s labor intensive.
The original design had four 74154 1-of-16 decoders providing an (active low) column select. We planned to use that to clock the latches. Here’s the first crude wiring of those latch clocks. Unfortunately – probably partly because we digitalWrite() the address bits out one at a time – the latches don’t reliably latch the correct data. (As the address bits change one by one the 74154 selects probably go active on unintended columns. And running fast TTL pulses on those loose wires is asking for trouble as well!) So while the LEDs flashed around with all 6 boards in place and a simple scrolling pattern in the Arduino driving it, they clearly didn’t do what they were supposed to do.
So the next step is troubleshooting the addressing/latch clocks. I have a little USBee logic analyzer that would let us look at what actually shows up on the select lines, but I’m kind of afraid we’ll need to come up with a whole new 1-of-64 addressing scheme that guarantees clean clocks. I won’t even bother to make up any more latch boards until we can demonstrate that we can get those good clock pulses.
Update 2/17/12: Oops – tests of all 6 boards were invalid. I forgot to provide power to the 74154s in the display box! It’s always nice when finding out your tests were invalid is a good thing.
We should be able to provide clean 6-bit addresses to the ‘154s if we use 6 bits of 74373/4 octal latch to buffer the bit-by-bit changing address the Arduino puts out and clocking it out when we’ve written all 6 bits. That’s a pretty simple hack, and I even have some ‘373s and ‘374s.
Update 2/28/12: Went to the space 2/23 and after Eric’s excellent Christmas (and Halloween) light display talk, made some good progress. First was rewiring the 6 input lines to the ‘154 board. I chopped down the silly long ribbon cable, kept the 6 pin male end, and connected nicely to the pins on the blue board.
Next was a more proper power interconnect. A terminal block to connect to an external supply now powers both the 154 board and the latch boards (and their LEDs). (Schlocky picture, but that’s how we learn.) A little hot melt and it all stays in place.
With the cabling a little more sensible, I tested using a direct port write to change the state of all 6 address lines at once (instead of writing several invalid addresses as the bits changed one by one with digitalWrite()). After several rounds of fixing stupid coding, it almost worked! The first hard coded pattern was just 2 sawtooths (sawteeth?) scrolling in opposite directions. But column 1 just kind of sat there with a couple of LEDs always on. Investigation showed that when we were inspecting the boards for bad traces, on the board with visible lengthwise hairline opens, we fixed the traces for data, but ignored the fact that the opens went thru the clock pad. When I soldered the clock line to the pad, Murphy made me solder to the part separated from the trace that went to the chip. It just barely worked (but worked well enough the first night that Jim and I both watched correct patterns on all 7 LEDs). Then while we weren’t watching, it failed. I resoldered the clock line to the side of the pad connected to the chip, and it worked fine. Here’s a clip. Sorry about the orientation. I wasted way more time than I should have trying to fix it. (I could rotate it but then couldn’t fix the aspect ratio.)
Encouraged, I hand coded pixels for “W88”. Here’s a clip. It’s not perfect (the display – we know the clip is sideways and crappy), but it’s pretty clearly working. Some columns sort of fade and blink. That’s the real display, not a video artifact.
The interesting surprise is that the low resolution (7 pixels vertical and 0.5″ pixel pitch) makes the display kind of disappointing. I suggest making up (and testing and installing) maybe 10 more boards so we can get at least a minimal idea how it will actually look. At that point we can make the call whether it’s worth all the effort to populate the other 48 columns. It will definitely have a ‘retro’ look, but I don’t know whether that will save it from just looking kind of pathetic. That evaluation is for a little later.
So we have an INPUT of a chip that can somehow pull the active output of a 154 down enough to make a visible difference in an LED. And that board never lights its target LEDs as bright as it should, and doesn’t always latch data in (or at least doesn’t display it on its 
output LEDs). What kind of failure or short on the board could make the clock input draw a lot of current? Sorry, didn’t feel the temperature of the chip – shoulda. And it doesn’t always pull a high level down – apparently only when it has to light its LEDs. The only test pattern we’ve looked at is all LEDs on. It would be interesting to see if it was less bad for fewer LEDs. For reference, here’s the board layout.
OK – what if the chip wasn’t getting power and was effectively being powered by current drawn into that clock input? Is that even possible? High draw from a bunch of LEDs (in addition to powering the chip itself) might well pull that 154 output down. I guess those are the next things to look at. Unfortunately, I don’t have a spare board (yet) to explore behaviors like that.
Trying to get a board out from the middle (boards in place on both sides) with the data bus laid into slots on the top of the board will be a challenge. It would be embarrassing if it was just a cold solder joint on the +5 line for that board, but I guess that would be better than having to pull the board out.
Could you put the test code up on Dropbox so I can think about it?
The code is LedDisplay2.pde under ScrollingLED in the dropbox. There are 2 simple patterns I tried. Each column of data is one array element. There are funcs to write a value to the data ‘bus’ and to write an addr to A0-A5.
As soon as I realized writing the addr bits one by one would cause all kinds of semi-random false selects coming out of the ‘154s, I tried to implement a sort of strobe on the addr lines by setting the high bit to 1, then changing all the bits (one at a time with digitalWrite() ), then setting the hi bit back to what it should be. That way I hoped all the noise would be in the high half of the select lines. It didn’t work much different. That’s a hack at best, since it would limit us to 32 columns.
I’m embarrassed to say the latches may have been running below 5V. There was a 39 ohm resistor on the + side of the big supply and I connected to its loose end (not to the end connected to +5 on the supply) for the latches. I noticed after while and hooked the clip lead supplying power to the boards to the proper +5V. LEDs got some brighter (as expected) but it seemed to work about as poorly. Then for reasons I can’t explain I connected back to the stupid side of the 39 ohms for the rest of the testing. Sorry, that made zero sense to do.
General wiring was fairly clean: Power and gnd from the big supply clipped directly to the #20s providing the power and gnd busses between the boards. That should supply the latches and of course the LEDs. I tacked the ground from the ribbon from that funny 2-part cable from the Arduino to the bus ground. No +5 from Arduino. I think that should be good.
Adding to the noise was the several feet of original ribbon carrying the address lines.
The 74154s don’t have any kind of CS or other enable. They expect clean bits in and change output immediately as inputs change. I hoped for a CS so maybe we could take our time writing the addr lines and then enable the 154, but no such luck. I haven’t looked for a part we might use for a clean 1-of-64 decoder. There must be something.
As a very short term test, we could take the 6 addr lines and run one as clock to each board, just to see if we could get clean behavior. But that doesn’t scale well.
Wait – I don’t think anything actually put +5 on the ‘154s!
From this pic http://jimlaurwilliams.org/wordpress/wp-content/uploads/2011/06/Electronics0181.jpg power to the 154s must have come from those other 2 pins from the middle of the ribbon. I’m sure I didn’t plug those into anything.
So that’s great news: all those tests that didn’t work were invalid!
When do you have another window to come play?
We could use a 6 bit latch with a real clock, hook the current 6 addr lines from the Arduino to those latch inputs, add one more Arduino bit as a clock to that latch, and get cleanly-changing 6 bit addresses to drive the 154s. That certainly sounds doable.
Those haywired clock lines in the last pic in the post above are still pretty scary. Maybe a couple of 32 conductor ribbons across the tops of the boards with one wire split off for the clock of each board? Connecting the other ends of those ribbons is still messy, though.
My best guess:
For the test program to work in the actual sign hardware, you will have to define another bit to strobe the data. D13 would be nice, you can watch the led blink out when it strobes. Each 154 has two output enables, ground one of those at each chip, and wire the other OEs all together and connect to D13. Then in your test code loop, after you set row and column data, wiggle D13 from high to low to high. That will drive the selected 154 output low then back high which according to the 574 truth table will clock the row data across the chip.
Don’t know when I can come up again, having a contractor in next week to do insulation. Will let you know. This is fun.
Very nice try, but I _think_ they use those 2 output enables to implement the high 2 bits of the 6 bit address. I _think_ the extra gate (a 7400?) takes the hi 2 addr bits (A, B) and provides the inverse of each. Then the 2 OEs of the four 154s are wired to:
(A,B) (A*,B) (A,B*) (A*,B*) so exactly one 154 gets both OEs low for each of the 4 possible combinations of A and B.
An alternative to the clocked 6 bit latch would be to use a real 2-to-4 decoder (active low), put the hi 2 addr bits on its inputs and run its 4 outputs to the first OE of each 154. Then tie all 4 of the second OEs together and bring them out to the new additional strobe line which idles high and pulses after the low 4 addr bits are stable exactly as you suggest.
The code (and requirement for one extra strobe bit) would be the same for either approach. A small benefit of the latch would be that none of the wire wrap wiring on the bottom of the board would change. We’d just disconnect the 6 addr lines from the 6 splayed wrap pins on the top (which we need to do anyway) and connect them to the latch output. Of course we’re probably going to have to pull the dumb blue board off and mess with the wrappings below to troubleshoot why the that 3rd 154s doesn’t select, so not having to mess with the bottom of the board may be moot.
It will be easy to make a 2-4 decoder with a hex inverter and a quad nand chip… Would leave two inverter sections available to use as buffers.
Here’s a relevant email thread:
I don’t think setup time is critical. We don’t care exactly when the address changes – just that all the bits change at the same time. I guess more accurately we need the addr bits to change so close to the same time that whatever propagation delays there are in the 154 chain (including that 7400 on the hi 2 bits) doesn’t have a chance to go to any false states – even for a very short time (like the minimum clock dwell time on the column latches).
My understanding (only from reading the port manip page on the arduino site) is that the port writes really are atomic – occur in one machine cycle. I would expect that would change the addr lines just (about?) as simultaneously as the output of our proposed address latch chip would.
Anyway, the uncertainties of those independent 154s and hoping they never produce incorrect output glitches is a valid concern when we have 64 latches intently listening for any sub-microsecond pulses on their clock lines. But stepping back to the practical world, I would propose that we change that address write function to use a direct port write and see if it works. If it does, we’re good. (And I won’t make up the 74373 latch board I completely laid out before the direct port write light bulb lit.)
I expect to be at the space Thursday eve and hope to make a little progress then (during/after Eric’s Christmas lights demo). You likely to make it?
I’m gonna copy this thread to the comments in the project notes, since it’s just this kind of analysis I’m trying to capture to maybe let me make better design decisions in the future.
——– Original Message ——–
Subject: Re: stable address for scrolling display
From: JAMES HARVEY
Date: Wed, February 22, 2012 9:42 am
To: Jim Williams
You can direct write six bits yes, might solve the problem. But in the end I think we need to find out how to strobe in the data else you might update the wrong column cuz the timing will be so critical. Port write takes a small amount of setup, see “port manipulation” on the arduino.cc site.
—
The only difference between men and boys, is the price of their toys.
From: Jim Williams
To: Jim Harvey
Sent: Tue, February 21, 2012 9:08:28 PM
Subject: stable address for scrolling display
You espoused using direct port writes some time ago. If we use A0..A5 – all on Port C – as the 6 bit column address, wouldn’t that give us clean transitions without any external latches or decoders?
And if so, why didn’t you gently beat me over the head until I stopped blowing off port writes?
Jim
Wow! Looks great. I see what you mean about the disappointing display though. Wonder if a diffuser in front of the LEDs would spread the light enough to merge the pixels. Are the column address bits wired to all four of the 154s? need to make sure we can drive four of them. And what about using the octal buffers to drive the rows?
I have to believe the column address bits go to all four 154s. Driving 4 loads shouldn’t be too hard. If we don’t just bail on the whole project because it looks puny, yes, I’d been thinking of maybe 4 octal buffers each driving 16 latch inputs. Haven’t done the fanout math yet.