PDA

View Full Version : E1.31 Protocol Discussions



j1sys
06-10-2010, 03:11 PM
Greetings -

Subject to DynamoBen's approval I thought I'd open a new thread in the DMX area for GENERAL discussion on the E1.31 Protocol.

I know Ben has been preaching for years that ArtNet, ACN, DMX over Ethernet is the future of DIYC. I happen to agree with him and for that reason took the direction I chose on all of my hardware/software designs. I will try not to mention my stuff too often in this thread. The idea is to continue discussions on things like "How many full universes per second can we push through a 100BaseT connection?" "What is the latency of given transports?" "What is the TTL for in multicast?"

There is a full specification available from ESTA for $40 that I'm sure that Ben has mentioned elsewhere. Since I paid the $40 I am constrained by license agreement from sharing the PDF and also don't want to be part of any other 'Draft' release discussions.

However I believe I can release derivative works and make direct quotes from the document when it is necessary to define the 'specified' interaction of E1.31.

To start it off I've attached the source code of the C# class that I use in my plugins to generate E1.31 packets. They are available elsewhere but may be the starting point for people to understand the 3 layers to the packet and it's format.

This discussion and the discussion of the Vixen plugin belong in this area as they are open source public discussions of industry standards. I will also include a thread describing the work on the LightShowPro plugin which I am working on with David. It may be for a proprietary system but IMHO belongs under the umbrella of DMX discussion.

Also, please don't ignore these discussion because you are a Renard or LOR user. Using E1.31 as a transport mechanism to a gateway device (see I didn't name my product) for ultimate delivery to a Renard or LOR signal chain is part of the beauty of E1.31

So please let the questions and answers begin.

-Ed

to make the .cs file upload I had change it to a .txt file. we might ask macrosill to add .cs, .h, .c files to the allowed list or we will always need to zip them.

mschell
06-10-2010, 04:10 PM
Ed,
Glad to see this topic raised and discussed. I'm believing that as things go forward, with larger and larger number of channels, etc., we will need to start utilizing better transport protocols to get data to the controllers, etc.

So better to start talking about it now, before it goes mainstream.

I'm excited that we're also talking with developers of different programs, so this becomes more universal.

DynamoBen
06-10-2010, 05:45 PM
Just so everyone is aware, I'm currently making "building blocks" based around the propeller microprocessor. Not surprisingly one of them has a DMX input but other has Ethernet. I haven't done any code for E1.31 but I hope to in the future. This building block should allow ppl to not only directly drive things like dimmers, leds, and motors but also could be used to build a node.

Hardware is being peer reviewed and then I need to send them to the board house to make protos.

http://doityourselfchristmas.com/forums/showthread.php?t=11109

aususer
06-10-2010, 11:13 PM
Its a fascinating discussion.. ethernet controlled lights..
I'll thow in ideas including 802.2q into the fray (I suspect that vlan'ing might have a direct impact on all your calculation of universes too);
and hardware items like PoE (802.3af) - addressing hardware/power ideas too.

I am not a programmer of any sort - I have command/compile level experiance with linux - my "normal" job is NetAdmin and have packet-level understanding of IP networks.

I can't help but see that there is a very logical future for E1.31. (what with 802.3 being so "easy" for joe-blow to get their hands on... and well understood)

I'd love to see the "sourceforge"-style coding effort to turn a linux box into an E1.31 node and make it into (say) a Native Reynard controller (cheap); DMX controller (more expensive); or XYZ protocol. All achivevable at very low costs.
I know that more "professsional" results are achived by the great work of J1SYS etal. but maybe we can start leaveraging of those programmers who cut code for a living?!

In case anyone cares... "Wireshark" now has ACN/E1.31 decoding streams in it - maybe it will help decoding what is being sent out etc...

I look in interest to see if there is anything I can do to progress this subject!

DynamoBen
06-10-2010, 11:16 PM
I'd love to see the "sourceforge"-style coding effort to turn a linux box into an E1.31 node and make it into (say) a Native Reynard controller (cheap); DMX controller (more expensive); or XYZ protocol. All achivevable at very low costs.


Check these out:
http://opendmx.net/index.php/OLA

http://openacn.engarts.com/

j1sys
06-10-2010, 11:33 PM
Yes the whole spectrum of ip protocols come into the 'proper' designing of a complex LAN. But for most people with $29 Ethernet switches they just need to think about simple isolation techniques to ensure that their LAN does not interfere with their UDP traffic. One reason I recommend using unicast over multicast for gateway devices is that simple (cheap) switches will isolate your LAN traffic somewhat while multicast will be treated like a broadcast and zing all over your LAN.

My recommendation for a show network computer would be to use dual Ethernet controllers if possible. One for the lighting control LAN and the other one for connection to your office/home LAN. If using a laptop/netbook then I would connect the lighting LAN to the Ethernet and use it's wireless to connect to your home/office LAN. This split horizon will keep contention at a minimum.

Even more fun will be had when we see 10,000 channel setups (I heard a rumor of one being planned) that may use multicast sensing switches or routers to help smooth the traffic flow.

As for POE we already have all smd POE devices on the drawing board and entering prototype stage.

DynamoBen
06-11-2010, 12:23 AM
The bummer about POE is that there isn't much in the way of consumer level POE switches so you a forced to buy or make injectors when can get a bit unwieldy.

j1sys
06-11-2010, 12:25 AM
$50-$70 netgear units aren't consumer grade?

Oops- trendnet $70 netgear $120

but I have seen some off brand in the $50 range.

DynamoBen
06-11-2010, 01:05 AM
$50-$70 netgear units aren't consumer grade?

Oops- trendnet $70 netgear $120

but I have seen some off brand in the $50 range.

I guess thats not too bad, still more expensive than an "standard" switch. I'm used to buying commerical POE switches.

aususer
06-11-2010, 01:25 AM
"seek and ye shall find" thanks for the links.
Might have to see how far I go with gcc for a software-based E1.31/Reynard gateway (to allow me to "retro-fit" my current environment) before I drown :)

Re: your $29 hub - I take your point, but considering I can buy an 8port TPLINK with 802.3q for $AU170 its not something that should be discredit out of reach.
I conceed that I haven't seen how much data we are talking about yet.. threads I read put it at ~260Kbs for 1 DMX512 universe (??) @ 10,000channels that would be ~5.2Mbs of raw..

E1.31 does tick a LOT of boxes for me (ie. I run ESXi - and usb/serial is a no-no.. thus I have to have a dedicated show PC :()
it also gives me some project ideas too:
eg. I just threw out old laptops that could have been software-hacked into 22x22 (1universe) "pixel" display (ie. like ledtrix - just using LCDDisplayed-pixels not LEDS).
Put 9 screens in a matrix (I just threw out 9)... 9 dmx universes - wack them all into a waterproof, perspex case.. Run lightshowpro transforms or Madrix..
Not a LED in sight.
you get the idea..and all very do'able by DIYrs.. (old notebooks are e-waste to most companies).

I do have a qustion regarding the E1.31...
Can you have more than one initiator throwing signals out?
I'm looking at ways I could intigrate "kick/stamp pads" into this - and if I can inject E1.31 data from anywhere - I can make a display interactive.

DynamoBen
06-11-2010, 01:37 AM
I do have a qustion regarding the E1.31...
Can you have more than one initiator throwing signals out?
I'm looking at ways I could intigrate "kick/stamp pads" into this - and if I can inject E1.31 data from anywhere - I can make a display interactive.

Yes, the protocol has a priority field. So your kick/stamp source would have a higher priority and the device would takes its values over another. This does however assume that everything involved adheres to the spec.

Also as a side note, there was some work not the long ago to get OLA to run on a Asus Router. I gave up because of my lack of *nix knowledge, not sure if you might be interested in that.

aususer
06-11-2010, 03:57 AM
Yes, the protocol has a priority field. So your kick/stamp source would have a higher priority and the device would takes its values over another. This does however assume that everything involved adheres to the spec.

Yipee... see sounds like the worlds most perfect protocol!! Why is anyone still developing non-standard DMX/Renard protocols!?!?! :D



get OLA to run on a Asus Router.....not sure if you might be interested in that.

Ohh Ohhh... yes please... those ASUS routers are essentially a linux box... (like the LinkSYS WRT hack!).. if there is a way to get that thing to listen to E1.31 (and maybe even drive a comport with reynard TX) even better!!!

OK.. I want to clarify things... I am reading OLA, ACN, ARTNET, E1.31 etc... we are talking about the same, interchangeable thing here right?! They are all interchangeable?
(I use the analogy of train lines: small, medium, narrow gauge - are all "train lines" - but not all trains can use any one of them)

I'm crossing my fingers that if I find some way to develop my ideas using OLA then it will "WORK" with something that pushes out E1.31 too?!!

Forgive me guys... its friday night - a long weekend, I'm still at work, and I need a beer (and the fridge is empty ;))

DynamoBen
06-11-2010, 10:44 AM
Ohh Ohhh... yes please... those ASUS routers are essentially a linux box... (like the LinkSYS WRT hack!).. if there is a way to get that thing to listen to E1.31 (and maybe even drive a comport with reynard TX) even better!!!

OK.. I want to clarify things... I am reading OLA, ACN, ARTNET, E1.31 etc... we are talking about the same, interchangeable thing here right?! They are all interchangeable?
(I use the analogy of train lines: small, medium, narrow gauge - are all "train lines" - but not all trains can use any one of them)

I'm crossing my fingers that if I find some way to develop my ideas using OLA then it will "WORK" with something that pushes out E1.31 too?!!

Forgive me guys... its friday night - a long weekend, I'm still at work, and I need a beer (and the fridge is empty ;))

Disregard the title (all we had was an artnet plugin at the time):
http://doityourselfchristmas.com/forums/showthread.php?t=10690

If you can get OLA working on this thing it has a USB port. The thought was to place a DMX dongle(s) or serial interface and away you go. The best part is they are around $30 each.

Tear it up and let me know how I can help. I have the hardware open on my bench collecting dust at present.

aussiephil
06-11-2010, 11:28 AM
Yipee... see sounds like the worlds most perfect protocol!! Why is anyone still developing non-standard DMX/Renard protocols!?!?! :D


Could not agree more about non-standard protocols.

Output E1.31, let the gateway drop each DMX universe out to the right blue cable and hook up your DMX controller.

Or just build E1.31 support straight into the controller, what i will be doing next year.

Cheers
Phil

Ps. Michael... you really want that stamp pad.... (i love the idea btw)

aususer
06-11-2010, 05:12 PM
Phil: "you really want that stamp pad" - What.. is it that obvious? :rolleyes:

DynamoBen, etal: I wish to thank you for your assistance and patience. At this point my ideas are flowing thick-and-fast - if only I knew how to program (just not sure if this old dog can be taught that trick... but I will give it a go).

Thanks for the offer of assistance... I may just need that (I was lying in bed last night thinking... "now how do I make linux display a 22x22 colour matrix".

How do you guys ever get any sleep!!!!! ;)

j1sys
06-11-2010, 05:31 PM
don't you know the programmers motto: sugar and caffeine and no need to sleep!!

nomis52
06-11-2010, 05:52 PM
Ohh Ohhh... yes please... those ASUS routers are essentially a linux box... (like the LinkSYS WRT hack!).. if there is a way to get that thing to listen to E1.31 (and maybe even drive a comport with reynard TX) even better!!!


If you want something that works now: http://opendmx.net/index.php/OLAGuruPlug

It's slightly more expensive hardware, but it's a *supported* config.

As a random note, it's looks likely that these devices will be at LDI in Vegas this year as part of the RDM/ACN connectivity pavilion.

Simon

aususer
06-15-2010, 01:02 AM
the only WRTs I have are WRT54G-V7... unable to run OpenWRT (not enough ram! bugger! :mad:)


If you want something that works now: http://opendmx.net/index.php/OLAGuruPlug

What a great product!
Guru plug is certainly a great idea and well worth investigating as part of the device development of this platform.

In my eyes - I am all for "standards" so we don't have to care what hardware we use.
(I come from the IT days when you could be using "Ethernet", "Blue Book Ethernet", "Red Book Ethernet" and "Ethernet II" to communicate between devices - depending on what vendor you were working with... it was ugly.
In Feb 1980 the IEEE ratified Draft 3 - and was eventually accepted by OEM's - and now what we now know as "802.3" ethernet... a standard that all devices that conform should work with.
As a result, you can now buy a 802.3-compliant switch from your local computer shop, plug it in and know that it will work with your mac, PC, RS9000, ATMEL etc. )

I just want to see if its easy for someone as dumb as me to be able to take some old, junk equipment and make it into something useful again
(and does my increased power usage as a result negate my e-cycling view here :D ????)

Matt_Edwards
06-15-2010, 02:03 AM
One concern I have about the GuruPlugs is the reliability. There are numerous reports stating this is an issue, like this one (http://1wt.eu/articles/guruplug-slow-heater/).
Do the latest GuruPlugs have this issue?

mrpackethead
06-15-2010, 02:37 AM
I've got two Guru-plugs and yes they have problems if you plug them into Gigabit networks, if you run them at 100MB they seem fine.. Had one running for 4 weeks no problems.

nomis52
06-16-2010, 12:30 PM
I've got two Guru-plugs and yes they have problems if you plug them into Gigabit networks, if you run them at 100MB they seem fine.. Had one running for 4 weeks no problems.

I've had the same issue when using GigE networks and to be fair they've offered to replace the unit for me.

I agree with the comments about the software on the plug being sub-standard. It feels like the software image was hacked together in a couple of days (config & init scripts in /root etc.), but that can all be fixed.

neilric99
07-21-2010, 07:23 PM
If you want something that works now: http://opendmx.net/index.php/OLAGuruPlug

It's slightly more expensive hardware, but it's a *supported* config.

As a random note, it's looks likely that these devices will be at LDI in Vegas this year as part of the RDM/ACN connectivity pavilion.

Simon

I am going to LDI this year and will be most interested in the DIY side as well as looking at the LED matrix tools.

DynamoBen
07-21-2010, 08:04 PM
I am going to LDI this year and will be most interested in the DIY side as well as looking at the LED matrix tools.

LDI is not really geared toward the DIY side. Its really an opportunity for theatrical and concert lighting manufacturers to show off their new and existing products.

neilric99
07-21-2010, 08:12 PM
LDI is not really geared toward the DIY side. Its really an opportunity for theatrical and concert lighting manufacturers to show off their new and existing products.

yes and thats also what I will be going to see and attend the LDI conference sessions to catch up with the latest technology.

DynamoBen
07-21-2010, 08:21 PM
yes and thats also what I will be going to see and attend the LDI conference sessions to catch up with the latest technology.

Fair enough then you are going to the right place. ;) BTW stop by the ETC booth and check out EOS, I had a hand in its creation.

dgirard
09-23-2010, 02:54 PM
I got excited about the ESX comment below...I thought about it myself a few days ago...the only problem...sound...

I've seen some Ethernet->USB converters with which I could use a USB audio adapter (envision--my FM broacaster with a network port on the front instead of audio-in!)....ethernet to FM!

the only problem is I've yet to find a "cheap" one...




"seek and ye shall find" thanks for the links.
Might have to see how far I go with gcc for a software-based E1.31/Reynard gateway (to allow me to "retro-fit" my current environment) before I drown :)

Re: your $29 hub - I take your point, but considering I can buy an 8port TPLINK with 802.3q for $AU170 its not something that should be discredit out of reach.
I conceed that I haven't seen how much data we are talking about yet.. threads I read put it at ~260Kbs for 1 DMX512 universe (??) @ 10,000channels that would be ~5.2Mbs of raw..

E1.31 does tick a LOT of boxes for me (ie. I run ESXi - and usb/serial is a no-no.. thus I have to have a dedicated show PC :()
it also gives me some project ideas too:
eg. I just threw out old laptops that could have been software-hacked into 22x22 (1universe) "pixel" display (ie. like ledtrix - just using LCDDisplayed-pixels not LEDS).
Put 9 screens in a matrix (I just threw out 9)... 9 dmx universes - wack them all into a waterproof, perspex case.. Run lightshowpro transforms or Madrix..
Not a LED in sight.
you get the idea..and all very do'able by DIYrs.. (old notebooks are e-waste to most companies).

I do have a qustion regarding the E1.31...
Can you have more than one initiator throwing signals out?
I'm looking at ways I could intigrate "kick/stamp pads" into this - and if I can inject E1.31 data from anywhere - I can make a display interactive.

bobkeyes
09-23-2010, 11:23 PM
Has anyone heard from Ed lately? I've email, called, etc. NO GO!

Ausiephil--Have you heard from him? Is he OK?

budude
09-24-2010, 12:10 AM
Has anyone heard from Ed lately? I've email, called, etc. NO GO!

Ausiephil--Have you heard from him? Is he OK?

He's been posting on Phil's site - sounds like he's been ultra busy putting new goodies out...

jstjohnz
09-28-2010, 03:54 PM
I am working on being able to receive E1.31 using a WIZ 812 ethernet module. As I get into this a bit deeper, a lot of questions are popping up.

What is presently available as far as software that will transmit E1.31, to use for debugging?

Typically, is a E1.31 transmitter configurable as to unicast or multicast, or both? What is the most common setup?

It would seem as though multicast would be the easiest plug and play.

So if I am a E1.31 receiver I need to look for packets from 239.255.x.x with destination port of 5568, correct?

I guess where I'm not clear is how to configure the WIZ module to look for UDP packets from 239.255.x.x. The packet structure itself looks pretty straightforward.

DynamoBen
09-28-2010, 04:06 PM
What is presently available as far as software that will transmit E1.31, to use for debugging?

Vixen is can do it, there is also a sticky that has a tool that will stream E1.31.
http://doityourselfchristmas.com/forums/showthread.php?t=184



Typically, is a E1.31 transmitter configurable as to unicast or multicast, or both? What is the most common setup?

Most devices I've used are multicast.


So if I am a E1.31 receiver I need to look for packets from 239.255.x.x with destination port of 5568, correct?

Correct, the multicast address lets you know which universe you are listening to.


I guess where I'm not clear is how to configure the WIZ module to look for UDP packets from 239.255.x.x. The packet structure itself looks pretty straightforward.

ftp://ftp.efo.ru/pub/wiznet/W5100_HowtoMulticasting_En_v1.0.pdf

jstjohnz
09-28-2010, 04:24 PM
Thanks for the link to that pdf, haven't read it yet but it sounds like exactly what I need. After posting above I found a tool called SACNLINK that seems to be perfect for testing.

DynamoBen
09-28-2010, 04:26 PM
....SACNLINK that seems to be perfect for testing.

That could work too, I downloaded that the other day but didn't spend much time with it.

nomis52
09-28-2010, 05:03 PM
What is presently available as far as software that will transmit E1.31, to use for debugging?

Typically, is a E1.31 transmitter configurable as to unicast or multicast, or both? What is the most common setup?


A list of E1.31 software is here: http://opendmx.net/index.php/Category:E1.31


Simon

Mickpat
01-14-2012, 07:23 PM
Hello Ed,

Do you have an sample C# project you could share or an example of how to call the class? Thanks.

Michael

Mickpat
01-14-2012, 07:51 PM
Hello Ed,

Do you have an sample C# project you could share or an example of how to call the class? Thanks.

Michael

I found the Vixen plug-in which is exactly what I needed.

j1sys
01-17-2012, 03:06 PM
I found the Vixen plug-in which is exactly what I needed.

that was what i was coming in to reply ....

only thing i've ever used it in. source was also provided to several software vendors. don't know how much they changed in their releases.

-Ed

cenote
01-17-2012, 10:02 PM
Quick question, can you hook up the E1.31 to DMX bridge directly to your network card on your pc, or do you need to hook to your router? Just wondering, if my show computer needs to be hooked to my network, or run independently for show.
Thanks

budude
01-17-2012, 10:15 PM
Quick question, can you hook up the E1.31 to DMX bridge directly to your network card on your pc, or do you need to hook to your router? Just wondering, if my show computer needs to be hooked to my network, or run independently for show.
Thanks

Either is fine - directly to PC or via a switch port.

Matt_Edwards
01-17-2012, 10:16 PM
Quick question, can you hook up the E1.31 to DMX bridge directly to your network card on your pc, or do you need to hook to your router? Just wondering, if my show computer needs to be hooked to my network, or run independently for show.
Thanks

Yes. Straight or cross over cable should work. My E31.1 network is on a different subnet to my home network, but also has physical separation. The show PC also has a Wireless Lan for connection to the home network.

cenote
01-17-2012, 10:20 PM
Thanks, hoping for that answer.
Chuck

timon
08-07-2012, 08:33 PM
Question for the E1.31 gru's. Can more than one source send commands to a single E1.31 controller as long as the don't try to control the same universe?

nomis52
08-07-2012, 08:36 PM
Question for the E1.31 gru's. Can more than one source send commands to a single E1.31 controller as long as the don't try to control the same universe?

That's perfectly fine. In fact multiple controllers can send data for the same universe. The priority field (and possibly other data) is used by the sources to decide how to merge the data.

DynamoBen
08-07-2012, 09:03 PM
In fact multiple controllers can send data for the same universe. The priority field (and possibly other data) is used by the sources to decide how to merge the data.

Just a word of caution that most of the projects here don't use the priority field.

jstjohnz
08-07-2012, 09:46 PM
There's also an extension of the spec drfined by ETC that allows one sender to control part of a universe while another sender controls another part.

neilric99
08-08-2012, 12:38 AM
There is an option in DMX/sACN called HTP (Highest Takes Presedence), unfortunatly no-one is supporting that option yet in the hobby based controllers that we use. As we start looking at the commercial market then this feature becomes much more a requirement.



That's perfectly fine. In fact multiple controllers can send data for the same universe. The priority field (and possibly other data) is used by the sources to decide how to merge the data.

jstjohnz
08-08-2012, 02:34 AM
There is an option in DMX/sACN called HTP (Highest Takes Presedence), unfortunatly no-one is supporting that option yet in the hobby based controllers that we use. As we start looking at the commercial market then this feature becomes much more a requirement.

Yes, but.... HTP generally can't accomplish anything useful when you're driving pixels when you're driving pixels.

timon
08-09-2012, 12:41 AM
I don't see it as strictly commercial. I'm planing to put in all my landscape lighting but I modify then with RGB lights and DMX controllers. I'm also going to modify the carrage lights on my house with RGB as well.

Normally they will be controlled by the home automation controller, it has Ethernet access, but the show computer should be able to override. The issue I see, not knowing how HTP works yet, is will it still override the home automation system when it's idling between shows.

If none of the existing controllers add it then I guess I could modify RPM's code. Was it in the draft specification which I thing is floating around?


There is an option in DMX/sACN called HTP (Highest Takes Presedence), unfortunatly no-one is supporting that option yet in the hobby based controllers that we use. As we start looking at the commercial market then this feature becomes much more a requirement.

mschell
08-09-2012, 08:59 AM
I believe Neil's reference to commercial market meant that HTP is expected to be included and supported in commercial products. Most folks in the hobby controller market aren't expecting to have multiple E1.31/sACN sources driving the network, and therefore the "need" for HTP isn't as great.


HTP means, I believe, that the highest value for a given channel takes precedence on any lower values sent out for that channel. So if your home automation controller was sending a command to have a given channel for your flowerbed to be at 25%, any commands from your show computer to have the light go lower than 25% would be ignored. There's also LTP, which is Lower Takes Precedence, and probably some other variations that I can't recall at the moment.

David_AVD
08-09-2012, 05:36 PM
You could also get the "background source" to monitor the universe(s) it's sending and cease transmission when it sees packets that it didn't send. Each E1.31 packet has fields for sender name and sequence number so should be easy enough to detect packets from other sources.

timon
08-09-2012, 08:13 PM
Having the background monitor traffic would work but the processor in the home automation system might not be able to handle the load. Even when it's sending E1.31 packets it would be not sending at the rate a show would run so it it had to monitor full traffic speed the processor might get overloaded. I'm not sure what the minimum speed you have to send is but I expect the HA would only send a background update one a second or so then speed up to a full 40 frames per second when changing the intensity of a channel.

BTW, do the E1.31 controllers work like the intelligent DMX controllers and keep sending the last set of data they received from the source to the DMX output or is it one E1.31 packet to one DMX output sequence like a dumb DMX controller? I haven't got that far in the specs to figure that out yet.

If I'm reading the draft correctly the priority field can handle this for a given universe. So if the HA send packets at a lower priority than the show computer then as long as the show computer is sending the packets from the HA would be ignored. When the show computer stopped the HA traffic would be processed. I'm assuming that the priority test is effectively stretched over some number of seconds so it's not bouncing back and forth.

This seems to be to be a very easy addition to make. You just need the ability to set the priority in the sender, i.e., vixen, xlights, LSP and LOR S3 etc or the HA. Since the HA code has yet to be written that would be the quickest one to change. Just have it default to a value less than 100 and it's done. The last point is that you would need to be able to shutdown E1.31. packets when the show was not running. I'll have to fire up the packet sniffer and see if any of the the sequencers do that.

Since the landscape lighting will all be P-DMX, either RJ45 or Ray's waterproof connectors, it might be an interesting project to layout a modified PCB using RPM's design and set it up for P-DMX. I like this rather than two boards. Shouldn't take much modification of RPM's code to add in the priority feature.

I was going make an intelligent DMX splitter that took in two DMX universes and switch them based on one of the channels and then drive it from a RPM's USB Dongle but E1.31 has a lot of advantages.

This is so much fun:biggrin2:

John

David_AVD
08-09-2012, 11:15 PM
The priority idea would work, but only if the E1.31 receiver implements it. I don't think any of the current (Christmas style) controllers do?

jstjohnz
08-09-2012, 11:29 PM
Having the background monitor traffic would work but the processor in the home automation system might not be able to handle the load. Even when it's sending E1.31 packets it would be not sending at the rate a show would run so it it had to monitor full traffic speed the processor might get overloaded. I'm not sure what the minimum speed you have to send is but I expect the HA would only send a background update one a second or so then speed up to a full 40 frames per second when changing the intensity of a channel.

BTW, do the E1.31 controllers work like the intelligent DMX controllers and keep sending the last set of data they received from the source to the DMX output or is it one E1.31 packet to one DMX output sequence like a dumb DMX controller? I haven't got that far in the specs to figure that out yet.


Since the landscape lighting will all be P-DMX, either RJ45 or Ray's waterproof connectors, it might be an interesting project to layout a modified PCB using RPM's design and set it up for P-DMX. I like this rather than two boards. Shouldn't take much modification of RPM's code to add in the priority feature.

I was going make an intelligent DMX splitter that took in two DMX universes and switch them based on one of the channels and then drive it from a RPM's USB Dongle but E1.31 has a lot of advantages.

This is so much fun:biggrin2:

John

As far as my controllers, the currently buffered data is sent out continuously to the DMX outputs, regardless of how fast it's coming in. In theory E1.31 isn't supposed to be sent at a higher rate packet rate than the 250kbps serial DMX, but sometimes a sender will exceeed that rate. It's common to have an option to turn the outputs off if the sender stops sending data for a period of time.


I have not implemented priority checking yet, but it's fairly trivial. You just need to maintain a variable that contains the current highest priority for each universe, and a timer with elapsed time since the last packet was received at that priority. If a lower priority packet comes along it's ignored. If a higher priority packet comes along that becomes the new highest priority value and the timer gets reset. The spec doesn't get into the detail of timeout of priority.

jstjohnz
08-09-2012, 11:33 PM
I believe Neil's reference to commercial market meant that HTP is expected to be included and supported in commercial products. Most folks in the hobby controller market aren't expecting to have multiple E1.31/sACN sources driving the network, and therefore the "need" for HTP isn't as great.


HTP means, I believe, that the highest value for a given channel takes precedence on any lower values sent out for that channel. So if your home automation controller was sending a command to have a given channel for your flowerbed to be at 25%, any commands from your show computer to have the light go lower than 25% would be ignored. There's also LTP, which is Lower Takes Precedence, and probably some other variations that I can't recall at the moment.

The problem with HTP, or any other non-trivial algorithm, is that it only makes sense for single channel lights. If I have one sender sending GREEN to a pixel, and another sending RED to the same pixel, HTP is going to give me a YELLOW pixel, probably not what was intended.

neilric99
08-10-2012, 12:28 AM
I did think about this last year when I was playing with LSP controlling Madrix and I wanted to get madrix to release its control of the sACN output so that I could send a sequence from LSP instead. Turns out I could not stop Madrix from sending out output (even though it was black, 0 value) to the channels on that universe. I believe having HTP would have helped in this case as Madrix would be sending 0 values for those channels and LSP would take presedance as they were sending an higher value for that channel. I do take your point though that this was really designed with single channel fixtures in mind and 3 / 4 channel RGB/W sort of breaks that.

rokkett
08-10-2012, 10:27 AM
As we have pointed out, using the HTP channel data resolution is problematic and is probably not what we want to do. What we really want to be looking at and processing is the data at the universe level, based on priorities.

When discussing universe priorities, the E1.31 documentation is referring to how we, the receiver, should decide which sender's packets will be processed by the device. In the case of multiple senders, e.i. the device detects two different sources of packets identifying themselves as containing data for Universe 1, the device should select the data from the E1.31 packet with highest priority. There is a one byte field in the E1.31 packet header, priority, that is used to send this data. The device is not be looking at the channel data, but rather this priority field.

So to implement the Christmas light show vs. landscape lighting:

Set the landscape lighting source set at priority of 50.
Set the Christmas light display at a priority of 100 (most software is defaulting to a value of 100, by the way.)

While the Christmas light show packets are not being sent, the priority of 50 is the highest, so the device should handle that traffic.

When the device detects the Christmas light show packets start showing up with the higher priority of 100, the device should stop processing the landscape lighting data and begin handling the Christmas light show data.

The E1.31 protocol requires a refresh packet be sent by a sender every 2.5 seconds, so once the device detects the sender with a higher priority has not sent an update for greater then 2.5 seconds, the device should then re-evaluate which senders data is at the highest priority, and begin processing that sender's data. There is no data merging going on here, only one senders data is processes at a time, based on priority.

The HTP conversation only comes into play when we detect two senders at the same priority for the same universe, but with the proper use of the universe priority, we can eliminate the data merging/HTP conversation completely.

So the question of the day - do the E68x devices handle E1.31 priority processing? If coding changes had to happen and I had a choice, I would want universe priority implemented first over data merging/HTP coding.

Technical details: The priority byte is located in byte location 108 of the header and can have a values ranging from a minimum of 0 to a maximum of 200.

neilric99
08-10-2012, 05:45 PM
good thinking Rokkett, it looks like the priority attribute in the e1.31 data packet could be used by the controller to determine what is being processed. And in the example of landscape lighting you could have you landscape lighting controller always on the produce a background and let the christmas lighting controller take over with a higher priority.

So what do youu think about this Ed at J1sys and Jim at Sandevices?

David_AVD
08-10-2012, 05:58 PM
As an aside, my da_E131 (https://www.audiovisualdevices.com.au/software/da_e131/index.php) software has the priority set to 100 normally, but you can change it in the settings. This would allow you to test receivers for priority based processing.

mrpackethead
08-10-2012, 08:09 PM
For what its worth, HTP will be included in the version 4.0 release of the Software that runs on the Stellascpaes E16..

neilric99
08-10-2012, 08:31 PM
thats good to hear Andrew, what is your valued opinion on the subject that we have been discussing on HTP and priority adn their use in the hobby market?

mrpackethead
08-10-2012, 08:43 PM
thats good to hear Andrew, what is your valued opinion on the subject that we have been discussing on HTP and priority adn their use in the hobby market?

Redundancy.

neilric99
08-10-2012, 08:58 PM
yes I can see redundancy and higher availability important to what you do.

timon
08-11-2012, 12:16 AM
Thanks Rokkett, you filled in several holes so I now have a better understanding. The fact that packets are required at least once every 2.5 sec works well when I figured the HA would send them out every second. Now the only issue, other than writing the code for the HA, is having a way to tell the show system when and when not to keep packets going out.

jstjohnz
08-11-2012, 01:43 AM
I agree that HTP could be useful in the case where one sender is idle and is sending all 0 packets. In most cases though I think that "respecting" the priority byte is a better solution in that a sender can take full control of a universe without having to know what another sender is sending. It is a fairly trivial feature to add to the software. HTP on the other hand is not trivial. You have to maintain a separate buffer of all of the DMX values from every sender. The other issue is that with multiple senders transmitting to the same set of universes, the controllers are going to be required to process N times the normal number of packets. That's going to be the choke point for most controllers.