I2C-addressable RGB LED Project [Archive] - Do It Yourself Christmas Forums

Entropy

12-27-2009, 12:40 AM

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/forums/showthread.php?p=80250#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/micropendous/wiki/USBVirtualSerial_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/forums/showpost.php?p=100499&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

12-27-2009, 12:43 AM

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

Entropy

12-27-2009, 12:45 AM

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

12-27-2009, 12:47 AM

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

12-27-2009, 01:26 AM

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

jmk

mrpackethead

12-27-2009, 02:01 AM

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/appnotes/i2c/pdf/an255.pdf

Entropy

12-27-2009, 11:35 AM

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

12-27-2009, 11:40 AM

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

12-27-2009, 01:53 PM

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

Entropy

12-27-2009, 02:18 PM

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

DynamoBen

12-27-2009, 03:01 PM

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

What about CAN bus? This is the same technology they use in cars to speak between ECUs, very good in harsh environments.

"250 kbit/s the cable length should not exceed 250 meters."

Distance Calculation:
Bitrate * Buslength < 50000 kBit m/s

Entropy

12-27-2009, 03:44 PM

What about CAN bus? This is the same technology they use in cars to speak between ECUs, very good in harsh environments.

"250 kbit/s the cable length should not exceed 250 meters."

Distance Calculation:
Bitrate * Buslength < 50000 kBit m/s
I'll look into it, however first impression indicates this would require bumping up to a significantly more expensive node controller chip, and/or adding an external interface IC. At that point you've likely exceeded the "DMX to each node" solution.

hhhhhhhhhhhhhhmmmmmmmmmmmmmmmmmmmm I just had a possible idea...

DMX protocol but with TTL voltage levels might do the trick... Really the problem with the "individually DMX-aware pixels" is that the RS-485 receivers cost nearly as much as the AVR chips. (Edit: oops, forgot the Tiny25/45/85 don't have a UART...)

I'm also considering a "meganode" design that would increase cost by $0.10 per node ($10 per 100) but make the addressing issue easier to solve - In quantities of 250 or more, the ATTiny48 is $1.12 and has much more I/O than the Tiny25. Edit: No UART still though.

Absolute cheapest cost per node would be some of the $0.50 PICs, however, as I've mentioned before:
1) I don't know how to program them
2) Lower clock rate could interfere with software PWM
3) Lack of any hardware acceleration for serial interfaces (the Tiny25/45/85's USI is basic, but at least gives you a shift register with some interrupts) would mean that the control interface would have to be bitbanged in software, likely significantly reducing the maximum data rate or reliability.

P. Short

12-27-2009, 04:59 PM

Another interesting part is the PIC12LF1822/PIC12F1822, which is an 8-pin part costing under $1.00 each in quantity 100. Unlike the $0.50 parts it has a built-in UART and interrupts.

On another note, I have a design for controlling an RGB LED using the $0.50 PIC (the PIC10F200, which is around $0.35 in 100 qty). The problems listed in the prior post are all solved, the biggest remaining problem IMO is that the address has to be hard-programmed into each node, since they are connected in parallel (instead of series). It accepts data at 38400 baud in an 8N2 format, so that no intermediate data conversion is required between a PC and the string. The other issue, of course, is that it is quite tedious hand-assembling 100 nodes (be they SMD or through-hole), and I'm not in a position right now to deal with finding a board assembly house (which also puts it outside the realm of this forum/site). So for now this project is sitting on the bench.

Entropy

12-27-2009, 06:15 PM

mrpackethead

12-27-2009, 06:43 PM

David_AVD

12-27-2009, 06:45 PM

I've just started using those Allegro chips in a couple of designs. Very neat.

mrpackethead

12-27-2009, 06:51 PM

I've just started using those Allegro chips in a couple of designs. Very neat.

and you can push up to 150mA per channel at about 17V if i remember rightly.. Which makes it quite feisble to control some pretty grunty leds.

The Formfactor is not freindly for diy construction however.

Entropy

12-27-2009, 06:54 PM

Theres a bunch of custom chipsets that are available for doing this task.. An easy to get hold of one is the allegro A6281 ( http://www.allegromicro.com/en/products/part_numbers/6281/ ).. its about $0.70 if i remember correctly.. Sorts out your addressing issues... And driving it is almost trivial with any number of uP... This is what our tripix project was about..
OK, just keep in mind, my estimates are in US dollars.

You mentioned the A6281 once before and it's not that easy to find (only 1-2 distributors offer it in quantities less than 1500), and even in quantity, it doesn't drop below the ATTiny25 until 2,000 units (from Digi-Key). At that point it drops to $0.92, not $0.70. Most of the DIYers are probably going to be targeting the 100-500 units range is my guess. I'm currently thinking along the lines of 100-200 in my first year, going to 500ish the next year.

While I might eventually reach that scale, the ATTiny lets me get the volume pricing at a MUCH lower volume.

Entropy

12-28-2009, 05:09 PM

Grrrrrr... Still some investigation to be done, but I'm seeing occasional reliability issues where the color gets corrupted, which appears as a brief flicker during rapid updating.

I'm starting to see why I2C may be problematic. It remains to be seen whether I have enough flexibility in the Tiny's USI interface and in the master to have the master drive the bus push-pull instead of open-collector.

mrpackethead

12-28-2009, 10:31 PM

Keep going! the best learning is done while doing things that dont' work.

kychristmas

12-28-2009, 10:35 PM

Man, you guys are too smart for me.

When its done, please tell me what to order, where to solder, and how to plug it in. That's all I can handle :)

Thanks for all of the hard work Entropy

Entropy

12-28-2009, 11:16 PM

Keep going! the best learning is done while doing things that dont' work.
Heheheh. I already have a number of workarounds in mind. Many involve learning more about the Tiny2/4/85's USI.

Possibilities include:
1) Checksum byte, will reduce refresh rates but I've got room to play with so far.
2) Parity bit for each color. Will reduce me to 127 dimming levels, but the fact that I have a gamma curve expansion now may allow this to still achieve smoother dimming than a 255-level linear dimmer
3) If I can somehow get the slave's USI to operate in a slave-only SPI-ish mode WITHOUT configuring DO as an output. (That pin is already used for one of my PWM outputs and there are no spares without eliminating the ability to do ISP.)

The first two options maintain universal compatibility with I2C masters, the last one pretty much makes the system a custom protocol, however is going to be more robust - since I have no need for multimaster or slave readbacks, something that lets me go to a push-pull driving of the data and clock lines instead of the open-collector-with-bus-pullup of I2C. Option 3 may have to wait until better test equipment arrives.

Actually, Option 4 was mentioned earlier - The ATTiny48 is 10 cents more per node but has a TON of I/O compared to the Tiny25/45/85. Too much in fact, I'm concerned that a 28/32-pin chip may be too big even in SMD form, or at least the more DIY-friendly SMD packages.

Oddly, the 20-pin Tinys are MORE expensive than the 28-pin ones.

JonathonReinhart

12-28-2009, 11:56 PM

Sounds like you've got a great project going here Entropy. Keep up the good work!

Entropy

12-29-2009, 10:32 AM

Sounds like you've got a great project going here Entropy. Keep up the good work!

It's going to slow down soon. The family oscilloscope isn't a storage one and will make debugging the data corruption issues difficult, and will make developing a custom protocol very difficult. Plus that old tube-based dinosaur won't fit in my apartment - I need to go DSO-shopping soon.

WireWrap

12-29-2009, 11:32 AM

...
I need to go DSO-shopping soon.

Just think of it as an addition to your display for next year....

What's wrong with Blinky-Flashy-Whirly-Swirly lights?

:)

Entropy

12-29-2009, 12:01 PM

Just think of it as an addition to your display for next year....

What's wrong with Blinky-Flashy-Whirly-Swirly lights?

:)
Hmm, scope with X/Y inputs and VGA outputs + some microcontroller trickery = funky patterns.

Although X/Y scope tricks work better on the oldschool ones like the ones in the basement here. (I'm visiting my parents for the week.)

Too bad the new DSO Nano from Seeed only has one channel - I'd snag it in a heartbeat if it did two.

I'm also looking forward to the Sump Pump (or whatever it eventually gets called) getting finished and becoming available - http://dangerousprototypes.com/2009/12/17/open-source-logic-analyzer-update-2/#more-2827

Entropy

12-29-2009, 05:40 PM

Another idea to throw out - What would people think about HSV control instead of RGB control?

With HSV, using only two bytes, it would be possble to achieve (as an example):
64 hues (6 bits)
4 saturation values (from white to maximally saturated color) (2 bits)
256 levels of brightness, with a gamma curve applied (smoother dimming visually than a 256 level linear curve)

In the event that I don't find a better solution, this would allow for a byte to be allocated to checksumming without increasing the message size per node, eliminating the corruption problem without affecting refresh rates. I'm pretty sure I can fit an HSV to RGB conversion within the 500 bytes of flash I still have to play with.

dirknerkle

12-30-2009, 01:16 AM

What's wrong with Blinky-Flashy-Whirly-Swirly lights?

:)

Are they even legal?!?!? :p

WireWrap

12-30-2009, 09:47 AM

Are they even legal?!?!? :p

Does that matter???? :twisted: :twisted: :twisted:

:)

nofear

12-31-2009, 08:24 AM

I too am following this with much interest.

Matt_Edwards

12-31-2009, 08:38 AM

Another idea to throw out - What would people think about HSV control instead of RGB control?

Pardon my ignorance, but what is HSV? in Australia HSV is Holden Special Vehicles, and Google didn't really bring up any conclusive results

David_AVD

12-31-2009, 08:50 AM

http://en.wikipedia.org/wiki/HSL_and_HSV

Sometimes used in the professional lighting industry instead of RGB.

Entropy

12-31-2009, 09:14 AM

http://en.wikipedia.org/wiki/HSL_and_HSV

Sometimes used in the professional lighting industry instead of RGB.

Also used a lot by photographers and artists.

It stands for Hue, Saturation, and Value. So one number is the "color", one is "how colorful", and the last is "how bright".

The human eye is far more sensitive to brightness than to color, and as a result, one can gain good results with reduced bit depth for color information, as long as full bit depth for brightness is retained.

kiowamike

12-31-2009, 11:21 PM

Hmm, scope with X/Y inputs and VGA outputs + some microcontroller trickery = funky patterns.

Although X/Y scope tricks work better on the oldschool ones like the ones in the basement here. (I'm visiting my parents for the week.)

Too bad the new DSO Nano from Seeed only has one channel - I'd snag it in a heartbeat if it did two.

I'm also looking forward to the Sump Pump (or whatever it eventually gets called) getting finished and becoming available - http://dangerousprototypes.com/2009/...e-2/#more-2827

Would this help? I built one myself, more for entertainment purposes rather than a scientific tool. None the less, it was fun to build and play with.

http://www.pdamusician.com/lcscope/

Entropy

01-01-2010, 11:32 AM

Would this help? I built one myself, more for entertainment purposes rather than a scientific tool. None the less, it was fun to build and play with.

http://www.pdamusician.com/lcscope/
It isn't that low-cost anymore.

The DSO Nano has the same samplerate, is smaller than that box, and has a built-in display for $89. Only one channel however.

I'm seriously considering, rather than buy a partial solution that I'll need to upgrade down the line, just grabbing a Rigol DS1052E - They're about $500 nowadays and get good reviews. I won't go for the MSO variant, since I should be able to achieve the same thing once the Sump Pump becomes available, as the Sump has a trigger output in addition to a trigger input.

mrpackethead

01-01-2010, 02:48 PM

It isn't that low-cost anymore.

The DSO Nano has the same samplerate, is smaller than that box, and has a built-in display for $89. Only one channel however.

The circuit gearn CGR-101 from Saelig is well worth considering at $179 as a really useful tool for the serious DIYer.. Mac/Windows/Linux software and open source..

http://www.saelig.com/PSPCEL/PSPC019.htm

DynamoBen

01-01-2010, 05:46 PM

We should get back on topic but thought this one was worth mentioning. It just came out and looks to be very expandable.

http://www.parallax.com/Store/Microcontrollers/PropellerTools/tabid/143/ProductID/586/List/0/Default.aspx?SortField=ProductName,ProductName

DynamoBen

01-02-2010, 10:58 AM

If worst comes to worst it could be done with clocked serial...not as nice as I2C but doable.

Example: http://docs.macetech.com/doku.php/shiftbar

Entropy

01-02-2010, 03:32 PM

If worst comes to worst it could be done with clocked serial...not as nice as I2C but doable.

Example: http://docs.macetech.com/doku.php/shiftbar

Yup, I've been reading the datasheets to see if I can use the USI to receive a form of clocked serial. (Pretty much almost I2C but minus the ACKs going back from the slaves.) I think clocked serial without a strobe is doable on the slave end while retaining the benefits of USI (one interrupt per byte instead of one per clock), gotta tweak the master end a bit. Clocked serial with a strobe is not possible without moving to the ATTiny48, as there are not enough free pins on the Tin25/45/85 without losing ICSP capability. (The RESET pin can be used for I/O, but you can no longer hold the chip in reset, which means you can't in-circuit program it.)

Another possibility to investigate is using a constant current pullup on the I2C bus instead of a resistor-based pullup. See http://www.i2cchip.com/constant_current_pullup.html

Another option is the Linear LT1694-1, which only provides CC pullup during the rise slew. If the strand were driven only by AVRs (Probably a Mega168 as master, all nodes as Tiny25s), that could be doubled up.

P. Short

01-03-2010, 02:28 AM

Just out of curiosity, what are your intentions for this project in terms of making it available to others? Is it just for yourself, are you intending to run coops (or have someone stock the boards), to have the nodes assembled in Asia, or ???

Entropy

01-03-2010, 09:01 AM

I'm not sure if I am ready to run a coop/group buy myself.

So far I've only posted things that are tested and (mostly) working. So right now that's just my firmware source - I have only tested this on a breadboard now. That's GPL licensed - I was always planning on it being under an OSS license, and was strongly leaning towards GPL, the licensing terms of the I2C slave library I used sealed the deal. Which reminds me, my file headers indicate that the source is GPL-licensed but I forgot to actually include a copy of the full GPL text in my archive. I need to fix that.

I have an Eagle schematic/board for a through-hole prototype board as of yesterday, but I won't be posting that until I've actually etched a working board with it. At that point I'll be posting it, likely under a CC-BY-SA license. That board will probably not meet my cost goals, and won't exactly be the most outdoor-robust unit, however it should be usable to some.

Down the line I want to shrink the board to become an SMT board, hopefully something that can be "skillet soldered" as a panel wwth the exception of the LED and connectors (as they would be through-hole). At this point I may order a batch of commercial PCBs, if they work well I might consider a group buy/coop for the second batch.

At some point I may move this to a place like Google Code or github, as soon there are going to be too many components to keep track of in one thread effectively:
1) Firmware source for the nodes
2) Eagle schematic and board file for the through-hole prototype
3) Eagle schematic and board file for an SMT board
4) Firmware source and schematics/boards for a DMX-to-I2C bridge needed to control the strings
5) Schematics/board file for an LT1694-1 based bus terminator. (May make this part of #4, need to determine if it's best at the opposite end of the strand or not)
6) (Possibly) schematics for a switching-regulator-based power injector to step 12 or 24 volts down to 5v.

There are any number of things that could prevent me from achieving completion (My company has another round of layoffs in the pipeline, and I will also eventually reach a point where it is difficult/not much of a point in continuing development until I actually have bought a house.), however there should always be enough documentation that someone so inclined could easily pick up and continue without reverse engineering anything.

I definately do not plan to have nodes contract manufactured at the moment - if you want prepackaged nodes on a strand on a large scale, MPH/JEC's strands are your best bet. That said, I intend to keep the license such that anyone who wants to try and have the nodes contract manufactured can do so. (Who knows, it might prove to be something right up Seeed Studio's alley... They are becoming specialists in contract manufacture of "open hardware" projects. Their quality is so-so right now but hopefully improving as they get feedback from customers. I may try their Fusion PCB service for my first attempt at SMT boards.)

P. Short

01-04-2010, 12:32 PM

One thing that has bothered me about the pixels that I've been working on is the difficulty in obtaining a good, linear response. The human eye has a somewhat logarithmic response to light. The usual PWM method creates a more or less linear response, where an exponential response would be desired (so that it appears more linear after processing by the eye/brain). About a year and half ago I started to play around with creating a more-or-less exponential response, but it needed a more powerful processor, and I became distracted by other projects.

The more powerful processer in the I2C-addressable RGB LED Project should be useful in testing methods to address these issues. The HSV encoding, if supported by Vixen, should also help.

DynamoBen

01-04-2010, 07:06 PM

I have a pretty good dimmer curve that I'm using in my project. Its a table of 255 values and I do a lookup on it. If you are interested I attached a text file with the values and an excel spreadsheet with a graph of what the curve looks like.

Entropy

01-04-2010, 08:49 PM

I think it rises a bit too fast initially - probably good for incans since at low powers they're basically invisible.

The way most PCs and TVs do it is with what's called a gamma curve - map brightness to a range from 0-1, and you map input to output with:
out = in^gamma, where gamma is usually 2.2 for PCs.

I have a gamma=2.2 curve implemented, I am going to make some small tweaks to it. Right now the first 8-10 input values map to 0 output value. Other than that the curve works pretty well.

Entropy

01-08-2010, 08:30 PM

An update: I got my new oscilloscope (Rigol DS1052E) yesterday, and took a look at the waveforms. They looked... odd, like the Tiny85 was having serious trouble pulling down the bus when sending I2C ACKs and when clock stretching.

In addition, I remembered that I always had to disconnect the I2C master when programming the Tiny, which shouldn't have been necessary since the master should've been open collector with the drivers switched off when the bus was idle.

So after another attempt at digging into the firmware of the bus master I was using, I discovered that for some reason, it was using software bitbang I2C on ALL devices, regardless of whether they had hardware I2C, due to some unspecified problem/failure.

A little bit of tweaking and the master is in proper hardware mode and there's no longer a bus fight between the ATMega32U4 (the current master) and the Tiny85. No more flickers, things are nice and reliable now. Whatever undocumented "failure" caused the author of that particular bus master firmware to choose software I2C on all devices doesn't seem to be occurring on my Teensy board.

Piece of advice: DO NOT use the software I2C functions in avrlib - they have some severe problems!

New zip file with firmware source sometime this weekend - #define for common cathode vs. common anode LED, and possibly moving the I2C address into EEPROM.

I'm going to have to dig into the I2C slave library I'm using as it doesn't allow the application code to determine which address it is responding to (the set address or the "all call" address of 0x00) - I'm thinking I can have remotely programmed addresses with a jumper and the 0x00 address.

Entropy

01-10-2010, 10:36 PM

Breadboard prototype demo with two nodes posted to YouTube

http://www.youtube.com/watch?v=bg5ph8kWKJA

Matt_Edwards

01-10-2010, 10:45 PM

brilliant work. I hope you work out the miss triggers.
Now if only the Tiny13 would be usable.

mrpackethead

01-10-2010, 10:45 PM

Breadboard prototype demo with two nodes posted to YouTube

http://www.youtube.com/watch?v=bg5ph8kWKJA

nice work.

Entropy

01-10-2010, 11:08 PM

brilliant work. I hope you work out the miss triggers.
Now if only the Tiny13 would be usable.

MIGHT be doable without USI, but that would make my head explode. As much as I want to reduce costs, that's not worth 10 cents/node.

I just realized one potential other problem - I'm fitting into the flash of the Tiny25, but I haven't tested to see if I fit into its RAM. Gonna have to order some T25s to test with now.

If I have to jump to the Tiny45, I may just pop up to the Tiny48 - only a few cents more and FAR more flexible.

Matt_Edwards

01-10-2010, 11:10 PM

Prismalites

01-12-2010, 03:59 PM

MIGHT be doable without USI, but that would make my head explode. As much as I want to reduce costs, that's not worth 10 cents/node.

I just realized one potential other problem - I'm fitting into the flash of the Tiny25, but I haven't tested to see if I fit into its RAM. Gonna have to order some T25s to test with now.

If I have to jump to the Tiny45, I may just pop up to the Tiny48 - only a few cents more and FAR more flexible.

Hi, get in contact with me - I am the guy who invented and patented I2C RGB control (seriously) for use in holiday lighting. I have several patents regarding this type of system and have done extensive work in this arena and in intelligent holiday lighting in general and would be very glad to help! A couple of my related patents are 7,015,825 and 7,327,337 and it's very likely that I have already solved some of the problems you may encounter. I have always just lurked in here on occasion but when I saw that someone was interested in actually working on an I2C intelligent control system I wanted to chime in since I began working with this in 2003 with Philips (now NXP). It really is great to see someone with this interest. Actually I designed several of the NXP I2C color control ICs they currently sell and I developed the control systems and even the register layouts and command sets of those chips and a whole lot more that you may find helpful. Also I an an R&D engineer in SSL and have extensive experience in various embedded micro based implementations too and can easily help you to design/build light lines and controllers for your projects. I'd also be interested in helping to fund the effort on a private level and can get you all kinds of free samples and so forth to prototype with including pre-fab modules from NXP and ThingM some of my licensees! I am excited to hear from you and any others interested in this research and product dev!

Entropy

01-13-2010, 08:57 AM

Project on hold for a while, I'm going to be very busy with other stuff for the next week and a half, plus I now need to reread the GNU GPL a bunch of times regarding the interaction of patents and GPL.

Depending on how that goes, I may be either shutting down the project or significantly rearchitecting things, there's no way I'm going to rewrite Don Blake's GPL-licensed USI TWI Slave library from scratch.

Edit: Just one other thing I want to make clear to forum members, I've already sort of said this in earlier posts when P. Short asked about my intentions, but this is a hobby project/mental exercise. I have and never have had any intentions of commercial development, I'm leaving those headaches to MPH and JEC! My day job is completely unrelated to lighting control and will almost surely remain that way. Even if I do continue along with this work, I can guarantee at this point that there will not be any group buys or coops offered by myself. I was nervous about the hassle/responsibility involved to begin with, but the patent issue tips the scale for me. Anyway, anyone interested in building nodes based on this design is going to be interested in sufficient quantities of nodes to get pretty good price breaks on components and PCBs anyway.

mrpackethead

01-13-2010, 02:28 PM

Entropy

01-13-2010, 06:31 PM

OK, thanks for the clarification. I just need to track down the GPL stuff some more.

Entropy

01-13-2010, 08:53 PM

>Read the patents,

I have

>they are not too hard to understand for sure

If you wrote them, i'm sure they are not.

>There's plenty more but for Gods sake I don't want to write a book here!

As yet, you've not offered anything to help out entropy in his project, other than to tell everyone that you have some patents? I can't make sense of it?

>I -did- like your display,

Thanks. So did many other people. It did'nt have a scrap of I2C in it, sorry.

>and yes I think it was brilliant

Yup, it was bright. Though i didn't measure how bright.

>volumetric displays

You might need to elaboroate what that is.

To Prismalite's credit, he did offer some help (reread his first post... Or was that his initial PM to me?)... He just offered it at the same time as bringing up patents, which makes people tend to freak out a bit! :)

However, at this point in time, most of my barriers are AVR software specific - in two different instances (Both my ATMega32U4-based USB board, and my ATMega168-based board) the CPU in my I2C master hangs at some point. At least I know it's not specific to the USB virtual serial implementation on the 32U4 now that I have the exact same symptoms on the Mega168-board using a hardware UART and a USB-to-serial converter.

There's a possibility I might need help with the "missed update" issue seen in the video, but first I need to find a good recreatable test case, and also double check the code of the I2C slave implementation, as the implementation in the Tiny85 is a 50/50 mix of software and hardware.

Prismalites

01-13-2010, 09:00 PM

To Prismalite's credit, he did offer some help (reread his first post... Or was that his initial PM to me?)... He just offered it at the same time as bringing up patents, which makes people tend to freak out a bit! :)

Let me read what you have posted and see if there's anything I can offer. Thanks for not throwing me into the ranks of a patent troll. I'm harmless (mostly) - hahahah.

Off the cuff, look at this Entropy: blinkm.thingm.com , the BlinkM.

Its a implementation similar to what you're trying to do I think and if you want you can get one to play with. If you need the micro source code that can be arranged. These have been used by my pals out there Tod and Mike in some excellent art pieces and demonstrations. ;-)

Entropy

01-13-2010, 09:17 PM

I've seen the BlinkM - It's an interesting piece of hardware, however at on the order of $10/node, it's pretty much not feasible for a lot of projects. Even at the $2/node price point of MPH's work, it's really expensive once the node count goes up!

In terms of seeing the micro source - Since I have been releasing my firmware under the GPL, that might not be the best idea.

Prismalites

01-13-2010, 09:33 PM

I've seen the BlinkM - It's an interesting piece of hardware, however at on the order of $10/node, it's pretty much not feasible for a lot of projects. Even at the $2/node price point of MPH's work, it's really expensive once the node count goes up!

Okay then. But even would the code in those units help some in your project? I was just asking and that could be arranged. Also, we all know its a fact that its VERY difficult to minimize an RGB nodes cost beyond a certain point. Which...brings to mind something else interesting I might pass along to you and the forum. I happen to be privvy to a new IC thats coming out that was invented by Tsutomu Shimomura another LED control researcher contact of mine that breaks alot of the distance barriers and power distribution problems down. If I can get him to let me show you the datasheet I will. Might require a simple NDA though.

Expense is unavoidable also when you use quality LEDs and if you design your nodes not to be unidirectional on the emitter side of things, say like when you have emitters on both sides of a board. Just some thoughts. Module BOM is the killer, huh? ;-)

Prismalites

01-13-2010, 09:49 PM

Okay then. But even would the code in those units help some in your project? I was just asking and that could be arranged. Also, we all know its a fact that its VERY difficult to minimize an RGB nodes cost beyond a certain point. Which...brings to mind something else interesting I might pass along to you and the forum. I happen to be privvy to a new IC thats coming out that was invented by Tsutomu Shimomura another LED control researcher contact of mine that breaks alot of the distance barriers and power distribution problems down. If I can get him to let me show you the datasheet I will. Might require a simple NDA though.

Expense is unavoidable also when you use quality LEDs and if you design your nodes not to be unidirectional on the emitter side of things, say like when you have emitters on both sides of a board. Just some thoughts. Module BOM is the killer, huh? ;-)

One way I started working on in 2002 to minimize node costs was to actually embed the I2C driver into a 8mm RGB encapsulated LED with the required 4-pin connector built in. I prototyped those with Philips Logics help and a compnay called ETG , about 250 of them for experiments. Thermal imaging showed they were getting too hot and so I solved the thermal management problem but never put those into production beyond the first run. I used bare dice for the driver portion on a metal core pcb which I had to tweak for the thermals...

Prismalites

01-13-2010, 09:54 PM

I've seen the BlinkM - It's an interesting piece of hardware, however at on the order of $10/node, it's pretty much not feasible for a lot of projects. Even at the $2/node price point of MPH's work, it's really expensive once the node count goes up!

In terms of seeing the micro source - Since I have been releasing my firmware under the GPL, that might not be the best idea.

I might be able to resurrect that old design or at least post some data and pics to anyone interested in the "no external parts" required fully encapsulated RGB I2C LED. It was a good idea then and a good idea now but I never marketed it.

Entropy

01-13-2010, 10:02 PM

Well, in terms of LED quality, these 10mm diffused ones from EMSL seem more than sufficient at 45 cents/pop. :)

In terms of seeing the BlinkM source code - the problem is that after seeing their code, it is VERY difficult for me to prove that somehow their code didn't wind up in my GPLed code. See, as an example, the SCO fiasco and the AT&T/BSD saga.

I just found a definitive "something is broken" with my USI slave library, so I'm going to investigate that further. (Periodically something is pulling SDA down for no reason at all.) In the case of my USI slave library, the guy that ported it from the Atmel app note to GCC lives 10 minutes down the road from me. :)

As mentioned in previous posts, pincount issues (the addressing interface) may take me to the Tiny48 (adds 10 cents/node). That has a full blown TWI module in, which eliminates USI implementation bugs. However, that unit is kind of overkill in the pincount arena. I still can't figure out why it's so cheap - nearly all of the other Tinys are more expensive but less capable! (Although the price delta at Mouser seems to have gone from 10 cents to 15-18 cents between the Tiny25 and the Tiny48)

DynamoBen

01-13-2010, 10:04 PM

I might be able to resurrect that old design or at least post some data and pics to anyone interested in the "no external parts" required fully encapsulated RGB I2C LED. It was a good idea then and a good idea now but I never marketed it.

I think the two biggest challenges with this project are going to be cost, and the ability to make this at home. Will this older project be able to be adapted for DIY?

Prismalites

01-13-2010, 10:11 PM

As someone whos followed that entire debacle for years, you might understand why you looked like part of CK, and their craziness.

Yeah I suppose it could have been construed that way. But anyhow, back to smaller more affordable smart RGB nodes...Has anyone here ever tried to just build custom LEDs with the driver (micro or otherwise) into an encapsulated bullet module? It could save money per node theoretically if you could have enough of them built, and if some of you are interested I'd be glad to post some stuff later about it. The wire bonding was a bit complex for the Taiwanese folks I had make them up initially but it did work. Addressability was wire bonded pre-set but at the time it was an experiment. I have some ideas now about how to do ICP address setting and so forth so a MkII version would be cool to work on. Any interest would be welcome.

And sure DynamoBen, some of the I2C RGB DIY'ers would have a ball with that type of LED I'm sure. If they can send I2C signals and know anything about busses, repeaters , line drivers or whatnot why not? It might be something I'd be interested in picking back up with enough interest.

DynamoBen

01-13-2010, 10:16 PM

Yeah I suppose it could have been construed that way. But anyhow, back to smaller more affordable smart RGB nodes...Has anyone here ever tried to just build custom LEDs with the driver (micro or otherwise) into an encapsulated bullet module? It could save money per node theoretically if you could have enough of them built, and if some of you are interested I'd be glad to post some stuff later about it. The wire bonding was a bit complex for the Taiwanese folks I had make them up initially but it did work. Addressability was wire bonded pre-set but at the time it was an experiment. I have some ideas now about how to do ICP address setting and so forth so a MkII version would be cool to work on. Any interest would be welcome.

Keep in mind that one of the tenets of this forum is no pre-made devices. We do group buys on boards and parts, members must build it themselves.

Matt_Edwards

01-13-2010, 10:17 PM

firstly Prismalites I appreciate you openness and willingness to work with the DIY community here. It is a great hobby and most people here would not represent a threat to your patents.

Now I would like to raise a scenario similar to what is discussed. If I use a 6ch of a TI 8CH LED driver chip that uses IIc as the C&C bus, connected to 2x RGB LEDs I am in no way breaching the Patents referenced in your OP. You can't patent the use of IIc nor RGB ( You have already stated this) Bringing the two together via a TI chip doesn't put me in breach of your patent, because I don't hold the IP to the IIc LED Driver, that is for TI.

Now should i design a DMX to IIc bridge, I suspect that would be a different story, as that is a unique bringing together of two technologies.

So I for one would like to continue developing LED fixtures.

Prismalites

01-13-2010, 10:21 PM

Keep in mind that one of the tenets of this forum is no pre-made devices. We do group buys on boards and parts, members must build it themselves.

Well then I guess since I can surmise that nobody here has their own wire-bonding machinery or LED encapsulation equipment that idea is a little impossible to implement with your stated limitation. Some things just can't be done without the right tools and thats a sad fact - especially when you're talking about LED systems and "bringing down the cost". Oh well...

Entropy

01-13-2010, 10:24 PM

David_AVD

01-13-2010, 10:33 PM

Keep in mind that one of the tenets of this forum is no pre-made devices. We do group buys on boards and parts, members must build it themselves.

I'm only new here as well so find this potentially confusing. I can't say I read anything about it when I signed up. Can you point me to where this please? I'm not being argumentative, just curious as to where all this is spelled out.

Personally, I think it's hard to draw a definitive line as to what's "pre-made" and what's simply a component of a larger project. I mean we don't make the IC's, LEDs, cable, boxes, etc that we all use. As long as the "pre-made" item isn't pretty much the whole item, where's the problem?

kychristmas

01-13-2010, 10:34 PM

Keep in mind that one of the tenets of this forum is no pre-made devices. We do group buys on boards and parts, members must build it themselves.

I don't see how this can't change. Both of the RGB Node threads I though were going to pre assembled if they ever became a Co-op/group buy item. I thinks there's quite a bit of gray area here. Do we view these Nodes as a we would a string of lights. For instance, there are folks trying to look at a co-op for LED Strings. Are those not pre-made? I don't think we should pay more than we should or allow quality to suffer to blindly follow the the DIY concept.

While I certainly understand that this is DIY, I'm not clear on where the Line is. DIY skills vary greatly from member to member. I'm not trying to be confrontational Ben, I want to try to understand the contstraints.

Maybe I'm reading too much into your statement.

Kelly

Prismalites

01-13-2010, 10:39 PM

Sounds like you described the "Asian Node" as I call it. See the end of MPH's video.

MPH has access to a pretty nice driver chip that is widely available in Asia but pretty much unsourcable in the US. (Probably due to Color Kinetics...)

Matt raises an interesting question regarding the TI chips... My guess is they're a licensee...

Edit: On a semi-related note, I just found a bunch of bugs in my slave code. I had a timeout that would reinit the USI TWI if no data was received for a while, I've replaced that with a simple buffer flush. Now I'm really wishing I had a better ICSP to breadboard adapter, with two nodes connected, reprogramming both is a pain!

TI is using I2C because Philips licensed it to them a long time ago. Actually I think the original I2C patents expired a few years ago anyway.

Entropy

01-13-2010, 10:39 PM

Both? I know there is:
1) MPH/JEC's project - yeah this one has preassembled nodes
2) This thread - I've stated multiple times I'm nervous about organizing a coop/group buy. Anyway, if I can build it, you can too! :P
3) There were one or two DMX pixel threads, one from (I think?) Matt Edwards - this was fully DIYable IIRC.

DynamoBen

01-13-2010, 10:42 PM

David_AVD

01-13-2010, 10:54 PM

DynamoBen

01-13-2010, 10:58 PM

Ah, your comment only applies to Group Buys then? I'm sure there will be plenty of projects in the future that need sub-assemblies. As long as discussion of the items and linking to the outside seller is ok, that should still be within the bounds?

To an extent, typically we relegate these announcements to the Venders area of the forum. Further this forum is held harmless in all of these sorts of interactions.

With that being said even if the project won't go through a group buy here need to be willing to post schematics, and code here for all to benefit.

Prismalites

01-13-2010, 11:22 PM

Sounds like you described the "Asian Node" as I call it. See the end of MPH's video.

MPH has access to a pretty nice driver chip that is widely available in Asia but pretty much unsourcable in the US. (Probably due to Color Kinetics...)

Matt raises an interesting question regarding the TI chips... My guess is they're a licensee...

Edit: On a semi-related note, I just found a bunch of bugs in my slave code. I had a timeout that would reinit the USI TWI if no data was received for a while, I've replaced that with a simple buffer flush. Now I'm really wishing I had a better ICSP to breadboard adapter, with two nodes connected, reprogramming both is a pain!

Well, I think I know of what chip you speak of but its number escapes me right off hand tonight. Yes evidently they are pretty scarce and if its the driver I am thinking of the protocol itself had to be reverse engineered even to make it work. Not exactly like that Asian Node thing, no, but probably similar in function? I dunno. I would appreciate a link to where I could see one up close and a few specs. Remember, i don't know my way around this place too well yet. ;-)

kychristmas

01-13-2010, 11:37 PM

Sorry folks, see the rules here:
http://www.doityourselfchristmas.com/forums/showthread.php?t=2919

There aren't any group buys for pre assembled items is on this site. We allow members to announce the sale of these items here but you must handle the sale off site.

This is starting to become a hi-jacking, but I will leave that to the MODS.

I can read the rules, but I think the interpretation is a problem for me. At what point does it become a component rather than a pre-made assembly? I'm pretty dense about this technology, but I see these Nodes as being a component rather than a sub-assembly. Like a very sophisticated LED, No?

So, a Group Buy for LED Strings would not be an official DIYC and would need to be run off-site or through the approved Vendor?

DynamoBen

01-13-2010, 11:47 PM

So, a Group Buy for LED Strings would not be an official DIYC and would need to be run off-site or through the approved Vendor?

Correct, if you have further questions on this feel free to PM a MOD or our ADMIN.

Prismalites

01-13-2010, 11:55 PM

Well theres another good project going west....

who certainly do have headaches. And to make it perfectly clear to everyone. I am not using I2C to control leds.

Just FYI, we built a 110' light-line tree down at Tanglewood Park in Clemmons NC this year that does what your equipment does but with mathematical algorithms that do text and 3-d effects (the volumetric thing you asked about) at about 62fps update rate. I worked for several years with a few collaborators to build something like this and these RGB trees really look great don't they? Thats why I said I was impressed. I therefore wasn't complimenting you on your brightness, just your forward thinking. Please follow this link to see our large proprietary commercial system now available for sale. It was on display to over a million viewers in two locations in the US this past season and they really liked it. I'm sure a smaller version marketed to the DIY crowd would do great. I had this all working in December of 2007 - we just missed a window for marketing to commercial venues earlier because of mass production of the light strings but thats fixed. This year , 2010, is a different story. I have a 25' demo unit I'm taking to Disney, Dollywood, and others in about 2 weeks. What you did on your own is very impressive and I understand the challenges you went through so again - great job.

BTW this is not a sales pitch to sell to anyone on the boards at all, I just wanted you all to be aware that very large and very intelligent RGB displays are a primary focus of mine for many years and that the commercial customers love it. They are truly mesmerizing when programmed properly. Scrolling text on this unit was a big deal - it was used to show several holiday messages and sponsor messages.

http://news14.com/coastal-news-110-content/top_stories/617553/festival-of-lights-opens-in-clemmons--tanglewood-park/

DynamoBen

01-14-2010, 12:09 AM

Happened upon this tonight not a lot of detail but might offer some inspiration.

http://www.pchilton.co.uk/rgbleds.html

Prismalites

01-14-2010, 12:21 AM

Happened upon this tonight not a lot of detail but might offer some inspiration.

http://www.pchilton.co.uk/rgbleds.html

Thanks! Nice link...looking into that!

mrpackethead

01-14-2010, 02:08 AM

Deleted my reply. Second thought was that i was descending to a level below me...

djulien

01-14-2010, 02:10 AM

Has anyone here ever tried to just build custom LEDs with the driver (micro or otherwise) into an encapsulated bullet module?

I'm not wanting to hijack the thread, but maybe this is somewhat related... Is something like that already available? (a flash-programmable or bootloader-enabled microcontroller embedded/bonded with an RGB LED, or perhaps even a pre-programmed version of that with a 2-wire RGB LED that accepts address and color-select signals modulated on top of the +ve supply)

don

Aurbo99

01-14-2010, 08:27 AM

Entropy

01-14-2010, 10:43 AM

Entropy,

I didn't read too far down this thread yet, so this may have already been answered.

I2C uses one Master and multiple Slaves if I recall
I'f thats correct, then in setup, user input on how many units can set your Slave id count.

I2C actually allows for multi-master operation.

The rest of it... I don't quite understand what you said. Each slave device on an I2C bus has an address, it's not "self-addressing-by-physical-architecture" like some of the 595-based protocols and the Asian chipset in MPH/JEC's nodes. The issue is, of course, how to assign an address to each slave node. Right now my two most likely avenues are:
1) ICSP programming of the AVR EEPROM - With the current MCU I would need connectorized nodes, as the pins used for SPI are also used by I2C on the TinyX5 - If you try to program a node when there are others on the I2C bus, the I2C functionality of the other nodes conflicts with the ICSP protocol.

2) A "program" jumper combined with the I2C "all call" address. In theory this could be done with the current MCU, but would result in a short if you put the jumper on before the MCU was in "program mode" as the progmode input would have to be shared with an LED output! (this is possible but ugly - send a command to the "all call" address to put the whole strand into progmode which configures that pin as an input, then jumper it, then send another "set address" command.)

Moving to a Tiny48 makes either approach much easier - extra I/O and ICSP is on separate pins from I2C.

n1ist

01-14-2010, 01:02 PM

What about a mode where you use the LED as a photosensor to either receive data or put one of the nodes on a string into programming mode?
/mike

Prismalites

01-14-2010, 01:53 PM

What about a mode where you use the LED as a photosensor to either receive data or put one of the nodes on a string into programming mode?
/mike

That actually WORKS - pretty sharp of you Mike. We messed around with that in 2003 and instead of using the LED as a sensor we just hung off a small coil to an unused pin of the micro and pulsed a custom EM sequence to the module to program it, the node address or alternatively a stored blink/color pattern. Easy. What we ended up with was this "wand" that we pointed at the light nodes and set addresses , then the wand could also be used on a similarly EM pickup coil configured master in another mode to control light string sequences stored locally in it... I also went the other way and worked out a system by which data could be broadcast via an IR LED on a 4th bit of a driver IC or micro allowing for some other very interesting possibilities like display serial number broadcast, date of manufacture, and so on. Just wanted to throw that in. Might be useful.

kychristmas

01-14-2010, 02:00 PM

Good Lord! I feel like I stumbled into the Neuroscientist Club meeting while on my way to a G.E.D. Preparation class. I'm starting to feel VERY, VERY Inferior:)

Entropy

01-14-2010, 02:34 PM

What about a mode where you use the LED as a photosensor to either receive data or put one of the nodes on a string into programming mode?
/mike

Hmm. I'm fairly certain one of my LED outputs is also an ADC input. The question is whether a diffused LED with a series resistor is sensitive enough. I'll have to play with that sometime after I return from my business trip...

mrpackethead

01-14-2010, 02:59 PM

the led programming idea is very clever, but do you need to be so complex?

ctmal

01-14-2010, 03:06 PM

I'm not sure this would help out on addressing but I'll take a stab at it anyway...

If there's room for 2 buttons on the master and 1 button on each slave you might be able to have a program mode...I believe there's a broadcast address in I2C

Button A on the master enters program mode, button B selects it and repeats it to the broadcast.

On the slave, a press of the button accepts and saves the address.

This would also allow multiple leds on the same address if that's what you wanted.

It's probably too simplistic to work but I tried...;-)

Entropy

01-14-2010, 04:57 PM

the led programming idea is very clever, but do you need to be so complex?

If I stay with the TinyX5, I may need to be - Sharing a pin between LED PWM output and jumper input depending on mode presents a pretty big risk of a short. I am maxed out on I/O unless I enable the RSTDISBL fuse, but I really don't want to do that since it eliminates the ability to do ICSP programming.

Even if I give up ICSP programming, the LED-as-sensor idea gives me the ability to completely encapsulate the whole thing and still program the address - If you encapsulate the leads, LEDs don't corrode!

I'm not sure this would help out on addressing but I'll take a stab at it anyway...

If there's room for 2 buttons on the master and 1 button on each slave you might be able to have a program mode...I believe there's a broadcast address in I2C

Button A on the master enters program mode, button B selects it and repeats it to the broadcast.

On the slave, a press of the button accepts and saves the address.

This would also allow multiple leds on the same address if that's what you wanted.

It's probably too simplistic to work but I tried...

I could do this, but it's easier to just hook the strand to a USB-to-I2C or serial-to-I2C bridge like the one I'm using now than to add buttons to the master (which in a typical setup is going to be a DMX-to-I2C bridge). On a slave a button is too expensive, and is functionally the same as a jumper anyway.

Another possibility is pogo pins, depending on the corrosion resistance of PCB pads. http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=138

Edit: A bit of an update, I just squashed a LOT of bugs tonight. My serial-to-I2C bridge hasn't hung/froze since I moved the I2C transmission routines out of a task ISR and into an endless for() loop. (There's an if() statement to make sure there is something to send of course). Similarly, since disabling sleep mode on the Tinys, things are mostly solid. Not a single missed update or glitch on the first node. The second node on the breadboard occasionally gets glitchy data. Strange thing is - it gets WORSE as you drop the clock frequency and better as you crank the I2C clock above 100 kHz. So something weird happens when you try to send updates too soon after one another. Not sure if it's a node glitch or a master glitch. Will hopefully have a chance to look at it on the scope this weekend.

scorpia

01-17-2010, 10:47 PM

not sure if this is related. but check http://www.sebsz.com/index.php?m=01&y=10&entry=entry100116-141613

looks like an interesting project

Entropy

01-20-2010, 08:22 PM

not sure if this is related. but check http://www.sebsz.com/index.php?m=01&y=10&entry=entry100116-141613

looks like an interesting project
TLC5940 or PCA9635 based most likely - 5 RGB LEDs from a single controller board says some sort of 16-channel chip. The presence of what appears to be addressing jumpers says PCA9635 to me.

These are good for when you aren't trying to build a "strand" of lights and can afford having semi-centralization (a controller board for every 5 lights).

Prismalites

01-23-2010, 06:43 PM

TLC5940 or PCA9635 based most likely - 5 RGB LEDs from a single controller board says some sort of 16-channel chip. The presence of what appears to be addressing jumpers says PCA9635 to me.

These are good for when you aren't trying to build a "strand" of lights and can afford having semi-centralization (a controller board for every 5 lights).

Yes he's using the NXP part. ;-) I wanted to comment also right quick about I2C RGB intelligent LED lighting applications on a large scale in general. There seems to be a common misconception (not necessarily here in this forum though) that I2C cannot be used in large scale RGB lighting systems because of bus length limitations , bounce, and so forth but thats simply incorrect. I suppose its a throwback to what everyone learned in engineering class about I2C and short-run communications limitations back in the day, I dunno.. BUT - Its a fact that advancements made in the past few years including the FM+ standard now allow huge systems to be constructed. Lighting node networks made up of more than 340m of cable can be designed now with some innovative yet relatively simple to implement engineering. Please reference :

http://www.bus-buffer.com/_data/docs/bus-buffer-design-ideas-di002.pdf

and take a look at this please, it could be helpful as well:

http://ics.nxp.com/support/documents/i2c/pdf/i2c.clock.speed.calculator.pdf

I don't know if any of you are considering using FM+ yet for anything but you might seriously look at it - At the very least you can see how the integration of various very handy bus buffers and switches can help you to build MUCH larger scale I2C RGB LED node designs. The example in the NXP link that uses the PCA9633's is a prime example of a conservative design that doesn't nearly reach it's potential I2C comm. distance limit. Just wanted to throw in some info. Thanks guys I am glad I joined there's alot of interesting info flying around here!

SeBsZ

01-23-2010, 06:56 PM

Prismalites

01-23-2010, 09:14 PM

Hi,

Thanks for mentioning my project. If anyone is interested, I just posted an update on my website. I now have 25 RGB LEDs. Fun! http://www.sebsz.com . Should anyone have any questions, feel free to ask!

Thanks for watching,

Regards,

SeBsZ

A question. What do you think about the NXP I2C dimmer parts in general? Do you like the lower level functionality that was designed into them to make sequencing a bit easier? What would you do to improve them?

Regards
Prismalites

mrpackethead

01-23-2010, 10:05 PM

A question. What do you think about the NXP I2C dimmer parts in general? Do you like the lower level functionality that was designed into them to make sequencing a bit easier? What would you do to improve them?

Regards
Prismalites

How about you start a new thread? Poor old entropys threads been hijacked several times so far.

Prismalites

01-23-2010, 10:26 PM

How about you start a new thread? Poor old entropys threads been hijacked several times so far.

Not at all meaning to hijack anything and thus far I personally have actually just been mostly trying to post a few useful bits of information only sporadically directly related to the evolution Entropy's project. . . I saw no other reference to how he might be enabled to extend his modules farther apart and so on and so I have tried to help. Look, are you a hall-monitor here or what? Just because you primitively hacked together some very limited intelligent basic light strings using somone elses technology that had to be reverse engineered even to work does not give you the right to direct anything here. Read up on it. I am not in your class so please don't lecture me on 'hijacking' anybodys anything. I worked for 5 hours last night trying to lay out a simple method for self addressing modules for Entropy , where's your solution? I have mine ready to post. Please, if you can't be constructive and add anything but "blah grumble blah" stay silent yourself and start your own thread! These projects and refs are ALL very related and are quite applicable to the evolution of Entropy's project.

General description:

ALL NODES AT POWER UP ARE UNDER CONTROL OF AN AUTOMATIC SELF-ADDRESSING PROGRAM AND ARE MONITORING PIN R (ARX) TO RECEIVE 7-BIT BINARY NODE ADDRESS SET-UP DATA FROM THE SLAVE NODE OR MASTER BEFORE IT. PIN T (ATX) IS UTILIZED TO TRANSMIT INCREMENTED 7-BIT BINARY NODE ADDRESS SET-UP DATA TO THE NEXT I2C RGB LED NODE IN LINE. ALL NODES HAVE A SERIES IN/OUT CONNECTION BETWEEN THEM AT PIN T AND PIN R. THE FIRST PIN R (ARX) ON NODE 1 CONNECTS TO A MASTER (MTX) PIN. THIS SOLUTION REQUIRES 4-WIRES (I2C) PLUS 1 ADDR TX/RX WIRE INTERCONNECTED BETWEEN EACH NODE AT PINS T AND R. ALL NODES ON POWER UP DO NOT SET UP THEIR MICROS FOR I2C BUS COMM. UNTIL EACH NODES AUTOMATIC SELF ADDRESSING PROGRAM ENDS.

MASTER STARTS AN I2C-COMMUNICATIONS WAIT TIMER LOOP
A 7-BIT BINARY START VALUE X IS SENT TO NODE 1 ARX BY A MASTER MTX PIN,
NODE 1 SELF ADDR PROGRAM RECEIVES VALUE X AND PERFORMS X=X+1,
INCREMENTED VALUE X IS STORED IN NODE 1 MEMORY AS ITS I2C ADDRESS
NODE 1 ATX SENDS THE INCREMENTED 7-BIT BINARY VALUE X TO NODE 2 ARX PIN R,
NODE 1 SELF ADDR PROGRAM ENDS
NODE 1 SHIFTS INTO I2C COMM MODE USING ITS ASSIGNED I2C ADDRESS.
NODE 2 SELF ADDR PROGRAM RECEIVES VALUE X AND PERFORMS X=X+1,
INCREMENTED VALUE X IS STORED IN NODE 2 MEMORY AS ITS I2C ADDRESS
NODE 2 ATX SENDS THE INCREMENTED 7-BIT BINARY VALUE X TO NODE 3 ARX PIN R,
NODE 2 SELF ADDR PROGRAM ENDS
NODE 2 SHIFTS INTO I2C COMM MODE USING ITS ASSIGNED I2C ADDRESS.
NODE 3 SELF ADDR PROGRAM RECEIVES VALUE X AND PERFORMS X=X+1
. . .
N TX/RX PROCESS REPEATS UNTIL MAX # OF NODE ADDRESSES ARE SET AND
ALL NODES ARE SHIFTED FROM SELF ADDRESSING MODE INTO I2C COMM MODE.
MASTER I2C-COMMUNICATION WAIT TIMER LOOP ENDS,
MASTER INITIATES AN I2C RGB NODE ADDRESS TEST SCAN N=N+1 UNTIL NO ACK
TOTAL N BEFORE NO ACK = # OF I2C RGB LEDS AUTOMATICALLY SEQUENTIALLY ADDRESSED.
NODES ARE NOW READY TO RECEIVE UNIQUELY ADDRESSED I2C RGB LED COMMANDS

Not complete , but I think this is on the right track Entropy I will run tests it should work. Sorry for the extra wires, but it was necesary using this addressing construct.

Regards,

Jeff

aussiephil

01-23-2010, 10:43 PM

Yes he's using the NXP part. ;-)

http://www.bus-buffer.com/_data/docs/bus-buffer-design-ideas-di002.pdf

and take a look at this please, it could be helpful as well:

http://ics.nxp.com/support/documents/i2c/pdf/i2c.clock.speed.calculator.pdf

I don't know if any of you are considering using FM+ yet for anything but you might seriously look at it - At the very least you can see how the integration of various very handy bus buffers and switches can help you to build MUCH larger scale I2C RGB LED node designs. The example in the NXP link that uses the PCA9633's is a prime example of a conservative design that doesn't nearly reach it's potential I2C comm. distance limit. Just wanted to throw in some info. Thanks guys I am glad I joined there's alot of interesting info flying around here!

I would like to say thankyou for those links, they should be required reading for anyone playing in this space.
I have two projects using FM+ and had missed the calculator pdf in all the research.
I have just swapped from TI parts to the NXP parts and they look to be good by the spec sheets, just wish they were a little more available :)

In my current toy shop searching (china manufacturers) i've notice a large number of IIC driven RGB LED Nodes becoming available at cheap prices, US90c/node was one price i was given.

Aussiephil

Prismalites

01-23-2010, 11:15 PM

I would like to say thankyou for those links, they should be required reading for anyone playing in this space.
I have two projects using FM+ and had missed the calculator pdf in all the research.
I have just swapped from TI parts to the NXP parts and they look to be good by the spec sheets, just wish they were a little more available :)

In my current toy shop searching (china manufacturers) i've notice a large number of IIC driven RGB LED Nodes becoming available at cheap prices, US90c/node was one price i was given.

Aussiephil

Please , pass along to the forum any information you have on I2C node producers..it would sincerely help Entropy and others interested in applying the technology.

Regards

Jeff

mrpackethead

01-23-2010, 11:35 PM

In my current toy shop searching (china manufacturers) i've notice a large number of IIC driven RGB LED Nodes becoming available at cheap prices, US90c/node was one price i was given.

Aussiephil

90c wow, thats expensive.. I've seen them for as low as 0.50c..

However Good luck if you want them to last for much more than a few days. The build quality of 90% of the stuff is absolute garbage. They are not waterproof ( they will claim IP67, but won't survive a rain shower ), they will use the nastyist cheap cable ( that will perish in the sun in less time than a single blinky season..

mrpackethead

01-23-2010, 11:36 PM

Please , pass along to the forum any information you have on I2C node producers..it would sincerely help Entropy and others interested in applying the technology.

And no doubt it will help the patent owners keep an eye on things.

Prismalites

01-23-2010, 11:40 PM

And no doubt it will help the patent owners keep an eye on things.

Please...?

budude

01-23-2010, 11:44 PM

And no doubt it will help the patent owners keep an eye on things.

That's odd - - could have sworn this got moved to a separate thread... what was that about hijack again?

Prismalites

01-23-2010, 11:50 PM

That's odd - - could have sworn this got moved to a separate thread... what was that about hijack again?

Its pretty obvious that MPH is in here just to play "stir up" - as he has consistently not offered anything useful but has adamantly continued on with his assured stream of negativity - again, WHAT are YOU contributing MPH? Either stop posting things intended to provoke other members or go silent. I , for one, find MPH less than amusing. Sorry, budude , for posting this in your comment. Its' just really quite alarming socially speaking how some people just can't get along.

mrpackethead

01-24-2010, 01:23 AM

Sorry to !Prismalites but its important that i correct a few things here that are not really factual, and that will be the last i'll say.

Just because you primitively hacked together some very limited intelligent basic light strings using somone elses technology

Yes, what I did was based on someone elses technology. Just like most work these days is based on someone elses work.. I don't believe i ever claimed anything other than that.

that had to be reverse engineered

Actually it did'nt need to be reverse engineered. It was my lack of ability to read chinese that was the problem. The datasheet was not available in english, it was easier just to watch the data, and work it out that way. Theres no big secrects there.

The point is that we actually did it, and created somethign that a LOT of people really enjoyed.

As for it being primitive, it did what it needed to do. I can't think of why i need a more intelligent node. Its reduced to something that is pretty much tiny, in order to reduce the cost point. It doesn't need to be able to do any more. And more importanly it MET my needs and requirements.

Oh and it was published back in December

aussiephil

01-24-2010, 01:45 AM

90c wow, thats expensive.. I've seen them for as low as 0.50c..

However Good luck if you want them to last for much more than a few days. The build quality of 90% of the stuff is absolute garbage. They are not waterproof ( they will claim IP67, but won't survive a rain shower ), they will use the nastyist cheap cable ( that will perish in the sun in less time than a single blinky season..

Yeah, i've seen them down to 50c too, I was quoting a confirmed price from a place i have dealt with and have happy with other products they have :). Mind you their nodes may be no good either, haven't ordered i was just curious on price :).

Cheers

Macrosill

01-24-2010, 09:41 AM

Knock it off and get back on topic. If anyone has a problem with another take care of it via PM, not in a thread. Should this veer off topic again infractions will be issued for all involved.

tconley

01-24-2010, 06:01 PM

what software are you using to control the display are those elements dmx addressable? What do you think a cost per pixel element would be?

Entropy

01-24-2010, 08:20 PM

what software are you using to control the display are those elements dmx addressable? What do you think a cost per pixel element would be?

Mine or MPH's?

MPH's nodes will be around $2/pixel and he and JEC are working on a protocol bridge between DMX and Asian Node Controller Protocol. (for lack of any better term...)

I'm really hoping to get below $2/node at moderate quantities although it's going to be very tough. $2.50 shouldn't be hard at all. Read back through the thread to see some of my rough early calculations, however it looks like I'm going to have to take either a 20 cent/node hit for a larger microcontroller, a 25ish cent/node hit for connectors (with unknown long-term performance - I've seen some data that indicates tin-plated pin headers are reasonably corrosion resistant, but who knows what they'll really do?), or a node that can't be reprogrammed or easily repaired once assembled.

Right now, I have:
USB virtual serial to I2C bridge using a PJRC Teensy, not too reliable
Serial to I2C bridge on an Adafruit Boarduino, same protocol as above, but reliable
So far my test code is just a basic Python script

Planning on:
DMX-to-I2C bridge, hopefully supporting multiple slave device types (these nodes, NXP PCA96xx series).

One of the barriers right now is that the cheapest board house I've found in terms of cost per square inch has a minimum board size that kind of kills their cost advantage. :(

Matt_Edwards

01-24-2010, 08:33 PM

One of the barriers right now is that the cheapest board house I've found in terms of cost per square inch has a minimum board size that kind of kills their cost advantage. :(

this just means you have to design your board as a Scored panel and not individual boards.

Cheers
Matt

kychristmas

01-24-2010, 09:01 PM

Mine or MPH's?

...
One of the barriers right now is that the cheapest board house I've found in terms of cost per square inch has a minimum board size that kind of kills their cost advantage. :(

Couldn't you gang-up multiples on one board layout file? Of course, I don't know how they get cut into individual boards.

Kelly

David_AVD

01-24-2010, 09:19 PM

this just means you have to design your board as a Scored panel and not individual boards.

We've done that (V-grooved panels) before for some boards that were only 0.7 sq" in area each. Depending on how you design the board, you may be able to populate all parts while still in the panel. With ours, a connector hung over each end, so we do them in strips.

Prismalites

01-24-2010, 09:23 PM

this just means you have to design your board as a Scored panel and not individual boards.

Cheers
Matt

Of course I agree - just panelize the boards. Saves money to do it that way. No mass production , even on a short run, can benefit if you don't utilize that method.

Regards,

Jeff

Entropy

01-24-2010, 09:35 PM

this just means you have to design your board as a Scored panel and not individual boards.

Cheers
Matt

The vendor in question (Gold Phoenix, which seems to have great per-square-inch rates for their 100 and 155 square inch panels) has a minimum per-board dimension of 1 inch by 1 inch for panelized designs. They'll do smaller, but you get a maximum of 100 boards for their 100 square inch panels. (Actually... That might only be for their discounted-by-10-dollar service... They have two 155 square inch services that differ by $10 and one has that limitation and one does not...)

Olimex doesn't have a minimum board size when depanelizing, but are more expensive.

Gold Phoenix would be 36 cents/board without their minimum size restriction, Olimex 70 for DSQ service.

Prismalites

01-24-2010, 10:32 PM

aussiephil

01-24-2010, 10:37 PM

Planning on:
DMX-to-I2C bridge, hopefully supporting multiple slave device types (these nodes, NXP PCA96xx series).
:(

I have what is effectively a DMX to I2C bridge done as part of my Tiger controllers, would be simple to split off the Control section from the I2C stuff and add some IO.
I was going down this road but decided that i had more use for a all on one board solution this year with a 120ch LED controller being the result.

PM me if you wish to discuss possibilities...

Cheers
Aussiephil

Prismalites

01-24-2010, 10:59 PM

I have what is effectively a DMX to I2C bridge done as part of my Tiger controllers, would be simple to split off the Control section from the I2C stuff and add some IO.
I was going down this road but decided that i had more use for a all on one board solution this year with a 120ch LED controller being the result.

PM me if you wish to discuss possibilities...

Cheers
Aussiephil

Indeed! Freescale is a great start.

mrpackethead

01-24-2010, 11:30 PM

Mine or MPH's?

MPH's nodes will be around $2/pixel and he and JEC are working on a protocol bridge between DMX and Asian Node Controller Protocol. (for lack of any better term...)

And at any reasonable quantity they will be cheaper than that, 1000 nodes is about $1800 if i remember rightly.

The 'T2' box will provide a RS485 to pixel speak bridge. I say pixel speak, because it should drive quite a few different chip-sets with only software changes.
The output right now is SPI. But its quite possible ( i might need to think about this ), that the box could also drive I2C, without too much trouble. It is using a PIC24H which has mappable devices, one of which is a I2C.

The PIC24H Will let us drive up to 1Mbps input, so we can get a lot more data into it..

Racing to get this out the door, give us a few more days.

[EDIT]: The answer is definatively yes, i can map a I2C interface off the T2 box.

Entropy

01-24-2010, 11:56 PM

I think that you need to expand your Master dev. environment. So, I have been looking for something along these lines that might give you a bit more processing power on your front end. http://www.devasys.com/usbi2cio.htm. I will report what I uncover.

So far the ATMega168 seems to be pretty robust, and it has the RAM to handle DMX in and I2C out. I am 90% certain the glitching I'm seeing on my second node is a bug with the USI-TWI slave implementation - it's half software. Most importantly, it has enough SRAM to buffer an entire DMX universe internally.

Don't really need much more processing power than that. At the price of what you linked, I may as well go with a Digilent Basys2 or a Gadget Factory Butterfly. The Boarduino is $17.50 in single quantities, and the FTDI cable is another $20. USB Boarduino is $25, however a DMX solution would be best served by an ATMega168 + an RS485 adapter. It may prove cheaper for power than the Boarduino's regulator if I just cannibalize a DealExtreme USB charger - http://www.dealextreme.com/details.dx/sku.32206

Possible future project, likely not until 2011 due to too many other things in flight: Multi-universe (8+ universes easily) USB-to-DMX combining an AT90USB1286 and a Xilinx Spartan-3E. (Make a DMX output IP core for the Spartan, and expose the BRAMs in the Spartan with an interface identical to how AVRs interface with external SRAM.)

P. Short

01-25-2010, 11:37 AM

A bit off-topic (since this is DIY), but LOR seems to have things well in hand:

http://store.lightorama.com/cocori.html

tconley

01-25-2010, 12:25 PM

that was cool

tconley

01-25-2010, 12:30 PM

http://www.sebsz.com (http://www.sebsz.com/)What I am looking to do is something similar to the board listed above but i would like it to be 10x10 or better 15x15. I have a window in the front wall of my garage i was going to build a box designed to fit withing the window trim and then have the full color matrix running in the window. I was going to using lsp matrix animator to do some animations. For Halloween a eye may stare out and dissolve into a bat or a pumpkin. With the number of elements required for 10x10 or 15x15 i want to keep the cost down as far as possible per element.

Entropy

01-25-2010, 12:49 PM

In your case you might want to consider, depending on color depth needs and such:

One PCA9635 or TLC5940 per color (this avoids wasting the 16th channel of either if you use it in a 5-RGB configuration) - I've seen a few designs that do this

Rainbowduino - 8x8 matrix for $40 complete with controller, and can be seamlessly connected to adjacent matrices. If the Rainbowduino matrix is too small for you, you'll have to manually wire your own matrix and connect it to the controller ($20). It only does 12 bits/pixel - 4 bits/color.

chicken

01-26-2010, 03:26 AM

Just FYI, we built a 110' light-line tree down at Tanglewood Park in Clemmons NC this year
Prismalites, do you have any more pictures or video of the tree. Really cool looking. Good job.

Wene

01-26-2010, 07:09 AM

Hello

A bit off-topic (since this is DIY), but LOR seems to have things well in hand:

http://store.lightorama.com/cocori.html

I took one of this stripes with an arduino. I folded this stripe four times to get a pixel array.

Here is a first video of the array displaying running text.

http://www.youtube.com/watch?v=_fcX1LMd6Qg

Greetings

Wene

Prismalites

01-26-2010, 04:48 PM

Prismalites, do you have any more pictures or video of the tree. Really cool looking. Good job.

I do not intend or want to get off topic because that system -is- very different than Entropys project and can't be applied here but yes I will hunt up what I have and message you some more stuff when I get some time. One last thing - That project was a large one and took alot of time to finally get to a point that something could be done with it and it took alot of people to make it happen - definitely not just me - but thanks for the comment. It's the result of a third try to make large intelligent RGB trees using various RGB lamp technologies that I have been directly involved in applying for several years. I can give you more detail, but really we should keep that in another arena. Different animal / different architecture.

mrpackethead

01-26-2010, 09:37 PM

I do not intend or want to get off topic because that system -is- very different than Entropys project and can't be applied here but yes I will hunt up what I have and message you some more stuff when I get some time. One last thing - That project was a large one and took alot of time to finally get to a point that something could be done with it and it took alot of people to make it happen - definitely not just me - but thanks for the comment. It's the result of a third try to make large intelligent RGB trees using various RGB lamp technologies that I have been directly involved in applying for several years. I can give you more detail, but really we should keep that in another arena. Different animal / different architecture.

Thread for 'Really cool Megatrees' ---->

http://doityourselfchristmas.com/forums/showthread.php?t=10700

please post your pics and videos.

Entropy

01-27-2010, 09:14 PM

OK, I'm going to be sendng a board design to Olimex for a prototype batch soon. I originally said I'd hold off on posting a board design until it was tested, but I decided to put it up for comments first. Note, the attached board is UNTESTED.

A few notes:

I decided to go straight to SMD.

The main power/data header is a standard 2.54mm (0.1") header. It will be populated with a right angle header to permit testing/development with the board plugged into a breadboard, or connected to an IDC connector on a 4-conductor cable for initial multi-unit testing. (Also should be just fine for indoor/sheltered nodes.)

Since 4 of the 6 pins of the standard AVR ISP header are also on the main data/power connector, instead of a full ISP connector, I just have a two-pin header that adds the missing signals to save space.

I went straight to through-hole. There wasn't enough silkscreen room for the IC name, it's a Tiny25.

I'm still debating the footprint of the LED. To meet design rule limitations of Olimex, I had to increase the hole spacing beyond that of straight leads from the LED, so leads will have to be bent outwards a bit. I could also "sideways surface mount" the LED, which would have it face the correct way from the board (to the side) without bent leads, but it would be a pain to solder, since I couldn't just lay the LED down to solder it.

Before submission I need to figure out how to hide the silkscreen for the LED - Olimex doesn't like silkscreens that extend off-board-edge.

I'm considering using a larger value (1 uF most likely, I have the option of up to 10 uF in 0805) power supply bypass capacitor to keep the LED switching from causing weird things to happen.

Some documentation indicates the 10k pullup on RST isn't really needed due to an internal pullup except in electrically noisy environments - I gain nothing in board real estate by removing it so I'm going to keep it for now.

Edit: Just figured out how to make the board slightly smaller. BRD and PDF updated.

n1ist

01-28-2010, 07:37 AM

Entropy

01-28-2010, 07:48 AM

If possible, you may want to move that SMT cap from the backside - it's the only SMT there, and one more step if you ever go to reflow. Can it fit between the IC and header if you move those vias under the IC?
/mike

Good point. I'll check into that. I put it there to minimize trace distance between it and the uC power pins, but I've had AVRs do fine with far less bypassing, so if I increase the trace distance I'm guessing it'll still be OK.

Edit: WHOA. After moving the chip, it is more obvious that I think something is quite wrong with the Eagle footprint for the Tiny - Power and ground appear to be wired to pins across from each other, they are on opposite corners!

This is going to require some doublechecking...

Edit 2: Attached revised board with pinout fixed. Man that was a close one, thanks!

I'm probably going to move my projects to github soon, and rather than posting multiple attachments (waste of space) will likely just post links to tagged github versions.

Entropy

01-31-2010, 09:38 PM

Firmware update released, and the project source is now hosted at github.

http://github.com/Entropy512/I2C_RGB

budude

05-28-2010, 02:50 AM

Hey Entropy - anything new happening/planned for this? I'm still tossing around different avenues for LED drivers and I like the simplicity (well - perhaps perceived simplicity anyway :p) of this.

Entropy

05-28-2010, 02:27 PM

Hey Entropy - anything new happening/planned for this? I'm still tossing around different avenues for LED drivers and I like the simplicity (well - perhaps perceived simplicity anyway :p) of this.

I've had so much in flight lately that I haven't done much on it for a while.

However, I just got an ATJTAGICEII in (Arrow has them for $150 instead of the normal $300 in limited quantities) and I'm hoping that maybe debugWire support will help me track down the glitching. (plus it LOOKS like you can reprogram the device in debugWire mode, which means I can try fixes without having to disconnect the I2C bus to permit programming like I do now). Also, my Open Workbench Logic Sniffer finally arrived a week ago.

If I still don't make much progress on the "glitching" I'm probably going to migrate towards a 6-channel design using a Tiny48, which has a fullblown TWI implementation and not that pesky USI. The 6-channel approach would let me drive two "aussiephil/fathead" style RGB strands independently with a small cheap controller.

Because of the unresolved "glitching" I never went forward with getting a batch of prototype PCBs manufactured. Specifically, at this point the first device in my chain is rock solid reliable. The second unit in the chain will often blink to a color other than what I command it occasionally. The strange thing is that dropping the bus clock speed makes this issue *worse*, so I'm guessing it somehow has to do with the spacing between when the data is sent to the first light and when it is sent to the second. (I only have two circuits wired so far.)

I still am not going to have too much time for this - I'm behind enough on house shopping as it is, and without a house to light up I'm going to be really cutting back on the blinky flashy work. It's only been a month since I got the "all clear" to start on that (company had a round of layoffs a month ago), but the weather has been so nice lately I've been hiking and taking pictures a lot.

aususer

06-23-2010, 03:35 AM

I have a question... just ordered an arduino to play with (I am no programmer BTW) so started to look at I2C stuff..
and came across NCP5623 i2C RGB driver (http://www.onsemi.com/pub_link/Collateral/NCP5623C-D.PDF).

I've ordered a sample to see if it could be considered for driving one of the 200 RGB leds I bought in the recent group buy.
Looking at the datasheet, it seems to fit the bill OK..
and at (mouser)$AU1.30/500 (plus some sundry power components, R&C's and PCB) it might fit closer to the $2/node idea - at least for the individual lights in a string - and from what I see it is already addressed (yes, I haven't done any homework on this so probably wrong).

Pondering further:
I wonder if someone(?) could develop an E1.31 protocol convertor on (say) an arduino, with an 802.3 interface - and driver the I2C bus (with 170 devices).
Then use J1SYS's Vixen plug-in and drive it from vixen!
Might be an option rather than going down the DMX path?

Just floating ideas..

Tabor

06-23-2010, 04:45 AM

Aususer

I hope you have a very steady hand and a good microscope, those chips are tiny, 2mm square. :shock:

DynamoBen

06-23-2010, 10:35 AM

Pondering further:
I wonder if someone(?) could develop an E1.31 protocol convertor on (say) an arduino, with an 802.3 interface - and driver the I2C bus (with 170 devices).
Then use J1SYS's Vixen plug-in and drive it from vixen!
Might be an option rather than going down the DMX path?

I'm not sure how fast the arduino is. The hard part is getting data out off the network and onto the device as least as fast as DMX. So I would argue if you can do DMX you should be able to do E1.31 (E1.31 has additional data in its payload so there is more parsing to be done). Check out the WIZNET 5100 boards, $20 and it handles the TCP stack for you.

dmcole

06-23-2010, 01:35 PM

I'm not sure how fast the arduino is.

FWIW, the high-end Arduino chip is an ATMega328, which Atmel claims has "20 MIPS throughput at 20 MHz," achieved, of course, through an off-chip crystal/oscillator. There are a lot of code examples for the Arduino *sending* DMX-512 at 250k bps and at least one for it *receiving* DMX-512, though after about a month of trying I have yet to have gotten it to work.

\dmc

DynamoBen

06-23-2010, 01:45 PM

Entropy

06-23-2010, 01:54 PM

FWIW, the high-end Arduino chip is an ATMega328, which Atmel claims has "20 MIPS throughput at 20 MHz," achieved, of course, through an off-chip crystal/oscillator. There are a lot of code examples for the Arduino *sending* DMX-512 at 250k bps and at least one for it *receiving* DMX-512, though after about a month of trying I have yet to have gotten it to work.

\dmc

Using the Arduino development environment or just Arduino hardware and AVR-GCC?

The Arduino dev environment is known to have some pretty nasty performance inefficiencies in some areas. (Like changing pin states - apparently that's something like a 20x performance penalty, or at least was.)

I'm planning on using (unless I encounter a problem) an ATMega168 (my Boarduino is an older one...) clocked at 16 MHz (Arduino standard clock rate for XX8s) to do DMX-to-I2C. I just haven't started that aspect yet as I'm waiting for RPM's DMX dongles from his group buy to ship. So the design should be fully compatible with Arduino hardware (although Arduinos with onboard USB-serial likely won't work unless you can disconnect the USB-serial, since DMX would go into the serial port.)

I'll have to take a look at that I2C controller chip linked above. I do plan on doing some PCA9635 work in addition to the AVR-based dimmer nodes.

Edit: That NCP5623 chip, while promising in terms of some features and its price ($0.82USD at quantities of 500, sweet!), it has one minor and one critical flaw that make it unsuitable for DIYC apps if I am reading the datasheet correctly:
(Minor) - Only 5 bits/channel dimming.
(Critical) - Fixed I2C address of 0x39, limiting its use to one device per I2C chain.

For the rest of the post, prices are in USD:

For reference, as of June 2010, ATTiny25s (original design target of this project) are $1.02 each in quantities of 500 and $1.03 each in quantities of 100

ATTiny48s (possible retarget of my project) are $1.19-1.21 each in quantities of 100, and seem to be the cheapest AVRs that have full hardware I2C, and in fact seem to be the second cheapest AVRs with enough I/O and any form of I2C capability after the Tiny25. They have enough I/O to support a second RGB LED and likely a third per unit. PCA9635s are actually cheaper but don't have logarithmic dimming capability and require the address to be set with physical connections to the chip. (No way to program address into an EEPROM.)

dmcole

06-23-2010, 02:14 PM

Using the Arduino development environment or just Arduino hardware and AVR-GCC?

I'm using the Arduino development environment ... the project in question is at http://blog.wingedvictorydesign.com/2009/03/20/receive-dmx-512-with-an-arduino/

As you can see from my comments on that site, the problem (not confined to just me) is just getting the guy's code to compile ...

\dmc

aususer

06-23-2010, 06:53 PM

And that - folks - is why you guys get paid the big bucks!

I refer to my post: "(I am no programmer BTW)"..
I chose the Arduino not for this project... but as part of another project i am working on (nothing to do with blinky-flashy... another hobby).
It was just while I was looking at projects for the arduino, that I came across this (http://theducks.org/2009/05/arduino-rgb-ethernet-light/) which got me thinking... one thing led to another.... yadda yadda yadda.

Tabor: good spot, I truley didn't notice the size :D like I said... didn't do a lot of homework on it (but of course, anything is possible given time and money!) :D

From my quick skim it appeared a nice component; a search over DIYC!=result so I posted ;)

I think Entropy nailed it - if it is hardcoded with 1 address.. you would have to work around switching that address (found a post here (http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1214338541/0) saying
"No all you need to do is to switch the I2C data line through an analogue switch, such as a 4066, to direct it to the device you want. The clocks can all be commoned up. In that way you can have as many devices as you like on the same address."
so there is always "a way", but adding components starts to potentially defeat the purpose..

Oh well... it was just an idea.. thanks for the clarification (and no flame for the noobie!) - its what makes this a great forum..

Entropy

06-28-2010, 09:59 AM

Small status update:

It appears that even when unloaded, my USB-TTL cable is only putting out 500 mV on the Tx line now. (Should be +5v high!) It may have been on its way out before, which might explain the periodic glitching.

To work around this until I get a replacement, I had my master (a Mega168) start generating an up/down ramp internally and then send that out. Not a single glitch since then, but instead sometimes the master just hangs. Thanks to the JTAGICE and debugWire, it appears that it's freezing in a loop where it waits for an I2C operation to complete. Whether this is a master problem, or a slave problem angering the master, I won't be able to tell until I can catch it on a scope or logic analyzer. (By the time I see it, the bus has returned to an idle state.) The next few weekends are going to be crazy thanks to family visits and a wedding so not sure how much progress I'll make for a while.