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.

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.

Right here, in about 30 days.

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!

"you might want to consider a heat sink to lengthen the lives of your LEDs"

To get a clue considerer:
How about asking if something was considered before telling someone to considered. And just as expected, the consideration took place long ago. Typical wasteful post.

That LED pinout is a little deceptive. If you look at the top view as if it were a bottom view then I believe the pinout is correct.

Soon.....

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.

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.

Here's the version I came up with, hopefully it will help someone out, though it seems to flicker at low light levels, anyone have an idea why?

int datapin = 9; // DI
int latchpin = 10; // LI
int enablepin = 11; // EI
int clockpin = 12; // CI
#define chainlength 5

int SB_CommandMode[chainlength];
int SB_BlueCommand[chainlength];
int SB_RedCommand[chainlength];
int SB_GreenCommand[chainlength];

void setup() {
pinMode(datapin, OUTPUT);
pinMode(latchpin, OUTPUT);
pinMode(enablepin, OUTPUT);
pinMode(clockpin, OUTPUT);

digitalWrite(latchpin, LOW);
digitalWrite(enablepin, LOW);
/*
SetSB(1,127,127,127,B01);
SetSB(2,127,127,127,B01);
SetSB(3,127,127,127,B01);
SetSB(4,127,127,127,B01);
SetSB(5,127,127,127,B01);
SB_Refresh();
*/

}

void SB_Refresh() {
for(int led=0;led 24);
shiftOut(datapin, clockpin, MSBFIRST, SB_CommandPacket >> 16);
shiftOut(datapin, clockpin, MSBFIRST, SB_CommandPacket >> 8);
shiftOut(datapin, clockpin, MSBFIRST, SB_CommandPacket);

}
delayMicroseconds(1); // adjustment may be necessary depending on chain length
digitalWrite(latchpin,HIGH); // latch data into registers
delayMicroseconds(1); // adjustment may be necessary depending on chain length
digitalWrite(latchpin,LOW);

}

void SetSB(int led, int red, int green, int blue, int mode){
led=led-1;
SB_CommandMode[led]=mode;
SB_BlueCommand[led]=blue;
SB_RedCommand[led]=red;
SB_GreenCommand[led]=green;
}

void loop() {
int i=0;
for(i=0;i<=1023;i=i+2){
SetSB(1,i,0,0,B00);
SetSB(2,0,i,0,B00);
SetSB(3,0,0,i,B00);
SetSB(4,0,i,0,B00);
SetSB(5,i,0,0,B00);
SB_Refresh();
}

for(i=1023;i>=0;i=i-2){
SetSB(1,i,0,0,B00);
SetSB(2,0,i,0,B00);
SetSB(3,0,0,i,B00);
SetSB(4,0,i,0,B00);
SetSB(5,i,0,0,B00);
SB_Refresh();
}
}

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.

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.

Hello Again

I finally sat down and patched together 16 Shiftbrites. I tied them into a PIC chip and found some code to drive them at:

http://www.efx-tek.com/php/smf/index.php?action=printpage;topic=620.0

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.

Homer J

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?