Re: Lessons learnt DMX over IP.. Part(1) there is standards / there is no standards
A couple of comments. Sometimes portions of the standard may not make sense for a particular application. An example that comes to mind is arbitrating bwtween 2 or more simultaneous senders. The default is supposed to be "HTP" or Highest Takes Precedence. In other words if 2 senders are sending different dim values to the same channel, you go with the highest value. While that may make sense for individual single-channel light fixtures. it doesn't for pixels. If one sender is trying to light a pixel RED while another is trying to light the same pixel GREEN, and you use HTP you wind up with a YELLOW pixel.
There are other examples, for example in multicast E1.31, the universe numper appeares twice in every packet, in the header and in the packet itself. The standard says that if the 2 values differ, use the one in the packet. Why? If the 2 values differ, something's screwed up, and whichever way you go you've got a 50% chance of being right.
Also ETC has added their 'CC' extensions to the SACN standard that allow a sender to take control of a portion of a universe. Well, there's a lot of overhead involved in implementing that feature because there's no theoretical limit to the number of possible simultaneous senders.
Anyway, the good news is, for the most part, if you're dealing with a single sender, which is the case for most of the installations we deal with here, everything generally talks together pretty well.
The Sandevices E680/E681/E682 Pixel Controllers, part of the[SIZE="3"] [COLOR="red"]P[/COLOR][COLOR="orange"]I[/COLOR][COLOR="blue"]X[/color][COLOR="lime"]E[/COLOR][COLOR="magenta"]L[/COLOR] [COLOR="red"]P[/COLOR][COLOR="lime"]R[/COLOR][COLOR="blue"]O[/COLOR][COLOR="red"]J[/COLOR][COLOR="magenta"]E[/COLOR][COLOR="cyan"]C[/COLOR][COLOR="red"]T[/COLOR]
[url]www.sandevices.com[/url][/SIZE] <-email jim at