Setting up for unicast transmission
- Thread starter BundyRoy
- Start date
damona
Full time elf
- Joined
- Oct 23, 2013
- Messages
- 296
Under the current standards if you want the best chance of a object or a set of same objects being in sync then you need to maximize the use of a Universe, so that one E131 packet can control as much as it can.
If you have one or more controller for you matrix, then ensure you use all 170 pixels in a universe before moving onto the next universe, even if its not a whole row.
If you think you will make the matrix bigger one day do not use the next few universe save them for expanding the matrix.
I would suggest you only use a new universe when you have a different object type, or you used up the universe.
e.g. Universe 1 Candy Canes 8 x 20 pixels each. (160 pixels) These Candy Canes may be spread across multiple controllers. They will be in sync because all the controllers in use will get the same multicast packet at the same time.
If you have one or more controller for you matrix, then ensure you use all 170 pixels in a universe before moving onto the next universe, even if its not a whole row.
If you think you will make the matrix bigger one day do not use the next few universe save them for expanding the matrix.
I would suggest you only use a new universe when you have a different object type, or you used up the universe.
e.g. Universe 1 Candy Canes 8 x 20 pixels each. (160 pixels) These Candy Canes may be spread across multiple controllers. They will be in sync because all the controllers in use will get the same multicast packet at the same time.
Beacy
It's so much better on the dark side
Ok am I correct about the following
1. Each universe requires a "Packet" - therefore 160 unis = 160 packets
2. A "packet" size = "X"
3. If I reduce the amount of pixels/channels I am using in a universe the packet size of "X" remains the same OR it reduces the size of "X" and therefore less data total for that packet.
If the "X" remains the same size then reducing the number of universes will obviously reduce the data and congestion. BUT if it the lower number of channels on a universe does reduce the packet size wouldn't the total amount of data be the same?
1. Each universe requires a "Packet" - therefore 160 unis = 160 packets
2. A "packet" size = "X"
3. If I reduce the amount of pixels/channels I am using in a universe the packet size of "X" remains the same OR it reduces the size of "X" and therefore less data total for that packet.
If the "X" remains the same size then reducing the number of universes will obviously reduce the data and congestion. BUT if it the lower number of channels on a universe does reduce the packet size wouldn't the total amount of data be the same?
Each E1.31 packet contains one universe (512 channels) worth of data. Even if you are only using part of a universe, the software still has to send the whole packet.
So for example if you needed 2048 channel but only used 128 channels in each universe you'd need 16 universes, whereas if you packed them together you'd only need 4 universes.
So for example if you needed 2048 channel but only used 128 channels in each universe you'd need 16 universes, whereas if you packed them together you'd only need 4 universes.
damona
Full time elf
- Joined
- Oct 23, 2013
- Messages
- 296
Each Pixel needs 3 DMX Channels (Red 0-255 , Green 0-255, Blue 0-255). 3*170 = 510 DMX channels
First Pixel is DMX Channel 1,2,3 and the Last Pixel is 508,509,510. DMX Channel 511 & 512 are general not used.
I believe pixel controllers assume you only use up to DMX channel 510, before moving on to the next universe and DMX channel 1,2,3 for the next pixel. This is how the PixLight works.
Lets say ouput 1 is 171 Pixels
Pixel 1 is Universe 1 DMX Channel 1,2,3
Pixel 170 is Universe 1 DMX Channel 508,509,510
Pixel 171 is Universe 2 DMX Channel 1,2,3
If you were building a matrix you would start output 2 as Pixel 172 Universe 2 DMX Channel 4,5,6
First Pixel is DMX Channel 1,2,3 and the Last Pixel is 508,509,510. DMX Channel 511 & 512 are general not used.
I believe pixel controllers assume you only use up to DMX channel 510, before moving on to the next universe and DMX channel 1,2,3 for the next pixel. This is how the PixLight works.
Lets say ouput 1 is 171 Pixels
Pixel 1 is Universe 1 DMX Channel 1,2,3
Pixel 170 is Universe 1 DMX Channel 508,509,510
Pixel 171 is Universe 2 DMX Channel 1,2,3
If you were building a matrix you would start output 2 as Pixel 172 Universe 2 DMX Channel 4,5,6
Beacy
It's so much better on the dark side
OK .... big improvment after stripping back the number of uni's to 117 still in Multicast might try the unicast on a different computer after Christmas.
A big thankl you to all that helped both here and in chat.
PS sorry Alan it was NOT an LSP issue
A big thankl you to all that helped both here and in chat.
PS sorry Alan it was NOT an LSP issue
Now,now Alan. We are talking 160 universes, Not 160 channels mate
damona
Full time elf
- Joined
- Oct 23, 2013
- Messages
- 296
Order a Raspberry PI B+ and have a play with it before packing up your display. Assuming the FFP supports LSP.
With Vixen 3, it calculates what to do as it plays, so if the computer is slow, or the display very complex, you would get a lag. Export Vixen3 to FFP and it outputs a already calculated file. The FFP just sends the data. i.e. E131.
Stick with multicast it is the standard.
With Vixen 3, it calculates what to do as it plays, so if the computer is slow, or the display very complex, you would get a lag. Export Vixen3 to FFP and it outputs a already calculated file. The FFP just sends the data. i.e. E131.
Stick with multicast it is the standard.
nutz4lights
Full time elf
I'm going thru this right now for my display. Having trouble exporting composer sequence from LSP and converting with nutcracker/xlights, but if I convert the LSP sequence with Light Elf to falcon pi, it almost works... The playback is definitely with... although I have the pi setup as unicast... that's what was recommended... should the pi be setup as multicast?
Louie
Louie