RGB Mega-tree, How big will yours be?

[smeighan]

I just saw this video
You are not allowed to view links. Register or Login

I am going to challenge myself to be able to do at least half of the effects shown here with the tool i am building, You are not allowed to view links. Register or Login.

One thing i noticed, around 3:33 into the video, is that the tree looks to be at least 64 strands of lights.

Does anyone know if there has been a performance test for lag between LOR, LSP, Xlight and Vixen as it drives more and more strings of RGB? What would be a practical upper limit for my design. The tool can handle 64 strands now, i just dont want to generate that much data.
If the tree in this video was 64 strands with say 127 pixels, i would have 8128 channels in Vixen, 24,284 channels in LOR (one channel for each R,G,B).

Is there any design specs i should know about for the upper limits of LOR,LSP,Vixen,Xlights? I assume there would be multiple E1.31 controllers for something like this.



Thanks
sean

[smartcontrols]

Hi Sean,

Your work is looking good.

First thing that struck my eye in your post was your example channel count for Vixen.
For 64 Smart Strings at 127 nodes each, run in Vixen 2.1 would require 24,384 channels.
(64*127*3) = 24,384

Vixen 2.1 can handle over 60,000 channels using the EtherDongle.

My mega tree planed for this year will be 96 Smart Strings at 88 nodes each. That gives me 25,344 channels for it.

-Jeff

[smeighan]

Thanks Jeff;

Since i have not started Vixen,LSP or LOR on my desktop i am just using the vix,msq and lms files as input. Thanks for the input.

For the poll i would want the number of pixels (nodes). So in your case it would 8448 (96x88). I will calculate the needed channels for each LSP,LMS and LOR.

So when i build a 25,344 channel xml file for you, is there anything i might need to do to improve performance? In LOR, their time quantum is 10ms (centisecond). If i set 5000 channels to turn on , i believe there is a delay in LOR. I will experiment with LOR with maybe dividing the pile of work due to be activated and spreading it across a few centiseconds.

It may be better at the higher channel count to slave a couple PC's, each with an E1.31 or something. Does LSP,LOR or Vixen allow making a master and some salve computer(s) to drive large displays? Or is this not going to be needed because they can output 1000's of channels in a few milliseconds?

Since i have no hardware , i am not sure the performance lag with high channel count.

thanks
sean

[Steve Gase]

Vixen 2.1 can handle over 60,000 channels using the EtherDongle.

A single EtherDongle can only do 16384 channels.  If you have 2 EDs, they will be mirrors of the other.

At some point, multiple EDs will be able to coexist with different channel assignments, but RJ will need to give us new firmware and possibly a configuration utility.

In the meantime, you could use a single ED and combine it with USB dongles to get your channel counts higher.

I think I saw a mention of EtherDongle using 5mbps at 50ms refresh.  But the way that the protocol is designed there should be no slowdowns or dropped timings.

[smartcontrols]

Vixen 2.1 can handle over 60,000 channels using the EtherDongle.

A single EtherDongle can only do 16384 channels.  If you have 2 EDs, they will be mirrors of the other.

At some point, multiple EDs will be able to coexist with different channel assignments, but RJ will need to give us new firmware and possibly a configuration utility.

In the meantime, you could use a single ED and combine it with USB dongles to get your channel counts higher.

I think I saw a mention of EtherDongle using 5mbps at 50ms refresh.  But the way that the protocol is designed there should be no slowdowns or dropped timings.

Ooops,
that was my typo. should have been over 16,000 channels.
Steve, Thanks for catching that.

[smeighan]

I think I saw a mention of EtherDongle using 5mbps at 50ms refresh.  But the way that the protocol is designed there should be no slowdowns or dropped timings.

Hi steve; i was not as concerned about the speed of the ethernet dongle as the performance of the software driving it.

I believed i will get my tool to eventually read a video file and output the rgb values to the matrix of pixels that are in a target.

In Jeff's case, 96 strands, 88 nodes each = 8448 nodes. If i wanted to update at 30 fps that would = 253,440 nodes being updated each second.

If the software needs to output to 3 channels for each R,G,B this would be 760,320 changes/second.

Does LSP,LOR, Xlights or Vixen have a performance close to 1 microsecond? It comes back to my original question, what is the fastest rate of change that i could expect from the Software/hardware package?

We can use less pixels(nodes), dont modify every pixel each frame,  a slower frame rate. But as we go into new RGB territory here, we are probably going to hit limits. Massive RGB targets are going to stretch the norm of what we currently have.

thanks
sean

[smartcontrols]

The current software separates their sequencer from the scheduler (player).  For schedulers we also have xLights.I believe it can play LSP, LOR or Vixen files. Last I heard was that xLights is hardcoded at 50ms and limited to 4096 channels. I am not sure that is still true. Or what changes will be made to it this year. He does good work and is always adding to xLights.

I think many of us, as I know I am, are betting on the conductor to be released to be able to handle these sequences. It is not out yet so there are few details about it yet.

If not one of those 2 than I would expect something else would come out that can read these sequences and produce the high channel count at the speeds needed.

It would be disappointing then, if any new tools for sequencing where again the limiting factor.

Just my 2 cents.
-Jeff

[smartcontrols]

Just a few years ago, I joked that someday I would have as many channels as I do bulbs and would be able to control every bulb on my house individually. People laughed about how much wire that would take.

I never dreamed I would have 3 times as many channels as bulbs and be able to make any of them any color I want.

So what should you support. I don’t know. There has to be a limit to something some where. Then someone will come along and change the limit again.

-Jeff

[Steve Gase]

If the software needs to output to 3 channels for each R,G,B this would be 760,320 changes/second.

My understanding...  DMX protocol works by shipping the entire state of the lights with each packet.  You have 512 channels on DMX, and all 512 are sent with each 'refresh'.  I haven't looked at the protoco definition, but I've heard of one special byte that is used to start the packet.  The data consists of one byte per channel -- the byte represents the intensity of the channel. 0=off, 255=full, 127=50%, etc.

So... any communication problems can instantly be corrected with the next packet of 512 channels.  The packet is resilient, though not error free.  this is an improvement over LOR that only communicates changes in the levels.

This means that the communication is done at a predictable/constant pace -- with little delay between channels... though I am not quite sure of that in my own analysis. 

What does DMX have to do with pixelnet?   I understand pixelnet to be highly-leveraged, changing timings (shorter), and the number of channels (512 becomes 4096), but the basics are the same.

The fixed channel counts give you predicable performance.

The refresh rate can be adjusted in LSP and other tools, but for Lynx the recommended (required??) rate is 50ms.  So, instead of 30fps, Lynx works with 20fps.  Going faster would adjust transmission timings and would introduce errors over the cable lengths used by most displays.  At 50ms/20fps there is enough of an error margin built in that poor cables, or long cables will still work reasonably well.    I don't know for certain that you couldn't do 25ms/40fps.

Understand too, that some installations may use wireless, and it may have its own limitations on the bytes/sec available to pixelnet traffic -- especially if 16384 channels (4 universes) are updated at 50ms...  is there enough bandwidth to double the rate?

Someday I'll have to read the specs to provide more accurate responses -- but to do that would be to step over a line and make this more like work, and less like a hobby.