PDA

View Full Version : PropController - sACN (E1.31) to DMX Node



DynamoBen
04-15-2011, 11:49 AM
I started a proof of concept project last night and was able to stitch together some code to turn the PropController into a 4 port (4 universe) DMX node. At present it takes sACN (E1.31) in and outputs data to four separate DMX connections. I have to do some more testing but it looks good so far.

From a hardware point of view the only thing needed to build this are some RS485/DMX daugtherboards. In a perfect world the daugtherboards could be either isolated or non-isolated by populating different sections of the same board. Thoughts, Opinions?

chilloutdocdoc
04-15-2011, 02:03 PM
What I plan on turning my PropController into for my show :)

DynamoBen
04-15-2011, 02:10 PM
What I plan on turning my PropController into for my show :)

Awesome. Well the good news are the basics are covered, now it's a matter of making it nice and tying up the loose ends.

Beyond the basics there are some design choices that need to be made to make this more user friendly. For example if you use 4 universes of sACN data then you have to use up all the available sockets. Which is fine until you want to use DHCP, now you need to close one socket, talk to the DHCP server, and then reopen the socket for sACN data. Some would say you only need to do this at boot but you need to remember DHCP is lease based so every 3 days this needs to happen and will take a couple of seconds to complete. So the design decision is if DHCP should be allowed or not.

This is one of many design choices I've been considering.

chilloutdocdoc
04-15-2011, 02:15 PM
Awesome. Well the good news are the basics are covered, now it's a matter of making it nice and tying up the loose ends.

Beyond the basics there are some design choices that need to be made to make this more user friendly. For example if you use 4 universes of sACN data then you have to use up all the available sockets. Which is fine until you want to use DHCP, now you need to close one socket, talk to the DHCP server, and then reopen the socket for sACN data. Some would say you only need to do this at boot but you need to remember DHCP is lease based so every 3 days this needs to happen and will take a couple of seconds to complete. So the design decision is if DHCP should be allowed or not.

This is one of many design choices I've been considering.


Wasn't there talk of getting more than one universe through in a socket?

DynamoBen
04-15-2011, 02:38 PM
Wasn't there talk of getting more than one universe through in a socket?

Sure there was talk of it and that might be possible, at present I don't have to time to investigate it though. Take a look at Raw mode in the W5100 datasheet to see if this is feasible. If that works that will open up a number of amazing possibilities.

chilloutdocdoc
04-15-2011, 06:07 PM
lol let me understand how to get it working in any mode first! i'll take a look though.. (remember total newb here)

DynamoBen
04-15-2011, 06:08 PM
lol let me understand how to get it working in any mode first! i'll take a look though.. (remember total newb here)

Once I've done a bit of testing and cleanup I will post all the code to the google project stie, then you can get a jump on it. ;)

pmscientist
04-15-2011, 06:57 PM
E1.31 to RS485 DMX is certainly something I'm interested in, hopefully will have time to incorporate that this year.

Have you given any thought to using the WIZ830MJ down the road? It supports 8 sockets, and does DHCP internally, among other features. Same price as the 812/811, just a bit bigger foot print.

DynamoBen
04-15-2011, 07:09 PM
Have you given any thought to using the WIZ830MJ down the road? It supports 8 sockets, and does DHCP internally, among other features. Same price as the 812/811, just a bit bigger foot print.

I don't believe it supports SPI which means that we would loss several I/O pins to accommodate it.

pmscientist
04-15-2011, 07:19 PM
Ahh, that's what I get for not reading the data sheet. I suppose you could use an SPI or I2C to MCU bridge, but that adds a couple bucks to the component cost, and the code probably gets a bit more complex too.

steve_hirst
04-15-2011, 07:38 PM
so your looking at a prop based ecg-dr4? it does the same thing along with renard and hyper dmx.

DynamoBen
04-15-2011, 08:13 PM
Ahh, that's what I get for not reading the data sheet. I suppose you could use an SPI or I2C to MCU bridge, but that adds a couple bucks to the component cost, and the code probably gets a bit more complex too.

There are three ways to overcome this "problem":

1. Make strategic design choices and compromises
2. Sacrifice I/O pins to gain functionality of WIZ830MJ (would require a rework of the board)
3. Create an an alternative Ethernet interface that uses the WizNet pinout

Right now option one is the right choice, however in the future if there is need I would suggest option three. The third option would require someone to design an ethernet module that is pin compatible (or at least the pins I'm using) to the Wiznet but offers additional functionality that the Wiznet lacks. I suspect this wouldn't be that hard to do with a modern PIC processor which could be teamed up wit a PCB that matches the WizNet footprint.

DynamoBen
04-15-2011, 08:15 PM
so your looking at a prop based ecg-dr4? it does the same thing along with renard and hyper dmx.

I have some untested Renard code but nothing for hyperDMX. Is hyperDMX a published protocol?

chilloutdocdoc
04-15-2011, 08:48 PM
There's documentation somewhere over at AusChristmasLighting.
As for the Renard code, I'll be able to put it through it's paces when my board comes.

jstjohnz
04-17-2011, 03:02 AM
I just finished laying out a board for an 8-universe E1.31 bridge using the WIZ830. It takes 16 I/O pins for the 830. With 4 taken up by the prog port and eeprom, and 3 more for a pushbutton and a couple of LEDs, I have 9 left over. 8 of those will be DMX outputs. This will be a one-way only board, E1.31 in, DMX, HYPERDMX, or PIXELNET out.

The big unknown is how much tweaking will have to be done to the 812 drivers to work with the 830. It may very well turn out to be more trouble than it's worth. I haven't compared the data sheets enough to know how much they differ.

I don't think it's feasible to try to get 8 universes out of an 812 in spi mode. IIRC, it takes just under 4ms to acquire an E1.31 packet using SPI mode of the WIZ. at 44 hz, 6 universes would be the theoretical limit. And with raw mode you have to receive and examine every udp packet that comes down the network.

An 812 using indirect mode might be fast enough to use raw mode to do more than 4 universes. I still have my original bridge board that is laid out for the indirect interface. I don't remember how long it took to process each packet, but I know it was quite a bit faster than the SPI version.

The other issue is, to do 8 universes of DMX, one cog would have to be able to handle 2 universes. Probably do-able at 250kbps. Or maybe limit it to 7 universes of DMX, or 2 of hyper-dmx, or 1 of pixelnet.

DynamoBen
04-17-2011, 12:13 PM
2 and 4 DMX outputs per ethernet node is a fairly common configuration in the lighting world. It's a rare case that you need 8 universes of DMX all in one location and in those situations it's often easier to just place two nodes there.

If 8 outputs are required then it will be a pretty dramatic change in design and concept. Which could include switching to a different micro, using multiple micros, or being really creative with the code (IE two DMX outs per cog). Is 8 something I should be considering for future or is 4 good for now?

jstjohnz
04-17-2011, 01:34 PM
I think I agree with you. 8 DMX outputs is a lot. My main reason for doing this is to get a chance to play with the 830. Strictly looking at it as a protocol converter, having 8 available universes would let you do 2 hyper-dmx outputs (2k chans ea I think) or 1 pixelnet output (4k channels).

DynamoBen
04-17-2011, 01:39 PM
For clarity for others reading this thread, the PropController can have as many DMX outputs as you want. The limitation is the number of sockets available which is 4. So you could have 8 DMX outputs but you would only be able to source 4 universes of data which would mean that 1/2 of the outputs would output duplicate data, sort of like a DMX splitter.