5x7 LED matrix driver

Jon Kirwan · Mar 3, 2013

I'm considering a 5x7 LED digit module design to work with a
microcontroller with these two simple ideas:

(1) Constant current drive for the LEDs, settable by a single
external resistor. This will set the maximum (100%) LED
current. PWM (or PFM) will be used to individually reduce the
effective brightness on an LED by LED basis, referenced to
this maximum setting.

(2) A microcontroller Vcc rail, from 2.5V to 5.0V.

(3) Separate LED power supply rail, which can be higher than,
but not less than, the Vcc rail. The LED rail can be up to
15V, though dissipation issues will dictate that it be as low
as possible. I may, in the case of RGB, want three such
rails. The idea is to keep dissipation as low as reasonable,
but to allow flexibility, too. (2 LEDs in series, for
example, or blue vs red, etc.)

(4) Muxing is done with 5x, placing 7 LEDs per row, 5 rows,
and with 5x the average current. Since I may use 20mA LEDs,
this means 100mA peak LED current (as set by the external
resistor.)

(5) 5% variation in LED current across active LEDs in a row.

Variations in LED V vs I yield unacceptable differences in
brightness (noticeable) when operated in parallel.

I developed a tentative schematic (without slew rate limits),
but I'm using 64 BJTs to manage 35 LEDs. It works and none of
the transistors deal with more than Ic=100mA, neither the row
nor column ones. But that's a lot of BJTs and I'm betting I'm
missing something terribly obvious. (I'm using cheap 0.3 and
0.4 cent BJTs, so it's not expensive. Everything else is what
costs money.)

These 5x7 displays will be about 3" high, by the way, and I'm
using the 3d printer to make the black grids for mounting 5mm
LEDs.

Here's a portion that gets my mental state (bad as it may be)
across:

http://www.infinitefactors.org/schematics/portion%20of%205x7%20driver.png

What am I missing about simplifying this without putting LEDs
in parallel to each other during muxing?

Jon

petrus bitbyter · Mar 4, 2013

"Jon Kirwan" <jonk@infinitefactors.org> schreef in bericht
news:3ag7j8lpfoai4lm2giedg16b8n9hcbovut@4ax.com...

I'm considering a 5x7 LED digit module design to work with a
microcontroller with these two simple ideas:

(1) Constant current drive for the LEDs, settable by a single
external resistor. This will set the maximum (100%) LED
current. PWM (or PFM) will be used to individually reduce the
effective brightness on an LED by LED basis, referenced to
this maximum setting.

(2) A microcontroller Vcc rail, from 2.5V to 5.0V.

(3) Separate LED power supply rail, which can be higher than,
but not less than, the Vcc rail. The LED rail can be up to
15V, though dissipation issues will dictate that it be as low
as possible. I may, in the case of RGB, want three such
rails. The idea is to keep dissipation as low as reasonable,
but to allow flexibility, too. (2 LEDs in series, for
example, or blue vs red, etc.)

(4) Muxing is done with 5x, placing 7 LEDs per row, 5 rows,
and with 5x the average current. Since I may use 20mA LEDs,
this means 100mA peak LED current (as set by the external
resistor.)

(5) 5% variation in LED current across active LEDs in a row.

Variations in LED V vs I yield unacceptable differences in
brightness (noticeable) when operated in parallel.

I developed a tentative schematic (without slew rate limits),
but I'm using 64 BJTs to manage 35 LEDs. It works and none of
the transistors deal with more than Ic=100mA, neither the row
nor column ones. But that's a lot of BJTs and I'm betting I'm
missing something terribly obvious. (I'm using cheap 0.3 and
0.4 cent BJTs, so it's not expensive. Everything else is what
costs money.)

These 5x7 displays will be about 3" high, by the way, and I'm
using the 3d printer to make the black grids for mounting 5mm
LEDs.

Here's a portion that gets my mental state (bad as it may be)
across:

http://www.infinitefactors.org/schematics/portion%20of%205x7%20driver.png

What am I missing about simplifying this without putting LEDs
in parallel to each other during muxing?

Jon

If I understand your schematic well, you're driving each LED individually.
By muxing you only need 5+7=12 lines and 12 transistors, maybe 5 more for
driving the high side. You select one digit at a time together with all
segments you want to light for that particular digit. Off course the
correspoding segments of the other digits are selected as well but they do
not light as those digits are not selected.

petrus bitbyter

Jon Kirwan · Mar 4, 2013

On Mon, 4 Mar 2013 11:18:07 +0100, "petrus bitbyter"
<petrus.bitbyter@hotmail.com> wrote:

"Jon Kirwan" <jonk@infinitefactors.org> schreef in bericht
news:3ag7j8lpfoai4lm2giedg16b8n9hcbovut@4ax.com...
I'm considering a 5x7 LED digit module design to work with a
microcontroller with these two simple ideas:

(1) Constant current drive for the LEDs, settable by a single
external resistor. This will set the maximum (100%) LED
current. PWM (or PFM) will be used to individually reduce the
effective brightness on an LED by LED basis, referenced to
this maximum setting.

(2) A microcontroller Vcc rail, from 2.5V to 5.0V.

(3) Separate LED power supply rail, which can be higher than,
but not less than, the Vcc rail. The LED rail can be up to
15V, though dissipation issues will dictate that it be as low
as possible. I may, in the case of RGB, want three such
rails. The idea is to keep dissipation as low as reasonable,
but to allow flexibility, too. (2 LEDs in series, for
example, or blue vs red, etc.)

(4) Muxing is done with 5x, placing 7 LEDs per row, 5 rows,
and with 5x the average current. Since I may use 20mA LEDs,
this means 100mA peak LED current (as set by the external
resistor.)

(5) 5% variation in LED current across active LEDs in a row.

Variations in LED V vs I yield unacceptable differences in
brightness (noticeable) when operated in parallel.

I developed a tentative schematic (without slew rate limits),
but I'm using 64 BJTs to manage 35 LEDs. It works and none of
the transistors deal with more than Ic=100mA, neither the row
nor column ones. But that's a lot of BJTs and I'm betting I'm
missing something terribly obvious. (I'm using cheap 0.3 and
0.4 cent BJTs, so it's not expensive. Everything else is what
costs money.)

These 5x7 displays will be about 3" high, by the way, and I'm
using the 3d printer to make the black grids for mounting 5mm
LEDs.

Here's a portion that gets my mental state (bad as it may be)
across:

http://www.infinitefactors.org/schematics/portion%20of%205x7%20driver.png

What am I missing about simplifying this without putting LEDs
in parallel to each other during muxing?

Jon

If I understand your schematic well, you're driving each LED individually.
By muxing you only need 5+7=12 lines and 12 transistors, maybe 5 more for
driving the high side. You select one digit at a time together with all
segments you want to light for that particular digit. Off course the
correspoding segments of the other digits are selected as well but they do
not light as those digits are not selected.

An entire row is enabled at a time, just to be clear.

Muxing in the usual way would drive the LEDs in a ROW (0 to 7
of them) in parallel to each other. This isn't good as some
LEDs will hog the current. I want to know that if I set 100mA
as the peak current, that each LED will ACTUALLY have 100mA
as its peak (100% duty cycle) current.

I know that what I've done in the schematic has been done in
commercial products, because I've contracted to do work on
them before. OSRAM built 16x16 RGB modules, self-contained,
for OEM sales which actually used the technique I show (with
lots more transistors, but the idea is right.)

I'm just hoping for a simpler method to achieve precision (5%
worst case variation during a row-enable) current control of
each LED and not have them all with individual BJTs... but I
suspect that isn't possible. Going to RGB, which I intend on
also doing, only adds 14 more transistors per color, do 28
more for a total of 92 BJTs for 105 LEDs. So it scales better
than it looks.

Jon

Daniel Pitts · Mar 4, 2013

On 3/4/13 11:55 AM, Jon Kirwan wrote:

On Mon, 4 Mar 2013 11:18:07 +0100, "petrus bitbyter"
petrus.bitbyter@hotmail.com> wrote:

"Jon Kirwan" <jonk@infinitefactors.org> schreef in bericht
news:3ag7j8lpfoai4lm2giedg16b8n9hcbovut@4ax.com...
I'm considering a 5x7 LED digit module design to work with a
microcontroller with these two simple ideas:

(1) Constant current drive for the LEDs, settable by a single
external resistor. This will set the maximum (100%) LED
current. PWM (or PFM) will be used to individually reduce the
effective brightness on an LED by LED basis, referenced to
this maximum setting.

(2) A microcontroller Vcc rail, from 2.5V to 5.0V.

(3) Separate LED power supply rail, which can be higher than,
but not less than, the Vcc rail. The LED rail can be up to
15V, though dissipation issues will dictate that it be as low
as possible. I may, in the case of RGB, want three such
rails. The idea is to keep dissipation as low as reasonable,
but to allow flexibility, too. (2 LEDs in series, for
example, or blue vs red, etc.)

(4) Muxing is done with 5x, placing 7 LEDs per row, 5 rows,
and with 5x the average current. Since I may use 20mA LEDs,
this means 100mA peak LED current (as set by the external
resistor.)

(5) 5% variation in LED current across active LEDs in a row.

Variations in LED V vs I yield unacceptable differences in
brightness (noticeable) when operated in parallel.

I developed a tentative schematic (without slew rate limits),
but I'm using 64 BJTs to manage 35 LEDs. It works and none of
the transistors deal with more than Ic=100mA, neither the row
nor column ones. But that's a lot of BJTs and I'm betting I'm
missing something terribly obvious. (I'm using cheap 0.3 and
0.4 cent BJTs, so it's not expensive. Everything else is what
costs money.)

These 5x7 displays will be about 3" high, by the way, and I'm
using the 3d printer to make the black grids for mounting 5mm
LEDs.

Here's a portion that gets my mental state (bad as it may be)
across:

http://www.infinitefactors.org/schematics/portion%20of%205x7%20driver.png

What am I missing about simplifying this without putting LEDs
in parallel to each other during muxing?

Jon

If I understand your schematic well, you're driving each LED individually.
By muxing you only need 5+7=12 lines and 12 transistors, maybe 5 more for
driving the high side. You select one digit at a time together with all
segments you want to light for that particular digit. Off course the
correspoding segments of the other digits are selected as well but they do
not light as those digits are not selected.

An entire row is enabled at a time, just to be clear.

Muxing in the usual way would drive the LEDs in a ROW (0 to 7
of them) in parallel to each other. This isn't good as some
LEDs will hog the current. I want to know that if I set 100mA
as the peak current, that each LED will ACTUALLY have 100mA
as its peak (100% duty cycle) current.

I know that what I've done in the schematic has been done in
commercial products, because I've contracted to do work on
them before. OSRAM built 16x16 RGB modules, self-contained,
for OEM sales which actually used the technique I show (with
lots more transistors, but the idea is right.)

I'm just hoping for a simpler method to achieve precision (5%
worst case variation during a row-enable) current control of
each LED and not have them all with individual BJTs... but I
suspect that isn't possible. Going to RGB, which I intend on
also doing, only adds 14 more transistors per color, do 28
more for a total of 92 BJTs for 105 LEDs. So it scales better
than it looks.

Jon

I use a Constant Current Sink (not Source) to power a Common Cathode LED
matrix.

The Constant Current Sink pins are controlled via a shift register.
Then I use a 1-of-8 demuxer to select which "column" to use.

So, each column is powered by one state of the Constant Current chip,
then I disable all current, set up the next column in the shift
register, then move to the next column and enable current on the rows
that need it. This means each LED has its own independent current
controller.

BTW, I do this 16x60Hz so that I basically use PWM for intensity control
(16 levels of brightness) and the entire display updates 60 times a second.

Jon Kirwan · Mar 4, 2013

On Mon, 04 Mar 2013 12:06:33 -0800, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote:

On 3/4/13 11:55 AM, Jon Kirwan wrote:
On Mon, 4 Mar 2013 11:18:07 +0100, "petrus bitbyter"
petrus.bitbyter@hotmail.com> wrote:

"Jon Kirwan" <jonk@infinitefactors.org> schreef in bericht
news:3ag7j8lpfoai4lm2giedg16b8n9hcbovut@4ax.com...
I'm considering a 5x7 LED digit module design to work with a
microcontroller with these two simple ideas:

(1) Constant current drive for the LEDs, settable by a single
external resistor. This will set the maximum (100%) LED
current. PWM (or PFM) will be used to individually reduce the
effective brightness on an LED by LED basis, referenced to
this maximum setting.

(2) A microcontroller Vcc rail, from 2.5V to 5.0V.

(3) Separate LED power supply rail, which can be higher than,
but not less than, the Vcc rail. The LED rail can be up to
15V, though dissipation issues will dictate that it be as low
as possible. I may, in the case of RGB, want three such
rails. The idea is to keep dissipation as low as reasonable,
but to allow flexibility, too. (2 LEDs in series, for
example, or blue vs red, etc.)

(4) Muxing is done with 5x, placing 7 LEDs per row, 5 rows,
and with 5x the average current. Since I may use 20mA LEDs,
this means 100mA peak LED current (as set by the external
resistor.)

(5) 5% variation in LED current across active LEDs in a row.

Variations in LED V vs I yield unacceptable differences in
brightness (noticeable) when operated in parallel.

I developed a tentative schematic (without slew rate limits),
but I'm using 64 BJTs to manage 35 LEDs. It works and none of
the transistors deal with more than Ic=100mA, neither the row
nor column ones. But that's a lot of BJTs and I'm betting I'm
missing something terribly obvious. (I'm using cheap 0.3 and
0.4 cent BJTs, so it's not expensive. Everything else is what
costs money.)

These 5x7 displays will be about 3" high, by the way, and I'm
using the 3d printer to make the black grids for mounting 5mm
LEDs.

Here's a portion that gets my mental state (bad as it may be)
across:

http://www.infinitefactors.org/schematics/portion%20of%205x7%20driver.png

What am I missing about simplifying this without putting LEDs
in parallel to each other during muxing?

Jon

If I understand your schematic well, you're driving each LED individually.
By muxing you only need 5+7=12 lines and 12 transistors, maybe 5 more for
driving the high side. You select one digit at a time together with all
segments you want to light for that particular digit. Off course the
correspoding segments of the other digits are selected as well but they do
not light as those digits are not selected.

An entire row is enabled at a time, just to be clear.

Muxing in the usual way would drive the LEDs in a ROW (0 to 7
of them) in parallel to each other. This isn't good as some
LEDs will hog the current. I want to know that if I set 100mA
as the peak current, that each LED will ACTUALLY have 100mA
as its peak (100% duty cycle) current.

I know that what I've done in the schematic has been done in
commercial products, because I've contracted to do work on
them before. OSRAM built 16x16 RGB modules, self-contained,
for OEM sales which actually used the technique I show (with
lots more transistors, but the idea is right.)

I'm just hoping for a simpler method to achieve precision (5%
worst case variation during a row-enable) current control of
each LED and not have them all with individual BJTs... but I
suspect that isn't possible. Going to RGB, which I intend on
also doing, only adds 14 more transistors per color, do 28
more for a total of 92 BJTs for 105 LEDs. So it scales better
than it looks.

Jon

I use a Constant Current Sink (not Source) to power a Common Cathode LED
matrix.

The design I illustrated in the link I provided also uses
constant current sinks. But in contast to what you write
below, I enable or disable all at once.

The Constant Current Sink pins are controlled via a shift register.
Then I use a 1-of-8 demuxer to select which "column" to use.

So, each column is powered by one state of the Constant Current chip,
then I disable all current, set up the next column in the shift
register, then move to the next column and enable current on the rows
that need it. This means each LED has its own independent current
controller.

BTW, I do this 16x60Hz so that I basically use PWM for intensity control
(16 levels of brightness) and the entire display updates 60 times a second.

Okay. So if I follow you on the above, unlike the design I
illustrated, you have individual control of each of the
current sinks. Then you simply enable the high side switch.
So you have, in this way, individual control of each current
because you can enable/disable each driver.

So if I instead redesign the discrete circuit to permit
individual control of each current sink (more transistors
per, plus a shift register), then I could go to a common
anode structure.

Thanks, I'll consider that one more carefully. I think it's
something I didn't take time to consider and I need to do
that. Very much appreciated criticism.

Jon

Jon Kirwan · Mar 4, 2013

Hmm. This makes the single programming resistor circuit a
little more complex, using discrete design. Looks like a
constant current sink chip with an external setting resistor
and up to 8 outputs and a shift register is the way to go,
then.

I suspect that there are constant current chips with built in
shift register enables. Know of any commonly used ones?

Thanks,
Jon

Jim Thompson · Mar 4, 2013

On Mon, 04 Mar 2013 13:37:26 -0800, Jon Kirwan
<jonk@infinitefactors.org> wrote:

Hmm. This makes the single programming resistor circuit a
little more complex, using discrete design. Looks like a
constant current sink chip with an external setting resistor
and up to 8 outputs and a shift register is the way to go,
then.

I suspect that there are constant current chips with built in
shift register enables. Know of any commonly used ones?

Thanks,
Jon

Jon Kirwan · Mar 4, 2013

On Mon, 04 Mar 2013 13:37:26 -0800, I wrote:

Hmm. This makes the single programming resistor circuit a
little more complex, using discrete design. Looks like a
constant current sink chip with an external setting resistor
and up to 8 outputs and a shift register is the way to go,
then.

I suspect that there are constant current chips with built in
shift register enables. Know of any commonly used ones?

Thanks,
Jon

I'm pretty much finding this $1 part:

TLC5916/5917, 3-5.5V operation, 5ma to 120mA, max 17V LED

Looks okay for my goals.

Jon

Daniel Pitts · Mar 4, 2013

On 3/4/13 12:06 PM, Daniel Pitts wrote:

On 3/4/13 11:55 AM, Jon Kirwan wrote:
On Mon, 4 Mar 2013 11:18:07 +0100, "petrus bitbyter"
petrus.bitbyter@hotmail.com> wrote:

"Jon Kirwan" <jonk@infinitefactors.org> schreef in bericht
news:3ag7j8lpfoai4lm2giedg16b8n9hcbovut@4ax.com...
I'm considering a 5x7 LED digit module design to work with a
microcontroller with these two simple ideas:

(1) Constant current drive for the LEDs, settable by a single
external resistor. This will set the maximum (100%) LED
current. PWM (or PFM) will be used to individually reduce the
effective brightness on an LED by LED basis, referenced to
this maximum setting.

(2) A microcontroller Vcc rail, from 2.5V to 5.0V.

(3) Separate LED power supply rail, which can be higher than,
but not less than, the Vcc rail. The LED rail can be up to
15V, though dissipation issues will dictate that it be as low
as possible. I may, in the case of RGB, want three such
rails. The idea is to keep dissipation as low as reasonable,
but to allow flexibility, too. (2 LEDs in series, for
example, or blue vs red, etc.)

(4) Muxing is done with 5x, placing 7 LEDs per row, 5 rows,
and with 5x the average current. Since I may use 20mA LEDs,
this means 100mA peak LED current (as set by the external
resistor.)

(5) 5% variation in LED current across active LEDs in a row.

Variations in LED V vs I yield unacceptable differences in
brightness (noticeable) when operated in parallel.

I developed a tentative schematic (without slew rate limits),
but I'm using 64 BJTs to manage 35 LEDs. It works and none of
the transistors deal with more than Ic=100mA, neither the row
nor column ones. But that's a lot of BJTs and I'm betting I'm
missing something terribly obvious. (I'm using cheap 0.3 and
0.4 cent BJTs, so it's not expensive. Everything else is what
costs money.)

These 5x7 displays will be about 3" high, by the way, and I'm
using the 3d printer to make the black grids for mounting 5mm
LEDs.

Here's a portion that gets my mental state (bad as it may be)
across:

http://www.infinitefactors.org/schematics/portion%20of%205x7%20driver.png

What am I missing about simplifying this without putting LEDs
in parallel to each other during muxing?

Jon

If I understand your schematic well, you're driving each LED
individually.
By muxing you only need 5+7=12 lines and 12 transistors, maybe 5 more
for
driving the high side. You select one digit at a time together with all
segments you want to light for that particular digit. Off course the
correspoding segments of the other digits are selected as well but
they do
not light as those digits are not selected.

An entire row is enabled at a time, just to be clear.

Muxing in the usual way would drive the LEDs in a ROW (0 to 7
of them) in parallel to each other. This isn't good as some
LEDs will hog the current. I want to know that if I set 100mA
as the peak current, that each LED will ACTUALLY have 100mA
as its peak (100% duty cycle) current.

I know that what I've done in the schematic has been done in
commercial products, because I've contracted to do work on
them before. OSRAM built 16x16 RGB modules, self-contained,
for OEM sales which actually used the technique I show (with
lots more transistors, but the idea is right.)

I'm just hoping for a simpler method to achieve precision (5%
worst case variation during a row-enable) current control of
each LED and not have them all with individual BJTs... but I
suspect that isn't possible. Going to RGB, which I intend on
also doing, only adds 14 more transistors per color, do 28
more for a total of 92 BJTs for 105 LEDs. So it scales better
than it looks.

Jon

I use a Constant Current Sink (not Source) to power a Common Cathode LED
matrix.

The Constant Current Sink pins are controlled via a shift register. Then
I use a 1-of-8 demuxer to select which "column" to use.

So, each column is powered by one state of the Constant Current chip,
then I disable all current, set up the next column in the shift
register, then move to the next column and enable current on the rows
that need it. This means each LED has its own independent current
controller.

BTW, I do this 16x60Hz so that I basically use PWM for intensity control
(16 levels of brightness) and the entire display updates 60 times a second.

For reference, I used 3 of TI's tlc5917 [1] chip as the current sink,
and a single 54HC238 [2] chip as the column selector. My MCU was an
ATTiny84 [3] (basically, a scaled down Arduino core), and the LED matrix
I used was equivalent to the one available from SEEED studio [4].

[1] <http://www.ti.com/lit/ds/symlink/tlc5917-q1.pdf>
[2] <http://www.ti.com/lit/ds/symlink/cd54hc238.pdf>
[3] <http://www.atmel.com/Images/doc8006.pdf>
[4] <http://www.seeedstudio.com/depot/datasheet/2088RGBMatrix.pdf>

Jon Kirwan · Mar 4, 2013

On Mon, 04 Mar 2013 14:42:33 -0700, Jim Thompson
<To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> wrote:

On Mon, 04 Mar 2013 13:37:26 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

Hmm. This makes the single programming resistor circuit a
little more complex, using discrete design. Looks like a
constant current sink chip with an external setting resistor
and up to 8 outputs and a shift register is the way to go,
then.

I suspect that there are constant current chips with built in
shift register enables. Know of any commonly used ones?

Thanks,
Jon

I know some custom ones...

Last year I did some chip designs for billboard video ;-)

I did tester and optical calibration systems for OSRAM's OWM
parts.

But they are unobtainium for me.

What do you think of:

TLC5916/5917, 3-5.5V operation, 5ma to 120mA, max 17V LED

http://www.ti.com/lit/ds/symlink/tlc5916-q1.pdf

Seems more than decent. 3% between LEDs and 6% between LEDs
on different ICs. I could live with that.

Jon

Daniel Pitts · Mar 4, 2013

On 3/4/13 1:50 PM, Jon Kirwan wrote:

On Mon, 04 Mar 2013 13:37:26 -0800, I wrote:

Hmm. This makes the single programming resistor circuit a
little more complex, using discrete design. Looks like a
constant current sink chip with an external setting resistor
and up to 8 outputs and a shift register is the way to go,
then.

I suspect that there are constant current chips with built in
shift register enables. Know of any commonly used ones?

Thanks,
Jon

I'm pretty much finding this $1 part:

TLC5916/5917, 3-5.5V operation, 5ma to 120mA, max 17V LED

Looks okay for my goals.

Jon

Yup, that's the one I used. I replied to my earlier message with the

list of components I used for my project (sans resistors and the 20MHz
oscillator).

Jon Kirwan · Mar 4, 2013

On Mon, 04 Mar 2013 13:52:11 -0800, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote:

On 3/4/13 12:06 PM, Daniel Pitts wrote:
On 3/4/13 11:55 AM, Jon Kirwan wrote:
On Mon, 4 Mar 2013 11:18:07 +0100, "petrus bitbyter"
petrus.bitbyter@hotmail.com> wrote:

"Jon Kirwan" <jonk@infinitefactors.org> schreef in bericht
news:3ag7j8lpfoai4lm2giedg16b8n9hcbovut@4ax.com...
I'm considering a 5x7 LED digit module design to work with a
microcontroller with these two simple ideas:

(1) Constant current drive for the LEDs, settable by a single
external resistor. This will set the maximum (100%) LED
current. PWM (or PFM) will be used to individually reduce the
effective brightness on an LED by LED basis, referenced to
this maximum setting.

(2) A microcontroller Vcc rail, from 2.5V to 5.0V.

(3) Separate LED power supply rail, which can be higher than,
but not less than, the Vcc rail. The LED rail can be up to
15V, though dissipation issues will dictate that it be as low
as possible. I may, in the case of RGB, want three such
rails. The idea is to keep dissipation as low as reasonable,
but to allow flexibility, too. (2 LEDs in series, for
example, or blue vs red, etc.)

(4) Muxing is done with 5x, placing 7 LEDs per row, 5 rows,
and with 5x the average current. Since I may use 20mA LEDs,
this means 100mA peak LED current (as set by the external
resistor.)

(5) 5% variation in LED current across active LEDs in a row.

Variations in LED V vs I yield unacceptable differences in
brightness (noticeable) when operated in parallel.

I developed a tentative schematic (without slew rate limits),
but I'm using 64 BJTs to manage 35 LEDs. It works and none of
the transistors deal with more than Ic=100mA, neither the row
nor column ones. But that's a lot of BJTs and I'm betting I'm
missing something terribly obvious. (I'm using cheap 0.3 and
0.4 cent BJTs, so it's not expensive. Everything else is what
costs money.)

These 5x7 displays will be about 3" high, by the way, and I'm
using the 3d printer to make the black grids for mounting 5mm
LEDs.

Here's a portion that gets my mental state (bad as it may be)
across:

http://www.infinitefactors.org/schematics/portion%20of%205x7%20driver.png

What am I missing about simplifying this without putting LEDs
in parallel to each other during muxing?

Jon

If I understand your schematic well, you're driving each LED
individually.
By muxing you only need 5+7=12 lines and 12 transistors, maybe 5 more
for
driving the high side. You select one digit at a time together with all
segments you want to light for that particular digit. Off course the
correspoding segments of the other digits are selected as well but
they do
not light as those digits are not selected.

An entire row is enabled at a time, just to be clear.

Muxing in the usual way would drive the LEDs in a ROW (0 to 7
of them) in parallel to each other. This isn't good as some
LEDs will hog the current. I want to know that if I set 100mA
as the peak current, that each LED will ACTUALLY have 100mA
as its peak (100% duty cycle) current.

I know that what I've done in the schematic has been done in
commercial products, because I've contracted to do work on
them before. OSRAM built 16x16 RGB modules, self-contained,
for OEM sales which actually used the technique I show (with
lots more transistors, but the idea is right.)

I'm just hoping for a simpler method to achieve precision (5%
worst case variation during a row-enable) current control of
each LED and not have them all with individual BJTs... but I
suspect that isn't possible. Going to RGB, which I intend on
also doing, only adds 14 more transistors per color, do 28
more for a total of 92 BJTs for 105 LEDs. So it scales better
than it looks.

Jon

I use a Constant Current Sink (not Source) to power a Common Cathode LED
matrix.

The Constant Current Sink pins are controlled via a shift register. Then
I use a 1-of-8 demuxer to select which "column" to use.

So, each column is powered by one state of the Constant Current chip,
then I disable all current, set up the next column in the shift
register, then move to the next column and enable current on the rows
that need it. This means each LED has its own independent current
controller.

BTW, I do this 16x60Hz so that I basically use PWM for intensity control
(16 levels of brightness) and the entire display updates 60 times a second.

For reference, I used 3 of TI's tlc5917 [1] chip as the current sink,
and a single 54HC238 [2] chip as the column selector. My MCU was an
ATTiny84 [3] (basically, a scaled down Arduino core), and the LED matrix
I used was equivalent to the one available from SEEED studio [4].

[1] <http://www.ti.com/lit/ds/symlink/tlc5917-q1.pdf
[2] <http://www.ti.com/lit/ds/symlink/cd54hc238.pdf
[3] <http://www.atmel.com/Images/doc8006.pdf
[4] <http://www.seeedstudio.com/depot/datasheet/2088RGBMatrix.pdf

I'm dedicating one micro per digit, to modularize this, for
now. So I have enough pins and don't need to worry about
more. And yes, I'm seeing the 5916/5917 as the best option
right now. ($1 each in small qtys.) MUCH less wiring results,
so worth the extra part cost over lots of half-penny BJTs.

Did you feel a need for the special error detection in the
5917 vs the 5916?

Thanks,
Jon

Jim Thompson · Mar 4, 2013

On Mon, 04 Mar 2013 13:53:04 -0800, Jon Kirwan
<jonk@infinitefactors.org> wrote:

On Mon, 04 Mar 2013 14:42:33 -0700, Jim Thompson
To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> wrote:

On Mon, 04 Mar 2013 13:37:26 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

Hmm. This makes the single programming resistor circuit a
little more complex, using discrete design. Looks like a
constant current sink chip with an external setting resistor
and up to 8 outputs and a shift register is the way to go,
then.

I suspect that there are constant current chips with built in
shift register enables. Know of any commonly used ones?

Thanks,
Jon

I know some custom ones...

Last year I did some chip designs for billboard video ;-)

I did tester and optical calibration systems for OSRAM's OWM
parts.

But they are unobtainium for me.

What do you think of:

TLC5916/5917, 3-5.5V operation, 5ma to 120mA, max 17V LED

http://www.ti.com/lit/ds/symlink/tlc5916-q1.pdf

Seems more than decent. 3% between LEDs and 6% between LEDs
on different ICs. I could live with that.

Jon

Jon Kirwan · Mar 4, 2013

On Mon, 04 Mar 2013 15:07:30 -0700, Jim Thompson
<To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> wrote:

On Mon, 04 Mar 2013 13:53:04 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Mon, 04 Mar 2013 14:42:33 -0700, Jim Thompson
To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> wrote:

On Mon, 04 Mar 2013 13:37:26 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

Hmm. This makes the single programming resistor circuit a
little more complex, using discrete design. Looks like a
constant current sink chip with an external setting resistor
and up to 8 outputs and a shift register is the way to go,
then.

I suspect that there are constant current chips with built in
shift register enables. Know of any commonly used ones?

Thanks,
Jon

I know some custom ones...

Last year I did some chip designs for billboard video ;-)

I did tester and optical calibration systems for OSRAM's OWM
parts.

But they are unobtainium for me.

What do you think of:

TLC5916/5917, 3-5.5V operation, 5ma to 120mA, max 17V LED

http://www.ti.com/lit/ds/symlink/tlc5916-q1.pdf

Seems more than decent. 3% between LEDs and 6% between LEDs
on different ICs. I could live with that.

Jon

Yep. That's a pretty standard matching.

Yes, given a boosted current mirror design, with differing
numbers of active current mirror sinking BJTs enabled, that
seems about the best I could expect with a simple BJT design
(I computed about 4% variation by hand _without_ taking into
account variations in discrete BJTs.) On an IC, I assume they
have more transistors (to improve on it) and better
uniformity (to also improve on it) so that 6% across ICs
seems like a comfortable design margin.

Jon

Daniel Pitts · Mar 4, 2013

On 3/4/13 1:58 PM, Jon Kirwan wrote:

On Mon, 04 Mar 2013 13:52:11 -0800, Daniel Pitts
newsgroup.nospam@virtualinfinity.net> wrote:

On 3/4/13 12:06 PM, Daniel Pitts wrote:
On 3/4/13 11:55 AM, Jon Kirwan wrote:
On Mon, 4 Mar 2013 11:18:07 +0100, "petrus bitbyter"
petrus.bitbyter@hotmail.com> wrote:

"Jon Kirwan" <jonk@infinitefactors.org> schreef in bericht
news:3ag7j8lpfoai4lm2giedg16b8n9hcbovut@4ax.com...
I'm considering a 5x7 LED digit module design to work with a
microcontroller with these two simple ideas:

(1) Constant current drive for the LEDs, settable by a single
external resistor. This will set the maximum (100%) LED
current. PWM (or PFM) will be used to individually reduce the
effective brightness on an LED by LED basis, referenced to
this maximum setting.

(2) A microcontroller Vcc rail, from 2.5V to 5.0V.

(3) Separate LED power supply rail, which can be higher than,
but not less than, the Vcc rail. The LED rail can be up to
15V, though dissipation issues will dictate that it be as low
as possible. I may, in the case of RGB, want three such
rails. The idea is to keep dissipation as low as reasonable,
but to allow flexibility, too. (2 LEDs in series, for
example, or blue vs red, etc.)

(4) Muxing is done with 5x, placing 7 LEDs per row, 5 rows,
and with 5x the average current. Since I may use 20mA LEDs,
this means 100mA peak LED current (as set by the external
resistor.)

(5) 5% variation in LED current across active LEDs in a row.

Variations in LED V vs I yield unacceptable differences in
brightness (noticeable) when operated in parallel.

I developed a tentative schematic (without slew rate limits),
but I'm using 64 BJTs to manage 35 LEDs. It works and none of
the transistors deal with more than Ic=100mA, neither the row
nor column ones. But that's a lot of BJTs and I'm betting I'm
missing something terribly obvious. (I'm using cheap 0.3 and
0.4 cent BJTs, so it's not expensive. Everything else is what
costs money.)

These 5x7 displays will be about 3" high, by the way, and I'm
using the 3d printer to make the black grids for mounting 5mm
LEDs.

Here's a portion that gets my mental state (bad as it may be)
across:

http://www.infinitefactors.org/schematics/portion%20of%205x7%20driver.png

What am I missing about simplifying this without putting LEDs
in parallel to each other during muxing?

Jon

If I understand your schematic well, you're driving each LED
individually.
By muxing you only need 5+7=12 lines and 12 transistors, maybe 5 more
for
driving the high side. You select one digit at a time together with all
segments you want to light for that particular digit. Off course the
correspoding segments of the other digits are selected as well but
they do
not light as those digits are not selected.

An entire row is enabled at a time, just to be clear.

Muxing in the usual way would drive the LEDs in a ROW (0 to 7
of them) in parallel to each other. This isn't good as some
LEDs will hog the current. I want to know that if I set 100mA
as the peak current, that each LED will ACTUALLY have 100mA
as its peak (100% duty cycle) current.

I know that what I've done in the schematic has been done in
commercial products, because I've contracted to do work on
them before. OSRAM built 16x16 RGB modules, self-contained,
for OEM sales which actually used the technique I show (with
lots more transistors, but the idea is right.)

I'm just hoping for a simpler method to achieve precision (5%
worst case variation during a row-enable) current control of
each LED and not have them all with individual BJTs... but I
suspect that isn't possible. Going to RGB, which I intend on
also doing, only adds 14 more transistors per color, do 28
more for a total of 92 BJTs for 105 LEDs. So it scales better
than it looks.

Jon

I use a Constant Current Sink (not Source) to power a Common Cathode LED
matrix.

The Constant Current Sink pins are controlled via a shift register. Then
I use a 1-of-8 demuxer to select which "column" to use.

So, each column is powered by one state of the Constant Current chip,
then I disable all current, set up the next column in the shift
register, then move to the next column and enable current on the rows
that need it. This means each LED has its own independent current
controller.

BTW, I do this 16x60Hz so that I basically use PWM for intensity control
(16 levels of brightness) and the entire display updates 60 times a second.

For reference, I used 3 of TI's tlc5917 [1] chip as the current sink,
and a single 54HC238 [2] chip as the column selector. My MCU was an
ATTiny84 [3] (basically, a scaled down Arduino core), and the LED matrix
I used was equivalent to the one available from SEEED studio [4].

[1] <http://www.ti.com/lit/ds/symlink/tlc5917-q1.pdf
[2] <http://www.ti.com/lit/ds/symlink/cd54hc238.pdf
[3] <http://www.atmel.com/Images/doc8006.pdf
[4] <http://www.seeedstudio.com/depot/datasheet/2088RGBMatrix.pdf

I'm dedicating one micro per digit, to modularize this, for
now. So I have enough pins and don't need to worry about
more. And yes, I'm seeing the 5916/5917 as the best option
right now. ($1 each in small qtys.) MUCH less wiring results,
so worth the extra part cost over lots of half-penny BJTs.
Yes, and the Shift Register+Latch aspect of it give you some advantages

as well. My MCU only needs 6 output pins to drive 192 LEDs. 3 for Column
Select, 1 for shift data, 1 for shift clock, and 1 pin which alternately
updates the latch and enables output.

The 74238/54HC238 has a way to do output-enable with either high or low
input, depending on which pin you connect to. I tied the "Latch" pin on
the 5196's to each other and to the "Output Enabled" pin on the 54HC238.
So that disabling the display latches the data. This seems to work
really well, but I'm pretty newbie so there might be some problem
lurking I don't know about

As far as "part cost", if you're hand building something, include the
time-cost of assembly and trouble-shooting.

Did you feel a need for the special error detection in the
5917 vs the 5916?

No. As a matter of fact, I think I have the 5916. I was quoting the part
number based on the URL I used here

.

I could see the error handling as more of a "professional" set up, where
I would want to alert an operator of a failure so they could replace the
module. Nothing I'd be working on.

Good luck. Let me know how it turns out.

Jon Kirwan · Mar 4, 2013

On Mon, 04 Mar 2013 14:52:27 -0800, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote:

On 3/4/13 1:58 PM, Jon Kirwan wrote:
On Mon, 04 Mar 2013 13:52:11 -0800, Daniel Pitts
newsgroup.nospam@virtualinfinity.net> wrote:

On 3/4/13 12:06 PM, Daniel Pitts wrote:
On 3/4/13 11:55 AM, Jon Kirwan wrote:
On Mon, 4 Mar 2013 11:18:07 +0100, "petrus bitbyter"
petrus.bitbyter@hotmail.com> wrote:

"Jon Kirwan" <jonk@infinitefactors.org> schreef in bericht
news:3ag7j8lpfoai4lm2giedg16b8n9hcbovut@4ax.com...
I'm considering a 5x7 LED digit module design to work with a
microcontroller with these two simple ideas:

(1) Constant current drive for the LEDs, settable by a single
external resistor. This will set the maximum (100%) LED
current. PWM (or PFM) will be used to individually reduce the
effective brightness on an LED by LED basis, referenced to
this maximum setting.

(2) A microcontroller Vcc rail, from 2.5V to 5.0V.

(3) Separate LED power supply rail, which can be higher than,
but not less than, the Vcc rail. The LED rail can be up to
15V, though dissipation issues will dictate that it be as low
as possible. I may, in the case of RGB, want three such
rails. The idea is to keep dissipation as low as reasonable,
but to allow flexibility, too. (2 LEDs in series, for
example, or blue vs red, etc.)

(4) Muxing is done with 5x, placing 7 LEDs per row, 5 rows,
and with 5x the average current. Since I may use 20mA LEDs,
this means 100mA peak LED current (as set by the external
resistor.)

(5) 5% variation in LED current across active LEDs in a row.

Variations in LED V vs I yield unacceptable differences in
brightness (noticeable) when operated in parallel.

I developed a tentative schematic (without slew rate limits),
but I'm using 64 BJTs to manage 35 LEDs. It works and none of
the transistors deal with more than Ic=100mA, neither the row
nor column ones. But that's a lot of BJTs and I'm betting I'm
missing something terribly obvious. (I'm using cheap 0.3 and
0.4 cent BJTs, so it's not expensive. Everything else is what
costs money.)

These 5x7 displays will be about 3" high, by the way, and I'm
using the 3d printer to make the black grids for mounting 5mm
LEDs.

Here's a portion that gets my mental state (bad as it may be)
across:

http://www.infinitefactors.org/schematics/portion%20of%205x7%20driver.png

What am I missing about simplifying this without putting LEDs
in parallel to each other during muxing?

Jon

If I understand your schematic well, you're driving each LED
individually.
By muxing you only need 5+7=12 lines and 12 transistors, maybe 5 more
for
driving the high side. You select one digit at a time together with all
segments you want to light for that particular digit. Off course the
correspoding segments of the other digits are selected as well but
they do
not light as those digits are not selected.

An entire row is enabled at a time, just to be clear.

Muxing in the usual way would drive the LEDs in a ROW (0 to 7
of them) in parallel to each other. This isn't good as some
LEDs will hog the current. I want to know that if I set 100mA
as the peak current, that each LED will ACTUALLY have 100mA
as its peak (100% duty cycle) current.

I know that what I've done in the schematic has been done in
commercial products, because I've contracted to do work on
them before. OSRAM built 16x16 RGB modules, self-contained,
for OEM sales which actually used the technique I show (with
lots more transistors, but the idea is right.)

I'm just hoping for a simpler method to achieve precision (5%
worst case variation during a row-enable) current control of
each LED and not have them all with individual BJTs... but I
suspect that isn't possible. Going to RGB, which I intend on
also doing, only adds 14 more transistors per color, do 28
more for a total of 92 BJTs for 105 LEDs. So it scales better
than it looks.

Jon

I use a Constant Current Sink (not Source) to power a Common Cathode LED
matrix.

The Constant Current Sink pins are controlled via a shift register. Then
I use a 1-of-8 demuxer to select which "column" to use.

So, each column is powered by one state of the Constant Current chip,
then I disable all current, set up the next column in the shift
register, then move to the next column and enable current on the rows
that need it. This means each LED has its own independent current
controller.

BTW, I do this 16x60Hz so that I basically use PWM for intensity control
(16 levels of brightness) and the entire display updates 60 times a second.

For reference, I used 3 of TI's tlc5917 [1] chip as the current sink,
and a single 54HC238 [2] chip as the column selector. My MCU was an
ATTiny84 [3] (basically, a scaled down Arduino core), and the LED matrix
I used was equivalent to the one available from SEEED studio [4].

[1] <http://www.ti.com/lit/ds/symlink/tlc5917-q1.pdf
[2] <http://www.ti.com/lit/ds/symlink/cd54hc238.pdf
[3] <http://www.atmel.com/Images/doc8006.pdf
[4] <http://www.seeedstudio.com/depot/datasheet/2088RGBMatrix.pdf

I'm dedicating one micro per digit, to modularize this, for
now. So I have enough pins and don't need to worry about
more. And yes, I'm seeing the 5916/5917 as the best option
right now. ($1 each in small qtys.) MUCH less wiring results,
so worth the extra part cost over lots of half-penny BJTs.
Yes, and the Shift Register+Latch aspect of it give you some advantages
as well. My MCU only needs 6 output pins to drive 192 LEDs. 3 for Column
Select, 1 for shift data, 1 for shift clock, and 1 pin which alternately
updates the latch and enables output.

The 74238/54HC238 has a way to do output-enable with either high or low
input, depending on which pin you connect to. I tied the "Latch" pin on
the 5196's to each other and to the "Output Enabled" pin on the 54HC238.
So that disabling the display latches the data. This seems to work
really well, but I'm pretty newbie so there might be some problem
lurking I don't know about

As far as "part cost", if you're hand building something, include the
time-cost of assembly and trouble-shooting.

Yeah, there is that of course. And board space required for
all those holes and traces. It's much more attractive this
way.

Still.... if I were doing up a LOT of these as a commercial
product ... I can get the BJTs at 0.003 and .004 per in to-92
-- probably cheaper in smt. They are very common and will
NEVER go away. Multisource everywhere. Part cost would be
low, but I suspect placing and board space would make up for
it. So yeah, I can't win with that crazy approach.

However... doing up discrete BJT current drivers that are
individually controlled, rather than the way I did it, would
cost more BJTs per... but instead of 35 BJTs for each LED, it
would be 7 sets of controllable drivers. So just the basic
idea you pointed at would also reduce the discrete count,
too.

I'm glad I sat down and learned something doing that up in
the first place, at least.

Did you feel a need for the special error detection in the
5917 vs the 5916?

No. As a matter of fact, I think I have the 5916. I was quoting the part
number based on the URL I used here .

Okay! I think I save 20 cents or more that way. (I'm finding
them at 85 cents each in ones as opposed to 1.04 for the '17.

I could see the error handling as more of a "professional" set up, where
I would want to alert an operator of a failure so they could replace the
module. Nothing I'd be working on.

Yeah. Same here.

Good luck. Let me know how it turns out.

Okay. I guess here, then.

The makerbot ABS module is very pretty, by the way. Makes a
very nice looking unit. And weather proof besides.

Jon

petrus bitbyter · Mar 4, 2013

"Jon Kirwan" <jonk@infinitefactors.org> schreef in bericht
news:qju9j8dr924gggpli9cddp7gfh54plao5r@4ax.com...

On Mon, 4 Mar 2013 11:18:07 +0100, "petrus bitbyter"
petrus.bitbyter@hotmail.com> wrote:

"Jon Kirwan" <jonk@infinitefactors.org> schreef in bericht
news:3ag7j8lpfoai4lm2giedg16b8n9hcbovut@4ax.com...
I'm considering a 5x7 LED digit module design to work with a
microcontroller with these two simple ideas:

(1) Constant current drive for the LEDs, settable by a single
external resistor. This will set the maximum (100%) LED
current. PWM (or PFM) will be used to individually reduce the
effective brightness on an LED by LED basis, referenced to
this maximum setting.

(2) A microcontroller Vcc rail, from 2.5V to 5.0V.

(3) Separate LED power supply rail, which can be higher than,
but not less than, the Vcc rail. The LED rail can be up to
15V, though dissipation issues will dictate that it be as low
as possible. I may, in the case of RGB, want three such
rails. The idea is to keep dissipation as low as reasonable,
but to allow flexibility, too. (2 LEDs in series, for
example, or blue vs red, etc.)

(4) Muxing is done with 5x, placing 7 LEDs per row, 5 rows,
and with 5x the average current. Since I may use 20mA LEDs,
this means 100mA peak LED current (as set by the external
resistor.)

(5) 5% variation in LED current across active LEDs in a row.

Variations in LED V vs I yield unacceptable differences in
brightness (noticeable) when operated in parallel.

I developed a tentative schematic (without slew rate limits),
but I'm using 64 BJTs to manage 35 LEDs. It works and none of
the transistors deal with more than Ic=100mA, neither the row
nor column ones. But that's a lot of BJTs and I'm betting I'm
missing something terribly obvious. (I'm using cheap 0.3 and
0.4 cent BJTs, so it's not expensive. Everything else is what
costs money.)

These 5x7 displays will be about 3" high, by the way, and I'm
using the 3d printer to make the black grids for mounting 5mm
LEDs.

Here's a portion that gets my mental state (bad as it may be)
across:

http://www.infinitefactors.org/schematics/portion%20of%205x7%20driver.png

What am I missing about simplifying this without putting LEDs
in parallel to each other during muxing?

Jon

If I understand your schematic well, you're driving each LED individually.
By muxing you only need 5+7=12 lines and 12 transistors, maybe 5 more for
driving the high side. You select one digit at a time together with all
segments you want to light for that particular digit. Off course the
correspoding segments of the other digits are selected as well but they do
not light as those digits are not selected.

An entire row is enabled at a time, just to be clear.

Muxing in the usual way would drive the LEDs in a ROW (0 to 7
of them) in parallel to each other. This isn't good as some
LEDs will hog the current. I want to know that if I set 100mA
as the peak current, that each LED will ACTUALLY have 100mA
as its peak (100% duty cycle) current.

I know that what I've done in the schematic has been done in
commercial products, because I've contracted to do work on
them before. OSRAM built 16x16 RGB modules, self-contained,
for OEM sales which actually used the technique I show (with
lots more transistors, but the idea is right.)

I'm just hoping for a simpler method to achieve precision (5%
worst case variation during a row-enable) current control of
each LED and not have them all with individual BJTs... but I
suspect that isn't possible. Going to RGB, which I intend on
also doing, only adds 14 more transistors per color, do 28
more for a total of 92 BJTs for 105 LEDs. So it scales better
than it looks.

Jon

So I understand you to activate one or more whole rows at once. But as
you're multiplexing I suppose you activate only one column at a time. This
way only one LED of each row can light, all others of that row are in other
columns. So why not tie all cathodes of the LEDs of one row together using
only one transistor to drive them? You can still control the brightness of
every single LED. For instance you set the rate of column activation to 5ms
and vary the row activation from 0 up to 5ms depending on the brightness
required for that particular LED.

petrus bitbyter

Jon Kirwan · Mar 4, 2013

On Tue, 5 Mar 2013 00:12:35 +0100, "petrus bitbyter"
<petrus.bitbyter@hotmail.com> wrote:

"Jon Kirwan" <jonk@infinitefactors.org> schreef in bericht
news:qju9j8dr924gggpli9cddp7gfh54plao5r@4ax.com...
On Mon, 4 Mar 2013 11:18:07 +0100, "petrus bitbyter"
petrus.bitbyter@hotmail.com> wrote:

"Jon Kirwan" <jonk@infinitefactors.org> schreef in bericht
news:3ag7j8lpfoai4lm2giedg16b8n9hcbovut@4ax.com...
I'm considering a 5x7 LED digit module design to work with a
microcontroller with these two simple ideas:

(1) Constant current drive for the LEDs, settable by a single
external resistor. This will set the maximum (100%) LED
current. PWM (or PFM) will be used to individually reduce the
effective brightness on an LED by LED basis, referenced to
this maximum setting.

(2) A microcontroller Vcc rail, from 2.5V to 5.0V.

(3) Separate LED power supply rail, which can be higher than,
but not less than, the Vcc rail. The LED rail can be up to
15V, though dissipation issues will dictate that it be as low
as possible. I may, in the case of RGB, want three such
rails. The idea is to keep dissipation as low as reasonable,
but to allow flexibility, too. (2 LEDs in series, for
example, or blue vs red, etc.)

(4) Muxing is done with 5x, placing 7 LEDs per row, 5 rows,
and with 5x the average current. Since I may use 20mA LEDs,
this means 100mA peak LED current (as set by the external
resistor.)

(5) 5% variation in LED current across active LEDs in a row.

Variations in LED V vs I yield unacceptable differences in
brightness (noticeable) when operated in parallel.

I developed a tentative schematic (without slew rate limits),
but I'm using 64 BJTs to manage 35 LEDs. It works and none of
the transistors deal with more than Ic=100mA, neither the row
nor column ones. But that's a lot of BJTs and I'm betting I'm
missing something terribly obvious. (I'm using cheap 0.3 and
0.4 cent BJTs, so it's not expensive. Everything else is what
costs money.)

These 5x7 displays will be about 3" high, by the way, and I'm
using the 3d printer to make the black grids for mounting 5mm
LEDs.

Here's a portion that gets my mental state (bad as it may be)
across:

http://www.infinitefactors.org/schematics/portion%20of%205x7%20driver.png

What am I missing about simplifying this without putting LEDs
in parallel to each other during muxing?

Jon

If I understand your schematic well, you're driving each LED individually.
By muxing you only need 5+7=12 lines and 12 transistors, maybe 5 more for
driving the high side. You select one digit at a time together with all
segments you want to light for that particular digit. Off course the
correspoding segments of the other digits are selected as well but they do
not light as those digits are not selected.

An entire row is enabled at a time, just to be clear.

Muxing in the usual way would drive the LEDs in a ROW (0 to 7
of them) in parallel to each other. This isn't good as some
LEDs will hog the current. I want to know that if I set 100mA
as the peak current, that each LED will ACTUALLY have 100mA
as its peak (100% duty cycle) current.

I know that what I've done in the schematic has been done in
commercial products, because I've contracted to do work on
them before. OSRAM built 16x16 RGB modules, self-contained,
for OEM sales which actually used the technique I show (with
lots more transistors, but the idea is right.)

I'm just hoping for a simpler method to achieve precision (5%
worst case variation during a row-enable) current control of
each LED and not have them all with individual BJTs... but I
suspect that isn't possible. Going to RGB, which I intend on
also doing, only adds 14 more transistors per color, do 28
more for a total of 92 BJTs for 105 LEDs. So it scales better
than it looks.

Jon

So I understand you to activate one or more whole rows at once. But as
you're multiplexing I suppose you activate only one column at a time. This
way only one LED of each row can light, all others of that row are in other
columns.

No. I can operate more than one LED at a time with the
schematic I laid out. Anywhere from 0 to 7 of them. So I only
need to do 5x scanning for the display.

So why not tie all cathodes of the LEDs of one row together using
only one transistor to drive them? You can still control the brightness of
every single LED. For instance you set the rate of column activation to 5ms
and vary the row activation from 0 up to 5ms depending on the brightness
required for that particular LED.

I think Dennis identified my stupidity, already, pointing out
the use of a x8 controller like the TLC5916. I had avoided
setting up completely separate and individually controllable
current sinks in the silly idea of reducing BJT count, while
actually doing the opposite. Although it takes more BJTs to
do individually controllable current sinks, it takes a lot
less of them to do the job. So it's a win. I just missed it
while taking my first shot at this. Which is why I posted, to
get my head bashed in. Dennis did that perfectly. Made
absolute sense the way he wrote so clearly to me.

Jon

Jon Kirwan · Mar 4, 2013

On Mon, 04 Mar 2013 15:27:09 -0800, I wrote:

snip
I think Dennis identified my stupidity, already, pointing out
the use of a x8 controller like the TLC5916. I had avoided
setting up completely separate and individually controllable
current sinks in the silly idea of reducing BJT count, while
actually doing the opposite. Although it takes more BJTs to
do individually controllable current sinks, it takes a lot
less of them to do the job. So it's a win. I just missed it
while taking my first shot at this. Which is why I posted, to
get my head bashed in. Dennis did that perfectly. Made
absolute sense the way he wrote so clearly to me.

Sorry!!! That is Daniel!!!!

Jon

Jon Kirwan · Mar 4, 2013

On Mon, 04 Mar 2013 13:54:57 -0800, Daniel Pitts
<newsgroup.nospam@virtualinfinity.net> wrote:

On 3/4/13 1:50 PM, Jon Kirwan wrote:
On Mon, 04 Mar 2013 13:37:26 -0800, I wrote:

Hmm. This makes the single programming resistor circuit a
little more complex, using discrete design. Looks like a
constant current sink chip with an external setting resistor
and up to 8 outputs and a shift register is the way to go,
then.

I suspect that there are constant current chips with built in
shift register enables. Know of any commonly used ones?

Thanks,
Jon

I'm pretty much finding this $1 part:

TLC5916/5917, 3-5.5V operation, 5ma to 120mA, max 17V LED

Looks okay for my goals.

Jon

Yup, that's the one I used. I replied to my earlier message with the
list of components I used for my project (sans resistors and the 20MHz
oscillator).

Just ordered 25 of the DIP from arrow at .81 each, plus about
$5 shipping, which brings them to about $1 each.

Jon

5x7 LED matrix driver

Jon Kirwan

Guest

petrus bitbyter

Guest

Jon Kirwan

Guest

Daniel Pitts

Guest

Jon Kirwan

Guest

Jon Kirwan

Guest

Jim Thompson

Guest

Jon Kirwan

Guest

Daniel Pitts

Guest

Jon Kirwan

Guest

Daniel Pitts

Guest

Jon Kirwan

Guest

Jim Thompson

Guest

Jon Kirwan

Guest

Daniel Pitts

Guest

Jon Kirwan

Guest

petrus bitbyter

Guest

Jon Kirwan

Guest

Jon Kirwan

Guest

Jon Kirwan

Guest

Log in

Welcome to EDABoard.com

Sponsor