I2C-addressable RGB LED Project

[Entropy]

I've been mentioning a desire to do this for a few weeks now, but I now have a prototype up and running.

I'm working on an approach to individually addressable RGB LEDs. There are a couple of similar projects out there:

MPH/JEC's current project - Based on what I have read, depends too much on nodes sourced from an unnamed Asian manufacturer who refuses to even document the protocol used (they had to reverse engineer it!)

MPH/JEC's last project (the pixels) - Each pixel was DMX-aware, this drives cost quite a bit.

Matt Edwards' project at http://doityourselfchristmas.com/for...0250#post80250 - Similar in concept to MPH/JEC's original pixels, but it was AVR-based. Like the original pixels, they were DMX-aware, driving cost up quite a bit. The RS485 receivers I have seen cost nearly as much as my entire parts BOM as it currently stands.

Parts used:
Atmel ATTiny85 AVR - Final design will be a Tiny25.
RGB LED - The unit I currently have is common cathode, final design will be common anode. (My order of 50 units didn't arrive on time, I had to pay $5 for a single unit in a local store today!)
Three current limiting resistors for the LED
One pullup resistor for the Tiny's RST line
Power supply bypass capacitor

The units respond to data sent over I2C. Each unit is sent three bytes at its I2C address - one for each color. I2C means that the nodes do not need any additional interface hardware. (Somewhat similar to MPH/JEC's Asian nodes)

I currently have it prototyped on a breadboard. I only have a single one at the moment, additional units probably won't happen until after the new year (no more RGB LEDs).

Right now I'm driving the I2C bus with a PJRC Teensy loaded with the Micropendous Serial-to-USB firmware:
http://www.pjrc.com/teensy/
http://code.google.com/p/micropendou...tualSerial_I2C

Eventual goal would be a DMX-to-I2C converter.

I2C only allows 127 nodes per chain, however since a DMX universe could only control around 170-180 nodes (brain is fried after working this all da...), this isn't too much of a limitation.

The firmware is GPL licensed. See the README and comments for known issues with the code. Known issues with the hardware are not documented in this file, but I have mentioned some in subsequent posts. It has been tested on an ATTiny85, but should work without any modifications other than the Makefile and the avrdude programming command in an ATTiny25.

Included is a small Python test script for those who have a USB AVR to play with.

Update: Demo of two nodes on breadboard uploaded to YouTube, see http://doityourselfchristmas.com/for...9&postcount=46

Firmware update released. It is not attached here, all future firmware updates will be in my github repository for this project at http://github.com/Entropy512/I2C_RGB

[David_AVD]

Sounds interesting. What's the expected cable distance limitation using I2C ?

[Entropy]

Oh, and I realize there are some challenges yet to be solved:
1) How to set the address of each node - It's not based on physical location in a string. I'm going to move the address from a #define to EEPROM soon, however probably not before I post the first release of the source.
2) Final physical packaging. The cheapest approach (see the Asian nodes - solder wires to boards and then encapsulate the whole shebang) is not the most maintainable, especially with issue 1) above. However, if the maintainability hit can be tolerated, there are plenty of ways to goop up a circuit board. The stuff my family is using to repair their shoes seems like a good candidate and it's cheap - however it may prove to be too stiff when cured.

[Entropy]

Sounds interesting. What's the expected cable distance limitation using I2C ?

I need to look into that. Keep in mind that power injection proved to be a pretty big issue for MPH/JEC's node strands and not the bus length. The idea here is for pretty densely packed node strands anyway - isolated nodes are better suited to DMX and the like.

[qpm01@yahoo.com]

What do you guess the price per node will be in the quantities we would likely use for holiday displays?

jmk

[mrpackethead]

Hi entropy, great to see another project developing..

Id suggest that you take a pretty serious look at the bus length of i2c and your required datarates, before to track too much further. Not wanting to knock your project, I've just been down this path recently...

A really good paper on the topic

http://www.philipslogic.com/support/.../pdf/an255.pdf

[Entropy]

Thanks for the extra info. I did some rough calculations so far:
Each node currently needs 32 bits of data transferred to it - 4 bytes are Addresss+R/W, Red, Green, Blue. Let's assume an extra byte of overhead, so 40 bits (clock cycles) per node update. (There may be more overhead than this - my Bus Pirate hasn't arrived yet for me to look at what's going on).

This gives 2500 node updates per second. So from here, it depends on what refresh rates you need:
For 15 Hz refresh rate, you can drive 166 nodes. There aren't this many addresses though!
For 125 nodes (I would prefer to reserve a few addresses for special functions), it would be 20 Hz. This is pretty respectable.

On page 25 of the document you linked, it does mention that 100 kHz buses have been run up to 100 feet. If you're running a node-to-node spacing greater than a foot, there are probably better solutions than this. I have in mind densely packed applications here.

There ARE still a few gotchas I need to look into - The USI implementation in the Tinys lacks the input noise filtering normally present in I2C devices - how much of a difference it makes in this specific application is unknown.

Also I need to find out whether the drive capabilities of the TWI implementation in higher end AVRs (Like the Mega168 or the Mega32U4 I'm using currently) are higher than typical for I2C devices.

As to node pricing, VERY rough estimate assuming quantities of 100:
ATTiny25-20SU (SOIC version, 20 MHz) - $1.03 from Mouser
Diffused lens common anode LED - $0.45 for 10mm from EMSL
0805 SMD resistors - $0.01 each (note, assumed quantities of 1000 for this one), need 4, so $0.04 per node in 3 different values
0.1 uF power supply bypass capacitor, 0805 SMD - $0.061

So for parts (minus board and connectors - these still need to be looked at!) - $1.58

That leaves $0.42 for boards and potting if the target is <$2/node

Biggest issue is maintainability - cost per node goes up if you add the connectors needed to ICSP the AVR after it has been encapsulated.

If you don't mind a non-waterproof solution where multiple nodes are housed in a large enclosure, machine pin headers aren't too expensive.

[Entropy]

Also, I'm looking into whether an RGB565 format with a gamma curve applied might work well. Without a gamma curve applied it won't provide enough dimming levels (I saw your comment about that issue with your nodes.), but this would allow the bus to be clocked down further while maintaining refresh rates.

I used to have some interesting sigma-delta modulation code that let me get quite high dimming resolution, with the limitation that minimum brightness had to be higher than a "1" value or flicker would ensue. Unfortunately, I think what happened is that I changed usernames on the system I developed that on, and didn't back up the old username's directory two years later, thinking I had only used one username on that machine at all times. End result is my sigma-delta dimming code is gone

Another thing I am thinking of is possibly instead of 1-bit SDM like my previous project, combine a sigma-delta modulator with the 8-bit PWM code to extend the resolution to 10+ bits by performing temporal dithering of the 8-bit output. It's really expensive to do 16-bit math inside the main PWM ISR, but could be easily done outside of the ISR once every 256 firings of the PWM ISR. I just need to figure out a way to ensure that the SDM code occurs only once per 256 cycles of the PWM ISR. The 10-bit dimming would not be directly accessible to an I2C user - the Tiny would apply a gamma or logarithmic curve of some sort.

[P. Short]

Don't ignore mph on the I2C distance/bitrate limitations/tradeoffs...

[Entropy]

Don't ignore mph on the I2C distance/bitrate limitations/tradeoffs...

See my above calculations. 125 nodes should be drivable with a 100 kHz bus at 20 Hz refresh rate.

According to that Philips application note, 100 kHz buses have been driven to 100 feet without any problems in real-world applications. With a node spacing similar to JEC/MPH's strings, a 125 node string would be about 40 feet. Of course, there's the issue of how much the nodes would load up the bus...

RGB565 + a gamma curve would allow for the clock rate to be reduced if need be.

Also, I could have the option of making it "not quite I2C" - specifically making the driver push/pull vs. open collector, since this particular application does not require readback or multi-master. I'd prefer to keep it standard if I can though. I need to read through the datasheets of the AVR USI to see what flexibility I have in this regard. (Edit: Not looking promising there.)