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'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.


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

...to...

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


I then wanted to try to max out the brightness of all of the SBs. I changed...

image[i][1] = 100; //Set new to max

...to...

image[i][0] = 1023; //Set new to max
image[i][1] = 1023; //Set new to max
image[i][2] = 1023; //Set new to max


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.

Thanks!

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?

for use with ATtiny devices:

#include
#include

#define bit_get(p,m) ((p) & (m))
#define bit_set(p,m) ((p) |= (m))
#define bit_clear(p,m) ((p) &= ~(m))
#define bit_flip(p,m) ((p) ^= (m))
#define bit_write(c,p,m) (c ? bit_set(p,m) : bit_clear(p,m))
#define BIT(x) (0x01 << (x))
#define LONGBIT(x) ((unsigned long)0x00000001 << (x))
#define NOP asm("nop")

#define E_S bit_set(PORTA,BIT(0));
#define E_C bit_clear(PORTA,BIT(0)); //OE is active low, this turns lights on

#define L_S bit_set(PORTA,BIT(1));
#define L_C bit_clear(PORTA,BIT(1));

#define LED_OFF bit_clear(PORTA,BIT(7));
#define LED_ON bit_set(PORTA,BIT(7));

#define shift USICR|=(1<24) & 0xff);
shft8bit((packet>>16) & 0xff);
shft8bit((packet>>8) & 0xff);
shft8bit((packet>>0) & 0xff);
L_S;
_delay_us(40);
L_C;
}

void LED_setup(void)
{
shft8bit(0b11111111);
shft8bit(0b11111111);
shft8bit(0b11111111);
shft8bit(0b00111111);
L_S;
_delay_us(40);
L_C;
}

void Blue(void)
{
// blue
shft8bit(0b10111111);
shft8bit(0b11110000);
shft8bit(0b00000000);
shft8bit(0b00000000);
L_S;
_delay_us(40);
L_C;
}

void Red(void)
{
// red
shft8bit(0b10000000);
shft8bit(0b00001111);
shft8bit(0b11111100);
shft8bit(0b00000000);
L_S;
_delay_us(40);
L_C;
}

void Green(void)
{
// green
shft8bit(0b10000000);
shft8bit(0b00000000);
shft8bit(0b00000011);
shft8bit(0b11111111);
L_S;
_delay_us(40);
L_C;
}

void Clear(void)
{
// green
shft8bit(0b10000000);
shft8bit(0b00000000);
shft8bit(0b00000000);
shft8bit(0b00000000);
L_S;
_delay_us(40);
L_C;
}

void Delay(void)
{
_delay_ms(40);
}

int main (void)
{
E_S;
Delay();
Port_setup();
LED_setup();
Clear();
Clear();
E_C;
LED_ON;
for(;;)
{
int y=0;
for(int i=1023;i>0;i--)
{
y++;
colors(i,y,0);
Delay();
}
y=0;
for(int i=1023;i>0;i--)
{
y++;
colors(0,i,y);
Delay();
}
y=0;
for(int i=1023;i>0;i--)
{
y++;
colors(y,0,i);
Delay();
}
}
}

They are 0.1" headers....

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.

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.

I've used 100 for blue and 110 for green, in order to get warmer colors.

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.

Sample code was posted here: macetech.com/blog/node/54

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.

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 :)

Wavelength = Resultant RGB Color

It would be hard to verify a direct translation
without a spectroscope I would think. If you had one, you could create a conversion table.

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'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.