Jump to content
Light-O-Rama Forums
EmmienLightFan

How to set this up in the visualiser

Recommended Posts

I am going to build a matrix that is 75x14 pixels, with an outline of 150 nodes around the edge. 

I have it set up in XLights, and I can do it in FPP (I am now testing out FPP to see what I should run my show with). 

I want to control it with a Pixlite 4. It has four outputs, obviously.

I want four of the fourteen lines on one, four on another, four on another, then three.

But I don't see how I can set this up, because the visualiser only allows 170 pixels per universe. 

The Pixlite can have pixels spanning multiple universes, but I know the visualiser can't.

Is it not at all possible to set this up?

Share this post


Link to post
Share on other sites

I know physically you can do that with that controller but it's not a good idea once you have more than one universe on an output your refresh rate goes down. I tried it myself with not so good results. I did my RGB arches all on one output and when anything in the sequence started going fast it couldn't keep up and got a little weird. Butt in visualizer you're just going to have to make several small custom matrix and put them next to each other. I wish the visualizer was is easy to use as X lights

Share this post


Link to post
Share on other sites
On 1/30/2016 at 9:34 PM, Ebuechner said:

I know physically you can do that with that controller but it's not a good idea once you have more than one universe on an output your refresh rate goes down. I tried it myself with not so good results. I did my RGB arches all on one output and when anything in the sequence started going fast it couldn't keep up and got a little weird. Butt in visualizer you're just going to have to make several small custom matrix and put them next to each other. I wish the visualizer was is easy to use as X lights

Do you mean the refresh rate in the visualizer itself or on the actual lights?

Share this post


Link to post
Share on other sites

jstorms, yes, the refresh rate on the pixels gets slower.

 

As for splitting universes in Visualizer.  No major problem, but you have to deal with the situation.  For strings that will cross universes, make two fixtures.  For example:

 

String 1 - universe 1, pixels 1 - 75

String 2 - universe 1, pixels 76 - 150

String 3a - universe 1, pixels 151 - 170

String 3b - universe 2, pixels 1 - 55

String 4 - universe 2, pixels 56 - 130

String 5a - universe 2, pixels 131 - 170

String 5b - universe 3, pixels 1 - 35

String 6 - universe 3, pixels 36 - 110

String 7a - universe 3, pixels 111 - 170

String 7b - universe 4, pixels 1 - 15

 

You should get the point from that without my typing all 14 strings, plus the outer 150.

 

Share this post


Link to post
Share on other sites
15 hours ago, jstorms said:

Do you mean the refresh rate in the visualizer itself or on the actual lights?

Actual lights. When I did mine Visualizer looked just fine it was the lights that had the problem. This might be a problem with the way light-o-rama handles the data. It may be different if you used X lights. I'm not sure but I think light o rama will send out the data for two full universes to the one output even though you might only use 30 pixels in the second universe. Which means you're waiting for it to cycle through 420 unused channels before it gets back to the start channel

Edited by Ebuechner

Share this post


Link to post
Share on other sites
3 hours ago, Ebuechner said:

Actual lights. When I did mine Visualizer looked just fine it was the lights that had the problem. This might be a problem with the way light-o-rama handles the data. It may be different if you used X lights. I'm not sure but I think light o rama will send out the data for two full universes to the one output even though you might only use 30 pixels in the second universe. Which means you're waiting for it to cycle through 420 unused channels before it gets back to the start channel

Each element in my yard is a seperate universe.  I have 3 bushes with 90 pixels each....2 bushes with 105 pixels each....my gutters with 50 pixels each....around my garage with 3 50 pixel strips...not to mention my LOR AC controllers, dc controllers and LOR CCRs.

i don't have timing issues.  And I am using universe 1 up to universe 23.  Not full universes....

If you are having timing issues with only 2 universes something else is wrong.

And the data for the lights should go out all at once...not sequentially. The data goes out to all connected lights and only the correct address picks it up and uses it.

Share this post


Link to post
Share on other sites
17 minutes ago, sax said:

Each element in my yard is a seperate universe.  I have 3 bushes with 90 pixels each....2 bushes with 105 pixels each....my gutters with 50 pixels each....around my garage with 3 50 pixel strips...not to mention my LOR AC controllers, dc controllers and LOR CCRs.

i don't have timing issues.  And I am using universe 1 up to universe 23.  Not full universes....

If you are having timing issues with only 2 universes something else is wrong.

And the data for the lights should go out all at once...not sequentially. The data goes out to all connected lights and only the correct address picks it up and uses it.

We're talking about when you have two universes of lights connected to one physical output. That forces a slower refresh rate due to the time it takes to cycle through the extra lights. 

Share this post


Link to post
Share on other sites

Here's the deal on refresh rate.  The E1.31 controller sends the data to the pixels as a serial data stream.  The more pixels in the string, the longer it takes before it can start over.  That reduces the number of times per second that the lights get new commands.  I did a little testing just now with a couple of idle ports on a SanDevices E6804 controller.  I changed the configuration of those ports, and observed the calculated refresh rate.  This chart is based on using WS2811 pixels - different pixels have different data requirements:

50 pixels - refresh rate of 245 times / second (4.08 mSec per refresh)

100 pixles - refresh rate of 123 times per second (8.13 mSec per refresh)

200 pixles - refresh rate of 62 times per second (16.13 mSec per refresh)

300 pixels - refresh rate of 41 times per second (24.39 mSec per refresh)

400 pixels - refresh rate of 31 times per second (32.25 mSec per refresh)

500 pixels - refresh rate of 24 times per second (41.67 mSec per refresh)

 

E1.31 sends a new data packet every 22 mSec, so for example if using a 50 pixel string, the string will get refreshed 5 or 6 times with the same data between each new packet of data.  With 300 pixels, the E1.31 controller will not have completed sending out the previous packet of data when a new one arrives.  The result of that is that some packets will get dropped.  The result of that is fast action may either get dropped or delayed unevenly.

 

BTW, I mentioned that different pixel technologies have different data requirements - generally that means either a different data rate or different number of bits of data to be sent.  This results in different refresh rates for different pixel types.  I tried several pixel types for a 50 pixel string on my E6804 with these results:

WS2811 = refresh rate of 245 times per second

GECE = refresh rate of 20 times per second

LDP6803 = refresh rate of 267 times per second

WS2801 = refresh rate of 212 times per second

16716 = refresh rate of 164 times per second

LPD880x = refresh rate of 2 times per second

981x = refresh rate of 2 times per second

TLS3001 = refresh rate of 81 times per second

DMX = refresh rate of 160 times per second

RENARD57K = refresh rate of 26 times per second

And yes, on the LPD880x and 981x, that is not a type, it really is two - and I thought the GECE lights were slow!

 

 

Share this post


Link to post
Share on other sites

I think DevMike and others refer this as pixelpacking, and is somewhat controller dependant ie; to use LOR software, and Sandisk controllers(e682, 6804) you have to use pixel packing; somewhat of a pain but necessary for dmx/e1.31 on these controllers

 

Jim, thanks for the data rates, makes a big difference on what pixels you use

Share this post


Link to post
Share on other sites

Who told you you have to use pixel packing on  a E682.  I have 3 E682's don't use pixel packing at all. You could but you make it sound like you have to .

Share this post


Link to post
Share on other sites

Jim

Thanks for the Pixel comparison,  that should help people decide which pixels they want to use.  Interesting results

Share this post


Link to post
Share on other sites

The original poster is not using a Sandevices controller, but rather a Pixlite 4.  Since the controller has only four outputs, he plans on having four strings on each output, which DOES force packing.

 

Share this post


Link to post
Share on other sites

The WS2811 pixels running at high speed mode have a data rate of 800K bps.  There are 24 bits per pixel.

The PixCon16 blasts these bits out in a really tight stream, but has a very long reset signal between streams.

The Sandevices E681 has a bit more time between bits - and takes about twice as long to send the same amount of bits out as the PixCon16, but has a much tighter reset between pulse trains - 65 micro seconds.

Edited by wbaker4

Share this post


Link to post
Share on other sites
26 minutes ago, Grinch said:

Jim

Thanks for the Pixel comparison,  that should help people decide which pixels they want to use.  Interesting results

You're welcome.  Frankly, I was astounded at how much variation there was between pixel types.

The only ones I use are WS2811 and GECE.

 

Share this post


Link to post
Share on other sites

k6ccc how are you measuring the refresh rate? Frequency counter or scope

Share this post


Link to post
Share on other sites
18 hours ago, Dennis Laff said:

Who told you you have to use pixel packing on  a E682.  I have 3 E682's don't use pixel packing at all. You could but you make it sound like you have to .

DevMike I believe a while back at the class in Fort Worth; I think it's the way I have my lights and display setup, ; for instance, my pixel tree is 16 rungs by 50 pixels each, using one e682 controller; I couldn't figure out anyother way to do it.  Is there another way?

 

 

Share this post


Link to post
Share on other sites
14 hours ago, Ebuechner said:

k6ccc how are you measuring the refresh rate? Frequency counter or scope

 

The SanDevices control interface tells you whenever you change pixel configuration.

 

Share this post


Link to post
Share on other sites
47 minutes ago, wmilkie said:

DevMike I believe a while back at the class in Fort Worth; I think it's the way I have my lights and display setup, ; for instance, my pixel tree is 16 rungs by 50 pixels each, using one e682 controller; I couldn't figure out anyother way to do it.  Is there another way?

 

To add a little to this, the way that the E682 assigns channels somewhat forces it - partially.  The E682 assigns addresses in what Jim calls "Clusters".  An E682 has four clusters that each have four outputs.  You define the starting address, number of strings in use, type of strings, number of pixels on each string, group size for each cluster.  Each cluster can be completely different.  So for example using wmilkie's 16 strings of 50 pixels situation.  Assuming each of the 50 strings is on a single output from the E682 (a normal way to do it), if cluster 1 starts with Universe 1, channel 1, the next four outputs will be packed and end at universe 2 channel 90.  Now, you could lie to the E682 and tell it that there are really 170 pixels in each string - in which case each string would start with a new universe.  However that would create a new problem in that the E682 can only handle a total of 12 universes.  For 2015, I lied to my E682 that handles my tree and told it that there were 85 pixels on each string, so each universe had two strings.  That worked out just fine for the E682 and Visualizer.  The other reason I did that was a future plan for string arrangement that I planned for 2015, but time and money prevented from happening.  For 2016, I will be changing it again (I think) because I think I'm going to change the construction plan from what I was going to do last year.

 

Share this post


Link to post
Share on other sites
20 hours ago, k6ccc said:

 

To add a little to this, the way that the E682 assigns channels somewhat forces it - partially.  The E682 assigns addresses in what Jim calls "Clusters".  An E682 has four clusters that each have four outputs.  You define the starting address, number of strings in use, type of strings, number of pixels on each string, group size for each cluster.  Each cluster can be completely different.  So for example using wmilkie's 16 strings of 50 pixels situation.  Assuming each of the 50 strings is on a single output from the E682 (a normal way to do it), if cluster 1 starts with Universe 1, channel 1, the next four outputs will be packed and end at universe 2 channel 90.  Now, you could lie to the E682 and tell it that there are really 170 pixels in each string - in which case each string would start with a new universe.  However that would create a new problem in that the E682 can only handle a total of 12 universes.  For 2015, I lied to my E682 that handles my tree and told it that there were 85 pixels on each string, so each universe had two strings.  That worked out just fine for the E682 and Visualizer.  The other reason I did that was a future plan for string arrangement that I planned for 2015, but time and money prevented from happening.  For 2016, I will be changing it again (I think) because I think I'm going to change the construction plan from what I was going to do last year.

 

There is new firmware either out now or very shortly that will allow the E682 to be individual outputs and not clusters anymore. I believe it was posted as a beta on DIYC a couple weeks ago 

Share this post


Link to post
Share on other sites
2 hours ago, 1983ss454 said:

There is new firmware either out now or very shortly that will allow the E682 to be individual outputs and not clusters anymore. I believe it was posted as a beta on DIYC a couple weeks ago 

Jim had told me over 6 months ago that changes to allow individual control was in the works.  I just checked his website and it's not public yet.  I'll have to look for the beta.

 

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.
Note: Your post will require moderator approval before it will be visible.

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...