CHAUVET Professional

Active Member
Lighting designers have an ever expanding array of networking and protocol options to choose from. Sam Bowden, European Product Manager for CHAUVET Professional, explains why sACN, a relative newcomer on the scene, deserves your consideration if you want to make your life easier when it comes to programming shows.

What is it about sACN that makes you so excited?
“The heart of the matter is that sACN makes it easier and more practical for a designer to fully maximize the potential of a modern lighting fixture. You can take advantage of all the features that are designed into a fixture with sACN more readily than you can with DMX. If all you need is a simple wash to light specific parts of a set or people on stage, then yes DMX will be fine. But if you’re lighting rock and roll, or wanting to create a different look for theater — like say lightning strikes — then you may want something more.
“For example, suppose you want to use pixel mapping to create these looks and really push your fixtures to do everything they’re capable of achieving. Why not do this with DMX? Well for one thing, it will end up using over 100 channels and take up nearly a quarter of a universe by itself. If you’re using your fixtures to their full potential, even a simple rig can end up swallowing 12 universes in no time – especially if you’re pixel mapping.
“What I like about sACN is that it greatly simplifies this process. So when you come to set your fixtures up it’s simple — just address the fixture and stick the universe number in. It’s pretty much as easy as setting up a unit on DMX.”

Ok, but what about other protocols beyond DMX like Art-Net?

“I’ve built data networks in the past with the earlier versions of Art-Net, and while they offer advantages over DMX, they can be complicated. One of the things I’ve never really been a fan of with Art=Net was the limitations of IP addressing: you can only use address codes which start with 2 or 10 and then you have to go around and make sure all the units in the network have got onto the right IP address; otherwise they won’t work.
“As a result, the setup can become a lot more intricate. I must set the DMX address, the universe, the sub net and the IP address. Even then I have to plug this info into the controller and hope it all works. It just wasn’t really saving me enough time and effort to justify me changing.
“Another thing that concerned me is the Unicast/broadcast dilemma. When sending data over Art-Net, there are two distinct ways of doing it. One is Broadcast, which has all data sent over the network line to every fixture. The other is Unicast, which breaks down the data at the point of control and sends the relevant IP information to the relevant IP address. Both have issues in my view.”

What are those issues?

“With Broadcast, there are huge swathes of data flying around, colliding, and when they do finally arrive at your unit, the processor inside has to break the packet down and pull the relevant data from it – more often than not it is having to do this 42 times a second – the standard DMX refresh rate from the popular desks. When you’re running two or three universes, this isn’t such a huge issue, but when you get over 15 universes it starts to become a concern. Then there is Unicast -– it’s a much better way of doing this, but it still puts strain on the front end processing and there is still a lot of time involved with the network setup on the unit.”
proxy.php

So what makes sACN any better?
“It’s the simple things really. sACN can operate on any network address. You can even mix and match in the same network – one unit might be address 10.5.234.12 and the next might be 50.4.21.124, but it won’t matter, it still works. So when you come to set your fixtures up it’s simple; just address the fixture and stick the universe number in – it’s pretty much as easy as setting up a unit on DMX.
“Then there is the cabling advantage. You might have five units next to each other and they might all be on different universes. That’s fine when you have one cable carrying all the universes on it anyway, because you can just link through. But what happens when suddenly my cable diagram has gone from having five cables coming up to the bar to one, and my time on site has been reduced greatly because it’s a single line?
“With sACN, prep time will be reduced, because now it really doesn’t matter what universe that fixture is on or how many universes you’re using. You don’t have to sit there trying to squeeze in that last unit with six channels on the end of a universe or pair those two units that ‘no one will notice’ onto the same address, because you’ve run out of channels. Theoretically, you can run every unit on a different universe with sACN and affect setup time very much.”

How does sACN send information?

“It uses multicast. The great difference with multicast is that it shares the load. So it doesn’t send all information to every fixture to let them sort through the data. It also doesn’t sort through all the info at the front end then send it. What multicast does is break the information down into groups at the front end and send out several smaller packets of info to the units. These are received by the end units, which break the rest down easily. The beauty of multicast is that it is easily expandable. It really shouldn’t make any difference how the units run whether you have two universes or 200.”

Can you tell us a little about how sACN has been designed?

“Sure, from a design perspective the protocol has been designed by ESTA, which has been responsible for many of the latest developments in protocol and also safety standards in the U.S. It’s an open protocol which anyone can adopt and use in their units, and there is one version out there, meaning everything on sACN is talking the same language. Most importantly, this is now a standard, so all units that adopt it will be on the same page so to speak.”

Can sACN assign priority to multiple controllers?

“Yes it can. This has two major advantages in my view. The first is backup, which means you can put two control desks onto the same line, and should the main desk fail, you can jump straight onto the second desk and pick up the gig from there with no down time on the control side. However, when things are going smoothly, the main desk will always have control over the other desk.
“The second advantage is that you can split control between the media server and the lighting console, which is very important when you have a big pixel mapped rig. So, if you set the console to a lower priority, and the media server to a higher priority, the lights will follow the pixel information from the lighting desk until they see information from the media server, then they’ll listen to it instead. So, you can leave a backup look in the console, so that when the content you’re sending from your server stops, there is still a look on-stage.”

Do you have any other comments on sACN?

“I can’t talk highly enough of this protocol because for me when it comes to a production and the kit I am using, I ask myself three questions: Does it work? How easy is it? If it goes wrong, can I sort it? sACN is able to answer all these questions better than anything currently available.”
proxy.php
 
Oh dear me; how horrible.

Technically he's right that sACN could still work, but lots of other things would certainly break...

Also, I was really confused about who would describe sACN as "a relative newcomer" until I finally read the date on that post. It's still stretching that "relative" qualifier a bit further than I would, but at least it's not someone saying that today.
 
Technically he's right that sACN could still work, but lots of other things would certainly break...

Also, I was really confused about who would describe sACN as "a relative newcomer" until I finally read the date on that post. It's still stretching that "relative" qualifier a bit further than I would, but at least it's not someone saying that today.
Yeah; it came up in a search for something else, and -- have you met me? -- I just couldn't let that go by.

At least he didn't specify 82.268.1.350.
 
Begs the question do you really want star topollogy distribution to a lot of fixtures. DMX daisy chain is certainly easier.
 
Plus a lot of their gear is DMX over WiFi, so thats easier as well. sACN over WiFi would be cool. Glad I'm out of the business and dont have to deal with it anymore, LOL.
I am not any more certain that I like lighting over wifi anywhere you don't *absolutely* need it any more than I like Dante over your production net. :-}
 
Plus a lot of their gear is DMX over WiFi, so thats easier as well. sACN over WiFi would be cool. Glad I'm out of the business and dont have to deal with it anymore, LOL.

It's not actually Wi-Fi, but City Theatrical's Multiverse wireless DMX protocol. DMX (or really sACN at that point) over Wi-Fi is a terrible idea that might work some of the time... but is inherently unreliable due to the basic model of how Wi-Fi works. The DMX-specific wireless protocol used in those fixtures and other professional products is very robust and about as reliable as you can get without a physical wire. Honestly, even the cheap knock-offs are pretty good these days (Donner/Chinly/whateverrandomnameoftheday on Ebay and Amazon).
 
Yeah, usually the confusion is that both Wi-Fi and these wireless DMX protocols can live in the 2.4GHz range, but the wireless DMX protocols are not in any sense Wi-Fi. They are purpose-built specifically for transporting lighting control information and many/most these days are quite reliable. City Theatrical is at or near the top of the list in terms of reliability.

Sending DMX level information as sACN over Wi-Fi is possible (depending on your network configuration), but definitely not a reliable approach.

I suppose another potential point of confusion is a tendency for some people to use the term "Wi-Fi" to mean anything wireless rather than sticking to its actual meaning. In this case, the distinction is very important.
 
I think what folks forget is that "Wifi" is not just a generic term for data sent over a radio transmission system, but is an actual protocol and that in the case of Multi-Verse is not what is used. Multi-Verse being its own protocal, that also uses radio tramsmission and receiving in a similar manner.
 

Users who are viewing this thread

Back