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

E1.31 .. another iteration.

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

  1. multicast

    multicast Senior Elf Generous Elf

    Joined:
    Jul 13, 2013
    Messages:
    715
    Likes Received:
    7
    So, in October the E1.31 task Group will be meeting again, and we are going to reopen the E1.31 standard with a view to keep developing more features.. ( Just to clarify this is not the sync and discovery stuff, which is very nearly there ).



    some things that are on the list to think about are;

    ipv6
    increased numbers of universes
    jumbo dmx frames
    security of e1.31

    If you have any bright ideas or good ideas, i'd be happy to throw these into the mix, no guarreentees they will get in there, but they will get considered.

    And as always the Working group is not a closed thing, and you can join in, there is a cost now of $100USD per year per particpant, which helps pay for the costs...
     
  2. damona

    damona Full Time Elf

    Joined:
    Oct 23, 2013
    Messages:
    254
    Likes Received:
    5
    All sounds good to me. esp the jumbo frames to allow more channels per packet and go over the 512 limit.
     
  3. OP
    OP
    multicast

    multicast Senior Elf Generous Elf

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

    I dont' rate the chances of this happening too highly. There is a great deal of opposition to this.
     
  4. keithsw1111

    keithsw1111 Full Time Elf

    Joined:
    Oct 11, 2012
    Messages:
    251
    Likes Received:
    15
    Location:
    Kellyville, NSW
    Find Me On:
    And once you cross the Ethernet packet size limit controller code gets a lot more complicated.
     
  5. damona

    damona Full Time Elf

    Joined:
    Oct 23, 2013
    Messages:
    254
    Likes Received:
    5
    Can not see how it would cause any compatibility issues. One packet/frame is for one Universe. You would only send the large frame to a device which is design to take over 512 channels in a single frame/Universe. This also helps reduce the need for more universes while maintain compatibility with older devices. Sticking with less than half size packets is such a waste of bandwidth and increasing the processing on devices, as they have the overhead of processing more packets for the same result.

    Strip would be the classic case of having to resend all the data down the strip again when the second packet turns up to change the last half the lights, because it could not be contain in a single packet. However work around for this is synchronization in the almost approved standard.

    Another example would be the Raspberry Pi 2 it would be able to control more channels from its 100Mbit Ethernet. Or even wireless might work better.

    It would not hurt or hinder the standard to allow it either. I might be thinking to simple, but some existing devices if their Ethernet buffer supports full frame and have a bit of free ram, a firmware upgrade might be all that is required.

    I am surprised. :eek:

    I am not talking about data spread across multiple Ethernet frames. Current Ethernet frame could carry another 815 channels, for a total of 1,327 channels instead of the current limit of 512.

    This is a bit of what I sent in
    "Assuming a pay load of 1,452 Octets possible on an Ethernet frame IPv6 (bigger header), with 512 Universe using 637 Octets that leaves 815 free Octets. So the maximum DMX channels for a Universe could be 1,327. (1,326 if a multiple of 3, 1,326/512=~2.6)"
     
  6. OP
    OP
    multicast

    multicast Senior Elf Generous Elf

    Joined:
    Jul 13, 2013
    Messages:
    715
    Likes Received:
    7
    Im with you on this, there are some folks who really will dig their toes. in. Become a voting member and have your say. Costs $100 now per year...

     
  7. marmalade

    marmalade cats & pixels

    Joined:
    Dec 1, 2015
    Messages:
    188
    Likes Received:
    25
    Location:
    newcastle
    What about the overall backwards compatibilty? I would imagine there are a lot of controllers/bridges out there that will need to come out of their enclosures for firmware updates (if even available)


    Maybe e1.31.1 :)
     
  8. OP
    OP
    multicast

    multicast Senior Elf Generous Elf

    Joined:
    Jul 13, 2013
    Messages:
    715
    Likes Received:
    7
    Always a consideration. Future change are done with this in mind, as nobody will want to break stuff that is already working. Having said that, if people dont' implement the standards properly and only do a minimum to make it work, rather than implementing it all to check that things are valid etc, then subsquent changes might break thing


     
  9. damona

    damona Full Time Elf

    Joined:
    Oct 23, 2013
    Messages:
    254
    Likes Received:
    5

    How many current voting members are there today?
    Does each proposal get voted on?
    Is it voting over the internet? (I assume you can vote without attending the meeting/conference)
     
  10. OP
    OP
    multicast

    multicast Senior Elf Generous Elf

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



    Yes. Lots of talk, lots of spin. and yes eventualy any changes to stanards get voted on.


    yes, you dont' have to turn up in person to a a meeting, they have web-ex...
     
  11. Barnabybear

    Barnabybear New Elf

    Joined:
    Mar 30, 2012
    Messages:
    20
    Likes Received:
    1
    Location:
    UK
    Hi, I know it's not a normal application but I use an ESP8266 to read from memory or SD card and send UDP packets to other controllers for off season events and wearables. Pretty much what FPP and other sequencers do, I've already had to up the buffer size to get the 637 bytes needed to send a full universe. Whilst I understand that I wouldn’t need to adopt multi-universe packets if they became part of the standard, I am curious if the implication of generating the packet has been considered.
     

Share This Page