EmmienLightFan Posted January 29, 2016 Share Posted January 29, 2016 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? Link to comment Share on other sites More sharing options...
Ebuechner Posted January 30, 2016 Share Posted January 30, 2016 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 Link to comment Share on other sites More sharing options...
jstorms Posted February 4, 2016 Share Posted February 4, 2016 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? Link to comment Share on other sites More sharing options...
k6ccc Posted February 5, 2016 Share Posted February 5, 2016 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. Link to comment Share on other sites More sharing options...
Ebuechner Posted February 5, 2016 Share Posted February 5, 2016 (edited) 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 February 5, 2016 by Ebuechner Link to comment Share on other sites More sharing options...
sax Posted February 5, 2016 Share Posted February 5, 2016 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. Link to comment Share on other sites More sharing options...
Ebuechner Posted February 5, 2016 Share Posted February 5, 2016 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. Link to comment Share on other sites More sharing options...
k6ccc Posted February 5, 2016 Share Posted February 5, 2016 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! Link to comment Share on other sites More sharing options...
wmilkie Posted February 5, 2016 Share Posted February 5, 2016 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 Link to comment Share on other sites More sharing options...
Dennis Laff Posted February 5, 2016 Share Posted February 5, 2016 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 . Link to comment Share on other sites More sharing options...
Grinch Posted February 5, 2016 Share Posted February 5, 2016 Jim Thanks for the Pixel comparison, that should help people decide which pixels they want to use. Interesting results Link to comment Share on other sites More sharing options...
k6ccc Posted February 5, 2016 Share Posted February 5, 2016 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. Link to comment Share on other sites More sharing options...
wbaker4 Posted February 5, 2016 Share Posted February 5, 2016 (edited) 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 February 5, 2016 by wbaker4 Link to comment Share on other sites More sharing options...
k6ccc Posted February 5, 2016 Share Posted February 5, 2016 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. Link to comment Share on other sites More sharing options...
Ebuechner Posted February 6, 2016 Share Posted February 6, 2016 k6ccc how are you measuring the refresh rate? Frequency counter or scope Link to comment Share on other sites More sharing options...
wmilkie Posted February 6, 2016 Share Posted February 6, 2016 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? Link to comment Share on other sites More sharing options...
k6ccc Posted February 6, 2016 Share Posted February 6, 2016 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. Link to comment Share on other sites More sharing options...
k6ccc Posted February 6, 2016 Share Posted February 6, 2016 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. Link to comment Share on other sites More sharing options...
1983ss454 Posted February 7, 2016 Share Posted February 7, 2016 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 Link to comment Share on other sites More sharing options...
k6ccc Posted February 7, 2016 Share Posted February 7, 2016 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. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now