Difference between sACN per-address and per-port priority
Introduction
When looking at streaming ACN (sACN) settings for various ETC (and some non-ETC) products, you may notice a choice between two types of sACN priority, and wonder what the difference between them is, and why you may choose one over the other. Each is known by different terminology, but the choices are often found as:
- per-port, per-universe, or per-source
- per-address, per-channel, or slot-by-slot
Below each type is explained in detail, as well as info about tools for troubleshooting.
Per-Port Priority
Per the ANSI E1.31 sACN standard, each transmitted level packet (start code 0x00) must contain a priority as a value from 0 to 200, with a default priority of 100. The lowest priority is 0 (least important), and the highest is 200 (most important). The level packet contains levels for all 512 address in a universe, and all share the same priority, even if an address isn't patched at the source. Each universe is transmitted as a separate packet, and it's possible for multiple universes transmitted from the same source to have different per-port priorities.
Although E1.31 receivers aren't required to support multiple sources, it's suggested that a receiver be capable of distinguishing between sources by their Component Identifier (CID). One method for dealing with multiple sources that have an equal priority is to merge levels for individual addresses via Highest Takes Precedence (HTP). Some receivers are able to handle multiple sources, but only a certain quantity. For example a receiver may support four concurrent sources, but a new fifth source will be ignored until one of the original four sources goes away. If the original source returns, it will now be ignored since the receiver switched to the originally-ignored source, and is already at its maximum of four. The quantity of sources a receiver supports - and how it handles them - can vary greatly between products.
If the receiver supports priorities and there are multiple sources at different priorities, the receiver will always use the levels for all addresses in the universe from the highest priority source, even if the levels are below that of lower priority sources. The exception to this is if a receiver is already at its maximum number of sources when a higher-priority source comes online. Using the previously example, the receiver will use levels from one of the four lower-priority sources until one of them disappears and the higher-priority source replaces it.
Per-Port Example - Equal Priorities
Below is a table showing an example between two sources (an architectural system and a console), with both at the same per-port priority. Since the priorities are equal the values from both sources are merged via HTP, and resultant output is a combination of the two
| Product | Address 1 | Address 2 | Address 3 | Address 4 |
|---|---|---|---|---|
| Arch System (priority 100) | 75% | 100% | 50% | 0% |
| Console (priority 100) | 35% | 15% | 65% | 25% |
| Winning Values | 75% | 100% | 65% | 25% |
Per-Port Example - Different Priorities
Below is a table showing the same two sources and values, with the console at a higher priority. Since the console is higher, all of that source's values are used, even though some of its DMX values are less than the arch system.
| Product | Address 1 | Address 2 | Address 3 | Address 4 |
|---|---|---|---|---|
| Arch System (priority 100) | 75% | 100% | 50% | 0% |
| Console (priority 150) | 35% | 15% | 65% | 25% |
| Winning Values | 35% | 15% | 65% | 25% |
Per-Address Priority
Per-address priority is an extension to the ANSI E1.31 sACN standard, implemented in many ETC products, which defines the ability to assign a different priority for each address individually. For example address 30 might have a priority of 97, while address 31 is a priority of 126. The per-address priorities are transmitted alongside - and in sequence with - level packets (0x00) as a separate packet with an alternate start code of 0xdd. Instead of carrying level data, it contains priority data for all 512 addresses in a universe. In ETC products unpatched addresses are transmitted at a priority of 0. Whereas priority 0 is a valid level in per-port priority, in per-address priority a priority 0 means "ignore the level data for this address". If multiple sources are transmitting levels for an address at the same per-address priority, the HTP merge rules utilized by per-port priority also apply here, but just at the address scope.
Per-Address Priority - Equal Priorities
Below is a table showing an example between two sources (an architectural system and a console), with each of their addresses at the same per-address priority. Since the priorities are equal the values from both sources are merged via HTP, and resultant (winning) output is a combination of the two.
| Product | Address 1 (priority) | Address 2 (priority) | Address 3 (priority) | Address 4 (priority) |
|---|---|---|---|---|
| Arch System | 75% (100) | 100% (100) | 50% (100) | 0% (100) |
| Console | 35% (100) | 15% (100) | 65% (100) | 25% (100) |
| Winning Values | 75% (100) | 100% (100) | 65% (100) | 25% (100) |
Per-Address Priority - Different Priorities
Below is a table showing an example between the same sources, but all of the console's addresses are the same priority (100), while the arch source's addresses are at different per-address priorities. Since the priorities between addresses is different, the resultant (winning) output will be a combination of the two.
| Product | Address 1 (priority) | Address 2 (priority) | Address 3 (priority) | Address 4 (priority) |
|---|---|---|---|---|
| Arch System | 75% (1) | 100% (150) | 50% (75) | 0% (200) |
| Console | 35% (100) | 15% (100) | 65% (100) | 25% (100) |
| Winning Values | 35% (100) | 100% (150) | 65% (100) | 0% (200) |
Combining Per-Port and Per-Address Products
Per the E1.31 sACN standard, sources and receivers are not required to utilize or understand per-address priority.
- Many sources and receivers are only capable of per-port priority
- Some are capable of per-address priority, but default to per-port priority
- Some are capable of, and default to, per-address priority
Below are the noted behaviors with different combinations of per-address support on sources/receivers:
- When the source is sending per-address priority, but the receiver is at per-port priority, it will ignore the entire 0xdd packet and only use the per-port priority found in the 0x00 packet.
Some per-port receivers exist which do not properly ignore 0xdd packets and attempt to interpret them as level data, resulting in flickering lights or other undesirable behavior. In these cases - if possible - it's recommended to switch to per-port priority at the source.
- When the source is per-port and the receiver is per-address, the system will function as if both products are set to per-port. i.e. there is no 0xdd packet to observe by the receiver.
- When both the source and receiver support per-address priority, control decisions can be made for each address individually based on the priority levels. This is particularly useful when multi-parameter fixtures exist in the system, since features like arbitration in ETC's Paradigm architectural system can dynamically change per-address priorities to influence which source's levels the receiver should be using.
The output in behaviors 2 and 3 above essentially align with the type of behavior outlined in the four tables above. Below is a table showing what the resultant output is if the sources support per-address priority, but the receiver only supports per-port. The per-address priorities are ignored, and since the arch system has a higher per-port priority, all of its values are used, resulting in drastically different output. This basically nullifies any per-address arbitration that may be present in either product.
| Product | Address 1 (priority) | Address 2 (priority) | Address 3 (priority) | Address 4 (priority) |
|---|---|---|---|---|
| Arch System (pr 125) | 75% (1) | 100% (150) | 50% (75) | 0% (200) |
| Console (pr 100) | 35% (100) | 15% (100) | 65% (100) | 25% (100) |
| Winning Values (pr 125) | 75% (1) | 100% (150) | 50% (100) | 0% (200) |
Troubleshooting Tools
When encountering issues related to sACN priority, there are two primary methods used for troubleshooting, both of which are software solutions installed on a separate computer hooked up to the lighting network. Each is outlined separately below.
sACNview Troubleshooting
sACNview is a free open-source third-party utility with several monitoring and testing features, one of which displays level and priority data for each address on all sources of any detected sACN universe. This is a quick way to determine if the "winner" of an address is who you expect it to be, as well as exposing if unexpected sources of sACN data exist on the network.
NOTE: Eos family consoles running v2.7.0 and higher have a built-in sACN Output Viewer. While it does offer the ability to see which levels exists on the network, and which source is the winner for an address, it isn't as full-featured as the sACNview utility. It's good as a first pass when starting the troubleshooting process.
Wireshark Troubleshooting
Wireshark is a free third-party utility used to capture raw packet information on a network. When it comes to sACN, generally Wireshark is only necessary when very deep troubleshooting is needed, and often requires port-mirroring a specific device to see what data is or is not being sent to/from said device. If you're using this tool chances are high that you're already working with ETC Technical Support for assistance. Detailed information on using Wireshark for this purpose can be found at Troubleshooting sACN priority using Wireshark.