Lighting Network Essentials - Part Two, Specifying and Setting Up a Lighting Network

When it comes to lighting fixtures and control systems, lighting designers have never had as many choices as they do today.  With so many options in moving lights, media servers, console architectures, and laser systems, stage shows are as varied and creative as ever, and require moving more data between front-of-house and the rig than ever before.  A solid show network is about as important as solid power distribution for many shows. In this video, we’ll look at how to start from a sample equipment plot using Capture and design a network that will support the equipment and protocols we need to execute the design vision.

The first stage of designing a network is to examine the devices we have and look at what sort of data each needs to send or receive.  An overall production might use IP networking to handle lighting, audio, video, laser, and automation data. We’ll be focusing on lighting data, but we’ll look at how these different types of data can coexist later.  

Looking at the fixture list in our Capture file we see that this rig uses:

• 10 Clay Paky A.leda Wash K20s
• 8 ADB Lighting Technologies ALC4 Cyc lights
• 10 Clay Paky Alpha Spot QWO 800s
• 24 Robe Robin MMX Spots
• 24 Robe Robin MMX WashBeams
• 8 X-Laser Skywriter HPX M-5s
• 1 Avolites Q3 Media Server

 With this equipment list in hand, we need to figure out what our connectivity options are for each of these systems. We can learn this by searching for the manuals and datasheets of these fixtures. As an example, I haven’t worked with the A.Leda wash K20s before so I just google the fixture, which takes me to the clay paky website which has a datasheet on the unit. If I look at the control section I can see that the fixture is compatible with DMX as well as art net, but not streaming ACN. I can also see how many parameters this fixture requires in its different modes. 

Once I determine what our connectivity options are for the fixtures and our parameter count requirements, I can determine what I need for a console to control it all. Our total parameter count for these fixtures is 2,884. While that’s a large number, it’s not an unusually high number for a show with many moving fixtures and is well within the control capabilities of all the major console brands. Since a universe is 512 parameters and 2884 divided by 512 is 5.6, we need a minimum of 6 universes, which is no big deal for a modern lighting network. We could run this show on our Avolites Quartz, which provides for 16 universes with no problem, but for the purposes of showing what a festival or arena sized lighting network may look like we are going to use an Avolites Arena, with the Quartz as a backup at front of house, then a TNP processing unit and optical titan net switch unit back stage.

Immediately with a system like this we can see the benefits of a lighting network or just using straight DMX. By networking the consoles together, we have immediate failover support in case one console were to go down during our show or if we wanted the consoles to perform different jobs such as one console running lights while the other ran the media server and lasers, all on the same network.

 

Our Avolites Arena console has a built in gigabit fiber optic connection, which would allow us to run a single fiber optic cable to the titan net switch backstage instead of having to run 6 different runs of 5 pin DMX cable. Fewer cables means faster load in/load out and less space taken up in the truck.

 

Is the gigabit connection fast enough for what we want to do though? It’s important to make sure your network has plenty of bandwidth for the data you are trying to send. Remember before broadband internet was common and you used to have to wait for videos to “buffer” and images to slowly load when web browsing? This was due to not having enough bandwidth, the ability to move data at high speed. Let’s learn a little about what our systems require, then specify our lighting network to have enough bandwidth.

 

Commonly, network speeds are given in bits per second, but we often talk about data in terms of bytes.  One byte is eight bits, so our network bandwidth in bytes per second is one eighth of the bandwidth in bits per second.  On a lighting network, the main data streams we need to consider are sACN and Art Net.

To be safe we’ll round up to 250kbps per universe, so our 6 universes require a total of 1.5Mbps bandwidth between front of house and the stage.  We can accommodate a lot of DMX data on even a 100Mb link and we have 10 times that bandwidth with our gigabit link.

 

A lighting network is ideally used for nothing but lighting data, but just in case you have to share it’s important to know what bandwidth might be taken up by other departments. Audio or video data will consume much larger amounts of bandwidth. Uncompressed audio at 48khz x 24bit will consume 1.2Mbps per channel, and a single compressed video stream can consume 20-250Mbps depending on frame rate and resolution. If over the same gigabit connection someone is trying to stream 4 4K 60FPS video streams, suddenly your gigabit connection isn’t enough and you may begin experiencing lag.

 

Audio:

• 48khz x 24bits = 1.15Mbps

Video (https://newsandviews.dataton.com/what-is-ndi-network-device-interface):

• SD video = 20 Mbps
• 720p50/59.94 video = 90Mbps
• 1080i50/59.94 video = 100Mbps
• 1080p50/59.94 video = 125Mbps
• UHDp30 video = 200Mbps
• UHDp60 video = 250Mbps

Now that we know our gigabit connection from front of house is plenty of bandwidth for our lighting data, let’s look at how to patch and physically connect our fixtures.

 

Some of our rig uses fixtures that require 5-pin DMX.  We could run a bunch of DMX lines from FOH to the stage, but we can simplify our load-in and provide some more flexibility in our rig by using DMX nodes. A DMX node can be as simple as a device that takes in art net or streaming ACN and converts that data stream to a single DMX universe, or they can be complex multi-universe systems with built in processing. Our TNP is a very advanced node that is capable of doing additional processing as well as taking our artnet/sACN data streams and converting them to DMX, in this setup we’re using it with the optical switch as a DMX node to convert our network data streams over the fiber optic cable from front of house to copper cat5 cables for our artnet fixtures and copper DMX cables for our DMX only fixtures.

 

We’ll split up our fixtures based on three factors:

• How many parameters we need to control them. Each universe provides up to 512 channels. With sophisticated fixtures like Mercury-enabled lasers or the K20s in pixel mapping mode we may run out of parameters on a universe quite quickly.
• How many physical devices we have.  As a rule, we should not have more than 32 physical devices on a DMX run.  We can use a DMX splitter to expand this number, or we can use additional DMX nodes to give us the required physical runs to meet our needs. All multi-port DMX nodes we’re aware of will allow you to set them to output the same universe on multiple DMX ports
• How those fixtures are distributed. Because DMX devices must be strictly daisy chained, it can be difficult to find a way to link up large arrays of fixtures without cumbersome cable runs.  

 

Looking at our rig in capture, we can see that our fixtures that must be operated by DMX are located at the base of our cyc and on our sidelight towers. For the fixtures at the base of the cyc we can run one line of DMX out from our TNP offstage left along the back of the stage to chain these fixtures. For the alpha spots on our side light towers we have two options, we can either run a DMX line from our TNP to the stage left tower, then chain to the stage right tower, or we can run ethernet cable to each of these towers and use a node at each tower. Conveniently, the X-Laser Skywriters at the top of each tower have built into them a node functionality. We can have each of these output universe 2 on each tower, so we can run ethernet cable to the lasers, then take DMX output from the lasers down the towers to control the Alpha Spots. Since we intend to run ethernet for the lasers anyway this keeps our cabling very simple.

All of the rest of our fixtures can be controlled by Art Net, so lets look at the simplest way to run the ethernet cables for these. One thing you may notice when looking at datasheets and manuals is that some fixtures have multiple ethernet ports for chaining fixtures, but some others don’t. These multi-port fixtures have a device called a switch integrated. We will get into the differences between hubs, switches and routers in another video, but for this portion all you need to know is that the switch repeats relevant network data to connected devices and allows you to chain art net/sACN devices.

 

When the fixtures don’t have a switch built in, we have to figure out another way of getting the network signal to each fixture independently. We can do this with a standalone switch. Switches for lighting networks are often rack mount and work well for ground packages, but often are impractical for mounting in the truss. In the case of our demo capture file here, our better bet is to just run DMX for these fixtures. Even though they have art net capability, using that capability with these fixtures in this arrangement is impractical. For the sake of convenience, each flown segment has it’s own DMX universe and we can run either a home run DMX cable or we can place a DMX node to convert art net from an ethernet cable to DMX for our fixtures.

The X-Lasers on the rear truss can all be controlled by DMX, art net or streaming ACN. Since they have integrated switches we can just chain them all together and put them on their own universe.

Now that we know what fixtures we’re running by art net, streaming ACN and DMX we should decide on an IP addressing scheme.  While we could use automatic addressing with a DHCP server on the network (as long as all of our equipment supports DHCP) many show networks still use static IP addresses. One other important thing to check is if the fixture has any limitations on the IP address settings. In the case of the X-Laser and Clay Paky systems there are no limitations, but the Robe Robin units will only function on a 2.x.x.x or 10.x.x.x network. Since of those two options 10.x.x.x is the only private network option from these choices, we’ll need to address all of our systems to be on the 10.x.x.x network with a subnet mask of 255.0.0.0.  This gives us plenty of IP addresses, and we can use the last three segments of the IP address to split our devices into different ranges while still allowing all of them to communicate. We can put our lighting control systems into the 10.1.x.x range, our media servers into 10.2.x.x, and then we can break up our other devices by their location, maybe 10.101.x.x for one section of truss, 10.102.x.x for another section, and so on.

• Primary Console: 10.1.0.1
• Backup Console: 10.1.0.2
• TNP: 10.1.0.3
• Media Server 1: 10.2.0.1
• Lasers: 10.3.0.1-8
• Flown Truss Nodes: 10.101-104.0.1

Once we have everything hooked up, turned on, and assigned an IP address we’re ready to start configuring our networked fixtures and nodes for either Art-Net or Streaming ACN. 

For sACN, we only need to configure the console to send whatever universes we need, and set the corresponding universe on each receiving device.  The receiving devices will join the correct multicast group for each universe they need to receive.

In order to use Art-Net, there is some extra configuration involved.  Art-Net can be either unicast or broadcast. Ideally, we want to unicast all of our Art-Net universes only to the devices that want them.  So we have to tell our console which universes should be sent to which IP addresses. Our console will check the network to try to discover all Art-Net devices and should list those devices and the universes that they want to receive.  Some consoles can then automatically begin transmitting the requested universes to the detected devices, or we can manually assign universes to devices.  

Due to limitations in the Art-Net protocol, devices that receive more than one universe may not be detected properly.  These devices will generally need to be configured manually. It’s also important to note that if the IP address of a receiving device changes, then the Art-Net configuration on our console may need to be updated manually.

Console configuration for your outputs is different between all the major brands, but each of them has excellent documentation and video support on how to do this.

There’s a lot more that goes into the difference between Art-Net and Streaming ACN, we’ll get in depth on the difference between the two in another post.   

So there it is, we learned how to design and specify our network to make sure we have the bandwidth we need, how to arrange and physically connect the components of our lighting network and configure your fixtures for proper connectivity. In the final part of this series we’ll cover basic troubleshooting and how to verify that your network is setup properly and your console is sending lighting network data.