Propellor Drives 32x16 RGB Message Board: 1/4 Scale Proof of Concept
tomcrawford
Posts: 1,127
Summary
This note describes a 32x16 RGB panel based on Propellor and readily available 8x8 common-anode RGB LED Modules. This is useful for scrolling message board applications. This supports seven colors only; three bits per pixel. I am looking to work with a layout/manufacturing guy and would like to end up with half a dozen panels for my efforts.
Background
I have been hobby-building scrolling message boards for several years now. A recent effort based on Sure Electronics 32x16 RG panels is described here.
http://forums.parallax.com/showthread.php/143098-PropClock-with-Scrolling-Pithy-Sayings
I have wanted to go to 7-color panels but havent been able to find any. There are a number of 8x8 RGB modules (including one from Parallax) but they each have problems for what I want to do.
My Requirements
Use common-anode 8x8 modules with Rainbowduino pinouts. From what I see on eBay, this is what will be available with multiple sources.
Three bits per pixel. RGB, one bit each. I believe this is fine for message boards and truly simplifies the implementation as compared to full color.
Dumb frame buffer.
Form factor and connectors same as Sure Electronics DP14211 5mm 32x16 RG
Progress to date
The attached photo shows a ¼ scale model on solderless breadboard. Adding six more 8x8 modules, 24 more TLC5916, perhaps more row drivers, and connectors gets you a 32x16 panel. I have mixed Spin/PASM code running to load buffers and refresh the display.
The attached movie
http://youtu.be/NB2qPsiQXSA
shows text scrolling and gives one some idea of the colors. I keep stumbling across the problem of making of movies of LEDs with a point-and-shoot camera. Trust me, its better than it looks.
Circuit Overview
Eight-way multiplexing is used. In a full panel, there are eight 8x8 RGB modules, arranged in a four by two array for a total of 32 columns of 16 rows. The modules are driven one row at a time (the panel is driven two rows at a time).
Each of four PASM cogs load 24 bits for each of two 8x8 modules. One Spin cog keeps track of the current row and controls the row drivers. Currently the display is refreshed at 360 Hz. One PASM cog reads serial data from the host and interprets commands.
TI TLC5916 Sink Drivers
Three TI TLC5916 8-bit current sink drivers, one for each color, control the column data for each module (24 pieces per panel). These are double buffered so that the propellor can load data for the next row while the current row is being displayed. The current is adjustable on a TLC basis; this allows controlling the overall brightness to compensate for varying ambient lighting conditions. This could also be used at final test to compensate for 8x8 RGB module variations
Row Drivers
I am currently using a Mitsubishi M5464 8-unit 500 mA source Darlington array as a row driver. These pull up to 5V and I have a HCT244 translator between the propellor and the array. This is a work in progress; I am thinking that a FET array may be better.
Host Interface
The data interface is one command enable, clock, and one bit data. Updating a 16-panel board at, say, 30 Hz means 1536 bits per panel times 16 times 30 says 750 KBit/second. I am currently doing 1.6 MBit/sec.
Having multiple panels strung together in a large message boards means panel selects. I am currently thinking DIP switches or jumpers and a header packet that identifies the panel.
Bells and Whistles
As currently specified, the panels are dumb frame buffers, which is just fine for what I want to do. But somehow it seems a shame not to make better use of the propellor. There are two unused cogs and something like 6000 unused longs. Here are some thoughts. Some of these ideas bring up the problem of sharing data among the panels; I am not seriously proposing any of them.
On-board fonts
Down-loadable bit-maps
Really fancy stuff like lines and circles.
Things Needing Done
I have to implement code to load the current values into the column drivers. I dont expect this to be an problem; the timing is well documented.
The Row drivers remain an issue. I dont know whether FETs would be a better choice and I dont know how many, if any, need to be paralleled.
Need to work out the details of panel select.
What I am Hoping for
Laying out a surface-mount board, let alone assembling it is more than I want to take on, so I am hoping to work with someone who has that kind of experience. I will undertake to make the code robust enough to put into production in exchange for several panels.
This note describes a 32x16 RGB panel based on Propellor and readily available 8x8 common-anode RGB LED Modules. This is useful for scrolling message board applications. This supports seven colors only; three bits per pixel. I am looking to work with a layout/manufacturing guy and would like to end up with half a dozen panels for my efforts.
Background
I have been hobby-building scrolling message boards for several years now. A recent effort based on Sure Electronics 32x16 RG panels is described here.
http://forums.parallax.com/showthread.php/143098-PropClock-with-Scrolling-Pithy-Sayings
I have wanted to go to 7-color panels but havent been able to find any. There are a number of 8x8 RGB modules (including one from Parallax) but they each have problems for what I want to do.
My Requirements
Use common-anode 8x8 modules with Rainbowduino pinouts. From what I see on eBay, this is what will be available with multiple sources.
Three bits per pixel. RGB, one bit each. I believe this is fine for message boards and truly simplifies the implementation as compared to full color.
Dumb frame buffer.
Form factor and connectors same as Sure Electronics DP14211 5mm 32x16 RG
Progress to date
The attached photo shows a ¼ scale model on solderless breadboard. Adding six more 8x8 modules, 24 more TLC5916, perhaps more row drivers, and connectors gets you a 32x16 panel. I have mixed Spin/PASM code running to load buffers and refresh the display.
The attached movie
http://youtu.be/NB2qPsiQXSA
shows text scrolling and gives one some idea of the colors. I keep stumbling across the problem of making of movies of LEDs with a point-and-shoot camera. Trust me, its better than it looks.
Circuit Overview
Eight-way multiplexing is used. In a full panel, there are eight 8x8 RGB modules, arranged in a four by two array for a total of 32 columns of 16 rows. The modules are driven one row at a time (the panel is driven two rows at a time).
Each of four PASM cogs load 24 bits for each of two 8x8 modules. One Spin cog keeps track of the current row and controls the row drivers. Currently the display is refreshed at 360 Hz. One PASM cog reads serial data from the host and interprets commands.
TI TLC5916 Sink Drivers
Three TI TLC5916 8-bit current sink drivers, one for each color, control the column data for each module (24 pieces per panel). These are double buffered so that the propellor can load data for the next row while the current row is being displayed. The current is adjustable on a TLC basis; this allows controlling the overall brightness to compensate for varying ambient lighting conditions. This could also be used at final test to compensate for 8x8 RGB module variations
Row Drivers
I am currently using a Mitsubishi M5464 8-unit 500 mA source Darlington array as a row driver. These pull up to 5V and I have a HCT244 translator between the propellor and the array. This is a work in progress; I am thinking that a FET array may be better.
Host Interface
The data interface is one command enable, clock, and one bit data. Updating a 16-panel board at, say, 30 Hz means 1536 bits per panel times 16 times 30 says 750 KBit/second. I am currently doing 1.6 MBit/sec.
Having multiple panels strung together in a large message boards means panel selects. I am currently thinking DIP switches or jumpers and a header packet that identifies the panel.
Bells and Whistles
As currently specified, the panels are dumb frame buffers, which is just fine for what I want to do. But somehow it seems a shame not to make better use of the propellor. There are two unused cogs and something like 6000 unused longs. Here are some thoughts. Some of these ideas bring up the problem of sharing data among the panels; I am not seriously proposing any of them.
On-board fonts
Down-loadable bit-maps
Really fancy stuff like lines and circles.
Things Needing Done
I have to implement code to load the current values into the column drivers. I dont expect this to be an problem; the timing is well documented.
The Row drivers remain an issue. I dont know whether FETs would be a better choice and I dont know how many, if any, need to be paralleled.
Need to work out the details of panel select.
What I am Hoping for
Laying out a surface-mount board, let alone assembling it is more than I want to take on, so I am hoping to work with someone who has that kind of experience. I will undertake to make the code robust enough to put into production in exchange for several panels.
pdf
2M
Comments
I've played with some 8x8 RGB arrays myself. I used high power shift registers to control the columns. I've been reading the TLC5916 datasheet to see how they compare with the TPIC6B595 shift registers I'm using. So far, I'm not seeing a downside to using the TLC5916 rather than shift registers. The TLC5916 look like they're less expensive than the TPIC6B595 chips.
I can understand your limiting the colors to 3-bit. I find I have to trade off between color depth and the number of arrays I've driving. I can drive two arrays with 15-bit color if I use six arrays, I have to reduce to 3-bit color. My plan is to use multiple cogs in order to keep deeper color depth when driving multiple arrays.
At some point, I'll need to worry about Prop to Prop communication when get around to building my LED coffee table (I don't drink coffee so I'm not in a rush).
I'm using pair of SN754410 dual half-bridges to drive the rows, I don't think this is a good option. I'm also thinking about using FETs and I'm very curious about what parts you choose.
I'd make sure to shop around for similar arrays. The prices of these arrays have been falling dramatically IMO. I had thought about trying to sell some arrays but I found large arrays selling with drive circuits that cost about the same as the parts in my arrays.
A really Good Thing about the TLC5916 is that you can control the current by programming an internal register. This means you can control the brightness, at least on a frame-to-frame basis. This will allow one to compensate for varying ambient lighting and perhaps to compensate for LED module variations. Here is a video with two current setting. The first half is bright, the second half is less bright.
http://youtu.be/iqssBHaUJnY