I came into possession of the device pictured above a while back with the intent of reverse engineering it without any documentation to begin with. At the time I felt it would be an interesting exercise in using my EE intuition to figure out someone else’s work and repurposing it for my own use. I’ve always been inspired by the ingenuity of hackers on Hack-A-Day and I felt this would be a great starting point for my hacking career. From first glance, the device is obviously some kind of LED display wired by hand. I hope to figure out the chips/interconnections that drive the display by reading datasheets and probing around with the multimeter. By the end of this I will be able to design my own controller hardware and write code that will make use of the display. A side goal of this project is to make use of a new tool I purchased, the bus pirate, which allows for a terminal based method of testing IC communications.
With closer observation it becomes apparent that the display consists of 20 individual 8×8 LED matrices arranged in 4 rows and 5 columns. On the bottom there are two different IC’s: a 20 pin chip of which there are four, and a smaller 16 pin chip of which there are many. These IC’s I assumed were some kind of LED driver, most likely shift registers that are daisy chained in some fashion. I was unsure what the difference was between the big/small chips at the time though. Moving my attention to the jumpers, there’s what appears to be a power connector with the conventional red/black wires that connect to the top jumper. The middle jumper appears to be some kind of programming header. Finally, the bottom jumper appears to be some form of electrical isolation for certain parts of the circuit.
I then set out to read up on the datasheets for the three components LTP14188A01 (Display), TB62710P (20-pin IC), and TB62725P (16-pin IC). What I found most surprising was that each display’s pixel consisted of two LED’s for green and orange. The rows were common anode and the column cathodes were unique to each LED. The two IC’s were both LED drivers as expected . Without getting too in depth with the datasheets they appeared to offer identical functionality short of the bigger chip offering the ability to send serial out to two different chips. They may also be able to source current which would make sense from a design standpoint, but I’d have to check the datasheet again. However, both operate as latchable shift registers with the possibility of daisy chaining to minimize the number of SPI buses.
I now had to figure out exactly how this thing was wired using nothing but my trusty multimeter, continuity testing, and my intuition. First I tried to verify my assumption from early on regarding the power connectors, this led to me finding out that the bottom jumpers were put in place to ground certain parts of the circuit. Next was the supposed programming header. My approach was to touch a single pin on the connector and tap the IC pins until it beeped. Then I looked it up on the datasheet and wrote it down and checked to see if the connection was shared by other chips. By the end I found the pinout for the header and got a good idea as to how the entire thing was organized which I’ve sketched to the left.
There are 12 SPI buses that share common clock and enable lines. Latching is separated by the row and column drivers. You can look at the display as being divided into rows of matrices. A single row driver is connected to the common anode of the row pins of each matrix and is driven by it’s own SPI bus. For each row there are two groups of five LED drivers daisy chained together. Each of these drive the 40 cathodes of the columns for a specific color. A unique SPI bus is assigned to green and orange columns for each row unit.
With the hardware figured out, I have a good idea as to how to make use of the display. Data is loaded onto the shift registers 4 rows at a time using the 12 SPI buses. The latch pins are strobed lighting up the LED’s in a single row. The process is repeated for the 8 rows per matrix faster than the eye can see. Thanks to persistence of vision, an image emerges. I’m a little disappointed by the design of this device though because of the 12 SPI buses required for it to work. This means either a single MCU must have the requisite SPI buses or some synchronization scheme must be implemented between multiple devices. Will need some time to figure out how this device was intended to be used. I hope to actually get to writing some test code soon.