LED Matrix Display

Putting some surplus LiteOn LTP2558AA modules to use

Similar projects worth following
I came upon a bunch of these 5x8 LED modules while wandering the aisles of our local electronic surplus shop. A tube of 20 of them was $16US and it followed me home. The modules are about 2.3" x 1.4" with each dot supporting red and green. After some searching, the best drivers that I found were the IS32FL3738 chips. In the interest of keeping PCB costs down, I decided to make individual driver PCBs for each module, and mount them on a plate. Two driver chips are required per module, one for red and one for green. The driver chips use an I2C interface, and there are 4 address options. In order to run more than 4 of the chips (2 modules worth), I put an I2C address translator chip on each module. There was no end use for these modules in mind when I found them, but I think I will build a clock that shows the day of the week and date/time.

These LiteOn LTP2558AA LED modules came from the local surplus shop ( They have a LOT of these beasts in stock. Usable data sheets were found on the LiteOn web site.

LiteOn LTP2558AA LED Module With a Familiar Object for Scale Reference.
LiteOn LTP2558AA LED Module With a Familiar Object for Scale Reference.

This is my first dive into matrix LED stuff. Driving them seems a little bit like driving a video display, but only sort of. I looked at options for driving them from raw drivers and a SPI interface to fully integrated controller/driver chips. In order to support the red and green LEDs, there are two separate sets of row and column pins on each module. Each of the matrices has its own driver chip. The ISSI IS32FL3738 chips support up to a 6x8 matrix, provide current control and dimming options and two of them will fit on a PCB that sits under each module. They are also readily available and fairly inexpensive. I roughed out an electronic design and laid out a 4 layer PCB to mess with.

Rev 1 Driver PCB test fit on the back of an LED module.
Rev 1 Driver PCB test fit on the back of an LED module.

The boards came back from OSH Park and I built up the first one. The two LED controller chips are visible in the center of the board and the I2C address translator (LTC4316) at the lower left corner. The I2C bus and sync signal will route from module to module via the connector on the lower left edge of the board. Power connections will be done in a star configuration ending at the power connector above the bus connector.

From the IS32FL3738 data sheet, it sounded like I needed direct routing from the driver outputs to the LED module pins due to current requirements. The driver chips require half a dozen or so passive components. In order to minimize the routing interuptions, I put the passive components on the back side of the board. There are ground/heat sink pads on the bottom side of the driver chips. In order to get a good solder connection to the pad, I populated the top side of the board and reflowed the solder on my hot plate. The passives on the back side got installed and hand soldered which is a pretty fiddly process.

The rev 1 board was designed with address translation on the upper 3 bits only, with one translation configuration resulting in an undesirable address (0) for the red controller.

In order to simplify the build and get address translation on both the upper and lower nibbles of the address, I did an iteration on the board design. All of the passive components got moved to the top side of the board. I also narrowed the board slightly so that the board fits completely under the module. The new boards have been sent out and should be returning from OSH Park early this week.

Documentation on the IS32FL3738 chips is pretty terse and this is the first time I have messed with them. In order to figure out how to drive the chips, I used a PC based USB to I2C dongle (TotalPhase Systems Aardvark) and a tool that I wrote that accepts text file input and drives the I2C bus. I roughed out a minimal initialization sequence for one of the driver chips and got fairly close. It took a couple of hours of experimentation to get the first LED to turn on. Then I progressed to controlling multiple rows and columns and getting the green controller operating. The red and green LEDs look yellow when both are lit.

In order to generate the data for actual characters, I wrote a tool in Labview to take LED on/off data from a GUI and output it as a .csv file formatted for the LED ON/OFF registers on the IS32FL3738 chip. Labview is a good tool to generate GUI interfaces quickly for me. The bit manipulation and data handling capabilities adequate for this type of work.

The IS32FL3738 chips support a 6x8 matrix, but I am only using a 5x8 matrix. I included the extra column and data in the output for completeness. The tool supports reading an existing data file for editing. Click on a dot...

Read more »

Adobe Portable Document Format - 122.53 kB - 08/28/2020 at 02:17


Comma-Separated Values - 947.00 bytes - 08/28/2020 at 02:17



Schematic for LiteOn LTP2558AA test module. R1p1

Adobe Portable Document Format - 241.67 kB - 08/03/2020 at 19:13


Bill of Materials-Display1.csv

Bill of Materials for LiteOn LTP2558AA test module. R1p1

Comma-Separated Values - 1.52 kB - 08/03/2020 at 19:12


  • Ported the driver code over to the Single Driver display modules

    Bharbour3 days ago 0 comments

    Most of the work on the #GPS Driven Clock project is done. As mentioned in earlier log files, the dual driver display modules were too expensive, so I developed driver board using a different driver chip (ISSI IS31FL3730) that is about 40% of the cost of the dual driver modules. When I started on the clock project, I had just gotten the first of the single driver modules built up and minimally tested.

    This morning, I built up the other two PCBs for a total of 3 of these displays operating. In order to drive then new displays with more than just test code, I ported the software drivers over to deal with the IS31FL3730 chip. The architecture of the new chip is quite a bit simpler than the previous one, so the initialization sequence changed and there is only one chip per module to drive. Because of the way that the display had to connect to the driver chip, the data format for the green LEDs is rotated 90 degrees from the format for the red LED data. I brute forced this with a second character generator table rather than rotatating the data in real time. The character generator tables are 768 bytes per table, which is not too ugly.

    The current control register on the new chip is a wierd, discontinuous thing, so I need to write the code to map a linear input value to the required register data format.

    The new chips only support 4 different I2C addresses, and I did not put an address translator chip on each board, as the translator chips cost more than 2X the cost of the display driver chips. I have a bus splitter/address translator board laid out already that will let me run 4 separate bus segments with their addresses mapped to unique spaces, so one of those boards will support up to 16 display modules. Also, the power for the displays and the power for the address translator chips are supplied through different connectors on the splitter translator board. This will allow me to run the I2C bus on the microcontroller side at 3.3V and the individual I2C buses to the displays at 5V which should give more headroom on the LED supply from driver chips.

  • Strange I2C Issue Solved

    Bharbour08/28/2020 at 19:43 0 comments

    On the build of the last three boards, one of the boards refused to respind to "pings" on the I2C bus to one of the IS32FL2728 chips. The "ping" is just a read command that gets no data. The other 8 boards had no issues on this with both chips responding as expected through the LTC4316 address translater chip. The board accepted write operations and commands to both controllers normally. The I2C address translation values were picked to not collide with any of the other 8 controllers on the bus. There are some special purpose reserved addresses at the extreme low and high address areas and I avoided them as well.

    Thinking that if one of the addresses did respond and the other one did not, the I2C bus was probably good and the IS32FL3738 chip that was not responding had a problem. After lots of un-rewarding inspection of the board and verifying power and I2C goodness to the chip, I replaced the IS32FL3738 chip that was not responding. No joy, it still did not respond. In a fit of irritation, I swapped a few passive components related to the chip with similar results.

    I checked the soldering around the address translater chip and all looked fine. Looking at the I2C signals with a scope on both sides of the translater chip, looked about as good as one would expect of an I2C bus with 18 devices on it. I did not put testpoints on the board that would have made it easier to hook a bus sniffer up and examine the translater output traffic, so that was not done.

    The application that I am using these parts for does not need to read anything back from the IS32FL3738 chips, so I put the problem aside for a few days. Leaving something that glaring wrong on a project bothered me, so I did not decide to just ignore the issue.

    The way that the translater chip was configured, the responsive chip was at 8 bit address 0x5A and the missing response should have been at 0x50. It occurred to me that for some reason, the LTC4316 address translater chip might not be translating the address correctly. I searched the data sheet on reserved addresses on the I2C bus and 0x50 (7 bit 0x28) might be a reserved address. There was no mention of it. I started digging through the I2C spec and saw a mention of a strange PMBus zone read protocol involving address 0x50, but no details. The PMBus document did not mention it either.

    Figuring that the problem was only seen on a read operation, it might be related to that zone read thing, so I changed the translation address to put it at 0xD0 and 0xDA. Bingo, both IS32FL3738 chips responded to the ping. I can only assume that the LTC4316 address translater chip was refusing to translate the 0x50 address for a read operation.

  • The Boards Are Back

    Bharbour08/27/2020 at 12:39 0 comments

    The last 3 of the rev 1.1 boards are back from OSH Park and assembled. The chassis that I designed for 9 displays is now populated and looks good.

    Fully Populated Display Panel
    Fully Populated Display Panel

    I started working on the application code for using these beasts while I was waiting for the boards to come back. It will be a GPS driven clock. I also built a breakout board for an ambient light sensor chip to use for automatically dimming the clock.

    In the previous log file, I mentioned doing a PCB for a different driver chip that would be a less expensive board. After totalling the costs on the bill of materials, the new boards come out at about 40% of the cost of the rev 1.1 boards.

    The new PCB design is a 2 layer board because there is a lot less routing with a single chip than 3 chips, and the heat sinking did not appear to be the problem I was expecting on the original design. Using only 2 layers reduced the cost of the PCB by 50% . A single jumper wire was needed to route one signal on 2 layers, so that one blue wire is a feature, not a mistake :)

    Prototype boards for the new design came back from OSH Park and assembled easily enough. I took care of several convenience issues with the new design like having jumper selectable address and terminator enable. To keep size down on the jumpers, I used the 1.27mm header and shunt blocks.

    Component Side of New Driver Board Design
    Component side of new driver board design
    Assembled Display Module
    Assembled display module.

    Because of the way the matrices of LEDs are implemented in the LiteOn displays, I had to rotate the matrix of the green LEDs by 90 degrees. The red matrix is wired as a common cathode matrix. If the green matrix had been wired as a common anode matrix, it would have matched the intended configuration of the IS32FL3730 chips, but no joy. The displays have two 5x8 common cathode matrices, one red and one green. I wound up connecting the red matrix in the conventional way and connecting the green matrix with the column driver outputs connected to the LED row inputs and the row driver outputs connected to the LED column inputs. This effectively rotates the green matrix 90 degrees. In use, the time penalty of rotating the character generator matrix 90 degrees while updating the display is probably more of a problem than the space incurred with a second character generator data set, so a second character generator data set with the data already rotated will solve that problem.

    Rotating the matrix also has some implications about current control when multiple LEDs are lit in a single column,  but that needs more testing to see if it will be a problem. I have a home written tool that allows sending I2C write transactions controlled by a simple text file with a lot of flexability. It uses the Total Phase Systems Aardvark to go from USB to I2C, SPI or GPIO. The tool called VarkBlaster is useful for exploring configuration and control of parts like this. I wrote a few scripts that drive the display with varying numbers of LEDs lit per row and per column, and there was no difference visible to me in the LED itensity.

    Using the character generator array that I developed for the rev 1.1 IS32FL3738 based boards, I wrote a tool that translates that into the register bit formats for the two matrices in the IS31FL3730 chips and displayed a couple of characters from each array to sanity check it. So far so good. The character generator arrays form a lookup table mapping ASCII code to register values to display the character. In general, the brightness seems a little low but I have not started experimenting with the LED current control register yet.

  • Rev 1.1 PC Boards are Back

    Bharbour08/06/2020 at 17:58 0 comments

    The rev 1.1 PC Boards are back from OSH Park. I built up all three of them. They are much quicker to assemble since all of the components are on the top side of the board except the sockets for the LED Matrix.

    Assembled Rev 1.1 Board
    Assembled Rev 1.1 Board

    I made sure to keep the bolt pattern and it's relationship to the LED Matrix the same as the rev 1.0 boards so they will both live on a mounting plate and be interchangable with the rev 1.0 boards. I also added resistors to support translating the low nibble of the I2C address that were lacking on the rev 1.0 boards.

    I now have 6 of these boards built and operating, and I want 3 more. Those will be ordered this weekend.

    Display Panel With 6 Modules Installed
    Display Panel With 6 Modules Installed

    The cost on these modules is higher than I am happy with. Separate driver chips (IS32FL3738) are used, one for red and one for green. There are only 4 options for I2C address selection on these driver chips, so I added an I2C address translator to each board to allow running more than 2 boards on an I2C bus. The PCB is a 4 layer board. I chose to use a 4 layer board to get low impedance ground and power distribution to both display drivers and the address translator. Also, the driver chips have a heat spreader pad under them and I wanted to be able to use a ground plane for heat sinking the drivers.

    Poking around in the projects on Hackaday, I found a project that is very similar to this one: #PIXIE - Chainable, Dual 5*7 Micro-LED Displays! The display driver chip (IS31FL3730) used on that project is capable of driving both the red and green matrices in the display, so I laid out a board to use that chip. These chips also support 4 choices for the I2C address, but only one chip is needed per board, allowing up to 4 displays on an I2C bus segment. I removed the I2C address translator and added jumpers to select the address and enable/disable the I2C terminators. My concerns about heatsinking the driver chip did not seem warranted with the rev 1.0 boards, the drivers only run a few degrees above ambient temperature. With a single driver chip to supply power and ground to, a 2 layer board makes more sense. With the changes listed above, the parts count is less than half of what the current boards are using, and it will go on a 2 layer board. To get the same functionality as the previous boards, either bus multiplexing or address translators are going to have to go into a system somewhere. A prototype board for the new driver is ready to send out to OSH Park.

    The new driver chip handles the two matrices in kind of a strange way. One matrix connects to the driver pins labelled row[8:1} and column[8:1] matching the LED pin designations. This is a common cathode matrix. The second matrix looks to be a common anode matrix, but since both matrices in the LED block are common cathode, I rotated the second matrix, connecting driver rows to LED columns and driver columns to LED rows. It is not clear from the documentation whether the hardware corrects for this in the registers for the second matrix or not. I am just going to have to build one and mess with it. If the hardware does not correct for this, it will be necesary to do the pixel rotation in software.

    It is not clear what the maximum LED current is for the new driver. The electrical specs in the data sheet say that the maximum is 40mA, but in the register set description, there is an option for 75mA. Running 40mA per LED may be enough, but that is another thing to test when the boards get back.

    The IS31FL3730 uses my least favorite package for assembly at home, the QFN leadless package. None the less, it is worth trying. It is not like there is a deadline or anything.

View all 4 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates