Streaming ACN

Overview

Streaming ACN, also known by it’s abbreviation sACN or by its technical specification document number e1.31 is a lighting protocol that encapsulates DMX type data and sends it over a TCP/IP Ethernet network.  It is an intermediate step between DMX based lighting controls, and full ACN based implementations.  ACN (Architecture for Control Networks) is an extensible suite of protocols that can be used to control all varieties of devices used in live production networks.  Since a full transition to ACN is a major paradigm shift, sACN was created that operates within an ACN network and uses familiar concepts from the DMX standard that has been in common use for decades.  DMX defined the electrical signaling as well as the data format.  Only the concepts of channels and universe and a loose guideline for timing is carried forward from DMX to sACN.

Universes and Channels

In DMX, only 512 channels of data could be carried on a DMX cable.  This was a limit based on the balance of data rate, distance requirements, multidrop topology and refresh rate.  With all of those factors considered, 512 channels was defined as the standard number of channels in a universe.  As shows grew, and designers needed more than 512 channels to control a show, it became necessary to implement multiple independent DMX networks.  While not part of the standard, the term universe became the standard term to refer to each separate DMX network.  In the DMX world, every group of 512 channels was its own physical network and this network was called a universe.

Ethernet networking has far greater capacity for bandwidth and routing.  In fact, the bandwidth of the network has no defined limit in Ethernet networking.  Faster and faster links continue to be invented and come into common use.  Ten years ago, 100BaseT was common.  Now 1000BaseT and even 10GBaseT are becoming more and more common.  So there is no need to limit the number of channels transmitted on an Ethernet network.  However, to maintain backwards compatibility, and to make it easy for hardware developers to implement new transitional devices, the 512 channel per universe limit was kept.  But you can now send many universes on the same wire.  sACN currently allows 63,999 universes on a network.  This doesn’t mean this will work on a 10Mbps network.  But you can get pretty close on a 1000Mbps network.

Addressing

Many people get tripped up over Universe/Channel addressing.  It’s actually quite simple.  Channels are grouped into universes and universes are numbered.  You can think of it similar to postal addresses.  The channel is like the house number, and the universe is like the street name.  You can have a 101 First street, and a 101 Second street and the proper mail will get to the right houses.

A universe can have any number of channels in it from 1 to 512.  But each universe always starts at channel 1.  If you only have 50 channels to send, you can have a universe send only channels 1-50.  But you cannot send only 51-100.  (why would you want to?)

Why do I see the number 510 or 170?

Pixels or RGB elements take 3 channels to communicate the data for the Red, Green and Blue parts of the color.  If you have 10 pixels, you need 30 channels.

512 does not evenly divide by 3.  512 = 170 1/3.  So you can only fit 170 full pixels into a universe with 2 channels left over.  510 channels is 170 pixels worth of data.  Earlier models of pixel controllers did not bridge this gap across universes and required you to contain full pixels within a universe.  This is becoming less common on newer hardware designs.  It’s important to know which universe size your hardware supports when configuring the sACN universe outputs.

Multicast Vs Unicast

ACN is designed to be a minimal configuration control protocol.  It is intended that the show controller (the computer) just puts the data out onto the network, and the receivers see everything and get configured to use only what they need.  For this reason, multicast networking makes the most sense.  Multicast is a mechanism where the sender transmits the data, and the receivers see the available data and use it.

Multicast is a network assisted technology that relies on the network to manage which devices want the information and which don’t care.  It is backwards compatible with networks that have no specific multicast support.  But in these environments, since there is no assistance at the network level, every device gets all of the data.  This can easily result in a network that gets very congested.  It also tends to overwhelm many simple hardware receivers because they must inspect each packet of data to determine if it should use it or not.

This network guided delivery of data relies on a standard networking protocol called IGMP (Internet Group Management Protocol).  This is a system where listeners who are interested in a stream will subscribe to the group.  The switches then forward the traffic to only the switch ports where there are subscribers.  In the context of sACN, the groups correspond with a particular universe.  For this to work, you need network switches and routers that support multicast routing and/or IGMP snooping.  In general this is not a feature found on home networking equipment.  It’s found on managed or smart switches.

Because many people use low end networking equipment, especially in the early days of sACN adoption, The sACN standard also allows for unicast transmission of the data.  Basically, the standard says that while multicast is preferred, receivers must process any data that gets to it.  This helps to reduce network flooding on networks without proper multicast support.

It’s a myth that you can send more universes using unicast than you can by multicast.  When the network is doing its job, and all devices are following the rules, the traffic is the same in both cases. It can even be less with multicast, because if more than one controller is getting the same universe data, only one packet is sent to the whole network, not one per device.  The unicast is better myth started in the DIY Christmas Lighting hobby.  The early model pixel controllers didn’t properly implement IGMP subscriptions, so it looked like it didn’t work anyhow.  And these same devices had to employ other means to cope with the overload of data coming in the ports.  So there were artificial restrictions placed on it that were safe amounts of data the controller could handle without overload.

sACN over WiFi

When using WiFi as a link for your sACN data, multicast is always better because of the physical nature of wifi being a broadcast medium.  There’s no magical network switching happening in mid air.  Multicast also bypasses certain physical layer data integrity checks in 802.11 WiFi.  WiFi makes assumptions in the fundamental design that it’s more important for data to arrive without errors than it is for it to arrive on time.  While that’s true for most general purpose internet traffic, that’s not the case for live show realtime data.  For our applications, its more important that the data arrive on time, than arrive correct.  If it had to retry because there were data errors, it would be too late anyhow.  So it’s better that data gets dropped than for it to arrive late.  That’s what happens in multicast over WiFi.  Unicast on the other hand will retry a few times until it knows the receiving device got the data and got it correctly.  This will usually be seen as irregularly lagging transitions on your lights.

Optimizing the stream

While the specification doesn’t give a hard and fast timing for how often a universe should be refreshed, it will never be more than 44 times per second, which is the maximum speed allowed in the old DMX standard. It is typically much lower though - often corresponding on the frame rate of your sequencing or lighting software.  Vixen 3 defaults at a 50ms interval which corresponds to 20 frames per second.  Like DMX, sACN is designed to be a streaming format where all the data keeps getting resent over and over regardless of whether it’s changed.  If a light didn’t get the message right the first time, it’ll have another chance 50 milliseconds later.

In contrast, if you’re familiar with Light O Rama, you may have experienced stuck effects.  LOR is not a streaming format.  It’s a state change protocol.  It sends instructional commands that tell the lights what to do over what period of time.  If one message is missed, the light doesn’t change.  DMX (and sACN) do not have this problem because they keep repeating what all lights should be doing at every given moment.

But you can probably imagine, that sending the same data over and over ad infinitum is a whole lot of unnecessary data.  Especially when you consider that many lights aren’t changing for reasonable periods of time even in an active show.  As mentioned earlier, there’s no minimum refresh timing in sACN.  The specification further gives the receiving device the discretion to determine what duration means that there’s no more data coming and the source is inactive.  Though it’s generally accepted that you should get at least one frame of data per minute for the source to be considered alive.  Furthermore, the specification allows the receiving device to decide what to do when it determines that there’s no active data.  It could shut everything off, or turn it on to a predetermined level, or execute some internal program. Or it could leave everything at the level it was last set.

You probably get the comments that you must have a high electric bill with all those lights.  But you probably also know that by blinking the lights,  they’re off more than they’re on and the electric bill isn’t that bad.  The same line of thought follows with the network traffic.  If you’re going a few seconds at a time without changing a value, why resend it constantly.

Vixen has two parameters on the advanced tab for Streaming ACN controllers.  The first value is the number of times it will keep sending a frame of data that hasn’t changed.  This makes sure that the lights are at the values they should be before taking a break in the data stream.  For example, if you set this value to 10 and the sequence turns everything on for 5 seconds, it will send the frame for all on 10 times (at 50ms intervals) and then stop sending frames and sleep until something changes.  this makes sure that all the lights had a chance to get the data and catch up before stopping the stream.  If this value is set to zero (default), the output will not sleep and keep sending data at the normal refresh interval.

The second setting is a keep-alive.  This is the number of frames it’s allowed to skip during sleeping periods.  If the first setting is 10, and the second is 40, it will keep sending that unchanged data for 10 frames, then wait for 40 frames, then send it once and wait another 40 or resume whenever something changes.  This setting keeps a refresh packet going out at regular intervals regardless of change.  It will keep controllers awake and in sync.  When the repeat value above is 0, this keep-alive value has no effect.  When the keep alive is 0, it will not send the periodic frame and will continue sleeping

When used together, these two settings can drastically reduce network traffic while still keeping all of the relevant data going to the controllers.  You may want to have the repeat value set higher for WiFi controllers than you would for wired ones.  Most if not all of the pixel controllers currently in the DIY Christmas hobby hold their last received values indefinitely.  This means the keep-alive value can be safely set rather high.  A value of 99 represents about 5 seconds at the default interval rate.  If the chance of stray data is low, it’s safe to let long periods of time go by without sending a refresh frame.  Again, with WiFi, you may want to send this more frequently just in case some stray data leaves a channel in the wrong state.  The periodic refresh will bring it back where it should be.