Jump to content
Did you know?
  • The original Rudolph did not have a red nose. In that day and age, red noses were seen as an indicator of chronic alcoholism and Montgomery Ward didn’t want him to look like a drunkard. To complete the original picture, he was almost named Reginald or Rollo.
  • The Christmas wreath was originally hung as a symbol of Jesus. The holly represents his crown of thorns and the red berries the blood he shed.
  • The three traditional colors of most Christmas decorations are red, green and gold. Red symbolizes the blood of Christ, green symbolized life and rebirth, and gold represents light, royalty and wealth.
  • Tinsel was invented in 1610 in Germany and was once made of real silver.
  • The oldest artificial Christmas trees date back to the late 1800s and were made of green raffia (think grass hula skirts) or dyed goose feathers. Next the Addis Brush Company used their machinery that wove toilet brushes to create pine-like branches for artificial Christmas trees that were less flammable and could hold heavier decorations.
  • ‘Jingle Bells’ – the popular Christmas song was composed by James Pierpont in Massachusetts, America. It was, however, written for thanksgiving and not Christmas.
  • Coca-Cola was the first company that used Santa Claus during the winter season for promotion.
  • Hallmark introduced their first Christmas cards in 1915.
  • The first recorded date of Christmas being celebrated on December 25th was in 336, during the time of the Roman Emperor Constantine. A few years later, Pope Julius I officially declared that the birth of Jesus would be celebrated on that day.
  • Santa Claus's sleigh is led by eight reindeer: Dasher, Dancer, Prancer, Vixen, Comet, Cupid, Dunder (variously spelled Donder and Donner), and Blixem (variously spelled Blixen and Blitzen), with Rudolph being a 20th-century inclusion.
  • Outdoor Christmas lights on homes evolved from decorating the traditional Christmas tree and house with candles during the Christmas season. Lighting the tree with small candles dates back to the 17th century and originated in Germany before spreading to Eastern Europe.
  • That big, jolly man in the red suit with a white beard didn’t always look that way. Prior to 1931, Santa was depicted as everything from a tall gaunt man to a spooky-looking elf. He has donned a bishop's robe and a Norse huntsman's animal skin. When Civil War cartoonist Thomas Nast drew Santa Claus for Harper's Weekly in 1862, Santa was a small elflike figure who supported the Union. Nast continued to draw Santa for 30 years, changing the color of his coat from tan to the red he’s known for today.
  • Christmas 2018 countdown has already begun. Will you be ready???
  • Why do we love Christmas? It's all about the traditions. In this chaotic world we can miss the "good old days." Christmas reminds us of that time.
BrightChristmas

Rgb Pixel Array Success

Recommended Posts

I am new to RGB pixels this year and had almost aborted the plan to include them in the show this year. But after some tinkering, head banging, more tinkering, and testing, I've got a working solution that I thought I'd share.

Back story: I've been an LOR user for a number of years now. Couple hundred channels using super strings on most everything. I love the stability of LOR (there are a few quirks, but for the most part I can trust it to run the show for days on end). And I was comfortable with it and like the changes that have been coming. I also wanted to use RGB pixels this year, but knew that it would be a challenge to get them to work natively with LOR. So, I bought LightShow Pro when it went on sale. It seemed like it could do what I wanted, would import my LOR sequences, and would interface with the E681 controllers I was using. *BUT* LSP would crash anytime I tried to push it or even if I just wanted to add a controller sometimes. LSP has promise, but IMO isn't up the reliability standard that LOR has accomplished.

So, now I've got a box of RGB pixels, some nice E681 controllers, LSP, LOR, and look into the xlights program as a means to get E1.31 out of LOR. Surely I can make something work with all of this, right? Well, turns out you can!

My first obstacle was I wanted to make a RGB pixel array (matrix) for showing video. I had enough pixels to do a 16x33 pixel array on my garage door (7' x 16'). I found that I could set up 528 RGB pixels in LOR or LSP fairly easily. And the LSP transitions would even let me apply that video to the matrix really slick. But when I went to export the LSP sequence to LOR S2 format and load it into LOR, the ordering wasn't compatible. LSP outputs the RGB channels with all of the red, followed, by all of the green, and then all of the blue. LOR (and the E681) needed them in RGBRGBRGB format. I knew I could use the tracks feature in LOR and create a track that was setup with all of the reds, all of the greens, etc... This became my LSP "paste" track. If you have a ton of time on your hands, you can do this manually. I opted to learn the channel mapping file format (it is plain ol' XML) and wrote a script to create the XML and paste it directly. This last part is merely a time saver, but not a requirement to make this solution work. The same script also created the hardware channel mapping and visualizer array for the channels.

Once the LSP transitions are created, I output the S2 format, load it into LOR, copy the channels, and then paste into the LSP "paste" track. Now, when I look at the RGB track, I see the correct RGB colors.

On the E681, I have each 33-light string on one of the 16 channels. Each 4 channels are on a single DMX universe of 396 DMX channels. I'm using xlights to map LOR controllers 0x81 to 0xE3 to DMX universes 1 through 4 -- 396 channels per universe. So, my xlights channel setup looks like:

LOR 2048 channels

E1.31 DMX multicast universe 1, 396 channels

E1.31 DMX multicast universe 2, 396 channels

E1.31 DMX multicast universe 3, 396 channels

E1.31 DMX multicast universe 4, 396 channels

Now the LOR files are huge (100MB for just a minute of 10FPS video). I used the xlights file converter and that seems to help out quite a bit. I also plan to use a more powerful i7 desktop machine to run the show.

It's not up and running yet -- still soldering the RGB strings to the extension wires and waiting for my i7 parts to arrive (and 528 rare earth magnets to arrive as well -- anticipating fun!), but I've used the config -- playing back my 200 LOR channels with the 528 pixel array and a few strings plugged into the E681 and it looks great so far! The only question is the reliability of the xlights player and scheduler. But, if E1.31 native support is added to LOR (please, please, please!) and it runs just as smooth, then I'll be able to eliminate the need to use xlights.

I'm hoping to have this all running for the week before Christmas so my "regulars" will get a new surprise when they come back this year :)

Share this post


Link to post
Share on other sites

"First Light" video of the array on our Facebook page: http://www.facebook.com/video/video.php?v=2748646510853 Just a couple color splashes and a few seconds of snow falling "video" at the end.

Had a couple strings that seemed to have some signal integrity issues even though all of the runs are the same length (about 15'). Trimmed them down and they all work well now. xlights is working really well with the new i7-based desktop, but I will need to rework my LOR network.

I have 202 channels on a single USB to RS485 dongle running native LOR. I noticed that xlights was bandwidth constrained when there were big light changes that resulted in perceivable sweeps across the mini trees, for example. So, I'm pulling out all of the EasyLight linkers (even though they are at 57.6k baud now) and have updated the firmware to run in DMX mode (with the change in xlights network to run DMX). I'll see if that helps. If not, I also went ahead and ordered the Enttec DMX USB Pro and it should arrive later this week.

Share this post


Link to post
Share on other sites

This is interesting to follow. Thanks for posting for us RGB newbies to learn from. One question I do have so far. What do you think the Enttec Pro will accomplish?

Share this post


Link to post
Share on other sites

Hi, Jeff,

I'm not sure what the frame rate is for xlights and I wasn't sure what the frame rate would be out of the LOR USB to RS485 (DMX) dongle, so I figured the Enttec would provide the best-case scenario to getting well-synchronized channels with smooth fades (for DMX).

I did come home tonight, pulled all of the EasyLight linkers out of the network, updated all the controller firmware to support DMX, and reconfigured my channel mappings to support multiple networks. Loaded up my test song in xlights and it works fairly well. So well, I went ahead and threw together a profile and xlights is running the show (sans pixel array until those sequences are updated) tonight.

I can tell that the LOR adapter in DMX mode is working as a DMX device (other than the obvious settings in xlights) because the fades are not smooth like the standard LOR protocol allows. Instead, you can tell they stagger up and down fairly fast. I wouldn't probably even notice if it wasn't for the 99%+ LEDs in the show that show any changes in intensity without averaging them out in a heated filament. It's only mildly noticeable because I'm looking for it. We'll see if the enttec allows a faster rate that is no longer noticeable. It might not, if it is updating at the maximum rate that xlights is trying. I can also test with LOR to see if it is any smoother.

Share this post


Link to post
Share on other sites

I'm curious if there is a performance difference. I'm running an Enttec Pro for a number of Lynx Express controllers. Now I would like to perform a side-by-side test to see how it compares to the USB485B in DMX mode or the USB485B adapter using the LOR protocol.

I would expect for the price that the Enttec pro should perform well but I really wonder what the difference really is.

Share this post


Link to post
Share on other sites

I'm curious if there is a performance difference. I'm running an Enttec Pro for a number of Lynx Express controllers. Now I would like to perform a side-by-side test to see how it compares to the USB485B in DMX mode or the USB485B adapter using the LOR protocol. I would expect for the price that the Enttec pro should perform well but I really wonder what the difference really is.

I'll definitely keep updating this thread with the results.

To summarize so far:

This is all running on an i7 2600K desktop -- about as much horsepower as you can put into a show these days so none of the results should be CPU constrained. Instead, they will be hardware (adapters) or software (by design) constraints.

Using LOR:

* USB485B in LOR mode: Smooth fades (performed internally by the controllers themselves). Well-synchronized transitions across many channels (200+).

* USB485B in DMX mode: Ratcheted fades (barely noticeable during slower fades due to the use of LEDs). Well-synchronized transitions across many channels.

* Enttec Pro: TBD

Using Xlights:

* USB485B in LOR mode: Noticeable stepping in the fades. Slow synchronization across many channels -- resulting in perceivable "sweep" transitions.

* USB485B in DMX mode: Similar to LOR. Ratcheted slower fades. Well-synchronized transitions across many channels.

* Enttec Pro: TBD

Enttec Pro testing TBD to determine if ratcheting effect of fades can be reduced.

Share this post


Link to post
Share on other sites

I will be interested in your test. I have 8 pipes setup with 4 Lynx Express controlling them. I would like to perform the test below but we are getting too close to Christmas to mess with things.

1 USB485B running LOR with CTB16PC

1 USB485B running DMX with Lynx Express v5

1 Lynx Express Dongle with Lynx Express v5

1 Enttec Pro with Lynx Express v5

Because these pipes are 8 channels each and are within 14" apart the fading differences should be very noticeable if they differ.

Share this post


Link to post
Share on other sites

Kind of late since you have already solved your problem, but the E681 can accept the RGB channels in any order and transpose them to any other order using the RGB command.

Share this post


Link to post
Share on other sites

Definitely! Tell them to wait until closer to Christmas. I start my two weeks of vacation this weekend so I'll have some time to finish up the RGB elements and get them worked into the show by Christmas weekend.

Share this post


Link to post
Share on other sites

So i am currently saving for LOR and been buying RGB flood lights and strings so you telling me LOR doesnt control RGB? or is there a better controller for RGB? RGB and Fairy LED's ive been stocking up. so would you recomend me continuing to get my LOr 4 controllers, or get something else?

Share this post


Link to post
Share on other sites

Depends on how your RGB flood lights are driven. LOR can drive DMX and DC (through their DC controller board). But it doesn't drive E1.31 which is DMX over ethernet -- used by Jim's awesome E680 and E681 controllers. You can use the free xlights player to play LOR sequences and have it remap LOR channels to practically any hardware, including E1.31. In my show, in addition to having two E681 controllers running 671 independent RGB nodes, I have 15 LOR controllers running about 190 channels -- had more channels until they were replaced with RGB nodes ;)

Share this post


Link to post
Share on other sites

Updated results.

I have the Enttec Pro installed and running the LOR controllers (15 of them). Originally, when I had the LOR USB485B running in DMX mode, I was having controllers not come up and so I abandoned it that night. When I switched over to the Enttec Pro, I also installed a 120-ohm terminator on the last controller and they have been working flawlessly. So, I'm not sure if it was the USB485B or the lack of a terminator, but given that the combined cable run is probably around 200 feet, I expect the terminator was critical.

As for the ratcheted fades using xlights, I'm still seeing this. I pulled the xlights source code and started modifying it to try to reduce the ratchet. I could make it worse by increasing the time between DMX updates, but trying to reduce it from the default 50ms didn't seem to help. DMX512 should go to about 20 to 30ms, but setting it to 25ms didn't seem to help much. This could be a Windows limitation since I expect xlights is using the Windows timer -- I may look into this more later, but I'm happy enough with the results and stability, that I'm going to leave it alone for this season.

When I was tinkering around with xlights, I modified the output to adjust the blue channel down by 50% to all pixel nodes. My show uses warm white LEDs in the super strings and the RGB pixels are definitely a cool white. Setting the blue outputs to 50% produces a better white to mix with the warm whites. Jim, I'll send you an email, but this may be a nice feature to put into the E68x.

Jason

Share this post


Link to post
Share on other sites

Jason-

For the stepped fades you're seeing, it looks like you're seeing the stair stepped issue when using DMX on your LOR boxes, but not when using LOR native protocol on your LOR boxes - am I correct? We aren't talking about the E680 / E681 controllers with the issue, correct? I wonder if what you're seeing is the actual "digital" stair step of the 8-bit output in DMX. I'm supposing that the LOR protocol may have a smoothing process occurring in the output stage of the controller? When operating in DMX mode, I bet that's not possible, so you're actually seeing DMX values changing, for instance, between 31, 32, 33, 34, 35, etc. over a slow fade. If that is the case, you'd get the results you're describing - no change with faster refresh rates, and worse performance with slower refresh rates.

I've noticed the same thing driving a couple of LED strands using DMX on the LOR boxes this year. I also see it in the pixel nodes I'm running as well using the smart string controllers, etc. It's not "bad", but I'd love to get smoother fades on the LED lights at the lower end of the brightness scale, but some larger changes on the higher end of the brightness scale.

Share this post


Link to post
Share on other sites

Alan, you are pretty much right. To get a fade out of an LOR controller over DMX, you have to send rapid DMX changes. DMX has a finite speed and frame rate, so it is expected you will see some graduated changes. The LOR controllers have intelligence built in so you only have to send a single fade command over the LOR protocol and then the controller does all the fade work on its own.

What I was curious in discovering was whether it was due to the DMX frame rate limitation, the PC horsepower, the software, or some other limitation. My hunch is that it is between the DMX bandwidth and software (xlights). And I expect xlights due the use of the wxTimer class which will have a low resolution (slow) timer on the Windows platform. You can reprogram the timer interval on Windows to get higher resolution, but defeats the ability to use xlights on multiple platforms.

At this point, I'm happy with the results and will stick with it as-is.

Share this post


Link to post
Share on other sites

I would be surprised that you could see any noticeable change in fades of DMX vs LOR with DMX running 44 frame changes per second. I would really like to see a side-by-side comparison. Technically there may be a difference, but I'd like to know if you can visually see the difference.

Share this post


Link to post
Share on other sites

You can visibly see the difference. While DMX can do 44 frames per second, if the software is only sending 20 frames per second (the default in xlights), you'll see it. I'm not sure what frame rate LOR is sending its DMX commands since the source code is not publicly available.

Share this post


Link to post
Share on other sites

Alan, you are pretty much right. To get a fade out of an LOR controller over DMX, you have to send rapid DMX changes. DMX has a finite speed and frame rate, so it is expected you will see some graduated changes. The LOR controllers have intelligence built in so you only have to send a single fade command over the LOR protocol and then the controller does all the fade work on its own.

What I was curious in discovering was whether it was due to the DMX frame rate limitation, the PC horsepower, the software, or some other limitation. My hunch is that it is between the DMX bandwidth and software (xlights). And I expect xlights due the use of the wxTimer class which will have a low resolution (slow) timer on the Windows platform. You can reprogram the timer interval on Windows to get higher resolution, but defeats the ability to use xlights on multiple platforms.

Your experience with the differences between controller side fading using the LOR protocol vs the "host" side fading using DMX on an LOR controller is what I've documented:

http://vimeo.com/13703416

It's a bit "notchy" and seems to really be less than a full 8 bits.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...