wDMX

[MaxS]

Hey, I haven't been around the boards in a while - I've been busy with exams, but I was wondering if anyone has ventured into wDMX yet. (Sorry if this has been posted before; I didn't see anything in search.) I've worked with commercial products of the sort, but I haven't seen any talk of designing a DIY board around here. The commercially available products are fairly expensive, anywhere from $500 to $1100 for a transmitter/receiver set, so the cost of even building a prototype would have to be taken into consideration before any real progress would be made. Also, would there be FCC compliance hurdles with designing the PCBs/receivers/transmitter from scratch?

I'd be willing to help out/lead a project if I can get a few people interested. Wireless DMX would be huge as far as Christmas lighting goes, providing that it would be reasonably priced. It would make plotting, set-up, and tear-down at least twice as fast. Vote in the poll as to whether you'd use it, and if you're interested in helping to design a system just post.

(Wasn't sure if this should go in DMX or Development. If it belongs in the latter, please move it there.)

[JEC]

It's certainly a groovy concept. As you've probably seen, the high end commercial gear uses spread-spectrum frequency-hopping magic to get around potential interference.

Realistically, it's not often necessary to send an *entire* DMX universe wirelessly. Only 24/48/96 channels may be needed at the remote location. So dropping the channel count may reduce the bandwidth required, whilst ensuring a reasonable refresh rate on the datastream.

It'd probably be easiest to start with commercial (and FCC approved) wireless transmit/receive modules. Lynx makes some nice ones.

Throw in some code on the front and back to parse the DMX packets, possibly add some manchester modulation to keep the receivers happy, and be done with it.

I expect that a design which merely connects the RX line of an RS485 receiver directly to an RF transmitter would fail in spectacular fashion.

My $0.02. Neat project for sure.

JEC

[MaxS]

Good points.

As far as design goes, the whole shebang could be put on one PCB, which should make it pretty straightforward, but a modular system could be designed as well. I'm not sure which would be better yet. Anyway, the key to the project would be affordability, as well as front-end simplicity.

Also, after doing some digging, it looks like RJ was thinking the same thing and wants to integrate it into the Lynx II. Wonder why it hasn't been mentioned on this forum...
http://diylightanimation.com/index.php?topic=5.msg2749

[DynamoBen]

I concur with JEC. Some time ago I was looking into this and found several off the shelf RF devices that could handle 250K baud. All one would need to do is remove the RS-485 transceiver and insert the RF device.

I was looking at something like this:
http://www.sparkfun.com/commerce/product_info.php?products_id=153

[MaxS]

Hmm, I see what you guys are thinking now. That device is only spec'd to cover 50-120 feet, but for people with larger displays I would thinking something like this would work a bit better:

http://www.technilient.com/pdf/RFC2400A_1v8.pdf

That's got a 750mA 1w Tx current to it though, and although it operates in ISM band, the FCC only permits a maximum 50mV/m in the 2.4-2.4835GHz range. Documentation here:

http://edocket.access.gpo.gov/cfr_2007/octqtr/pdf/47cfr15.249.pdf

Well it's made in Malaysia, so just to be sure...
750mA = .75A
1w/.75A ≈ 1.3... V = L
L ≈ 4.72dBµ
4.72dBµ ≈ 0.001mV/m

I hope that's right - I don't calculate RF signal strength on a daily basis. =S Regardless, it operates using a compliant Nordic chip, so it should be fine. Right?

[JEC]

I concur with JEC. Some time ago I was looking into this and found several off the shelf RF devices that could handle 250K baud. All one would need to do is remove the RS-485 transceiver and insert the RF device.

I was looking at something like this:
http://www.sparkfun.com/commerce/product_info.php?products_id=153

For what it's worth (and there's a lot I don't know about the various RF modules, including the one listed above).

Some are complete modems. Insert serial data on the front, get serial data out the back. Just like a serial cable, just without the cable.

Some are only transmitter / receiver pairs without any underlying control logic.

It turns out that in RF-land, transmitting a long string of ones or zeros is difficult. The data has to be 'chopped' to keep the receivers in sync.

http://en.wikipedia.org/wiki/Manchester_code

The modems handle this in the background. The simpler transmit/receive pairs require that you encode your datastream before sending it.

Not that it's a big deal - a simple subroutine could handle everything easily. But it's something to consider.

[DynamoBen]

Hmm, I see what you guys are thinking now. That device is only spec'd to cover 50-120 feet, but for people with larger displays

Keep in mind they are being conservative with these distances. Also like any other RF technology the ratings are based on line-of-sight with perfect conditions.

[JEC]

Keep in mind they are being conservative with these distances. Also like any other RF technology the ratings are based on line-of-sight with perfect conditions.


<tangent>

Not to hijack the thread...

There may be an argument for building a set of DMX<-->ArtNet/ACN nodes. Then off-the-shelf wired and wireless networking gear can be used to distribute the data.

I believe about 40 universes of DMX can fit in an Ethernet cable on a private network.

</tangent>

[MaxS]

Keep in mind they are being conservative with these distances.
In my experience, specifications almost always exceed actual performance, which is the reason behind my posting of a more powerful RS485-ready 2.4GHz transceiver.

[JEC]

Hmm, I see what you guys are thinking now. That device is only spec'd to cover 50-120 feet, but for people with larger displays I would thinking something like this would work a bit better:

http://www.technilient.com/pdf/RFC2400A_1v8.pdf



That's a neat little board. Price?

[DynamoBen]

<tangent>

Not to hijack the thread...

There may be an argument for building a set of DMX<-->ArtNet/ACN nodes. Then off-the-shelf wired and wireless networking gear can be used to distribute the data.

I believe about 40 universes of DMX can fit in an Ethernet cable on a private network.

</tangent>


The hold up at the moment is a lack of a Vixen driver and the lack of supporting hardware. I'm having enough trouble finishing my multi-universe DMX dongle. :rolleyes:

[MaxS]

<tangent>

Not to hijack the thread...

There may be an argument for building a set of DMX<-->ArtNet/ACN nodes. Then off-the-shelf wired and wireless networking gear can be used to distribute the data.

I believe about 40 universes of DMX can fit in an Ethernet cable on a private network.

</tangent>
Isn't this essentially what ETC is doing with ETCNet2? They use regular network equipment for all connections as well. You have a good point in that it would be much easier to use existing wireless networking equipment. How does one configure TCP/IP over ACN?

[MaxS]

That's a neat little board. Price?
Not sure, you could call/email for a quote. I may do that if we roll with that idea, but see my above post first!

[JEC]

Isn't this essentially what ETC is doing with ETCNet2? They use regular network equipment for all connections as well. You have a good point in that it would be much easier to use existing wireless networking equipment. Would you have to mess with TCP/IP at all?

I'll defer to Ben on this one.

From what I understand, there are a few different ethernet-based DMX transmission standards out there. They're not compatible with each other.

However, both ArtNet and ACN are are free, open and have full documentation available. Particularly interesting to me is that lots of commercial lighting software does image-->pixel mapping and outputs ArtNet.

Normally the lighting guys will set up a private wired or wireless network between the control position and the various fixtures / dimmers.

If you're actually building a DMX<-->Ethernet bridge, I expect you'd need to be fairly comfortable massaging ethernet packets on a low level.

http://www.artisticlicence.com/index.php?mode=products&sub=category&action=&category_id=4&product_id=&project_id=&policies_id=&cart_id=&order_id=

A Lantronix X-Port may be just the ticket to making everything run smoothly, as it handles all the TCP/IP housekeeping on its own.

Somewhere on the artistic license site are a couple free programs which generate and analyze ArtNet packets.

[DynamoBen]

Isn't this essentially what ETC is doing with ETCNet2? They use regular network equipment for all connections as well. You have a good point in that it would be much easier to use existing wireless networking equipment. How does one configure TCP/IP over ACN?

Right, I actually designed and tested the system ETC is using while I worked there. BTW ETC is moving to ACN just like most large manufacturers which can traverse standard networking equipment w/o a problem.

[MaxS]

Heh, so there are definitely a few ways to go about this. For scalability and backward-compatibility I would think that DMX over ACN over Ethernet/802.3 would be the way to go, right? (Would that use the 802.11 or 802.3 standard?) But for simplicity, DMX over RS485 over ISM 2.4GHz would work as well. For the time being, because to lack of Vixen support for ACN, would it even be worth it to start developing an ACN-compliant system/DMX-ACN dongle? Phew, I got into a little more than I bargained for when asking about this. ;)


Normally the lighting guys will set up a private wired or wireless network between the control position and the various fixtures / dimmers.
That's exactly what ETC is doing in their systems. They use their proprietary ETCNet2 protocol and use the Ethernet/802.11 standard for everything. Consoles, servers, dimmer racks, and dimmer controllers are all connected to a central switch.

[JEC]

Heh, so there are definitely a few ways to go about this. For scalability and backward-compatibility I would think that DMX over ACN over Ethernet/802.3 would be the way to go, right? (Would that use the 802.11 or 802.3 standard?) But for simplicity, DMX over RS485 over ISM 2.4GHz would work as well. For the time being, because to lack of Vixen support for ACN, would it even be worth it to start developing an ACN-compliant system/DMX-ACN dongle? Phew, I got into a little more than I bargained for when asking about this. ;)

Yes, yes and yes.

:)

[MaxS]

All right, well I'll have to start looking into streaming ACN then. Post any more thoughts/ideas in this thread!

[DynamoBen]

For the time being, because to lack of Vixen support for ACN, would it even be worth it to start developing an ACN-compliant system/DMX-ACN dongle? Phew, I got into a little more than I bargained for when asking about this. ;)

You can but you will basically be creating a DMX to ACN gateway which is not going to be a trivial task. It would be best, in this case, to have someone crank out an ACN plug-in. It doesn't have to be the full ACN spec it could just be DMX-over-ACN (see my sticky). The request has been made in the Vixen plug-ins forum but not a lot of attention has been paid to it.

BTW you will need/want to buy a copy of the ACN spec from ESTA ($40).

[DynamoBen]

Post any more thoughts/ideas in this thread!

Start here:
http://doityourselfchristmas.com/forums/showthread.php?t=184

[MaxS]

You can but you will basically be creating a DMX to ACN gateway which is not going to be a trivial task. It would be best, in this case, to have someone crank out an ACN plug-in. It doesn't have to be the full ACN spec it could just be DMX-over-ACN (see my sticky). The request has been made in the Vixen plug-ins forum but not a lot of attention has been paid to it.

BTW you will need/want to buy a copy of the ACN spec from ESTA ($40).
Apparently ETC has already done exactly that, although the device is overkill. A gateway could be done though. It's designed for use with their new Net3 system, which is not proprietary. (See FAQ in the third link.)
The links are for their 4-Port gateway, but a 2-Port is also available, according to their catalogue (http://pdf.archiexpo.com/pdf/etc-architectural/etc-catalogue/9903-16000-_20.html).
Overview: http://www.etcconnect.com/product.overview.aspx?ID=20095
Documentation: http://www.etcconnect.com/docs/docs_downloads/datashts/Net3_4Port_Gateway_vA.pdf
FAQ: http://www.etcconnect.com/Community/blogs/davidlincecumsbrain/archive/2006/10/28/40.aspx



So what's up with Net 3? Why does it exist? Why did we call it that?

First off -- Net 3 is not ACN. ACN is a standard, a protocol description, a plan. Net 3 is a tool, a user experience, a tangible feature set.

But - ACN is a big part of our plan for Net 3. Most (but not all) Net 3 features are built on ACN and Net 3 supports integration with other ACN based networking solutions (when they come around!) We say Net 3 is "powered by ACN."

Net 3 remembers the past while welcoming the future. Many familiar protocols, like EDMX will work on Net 3 networks running newer hardware like Net 3 gateways.

Net 3 strives to solve real lighting problems beyond DMX distribution. See our integration with popular Media servers as an example.

Net 3 is performance tested. We use a system integration lab at ETC to test our equipment - and equipment by others - to insure an acceptable performance level is reached.

Net 3 supports expansion. This is a big difference from our previous networking protocols - we were tapped out. Net 3 is ripe with possibility.

Net 3 works with others. That's why we did not call it ETCNet 3. Net 3 supports interoperability with other ACN systems and with protocols like RDM as well.


The problem with a gateway though, is that you would have to have one on both ends, to bring the DMX-over-ACN back to the DMX devices (SSRs), as well as another wireless bridge before that if wireless was being used. It's looking like an ACN plug-in for Vixen would be the better way, but I'm not sure my programming skills are up-to-par.

[DynamoBen]

Correct Net3 is a "super set" of the ACN protocol. During my time there I was a member of the team developing the ACN protocol and the nodes you are referencing.

I think creating the plugin is a pretty straight forward task for anyone with any amount of ethernet programming expirence. The harder part is verification thats its is written properly...however I am willing to verify the code if someone is able to write it. You may want to "refresh" my thread in the Vixen plugin forums.

[ben]

Ok, I do not have any knowledge per say in this department I do want to say I will beta test and run this when needed. I am interested in going all DMX by next year and wireless DMX would be awesome!! I do not mind spending money on hardware to get this working. I want something that can be improved, not a miracle that it will work though. :p

Ben

[MaxS]

All righty, so providing we have the ACN plug-in written, what would system set-up look like? The whole thing should be done using 802.3x (802.3af could be implemented for PoE), which is compatible with 802.11x.)

I assume it would be something like what's shown in my attachment. As for the controller boards... they would need to be able to be assigned an IP, as well as a DMX address, right? They would also need to be able to interpret the DMX-over-ACN. How would that be done?

[ben]

I just want to say I have 2 wireless routers and a range booster I can use to setup a network and such to test whatever with.

Ben

[MaxS]

All right. Everything's theoretical at this point, as we have no ACN plug-in to play around with. ;) When we do though, we'll definitely be experimenting with networking with WireShark. (It's all layered on UDP/IP.) I've been thinking about whether or not we'd want to use PoE/802.3af instead of 802.11x so you wouldn't need all of the transformers for the wireless devices. 802.3af devices are few and far between, and because of that are fairly expensive though, so it would probably be better just to include an "Always On" outlet on the external housing for the controller board so that if the end-user chose to use wireless, the unit(s) could be fairly self-contained.

http://wiki.wireshark.org/ACN

Also, to provide the optional wireless to the controller boards, a product like this one would be used:
http://www.newegg.com/Product/Product.aspx?Item=N82E16833127053

Since that's fairly expensive for 16-64 channels (however many the controller board would provide), it would also be possible to "zone" boards. A switch could be run from the adapter/bridge which could provide data to multiple boards. (The controllers wouldn't be able to be easily daisy-chained.)

BRIDGE/ADAPTER --> SWITCH --> Controller Board
-------------------------------> Controller Board
-------------------------------> Controller Board

Being able to use standard networking equipment really opens up some cool possibilities. :)

[ben]

well, I was wondering how hard it would be to recode a router if we could get to the code of it? Being that the router I have has 4 wired outputs we could se it to recieve the signal and then you could hook up each controller to that output. I have heard you can hack into those routers not to hard if you actually have to right to access it.

Ben

[MaxS]

well, I was wondering how hard it would be to recode a router if we could get to the code of it? Being that the router I have has 4 wired outputs we could se it to recieve the signal and then you could hook up each controller to that output. I have heard you can hack into those routers not to hard if you actually have to right to access it.

Ben
You could use a router without messing with the firmware. If you wanted to do that, you would leave the WAN port open, and connect all of your peripherals to the four LAN ports. This works because the WAN input, let's call it eth0, routes everything through iptables or the respective firmware equivalent, and then back out eth1, which has the 4 port switch built into it. By only plugging everything into the switch, you get all of the infrastructure functionality, but you don't route things through the firmware.

The only (consumer-level) benefit in screwing with custom firmware would be to boost the wireless Tx power from the default 24mW. (On my home router I boosted it to 100mW and slapped on a custom fan and added some 9dBi gain antennas. Don't tell the FCC. ;)) Nothing custom would really need to be done though, as the ACN protocol uses the 802.11x/3x standard and is layered on UDP/IP, so it's fully compatible with all off-the-shelf networking equipment.

EDIT: I've updated the PDF layout to reflect an alternate layout.

[DynamoBen]

I took a look at your drawing and I'm not sure what you mean by "remote console." In an ACN system using Vixen ACN is sent directly via Ethernet, ACN capable devices would "listen" to it and decode it to dimmer levels.

Testing the network devices isn't what I am concerned about. My concern is verifying the ACN plug-in is really sending and receiving ACN. I have a number of tools available to me that will work for this. However we are missing one huge piece....the plug-in.

Once that is done developers, like me, will need to make ACN capable devices. This process will take time. The big battle here will be the cost of hardware and the difficulty in developing the firmware which is why I suggest DMX-over-ACN over full ACN.

Long term I think it makes sense to go the Ethernet/ACN route, microcontroller Ethernet communication is getting easier and less expensive each day. By this time next year it could be very cost effective and easy to make an CAN device.

[MaxS]

"Remote Console" was meant to be a laptop or other PC running Vixen that connects to the main server. (Accessed from Add-ins -> Remote Client) This is not part of ACN, but rather standard TCP/IP information being transferred between the remote client and the server. From what I understand, ACN is a protocol in the same way that HTTP, FTP, etc. are protocols, so you should be able to send other data over the network without problems.

Also, in the drawings all of the black lines are ethernet. (Purple are 2.4GHz ISM, red are 110/115/120VAC) I know that testing the network devices isn't really a priority right now, but as I lack the skills to work on a plug-in, I'm just thinking about what else would be needed to get a networked system working. I completely agree with your last statement, in that DMX-over-ACN over ethernet is the way to go.

[DynamoBen]

From what I understand, ACN is a protocol in the same way that HTTP, FTP, etc. are protocols, so you should be able to send other data over the network without problems.

Let me explain it this way:

DMX is just a protocol that travels down and RS-485 connection. ACN is just a protocol that travels down an Ethernet connection.

[MaxS]

Let me explain it this way:

DMX is just a protocol that travels down and RS-485 connection. ACN is just a protocol that travels down an Ethernet connection.
Yes, but since it is layered over UDP/IP, my question is can other data be passed through the network without problems? E.g., Vixen's remote client data for remote configuration and administration away from the server.

[DynamoBen]

Yes, but since it is layered over UDP/IP, my question is can other data be passed through the network without problems? E.g., Vixen's remote client data for remote configuration and administration away from the server.

Not a problem, ACN can co-exist with any other protocol.

ACN is treated differently than older Ethernet lighting protocols. For example in a Net2 system you have to run it on an isolated network. This is done not because Net2 can't co-exist with other network traffic but because you wouldn't want your network dragged down by other IT related problems during a show. A poor performing network could mean an abrupt end to your show.