Go Down

Topic: Programming GE ColorSafe lights on a Yun (Read 2245 times) previous topic - next topic


Dec 02, 2013, 07:34 am Last Edit: Dec 02, 2013, 08:18 am by thombrooks Reason: 1
I've been running some GE ColorEffects ('G35') RGB xmas lights on my house for a year or so now. We turn them on for holidays and I've have to re-load the onboard program every time I wanted a different set of patterns.

I had hoped to use the Yun for this (at least I can load new programs over Wifi, mission accomplished) but of course, it goes beyond that... because it's so tempting to want to do MORE, because the Yun is capable of so much more!

So here's what I came up with:

- Enabled cron, and wrote python scripts which use astral / python-dateutil / pytz  to figure out when sunset will happen today, then python-crontab / croniter to modify the start time of the script which turns the lights on at the best time.

- Using python 'gdata' module to look at a public google calendar I created, and I post 'special events' on that calendar on holidays. The body of the event contains a code, like XMAS, USA (4th of July) or halloWEEN, etc. which corresponds to different patterns of lights to play back.

But of course there are a few problems, and I would appreciate any advice folks can give me...

- I can upload a normal light control sketch to the board, but when I try combining with any kind of Yun bridge client stuff to communicate with the Linino side, it's getting hung up. The light control stuff is very timing-sensitive, it talks to each individual bulb on the light strings using a 1-wire kind of bus and has to vary the on/off timing pulses it sends. So I am not sure how to handle this better.

I looked at the trial version of 'arduino for visual studio' by visualmicro.com but it seemed to slow down the arduino too much with the debug overhead, which also messed up the attempts to debug this code.

- I am running out of space when only loading one set of light patterns (just my Xmas stuff plus the overhead for Bridge client and parsing my commands eats up 94%+ of the 28k.)

- The light patterns are all programmed (based off of sowbug's libraries, which in turn are based off of work by deepdarc and others who reverse-engineered the G35 protocol in the first place) and it takes a long time to write new patterns.

Instead I have been thinking about sequencer programs like Vixen (Windows only), or OLA / QLC  and similar.

I am wondering if I could run a process on the Linino side which would basically pick a file off of the SD card to 'play back' at a certain rate, sending the light control events to the Arduino side, which would then basically be a receiver that would translate openDMX (or whatever protocol) into the command format understood by the GE ColorEffects lights.  That would solve my issues of running out of space, and of having to write code for different light patterns. I'd just use a sequence authoring program on my computer, save a file and then load it on cue.

However this method would require a pretty fast baud rate, I think the openDMX stuff needs ~250000 baud. I have seen a couple of threads where people have talked about disabling the bridge communication between the Arduino and Linino sides and just using that connection as a more dumbed-down, high-speed serial bus. However I'm not sure whether that would be fast enough to support this idea.

Any helpful thoughts or pointers would be appreciated!


I've been working on something similar.  I have run into a problem trying to read enough data fast enough over the Bridge.  I have seen some mention of problems with 270 character limits or so.
I am rigging up an 8x25 LED matrix of the the 25 light G35 strings.
I wrote some very finely timed code on the Arduino side that writes all strings in parallel.  Haven't tested it on the lights yet, but looks great on my oscilloscope.
Then I started experimenting with how to actually get some cool Internet-based interaction and have run into some limitations on the data transfer rate between the MCU and the CPU.


I looked at the trial version of 'arduino for visual studio' by visualmicro.com but it seemed to slow down the arduino too much with the debug overhead, which also messed up the attempts to debug this code

The "slow down" is an optional feature for newer users who attempt to debug in the loop() without adding breakpoint conditions or a hit counter.

In the Atmel Studio project properties you can set ThrottleEnable=False and the Arduino will run at full speed.

This is documented in the debugger wiki found here

There is also a free Arduino debugging forum here

Arduino for Microsoft Visual Studio Pro and Atmel Studio 6.1 http://www.visualmicro.com
Arduino Debugger http://www.visualmicro.com/post/2012/05/05/Debug-Arduino-Overview.aspx

Go Up