in this circuit here, the current appears to be for lower power LEDs, I'm powering 20ma 5mm LEDs at 3.1v, and obviously need to use drivers on them.

in the circuit above, I feel I need something like the ULN2803 behind each shift register for extra current sinking, but I'm not sure if that is correct, I feel that it needs to be a PNP, please correct me if I am wrong.

Also, to drive more power, would the Nfets for the rows need to be more powerful?

That's a bit of a dodgy circuit. The shift registers may have to sink up to 160mA (all segments on), and this could damage them.

N-ch fets only need to be used if you are using >20mA LED's or if your microcontroller can't source 20mA per pin and 160mA in total. Most MCU's can.

 

That's a bit of a dodgy circuit. The shift registers may have to sink up to 160mA (all segments on), and this could damage them.

N-ch fets only need to be used if you are using >20mA LED's or if your microcontroller can't source 20mA per pin and 160mA in total. Most MCU's can.

I see you are right the shift registers can only source 8 leds at any time since I'm row scanning, therefore they should sink enough current.

however,

I am unsure how you think the mcu can source a possible whole row of up to 128 LEDs on, thats why there is a fet there, rated at 5amps since it adds up to a possible 2.5 amps...

now sure these can sink the rated LED power, but keep in mind with row scanning I will have a low duty cycle, so I should have to send more power to the LEDs, correct? This is why I am trying to figure out how to beef up the supply lines. Am I right to getting to this conclusion?

 

I see you are right the shift registers can only source 8 leds at any time since I'm row scanning, therefore they should sink enough current.

however,

I am unsure how you think the mcu can source a possible whole row of up to 128 LEDs on, thats why there is a fet there, rated at 5amps since it adds up to a possible 2.5 amps...

now sure these can sink the rated LED power, but keep in mind with row scanning I will have a low duty cycle, so I should have to send more power to the LEDs, correct? This is why I am trying to figure out how to beef up the supply lines. Am I right to getting to this conclusion?

Not really. Due to human persistence of vision it will look almost as bright as them all being on at the same time. Think of a TV - very similar.

 

Not really. Due to human persistence of vision it will look almost as bright as them all being on at the same time. Think of a TV - very similar.

I understand this, but everyone I'm come across, including myself on a smaller 4x14 led matrix that is in my living room, will notice at high freq the led's are dimmer.

I ask Again, how could the MCU possibly source the current of a whole row, 128 LEDs?

 

I understand this, but everyone I'm come across, including myself on a smaller 4x14 led matrix that is in my living room, will notice at high freq the led's are dimmer.

I ask Again, how could the MCU possibly source the current of a whole row, 128 LEDs?

The MCU should only be driving each column, not each row. It only needs to sink around 300mA. You might need a shift register or parallel driver.

 

k, but I'm not doing column scanning, as per the pic I linked you to.

 

k, but I'm not doing column scanning, as per the pic I linked you to.

In which case, you will need a driver for each row. It ends up easier doing column scanning.

 

how can column scanning 128 columns be easier?! first of all, the adruino can't handle the speeds necessary to get 100hz scanning 128 columns. Also the duty cycle would be a horrible 1/128, which means I'd need to overdrive the LEDs even more than they could be driven to achieve the same brightness.

 

how can column scanning 128 columns be easier?! first of all, the adruino can't handle the speeds necessary to get 100hz scanning 128 columns. Also the duty cycle would be a horrible 1/128, which means I'd need to overdrive the LEDs even more than they could be driven to achieve the same brightness.

Column scanning can be done with 16 shift registers or 128 fets, along with 16 IO's on the MCU, whereas row scanning would require an MCU with 128 IO's and there aren't many of them.

 

how so? my current design uses only 10 I/O lines with row scanning.

only 128 bits have to be sent out via serial data to the shift registers on the 128 columns, and then the MCU shifts between the 8 different rows. the 10th pin is for pwm signal for each shift register for brightness control.

Either I've got it backwards or you do. But I'm pretty certain the design above scans the rows.

 

how so? my current design uses only 10 I/O lines with row scanning.

only 128 bits have to be sent out via serial data to the shift registers on the 128 columns, and then the MCU shifts between the 8 different rows. the 10th pin is for pwm signal for each shift register for brightness control.

Either I've got it backwards or you do. But I'm pretty certain the design above scans the rows.

Yeah, but you can't use that with 20mA LEDs, the shift registers will smoke. Note that on the diagram it specifies 4mA per LED, 32mA total.

 

Hi Tom,

Thank you for your contributions.

I just wanted to mention that that particular design had 74HC595's in it because someone asked about reducing cost compared to a full brightness design. The original design used 8 bit serial-to-parallel Micrel MIC5891 350-ma "sourcing" driver IC's for the anode columns.

If you were to change the design to use P-FET anode row drivers then you would have a much larger choice of high current serial-to-parallel "sinking" cathode column driver ICs, including many newer 8-bit or 16-bit "constant current" sinking driver ICs which would eliminate the need for current limiting resistors on the cathode columns.

Cheerful regards, Mike

 

some of these columns on my design have a lack of LEDs as the matrix is embedded withing a letter "F", so I figured sticking with your design, I could simply not wire in the LEDs and adjust the resistors on the shift registers accordingly. right?

 

some of these columns on my design have a lack of LEDs as the matrix is embedded withing a letter "F", so I figured sticking with your design, I could simply not wire in the LEDs and adjust the resistors on the shift registers accordingly. right?

You want to be able to change the LED patterns, right?

 

yes. But there will be areas where the column/row may not have all the leds be 1-128(row) or 1-8(column) some areas have #1, 3-8 or another will be split in the middle missing one LED or two #1-3, 5-8... etc

I would of course extend the wiring to the rest of the matrix past any missing LEDs, the only real concern is keeping the current flow the same so as to keep the brightness the same.


I will be using the ATmega2560 with plenty of ram.

 

yes. But there will be areas where the column/row may not have all the leds be 1-128(row) or 1-8(column) some areas have #1, 3-8 or another will be split in the middle missing one LED or two #1-3, 5-8... etc

I would of course extend the wiring to the rest of the matrix past any missing LEDs, the only real concern is keeping the current flow the same so as to keep the brightness the same.


I will be using the ATmega2560 with plenty of ram.

That is pretty much unavoidable - have a look at most LED signs and you'll see differences in brightness. You could try calibrating brightness levels using PWM.

You should have resistors on the rows or columns (whichever you are driving directly) and no resistors on the other side, which will help keep brightnesses constant, but even differences between LED's, including previous usage, as well as component tolerances, will create visible differences in the light output of each.