1. New to Christmas lighting? Get started with the AusChristmasLighting 101 Manual:
    auschristmaslighting.com/wiki/AusChristmasLighting-101

E1.31-7 Extended Packets may cause some systems to have issues.

Discussion in 'DMX, E1.31 & Networking' started by multicast, Mar 4, 2016.

  1. multicast

    multicast Senior Elf Generous Elf

    Joined:
    Jul 13, 2013
    Messages:
    715
    Likes Received:
    7
    Hi folks,


    I have been working through the new E1.31 extensions, in the new standard which is likely to come out in the next month or do. Some current systems ( they will remain nameless becuase this is not a name and shame ) will have issues and testing shows that some will glitch if they get E1.31 extended packets. ( the sync packet or a discovery packet ). The E1.31 standard mandates that systems *should* check the various feilds in the headers. Some systems don't and they appear to process "extended" packets as data packets and the results vary from a lock up to a glitch. 2 vendors systems appeared ok. ( these are DIY Christmas common controllers ).

    I would urge you to ask your vendor if they are actually standards compliant ( now ).

    for vendors, please check the new draft standard, its all public. At a minimum you need to check the root vector feild and discard anthing apart from data packets, and you *should* be ok. I'd urge you however to probably spent a little more time and check all the feilds that are importnat.
     
  2. AAH

    AAH I love blinky lights :) Community Project Designer

    Joined:
    Dec 27, 2010
    Messages:
    2,625
    Likes Received:
    36
    Location:
    Eaglehawk
    Find Me On:
    Out of curiosity what software or hardware is there around that will actually transmit E1.31-7 at this time.
    A lot of people are using software and/or E1.31 hardware that can date back years. Anyone still using LSP will obviously be an old implementation as is the version of LOR that I'm using as I stopped updating it in 2014.
     
  3. SmartAlecLights

    SmartAlecLights Im a SmartAlec what can i say! Community Project Designer

    Joined:
    May 4, 2010
    Messages:
    1,205
    Likes Received:
    12
    Location:
    S.A.
    Find Me On:
    So why does it have to be changed..??
    E1.31 works..
    nothing is wrong with it..
    why do we need E1.31-7 that will make alot of things stop working..
     
  4. OP
    OP
    multicast

    multicast Senior Elf Generous Elf

    Joined:
    Jul 13, 2013
    Messages:
    715
    Likes Received:
    7

    The issue comes when/if you have implemented yoru E1.31 code without doing the packet sanity checks that you should do. The standard ( the currnet one ) always provided for a future where differnet kinds of data woudl be transported in the data.

    If you ignored the headers ( which you could, if you assumed all packets would be the same ) then it worked with E1.31, simply becuae there were *only* data packets.

    Soon there will be *extended* packets.

    Its not a big deal to add a simple check to your software to look at two bytes, in the header and see.
     
  5. OP
    OP
    multicast

    multicast Senior Elf Generous Elf

    Joined:
    Jul 13, 2013
    Messages:
    715
    Likes Received:
    7
    Not a lot, but i expect that pretty rapidly you'll see it turn up and i expect one of the first implmeentors will be Xlights / Falcon, as they are really first out.. Packet Sync is somethign that you need to see, but it makes a differnece to how sharp your show looks.. I 'm hoping to have this read as a demo at the melbourne mini.


    Provided you followed the E1.31 to start with, theres nothign to worry about. Its just when you did'nt, and implemented short cuts, that things might go wrong.

    NB. there is no requirement for you to *have* to process Sync or Discovery packets.. You might just want to recognise them and ditch them ( and not try to process them as Data packets )
     
  6. Gilrock

    Gilrock Full Time Elf

    Joined:
    Jan 4, 2013
    Messages:
    390
    Likes Received:
    6
    Location:
    Tucson, AZ
    Find Me On:
    I know for the software side I don't want it doing any sync and discovery. That just seems stupid for our applications. It should just be fire and forget.
     
  7. OP
    OP
    multicast

    multicast Senior Elf Generous Elf

    Joined:
    Jul 13, 2013
    Messages:
    715
    Likes Received:
    7

    Discovery does'nt make much sense, but sync really makes a LOT of sense. When you see the difference between a show when all the leds in show change together, versus one where the leds change over some period of change. ( as devices all receive their packets at different times of the network ) you'll know why sync is a really good idea. Its a bit hard to describe, but its makes things look a whole lot more snappy.
     
  8. OP
    OP
    multicast

    multicast Senior Elf Generous Elf

    Joined:
    Jul 13, 2013
    Messages:
    715
    Likes Received:
    7
    If you really feel stringly about the changes to the E1.31 standards, then make sure you send your comments and concerns into the Public review process. If you contribute you get listened to. If you dont', then dont' complain.
     
  9. dkulp

    dkulp New Elf

    Joined:
    Jan 2, 2013
    Messages:
    47
    Likes Received:
    0
    Location:
    Framingham, MA

    Personally, I don't see ANY benefit for my show and will actually make some delays worse. I have 250ish channels on my pure serial DMX. At 250K, it takes about 11ms to send that out. Thus, the device on the channel 250 will change 11ms after the first channel.


    Right now, you can kind of help it by having the e1.31 bridge "first" in the list of universes that the computer sends out. That can give it a ms or so head start. Thus, maybe the perceived delay is 9 or 10 ms. With the sync, it would be the full 11ms.
     
  10. David_AVD

    David_AVD Bite my shiny metal ass!

    Joined:
    Jun 12, 2010
    Messages:
    3,541
    Likes Received:
    81
    Location:
    Victoria Point (Brisbane)
    Find Me On:
    Assuming traditional DMX (not E1.31), any delay between channels would depend on a number of factors.

    If the channels are split between multiple universes, then the timing of the sending device will have an effect. (Universes on different ports sent synchronously or offset in time)

    If they are all part of the same universe (physical port), things can be much tighter. It all depends on when the receiving unit updates the data that will be sent to the actual lights.

    If a receiver updates as soon as it has all of the channels it wants, then there could be a delay in updates between receivers with different channel allocations.

    If the receiver waits until the end of the DMX frame to update, all receivers on that universe will update at the same time. You could still get channel skew depending on how the receiver updates the actual channel outputs of course.
     
  11. bluzervic

    bluzervic 65,768 Channels, 185 Universes

    Joined:
    Dec 31, 2011
    Messages:
    516
    Likes Received:
    11
    Location:
    Fremont, Calif.
    Find Me On:
    So if the Software, LOR, Xlights4, Etc. do not send packets with the implemented standard (E1.31-7) and remain as E1.31, what does it matter ? There should be no changes needed to firmware and or hardware.


    It is only if the software changes to E1.31-7 that the firmware/hardware would need to check for it.


    Also, you mentioned some hardware may not be compliant, do you have a complete list ?
    Do you know if any of these controllers would actually require a Hardware refresh besides a firmware update to handle the changes.


    Has any of the Software firms, LOR, Xlights4 posted any roadmaps indicating when they plan on implementing E1.31-7


    -Blu
     
  12. OP
    OP
    multicast

    multicast Senior Elf Generous Elf

    Joined:
    Jul 13, 2013
    Messages:
    715
    Likes Received:
    7
     
  13. OP
    OP
    multicast

    multicast Senior Elf Generous Elf

    Joined:
    Jul 13, 2013
    Messages:
    715
    Likes Received:
    7

    For slow moving targets like Serial DMX, the sync likely woud'nt help you. Its being driven by the large numbers of things that are on IP networks. The standard allows for a device to be set up to sync or not to sync, and you can have some devices syncing and others not.

    If you have 40 universes of Pixels in a "Grid", havint them all syncing togehter is huge.
     
  14. OP
    OP
    multicast

    multicast Senior Elf Generous Elf

    Joined:
    Jul 13, 2013
    Messages:
    715
    Likes Received:
    7
    NB.

    I'm not sure why i deserved the hate mail from some on this topic. Its water off a ducks back, but the intention of this was just about proviing an early warning.. If you want to listen thats cool, if you dont' thats cool too.
     
  15. OP
    OP
    multicast

    multicast Senior Elf Generous Elf

    Joined:
    Jul 13, 2013
    Messages:
    715
    Likes Received:
    7
    Re: E1.31-7 the -7 is just a version number its not a new standard.

    Good Question someone asked me,

    the -7 on the Standard number is just a revision number. When the new version gets ratified, it will end up being called e1.31 version 7. Its not a massive rewrite.
     

Share This Page