Late 2011 GE Color Effects + Arduino thread

[jwhite]

Hi Folks,

So a number of us in the Twin Cities maker group are interested in driving a mess of the GE Color Effects lights in order to backlight the glass block windows in our building, the Hack Factory. The GE lights are perfect for us; their spacing exactly matches the glass block windows and everything. And about 6 strands would work nicely for us.

Sadly, I failed to read this thread:
http://doityourselfchristmas.com/for...mp-exploration
until just now, or I might have ordered a Propeller Proto Board USB and used darcos very nice .spin file.

But instead, we had an Arduino at hand, so suddenly everything looked like an Arduino problem :-/.

So I wrote some overly fancy code to theoretically let me drive up to 6 strings simultaneously on a little old Amtel328. In reality, the code ends up being gated on 115,200 baud, and the truth is I'll likely only ever drive 1 string at a time. But it was fun to write, and in theory, now I can write anything, even a Tetris wall.

*But* As I've played with this, I cannot squeeze out a few random glitches. A whole lot of googling suggests that others have experienced similar issues.

Occam's razor suggests it's my code that's broken; clue bats welcome. In fact, I'm more convinced of that now than when I started writing this post.

If anyone is interested, you grab an arduino and hook the signal line to pin 8.
The code is here:
https://github.com/knitfoo/geled
I'm a command line junky; I use a Makefile to build both the .hex file and a command line utility to talk to the Arduino (drive).
make && make upload
./drive --init --verbose
./drive --cmd=132 or ./drive --cmd=130
both will run long patterns with occasional glitches.

You can in theory fiddle with the timing in led.h (if the code works, that is) - I need to get a protocol analyzer hooked up to see if it actually works as claimed. Fiddling about hasn't really left me feeling I know the best timings.

Has anyone learned more about these bulbs in the last 9 months? Timings? Anyone know the IC inside 'em so I can look up a data sheet?

Cheers,

Jeremy

[Materdaddy]

Awesome first post, especially since I'm (a) a command line junkie myself, and (b) starting to work with GECEs. I just picked up a few sets today and came on DIYC to post a question about these strings just now.

Unfortunately my post is completely unrelated to yours, so I will start a new thread.

Welcome to DIYC and when I get things going I will likely look at your code. I have already "watched" it on github. Good luck with the smarter minds from DIYC on getting to the bottom of your problem.

[firstone]

Your timing is interesting. I've just finished coding small Arduino program to control multiple GE light strings.

One feature I have that I haven't seen is that is you can control multiple wires at once, using port registers rather than writeDigital function. So you basically get 8 string for the price of one. While I haven't actually tried controlling multiple strings at once, the code seems pretty stable at this point.

I have an animation that basically dims the light to 0 brightness, back to 0xCC to some intermediate color, dims to 0 again and back to 0xCC to a permanent color. And it iterates through each light like that until whole string changes color. So there are tons of commands being sent. So it glitches occasionally, like some light get wrong color. But in general, it's pretty stable. A code that I got from this site (and started with) glitches a lot more.

Also, I can adjust brightness in larger steps than 1 and it seems to work fine. Haven't had any issues yet.

I also have Animator framework that allows independent control of multiple strings. Not the easiest to use or debug but can potentially create cool animations.

I'm just putting finishing touches on it, fixing all bugs and need to add licensing comments to the files. I will then release it to the public if anybody is interested.

In a long run, I'm planning to add control by ethernet. My custom protocol first and perhaps E1.31 later if I can figure it out.

[P. Short]

First of all, I'm a purist about these sort of problems - they must be hunted down and eliminated. Too many times over the years I've been bitten hard by not tracking down these sort of issues as soon as possible. The problems will get worse and trouble you at the worst possible moment.

There is another possible source of problems, namely signal integrity issues. By this I'm referring to signal ringing due to reflections, ground bounce, etc. These become important as the time that it takes a signal to travel down the wires becomes comparable to the rise/fall times of the signals. Take a look at the signals going to the strings with a good high-speed oscilloscope, and especially look for ringing on the edges of the clock and data signals. You will probably need a 100MHz scope or faster, and high-bandwidth probes as well. Most of people on this group have probably never had to deal with these type of problems (there may be a few exceptions), so you may need to look elsewhere for advice if it turns out that this is part of your problem.

But do keep looking for code problems. Even if it is a code problem, looking at the electrical signals with an oscilloscope may be useful.

P.S. figure that the signals travel about 1 foot/ns, so you need to start being concerned with signals with a 5 ns rise time when the wire length approaches 2-1/2 feet.

[ags0000]

@Phil - agree on most (or all) fronts. Fix the bugs early before building more on top. Easier said than done, though. I'm working through issues on a design myself, and have decided to build a *real* PCB to rule out the parasitic (SI) issues you mention. I'm pretty confident that eliminating my rat's nest of wires with up to 20MHz clocks should fix things.

Even at triple speed, the bit-period of the GECE light protocol is 5uS, so I don't expect issues along the signal line driving the lights (@200kHz). But I could be wrong.

I need to "upgrade" my Rigol 50MHz scope to run at 100MHz so I can look at those signals...

[P. Short]

It is (usually) not the bit period that matters, but the rise and fall time of the signals. You mention 20 MHz clocks. If the rise and fall times of the signals are scaled to operate at 20 MHz, you would probably end up with rise/fall times below 10 ns, which could lead to a greater possibility of SI issues.

I'm not familiar with the strings in questions. Are the clock and data signal regenerated in each node? If not, the SI problems can become quite a difficult problem.

[firstone]

The problem with Arduino specifically seems to be a low timer resolution. That is, you cannot precisely measure the delay even to a usec level. For instance, the a command to set pin to high takes 0.5 usec. This would warrant a delay of 9.5 usec, which cannot be done. In fact, "micros" command has resolution of 4 on Uno. delayMicroseconds seems to have higher resolution but I don't really know what it is.

One way to deal with it would be to loop with some command with known nsec timing I guess until correct number of usec is hit. But that would very unportable and likely not very precise.

But, like I said, I think I was able to figure out the timings to be pretty stable. I'd estimate reliability of 99% or higher in my tests.

I'm kinda excited about Arduino Due though. I think (hope) faster clock will mean higher resolution and more stability.

[ags0000]

@Phil - OK, point taken. I don't have spec's or schematics for the nodes. They are self-clocking (only a data line) and they are addressable through enumeration. I am presuming that the data signal is regenerated and forwarded on by each pixel, but can't say for sure.

@firstone - I am using a Propeller and have been able to reliably drive many strings without any bulb glitches (until recently, when I added a bunch of stuff and a rat's nest of wiring and shift registers and ethernet and entirely refactored code...). I suspect that the lights are reliable and robust in function, it's just a matter of getting the timing right.

[P. Short]

@ags0000 - I suggest that you consider a four-layer PCB design with power and ground in the middle layers. If that isn't practical and you must use a two-layer design, try to place all of the non-ground signal traces on one layer and use the other layer for a ground plane. This may be hard in particular to accomplish with SMT parts, and is still not as good as a 4-layer board. But it should help a lot.

[ags0000]

@Phil - for this point in development I prefer to stick with the two-layer board for cost reasons (and since they may end up as coasters). I plan to submit the layout for review & comment by the experts here, and will hope that you can critique it as well. I'm planning on using through-hole devices.