Need some guidance on a project

thecyberbob

Greetings all. I've been looking to start a POV display project that would incorporate 64rgb LEDs using a bunch of TLC5940 chips to drive them. The extra trick on top of this is that I'd like to control what is being displayed by the LED's by having a Propeller chip read in a Bitmap image one "column" at a time and push out the RGB values to the TLC5940 chips.

I know that every individual part of this project can be done by the Propeller
1. Reading a file from an SD card: http://forums.parallax.com/forums/default.aspx?f=25&m=136676
2. Driving a large array of TLC5940's: http://forums.parallax.com/forums/default.aspx?f=25&m=164062

But I don't know if the Propeller could handle it all wrapped up together AND if it could handle decoding every pixel in a BMP file as a RGB value.

If this is possible and if you guys have and guidance I'd greatly appreciate it. Thanks!

MagIO2

I would start with some calculations.

We have a SDcard transfer rate of ~1.5MB/s
You have 64RGB LEDs. (Really RGB? So you have to drive 64*3 LEDs? )
One TLC5940 has 16 channels. So, how many TLCs do you need?
How many pixels do you get when you divide the transfer-rate with the number of LED's at a refresh rate of min. 20 pictures per second?

Which kind of POV do you have in mind? A clock-like POV where the LEDs are mounted on the arms? Or a cylindrical POV?

Reading a BMP is not a problem. Pixels are already available as 8 bit RGB data, so you only have to remove the least significant bits and send the result to the TLCs.
Depending on the type of POV you might have to rotate the image or store it in a completely different way (for the clock-like POV) to support fast reading.

thecyberbob

Yup. You are correct regarding with the assumption of essentially 192 LED's. I calculated that I'd need 12 TLC's.

Overall I wasn't planning on having any complicated animations that require a high frame rate (although that would be seriously cool), and was more thinking of having it display static images for the most part. The type of display was going to be a spherical POV display so I suppose a Cylinder is about the closest "simple" shape really.

Rayman

I was showing off my prototype 8x8xRGB LED matrix driver at UPEW...

It drives all the leds with just one Prop with 27-bits per pixel color.

Does levels by PWM at about 1000 Hz to be flicker free.

Basically, I just use 3 darlington arrays, 4 dual P-channel mosfet chips and one 3:8 logic decoder to make it work...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Apps:· http://www.rayslogic.com/propeller/Programming/Programming.htm

My Prop Info: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm

thecyberbob

@Rayman: Do you have anymore detail on that project of yours? I'd like to read up on it.

Timothy D. Swieter

You could use the LED Painter product by Brilldea (my company) to drive all the LEDs. At the moment though we are short on kits though.

I have another product that is about to be ready for sale - LED Painter II which uses the A6281 to control groups of LEDs.

Another option would be to use the Brildlea PolkaDOT-51, which is a combination of an A6281 and RGB LED. These pixels are easily strung together to form long chains of up to 250 ICs without an additional buffering required.

As for speed, updating the string of pixels shouldn't be too bad. I don't know much about what is required to translate the BMP to buffer, but if you can get the buffer filled fast enough - and there is enough buffer space that the POV needs to work through in order to work then you should be good to go.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com

Rayman

thecyberbob said...
@Rayman: Do you have anymore detail on that project of yours? I'd like to read up on it.

thecyberbob, this is something I've had on the backburner for a long time, but haven't written much about...

I did post the PCB layout here (although there was a mistake or two):
http://forums.parallax.com/showthread.php?p=878506


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Apps:· http://www.rayslogic.com/propeller/Programming/Programming.htm

My Prop Info: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm

thecyberbob

@Rayman: Thanks! I'm still in the planning phases for my own design anyways so right now I'm just at the experiment and design stage really. So as far as I'm concerned any more reading material on doing similar work is good material.

@Timothy: Those are interesting project boards. I think they may be the wrong sort of configuration for the layout I had in mind Plus having a stack of 4 of those PCB's for the TLC's may be a bit much. The PolkaDot is an intriguing idea though. Although since they'll be mounted on a curved arm to achieve the globe effect I think they may be a bit too bulky for that (I was hoping to have only LED's and wires on the armature to keep it looking simplistic). I'll research into the A6281 chip though as that sounds like a decent solution as well for controlling the LED's.

MagIO2

Spherical ... hmmm ... is it 64 LEDs on one side or do you have 32 on one side and 32 on the other?

The problem with sperical POVs is, that the angle-velocity on the poles is much less than on the equator. So, having the same current the LEDs close to the poles are brighter.

From the transfer-rate and the other values I calculated a possible resolution of 400 pixels per revolution. I think it very much depends on the size of the POV (radius of the sphere) if this is enough.

What are your plans for the PCB? Will the whole electronics rotate?

By the way ... the refresh rate is not 'needed' for animations ... it's essential for a POV.

Post Edited (MagIO2) : 6/29/2010 5:47:25 PM GMT

thecyberbob

Ah. I was taking the refresh rate as in the entire image not just a single line. Sorry.

The idea was to have all 64 on one side to simplify the programming (display 1 line and just go column by column at a given rate etc).

The PCB was going to spin with the wheel itself but location wise it would sit below a base with a hollow axel that would feed all necessary wiring to a loop that I'd attach the LEDs to down 1 side. The PCB's would be made in a series of small(ish) plates that would be staked around the axel and hidden within a wooden base. I envisioned having every plate have a particular "job". So 1 plate would contain the SD Card, Propeller and some stuff to regulate power appropriately (again I'm still in the planning phases). The next plate(s) above that would contain the TLC's to drive the LED's. That's the general idea. I could whip together a quick diagram sometime tonight to better illustrate it all though.

MagIO2

You need a counter-weight anyway, or the whole thing will start to swing and must be more massive to withstand the swinging. So, I'd prefere to have 2 lines of LEDs on the opposite side - of course slightly shifted up or or down against each other. This way the whole thing works like interlaced TV. Besides having a balanced system because it's symmetrical, you also have the impression of a 40Hz refresh even if you run the motor at 20 rounds per second.

Programming is not much harder especially when you optimize the bmp for that. You can have a SPIN program which reads a normal BMP and creates a version which has 32 pixels taken from the odd lines of the original and then 32 pixels from the even lines of the original, shifted by 180 degrees ( starting in the middle of the original picture ).

What diameter will the sphere have?

Timothy D. Swieter

Attached is an image of a prototype of the LED Painter II-8. The size is the same size as a standard Post-It note pad - 3" x 3". Depending on the overall mechanical dimensions, this device could live on the arm or could live off board with a bundle of wires to the LEDS. We are sourcing associated cables to ago along with this product which will make it a breeze to connect LEDs to.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com

thecyberbob

@MagIO2 Hmmmm... I hadn't thought of it that way (the ring). I knew I was going to have to counter weight it but if I did what you're saying it could eliminate that. Size wise I was aiming to have the LED's fairly tightly packed together. So size was going to be determined through experimentation. I had picked a goal of 64 LED's primarily because I figured that would give a decent enough resolution to any image I want to display (enough pixels so that you could still recognize what you're looking at).

@Timothy That board seems to be small enough for what I had in mind. The only thing I'm curious is how many individual RGB LED channels there is. I see 8 there on the board if that's the case then I'd need 8 of those. I'm not sure if that would be any more practical than me making my own from scratch using 12 TLC's on either 1 large board or 3 smaller ones each controlling a separate colour channel.

thecyberbob

From what everyone has said it sounds like the Propeller is definitely the chip I want to use to control my project though. Am I correct in my assumption or have I missed something?

MagIO2

What other options do you have in mind?

The bottleneck is the SD card. As I said, with 64RGB LEDs you have 400 pixels per rotation. You did not answer the question about the diameter you have in mind for your POV. If the diameter is big, one pixel will maybe more look like a line.
Other small microcontrollers have the same problem or even more, as the SD card read is much slower on many other uC.
If you use a controller with enough RAM to store a high res picture you don't have this limit.

If you are fine with repeating the same image 4 times (128x64x3) you have enough HUB RAM to store the picture there.

You could also split the display into a graphics area and a text area using the building font and a tile driver.
You can work with color palettes to optimize the possible resolution.

You can build a POV with the propeller without a doubt. The question is: are you fine with the theoretical limits.

thecyberbob

Well I've seen the type of POV display I'm planning done with an Arduino before but from my research it seems that the Propeller is the better option.

The diameter shouldn't be exceeding say 6". I can see that I have to give this POV display a bit more thought regarding the image sizes and what not. I suppose there's no way to just read directly from the bmp image on the SD card and push that straight to the TLC's would there? Just to stop having to cache the entire image perhaps?

Thanks for all your help by the way.

MagIO2

Taking the image from SD card and directly output it to the TLCs is exactly what limits the possible size of the image and is exactly what I'm talking about the whole time. You have ~1.5MB/sec transfer-rate with the SD card.

A 400x64x3 byte image needs 76800 bytes. Divide 1.5MB by 76800 and you see that you can load that image 20 times per second - which on the other side means that you can display it 20 times per second. 20 times per second means your POV has to be limited to 20 turns per second.

Do you have a link of the arduino project?

Timothy D. Swieter

Correct, the LPII-8 has eight groups of RGB LED, but the reason I recommend this product is because it is smaller, it can handle larger amounts of power dissipation than the TLC5940 and it is a lot easier to get a larger number of channels because the IC on the LPII-8 is the A6281 which has built in buffers/drivers where as the TLC5940 doesn't and you need to be careful with signal degradation. If all the TLC5940 are on one PCB, this may not be a problem.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com