Buy Products

Distributors

Categories

Project: ShiftBrite

ShiftBrite is a simple device I am designing and producing. It allows easy control of a bright RGB LED. The interface is a straightforward clocked serial data line and a latch input. All signals are buffered and passed through for good performance over long cables and daisy chaining many devices. Many ShiftBrite devices can be controlled from any type of controller that supports clocked serial data output, which is practically all microcontrollers and even PC parallel port or FTDI bitbang adapters.

The above images are renders of the revision 1 design. These were created by exporting PCB images from Cadsoft Eagle, and using the images as textures in a Sketchup model.

The controller IC is an A6281 from Allegro. This actually does all the necessary work to control three LED channels. It receives clocked serial data, generates regulated power for its internal logic, performs a 10-bit PWM cycle for each channel, provides current control up to 150ma per channel, and allows dot correction for improving the match between LEDs used together. It buffers the input signals and passes them straight through to the other side of the package. The A6281 is available in a 16-pad 3mm by 3mm package with thermal pad.

LEDs are a bright common-anode RGB part purchased directly from China on eBay. The seller is either TopBright or Shop4LEDs, I believe they are the same company. In large quantities, the pricing is very reasonable; in fact, my Chinese contacts were having difficulty sourcing similar LEDs anywhere near the same prices.

I am having the circuit board produced by OurPCB. They are also sourcing some of the parts and will assemble the complete devices. I won't post the exact pricing here, but if you have an idea for a device and need it produced, try getting a quote from OurPCB. You will likely be impressed at how low the barrier to entry is for mass-producing custom electronics products.

After I have verified the final product, I may be offering these devices for sale. I will most likely be able to price these in the $5.00 range, with discounts for multiple pieces.

Additional Information

I ordered samples of the A6281 from Allegro, and wanted to test the chips to make sure what I was reading in the datasheet matched reality. I decided to dead-bug wire the chip to a proto board for testing. The images below show some of this process and the results. This method did work just fine, I was able to successfully control a set of LEDs.

Prototypes

The circuit boards for the prototypes finally arrived, and I assembled some ShiftBrites. The common-anode LEDs from TopBright, I discovered, have an incorrect wiring diagram. The common anode lead is actually to the right of the notch, not below it. Fortunately this only means rotating the LED 180 degrees. The last photo below shows a second ShiftBrite chained to the previous one on a breadboard.

Sounds quite much like BlinkM (http://thingm.com/products/blinkm). What is the difference between them? Is there anything that Shiftbrite won't be able to do that BlinkM can or the oposite? A big advantage with your Shftbrite seem to be the price; the BlinkM cost 12.95 $ each.

The first main difference is that the ShiftBrite uses an inexpensive chip that doesn't require any flash programming during assembly. The BlinkM uses a microcontroller that probably doesn't cost more than $1 or $2 more, but it does have to be programmed before shipping to the customer. These two factors make it possible to get a very low price on completed devices, though I have no idea what that raw cost is for the BlinkM.

The second difference is that an array of ShiftBrites is a series of latched shift registers, rather than BlinkM which is I2C and can be thought of as a star diagram. Since the ShiftBrites are in series, the identity of an LED is defined by its position on the string. The BlinkM requires you to program an address into the LED before it can be uniquely addressed. The BlinkM allows you to send a command to one LED at a time, but the ShiftBrite requires you to command every LED in a string even if you only want to change one. Fortunately the ShiftBrite data clock can be several megahertz, so commanding LEDs should be at least as fast as the BlinkM 100KHz I2C bus. The microcontroller programming require for commanding a ShiftBrite is very simple in comparison to the BlinkM; the user only needs a simple serial clocked shift register and latch pin, and does not need to implement the I2C protocol.

The third main difference is the scripting software and standalone mode of the BlinkM, which don't exist on the ShiftBrite. Typically, someone using a ShiftBrite will get the most value if they want to use three or more on a string, and need to fully control them from their own microcontroller. If you only need one LED and want standalone scripted actions, the BlinkM is more compact and economical than taking a ShiftBrite and adding a dedicated microcontroller. However, this will not be the case in the second version of the ShiftBrite, which will be powering LED currents far in excess of the microcontroller's I/O port maximum.

It sounds like that might work as a solution for several applications. I am looking at the robotics aspect and would like to control an RGB led for basic color mixing/brightness from a servo pulse train acting like a virtual servo. This way it would be easy to work with and program. Would this be possible? I know it is not possible with the BlinkM, although they may offer it in a new version.

The BlinkM would most likely be a better choice. Mainly because it does use a microcontroller, and you could create custom firmware and reprogram that controller to mix colors based on the pulse-width servo input. The BlinkM and the ShiftBrite won't work with your application out of the box, but the BlinkM could be reprogrammed to do so. You'd need to learn firmware development for the AVR microcontroller.

Greetings! While I simply do not have the vocabulary to understand
very much about your device, I did gather that it can control multiple LEDs. I am wondering if it could be use for a battery operated light system for our Dancing Christmas Tree puppet costumes and 18 foot tall Giant Parade Puppets? Video at http://www.youtube.com/stiltpro

I think it's definitely possible, but if many lights are needed the cost could rise pretty fast compared to something like a string of LED christmas lights. Maybe a mix of normal LED strings for fill, and some ShiftBrite element in locations you need programmable patterns and color mixes.

I think it's definitely possible, but if many lights are needed the cost could rise pretty fast compared to something like a string of LED christmas lights. Maybe a mix of normal LED strings for fill, and some ShiftBrite element in locations you need programmable patterns and color mixes.

I hadn't planned on doing international shipping right away. Mostly because it's more of a pain than domestic shipping, which I can set up in a couple minutes then print a label. I'd have to worry about customs forms, long shipping delays, etc. Also, these devices are not RoHS or CE marked which might pose a problem for European markets.

However, in small quantities I am willing to ship to some European customers. If there's enough overseas demand I will switch to an RoHS process and do what I can to streamline international shipping.

The LEDs are only 20ma per channel. The leads are designed to stand the LED off the board by a few mm, air cooling seems to work fine. The A6281 definitely needs heat sinking, I have the thermal pad connected to a large ground plane and that seems to do the trick. When the thermal pad is not connected, the A6281 hits overtemp and shuts off one of the LEDs. It automatically turns back on when the heat issue is resolved...no need to worry about burning these out!

Can you clarify what pins on the LED are what? Referring to the picture of the LED above and your comments, I think what is identified as pin 2 (to the right of the notched corner) is the common anode. Which pin is which color?

I would like to see a spec sheet and some example programs, is this coming? When? I was not able to find any on the site to download. I got the allegro doc but it would be nice to see some actual interfacing for an Arduino.

They will draw about 60mA per device when running at full power on all channels. USB maxes out at 500mA per port, so don't exceed that. The ShiftBrites have an internal regulator that wants over 5.5 volts, but they can run on USB 5V if you bridge the solder jumper provided on the PCB for that purpose.

The maximum before damaging the chip is 17 volts, but it must regulate the voltage down to about 2-3 volts on each LED. This means that it will dissipate heat until it reaches an overtemperature limit, and shuts down the overheating channel. On these boards, the voltage I've had the best results with is about 7.5; with voltages close to 5.5 you will want to have a surplus of amperage capacity to smooth out any power fluctuations.

I was wondering how to control the leds individually in terms of modifying the Arduino code. I see the 1st shiftbrite pass the same data to the one next to it, how do I tell them do be different colors at the same time (one red, one green)?

Since the ShiftBrites are in a chain, it's necessary to rewrite all the ShiftBrites when one is changed. So, typically you would make an array[num_shiftbrites,3]. Your output routine just indexes through the whole array, shifts out the values that it finds. Maybe cue that on a timer so it happens automatically. To change the color of one LED, now all you have to do is write new values into the appropriate location in the array.

The low level flicker is caused by the PWM. The off time becomes to great to trick the eye into thinking that it is actually a solid light so you actually see the modulation. You may even notice this effect in your peripheral vision as you glance across the led at higher levels.

I see that both of you are not writing to the control register; you should at least write to it once, since leaving it at zero means the LEDs will be driven with 30% maximum current. And I highly recommend writing to it every time you refresh the PWM registers, or maybe every 10 times. If you ever get interference on the lines, you might accidentally set the control register to an unknown value. So refresh it every so often, to make sure it's in the right state.

I actually have been testing this Arduino code and noticed a flicker too. Mainly, it seems to happen when fading quickly between various colors. I have a theory which I think explains this really well. The A6281 generates its own internal PWM clock, which it uses to vary the intensity of the color. The clock default is 800KHz, which divided by 1024 is about 780 LED updates per second. See where I'm going? The oscillators in each ShiftBrite are free-running, there's no way to know at which point in a PWM cycle you will request a change in brightness. So if you're updating very rapidly, you'll end up jumping into a PWM cycle at random times, resulting in a slight brightness change.

There's two ways to deal with this. First, only update the display when necessary; the longer you wait between updates, the more full PWM cycles will occur and the closer the average brightness of the LED will be to the desired level. Second, the A6281 has a setting to use the data clock as an external PWM source. If your style was really getting cramped by the occasional flicker during fast fades, you could generate your own PWM clocks and sync your color changes to that, always ensuring you have complete PWM cycles.

Hello,
I noticed flicker with another code (for Microchip PIC).
I don't agree with you : " you'll end up jumping into a PWM cycle at random times "
but in the A6281 datasheet : " Latching new data into the brightness registers will not reset the PWM counter. "

Hello,
I noticed flicker with another code (for Microchip PIC).
I don't agree with you : " you'll end up jumping into a PWM cycle at random times "
but in the A6281 datasheet : " Latching new data into the brightness registers will not reset the PWM counter. "

Did somebody find a solution to reduce flickers ?

thank you

I've tested using three Shiftbrites with the sample code on an Arduino and also the bit bang route on a parallel port.
Always flickers on the arduino (slow or fast fading) and never flickers using the bit bang parallel interface.
Pulsing the enable does not seem to help at all.
Cannot seem to get it stable on the arduino.
Any ideas???

I pulse the Enable pin *during* the latch pulse. I know several people using ShiftBrites who experienced flickering during fade-outs, and this solved the issue. Perhaps you are using the Arduino ShiftBrite library? That has known problems with flickering when using more than one LED. It was contributed by a customer and it is a good introduction to the ShiftBrite, but it does need some rewriting.

Did not help. Thought it might have something to do with a Serial.read() used to input register values on the fly but I took that out and created simple loops to do the fades also. It made no difference. My goal was to simultaneously fade in/out a chain of at least 2 SBs between about 9 or 10 set color mixes, with a different color mix on each SB based on serial input. The serial input would provide two fresh sets of RGB register values on each read to control the color mix and fades.

I actually have been testing this Arduino code and noticed a flicker too. Mainly, it seems to happen when fading quickly between various colors. I have a theory which I think explains this really well. The A6281 generates its own internal PWM clock, which it uses to vary the intensity of the color. The clock default is 800KHz, which divided by 1024 is about 780 LED updates per second. See where I'm going? The oscillators in each ShiftBrite are free-running, there's no way to know at which point in a PWM cycle you will request a change in brightness. So if you're updating very rapidly, you'll end up jumping into a PWM cycle at random times, resulting in a slight brightness change.

There's two ways to deal with this. First, only update the display when necessary; the longer you wait between updates, the more full PWM cycles will occur and the closer the average brightness of the LED will be to the desired level. Second, the A6281 has a setting to use the data clock as an external PWM source. If your style was really getting cramped by the occasional flicker during fast fades, you could generate your own PWM clocks and sync your color changes to that, always ensuring you have complete PWM cycles.

A better way to deal with this is to toggle the output enable pin when you toggle the latch pin to set your new values. This will sync up the PWM and get rid of the glitching.

I've been playing with this code. I am using a chain of 12 SBs. I've modified to support 12...
int chainLength = 4; //Number of ShiftBrites in chain
int image[4][3]; //R,G,B for each ShiftBrite in the chain, first element is No. of SB's in chain

...to...
#define chainLength 12 //Number of ShiftBrites in chain
int image[chainLength ][3]; //R,G,B for each ShiftBrite in the chain, first element is No. of SB's in chain

I found that with a 1 millisecond delay for the latchpin I was getting some flickering on some of the SBs. I modified this to use delayMicroseconds() instead with a value of 1500 microseconds. This helped remove the flickering.

This seems to cause flickering in some SBs again. I adjusted the latch timing again and was able to remove the flickering. This tells me that there should be some sort of equation for determining the correct latch timing. It would seem to be based on how many SBs in the chain, total brightness (r+g+b), the rate of expected brightness change (in this case how fast the chase is running), maybe how many SBs are currently lit, maybe distance between individual SBs, etc.

Does anyone have any insight in to how this might work and/or what this equation might look like? I would very much like to be able to solve this in code so that I can handle many different color combination, brightness levels and timing issues (fades, rapid color changes, etc) on the fly.

Can you give us some more info on controlling these using the parallel port on a computer or a parallax servo controller board. I was thinking of using these as eyes in a talking skull like the one at skulltronix.com using Brookshires VSA Software.

I don't have PC parallel port code, I think someone has done it already; but do you have the EFX-Tek controller boards or anything programmable? They have working ShiftBrite code on the EFX-Tek forums. That would be easiest; have a controller that can understand the MiniSSC protocol, and integrate with VSA perfectly.

Edit: I downloaded the Brookshire VSA demo, figured out how to use it, wrote Arduino code to understand MiniSSC commands, and let it control each channel of a ShiftBrite like a servo. Works great! I'll add it to the documentation I need to get on the site.

I've got 33 shiftbrites working great so-far. The problem with VSA is that it will only supply 8 bits on a parallel port (using their LPT byte mode). So without another device in between the servo controller and the shiftbrites to decode the servo data (Arduino...) you can't. It would be nice to do it without another device and not have to pay extra and do coding for BlinkMs. I hope the documentation will be here soon.

VSA sorely needs some fresh code and a newer gui to match.
Maybe Garrett can work with the VSA folks (Jon) and get a new driver mode going?

Well, using an Arduino seems like a good solution to me. You can program it from any computer with a USB port, the official board costs $33 with other variants approaching the single digits. Brookshire VSA communicates fine over the onboard USB-serial converter. The code to control ShiftBrites is very easy, and the code to understand the MiniSSC protocol is easier. I could make it understand some of the other protocols, which allow more than 256 levels.

I think it works great...and parallel ports are getting really hard to find these days. The Arduino could also do motion control and activate other parts of your project, too.

Yep, but a parallel port card or USB to parallel converter is a lot cheaper to add than an Arduino with a USB programming interface. If you've already got the servo controller (a Lynxmotion SSC32 has inputs and 32 servo outputs for $40) there's no need for other controls.

The problem is just that VSA is only setup to support DMX lighting controllers for other than just on/off control.

I would love to try some USB interfacing with RGB control. Not sure what VSA is but I'll look it up and try to get the demo to play with. Got to get my Diecimila doing something new, maybe I'll actually learn something..hahaha

I don't have PC parallel port code, I think someone has done it already; but do you have the EFX-Tek controller boards or anything programmable? They have working ShiftBrite code on the EFX-Tek forums. That would be easiest; have a controller that can understand the MiniSSC protocol, and integrate with VSA perfectly.

Edit: I downloaded the Brookshire VSA demo, figured out how to use it, wrote Arduino code to understand MiniSSC commands, and let it control each channel of a ShiftBrite like a servo. Works great! I'll add it to the documentation I need to get on the site.

I chained 8 units together and as a quick test I used a couple of 555 timer IC's to generate some pulses. Of course the colors were haphazard however I was able to see the hues propagate down the line. I want to develop a pic based driver as a basic demo unit but I'm not the best or fastest coder and It would probably end up as another unfinished project on the shelf. So there it is. If any young PIC basic programming gurus out there want to tackle this and post some code I'm sure a lot of us would appreciate it.

Do you have any details regarding the controller you plan to use? If your heart isn't set on a PIC, I'd recommend an AVR. Or possibly an Arduino, which is an easy way to get into AVRs. The official USB Arduino Diecimila is only about $35, and there are third-party cheaper versions. Freeduino is $26, some soldering required. I haven't used PICs since the 16F84, but I believe if you can find some code that is designed to work with a shift register, you could easily adapt it.

This was written for the Basic Stamp but is very close to the PIC Basic code. This is a good place for PIC users to start since the code is short and clear. The code does uses the word ENABLE as a label which needs to be changed since it is a command word in PIC Basic.
The key to driving the shiftbrites can be found in studying the PIC basic command SHIFTOUT. It will manage all of the Data, timing and variable bit length requirements. You can even embed the two mode setting bits(31-32)to keep things synced. It makes a complicated task very intuitive and hassle free.

Thanks, I have received my Order and the shiftbrites are shifting brite :)

If you're doing the next batch I'd recommend to omit the pin headers. If you want to integrate the ShiftBrites into a bigger project they tend to be a hurdle, and desoldering them is way more work than attaching them if you need them (plus the prescision of their soldering is not that great). It also would make shipping and handling a bit easier I'd think.

Additionally there seems to be solder mask between the two pads of the +5V-Jumper on the bottom - it is quite hard to actually connect them with a blob of solder :)
If this could be avoided it would be a bit easier.

Can one (or two) of these plug directly into an arduino? It seems the power and ground could be taken care of by the pins on either side of the four controlling the shiftbrite. Would it have enough current?
Thanks!

I tried plugging the ShiftBrite directly into the Arduino and using I/O pins to supply power and ground. I found that it would cause the Arduino to reset when all three color LEDs were on at a high level.

I think the current draw is too much for the I/O pins to supply, so I changed to a separate power supply. This seems to work reliably, but...

I have also noticed intermittent problems when setting all three colors to the maximum value (1023) to create white light. This seems to work OK for an hour or so, then the LED starts blinking erratically when set to white. All the other colors work fine, as well as setting two colors to maximum and the third to a lower value. Does anyone have an idea why this might be happening? I don't think it's a defective ShiftBrite, since I tried others and they behave the same.

Yes, I also tried plugging it directly into an Arduino and could only power one color at a time, unless I dropped the current for all channels to 1/3rd. This makes sense since each channel draws 20mA which is near the maximum for the I/O ports. You might be able to get more out of the ShiftBrite by using the jumper on the bottom that bypasses the internal regulator, but probably run the risk of damaging the Arduino.

I'm not exactly certain what's going on with your second issue. This is when the device has been running for more than an hour? I doubt it's a data corruption issue; that's a known effect where any noise on the data lines can set configuration registers to invalid values. The solution is to periodically write the configuration registers. However, your problem seems to be time-related. I would suspect heating of the chip. When you touch the ShiftBrite controller, is it very hot? The chip will keep turning itself off if it gets too warm. This can happen if the power supply voltage is high; any excess voltage needs to be dumped as heat by the chip regulator before it goes to the LED channels. I am using 5.5V supplies mainly, what is yours?

MTA-100 connectors for 22-26 gauge wire should be adequate, I don't recommend 28 gauge connectors, I find them unreliable. However I have a bunch of premade cables en route, should be up on the store in a week.

Is there any easy way to change the clock to faster than 800kHz?
Alternatively, is there a way to use a smaller bit-count for the PWM?
I would prefer the PWM full-cycle time to be shorter (now it is 1.28ms I think).
Also, how fast can the LED change? There must be some fundamental limit on the
LED response time.

I have not actually tried this, but you can select an external PWM clock source and send up to 5MHz along the CLK line. Of course, you have to generate this frequency continuously if you want flicker-free operation, and the data you send needs to be synchronized with this clock. You can also use the OE line to reset the PWM counter; if you reset the counter at 256 clocks, you now have 8 bit PWM, for example. Obviously this is much more processor intensive than relying on the internal PWM clock generator.

Another quick question: has anyone found any values for the color calibration
that work better than full current to each channel? Now, I am using 127 for
each, just like the code above, but it seems like producing yellow or even
orange is difficult.

Hello
I have a new mustang with a Shelby style hood (knight rider). Thus i Would like to make my self a Kitt saner light... But The new KITT light is different from the original. The new kit basically has 2 light bars, one on the left and one on the right.
----
The Light starts form center moving out, lighting both bars to where all leds are on. Then the bars would fad out starting form the center. Next the bars would light from the outer ends of the bar going to center until the bars are completely on and once again the bar would fad out this time form the end to the center….. and so on ----

I Think i would be able to do it with 40 LEDs. 20 per each side. This is not a set number. I was have just received my Arduino Diemilanove yesterday. After some work on the bead board i have the look of what i want on a small scale, only 7 led currently. I was looking at the BlinkM's when i came across these. I like the price of these a lot better then the BlinkM's.

What would be my better option these or the BlinkM. The main reason i like the blinkm is the fact i just run them in a line add 5v and they run the program standalone. I don't understand enough about the how to use the shiftbrites to understand how to wire them to the board and write the program. I plan on it being a blue light so i am not really worried to much about a lot of color changing, just fading.

I don't think the self-running-program feature of the BlinkM's would help you here. Each BlinkM runs by itself. To get your synchronized fade effect, you would have to program a different profile into each LED, then start them all at the same time. It would be very difficult to get the effect just right.

You could control the BlinkMs individually, but at that point you're doing the same thing the ShiftBrite does, where each LED color setting is controlled by the main controller.

To be honest, if I were doing the same project I would probably not use ShiftBrites, since you only need red. But if you plan to have other color options, ShiftBrites would work well. Otherwise I would look at the TLC5940 or TLC5947 chips to control all the red LEDs.

If you decide to use ShiftBrites, let me know, and I can help you get your code running.

Hello, thanks for the response. I know with the blinkm i would have to program each one individually but i was willing to go that way because of the "BlinkM Sequencer programing software" it looked like i would have less code to deal with. Just more time would be spent getting each light sequenced and timed properly.

I actually plan on having the light be a light blue to match the color of the car. (It will only be for the shows) But I do like the possibility of changing the colors if i ever wanted to. I started reading the data sheets on the 5940 and 5947 and I got over my head pretty quick. My biggest fear is to invest a lot of time and money in to it and never get it up and going but these shitfbrites being 1/2 the cost of the blinkm.... well I am a little more inclined to give it a try. I will get with you after Christmas, i do think i will go the shiftbrite route.

Y'know, some sort of minimal datasheet would be really helpful. Maybe all the necessary information is out there, but it seems to be pretty scattered.

I've just spent several frustrating hours until stumbling across a single blog reference to the jumper which needs to be bridged to enable 5v operation. A single page could cover that information, current requirements, pinouts, physical dimension, etc. Tested, working sample code would be great as well, but I'd settle for the basics.

ShiftBrite is a neat product but I shelved mine months ago, shortly after purchasing, when I couldn't get them to work reliably. I wonder how may others are sitting unused out there...

I'll admit there needs to be a datasheet, however I've been getting feedback from early adopters and trying more things with power supplies and interconnects and timing, and didn't think it was a good idea to release a datasheet until I was absolutely sure of the details. For example, I wouldn't recommend using the 5V jumper right now because I had one customer report that he burned out some ShiftBrites when using that jumper. I have been running some tests and haven't gotten the same result yet, but don't want to widely advertise that jumper until I'm sure.

I have had many customers contact me for help getting their ShiftBrites running, and I'm more than happy to provide any information requested, help them write code for their chosen controller architecture, etc. I prefer to keep it interactive at this point, since I don't have a huge customer base right now (only about 150 different customers) and I want to keep an eye on the areas where most people are having problems.

I have here 10 SB that burn out, 2 of this burn the LEDs the other burn the alegro chip.
The problem is that i don't understand why, i don't use the 5V jumper, i'm waiting reply from Garrett.
in the mean while i'm reverse engineering the SB sheme, maybe i have pointed out a possible issue but i have to investigate better.
Hope to have a quick reply from Garret, i need the SB but i need also reliability

These ShiftBrites were at one point connected to a 9V battery without the ground connected to the Arduino, something that could very well cause incorrect voltage on the logic pins. Some were also run at 12V. I'm working with Alessandro to determine any other possible causes, perhaps find ways to prevent additional failures, and RMA the dead modules.

I just ordered ten of these to play with and connect to an Arduino for control. I want to do the Kitt kind of effect but with the colors changing. Reading everything above, I should run them on a 5.5 to 7.5 volt rail separately supplied and they should all be happy. One question. You mentioned above that you were working on a "newer" version that would supply more current to the LED's (This is from the April 2008 post. I assume these are the ones currently shipping. (Shoulda asked before buying LOL!) Anyway thanks for designing this! I plan on playing with that TI chip that will drive 16 LED's at some point later but the Shiftbrites seem totally cool.

The version currently shipping is the still the first version, I do have some newer versions into the PCB proto house. Got way too busy to make new products until now. However these should work fine for a KITT scanner, you're not the only one :)

Thanks for the rapid response. Look forward to playing with these. I built my own "Mega-Brite" LOL it has three 5watt luxeons for Red, Green and Blue and I drive it with an arduino that has the PWM pins going to power Mosfets. I need to get a quick Video up on youtuube for it. (I shoudl actually mount it in a case first!http://picasaweb.google.com/ryckebusch/LEDRandomPics#5296310634475381874
and

RGB LEDs contain three elements that each provide a narrow wavelength band centered on red, green, and blue wavelengths. These colors each interact with the sensors in our eyes to appear as a mixed color. The actual wavelength emitted by each LED never changes.

RGB LEDs contain three elements that each provide a narrow wavelength band centered on red, green, and blue wavelengths. These colors each interact with the sensors in our eyes to appear as a mixed color. The actual wavelength emitted by each LED never changes.

I agree for the individual led elements, but as a whole the luminous flux and the wavelength of the elements both affect the mixed color. Temperature and age of the elements can change both.

I was referring to the overall RGB color mix.

I've been playing with a few Shiftbrites and cannot eliminate
the flicker when running just three in a chain on an arduino. Driving me nuts.
Power supply is clean (5.5V 2A) and even tried on 7.2V battery. Yet the same setup works fine off an old bit bang interface, no flicker at all.

Thanks for the reply.
So I have three elements...for example blu is 460 nm, green is 550 nm and red is 630 nm. When I want red the power of the blu and green element is low and the red is high so the result is a red color...is it correct?

i use 1024 a6281 + same number rgb leds for my prototype
I Experienced problem with EMI.
i can play movie until first switch in house i used, then whole matrix gone
totaly messed until power off and power on +pole on on whole matrix board (onli for a6281 supply not logic)
Now question is, how is possible that this chip can not exit from messed stage with fresh data feed only with re-powering

I've spent quite a bit of time stringing up long chains of shiftbars (160), and in my experience I seem to always run into some kind of glitching/flicker scenario, usually when all LEDs go to full brightness, which makes me wonder if it's power related (I've tried different power supplies, and splicing in power regularly to help voltage drop). Fussing with the current values (going lower) sometimes fixes it, but the longer the chain the harder it is to combat. Mace any suggestions? The behavior of this chip, while on paper is straight forward, in practice has some crazy ju-ju going on....

I'm having the same problem, even with a few chips in a chain. I get white flashes and flickers whenever I try to run all colors at the same time. Fades with only one color work perfectly.

From some comments I've read bit banging seems to work better than SPI, I'm going to try to rewrite my code tonight to see if avoiding SPI makes any difference.

I'm using a breadboarded atmega328p, 9v regulated power supply, cat5e cables for interconnects.

One thing I've noticed that's interesting - the last light in the chain of shiftbrites always flickers like crazy unless I plug in an additional cable to the output pins - even if it isn't connected to anything. I don't understand that at all.

Hey Garret, I was wondering what's the maximum ShiftBrite chain size I can create and how much mA's I need for each one of them?
Working with them in series (chaining) would have any impact on each current necessities?
Also I'd be interested in buying a lot of 50 or so (I may need aprox. 46 for a project of mine) but it will be helpful to have a few extra ones, could you ship them to South America? I MAY need some more in the future, althought I can't grant you that.

I'm wanting to have 135 in series.. will run separate power to the 15 lines of 9 I have for a display over my pool.
If you could tell me that 135 in series are supported, I will purchase and give you videos/pictures :)