E1.31 Standard Revision - Public Review

[multicast]

The E1.31 standard is being updated and revised to include Synchronization. Its now in public review, which give you the opportunity to read and comment on it.


This standard describes a mechanism to transfer DMX512-A packets over a TCP/IP network using a subset of the ACN protocol suite. It covers data format, data protocol, data addressing, and network management It also outlines a synchronization method to help ensure that multiple sinks can process this data concurrently when supervised by the same controller. This revision includes the addition of DMX universe synchronization.


http://tsp.esta.org/tsp/documents/public_review_docs.php

 

[damona]

Just sent some feed back suggest that the E1.31 should support more than 512 Channels Per Universe e.g. 1,327 channels. Which is a full Ethernet Frame. Cannot think of any reason why not, given a person needs to program the show and can choose not to use above 512 for older hardware. I have suggest it as a optional implementation to the standard, rather than being mandated.

Cheers

 

[multicast]

Just sent some feed back suggest that the E1.31 should support more than 512 Channels Per Universe e.g. 1,327 channels. Which is a full Ethernet Frame. Cannot think of any reason why not, given a person needs to program the show and can choose not to use above 512 for older hardware. I have suggest it as a optional implementation to the standard, rather than being mandated.

Cheers

In deed. This wont' get into the newest revision thats coming out.. However..

At todays CPWG i got this exact topic in on the agenda, and it has been accepted that we will be working on the "expansion of the universe" in E1.31-8. With ipv6 also being added in. ( optionally ), some 8 billion channels will likely be avaialble to you! I am in aggrement with you that universe length does not have to be 512 and it can be much longer"

 

[damona]

I can not see anything in the existing standard that would prevent it e.g integer sizes etc. Only show stopper is it not being documented as an optional implementation. They just need to allow more than 512 channels/slots in a packet and not make it mandatory.

Basically the follow few para's updated.

7.7 Property Values (DMX512-A Data)
The DMP Layer's Property values field is used to encode the DMX512-A [DMX] START Code and data.

The first octet of the property values field shall be the DMX512-A [DMX] START Code.

The remainder of the property values shall be the DMX512-A data slots. This data shall contain a sequence of octet data values that represent a consecutive group of data slots, starting with slot 1, from a DMX512-A packet. The number of data slots encoded in the frame shall not exceed the DMX512-A limit of 512 data slots.

Processing of Alternate START Code data shall be compliant with ANSI E1.11 [DMX] Section 8.5.3.3 - Handling of Alternate START Code packets by in-line devices.

Its interesting the wording is "shall not" vs "must not", so in theory you could put more slots in a packet today.

Just needs more generous wording "The number of data slots encoded in the frame can exceed the DMX512-A limit of 512 data slots if both controller and device support it for a particular universe, up to 1,326 slots allowing support for Universe with more than 512 channels" (from existing 170 to 442 pixels per packet)

Given devices are 100Mbit Ethernet, any reduction in the number of packets they need to process (or CPU be interrupted by) is a good thing.