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

multicast

Senior elf
Joined
Jul 13, 2013
Messages
715
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.
 

AAH

I love blinky lights :)
Community project designer
Joined
Dec 27, 2010
Messages
4,188
Location
Eaglehawk
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.
 

SmartAlecLights

Im a SmartAlec what can i say!
Community project designer
Joined
May 4, 2010
Messages
1,533
Location
Murray Bridge, S.A.
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..
 

multicast

Senior elf
Joined
Jul 13, 2013
Messages
715
smartalec said:
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..


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.
 

multicast

Senior elf
Joined
Jul 13, 2013
Messages
715
AAH said:
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.

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 )
 

Gilrock

Full time elf
Joined
Jan 4, 2013
Messages
438
Location
Tucson, AZ
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.
 

multicast

Senior elf
Joined
Jul 13, 2013
Messages
715
Gilrock said:
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.


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.
 

multicast

Senior elf
Joined
Jul 13, 2013
Messages
715
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.
 

dkulp

Full time elf
Joined
Jan 2, 2013
Messages
143
Location
Framingham, MA
multicast said:
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.


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.
 

David_AVD

Grandpa Elf
Community project designer
Generous elf
Joined
Jun 12, 2010
Messages
4,681
Location
Victoria Point (Brisbane)
dkulp said:
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.

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.
 

bluzervic

65,768 Channels, 185 Universes
Joined
Dec 31, 2011
Messages
535
Location
Fremont, Calif.
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
 

multicast

Senior elf
Joined
Jul 13, 2013
Messages
715
bluzervic said:
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.
Yes, if the controllers ( Lor, xlights etc ) dont' implement sync, or discovery ( and thats allowable in the standard ) then devices are not checking the headers fully, will be ok. And in fact if you are careful with how you set thigns up, you could have a mixed enviroment where the devices that dont' do full checking never see the sync packets.

Having said that, the changes required in code to ensure your devices dont' have issues, are very small. You just need to check a few bytes ( the root vector feild ) and discard the packet if its not a data packet. Standards compliant devices should ahve been doing this, just now with the extenstions, if you dont' do it, you'll have trouble.

Also, you mentioned some hardware may not be compliant, do you have a complete list ?

I know some devices that have issues, ( including some of my early code, though hopefully no one is using it now ). I dont' want to go pointing the finger around, its (a) not really fair, the standard is still in draft ( though very likely to be adopted ). There was no absolute need to check this untill now, and so, this thread is really just an heads up so folks who have code have an opporunity to deal with it in a timely fashion, so nobody gets caught.

Do you know if any of these controllers would actually require a Hardware refresh besides a firmware update to handle the changes.

It woudl seem unlikely that anyone would need to swap hardware out, a firmware change should address most issues I'd have thought, but you'd have to ask specific vendors that question.. I know for my gear, we will be providing new software to allow for the Sync packets to be utilised, and i want to do that asap.

Has any of the Software firms, LOR, Xlights4 posted any roadmaps indicating when they plan on implementing E1.31-7
I''ve not seen any, I know some of the "pro" companys will be adding this in moments after the standard is ratified.
 

multicast

Senior elf
Joined
Jul 13, 2013
Messages
715
David_AVD said:
dkulp said:
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.

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.


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.
 

multicast

Senior elf
Joined
Jul 13, 2013
Messages
715
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.
 

multicast

Senior elf
Joined
Jul 13, 2013
Messages
715
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.
 
Top