My first foray into RGB Christmas lights was with the “GE-35 Color Effects”. Quite a community was aligned to them, starting in 2010. It was based around removing the official controller and replacing with an Arduino or similar.
The great thing about them is that they are outdoors certified, and there is a nice long distance between each bulb. The downside is that there are actually only 4096 colours.
As most of my light patterns are now FastLED, I was wondering how I could make these another supported type? (I would attempt this myself - I’m not expecting anyone else to do it)
But is anyone (@Mark_Kriegsman / +Daniel Garcia - I’m looking at you!) able to roughly point out the approach I should take, which modules to hack, or even if it’s possible!
The protocol looks simple enough. I wonder how many people would switch libraries, since most folk who want to do this are already using that (nice looking) library? Does GE still make and sell these?
It is a simple protocol, but it’s an odd fit for FastLED which usually expects to update all pixels per pass. I’m sure it’s possible to base the controller off the clockless design that’s already there, but I don’t have the template-foo to do it.
810us per-pixel , and you thought ws281x’s were slow (at 30us per pixel).
Because those leds separate out intensity and rgb values from each other getting that to mesh nicely with fastled’s scaling/color correction would be another ugly piece for supporting these leds.
I don’t think the clockless would be a good place to start, the avr clockless code is mostly asm, and based on a world where delays are measured in clock cycles, the protocol for these leds measures delays in microseconds.
I’m happy to add it to the list for eventually supporting - but there’s at least two (if not three) hardware platforms on the list first, and I’m starting to look at supporting 12 and 16 bit per color value pixels (where these are only 4).
As for where to start to try implementing it yourself, you’d need to make a subclass of CLEDController, and provide implementations for all the methods in there.
The other thing you could do would be to use the FastLED color/math functions to do your patterns but then directly call the G35 functions to set the leds once you have rgb values for each led.
Hi @Daniel_Garcia , where is the near final point where an RGB value is sent to the chosen chipset driver?
To answer other points raised here - I wasn’t particularly thinking of getting it added as an official supported chipset, it was more just for me to do a personal hack, so I could use the same base pattern code for all my lights.
Not that I actually do this (my wife would divorce me), but these lights are great for large outdoor displays:
When you call LEDS.show, that is what steps through the controllers and calls show on each one. Each controller is the. Responsible for stepping over its set of rgb data and writing it out.
Hi Mark, any luck with this? I rewrote the sowbug code to use the timer to send the pulsetrain. Works pretty well. Adding G35 to FastLED seemed like a natural - and I’m glad I stumbled on to this thread.
Daniel, thanks for your guidance to Mark, I’ll see if it works for me.
Hi Clint. I gave up and went the other way. I got led strings where you could put on changeable covers/diffusers. I do have fond memories of those G35 and have kept them in case I ever have a garden big enough.