A DMX controller for multiple RGB pixel strings

**n8huntsman** · 08-20-2011, 04:23 PM

Yep. Everything is back to original setup. So the lesson is, spt wire is not good for the clock or data wires on pixels. I'm debating on whether I should change the other one too even though it's working. If it aint broke, don't fix it?

**mschell** · 08-20-2011, 04:36 PM

SPT runs parallel for awhile on long runs, and for data, would be fairly easy to induce signals for the clock/data lines, especially if run along side of power feeds. Cat-5 twisted pair would be much better, since even unshielded, the wire twists help with not allowing interference.

But who knows exactly what was causing the problems in your case.

Glad you got it worked out.

**jstjohnz** · 08-21-2011, 07:53 PM

Attached is the latest E680 firmware file and a screen shot of the web page. This is version 2.20. Changes in this version:

Fixed bug re swapping of clusters 2 and 3 when using TLS3001 pixels on v2.17.
Fixed bug re bad value displayed for pixel refresh rate on v2.17.

Status of last get firmware attempt is now shown on web page.

A new command has been added for dynamic memory page selection based on the value of a specific DMX channel. The command is DP n, where n=0 to disable dynamic page selection, or 1-512 to enable this feature. Note: It is recommended to use channels 511 or 512 as these are never used by pixels. The control channel is always in the first universe. When this is enabled, the DMX value being sent on that channel will cause a specific memory page to be loaded. The page loaded is the DMX value/32. More documentation on this feature will be forthcoming.
Note: after installing this firmware you may have to do a DP 0 command to force dynamic paging off as it may come up as a random value.
Note: If you enable this feature without properly setting up all of the memory pages, you will probably get unexpected results.

The web server mode is now displayed on the web page as a character string rather than a numeric value.

The "No Data Timeout" feature is active. This value is set with the NO n command, where n=0 to disable, and n=1-999 to enable. When enabled, if no data is received on any dmx socket for nnn seconds, those channels will be turned off.

Some test patterns are now implemented. This should help users test their boards without having to have a source of e1.31 data. The command is
TE n, where n is 0 for off, or >0 to select a test pattern. At present 6 test patterns are implemented. 1-3 are all channels full on RED, GREEN, or BLUE, respectively. Test patterns 4-6 are a chase where a single full on pixel chases through a background of dimmer pixels.
After loading this firmware, you may have a random value for the test pattern. Use the command TE 0 to force it off, otherwise no pixels will light.

A new line has been added to the web page that displays the current memory page number (0-7) and a warning if changes have been made but not saved.

I would appreciate it if anyone with a prop tool would load this version and let me know if any issues are found.

**pmcpa** · 08-21-2011, 08:26 PM

Just loaded it onto one of my boards... Load was fast, Web server seems to respond EVEN FASTER. Will test on some strings in a little bit. Thanks again jim! Looking good!

**pmcpa** · 08-21-2011, 11:27 PM

Tests work... As a note, and I think this is a cause of the way the GECE are constructed, TE1 is Red on 2801's but Blue on GE's, TE2 is Green on both, TE 3 is Blue on 2801's, but Red on GE's (Same goes with TE4-6)

As Jim Noted, First thing you should do is TE 0, after I loaded the firmware, it showed Test Pattern: É5

**jstjohnz** · 08-22-2011, 12:28 AM

Originally Posted by pmcpa

Tests work... As a note, and I think this is a cause of the way the GECE are constructed, TE1 is Read on 2801's but Blue on GE's, TE2 is Green on both, TE 3 is Blue on 2801's, but Red on GE's (Same goes with TE4-6)

As Jim Noted, First thing you should do is TE 0, after I loaded the firmware, it showed Test Pattern: É5

Hmmm, I'll have to check into that one. I assume the pixels light up the proper colors normally (ie RGB mode properly configured)? The test pattern routine is just dumping data directly into the dmx buffer so I'm not sure why it's not working.

**budude** · 08-24-2011, 03:30 AM

I received my 1809 pixel strings today and connected them up to the E680 using 12v on the bottom DC block (j1-9) and connecting the strips to J1. I configured them as follows:

Cluster# Strings Chip Pixels Grp Str Len RGB DMX Address Range Reverse Zigs Null Pixels Refresh Gamma
1 1 1804(S) 150 001 0150 BRG s1-001 thru s1-450 NNNN 0000 0-0-0-0 0055

These show BRG on them so I configured them that way (this does not matter anyway for my issue).

When I plug the strips in, all 150 pixels (5m string) go full on white - no matter what I do or run, they stay full on. I initially started with Vixen and switched to SACNView to generate/view the data and I can see the packets received on the E680 - but nothing... I tried another string to verify - same thing. This was working with my GE lights just fine. I also loaded the new eeprom image 2.020 but that made no difference. I also tried the test patterns - nothing... I then moved it to cluster #2 putting them on plug J5 - nothing...

Any ideas here? These did not light up until I configured the pixel/string parameters and did a save 0 so it's not like a dead short or anything.

**TimW** · 08-24-2011, 05:08 AM

Brian there are 2 1804 chiptype configurations - which one to use depends on whether the pixels are manufactured to run in 'fast' or 'slow' mode. Try setting the chip to the other one (I think its type 3?)

**scuba** · 08-24-2011, 08:06 AM

Back from a long hiatus; Has anyone worked with the G-35's. As a start, I've got 200 pixels and a E680's. I want to control 4 strings of 50 pixels from a single E680. Has anyone used the controller that comes with the strings as power supplies for the strings? I was going to tie all the G-35 controller grd's together and separate the data lines and feed them to J1-J4. Any issues with this approach?

**mschell** · 08-24-2011, 08:32 AM

Brian,
I would suggest loading the latest firmware as well - not that it makes any difference for your 18xx strings, but for the test pattern generation. I was struggling with my setup and not getting pixels to light up at all. Due to some wiring issues, I wasn't sure it was Vixen/SACN/LSP or my setup. Having the test pattern generation allowed me to correct the wiring issues without worrying if I was sending the right data.