Hello - I'm working on a project that involves an arduino controlling 54 blinkm's spread out over about 50 feet. I'm wondering if anyone has tips of I2C range expanders, as the I2C bus only goes something like 9 feet before there is too much noise. Or any tips, really. I've only ever run up to 9 blinkm's off of one arduino, and the scope of my new art installation is really going to test my technical skills. Thanks!
You can look into active pullups, or simply stronger pullups; basically you need a device that can drive the cable harder than the typical I2C methods. There's the P82B715 I2C extender, but you'd need two for every device.
To shamelessly hawk my own wares, your application sounds almost ideal for a string of ShiftBrite RGB modules. They buffer all the signals before passing them to the next device in a chain, so that eliminates the problem with I2C. And in quantities over fifty, it's only $3.84 per device. An earlier customer has even made a ShiftBrite Arduino library. I even just put a bunch of 11.5" cables in the store this week, so you can plug it all together in a few minutes.
Of course there may be downsides. The ShiftBrite module only displays the color you have told it to display; it won't record and play back color sequences, or automatically fade between colors. You would have to handle any fading on the Arduino. It's not incredibly difficult though. See example below:
Anyway, if you have your heart set on BlinkM's, they're a great product and very easy to use. Some kind of amplification or active pullup system should help the I2C signal stretch that far. And remember, if you slow the I2C signal way down (by writing your own I2C implementation on the Arduino), you can transmit much further.
I looked at the P82B715, and yeah, that seems like too much.
Your ShiftBrite modules look like my godsend. I don't see a data sheet, and I've never used a serial interface. In fact, my arduino/tech experience is fairly limited - I'm a programmer, but I've never done hardware until my recent forays into arduino/led land. What more can you tell me about the ShiftBrites, or tech tip... etc?
What about the brightness / viewing angle? I'm building twenty seven 1.5' x 1' light boxes with semi-opaque plexiglass, and I'm trying to make sure the light levels in each box are uniform and bright. I've done this before with blinkms; I aimed em downwards into a white box with curved sides. I think blinkms are at 8000mcd, 140 degree view angle, how about the ShiftBrite?
I'm glad I haven't placed the hardware orders yet. (:
The communication method is basically the same as the 74HC595 Arduino tutorials, except the ShiftBrite is a 32-bit register. The ShiftBrite library really takes care of everything, all you have to do is run the command to set a color. The data stream passes through all ShiftBrites; power, ground, and four communication lines go into one side of the module, are buffered, and passed out the other side to the next ShiftBrite. Because of this, in order to change the color of one ShiftBrite, you have to write the desired colors to all of them; you write the entire array at the same time.
Example: you want the closest ShiftBrite to be red, and the farthest ShiftBrite to be green. You send the command for green first, then the command for red. The command for red pushes the command to the next device in the chain. It might sound complicated if you're not familiar with shift registers...if you're more familiar with programming, consider it a stack, or big FIFO.
The RGB LED I'm using is the same as BlinkM's LED; "superflux" style, 140 degree, 8000mcd, Chinese.
To get colors to diffuse better without reducing brightness much, try some of 3M's glass frosting spray directly on the surface of the LED.
How would this handle pulse width modulation? I like the fades.. possibly I write a program that loads animations, and then sends the arduino data per frame, which the arduino PWMs for the ShiftBrites.
This, by the way, is being laid out in a grid pattern of 3 panels tall by 9 panels wide.
Ok, I found your blog and found this: ShiftBrite RGB LED Module | macetech.com plus the datasheet for the A6281. I think ShiftBrite is exactly what I need.
Also, what about power for these? Obviously they need power independent of the arduino, so how should I do that?
I'll end up having a good number of questions more about this, but for now I'm off to do some research. My arduino knowledge is limited to some basic projects I've done involving sensors and blinkms.
Thanks! I really appreciate your help. This is going to be part of a major installation in Portland OR and I'll upload/send you some vids/pics when I get it built.
Yes, the ShiftBrites do handle 10-bit PWM for each color of each LED. The Arduino has to control the fades in that you calculate how bright each LED should be at a given time, send the command to the ShiftBrite, and the ShiftBrite will maintain that color until you are ready to send a new command.
I hope that two LEDs will be bright enough. I have just tested ShiftBrites with 18 LEDs per color channel, on a 50cm LED bar. This could be an option later if you need more brightness, I'll be producing a ShiftBrite with screw terminals to hook up your own LEDs.
Regarding power: you just find a power supply, 5.5 or 5.7 volts seem to work well, but you should be fine up to 9 volts. I just put 2 amp power supplies on the store, you could split the power wire halfway through the chain and power each half independently. Or find a larger supply. HSC Electronics has a good 5.7 volt supply with many more amps than you'd need for your current installation.
What are the data xfer limits on this communication method? For example, say I treat each ShiftBrite as a pixel, with 100 pixels, and I want a frame rate of 20fps. Is this possible? So I would be shifting out alot of data per iteration, 20 iterations per second.
What about the arduino's data storage? How much code can I upload into it... if the majority of the code is just arrays of ShiftBrite colors? Basically each array would be like an old school sprite. I'm thinking that I would write a few different fade routines, and then I would call each sprite (with fades in between) to create moving sprites across this 2D ShiftBrite matrix.
I'm not sure if this is within the Arduino's capabilities, although I imagine it is. It sure has been a long time since my days as an asm graphics programmer (i used to have high school dreams of the demoscene), but it seems that with it's clock speed I should be able to manage.
Sorry for such newbie questions. Thanks once again.
That would be a 64KHz shift register frequency...the ShiftBrites can handle up to 5MHz. So with the Arduino you'd probably do more like 1MHz (I never got around to measuring the shiftOut clock speed) which leaves plenty of time to do other things, like calculate the next fade values.
If you actually stored the color sequences in program flash (investigate the PROGMEM directive), you wouldn't run into any RAM constraints. Say you had two sets of 100 RGB triplets. If you wanted to fade between them, you'd start a counter and calculate a new RGB value realtime, something like R = (oldR*(16-count) + newR*(count))/16. Then immediately shift it out and go to the next triplet. If you wanted to store entire arrays in memory, it's just a matter of calculation. You could store one entire array of 100 triplets as integers, or sacrifice resolution and get two arrays of 100 triplets as bytes.
If you're putting two ShiftBrites in each box, you could save memory by simply shifting out the same values twice, assuming you wanted them to have the same color at all times.