E1.31 .. another iteration.

[multicast]

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...

 

[damona]

All sounds good to me. esp the jumbo frames to allow more channels per packet and go over the 512 limit.

 

[multicast]

All sounds good to me. esp the jumbo frames to allow more channels per packet and go over the 512 limit.

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

 

[keithsw1111]

And once you cross the Ethernet packet size limit controller code gets a lot more complicated.

 

[damona]

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

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.

And once you cross the Ethernet packet size limit controller code gets a lot more complicated

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)"

 

[multicast]

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...

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

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.

And once you cross the Ethernet packet size limit controller code gets a lot more complicated

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)"

 

[marmalade]

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

 

[multicast]

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

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

 

[damona]

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...

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)

 

[multicast]

How may current voting members are there today?

about 40

Does each proposal get voted on?

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

Is it voting over the internet? (I assume you can vote without attending the meeting/conference)

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

 

[Barnabybear]

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.