Ryan and I are getting close to having the ACL 101 completed and I'm going away for a few days and leaving him unsupervised. This morning I typed up a fairly incoherent page of info that I'd like to get some of into the 101.
Comments or feedback on the benefits/non benefits/issues/accuracy of what I've typed up would be appreciated. The manual has grown somewhat in size than it used to be and this is among the last major bit of info that may go in.
Some of the E1.31 unicast/multicast may get referred to the wiki
Alan
E1.31
E1.31 devices need to have an IP address in order for data to be routed to the correct place. The IP address can either be static which means that it is user assigned or it is dynamic and it is assigned via a DHCP server. The DHCP server is typically in the form of a router.
Unicast data is data that will only follow a path from the sequencer or sequence playback device to the assigned IP address and only transporting Universes and data that are defined.
Multicast data is data that is sent out from the sequencer or sequence playback device with Universe data but no assigned destination IP. The router or switch will accept the incoming data and alternately send it to all connected E1.31 devices or in the case of IGMP snooping routers it will learn what devices want what and will only send the required universe data to that device/s.
Benefits of Unicast data
Only the E1.31 device at the destination IP will receive the data that the sequencer or sequence playback device is sending those packets to.
Benefits of Multicast data
There is no need to know the IP address of destination E1.31 devices.
It is possible to have the same universe going to multiple E1.31 devices if only part of a universe is used on 1 device and the balance is used on another 1. It can also be useful if part of a display is mirrored.
Pitfalls to Unicast data
The biggest pitfall to unicast data is that if there is data being sent out to an E1.31 device on an assigned IP and it isn’t connected, powered up or on that IP address then the sequencer or sequence playback device will typically bog down as it continuously tries sending and re-sending out data packets looking for the destination but unable to find it. It can also flood the router.
The second pitfall is that if the device IP isn’t what is expected or it gets changed then the data won’t get to that device.
Pitfalls to Multicast data
If using multicast without a router that has IGMP snooping then every E1.31 devices gets sent every data packet. If using a device that doesn’t have a lot of processing power like a diy Arduino or similar then it can cause them to get bogged down. They have to process every incoming data packet, analyse them to see if they are required and then reject unwanted ones.
E1.31 IP addresses
In order to connect to an IP advice it has to have an IP. In order to be connectable the computer and E1.31 must have compatible IP ranges as must the router.
The 2 settings most commonly associated with E1..31 configurations are the IP and the Network Mask (or netmask).
The IP is a 32 bit number arranged as 4 8 bit numbers. Each of these 8 bit numbers is known as an octet. Common IP ranges that are used are 10.*.*.* and 192.168.*.* with 172.16.*.* sometimes used. Every computer and device on the network must have its own exclusive IP address. They should all be in the same IP range. ie have the same 1st and possibly 2nd and 3rd octet.
The network mask (netmask) limits the range of IP’s that are accessible from device to device. A Netmask of 255.255.255.0 which is quite common would allow devices 10.0.0.1 through to 10.0.0.255 to communicate with each other but prevent 10.0.0.1 communicating with 10.0.10.1 or 10.10.0.1. A netmask octet of 255 means that the matching IP octet on 2 devices must be an exact match. A netmask octet of 0 allows the full 0-255 range of IP octets to communicate. It is possible to use other than 0 or 255 but generally for home lighting control these 2 values are all that is required.
Pixels
When working with pixels it is necessary to ensure the exact number of pixels is assigned in the sequencer and pixel controller. Because pixels have no addressing then if there is a miscount between what is actually on the display and what the sequencer has then there can be a lot of confusion generated especially if there is more than 1 prop on a given output of a pixel controller. Xlights and potentially other sequencers have the ability to test individual models as part of the test feature. It is always worthwhile using this feature, if available, to check that all of a model turns on as it should and also that no other model turns on.
Generally speaking it is possible to assign virtually any universe and channels to any output on a pixel controller. There will be practical limitations as to the number of pixels per output (typically under 1020) and they are normally limited to contiguous universe numbers. Output 1 may use Universe 1 Channel 1 through to Universe 4 Channel 10 for a mega tree or instance. It is possible to use the balance of Universe 4 on output 2 if required or alternately another Universe could be assigned on the pixel controller for output 2.
As far as data goes it is better to fill universes as close to 512 channels as is feasible. The full 512 channels of a universe is typically sent to the E1.31 devices so having universes with only a small number of channels used means that there is a lot more data being sent out unnecessarily. Usually it would be normal to ensure that universes aren’t spanned across different E1.31 devices although this can be handled with multicast.
Comments or feedback on the benefits/non benefits/issues/accuracy of what I've typed up would be appreciated. The manual has grown somewhat in size than it used to be and this is among the last major bit of info that may go in.
Some of the E1.31 unicast/multicast may get referred to the wiki
Alan
E1.31
E1.31 devices need to have an IP address in order for data to be routed to the correct place. The IP address can either be static which means that it is user assigned or it is dynamic and it is assigned via a DHCP server. The DHCP server is typically in the form of a router.
Unicast data is data that will only follow a path from the sequencer or sequence playback device to the assigned IP address and only transporting Universes and data that are defined.
Multicast data is data that is sent out from the sequencer or sequence playback device with Universe data but no assigned destination IP. The router or switch will accept the incoming data and alternately send it to all connected E1.31 devices or in the case of IGMP snooping routers it will learn what devices want what and will only send the required universe data to that device/s.
Benefits of Unicast data
Only the E1.31 device at the destination IP will receive the data that the sequencer or sequence playback device is sending those packets to.
Benefits of Multicast data
There is no need to know the IP address of destination E1.31 devices.
It is possible to have the same universe going to multiple E1.31 devices if only part of a universe is used on 1 device and the balance is used on another 1. It can also be useful if part of a display is mirrored.
Pitfalls to Unicast data
The biggest pitfall to unicast data is that if there is data being sent out to an E1.31 device on an assigned IP and it isn’t connected, powered up or on that IP address then the sequencer or sequence playback device will typically bog down as it continuously tries sending and re-sending out data packets looking for the destination but unable to find it. It can also flood the router.
The second pitfall is that if the device IP isn’t what is expected or it gets changed then the data won’t get to that device.
Pitfalls to Multicast data
If using multicast without a router that has IGMP snooping then every E1.31 devices gets sent every data packet. If using a device that doesn’t have a lot of processing power like a diy Arduino or similar then it can cause them to get bogged down. They have to process every incoming data packet, analyse them to see if they are required and then reject unwanted ones.
E1.31 IP addresses
In order to connect to an IP advice it has to have an IP. In order to be connectable the computer and E1.31 must have compatible IP ranges as must the router.
The 2 settings most commonly associated with E1..31 configurations are the IP and the Network Mask (or netmask).
The IP is a 32 bit number arranged as 4 8 bit numbers. Each of these 8 bit numbers is known as an octet. Common IP ranges that are used are 10.*.*.* and 192.168.*.* with 172.16.*.* sometimes used. Every computer and device on the network must have its own exclusive IP address. They should all be in the same IP range. ie have the same 1st and possibly 2nd and 3rd octet.
The network mask (netmask) limits the range of IP’s that are accessible from device to device. A Netmask of 255.255.255.0 which is quite common would allow devices 10.0.0.1 through to 10.0.0.255 to communicate with each other but prevent 10.0.0.1 communicating with 10.0.10.1 or 10.10.0.1. A netmask octet of 255 means that the matching IP octet on 2 devices must be an exact match. A netmask octet of 0 allows the full 0-255 range of IP octets to communicate. It is possible to use other than 0 or 255 but generally for home lighting control these 2 values are all that is required.
Pixels
When working with pixels it is necessary to ensure the exact number of pixels is assigned in the sequencer and pixel controller. Because pixels have no addressing then if there is a miscount between what is actually on the display and what the sequencer has then there can be a lot of confusion generated especially if there is more than 1 prop on a given output of a pixel controller. Xlights and potentially other sequencers have the ability to test individual models as part of the test feature. It is always worthwhile using this feature, if available, to check that all of a model turns on as it should and also that no other model turns on.
Generally speaking it is possible to assign virtually any universe and channels to any output on a pixel controller. There will be practical limitations as to the number of pixels per output (typically under 1020) and they are normally limited to contiguous universe numbers. Output 1 may use Universe 1 Channel 1 through to Universe 4 Channel 10 for a mega tree or instance. It is possible to use the balance of Universe 4 on output 2 if required or alternately another Universe could be assigned on the pixel controller for output 2.
As far as data goes it is better to fill universes as close to 512 channels as is feasible. The full 512 channels of a universe is typically sent to the E1.31 devices so having universes with only a small number of channels used means that there is a lot more data being sent out unnecessarily. Usually it would be normal to ensure that universes aren’t spanned across different E1.31 devices although this can be handled with multicast.