The Control Protocol Working Group in 2016 has added extensions to the e1.31 standard. One of of these extensions is universe synchronization.
'''What is Sync?'''
Sync is a mechanism that allows every device to synchronise when the change from one frame to the next occurs. Without sync, most devices process incoming E1.31 data as it arrives, and switch their outputs as soon as they have doe the processing. The impact of that is that some devices will change before others and an effect known as "tearing" ( borrowed from LED screen folks ) occurs. It is sometimes difficult to see, until you compare it to the same display all be changed together. You'll often see more contrast, better colour rendition and a "sharper" show.
'''"What do you need to take advantage of sync"'''
You need E1.31 controller that know how to process the "extensions" to E1.31. Check with your vendor to see if they support it.
You need a E1.31 sender ( such as Xlights, Vixen, etc etc ) that provides the E1.31 sync signal
You need a network that either supports multicast with IGMP properly ( the best thign to do ), or understand that if you are using a network that just forwards all multicast packets, to all ports that you may have issues you will need to deal with. You can still use unicast to send your DATA, but the sync packet has to be multicasted.
'''
How Does it work?'''
- This is really only something developers probalby have to understand.
In a E1.31 DATA packet, one of the fields that was previous unused, is now used. If you set this feild to 0x00, the data is considered unsynced. If you set this feild to anything greater than 0x00, that number is now the datas "sync universe" number. This is the only change that needs to be made in the data packet.
After your controller has sent out all the data for that frame, it then sends another packet called a "SYNC" packet. This packet is similar to a DATA packet, however carries no data. The universe number of this sync packet should be the one that you set in the DATA packet. When your device receives this SYNC packet, it knows it is time to change from the previous frame, to the new frame that it has just received. Because everything on the network will receive this sync packet, at very nearly the same time, everything changes together.
Caution:
Some older e1.31 devices have not implemented the e1.31 standard fully, in respect of checking to see if the E1.31 packet they have received is in fact a data packet. This has always been in the standard, however since the only e1.31 packets that were being sent were data, not checking had little impact. Because data and sync packets are similar, it is possible that some devices may try to process a e1.31 sync packet as a data packet, and results may be erratic.
Multiple work arounds exisit for how to get around this, but ideally vendors will patch their code.
'''What is Sync?'''
Sync is a mechanism that allows every device to synchronise when the change from one frame to the next occurs. Without sync, most devices process incoming E1.31 data as it arrives, and switch their outputs as soon as they have doe the processing. The impact of that is that some devices will change before others and an effect known as "tearing" ( borrowed from LED screen folks ) occurs. It is sometimes difficult to see, until you compare it to the same display all be changed together. You'll often see more contrast, better colour rendition and a "sharper" show.
'''"What do you need to take advantage of sync"'''
You need E1.31 controller that know how to process the "extensions" to E1.31. Check with your vendor to see if they support it.
You need a E1.31 sender ( such as Xlights, Vixen, etc etc ) that provides the E1.31 sync signal
You need a network that either supports multicast with IGMP properly ( the best thign to do ), or understand that if you are using a network that just forwards all multicast packets, to all ports that you may have issues you will need to deal with. You can still use unicast to send your DATA, but the sync packet has to be multicasted.
'''
How Does it work?'''
- This is really only something developers probalby have to understand.
In a E1.31 DATA packet, one of the fields that was previous unused, is now used. If you set this feild to 0x00, the data is considered unsynced. If you set this feild to anything greater than 0x00, that number is now the datas "sync universe" number. This is the only change that needs to be made in the data packet.
After your controller has sent out all the data for that frame, it then sends another packet called a "SYNC" packet. This packet is similar to a DATA packet, however carries no data. The universe number of this sync packet should be the one that you set in the DATA packet. When your device receives this SYNC packet, it knows it is time to change from the previous frame, to the new frame that it has just received. Because everything on the network will receive this sync packet, at very nearly the same time, everything changes together.
Caution:
Some older e1.31 devices have not implemented the e1.31 standard fully, in respect of checking to see if the E1.31 packet they have received is in fact a data packet. This has always been in the standard, however since the only e1.31 packets that were being sent were data, not checking had little impact. Because data and sync packets are similar, it is possible that some devices may try to process a e1.31 sync packet as a data packet, and results may be erratic.
Multiple work arounds exisit for how to get around this, but ideally vendors will patch their code.