questions about powering leds in large matrix like mikes macmux design

deuplonicus said:

how in the world did you manage that amazing refresh rate/duty cycle?

Click to expand...

an interrupt routine bangs out 9 bytes 1000 times a second. every time it is called it reads the data from an array that corresponds to a different column. even does scrolling text messages

deuplonicus said:

I'm going to start searching for some suitable N fets, What should I look for? low Rds? I am not really sure what made you pick the Si2312BDS, so if you could inform me I would love to learn why.

Click to expand...

You want to select an N-FET for a display with cathode rows and anode columns or a P-FET for a display with anode rows and cathode columns. You have a much bigger choice of column driver ICs if you decide to build an anode row / cathode column display (MIC5821, TPIC6C595, any of the 8-bit or 16-bit "constant current" driver ICs, or even a 74HC595/ULN2803 combination).

The high current N-FET or P-FET you chose should have extremely low Rds(on) resistance with "logic level" gate control. You could also use two sets of eight row driver FETS, one set for each 8x64 display group, to reduce FET current handling requirements. Remember too that you'll probably never drive all 128 LEDs at the same time in any individual row so you could probably de-rate your maximum "peak" current requirements by 10%-15%.

The MacMux driver is relatively "low overhead". I normally use a 1-msec row update interval which produces an 8-msec "frame" rate (a 125-Hz refresh rate). If you're doin' any kind of animation you'll want to synchronize display array updates to the "frame" rate to avoid unwanted visual artifacts. If you have a lot of animation then you might want to increase the row update interval and refresh rate. A 500-usec row update interval would produce a 4-msec frame rate (250-Hz) which would allow you to change the display array up to 250 times per second (synchronized to the display "frame" rate).

Cheerful regards, Mike

Ubergeek63 said:

10% of an 8051 at 12MHz drives the display at 95% duty cycle refreshing a 64x10 array 100 times a second. (column off, send 8 bytes, column on, wait, repeat)

Click to expand...

How do you get a 95% duty cycle, please?

Your description sounds more like a 10% duty cycle (1 of 10 columns of 64 bits each, updated at 1-msec intervals, with 10 intervals to refresh the entire display).

@ Deuplonicus

Don't you feel like doing a cathode row design makes your hardware part messy by adding "PNP + Base resister" to each 595 outputs of column side & even if you choose a sourcing chip it makes your pocket empty.

My latest design I use an Anode row concept.So I can stick with 595 with ULN2803 on column side.Reduces Cost & plenty sinking drivers available in every stores.So only I have to worry about the Anode rows, I need only 16 high current PNP transistors.

My new design 6mA average current per LED on a 16 rows display.16 X 6 = 96mA which will supports many LED's maximum current requirements.

The below product of mine uses a 4mA average current per LED.Its a 1/7th duty cycle design.

Mike said:

How do you get a 95% duty cycle, please?

Your description sounds more like a 10% duty cycle (1 of 10 columns of 64 bits each, updated at 1-msec intervals, with 10 intervals to refresh the entire display).

Click to expand...

sorry, a bit of confusion there... i was referring to display active time, not column active time. might actually be higher, and certainly would with the ARMs we prefer to use these days since they run a 60MHz bus at half the power of the 6MHz bus 8051s

Hi Gayan,

I thought about it, but the Si2312BDS n-fets doublestacked should do the job fine, and they are plenty cheap at .18 cents each vs any other pnp transistor x 16

deuplonicus said:

Hi Gayan,

I thought about it, but the Si2312BDS n-fets doublestacked should do the job fine, and they are plenty cheap at .18 cents each vs any other pnp transistor x 16

Click to expand...

I was mentioning the column side not the row side.That's the hardest part.Are you using sourcing chips ex:MIC5891? or individual transistors to each column?

yea you guessed it, the MIC5891, as there weren't many options, but even these weren't that bad in price, only $1 each

Gayan Soyza said:

The below product of mine uses a 4mA average current per LED.Its a 1/7th duty cycle design.

Click to expand...

So I was looking at this and impressed. It almost appears in the photo as if they are on normal 100% duty cycle with 20ma, or would your display be much brighter?

I wonder this because My display has 1454 LEDs, it will be aimed at a raving crowd with the DJ on top of it essentially. and I was wondering if anyone thinks that its possible I'm designing this thing to be "too bright"? there will be upwards of 1500 people there.

From the shift register side I'm pumping maximum 30mA current.So when its multiplexing 1/7 will be 4.2mA average current per LED.I can supply more current if I were using Allegro parts to the column side, but those aren't available in my place.

If you are designing an indoor display then you don't have to worry much on brightness issues rather than outdoor displays.

Gayan Soyza said:

From the shift register side I'm pumping maximum 30mA current.So when its multiplexing 1/7 will be 4.2mA average current per LED.I can supply more current if I were using Allegro parts to the column side, but those aren't available in my place.

If you are designing an indoor display then you don't have to worry much on brightness issues rather than outdoor displays.

Click to expand...

How many times do I have to say it: ABT logic can supply 120mA CONTINUOUS. 74ABT574s can be wired as shift registers, only if you push more than 60mA you have to disable the columns to get the logic levels ( a good idea anyway since it prevents the data load from flashing the LEDs)

questions about power guys:

How do I figure out the powering voltage needed for 3.1v LEDs with the MIC5891 and Si2312BDS. I was thinking forward voltage from the spec sheets was a little high, 2v for the mic5891 and 0.8-1.2 for the Si2312BDS, then a 3.1v LED, means I need around 6.1v? I happen to have a 5v 18amp power supply which I was hoping to use.

hey mike,

I had a question about multiplexing the rows, in your design you use 8 pins to send serial data to each of the 8 shift registers. And you use these lines to activate each row at a time. How do you achieve this in software? it seems like daisychaining my mic5891s serial with a single data line to the arduino would be better.

deuplonicus said:

hey mike,

I had a question about multiplexing the rows, in your design you use 8 pins to send serial data to each of the 8 shift registers. And you use these lines to activate each row at a time. How do you achieve this in software? it seems like daisychaining my mic5891s serial with a single data line to the arduino would be better.

Click to expand...

i still say you should use ABT registers to avoid the row drivers, but what do I know? I am only a display design engineer after all!

in order to drive a 500 LED display you need to clock out 50,000 bits per second. in between that you have to do what you actually WANT to do AND build the display image. If you do not have a cache on your serial hardware you might just as well sit and wait for it it unless your bus speed is 10MHz or more (5Mhz would probably be about break even once you figure in interrupt overhead and frustration)

8 data lines brings that down to 6000 bytes per second.

depending on your hardware you might have to turn off all the column drivers while you are shifting in the data if you want to prevent the display from flashing, if this is the case your data rate goes up by a factor of 10, but you have the processing time in between to do your REAL work.

Ubergeek63,

thanks for the input, I would love to try your ideas as well but alas you chimed in after I had decided what chips to buy, and bought them. There will be plenty of opportunity though as I will have over 2500 left over LEDs after this matrix is complete, which has 1474 LED's divided between two separate matrices.

however, until I am done with this matrix, I will be working on this design that you despise with decent reasoning, so instead of new hardware how about so suggestions on this particular design? Like some odd things you should be given, this LED matrix is huge in size, the longest pathway of power for the farthest LED from a closed power source is about 16 feet from source to LED to sink. Each matrix will be just over 700 LEDs controlled by separate ATMEGA2560 chips. Two 6.4v 15 amp power supplys will feed the two matrices. There are plenty of other weird things about this matrix shape and size as well.

What I am more interested in at this point is getting the subroutines operating in the programming. The ISRs and row data senders etc.

deuplonicus said:

Ubergeek63,

thanks for the input, I would love to try your ideas as well but alas you chimed in after I had decided what chips to buy, and bought them. There will be plenty of opportunity though as I will have over 2500 left over LEDs after this matrix is complete, which has 1474 LED's divided between two separate matrices.

however, until I am done with this matrix, I will be working on this design that you despise with decent reasoning, so instead of new hardware how about so suggestions on this particular design? Like some odd things you should be given, this LED matrix is huge in size, the longest pathway of power for the farthest LED from a closed power source is about 16 feet from source to LED to sink. Each matrix will be just over 700 LEDs controlled by separate ATMEGA2560 chips. Two 6.4v 15 amp power supplys will feed the two matrices. There are plenty of other weird things about this matrix shape and size as well.

What I am more interested in at this point is getting the subroutines operating in the programming. The ISRs and row data senders etc.

Click to expand...

i did see after the fact a comment about micrel parts, that they are high current drivers and pricey compared to ABT chips.

i would not be using atmega, i would use Actel FPGAs.

As to algorithms and such it would make your life a lot easier if you set up your array to respond to a standard LVDS LCD interface. you then have your minimal interconnect wiring, high speed interface, and readilly available graphics engines.

BTW when i was "out of work" i did a stint in field service for a company that did big displays like this

Dan

deuplonicus said:

hey mike,

I had a question about multiplexing the rows, in your design you use 8 pins to send serial data to each of the 8 shift registers. And you use these lines to activate each row at a time. How do you achieve this in software? it seems like daisychaining my mic5891s serial with a single data line to the arduino would be better.

Click to expand...

You can do it that way. You would need one pin for the <dat> line input and one pin to drive all of the <lat> lines on the shift registers. During each row update interrupt you would load 128 bits of row data into the 16 daisy-chained shift registers and then pulse the <lat> line to copy the shift register data onto the driver output pins.

The MacMux method uses the PWM signal to re-task the row driver lines for use as <dat> and <clk> lines to load the column driver shift registers when PWM is high (display off) at the beginning of each interrupt cycle. The driver sends 128 bits of row data to the 16 shift registers by writing 16 special shift registers bytes and clocks onto the buss in about 64 (PIC) instruction cycles (about 8-usecs on a PIC with a 32-MHz clock). This means we have to enforce a minimum PWM duty cycle of at least 8-usecs to allow enough time to load the column driver shift registers before PWM goes high (display on) again. If we were to use 10-usecs as our minimum PWM duty cycle with a 1-msec row update interval, it reduces our maximum display brightness by 1% (display brightness is inversely proportional to PWM duty cycle). In practice, there's very little difference between 99% and 100% brightness.

The "down side" to the MacMux method is that you need additional "data bender" code to prepare the 16 special shift register bytes for the next row update interrupt. This uses about 256 cycles on a PIC which corresponds to about 32-usecs or 3.2% additional ISR overhead on a 32-MHz PIC.

In all fairness, a driver for ubergeek63's ABT column drivers would load 128 bits of row data in the same amount of time as the MacMux driver (less than 1% overhead) but the MacMux driver uses another 256 cycles (about 3.2% overhead) to prepare the special shift register byte array. ubergeek63's ABT driver uses 1% overhead while the MacMux driver uses about 5% overhead.

Fall semester wraps up in two weeks and I'll have more time to help you then.

Happy Holidays!

Mike

Finals! yea tell me about it. I happened to get sick just before finals studying began. Now here I am coughing out my lungs and still studying for my last final tomorrow morning! one of my worst weeks of stress in my life. Luckily I'm graduating the community college next week then off to Old Dominion university!

I've received all my hardware in and begun the long process of building, and will be setting up a small test matrix so I don't break the giant sign by bad programming testing. I'm pretty confident I can make this design work now on my own, be it tied in to the rows or not, doesn't really seem to matter with my mega2560 platform, just changes a little bit of the programming. I spent a good couple of weeks reading the 444 page long manual on the Atmel Mega2560 and learned a lot more than I expected! I highly suggest anyone who buys any uC to read the manual for said uC, they make these for a reason!

I'm certain I will run into some errors, and they'll be posted up here, lol.

HUGE Thanks for the help so far goes out to everyone! even all those old threads, I've searched and read them all several times! I've also noted that there seem to be quite a few inefficiently coded matrices out there, be wary!

some teaser pics

A small update: I just finished hot gluing all 1474 LEDs, looking mighty fine this sign, here's a sneak peak:

(we're trying to keep this thing a secret to the local dance/dj scene - which is proving tough as word-of-mouth spreads easily)