First and foremost, big thanks to Damien for her time and effort on soldering 265 LEDs on peggy2 circuit board, which made my programming part possible to continue.
Instead of soldering LEDs directly onto the Peggy2 board, we have to use Ethernet cables as “extensions” in order to let LEDs fill our smartsurface. Single Red, Green, Blue, and White LEDs are grouped as a module and then soldered on a small printed circuit board, which is connected to one end of a Ethernet cable while the other end is soldered to peggy2 circuit board that provides us means to control each LED in the matrix through programming. The Ethernet theory was confirmed by the Peggy2’s vendor, Evil Mad Scientistand the longest cable we are using is about 3 ft, whose resistance should not caused any trouble for us to light up the LEDs.
The finished Peggy2 looked more like a octopus than a matrix. Besides the joy from seeing the completed device, I felt a bit concerned about possible shorting among those touching modules.
However, after we powered the board with the power adapter purchased from the same vendor, nearly half of the unit didn’t light up and there isn’t a single unit that has all its RGBW LEDs lighted up. They either had only one or two on. I didn’t upload any new sketch. So according to the manual, factory pre-programmed sketch is supposed to uniformly light up all the LEDs. The bright side is that at least we confirmed that cable+LED works as well as LED on its own.
Here comes the worst part: the two LED driver chips heated up very fast (they got super hot within ~5 sec). I checked the components and everything is soldered correctly according to the instruction except my teammate placed the socket for 328 microcontroller in the opposite direction but the microcontroller itself is in the correct position with its half-moon matched to the drawing on the board. I personally don’t think the mis-orientated socket is the source of the problem because a electric socket are just whole bunch of metals and plastic that holds a electronic component.
We then tried to test each connection on the board with a single DC power supply (30V 1A), with a voltage of 2.7V and a current of 0.01A. Sometime we saw when connecting to a LED, let’s say R2 of the RGBW unit#2 shown below, the LED R1 of unit#1 that is two row above dimly lighted up, even though nothing was connected to it. I’m not sure if it’s normal or not.
Row 1: W1, B1
Row 2. R1, G1
Row 3. W2, B2
Row 4. R2, G2
After hours of trouble-shooting, we decided it’s easier to map all the LED to their corresponding rows and columns by taping the “Octopus” to a wall, so hopefully we can find some “patterns” among those malfunctioned LEDs.
After trying different codes and circuit configurations for another couple hours, things stayed the same. Now it’s the time to get helps from pros on forums. First, special thanks to Windell on Evil Mad Scientist Forum for his bullet-speed reply at 2am in the morning.
It turned out that someone put the 2 LED driver chips at the wrong place. So the chips that are supposed to be on socket U4 U5 were placed on socket U2 U3 and vice versa. So the overheating chips. So the overheating chips I mentioned earlier are actually 74HC154 chips that control the columns of the display. Basically, someone switched chips that controls rows of the matrix with chips that controls columns. And here is what Windell said:
Yikes– That’ll do it! If you plug those in at the LED driver locations, one of their outputs is connected to ground– a short circuit that may explain the overheating. Those chips are not “power” chips, and I don’t believe that they have any thermal shutdown mechanism; they could easily be damaged. The other two chips (LED drivers) could also be damaged the same way. (Also: your LEDs will not light up anywhere near uniformly– I’ll guarantee that.)
The 74HC154 chips control the rows, and the LED driver chips control the columns. If you have rows out then it could be due to a problem with those chips. In any case, I’d strongly recommend replacing all four chips as a first step just to make sure that everything else is okay. If it is, then you could swap in the old chips one at a time (in the right places) to see if they are okay. Only the AVR (the ATmega328P) has firmware on board, so you can replace the other four chips with off-the-shelf components (or all five chips, if you have an AVR ISP programmer).
Since we only have three days till our final installation in the gallery, we decided to order some chips from Evil Mad Scientist. Good news is that they have chips in stock. Unfortunately, because of they are on sale, the shipping must be delayed up to one week while we only have three days. I then email sales manager Lenore M. Edman and thanks to him, our chips can be shipped on next day with FedEx overnight shipping.
Now it seems things are getting better. However, good days only lasted till the chips arrived on the next day. After I carefully replaced those delicate chips from the huge “Octopus” LED matrix taped on the wall, the whole matrix were still malfunctioning. Well, I must say some rows lit up but certainly, the repaired peggy2 board was far from meeting what we need.
After spending nearly 50 hours trying to fix poor peggy, we aborted any further attempt, because time was running out. Driven by the hope that “I might fix the board with another hour”, I actually spent the time budgeted for CMUcam3, which turned out to be even more complicated than a “Octupos” LED matrix.
Eric and Damien came up with peggy2 plan B. With some copper tape and some transistors, they managed to get a small LED “Octopus” that could only light up a row of LEDs altogether. Even though this matrix might not be as sophisticated as the original one that allows you to control each LED. But it’s a lot better than not having any LED on our final surface. Moreover, it’s very impressive for them to pull this off in just several hours. Good job!
For more detail: Peggy2: High And Low