collapse

* Chat

Refresh History
  • JerryPlak: Hey What!!
    January 21, 2013, 11:38:44 PM
  • Steve Lelinski: Why does this only show up on some pages?
    January 18, 2013, 08:10:03 AM
  • Steve Lelinski: I'm confused
    January 18, 2013, 08:09:57 AM
  • Cenote: Let's fill up Greg's PM box with Shout outs for Chat mod..
    January 18, 2013, 08:09:15 AM
  • Cenote: Great, my eyes are burning now
    January 18, 2013, 08:08:15 AM
  • Steve Lelinski: Look at this!
    January 18, 2013, 07:38:26 AM
  • Steve Lelinski: Hey!
    January 18, 2013, 07:38:23 AM
  • JerryPlak: they are Zzzzing
    January 17, 2013, 09:52:30 PM
  • Cenote: "is there anybody out there"
    January 17, 2013, 06:54:21 PM
  • JerryPlak: Burb
    January 17, 2013, 05:33:29 PM
  • ErnieHorning: What?
    January 17, 2013, 12:53:05 PM
  • Greg Jones: Test
    January 16, 2013, 11:18:05 PM

Author Topic: GE Color Effects Pixel Project  (Read 9129 times)

Offline Steve Lelinski

  • REGISTERED
  • Junior
  • ***
  • Posts: 761
  • Ouch!
    • The Twinkling House
    • Email
GE Color Effects Pixel Project
« on: February 07, 2012, 11:21:33 AM »
I'm sure you all saw the GE Color Effects lights on shelves this year.  You remember, the ones that were something like $3 a bulb?



I know a number of decorators snatched these up once they went on clearance.  This top post will be updated with a quick "hit list" of the key points learned thus far.

Some facts about these lights:
  • "Hackable" to obtain full RGB capability on each individual pixel
  • Can be controlled by SanDevices E68X controller
  • Color is 4 bit.  Slow fades look choppy
  • Weatherproofing is excellent
  • Maximum "hacked" string length is 64 pixels
  • V- is ribbed wire, Data is middle, V+ is smooth wire
  • Color order is BGR
 

Offline Steve Lelinski

  • REGISTERED
  • Junior
  • ***
  • Posts: 761
  • Ouch!
    • The Twinkling House
    • Email
Re: GE Color Effects Pixel Project
« Reply #1 on: February 07, 2012, 11:35:15 AM »
This post intentionally left blank to highlight questions and answers as the discussion grows.


Offline Steve Lelinski

  • REGISTERED
  • Junior
  • ***
  • Posts: 761
  • Ouch!
    • The Twinkling House
    • Email
Re: GE Color Effects Pixel Project
« Reply #2 on: February 07, 2012, 11:36:46 AM »
Introduction

It should be noted that I am not the first person to play with these, not by a long shot.  The DIY folks have invested a tremendous amount of time and effort, for well over a year, into making these things work in a computerized Christmas display.  Anyone looking to use these pixels owes the DIY guys a round of applause and a beer.

The purpose of this post is to harvest the work they've done, and related it to the "average" Christmas Crazy person.  Put another way, to move it away from the cutting edge and make it more accessible for those who want to add pixels to their display.  I'm not a technical guy when it comes to electronics.  My goal is to keep this simple: what you need to know to use these lights.  For that reason, I'm going to keep the top post updated with bullet points and other useful links for getting up and running.  Hopefully lively discussion will follow in the comments.  If it does, and we get some good technical explanations, I'll do my best to provide links in the top post.

Finally, I imagine this is obvious, but these are not the only pixels available to the Christmas decorator.  Far from it.  It's safe to say these also are not the "best" pixels to use in your display.  If you want to pay top dollar, check out the other solutions talked about on this board.  Many pixel solutions exist that are nearly plug and play.  For me, I was able to get these pixels at a cost of about 55 cents/pixel, including power supply, mounting clips, and shipping.  That's a decent entry point for me into pixels.  I know many others picked these guys up as well, and I imagine even more people will buy them next year.  This thread is intended to be a discussion of how these pixels work.  If we run up against a limitation of the GECEs, feel free to suggest another pixel that solves that problem.  However I don't want this thread to turn into a debate about which pixels are the best.  If that happens, I'll split it out into another thread.

Offline Steve Lelinski

  • REGISTERED
  • Junior
  • ***
  • Posts: 761
  • Ouch!
    • The Twinkling House
    • Email
Re: GE Color Effects Pixel Project
« Reply #3 on: February 07, 2012, 12:16:00 PM »
Programing Testing

Using the SanDevices E681 controller, I connected the a string of 24 bulbs and ran one of the per-programed test patterns:
http://www.youtube.com/watch?v=xdshc1dGOP4

The next step was to get it working with something a little more custom.  There's a great program called da_E131 by David from the Aussie forums.  You can find it here: https://www.audiovisualdevices.com.au/software/da_e131/index.php.  It basically a Hardware Test Utlity for E1.31 controllers like the SanDevices controller.  You can turn the lights on and off as a group or an individual channel.  You can also run chase sequences.  It's a great way to verify the lights are working and configured properly.  Anytime I have a problem, first thing I do is pull up da_E131 to verify my setup.

The next test was using a program called xLights to run an LOR sequence on the pixels.  xLights can be downloaded here: http://sourceforge.net/projects/xlights/.  This is another free program, it's by Matt aka dowdybrown at DIYLA.  Unlike other testers, this program can actually run your show.  It has a scheduler and can control multiple controllers, LOR, D-Light, Renard... and of course E1.31.  More on xLights later.  For now, I mapped the RGB portion of my MegaTree to the GECE pixels, and ran a sequence from last year's show:
http://www.youtube.com/watch?v=Gz1JOg2c9qw

Although it proves these can be used in a computerized display, this video points out the first limitation of these pixels.  Note the stepping on the slow fades.  This is due to the pixels 4-bit color.  You can work around it by doing fast fades, or using more of a wipe effect to turn the pixels off.  If you can't live with this limitation, these pixels aren't for you.
« Last Edit: February 24, 2012, 04:28:11 PM by Steve Lelinski »

Offline Steve Lelinski

  • REGISTERED
  • Junior
  • ***
  • Posts: 761
  • Ouch!
    • The Twinkling House
    • Email
Re: GE Color Effects Pixel Project
« Reply #4 on: February 07, 2012, 12:40:12 PM »
About the Pixels

Next, some basic info on the pixels themselves.  First, wiring:



This shows bottom of the pixel wiring.  With the pixel facing towards you, the power/data enters on the left, and exits on the right.  You can see the ribbing on the V- wire, and the writing on V+.  That's the best indicator.  The ribbed wire is V-, the center wire is Data, and the wire with markings (smooth) is V+

There were some mumblings out there about reliability problems due to moisture, so I wanted to see how the weatherproofing stacked up.



In the first picture, you can see weep holes built in to the bulb. There are four total, two at the top, two at the bottom. This should allow condensation to exit the bulb whether they're hung bulb up or bulb down.

The bulbs are on there nice and tight, but with a little force they do pop off. Inside, you can see the entire inside is potted! There's a clear plastic cover that sits inside the base, the green potting material is then poured in to seal it up. In the last picture, you can see some of the potting material leaked out at a gap. This gives me pretty good confidence that these lights are well sealed against moisture. Of course, there's only one way to be sure:

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

Yup, it still works completely submerged in water. Following this test, the pixel survived a 24 hour soak, followed by 3 days cycling: 8 hour freeze, 4 hour soak, 8 hour freeze... Capped off with one last 12 hour soak. Still ticking! ...I mean blinking.
« Last Edit: March 01, 2012, 04:17:31 PM by Steve Lelinski »

Offline Cenote

  • Junior
  • ***
  • Posts: 595
  • I don't care
    • Email
Re: GE Color Effects Pixel Project
« Reply #5 on: February 07, 2012, 12:59:12 PM »
Does david's test program put out the e1.31 protocol, or do you still need another interface for testing?
Chuck
--->Proud User of LOR, Rennard, DMX, DIO's, and ACL's
--------->2013 - a butt load of assorted hardware and software

Offline Steve Lelinski

  • REGISTERED
  • Junior
  • ***
  • Posts: 761
  • Ouch!
    • The Twinkling House
    • Email
Re: GE Color Effects Pixel Project
« Reply #6 on: February 07, 2012, 01:34:38 PM »
Does david's test program put out the e1.31 protocol, or do you still need another interface for testing?

The sole purpose of David's program is to test E1.31.  All you need to do is plug the controller into your network.  You will need to have the E681 (or another controller) properly configured first.

Offline Steve Lelinski

  • REGISTERED
  • Junior
  • ***
  • Posts: 761
  • Ouch!
    • The Twinkling House
    • Email
Re: GE Color Effects Pixel Project
« Reply #7 on: February 07, 2012, 02:12:51 PM »
Setting up the Controller

OK, lets assume you bought and assembled your E681 (no small task, but a fun one!)

Here's how you wire it to your pixels.  First, cut off that pesky stock controller.  (There's been some talk about preserving the manufactures warranty by opening up the controller and desoldering the leads.  Give it a try if that's important to you.)  Now lets look at the E681 controller:



As shown, the Power Supplies hook up to the two large screw terminals at the bottom.  Similar to an LOR controller, the terminal on the right (Banks 3 & 4) also supplies the board power.  Thus, a Power Supply must be connected to the right terminal.  If you're only using Banks 3 and 4, that's all you need.  If you're using Banks 1 and 2, you'll need to attach a Power Supply on the left as well.  The Power Supplies included with the GECE pixels are regulated, and work perfectly with the E681.  Alternately, you can use one large power supply, and jumper wires to power both sides, again, similar to LOR controllers.

Next is the pixel string connector.  These are removable screw connectors.  V- on the pixels goes to Pin 1.  Pin 2 is blank, Pin 3 is Data, and Pin 4 is V+.  If you forget, they're labeled below connectors 1-2 and 4-4.  Make sure this is right, you could damage your pixels with improper wiring!

Finally, the Cat5 Ethernet cable connects to the port at the top left.  But wait!  Don't power on yet, we'll want to configure the board first.

One note:  We'll get into this more later, but I want to mention it here.  If you're injecting power at later points in the pixel string, that power must be turned on before power is turned on to the board.  If turned on afterwards, you'll get some seriously psychedelic effects.

Configuring the Controller

First step, unplug all the pixel strings.  We want to have the settings right to avoid damaging the bulbs.  Now, power on the controller, connect it to your network, and type 192.168.1.206 into your browser of choice.  You'll see a page that looks like this:



There's a box towards the bottom that lets you send commands to the controller.  We're going to be typing commands there, and pressing enter to send them.

Commands work like this TEXT X, Y where TEXT is the command you're sending, X is the cluster number, and Y is the setting.  One important note: Any changes you make in pixel type, grouping, string length, or string number will not take effect until you cycle power on the board.  This is because the GECEs get their address assigned at power up.  Also, make sure to save your settings before powering down the board.  Do that by typing SAVE 0.

If you're looking to get setup quickly, sending the commands in bold from this point forward will get a test pattern running on a string of GECEs in socket 1-1. 

First, lets set it for the GECEs.  Type CHIP 1, 2 and hit Enter - You'll see the Chip type for Cluster 1 changes to GECE.  You can repeat this for all 4 Clusters if you only plan to use the GECE pixels.  At this point, it's safe to power down, plug in your pixel strings, and power back up.

Next, set the RGB order.  According the E681, the GECEs are BGR.  So type RGB 1, 5.  Again, this is a good command to repeat for all 4 Clusters.

Now set the number of strings.  Type STRING 1, 1 - You're now set up to run 1 string in cluster 1.  If you want to test with more than one, set it to the number you plan to test.  At this point, there's no harm in setting it for a higher number of strings than you're using.

Now for the number of Pixels.  Type PIXELS 1, 50 - Obviously your string may not be 50 pixels.  Again, there's no harm in setting it for too many pixels.  That won't matter until you start worrying about channel numbers.  The max Pixels for a string of GECEs is 64.  We'll get into why later.

This is a good point to save and cycle power to make sure your pixels are addressed correctly.  First type SAVE 0.  Cycle power, and when it come back up, type TEST 2 and you should see some green pixels.  It's a good idea to cycle through all the tests to make sure everything is set up correctly.

  • Test 0 - Test Pattern Off
  • Test 1 - All lights Red
  • Test 2 - All lights Green
  • Test 3 - All lights Blue
  • Test 4 - All lights 50% Red, with 100% Red chase*
  • Test 5 - All lights 50% Green, with 100% Green chase*
  • Test 6 - All lights 50% Blue, with 100% Blue chase*

*Of note with the chase patterns: The lights do not turn on at 50% until the chase has passed by them.  Also, it chase through 680 pixels no matter how many are actually connected.  So if you start a chase test, and see nothing, give it a couple minutes to cycle.

When you're done with the Test Patterns, make sure to set it to Test 0.  Finally, type Save 0 to save your settings.

Now you're ready to go.  The next post will go into a little more detail about some of the more important settings.
« Last Edit: February 08, 2012, 08:43:56 AM by Steve Lelinski ಠ_ಠ »

Offline Steve Lelinski

  • REGISTERED
  • Junior
  • ***
  • Posts: 761
  • Ouch!
    • The Twinkling House
    • Email
Re: GE Color Effects Pixel Project
« Reply #8 on: February 07, 2012, 02:57:16 PM »
More on the Configuration Page

The E681 Owners Manual does an excellent job of explaining all the settings in detail, starting on page 12.  In addition to the settings addressed above, here are some you'll likely wind up using at some point:

First, it's important to understand that most settings apply to the entire cluster.  With 4 clusters, you get 4 different setups.  Each string on a cluster must be setup identically with a few exceptions: PIXELS, REVERSE, and NULLS.  You can always have fewer pixels on a string than the controller expects.  So you can set PIXELS to 50, and have a string of 50, and three strings of 25 on the same cluster.  It's just using up channels.  More on REVERSE and NULLS later.

GROUP X,Y - This command sets pixels in groups.  For example, on a string of 50 pixels, you may only want to control them in bunches of 5.  Then you'd set GROUP to 5, and PIXELS to 10.  See how that works?  If you multiply the setting for GROUP by the setting for PIXELS you should get the String Length.  You'll see the Configuration Page does this calculation for you.  It's the Str Len column.  This setting also lets you control an entire string as a "dumb" RGB string.  Simply set PIXELS to 1, and GROUP to the string length.  For individual pixel control, set GROUP to 1.

ZIGZAG X,Y - Very useful for making matrices.  Say you have 36 pixels and want to make a 4x9 matrix.  The easy way to wire it is to start a the bottom, go up 4 pixels, down 4 pixels, up 4, down 4...  But the easy way to sequence it would be if the pixel number always went from bottom to top.  ZIGZAG lets you do both.  In this example, for a matrix on Cluster 2, you're type ZIGZAG 2, 4.  Now the number will be reversed every 4 pixels (So the string would actually be number 1, 2, 3, 4, 8, 7, 6, 5, 9, 10, 11, 12, 16, 15, 14, 13, 17...)

REVERSE, X,Y - Reverse is a useful setting, but one of the more confusing.  A reversed string, will start with the highest pixel number, and end with 1.  This is useful if you want to have the controller in the middle of your display, but keep numbering constantly from left to right.  As I mentioned, it's one of the few that do not apply to each string in the cluster.  As before, X is the Cluster number, but this time Y is a sum.  For the REVERSE command the strings have the following values:
  • String 1 = 1
  • String 2 = 2
  • String 3 = 4
  • String 4 = 8
Adding up the values will give you the sum to enter for Y.  So to have Strings 1 and 3 act normal, and Strings 2 and 4 reversed (on Cluster 1) the command is REVERSE 1, 10.  Think of it like a dip switch.

NULLS X, A,B,C,D - Nulls are useful if you have long leads from the controller to the first pixel on the string.  Typically, the signals will only travel about 15-20 feet.  Each pixel repeats the signal, down the line, which is why the total string length can be more than 20'.  So if you wanted to have a 50' lead to your first pixel, you might space out 3 pixels to repeat the signal.  Wouldn't it be great if we could not only never have these pixels light, but also have them not included in the channel numbering?  That's what NULLS is for.  This setting is set for each string in a cluster.  So NULLS 1, 0,3,2,0 sets Cluster 1, string 1 to 0 null pixels.  String 2 has 3 nulls, String 3 has 2, and String 4 also has no nulls.

Let's get into DMX and channel numbering.  Something important to understand.  The controller "thinks" there are only 4 DMX universes, numbered 1 through 4.  Obviously, that won't work if you have more than one controller.   The way it works is with the following set of commands:

UNIVERSE X,Y - This is allows you to assign a DMX universe to each "internal" DMX universe (called a socket).  A command of UNIVERSE 1,650 will assign DMX universe 650 to what the controller considers universe.  NOTE: X in this case, is not an assignment to a Cluster. 

DMX X,Y-CCC - The DMX command assigns the internal DMX universe to the clusters.  Y can only be numbers 1 through 4.  These are the same internal universes as described above.  CCC is the starting channel in the universe.  It can be anything from 001 to 510 (511 and 512 are never used).  Note I said starting channel.  The ending channel is determined by the number of strings, times the number of pixels, times 3 (for R, G, and B channels).  So if you have 4 strings of 25 on Cluster 1, and assign it DMX 1, 1-001 the last channel will be 300.  You can have more than one universe on a cluster, and you can have more than one cluster per universe.  With the example we just used, say Cluster 2 has the same setup, 4 strings of 25.  You could start it fresh on the next universe (DMX, 2, 2-001) and that may be the easiest way.  But if you're going to max out the controller, you'll want to start it where cluster 1 left of: DMX, 2, 1-301.  Now, obviously we're going to go past channel 510.  It will automatically roll over into the second universe.  So the last channel used would be 2-090.

UNIVERSE and DMX work in combination.  You'll use DMX to assign channels to the Clusters, and UNIVERSE to assign physical DMX Universes to the channels.  For example UNIVERSE 2, 300 followed by DMX 4,2-001.  When you're sequencing this, the lights plugged into Cluster 4 will have a DMX universe of 300, starting on channel 1.

Remember I said the strings don't really have to be the same number of pixels?  There's a little cheat you can do to avoid wasting channels in certain situations.  If you have 3 strings of 36 bulbs, and 1 string of 25, you can plug them all into the same cluster and still not lose any channels.  Make sure to plug the shorter string into the Socket 4.  Now, set PIXELS to be 36.  When you set the DMX assignments, you can "overlap" the wasted pixels.  Let's supposed we plugged these strings into Cluster 1.  Now, assign DMX 1, 1-001.  The last channel cluster 1 will use should be 432 (36*4*3).  However, we can start Cluster 2 with the first pixel that's actually unused!  In this case there are really only 133 pixels (399 channels).  So DMX 2,1-400 will have the strings on Cluster 2 pick up right where the pixels actually left off, no channels wasted.

There's a number of other settings I didn't get into.  I really do recommend you read the instruction manual linked above to fully understand this controller.  Hopefully what I've typed here is enough to help someone who's really not familiar with DMX and Pixels get everything set up for their display.
« Last Edit: February 07, 2012, 04:00:02 PM by Steve Lelinski ಠ_ಠ »

Offline Steve Lelinski

  • REGISTERED
  • Junior
  • ***
  • Posts: 761
  • Ouch!
    • The Twinkling House
    • Email
Re: GE Color Effects Pixel Project
« Reply #9 on: February 07, 2012, 05:53:31 PM »
Testing with da_E131

da_E131 is a great little program if your sequencing software doesn't support E1.31.  Written by David from the Aussie forums, it can be found here.

The main page is pretty self explanatory:


The key is the Settings page (found under view):


What's shown here is properly configured to run tests on Universe 1 on the E681.  Important things to note, the IP Host/Port must be set to Multicast.  The E681 does not support Unicast.  Universe can be set for a range, so if you want to test more than one, or aren't sure what it's set to, go ahead and open it up to a more broad range.  The only downside is the Chaser tests will be spending a lot of time testing channels that aren't there.

The RGB/Single tab will test the all pixels in an RGB mode.  This is a good place to play around and see what different colors you can create.  The Chaser and Fader tabs are testing individual channels.  So when you start a chase, each light should go Red, Green, Blue, and then on to the next pixel.  If you can get your lights working with da_E131, everything is setup properly on your controller, and with your network.

One issue I had when first testing.  da_E131 seems to pick a network card and use that one.  For me it picked my wireless card, but my controller was plugged into the wired network.  If your lights aren't responding, try disabling all network adapters, except the one your E681 is connected to. 

Setting up xLights

xLights is another great program for controlling these pixels.  This program by Matt/dowdybrown over at DIYLA can be downloaded here

When you start it up, you'll see the only option is to choose a directory.  This can be your LOR (or whatever) sequence directory, but I created a new one.  If you're going to use xLights to actually play sequences and run your show, all files need to be placed here.

Once you pick your directory, you can click on Network Setup.  That brings up this page:


Click the E1.31 button to bring up the window on the right.  The setting shown are what is needed for the E681.  The IP is set for Multicast, the Universe is 1.  To set it up to run Universe 2, use the IP 239.255.0.2, Universe 3 is 239.255.0.3 and so on.  Last channel is 512 by default, and that's fine for now.  Click "Save" and you're back to the main menu. 

If everything is set up right, you should be able to click "Lighting Test" to access xLights' hardware utility.


Notice the check boxes on the left side.  If nothing is checked, nothing will light!  For now, pick "All" from the Selection Mode: drop-down, and click on any check-box to activate all channels.  xLights has a few more testing options than da_E131.  Spend some time playing with them to verify that xLights can control your pixels.

Of course, the real reason we're installing xLights isn't just for the test panel.  It's to run a sequence.  We'll get into setting that up in the next post.
« Last Edit: February 07, 2012, 05:55:06 PM by Steve Lelinski ಠ_ಠ »

Offline Steve Lelinski

  • REGISTERED
  • Junior
  • ***
  • Posts: 761
  • Ouch!
    • The Twinkling House
    • Email
Re: GE Color Effects Pixel Project
« Reply #10 on: February 08, 2012, 10:33:50 AM »
Running a Sequence with xLights

The trickiest part of getting xLights to run your show is understanding how to convert LOR channels to xLights channels.  There are two key things to remember:
  • xLights assumes all LOR controllers are 16 channels.
  • xLights assumes all controllers are numbered in order.

So controller 01, channel 1 is xLights channel 1.  01-2 is channel 2...
On controller 02, channel 1 is xLights channel 17.

The formula is xLights Channel = (LOR Controller Number - 1) * 16 + LOR Channel Number.  Obviously, you need to convert the Hex controller number to decimal.

Say you use controllers 01, 02, and A0.  On controller 01, your xLights channels are 1-16.  For 02, it's 17-32.  For A0 it's 2545-2560.  (A0=160.  (160-1)*16+channel# = 2544+channel#)  Wow that's a lot of channels!

So what does this mean, well, in this example not too much.  To set this up in xLights, your Network Setup would look like this:


The key here is that last channel must be equal to (or higher than) the last channel you're using.  You'll still set the addresses on your LOR controllers to be 01, 02, A0.  It's just that xLights has to convert them to a numbered channel, which it will then convert back to a hex controller number when it sends out the commands.

Alright, lets complicate things a little.  What if you're using a Cosmic Color Ribbon(CCR).  That's 50 channels on one ID.  xLights can handle this, it's the same formula as above.  The catch comes in with the next controller number.  Say you have a CCR on Unit ID 01.  Then a regular LOR controller on 02.  xLights will map LOR channels 17 through 32 of the CCR to xLights channels 17 through 32.  But, it will also map LOR channels 1-16 on controller 02 to xLights channels 17-32.  So be careful!  Remember, xLights always thinks a controller is 16 channels, so if you're using something with more than 16 channels, make sure to leave enough unused unit IDs before your next controller.  In our CCR example, the lowest unit ID you could use for the second controller would be 05 (the 50 channels of the CCR use up IDs 01, 02, 03, and the first two channels of 04.) 

Setting Up LOR to Run the GECEs

With me so far?  Let's get back on topic for the GECEs.  First question, how do you set up your pixels in LOR?  You'll notice (in S3) you can set DMX Universes.  That seems like the logical way to assign channels to the pixels.  (And it may very well be the way to do it once LOR releases E1.31 support, time will tell.)  But if you're using xLight, that won't work.  The way to do it is to assign them as 16 channel LOR controllers.  LOR S3 has an easy way to do this.  Add a New Device.  In the Add Device window, from the Device: drop-down, pick RGB Device (Non-CCD).



Pick your "Base Unit ID" to be wherever you want to start.  Make sure that "Channels per Unit ID" is set to 16.  You can set up to 48 Channels this way.  Now remember, these are RGB channels, not pixels.  So 48 channels gives you 16 pixels.  You'll likely need to go back and add another RGB controller or two.  Clicking OK will create 16 RGB channels, spanning Unit IDs 01-04.  To add another 16 pixels, you'll want to have the next controller start on channel 05.  Another 16 and you'll start on 09, and so on.

When xLights maps your LOR channels to the E681 channels, it's going to go in order.  Say we wanted to have two strings of 25 pixels.  The first string would be channels 1-75 channels.  The second will be 76-150.  To make sure our LOR channels map correctly, String 1 will be Unit ID 01 channel 1, up to Unit ID 05 channel 11.  As nice as it would be to just start String 2 on Unit ID 06 channel 1, this won't map correctly.  String 2 MUST pick up where String 1 left off.  So the first channel of String 2 is going to be Unit ID 05 channel 12.  The last will be Unit ID 09 channel 6.

Setting up the E681 in xLights

Before we go any further, lets set up this example in xLights.



Pretty straight forward.  Time to complicate it a little.  When it comes to E1.31 networks, each line is one universe.  Consider this example.  Let's keep our 2 Strings of 25 the way they are.  Our E681 is set up with those two strings in the first Cluster.  Now we'll add 4 strings of 50 pixels each to Cluster 2.  One way to configure this, would be to have Cluster 1 be universe 1, and start out Cluster 2 with universe 2-001.  What this means is Cluster 2 will spill over into universe 3.  Don't worry, we can handle that.

Let's start with the LOR setup.  The two strings on Cluster 1 we'll setup just like we did previously.  Now, since the next group of strings are on a new Universe, we can start them anywhere we want.  This time we don't have to pick up where the last string left off.  So lets be really crazy.  Let's start the strings on Cluster 2 at channel B1. 

Ok, 4 strings of 50 pixels gives us 200 pixels, or 600 channels.  That's 38 controllers!  So starting with B1 channel 1, we'll end up with the last pixel on Unit ID D7 channel 8.

What would the xLights setup look like for this?



Lets look at the key setting here.  The Ports and Universes are pretty straight forward.  We set the Last Channel for Universe 1 to be 2816.  But wait, there are only 512 channels in a DMX Universe.  This setting is actually more about the next Universe on the list.  Universe 2 started with xLights channel 2817 (LOR Unit ID B1 channel 1 = (177-1)*16 + 1 = 2817).  To get Universe 2 to start at 2817, Universe 1 must end at 2816.

Next, the Last Channel for Universe 2 is 510.  Why not 512?  Each Universe can controller 170 pixels.  That's 510 channels.  Since we can't have 2/3 of a pixel, channels 510 and 512 are unused.  It's important to set this to 510 when maxing out a Universe because our LOR channels roll right on through sequentially.  Blue on pixel 170 is on Unit D0 channel 14.  Red for Pixel 171 is Unit D0 channel 15.  In order to make sure D0-15 goes to Universe 3 channel 1, we have to make sure Universe 2 stops at 510 channels.

Hopefully this all makes sense so far.  Of course, we're just getting started.  We've set up an xLights Network with just LOR controllers, and one with just an E681 controller.  Next we'll go through setting up a mixed network.

Before we move on, there are two on-line calculators I found useful in figuring out all these Unit IDs and channels.  There's a Hex to Decimal converter and a Decimal to Hex converter.  Use them wisely.
« Last Edit: February 08, 2012, 10:43:54 AM by Steve Lelinski ಠ_ಠ »

Offline Steve Lelinski

  • REGISTERED
  • Junior
  • ***
  • Posts: 761
  • Ouch!
    • The Twinkling House
    • Email
Re: GE Color Effects Pixel Project
« Reply #11 on: February 08, 2012, 11:25:05 AM »
Mixing LOR and E681 Controllers with xLights

Let's look at a semi-realistic set up.  Let's take our first example with LOR controllers 01, 02, and A0.  On the E681, let's put 2 strings of 25 pixels on Cluster 1, set to Universe 1.  In LOR, we'll sequence them as Unit 10 channel 1 through Unit 1A channel 6.  What would this look like in xLights?



Let's break this down.  We have 2 LOR networks, and one E1.31 network.  This is all about mapping channels to the right controllers.  LOR Network 1 has a last channel of 240.  Why?  Because the pixels start at Unit 10 channel 1, which is xLights channel 241 ((16-1)*16+1=241) (Wait... 16?  Remember, Unit ID 10 is not the same as Controller #10.  It's 10 in Hex, which is really 16.)  To get Universe 1 channel 1 to be at xLights channel 241, the first network must extend through channel 240.  Now, we have 150 channels for our 50 pixels.  That's pretty straight forward.  Next is the last channel of 2170.  Where does that come from?  Well, it's controller A0, which means the last channel is 2560 by the formula.  Except we used 240 channels on Network 1 and 150 on Network 2.  That brings it down to 2170.  It could have been anything larger than this number, but it must be at least 2170.

Man, if only there was an easier way!  Well there is:

Using Multiple LOR Networks

Click on the "LOR Sequence Channel Mapping" button in the Network Setup Window.



To this point we've assumed everything was on the "Regular" LOR Network, and mapped the channels accordingly.  A very useful feature of xLights, is the ability to use the Auxiliary LOR Networks to simplify mapping.  If you select Multi-Network it changes the way the Lighting Networks are mapped.  Everything on the regular Network will go to whatever controller is on line 1.  Aux A goes to Line 2.  Aux B to Line 3 and so on.

Let's look at our example from a Multi-Network standpoint.  We'll stick with controllers 01, 02, and A0.  But this time, we'll put our 50 pixels on the Aux A Network (Do this by selecting Aux A from the Network drop-down in LOR when adding the channel.)  Now, even though we used controller 01, we'll start our pixels on Unit ID 01 channel 1.  Multiple Networks allows us to do that.  The setup in xLights is a little simpler:



Now you'll see the LOR network comes first, because it's set up on the Regular network.  The last channel is 2560 to make sure it extends through A0.  The E1.31 network comes next on Network Aux A.  Wait... Last channel says 512.  Shouldn't it be 150?  Or 510?  It could.  Using Multi-Network, it doesn't really matter.  Only the first 150 channels will be receiving commands.  The important thing to remember with Multi-Network mapping, is that your non-LOR controllers must start on Unit ID 1, channel 1 for each Aux Network.

There is one small catch.  Remember our example of 4 strings of 50 pixels which spanned two Universes?  If you tried to add a Universe 2 E1.31 Network on Line 3, it would not properly map to those pixels.  Remember, Line 3 is mapping to Aux B.  This means, to setup more than one universe, you'd have to put the first 170 pixels on Aux A Unit 01 channel 1 through Unit 0B channel 10.  Then pixel 171 starts at Unit ID 1 channel 1 in the Aux B Network.  So the xLights setup would look like this:



Don't feel bad if you struggle with this.  I made that first screen shot of the mixed LOR/E1.31 Network 9 times because I kept screwing things up.  If you're having trouble, post your channel setup here, and we'll try to help you sort things out.
« Last Edit: February 08, 2012, 11:50:54 AM by Steve Lelinski ಠ_ಠ »

Offline Steve Lelinski

  • REGISTERED
  • Junior
  • ***
  • Posts: 761
  • Ouch!
    • The Twinkling House
    • Email
Re: GE Color Effects Pixel Project
« Reply #12 on: February 08, 2012, 12:08:16 PM »
More on Pixel Number, Grouping, and Null Pixels

This section gets slight technical, but I wanted to explain what's really happening on the pixels when you start using some of the different settings.

It's important to understand that no matter what you do with the configuration, the physical pixels will get numbered 1, 2, 3, 4, 5... and so on.  (I'll explain why this is important in the next post.)

Let's consider 1 string of 50 pixels plugged into Cluster 1, socket 1.  Starting at Universe 1 channel 001.

Obviously, if you set PIXELS to 50, GROUP to 1, NULLS to 0, you'll have a STR LEN of 50, and your pixels will physically be numbered 1, 2, 3, 4... 49, 50 (Technically 0, 1, 2... 48, 49 but let's pretend for simplicity).  The pixels will then be on channels 1-001 through 1-150.  Accordingly, you'd set up 150 channels in LOR, LSP, Madrix... to control them.

Now, if we change GROUP to 5, you'll see STR LEN goes to 250.  That's because to the E681, pixels means points of control.  So for a string of 50, in groups of 5, you'll want to set PIXELS to 10.  Now you'll have channels 1-001 through 1-030.  The physical pixels are still numbered 1, 2, 3, 4... 49, 50.  The difference is when the controller hears "Turn on Channel 1" it converts that to "Turn on Pixels 1, 2, 3, 4, and 5." 

Next, lets set GROUP back to 1.  And set NULLS to 10 (technically 10-0-0-0).  Now, the first 10 pixels won't light, so we really have a string of 40 active pixels, so we set PIXELS to 40.  Once again, the physical pixels will be numbered
1, 2, 3, 4... 49, 50.  Now, then the controller hears "Turn on Channel 1" it converts it to "Turn on Pixel 11."

Now, why is this important to understand?  We talked about the board being limited to controlling 680 pixels (or 2040 channels, or 4 DMX Universes.)  You can physically connect and control far more than 680 pixels if you're using Nulls and Grouping.  The limit is in the number of DMX channels the controller can comprehend.  With all pixels set to groups of 10, you could (theoretically) connect 6800 pixels, and have them all controlled by the board (in groups of 10).  Nulls also don't count against your channel limit.  So if you needed 10 Null pixels on each string, you could physically connect 840 pixels, and still have individual control of all non-null pixels.

Remember that I said, "theoretically" because here comes the bad news...

Offline Steve Lelinski

  • REGISTERED
  • Junior
  • ***
  • Posts: 761
  • Ouch!
    • The Twinkling House
    • Email
Re: GE Color Effects Pixel Project
« Reply #13 on: February 08, 2012, 12:08:36 PM »
Limitations of the GECE Pixels

These pixels have a maximum string length of 64 pixels.  If you try to control any more than that, things get pretty crazy.  Why is this?  Well, basically, the pixels just can't count past 64 (it has to do with binary).  Pretend you're like me, and can only count if you use your fingers.  1, 2, 3... 9, 10 and then you run out of fingers and have to start over.  So start over and keep going 11, 12, 13, 14.. stop.  How many fingers are you holding up?  4.  Well, the GECEs only have 64 fingers.  So when you tell a pixel to be number 67, it doesn't understand.  To the pixel, telling it to be 67 is the same thing as telling it to be 3.

What does this mean?  If you tried to connect a string of 100 pixels, and set PIXELS to be 100, you'd get some strange results.  Doing a chase of red through these pixels, you'd see right away that Pixel 1 and Pixel 65 light up red at the same time.  Then pixel 2 and 66... and so on.  Not only that, but they're flickering instead of being on solid.  Why is that?  Remember when doing a chase, the controller isn't just telling pixel 1 to be "On" it's telling all the other pixels to be "Off".  Think of it as the controller screaming out "#1, turn on!"  Pixel 1 hears that and says "Oh, that's me!" and turns on.  Pixel 65 hears it too and says, "Oh, that's me!" and turns on as well.  Now it keeps going through the list, "#2, off"  "#3, off"  Eventually is says, "#65 off" Once again, BOTH Pixels 1 and 65 say "Oh, that's me!" and turn off.  Hence the rapid flickering.

Oh course, once you got to pixel 37, it stops getting the doubled commands.  Pixels 37 through 64 will behave normally.

Some variations on this:  If you connect 25 pixels, but set the E681 PIXELS to 100, all 25 pixels will flicker.  That's because the controller is still sending out commands to pixels 65-100, which are being heard by the 25 pixels.  If you flip that, and connect a string of 100 and set PIXELS to 64, you'll see the flicker goes away.  However, pixels 65-100 will light whenever pixels 1-36 are told to turn on.

Remember what we discussed with Grouping and Nulls?  It plays into this limitation as well.  Group X Pixels cannot be more than 64.  Likewise, Nulls + Pixels cannot be more than 64.  Remember, the pixels are numbered 1-64 no matter what.  Don't fret too much though.  If you plug strings of 64 pixels into each socket, that's still 1024 pixels.  There's still plenty of room to take advantage of Nulls and Grouping to cheat the 680 pixel limit!

A Silver Lining?

Now, here's an interesting note.  Let's say you connected 128 pixels, and set PIXELS to 64.  What would happen?  Basically, pixels 65-128 would be copies of 1-64.  You wouldn't get any flicker, just have the pixels duplicated.  There really would be no limit to how many times you could do this.  You could connect 512 pixels.  Keeping PIXELS at 64, you'd end up with the pixels repeated 8 times.  I've been trying to think of a way this would be useful in a display, but coming up with nothing.  But maybe you've got a situation that could take advantage of this!

A big thanks to Tim Herberger for doing a lot of the testing that turned up this information!
« Last Edit: February 08, 2012, 12:35:20 PM by Steve Lelinski ಠ_ಠ »

Offline Steve Lelinski

  • REGISTERED
  • Junior
  • ***
  • Posts: 761
  • Ouch!
    • The Twinkling House
    • Email
Re: GE Color Effects Pixel Project
« Reply #14 on: February 08, 2012, 12:58:10 PM »
IGNORE THIS SECTION!  Info here is not accurate
Updated Power Injection Diagrams can be found here

Injecting Power

If you're familiar with some of the short coming of pixels, you'll know all about injecting power.  Basically, running on 5V DC, Voltage drop very quickly begins to take it's toll on the lights.  If you trust the manufacturer, each stock power supply is good for 36 pixels.  So any time you have more than that on a string, or have more than one string on a cluster, you'll likely need to inject power.

So first off, what does that mean?  Basically, the Data and V- lines need to be continuous throughout each string.  However, we can cut V+ line.  Cap one end, and hook V+ from a new Power Supply to the other.  You'll also need to cut into the V- line, and splice in V- from the new PS.  This diagram should explain what I mean:



Tim Herberger is currently doing testing varying the length, number of pixels, and wire size to determine when and where power should be injected, along with the maximum lead length without using Null pixels.  I'll update once we have some good numbers to share.
« Last Edit: January 08, 2013, 02:30:10 PM by Steve Lelinski »