Rgb led 3x3x10 tower of color (3-d)

Hello Everyone:
I am starting a new stand-alone project using 16F88-16F628A.
Anyone who has already worked on similar or partial components of this project and would like to share please post your ideas. Feedbacks and inputs are welcome.

Description:
A tower of 3x3 RGB (9x3 bits) Base of the tower
10 Stories high
Stand-alone system
Use 16F628A or 16F88 as driving processor
Use 4017 Decade Counter for each stories

Concept:
Be able to individually address each RGB LED to have a specific color. There are 90 RGB LED's (9x10) that need to be addressed at each time. Refresh and do it again. Speed and efficiency is the key with goal of no flickering.
Write different codes to implement different effects and to access individual program.

Jump Start Idea:
Use 9 Outputs of the PIC as drivers
Use 3 Outputs of PIC for Color (RGB) (Multiplexing 27 channels)
Use 2 Outputs of PIC to Drive 4017 (Clock, Reset)-(Third Dimension Multiplexing)
Use RA4 of the PIC (Weak Pull-Up) as program select on the PIC with debounced tactile SW.

You'll need to use latching shift registers, there's no other way to do it without flickering, even then that means you're going to have to shift out 270 bits just to update the entire array once. I don't think there's any practical way to control the brightness of each LED, not with that many in a matrix the software logistics would be nearly impossible and the flicker would be bad, no way around it in a multiplexed array like that. If you absolutly needed to control the brightness the only thing I can think of is a MUCH more complicated array so that each LED is effectively driven by an R2R ladder, you can get a few bits of light control that way but the resistors values would be critical because I don't think apparent brightness is linear with current. Figure a 4 bit R2R DAQ for each of the 270 LED connections, that would require enough shift registers for 1080 discrete connections, that'd be 135 8bit shift registers, the wiring would be a logistics nightmare, I hope you're a neatfreak => Only having to shift out 1080 bits though would allow very fast updating of the entire array. To handle 60 updates per second the shift registers would only need to be clocked at 64.8kbps. If you PWM the entire array you might be able to get some extra brightness control, but it would have to be the entire array and it'd have to be clocked out VERY fast to avoid flicker.

Here is the original idea and schematics.
Thank you Sceadwian for your post. I was thinking along the same line that this might have to be done with shift registers and latches. Clever solution in hardware, more complex in programming the code.
One needs to build a system and test it out. Your hunch of not enough refresh rate to prevent the flickering could be correct.
This is good...keep them coming...

Regards,
Rom

Hi Rom,

With "direct" I/O drive at 1/30th duty cycle (3.33%) you might get about 0.65-ma "average" current per LED so you may have to lower the ambient room lighting a bit to see the display well.

Good luck on your project.

Actually with latching shift registers it's simple in both hardware and software, it just requires a lot of simplicity to do =) Many shift registers and resistors on the hardware side, and bit mapping on the software side to make it human readable. The actual complexity is very low, each unit is quiet elegant, there are just hundreds or more of them. Shift register R2R DACs with carefully chosen resistor values will give you a bright display and at least 16 levels of brightness. If you want fluid dimming you'll need 8 bits minimum (I'd aim for 10) Which is just as readily doable but now you're talking 2700 bits worth of shift registers and resistors. That's for a fully static display that will give you a practical display refresh rate of 370FPS with a serial clock of only 1mhz...

What if we reduce the project to 8 RGB base x 5 level high. Wouldn't that simply the project enough to work with 8-bit latches?
8 RGB LED x 3 color (RGB) x 65 ticks per color x 5 levels = 7800 hz. Would that be doable with a 8Khz processor clock?

If the math is correct could we use 3, 8-bit latches for 8 RGB per level = 15 8-bit latches total to do the work?

Mike: I like a project that is both practical and usable. Such dimm lighting of the LED will not do anyone any good. LOL
Scead: Do you have an example of R2R?
Sounds like what you fine gentlemen are telling me is that neither the PIC is fast enough nor the method is efficient enough to implement such a project. Correct?

R2R Example:
Not sure where the outputs are drawn for this circuit. One output?

I have a 15x7 Display using highbright red LEDs with absolutley no flicker and the LEDs are extremely bright. It would be a simple matter to extend the possibility to 270 LEDs and still get very good brightness.

**broken link removed**

Colin well done. Very similar concept!
I see you only used 7 of 10 outputs of 4017. If you use them all that would only give us 15 x 10 = 150 outputs
How would you change this layout to produce 270?
Cheers

Absolutely not a chance colin. I would actively challenge your claim that there is no flicker in that circuit, I can if you would like guarantee that I could design an experiment which would cause 100% of participants to be able to notice the difference between that circuit and one that is truly static. What is noticeable to the point of distraction is a FAR cry different from the ability of the human eye to detect flicker in a moving object, or when their eyes scan a flickering lightsource.

I've developed a personal technique for detecting it without moving, humming generally works but placing one's chin/skull against a vibrating object (such as a fan) works even better. LED clocks that are multiplexed will appear to shimmer and shake in an odd manner visually almost as if they were floating because of the harmonic difference between the vibration frequency and the multiplex rate. With a quick visual scan such a display on a large scale such as the poster wants to implement would be distracting on nearly a subconscious level if not outright irritating.

If this is for visual appeal, a 100% static display is an absolute requirement.

I have the project and you don't. There is no flicker at all. The scan rate is above perception.
I don't know what will happen when the number of lines are increased but I am not going to start an argument. I am sick of people pulling others down all the time.

My 2 cents would be to use a chip that has some decent Ram to handle whatever patterns you come up with, and a fast internal clock to process. Like the 18f14k22. Also seems like using any of the dozens of led drivers with internal PWM would simplify things a lot. Haven't tried one of these cubes, so don't know how a 33% duty cycle works?

Unroll your 3x3x10 rgb cube and you have 30 columns and 3 rows by 3 colors. Two 16bit led sinking drivers (x3), with PWM control, would handle the columns. 3 gpio pins (x3) to control the medium sized sourcing transistors for the rows.

To keep the pin count down on the micro device use a hardware I2C bus for the drivers, with the only problem being the amount of resisters (90) to control the column current. Pin count would be (2) for the I2C bus, (9) for the row drivers, and (1) for the menu button.

Lot less resistors (6 total) used on the SPI type sinking 16 bit led drivers, but need four pins for each color, so need a 28 pin micro to run the show. Its all about trade offs.

My 2 cents would be to use a chip that has some decent Ram to handle whatever patterns you come up with, and a fast internal clock to process.

Click to expand...

1. The program takes up very litle space.
2. We have a delay routine to display the LEDs, so you have absolutley no idea what you are talking about.

A few different companies make chips especially for driving multiplexed displays. I expect if you look you will find one you can drive from the pic that will do most if not all that you want to do with little fuss and muss.

I forget which companies make them but projects that drive large LED matrices sometimes use them.

colin55 said:

My 2 cents would be to use a chip that has some decent Ram to handle whatever patterns you come up with, and a fast internal clock to process.

Click to expand...

1. The program takes up very litle space.
2. We have a delay routine to display the LEDs, so you have absolutley no idea what you are talking about.

Click to expand...

Who are you addressing this to and what is the context?

colin55 said:

1. The program takes up very litle space.
2. We have a delay routine to display the LEDs, so you have absolutley no idea what you are talking about.

Click to expand...

Getting a little testy aren't we......Not talking about the program space. The implication being 8 bit PWM requires 270 bytes for a buffer array (i.e. Ram) to load a pattern on a static display. That's how a bitmap image would be displayed on a glcd. Call up a data table, read it into a buffer array, spit it out to the bus, that's how I would do it. Don't see how a cube is any different.

How many soft PWM's are trying to be accomplished at the same time? They make dedicated led drivers with inbuilt PWM for a reason. Look at **broken link removed**, and what do we see?. If you are only interested in 7 colors (270 bits, not bytes), then yes I'm all wet, but that's not what the initial post said.

If you've already done the rgb 3x3x10 software, my mistake, then please share.

EDIT: OK there seems to be some confusion here between Colin55 and the OP Chipwizard. My original post #13 was to Chipwizard. But because it followed Colin55's post #12, he thought it was for him. It was in no way meant to disparage his design, didn't really look at it.

My mistake in turn to accidentally think that Colin55 was the OP Chipwizard when writing reply in post #17, as only the 3x3x10 cube is discussed, my BAD.

I have modified the schematics to accomodate the driving circuits for all levels and not just a single row of RGB LED's.
I have completed multiplexing 3 x 9 and 3 x 12 RGB Circuits and did the code for them as well.
Now I have to build up on that to address the levels at the same time.

I read the feedbacks and took into consideration the duty cycle of each individual RGB. Although the source code may not require all 90 RGB LEDs to be turned on at once, but I would like us to complete this project as originally specified. There are many ways around lower duty cycle since we are driving the ports with CMOS-Transistors. The source voltage to the driving transistors can be increased for one. There are many shortcuts and tricks that can be played in the software itself to compensate for possible dimming of the LED's when multiplexed in such scale.
Next step for me is to build a board and actually test the limitations of hardware and software. I will post board layout, and hex as we go.

Please continue with posting and writing feedbacks.
Regards,
Rom

Wow I step away from the forum one day and you guys are fighting like cats and dogs.
Anyone that has a suggestion put it in a circuit diagram and post it. If we can not work together then no sense of continuing with this thread.

Hi chipwiz',

What are your goals for the new design? Have you "worked the numbers"? What is your target "average" current per LED with this 1/30th duty cycle design?

Regards, Mike