How to control 150 LEDs ?

Go To Last Post
34 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All -

I'm trying to figure out the best way to control 200 LEDs - each individually. They're arranged in 5 groups of 40, so this is almost definitely a job for a mega128.

One simple method would be to have a bunch of shift registers/latches. Load the registers for one set, clock 'em in, then on to the next set. That tends to add up to a whole lot of additional chips though. With 8-bit registers, that's 5 chips per group. Gah.

To continue that thought, maybe a PLD of some sort. One of the CPLD ones with a huge pin-count - x pins in, 4 pins for group select, and 200 for the LEDs.

So, ideas ?

Dean.

Dean 94TT
"Life is just one damn thing after another" Elbert Hubbard (1856 - 1915)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have a look at the Toshiba TB62706BF, which is a 16 bit constant current LED driver with latch and shift register in an SSOP24. Another possibility would be the Allegro UCN5832A, available in a PLCC44, which is a 32 bit serial input latched driver originally intended for driving thermal print heads, but now used (according to Allegro) for driving multiplexed LED arrays.

There may be other similars, but these are the two devices I have looked at myself.

Bill

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, you don't need a Mega128 thats for sure. With enough extra chips, you could do this with just a couple i/o lines. A bit simpler would be to use some of the LED or LED-matrix driver chips. I know some handle 35 leds per chip, not sure if any will do 40. TI makes some led drivers with internal shift registers that allow you to address 16 leds individually with a single i/o line.

If you can arrange them in a 15x15 matrix (logically, not physically) you could multiplex them all using 2 3-to-8 mux chips per side...4 total chips I think, and 6 i/o lines needed, plus maybe a couple for clocking and reset.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heh - I was just reading the datasheet on the UCN5833EP. Same thing.

But that still requires at least 5 additional chips :( I'm very real-estate constrained for the control system - the LEDs are off-board.

I've never done (C)PLD work before. How hard is it really to generate custom logic like this ? I've found a couple of "tutorials" on PLD programming - I'll have to dig into those. Also, it looks like Altera makes their software available free, so I guess I'll look at them first.

Good on ya Altera :)

Dean.

Dean 94TT
"Life is just one damn thing after another" Elbert Hubbard (1856 - 1915)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Doing the CPLD design is not terribly difficult, but consider that it still does not give you the current drivers. If you used the 16 bit constant current driver, and treated an array of 40 LEDs as 5X8, then two such chips would handle 4 of the 5 arrays (driving the rows), and require only 1 or 2 chips for column drive (not sure if there are any 10 bit drivers around.) Using three of the constant current drivers plus two 8 line current sinks would handle 200 LEDs, and your mux rate of 5:1 is not bad at all.

All a CPLD buys you is a lot of pins, and then you still need current drivers. If you get the serial access constant current drivers, and parallel access column drivers w/o latching, then you need only the pins available on an 8515. If you get serial access latched column drivers, you could probably use a 20 pin CPU.

Bill

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or arrange each bank as a 6x7 array, then a single 32-bit Allegro driver could drive the rows for all 5 banks. Then you could drive the columns with a 8 bit driver and get away with 2 chips total?

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you have a look at a TTL data book you will find a 4 to 16 MUX IC.
I don't remember the part number but you shoud be able to find it quite easily.

Anyway, if you arrange the LED's in a Matrix or 12x13 and rig them up as common Row and Cols then you could setup a Timer0 interrupt to write to each LED individually based on an array lookup or bit twiddling a var etc.

The interrupt would need to keep all of the LED's refreshed at >=15Hz to take advantage of persistence of vision and is calculated as such -

1second / (Number of LED's on at one time * Refresh frequency)

So to keep all 150 LED's flicker free would equate to a 2250Hz interrupt.

The advantage is that only one TTL output is ever sourcing current and only one is sinking at any given time and from my experience a direct TTL output will drive a standard LED (20ma) quite nicely.

Another thought would be to control the output pulse width within the interrupt and therefore the amount of current consumed by the LED. This way you could even do away with the current limiting resistors altogether and therefore further reduce the cost and bulk of the design.

Sy

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mike:
The 6X7 array hadn't occurred to me, but seems a much better approach. :) And though 30 LEDs per column could be on (max), the current to each LED can be small, as the duty cycle is 100%. The downside is the total current for the array could be fairly large, but if you strobed the columns in a round robin, then each has a 1/7 duty cycle, which is fine for the muxing, and though the per LED current will go up, the total will go down, perhaps 2 or 3 to 1, depending on the efficiency of the LEDs, and the brightness needed.

Symon:
Extremely low duty cycles won't get the job done, and the 20mA per LED, with a duty cycle of less than 1% will require a darkened room for viewing.

Bill

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You could also use two AVR's connected serially each managing 128 LED's...
Two AT90S8515's should be sufficient (of course with a few transistors)...

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CPLD's are very easy to do. Altera has devices that can handle up to 100ma per pin, I believe that would be plenty of an output. I am pretty handy at VHDL, if you need assitance just ask,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bill,

Thanks, but I'm sure I'd rather write the code for your approach than mine. 6X7 might save a couple chips, but all those odd byte boundaries would give me a headache fast :-)

Joker,

Driving 200 Leds directly would mean up to 2 _amps_ of current. A CPLD might sink 100mA per pin, but I'm pretty sure they have some very stringent rules about total current per IOGND or device, don't they? And a CPLD driving these directly would still need current-limiting resistors...resistors that are built into LED driver chips. The 200+ pin CPLD approach seems to take more board space, not less.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bill,

Thanks, but I'm sure I'd rather write the code for your approach than mine. 6X7 might save a couple chips, but all those odd byte boundaries would give me a headache fast :-)

Joker,

Driving 200 Leds directly would mean up to 2 _amps_ of current. A CPLD might sink 100mA per pin, but I'm pretty sure they have some very stringent rules about total current per IOGND or device, don't they? And a CPLD driving these directly would still need current-limiting resistors...resistors that are built into LED driver chips. The 200+ pin CPLD approach seems to take more board space, not less.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean

I have done a display baord that uses 420 leds in total this with an rs232 interface and decoding of text messages from mobiles into displayable drive data. It is done with an 8515, 8 X573 as latches and 60 transistors as current drivers. The data is broken down into 7 60 bit strings for the 7 rows and multiplexed in 12 columns. so at any one time up to 12 leds are on.

The Leds in this case are in a 7 by 5 matrix package.

When I set out to do it a bit of panic set in but it came good in the end.

Mike

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've done a 7*22 LED matrix with dual color LED's. That's 308 LED's in total. (each physical LED is built of two LED's red+green)
I arranged them logically in 7 rows of 44 LED's each.
Building LED matrixes with much more than say 10 rows might make it hard to get the LED's bright enough.

I use 7 high power TO220 transistors to drive each row since max current per row is about 3A (!!).
For now I use 44 low power transistors, 88 resistors and 6 * 8bit shift registers with built in latches to drive the columns. All standard components.
This is actually i little cheaper than thoose specially made 32 bit LED drivers. However, it takes up quite some board space. Not to mention the work of drilling and soldering all thoose pads...

I use a 8535, but I don't use half of it's I/O pins... however, I need the large flash memory to store text fonts and stuff. The whole thing is connected to a PC via RS232.

To scroll some text I can just write ""echo "Insert text here" > /dev/ttyS0"" at my Linux prompt. Neat, huh? :)

The LED matrix is made to fit a 5.25" CDROM bay perfectly, I use it to scroll text, display WinAmp's frequancy analyser, and so on...
Here are a picture and some small mpeg videos of it in action:
http://www.hh.se/stud/d99tibr/in...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow.

This is excellent - talk about a generated discussion. Lots of ideas to contemplate here.

As a question, how do the scrolling marque type LED displays control their arrays of LEDs - anyone know ? I've seen the posts here with the smaller ones, but how do the really big ones many hundreds of LEDs do it ?

Dean.

Dean 94TT
"Life is just one damn thing after another" Elbert Hubbard (1856 - 1915)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My guess is that the matrix LEDs and the large driver chips exist simply because of these large arrays. Since the multiplexing gets pretty dicey beyond 8:1, I assume that in the large arrays, there are many sectors (subarrays) in use. In fact, I've seen some evidence of this in the (mis)behavior of some of these things in public venues.

Bill

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thoose text displays are generally about 64*7 LED's in size...
They light up one row of 64 LED's at a time, (of course using two 32 bit LED driver IC's)

The current necessary to drive 64 LED's at once is however quite high... 6.4A if you feed each LED with 100mA.. So I'd say they probably use two or three power transistors in parallell for each row to take care of the current.

I've seen a few quite impressive LED displays... There was this one at a big bus station, displaying arrival times and such... It must have been like 2*3 meters!!
Think about it! Millions of (!dual color!) blinkenlights working together! :)
It looked quite impressive.

I'd say for that kind of display they probably have some kind of module system, it must be impossible to do it any other way.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Several years ago, I provided routine service for a rather large (33'x110') video display in a sports facility. Each pixel was about 1.5" square, and there were two in each of 67,200 tubes! There were 4200 chassis of 16 tubes each, and each received a parallel data connection, and a radial selector, as well as power. Oh yeah, power... about 400KW

Then there was the hot summer day when I arrived to find large blocks of the image slipping back and forth several feet at a time... One look, and I knew the cause. Can you guess?

Bill

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just using power transistors completely in parallel is not usually a good idea, because of their thermal characteristics. If one starts to get hot, its effective resistance decreases and it starts to sink more current, which in turn makes it hotter. In extreme cases, you can get most of the current going through one transistor.

It would be better to have, say, 1 transistor sinking current from each sub-row section of 8 or 16 LEDs, in a common-emitter configuration, and then drive all the bases from a single output through appropriate base resistors.

Sean.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sellis: You are right.. Better divide them into sections.
64 LED's divided into two section of 32 LED's each with one transistors driving each section should be enough...
Easy to build too.. Just one row of 7 transistors at each end of the display.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've used a part called 5150 (made by Nat Semi and others) in the past. This drives 35 LEDs without multiplexing and is serially controlled. The chip has a current control input which allows you to control the amount of current fed to each LED, perhaps from a PWM output from the AVR. It comes in a PLCC44 package.

You don't say what the scale of your project is, but if you need to consider EMC and CE (and who doesn't these days) it is tricky, to say the least, to design a high-current multiplexed display like the one outlined in this thread. My particular product was for a LED display containing up to 2000 LEDs and it passed EMC and CE testing first time.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is actually for a five-arm rotating display - Similar to the propeller clocks that were all the rage a while back. The difference here is that it has to be able to display nicely not only at fairly high rpm (around 1000rpm) but also at low rpm rates, say 300rpm or so (5Hz). Hence the 5 arms rather than just one or two, that will give a better visual persistence. Might be able to get away with three arms though ...

The other is that I would like to be able to display more than just the time or words - so just 7 LEDs won't cut it. It looks like 35 or 40 LEDs per arm is about the bare minimum for anything decent.

I hadn't even considered mux'ing the LEDs, I've been more concerned with maximizing the on time for each time slot. How much of a brightness effect would mux'ing like this cause ?

Actually, here's another hassle I've been noodling - the data storage format. The simplest would be to store bit patterns for each slot or display-time-tick. That gives discrete "pixels" per se. Not too bad, but it could be better. Particularly since the outer LEDs will be individual-looking, while the inner ones will have lots of overlap.

That can be mitigated by dealing with them in chunks. Say the outer five LEDs have 360 slots or pixels, the next five in have 300 slots, and so on. Numbers here are for arguments sake :) I haven't calculated out all the best sizes yet, but I know how to do it this way.

Another method is to store on and off times for each ring in the display. Or one can think of it as a polar display, and store the start and stop thetas for each d.

Pulling bit patterns out of memory and twiddling them is pretty easy. But my head hurts when I think about how to arrange the data for the second method, and it really hurts when thinking about how to access it efficiently.

Lots of expertise in this forum - this is great :)

Dean.

Dean 94TT
"Life is just one damn thing after another" Elbert Hubbard (1856 - 1915)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> "I hadn't even considered mux'ing the LEDs, I've been more concerned
> with maximizing the on time for each time slot. How much of a brightness
> effect would mux'ing like this cause ?"

Using a narrow, high-current pulse gives you more "bang for your buck", both in visual intensity and in power usage. But since these LEDs are rotating, the mux frequency will be more of an issue-- a 200 hz mux rate won't cut at 1000 rpms. I'd guess 5-10 degrees of angular displacement per pulse would be a maximum without impacting the perception of continuity.

Regarding data format, why not attack that issue at the physical level? Make CAV (constant angular velocity) arms! By that I mean do what they do in CAV disks...spread your data out. Put less LEDs in the inner rings, in a descending scale based on absolute rotational speed. Then you can treat each ring visually the same.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What the heck does the fact that the leds are spinning have to do with multiplexing them ?

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Multiplexing works because your eye has a certain persistence of vision. However, if the multiplexed output is moving relative to the eye, the persistence of vision is modified.

If you have a 4-digit LED alarm clock (or microwave oven, or video), try this experiment in subdued light. We're going to move your eye relative to the display, but the converse would hold.

Look straight at the 4 time digits. They should appear to be in a straight, horizontal line. Now, rapidly look up and down at something above and something below the display. If you can keep your attention on the digits while you're doing this (not easy, but subdued light helps), then you will notice that they no longer seem to be in a straight line.

OK, not a big deal for a microwave, but definitely a big deal for a high-speed spinning display.

Bottom line: don't multiplex the arm - all the LEDs on one arm must come on or go off at the same time, otherwise they will appear bent. You can multiplex between arms, though.

Sean.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> "Bottom line: don't multiplex the arm "

Not at 100 hz surely. But for his stated speed of 1000 rpm, a mux rate of 900-1200 hz would be adequate. After all, his design is depending on visual persistence between arms to create the perception of a single display. As long as the cycle time for a single pulse creates significantly less angular separation than that between two arms, it should work fine.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

True, as long as you don't multiplex *along* the arms, which would give a displeasing "bent" effect, even at small time differentials.

Sean.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If we assume a one foot arm rotating at 1000 rpm, that becomes a linear velocity of (2000pi/60)= 105 feet/sec. Assuming the innermost LEDs begin 2 inches out on the arm, their rotational speed = 17.5 fps. At a 1200 hz flicker, that becomes an (105-17)/1200 = 0.87 inch distortion.

As the outermost arms have a linear separation of (24/5)pi = 15 inches, this effect would be trivial compared to the inter-arm distortion, wouldn't it? For 5 arms to create a perceived monolithic display, the eye will have to visually join the innermost led on each arm with the outermost led on any other arm, a distortion of over 20 times what muxing gives.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Two years ago I built a 672 led moving message display, consisting of 4 boards with 24x7 single jumbo leds each. A board had 3 8-bit shift-registers, each driving a column of 8 leds. The first one's carry output was connected to the next one's carry input and so on, so only two pins (one data- and one clockline) were needed to load the content of a complete row (96 leds) into the shift-registers. Each row was driven by a transistor, so you needed 7 additional pins to control all transistors. So you load the first row, switch it's transistor on for some time, switch it off, load the next row and so on. Btw, I used a AT89C2051 @ 6 Mhz, so I'm sure noone needs a mega128. Oh, and the baby is still running today ;-) Sorry for my bad english...

Tobias

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heh - wow again. Good discussion here.

Mike -

I'm not sure I'm following you here.

> For 5 arms to create a perceived monolithic display, the eye will have to visually > join the innermost led on each arm with the outermost led on any other arm, a > distortion of over 20 times what muxing gives.

What do you mean visually join the innermost led with the outermost ? I'm not sure I'm visualizing the same thing you're intending ...

I've also been thinking about the resolution of the display. The simple way is to have say 360 display-slots. 360 bit patterns to make up an image. Pull a pattern, display it for a length of time for that display slot, then the next, etc. But that has the afore-mentioned overlap problem - the outer leds have nice discrete individual appearances, while the inner ones all congeal into an overlapping blob. Could do it in chunks, as mentioned above as well. But I like your idea of treating each led individually. Same idea as chunks, just taken to the logical extreme.

That will definitely make the data format and storage/retrieval much more complicated though. The simple 360 way is easy : just pull bit patterns from memory and shift em into the registers. Each bit pattern occurs at a set time. But running each led/ring with an individual total "pixel-count" or on-off slots per rotation for the whole display, now that messes things up :)

Fake numbers here : You would have to retrieve led1 bit pattern every 200 ticks. leds2 would be every 203 ticks. led3 every 209 ticks. So we'll need a bit-pattern for each led/ring rather than a bit pattern for each display slot. Also a table to say how often (how many ticks per) to retrieve the next bit for each led/ring. Since rotational speed is variable, those will have to be virtual ticks, scalable to the current rotational speed.

At the start of each rotation load a table with the scaled tick counts. Then every tick, check against the table. Any match, go get the next bit for that ring and shift it in to place. Heh, maintaining the pointers and accessing the individual bits like will be messy.

OK, enough software ...

My original hardware plan was to have a PLD of sorts driving all the leds. It would consist of five individual 40bit shift registers with 200 output pins for the leds, 4 bits for register select, and a couple of pins for serial and clock in. The cpu would select register A, clock in 40 bits, select register B, clock in 40 bits and so on. Then it would sit and twiddle its thumbs for a display-slot duration, then repeat with the next slot bit pattern. Hrm - had forgotten to check on total power dissipation for PLDs. Probably couldn't handle 200 leds at 20ma each :) So, that plan is now discarded.

Now it looks like muxing is a much better answer. Rather than twiddle thumbs, it could use that time to cycle among the five arms. Set the leds up in a 5x40 array, clock in the arm A pattern, display it, clock in the arm B pattern, display it, and so on. Repeat until the display-slot duration expires, then retrieve the next pattern and continue.

So instead of a mass of pins, we wind up with a single 40bit register - two chips probably.

Getting there :)

Dean 94TT
"Life is just one damn thing after another" Elbert Hubbard (1856 - 1915)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

LED driver, 8 x 16, or 16 x 16 using two, or they can be cascaded

http://www-s.ti.com/sc/ds/tlc592...

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi friends,thanks for mind blowing discussions here,
as part of my final project ,i want to make " display 45 characters in a single line of around 3"x2" as each character size,is there any std raw led structures available readily or i hav to move by forming matrix on pcb?

will it be better if I USE AVR ATmega32 controller? and (i am planning to use conventional transistor and resistor combinations as driver to provide the necessary current)...
plz frnds , help me out with ur valuable guidelines....!!

prashu
[hardwork never fails]

Quote:


Quote:


Quote:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

thanks for mind blowing discussions here,

Even if it was EIGHT years ago eh? ;-)

A Moderator.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
use conventional transistor and resistor combinations
Congratulations, you are starting off on the right foot.

Now start a new thread and show what you are doing or what you have done and where the problems, if any, are.

You should find a few projects like yours around to get you started.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly