Max clock rate the 16x32 RGB panel can accept?

[Andrewsi]

Anybody been playing with this panel have any experience with the highest serial-in clock rate they've successfully used? Driving the inputs at 3.3v from an FPGA I seem to top out at around 8mhz before the panel stops responding. With 10-bit pwm this is just barely good enough for a 60 hz frame rate, but I was hoping to get it running faster and get either a higher frame rate and/or up to 12-bit pwm cycles. :-/. I'm wondering whether perhaps some termination on the fast lines or 5v level shifters might help.

[adafruit]

we've seen them used on FPGAs at higher speeds, check your wiring, try to keep it very short as capacitance can make a difference.

[Andrewsi]

Will do. I had a suspicion that the ribbon cable combined with the additional length of pin jumpers I'm using to get to the dev board were probably contributing to the slow speeds. I'll check it out and see if I can shorten things up.

[Andrewsi]

Miscalculation on my part. 25Mhz clock rate is working fine. 30 Mhz not... but those are much more reasonable numbers, and I haven't had to shorten up the wires yet.

[Andrewsi]

To clarify, 25Mhz is good enough for just shy of 90hz with 10-bit PWM. But I'll look at shortening up the wires now, and we'll see if that helps get the clock rate up higher so I could push some even higher res PWM through it.

[Andrewsi]

Long story short: The Nexys-3 board has 200-ohm resistors in serial with each of the easily accessed header I/O pins. The resistors are on the schematic but aren't mentioned in its general purpose manual document. Should've noticed them sooner, but they're there on the underside of the board. These slow the available slew rate of those pins pretty enormously, so that about the max the LED board will function with is around 28Mhz, by which point the clock signal is hugely rounded off, and the p-p voltage is no longer able to reach the necessary logic levels in time. However, there is an I/O bank without those resistors that goes to the VHDCI connector with high-speed length-matched differential lines and no resistors, so I think I'll probably build another cable for that connector and I bet I'll get much improved speeds from there.

[Andrewsi]

I finally got around to building a cable off the VHCDI connector that avoids resistors in the output path to the matrix and the max output clock rate that works properly has roughly doubled. I can get somewhere between 50 and 60Mhz on the data clock line before I start seeing some flashes and misbehavior. 50Mhz is totally safe now as a clock rate, but it starts getting sketchy somewhere between there and 60Mhz, which was a bit ragged. I could still play with the adjustable drive strength a little bit, but the high slew rate and 8ma drive setting on the Spartan-6 seems adequate on the higher speeds, and you can even get away with 4 or 6ma at lower speeds. But anyway, now I have loads of headroom to play with for either more framerate or increased color depth.

Side note: I totally do not recommend trying to build your own VHCDI cable! The necessary male connector is available from Digilent in a board mount form, and from Digikey or Mouser as a (supposedly) insulation-displacement type connection to the wire. Both are $8-10, which is pretty pricey for a single connector. Furthermore, the pitch between wires is only 0.8mm, and nobody has ribbon cable available in small quantities that's got that tight a pitch! Standard .05" pitch 28-gauge ribbon cable looks gigantic relative to this thing! - totally unworkable.

In the end I did make it work out by painstakingly soldering 30-gauge kynar wire-wrap wire to the terminals (head-worn magnifier from Amazon was really a godsend here) and then attaching the other ends to a standard ribbon cable female plug for the matrix end. The exposed ends being soldered were very, very, short to avoid shorting against each other. I feel like a watchmaker now.

In any event, this is a temporary solution, I actually have a small PCB off at the prototype house now so I can eventually use the board-mounted version of the VHCDI connector and a standard IDC jack for the ribbon cable. I bet the signal integrity will be even a bit better after that.

The signals look just so much better now on the scope and I'm finally happy with the speeds I'm getting out.

[Andrewsi]

Turns out I was little overoptimistic and there is in fact a subtle failure at the higher speeds that I didn't notice at first with my test app (because only one lit pixel was missing in "Hello World" . Right around the 45Mhz data clock rate, the first few columns experience some sort of skew issue on the module that causes the left half of the display to fall behind by one clock, so that by 50Mhz or so the left half has shifted a full pixel to the right and yet the right half is placed correctly. At 45Mhz it's really visible because the red/green/blue dots have not all skewed by the same amount and it becomes glaringly obvious. At 40Mhz, the operation is completely normal. So, I think I'll be sticking to the lower rates.

[rhb]

This thread was really helpful for me, so I'll add my data. I haven't validated 100% pixel correctness, but 50 MHz seems to work for me (using favicons as test images, so not the easiest to spot errors). 67MHz definitely did not work. I'll try again with simple lines and shapes to be sure.

Protocol details & favicon example here: http://rhb.me/2012/05/led-matrix-bringup/

I'd like to capture the data from the 2nd connector to test the max clock rate for daisy-chaining displays. I did measure the power consumption vs. color/clock rate, this data is also at the link above.

[pburgess]

Hi Ryan,

Great set of data you've collected there. Would you mind if we added this info to the tutorial page? (Including the power diagram.) With attribution, of course.

Also, just out of curiosity, what sort of PWM resolution are you achieving? Looks buttery smooth!

[rhb]

Sure, go ahead and add it to the tutorial - that's great if it can help someone else.

Here is something else you might add - I just found this blog post which does a good job of explaining how the panel works: http://www.hobbypcb.com/blog/item/3-16x32-rgb-led-matrix-technical-details.html

My PWM code is all configurable right now so I can figure out what looks good. It takes in 8 bits per color (RGB), applies an exponential scale and then sets the duty cycle based on the PWM period I set. Most of the inputs are tweakable, so I'm not 100% sure how I had it set for the video.

The exponential scaling made the biggest improvement, as my friend informed me our color perception is non-linear, so mapping pixel values to PWM duty cycles linearly looked washed out. I haven't looked around for a good explanation of this, if I find one I'll post it on my blog as well.

[Andrewsi]

Technically, this is what they call "gamma correction." My FPGA code uses a lookup table to accomplish the same thing.