Networking Basics

Introduction

Ten years ago a technician could spend a whole career in AV without touching a network. Today the stage box talks to the console over one, the camera's picture and the command that moves it travel on one, the LED processor, the lighting console, the touch panel on the lectern and the projector in the ceiling are all addresses on a switch. When the network is wrong, the show is wrong, and it is wrong in ways you cannot see by looking at a cable.

The good news is that AV networking is not IT. You do not need to design a corporate network or pass a certification to be useful on a show. You need to understand how data moves, how devices are addressed, what the switch is doing, what AV traffic needs, and how a command from a touch panel actually reaches the device it controls. With that, a network stops being a mystery and becomes one more signal path to trace.

What this book covers

What a network is and the layers it is built from; switches, routers, copper and fiber cabling, Power over Ethernet and Wi-Fi; IP addressing, subnets, DHCP, DNS and the gateway; TCP, UDP, ports, multicast and firewalls; audio and video over IP and the switch settings they depend on; control systems — the interface, the processor and the devices it commands; control protocols from infrared and serial to IP commands, PJLink, VISCA and the show control protocols of live events; and troubleshooting, security, documentation and working with IT.

It was measured against the certification objectives for network technicians, foundation networking courses, AVIXA's networked AV training, the networking content of audio network certification, the standard text on show networks and control systems, and manufacturer control-system foundation training, so that nothing a technician is taught elsewhere about AV networks and control is missing here.

What this book does not do

It does not make you a network engineer or a control programmer. Designing enterprise networks, configuring routing and writing control system programs are disciplines with their own training. This book makes you the technician who can connect, address, test and troubleshoot an AV network and its control, and who can talk to network engineers and programmers in their own terms.

How to Use This Book

Each chapter follows the same shape, and the shape matters more than it might look. You read the ideas, then you see them play out in a real situation, then you get the procedure, then you are shown what goes wrong and how to recognise it early. Reading only the parts that look new is the fastest way to arrive on a job holding half of something.

1. Read the chapter body first. This is the understanding layer, and it is written to be read straight through.
2. Read On the job. The same material as a real situation on a real show, which is where it stops being abstract.
3. Work through How to do it. These are procedures you can follow on a job this week.
4. Study What goes wrong. Experienced technicians are not people who never make mistakes; they are people who recognise mistakes early.
5. Do the exercise before reading the answer key. Recognition feels like learning and is not.
6. Take the checklist with you. Photograph it on your phone. Use it until you no longer need it.

Keep a notebook

One habit is worth starting today, before the first chapter: keep a small notebook and write the details in it as you meet them. Networks and control run on exact values — the IP range and subnet mask for this show, the address of every device, which switch port is which, the VLAN numbers, the serial settings of the projector, the port its control protocol listens on, the exact command string and its delimiter.

Write it by hand rather than photographing a screen. Copying an address puts it on paper; writing the whole scheme out yourself is what puts it in your head, and deciding how to lay it out is most of the understanding.

Then use it twice. Read a few pages on the way to a job, which takes five minutes and turns things you half-know into things you know. And carry it on the job, because the address you cannot remember is always the one somebody is waiting for.

A note on the words

Networking and control words vary between IT, AV and manufacturers, and it is worth expecting that. A network switch is not a video switcher, and the context has to make clear which one is meant. Ethernet cable is network cable, Cat cable, CAT6 or data cable. Multicast is sometimes written multi-cast, and people sometimes say broadcast when they mean multicast, which is a different thing. A control processor is a controller, a control system, the brain or, by brand name, a Crestron. Dante calls its clock roles leader and follower; older documents say master and slave. And a port can mean a physical socket on a switch or a number that identifies a service, which is the source of real confusion.

None of that is worth arguing about. What matters is that you can say what a device or setting does, because a person who can describe the function will be understood by AV and IT alike.

A note on safety

Network and control work is low voltage and mostly safe, but it happens around things that are not. Fiber optic connectors can carry invisible laser light, so never look into a fiber end or a transceiver. Control systems move things — motorised screens, lifts, lighting bars, camera robots and rigging automation — and a command sent while testing can move something with a person underneath it. Relay outputs sometimes switch mains-powered equipment, and that wiring belongs to an electrician.

And the network itself carries a kind of risk that is easy to overlook. Plugging an AV switch into a venue's network, connecting a laptop with remote access to a show network, or leaving default passwords on devices can expose a client's systems. When a task touches someone else's network, ask before you plug in.

Where this book sits

This book assumes you have read AV Fundamentals 101, or that you already know what is in it.

Experience counts instead. If you have time on crews where you have already plugged AV devices into a switch, set an IP address and met a touch panel, start here.

If none of that is true yet, read AV Fundamentals 101 first.

What pairs with this

• Signal Flow & System Architecture — following a signal across the network once it exists

Where it leads

These are not steps in an order. Take whichever one fits.

• AV Networking Intermediate — to design and configure the networks this book teaches you to use
• Dante Level I–III — networked audio in depth, towards certification
• Show Control Fundamentals — if triggering whole shows is where control caught you
• Crestron Programming Basics — to write the control programs this book teaches you to test

Before You Begin

What a Network Is

A network is just devices sharing a path to pass data to each other. The rest is detail.

Data, packets, and the path

A network is a set of devices connected so they can pass data to each other. That data travels in small chunks called packets — a file, a video stream, or a control message is broken into packets, sent across the network, and reassembled at the other end. This packet approach lets many conversations share the same wires efficiently, which is exactly why one network cable can carry many AV signals at once.

The path a packet takes runs from one device, through network gear (switches and routers), to another device. This is the same source-to-destination thinking from AV signal flow, applied to data: a packet has a source device and a destination device, and the network's job is to get it there. Holding this simple picture — devices passing packets along a path — makes the rest of networking far less intimidating.

LANs and the internet

A local area network (LAN) is the network in one location — the devices connected together at a venue, a studio, or in a rack. Most AV networking happens on a LAN: the consoles, processors, and AV-over-IP devices all talking to each other locally. The internet is the vast network of networks that connects LANs around the world; reaching it from a LAN goes through a router. For most AV work the LAN is your world, and understanding the local network is what matters most.

Networks can be wired (Ethernet, over Cat6 or fiber) or wireless (Wi-Fi). Professional AV strongly favors wired networks because they are far more reliable and predictable than Wi-Fi — a show feed cannot afford the dropouts and congestion wireless can suffer. Wi-Fi has its place for convenience and control, but the critical AV traffic rides on wires.

The layers of a network

Networks are built in layers, and each layer does one job and relies on the one below it. Engineers describe them with the OSI model, seven layers numbered from the bottom. For a technician, the model is valuable for one reason: it turns "the network is broken" into a question with an order to it.

Layer 1, physical, is the cable, the connector, the fiber, the radio link and the electrical or light signal on it. A broken cable, an unplugged connector or a missing link light is a layer 1 fault.

Layer 2, data link, is Ethernet: devices identified by MAC addresses, and switches forwarding frames between them. VLANs live here too.

Layer 3, network, is IP: addresses, subnets and routers moving packets between networks.

Layer 4, transport, is TCP and UDP, and the port numbers that deliver data to the right service on a device.

Layers 5 to 7 — session, presentation and application — are the software that uses the network: a Dante subscription, a web page on a device, a control command, an NDI stream. IT people often fold them together as the application layer.

The practical rule is to troubleshoot from the bottom. Is there a link? Is the device on the right VLAN? Does it have the right address and subnet? Is the port open? Is the application configured? A fault at a lower layer makes every higher layer fail, so checking from the top first wastes time on settings that cannot possibly work until the cable does.

Ethernet, MAC addresses and how a switch learns

Almost every wired network in AV is Ethernet. Data on Ethernet travels in frames, and every Ethernet device has a MAC address: a hardware address built into its network interface, written as six pairs of hexadecimal characters such as 00:1D:C1:4A:22:9F. The first half usually identifies the manufacturer.

A switch forwards frames by MAC address, and it learns where devices are by listening. When a frame arrives on a port, the switch records the frame's source MAC address against that port in its MAC address table. When a frame arrives for a destination it has already learned, it sends the frame only out of that port. When it has not yet learned the destination, it floods the frame out of every port in that network, and learns from the reply.

Broadcast frames, addressed to everyone, always go out of every port in the same network. The set of devices that all receive each other's broadcasts is a broadcast domain, which on a simple switch is every device plugged into it.

This explains several things technicians see. A device moved from one port to another works again within moments, as the switch relearns it. Two switches connected together behave like one larger switch. And a network full of broadcast traffic slows every device on it, because every device has to look at every broadcast.

The layers, as a technician uses them

On the job

A conference in a hotel. The audio engineer's laptop cannot see the stage box in the networked audio software, though the stage box and console are exchanging audio perfectly.

The engineer has already rebooted the software twice. You work from the bottom. Layer 1: the laptop's network port has a link light, and the switch port it is plugged into is lit. Layer 2: it is plugged into the same switch as the stage box. Layer 3: you check the laptop's address. It is on the hotel's Wi-Fi as well as the wired network, and it has taken its default route and address from the hotel network; the wired port has given itself an address in a different range from the audio devices.

You turn off the laptop's Wi-Fi, set the wired port to obtain its address the same way as the audio network, and the stage box appears in the software within seconds.

Two reboots of the software could never have fixed a layer 3 problem. One minute spent at layers 1, 2 and 3, in order, did.

How to do it

1. Layer 1 — check link lights at both ends, the cable and the connectors.
2. Layer 2 — confirm the device is on the right switch and VLAN.
3. Layer 3 — confirm its IP address and subnet mask match the network, and nothing else uses its address.
4. Layer 4 — confirm the port the service uses is not blocked.
5. Application — only now check the software settings, subscriptions and commands.
6. Stop at the first layer that fails, and fix that before going on.

What goes wrong

Practice it

Answer before checking.

Network Gear & Cabling

A few devices do the work: switches connect, routers link networks, cables carry it all.

Switches and routers

Two devices form the core of networking. A switch connects many devices together on a local network and directs each packet to the right one — it is the meeting point of a LAN, much like a patch bay or an audio console's routing, but for data. When AV devices are on a network, they plug into a switch. A router connects different networks together and is what links a LAN to the internet or to other LANs; it makes the decisions about sending packets beyond the local network.

The simple rule: switches connect devices within a network; routers connect networks to each other. Many small boxes (like a home internet box) combine both functions, but understanding the two roles separately is what lets you reason about any network. In AV, you will most often work with switches connecting your AV devices, sometimes managed switches that offer extra control over the traffic.

Cabling

Networks run on cabling you already met in AV Fundamentals. Copper Ethernet cable — commonly Cat5e or Cat6 — terminated in RJ45 connectors is the everyday workhorse, connecting devices to switches over reasonable distances. Fiber optic cable carries data as light over much longer distances and is used for long runs and high-bandwidth links where copper cannot reach. Choosing and running the right cable, terminated correctly, is foundational network craft.

Cable quality and correct termination matter more on networks than beginners expect: a marginal cable that 'mostly works' can cause intermittent packet loss that shows up as glitches in AV-over-IP audio or video. The same care you bring to AV cables — good cable, proper connectors, tidy routing, testing — applies directly to network cabling, and prevents the maddening intermittent faults that are hardest to chase.

Copper cable categories, the 100 metre limit and T568

Copper Ethernet cable is rated in categories, and the category decides how fast it can carry data and how far.

Cat5e carries 1 gigabit per second to 100 metres. Cat6 carries 1 gigabit to 100 metres and 10 gigabits over a shorter distance, commonly up to about 55 metres. Cat6A carries 10 gigabits to the full 100 metres. Higher categories exist for data centres.

The 100 metre limit is for the whole channel between two active devices: typically up to 90 metres of fixed cable plus patch cords at each end. It is a real limit. Past it, a link may come up and then drop errors, or come up at a lower speed, and the symptoms look like anything but a long cable. Where a run is longer, the answer is a switch in the middle or fiber.

Each end of a cable is wired to one of two standards, T568A or T568B, which differ only in which colour pairs go on which pins. Both ends the same makes a straight-through cable, which is what is used almost everywhere. Modern network ports detect and correct crossed connections automatically, so crossover cables are rarely needed. T568B is common in North America; what matters is that both ends of a cable, and every termination in a building, follow one standard.

Touring AV uses tougher versions of the same thing: shielded, stranded cable in a rugged jacket, often with locking etherCON connectors that protect the RJ45 plug inside. Solid-core cable is for fixed installations and breaks if flexed repeatedly.

A cable tester confirms every pair is wired correctly. A certifying tester goes further and confirms the cable meets its category's performance, which is how installed cabling is signed off. One important clue needs no tester at all: gigabit Ethernet uses all four pairs of the cable, while 100 megabit uses two. A link that comes up at 100 megabits on gigabit equipment very often has a damaged pair.

Fiber, SFP modules, single-mode and multimode

Fiber carries data as light, over distances copper cannot reach, with no electrical connection and no interference. In AV it links stage to front of house, venue to broadcast truck, and building to building.

There are two families. Multimode fiber, usually with an aqua jacket in current types such as OM3 and OM4 (some makers jacket OM4 in violet, common in Europe), carries light in many paths down a wider core, and is used for shorter runs — up to a few hundred metres at 10 gigabits. Single-mode fiber, usually yellow, OS2, carries light down a very narrow core and runs for kilometres.

Network switches connect to fiber through small plug-in transceivers called SFP modules, or SFP+ for 10 gigabits. The module must match the fiber type — multimode or single-mode — and the module at the other end must match it too. The wrong module on the right fiber simply does not link, and a correct link with a dirty connector has errors or drops.

Fiber connectors are small and delicate. The common LC connector comes in pairs, one fiber each way. Touring systems use ruggedised multi-fiber connectors in armoured cable. Every fiber end is kept capped when unplugged, inspected and cleaned with the proper tools before connecting, and never looked into, because the light can be invisible and still damage an eye.

Power over Ethernet

Power over Ethernet, PoE, sends power down the same cable as the data, so a device needs no separate power supply. PTZ cameras, touch panels, wireless access points, small stage boxes, network speakers and microphones commonly run on it.

The standards set how much power each port can deliver. PoE, IEEE 802.3af, provides up to 15.4 watts at the switch port. PoE+, 802.3at, provides 30 watts. The newer 802.3bt provides 60 watts or 90 watts depending on type. A device takes slightly less than the port supplies, because some is lost in the cable.

Two numbers matter on a PoE switch: the power each port can supply, and the total PoE budget for the whole switch. A 24 port switch with a 370 watt budget can run a dozen 30 watt PTZ cameras, but not twenty-four, even though it has the ports. When the budget runs out, the switch refuses power to further devices or cuts power to lower-priority ports, and cameras reboot or never start.

PoE only works if both ends support the same standard, and a device that needs PoE+ will not start, or will start and then fail when its motors move, on a port that supplies basic PoE.

Managed and unmanaged switches

An unmanaged switch has no settings. Plug devices in and it forwards frames between them. It is fine for a small, simple system: a console, a stage box and a laptop.

A managed switch can be configured, usually through a web page or a command line: VLANs, quality of service, multicast handling, PoE priorities, port speeds, link aggregation, and monitoring of every port's status and errors. Almost every professional AV network larger than a handful of devices needs at least some of these, and networked audio and video manufacturers publish the settings their products require.

Every Ethernet link negotiates its speed and duplex automatically. Duplex is whether a link can send and receive at the same time — full duplex, which modern links always should be — or only one direction at a time. Mismatched settings, usually from one end being fixed by hand, cause errors and slow performance. Leaving both ends on automatic, and reading the negotiated speed on the switch, is the normal practice.

Switches are also linked to each other. The connection between them is an uplink, and it has to carry all the traffic between the devices on either side. A 1 gigabit uplink between two switches each full of video devices is a bottleneck however fast the individual ports are.

Loops, broadcast storms and spanning tree

Plug both ends of a patch cable into the same switch, or connect two switches with two cables, and you create a loop. A broadcast frame goes out of one port, comes back in the other, and is sent out again, round and round, multiplying with every pass. Within seconds the network is flooded with copies. This is a broadcast storm: link lights flash solid, every device on the network stops responding, and audio and video drop out entirely.

On a show it usually happens when somebody tidies a rack and plugs a loose cable into the nearest free port.

Managed switches can prevent this with spanning tree protocols, commonly RSTP, which detect loops and block the redundant path. Spanning tree has settings of its own that matter to AV, because a port can take several seconds to begin forwarding while it checks for loops, which is why ports connected to end devices are often configured to come up fast. The settings are part of the network design.

On an unmanaged switch there is no protection, and the fix is physical: find the looped cable and unplug it. When a whole network suddenly stops, ask what was just plugged in.

Wi-Fi for control, and its limits

Wireless networking is convenient for control — a tablet running the lighting console's remote, a wireless touch panel, a phone app adjusting a monitor mix — and it is unreliable for anything the show cannot live without.

Wi-Fi uses the 2.4 GHz band, which travels further and is very crowded, the 5 GHz band, which has more channels and shorter range, and, on newer equipment, 6 GHz. In a room of a thousand people with a thousand phones, every band is busy, and a connection that worked perfectly in an empty room can slow to nothing when doors open.

Good practice for show control on Wi-Fi is a dedicated access point on the show network, not the venue's guest network; a 5 GHz or 6 GHz channel chosen after checking what else is in use; the access point placed close to where the tablets will be; and a wired fallback for anything critical. Some 2.4 GHz wireless microphones, in-ear and intercom systems share the same band, which is another reason to plan frequencies together.

The rule that follows is simple. Audio, video and anything that must not stop travel on cable. Wi-Fi carries convenience.

Copper cable

Fiber

PoE standards and power per port

On the job

A corporate town hall. Eight PTZ cameras are mounted around the room and powered from a 24 port PoE+ switch at the video position. During rehearsal, three cameras keep rebooting whenever the director moves several cameras at once.

The cables test fine and each camera works on its own. You open the switch's web page and look at PoE. The switch has a total PoE budget of 185 watts. Each camera draws around 12 watts at rest and up to 25 watts when its motors move. Eight cameras moving at once ask for about 200 watts, more than the budget, and the switch cuts power to the ports with the lowest priority.

The cameras have been fine all week in the warehouse, where they were tested one at a time.

You move three cameras to a second PoE+ switch, linked to the first, and set the program camera ports to high PoE priority on both. The director drives every camera at once for a full minute. Nothing reboots.

How to do it

1. Inspect the cable and confirm its category suits the speed and distance.
2. For fiber, confirm the module and fiber type match at both ends, and clean and inspect the connectors.
3. Plug into the port the network plan assigns, not the nearest free one.
4. Check the link light and the negotiated speed on the switch.
5. For PoE devices, confirm the port standard and that the switch budget has room.
6. Before plugging any cable into a switch, confirm its other end is not already in the same network.
7. Record the device, port and cable number in the documentation.

What goes wrong

Practice it

Answer before checking.

Addresses & How Devices Talk

Every device needs an address. Get addressing right and the network works; get it wrong and nothing finds anything.

IP addresses

For devices to send packets to each other, each needs an address — an IP address, a unique number identifying it on the network (like 192.168.1.50). A packet carries its destination's IP, and the network delivers it there. This is the network equivalent of a DMX address: a device must have the right address, and no two devices on the same network should share one, or they conflict and communication breaks. Much of basic network setup is simply making sure every device has a correct, unique IP.

Addresses are either set automatically or manually. Many networks use DHCP, a service that hands out IP addresses automatically so devices just work when plugged in. Other times, especially in AV, devices are given fixed (static) addresses so they are predictable and always findable. Knowing whether a network uses automatic or manual addressing — and setting a device accordingly — is a core practical skill.

Subnets and gateways

Two more ideas complete basic addressing. A subnet is a group of addresses that form one local network; a subnet mask tells a device which addresses are local (it can reach directly) and which are elsewhere (it must send via a router). For devices to talk directly, they generally need to be on the same subnet with compatible addresses — a very common AV gotcha is two devices that cannot communicate simply because their addresses put them on different subnets. The gateway is the address of the router that a device sends traffic to when the destination is outside its local subnet — the way out.

You do not need deep IP math at this level. You need the practical picture: devices on the same subnet with unique addresses can talk directly; reaching anything beyond goes through the gateway. When two AV devices will not see each other, the first things to check are that they have unique IPs on the same subnet — that single check resolves a large share of AV network problems.

IPv4 addresses and private ranges

An IPv4 address is 32 bits, written as four numbers from 0 to 255 separated by dots, called octets: 192.168.1.50. Part of the address identifies the network, and the rest identifies the device on that network. The subnet mask, in the next section, says where the line between them falls.

Some address ranges are reserved for private networks, which is what nearly every AV network uses. They are 10.0.0.0 to 10.255.255.255, 172.16.0.0 to 172.31.255.255, and 192.168.0.0 to 192.168.255.255. Private addresses are not reachable from the internet, and the same private addresses are reused in millions of separate networks.

A few other addresses have special meanings. 127.0.0.1 always means this device itself. Addresses from 169.254.0.0 to 169.254.255.255 are link-local, which a device gives itself when nothing else gives it an address. And within any network, the first address identifies the network itself and the last is the broadcast address, so neither is given to a device.

Subnet masks and CIDR, worked

The subnet mask marks which part of an address is the network and which is the device. Written in the same dotted form, 255.255.255.0 means the first three octets are the network and the last octet is the device. The shorter CIDR notation counts the network bits: 255.255.255.0 is /24, because 24 of the 32 bits are network.

On a /24 network such as 192.168.1.0/24, every address from 192.168.1.1 to 192.168.1.254 is a usable device address, 254 of them. 192.168.1.0 is the network address and 192.168.1.255 is the broadcast.

Two devices can talk directly only if they are in the same network. With a /24 mask, that means the first three octets must match. 192.168.1.50/24 and 192.168.1.120/24 are on the same network. 192.168.1.50/24 and 192.168.2.20/24 are not, even though they look almost identical, and without a router between them they cannot communicate at all.

Masks can be larger or smaller. 255.255.0.0, /16, uses the first two octets for the network and allows 65,534 devices. 255.255.254.0, /23, allows 510. 255.255.255.128, /25, allows 126. On a /16 network, 10.10.1.50 and 10.10.200.7 are on the same network, because only the first two octets must match.

The mask must be the same on every device in a network. A device with the right address and the wrong mask may reach some devices and not others, which is one of the most confusing faults there is.

Link-local addresses

A device set to obtain its address automatically asks the network for one. When nothing answers — no DHCP server on the network — most devices give themselves a link-local address in the 169.254.0.0/16 range, choosing a random one and checking nobody else has it.

For some AV systems this is by design. Many networked audio devices use link-local addresses happily on a simple, isolated network with no DHCP server, and everything finds everything else. Dante devices, for example, fall back to link-local (169.254.x.x) on their primary interface and give themselves an address in 172.31.x.x on their secondary.

For almost everything else, a 169.254 address is a sign that a device expected DHCP and did not get it. It will only talk to other link-local devices, and a laptop that has fallen back to 169.254 cannot see devices set to static addresses in another range. When a device shows a 169.254 address and you did not plan for one, find out why DHCP did not answer.

DHCP reservations, DNS and ARP

DHCP gives addresses out automatically for a period called a lease. A device may get a different address next time, which is a problem for anything that must be found reliably, such as a projector a control system commands by address. A DHCP reservation solves it: the DHCP server is told to always give a particular MAC address the same IP. The device still uses DHCP, and its address never changes. Reservations are often preferred by IT to static addresses, because the addresses are managed in one place.

DNS, the domain name system, turns names into addresses, so people and software can use a name such as projector-main.venue.local instead of a number. Many AV devices also discover each other by name on the local network using multicast DNS, which is how networked audio software finds devices without anybody typing an address, and why that discovery often fails across different subnets or VLANs.

ARP, the address resolution protocol, connects the two addressing systems. Before a device sends to an IP address on its own network, it asks, by broadcast, which MAC address has that IP, and remembers the answer. Looking at a computer's ARP table shows which MAC addresses it has found for which IPs, which is a quick way to see what is on a network and to spot two devices answering for the same address.

The gateway, routers and NAT

A device sends traffic for its own network directly. Traffic for anywhere else goes to its default gateway, the address of a router on its network, which forwards it on. A device with no gateway, or the wrong one, works perfectly locally and cannot reach anything beyond. Many isolated AV networks deliberately have no gateway at all.

Routers connect networks and also separate them. Broadcasts do not cross a router, so each routed network is its own broadcast domain, and discovery protocols that rely on broadcasts or local multicast do not see devices on the far side.

A router connecting a private network to the internet usually performs NAT, network address translation. All the devices inside share the router's single public address; outgoing traffic is translated, and replies are translated back. The consequence for AV is important: a device inside can reach out to a cloud service or a streaming platform, but nothing on the internet can reach in to it unless the network is deliberately configured to allow it — which is IT's decision, and usually the wrong way to provide remote access anyway.

IPv6, briefly

IPv6 is the newer version of IP, with addresses 128 bits long, written in hexadecimal groups separated by colons, such as fe80::1c2a:44ff:fe10:9b2c. It exists because the world ran out of IPv4 addresses.

Most AV devices and show networks still run on IPv4, and many AV products do not support IPv6 at all. A technician will see IPv6 addresses on computers, especially link-local ones beginning with fe80, and may meet it on corporate networks. It is worth recognising, and it is rarely where an AV fault lies.

Private and special IPv4 ranges

Common subnet masks

Same network or not? (/24)

• 192.168.1.50 and 192.168.1.120 — same network.
• 192.168.1.50 and 192.168.2.20 — different networks.
• 10.0.0.5 and 10.0.1.5 — different networks.

On the job

A product launch. The control programmer has sent an IP schedule: every device on 192.168.10.x, mask 255.255.255.0. The video technician sets up the LED processor, the media servers and the switcher, and the touch panel can control all of them except the second media server, which does not respond.

The media server's network settings show 192.168.10.62, which looks right. Its mask is 255.255.0.0. It can see some devices and not others, and replies never quite make it back the way they should.

That is only half of it. When you ping 192.168.10.62 from your laptop, you get a reply — but the ARP table shows the reply came from a MAC address belonging to a different manufacturer. A laptop that the client's team plugged in during the morning has taken 192.168.10.62 as a static address.

You ask the client's team to move their laptop to an address the IP schedule has spare, set the media server's mask to 255.255.255.0, and the touch panel controls it at the first press. The spare addresses go on the schedule in bold, with a note that guest laptops use DHCP on a separate network.

How to do it

1. Get the address, mask and gateway from the IP schedule, not by guessing.
2. Confirm no other device uses the address — ping it first and check the ARP table.
3. Enter the address, mask and gateway exactly, with the mask matching the whole network.
4. Leave the gateway blank only if the network design says there is none.
5. Save, and restart the network interface if the device requires it.
6. Ping the device from a laptop on the same network.
7. Record the address, MAC address and switch port in the documentation.

What goes wrong

Practice it

Answer before checking.

Ports, Protocols and Traffic

An IP address gets data to the right device. Something more is needed to get it to the right service on that device, in the right way: a stream of audio, a web page, a control command and a discovery message all arrive at the same address. That is the job of the transport layer — TCP and UDP, and the port numbers they carry — and of the rules about how traffic is addressed: to one device, to all of them, or to a group.

This chapter covers TCP and UDP, port numbers and the ones AV uses, unicast, broadcast and multicast, IGMP and why multicast can flood a switch, and firewalls, which are the most common reason an AV system that worked in the warehouse fails on a client's network.

TCP and UDP

Two transport protocols carry nearly all traffic, and they make opposite trade-offs.

TCP, the transmission control protocol, sets up a connection between two devices before sending, numbers every piece of data, confirms each one arrived, and resends anything lost. Data arrives complete and in order, at the cost of delay whenever something has to be resent. Web pages, file transfers, most control commands and device configuration use TCP.

UDP, the user datagram protocol, just sends. No connection, no confirmation, no resending. Whatever is lost is lost, and whatever arrives arrives as fast as possible. Live audio and video streams use UDP, because a packet resent a moment later is useless to a sound that has already been played, and so do discovery messages, lighting data such as sACN and Art-Net, and many camera control protocols.

The practical consequences are simple. A TCP control connection either works or reports that it failed, and a control system can reconnect. A UDP stream degrades when the network loses packets — clicks, dropouts, frozen frames — with nothing on either end reporting an error. When AV over IP stutters, the network is dropping UDP packets somewhere.

Port numbers

A port number identifies which service on a device a piece of data is for. A device at one IP address can run a web server on port 80, a control service on port 23 and a streaming service on another, all at once, and the port number sends each packet to the right one. Port numbers run from 0 to 65,535; those below 1,024 are well-known ports reserved for common services.

A few ports turn up again and again in AV. Web configuration pages use port 80 for HTTP and 443 for HTTPS. Telnet, the plain-text terminal protocol many devices accept control commands on, uses port 23, and its secure replacement SSH uses 22. The PJLink projector control protocol uses TCP port 4352. sACN lighting data uses UDP port 5568, Art-Net UDP port 6454, and VISCA over IP camera control commonly uses UDP port 52381. Networked audio and video systems use their own documented ranges of ports.

Here the word port means two things, and it confuses people constantly. A switch port is a physical socket. A TCP or UDP port is a number. When IT asks which ports your system needs, they mean the numbers, and the answer comes from each manufacturer's documentation.

Unicast, broadcast and multicast

Traffic can be addressed three ways, and each behaves differently on a switch.

Unicast traffic goes from one device to one device. The switch sends it only out of the port where the destination is. Most control commands, web pages and many audio flows are unicast.

Broadcast traffic goes to every device in the network. The switch sends it out of every port. Discovery messages, ARP and DHCP requests are broadcasts. A little broadcast is normal; a lot slows every device.

Multicast traffic goes to a group of devices that have asked to receive it. It uses addresses in the range 224.0.0.0 to 239.255.255.255, each one a group, and a device joins a group to receive its traffic. It is efficient for anything many receivers want at once: an audio flow sent to several consoles and recorders, a video stream to several displays, a lighting universe sent to many nodes, and the clock messages that keep networked audio in time.

IGMP snooping, and why multicast can flood a switch

A switch that knows nothing about multicast treats it like broadcast and sends it out of every port. With a little multicast traffic that is harmless. With several high-bandwidth audio or video multicast streams, every port on the switch — including the port to a touch panel, a laptop or an access point — receives all of it. Slow devices are overwhelmed, links fill up, and the network degrades for everyone.

IGMP, the internet group management protocol, is how devices say which multicast groups they want. A managed switch with IGMP snooping enabled listens to those messages and sends each multicast stream only to the ports that asked for it. For IGMP snooping to work, the network also needs an IGMP querier: one switch or router that periodically asks devices which groups they still want. Without a querier, snooping switches may stop forwarding streams after a few minutes, or fall back to flooding, depending on the switch.

This is one of the most common reasons an AV network works during a small test and falls apart at full scale. The fix is in the switch configuration, following the AV manufacturers' guidance, and it is usually decided by whoever designed the network.

Firewalls, and why AV breaks on corporate networks

A firewall allows or blocks traffic according to rules: by address, by port, by protocol, and by direction. Corporate and venue networks are full of them — in routers, in switches, on every laptop — and their job is to block anything not explicitly allowed.

AV systems are often built and tested on an isolated network where nothing is blocked, then moved onto a client's network, where almost everything is. Control commands to a port that is not open, multicast that is not allowed to cross between VLANs, discovery that relies on local multicast, a streaming encoder whose outbound ports are closed, and a laptop whose own firewall blocks incoming control connections all fail silently. From the AV side it simply looks as if the devices are not there.

Guest Wi-Fi networks usually add client isolation, which stops devices on the same wireless network from talking to each other at all. A tablet on guest Wi-Fi can reach the internet and cannot reach the processor three metres away.

The fix is never to bypass the firewall. It is to give the network's owners an exact list of what the AV system needs — devices, addresses, ports, protocols and directions — and to test on the real network well before the show.

TCP and UDP compared

Port numbers worth recognising

Three ways to address traffic

On the job

A corporate client's new boardroom is being handed over. In the integrator's warehouse, the touch panel controlled the ceiling camera, the display and the DSP perfectly. Installed in the building, the panel controls the display and the DSP, and the camera ignores every command.

Layer 1 is fine, and the camera answers a ping. The panel reaches the display over TCP port 4352 and the DSP over TCP. The camera is controlled with VISCA over IP, which uses UDP.

You ask the client's network team whether anything between the boardroom VLAN and the AV VLAN filters UDP. It does: their policy allows the specific TCP ports the integrator listed in the handover document, and the list, written from memory, never mentioned UDP port 52381.

The network team adds the rule, the camera moves at the first press, and the integrator's handover document gets a new section listing every protocol and port for every device, taken from each manufacturer's documentation rather than memory.

How to do it

1. List every device, its address, and what it talks to.
2. For each connection, look up the protocol, TCP or UDP, and the port numbers in the manufacturer documentation.
3. Note any multicast traffic, and what discovery the system relies on.
4. Note any traffic that must reach the internet, such as streaming or cloud management.
5. Give the list to the network owner, with directions for each connection.
6. Test every connection on the real network before the event or handover.
7. Keep the list with the system documentation.

What goes wrong

Practice it

Answer before checking.

AV Over the Network

The reason this matters: modern audio, video, and control all ride on the network you now understand.

AV-over-IP

AV-over-IP means carrying professional audio and video as data over a standard network instead of over dedicated AV cables. Its appeal is huge: one network can carry many channels of audio and video, route them flexibly in software, and run over the same infrastructure as everything else. This is why networking is now core AV knowledge — the signal you are responsible for is increasingly a stream of packets on a switch, not a dedicated cable you can trace by hand.

There are standards for different media. Networked audio commonly uses Dante (very widely adopted in pro audio) or the AES67 standard. Networked video uses things like NDI (popular and flexible) or the broadcast standard ST 2110. You do not need to master each yet; you need to recognize that these are AV signals traveling as network data, set up with IP addresses on a network, and troubleshot with networking thinking on top of AV thinking.

Keeping AV traffic clean

AV traffic has special needs: it is continuous and timing-sensitive, so it cannot tolerate the delays and drops that ordinary data shrugs off. Two tools keep it clean. A VLAN (virtual LAN) separates the network into logical segments, so AV traffic is isolated from other traffic that might congest it — putting the AV devices on their own VLAN is a common best practice. Quality of Service (QoS) prioritizes important traffic, so time-critical AV packets get through ahead of less urgent data.

This is why AV networks are often designed and configured deliberately rather than just plugged together — and often use managed switches that support VLANs and QoS. As a beginner you may not configure these, but you should understand why they exist: to give AV the reliable, prioritized, isolated network it needs. A flat, shared, unmanaged network can work for small setups but causes glitches as AV-over-IP scales.

Networked audio — Dante, AES67 and the clock

Networked audio carries many channels of uncompressed audio between devices on an ordinary Ethernet network, with very low delay. The most widely used system in live and installed audio is Dante, and devices from many manufacturers use it.

A Dante device advertises its channels on the network by name, and routing is set by subscribing a receiver's channel to a transmitter's channel, in software. Devices find each other with multicast discovery, which is why they appear automatically on a simple network and may not across subnets without extra configuration.

Every device on a Dante network agrees on time using PTP, the precision time protocol, with one device elected as the clock leader. PTP messages are small and must arrive with very consistent timing, which is why networked audio cares so much about switch settings, as the next section shows.

Dante devices commonly have primary and secondary network ports for redundancy: two completely separate networks carrying the same audio, so a failure on one loses nothing.

AES67 is an open interoperability standard for networked audio. Many Dante devices, and devices from other audio networking systems, can be switched into an AES67 mode so they exchange audio with each other. It needs more manual configuration than Dante on its own, and uses a different version of PTP, but it allows systems from different families to share audio.

Switch settings networked audio depends on

Networked audio will run on almost any switch in a small, quiet test. On a real show network it depends on three settings, and manufacturers publish exactly what they require.

Quality of service. Busy links are shared, and without priorities a burst of other traffic can delay the clock messages and audio packets enough to cause clicks or dropouts. QoS lets the switch send marked traffic first. Traffic is marked with DSCP values in each packet, and the switch is set to give them strict priority. Dante's guidance puts PTP clock traffic, marked CS7 (value 56), at the highest priority, and audio, marked EF (value 46), next.

Energy Efficient Ethernet, EEE, sometimes called green Ethernet, lets switch ports briefly power down during quiet moments to save energy. The tiny delays as a port wakes up disrupt clock timing, and the result is dropouts. It is turned off on ports carrying networked audio.

IGMP snooping, from the previous chapter, matters as soon as the system uses multicast audio flows or multicast clock traffic across several switches.

None of these is visible from the outside. A show network assembled from switches nobody has configured can pass a sound check and fail when the stream to the broadcast truck starts.

Networked video — NDI, ST 2110, SDVoE and IPMX

Video over IP comes in several families, built for different jobs, and their bandwidth needs differ enormously.

NDI is widely used in live production, streaming and corporate AV. It is compressed video designed for ordinary gigabit networks: a full-bandwidth 1080p60 NDI stream uses around 125 megabits per second, and the lighter NDI HX variants use far less at the cost of more compression and delay. Sources appear on the network by name and receivers select them, and PTZ camera control and tally can travel alongside the video.

SMPTE ST 2110 is the broadcast standard for video over IP. It sends video, audio and data as separate streams, usually uncompressed, all timed by PTP. An uncompressed 1080p60 video stream is around 2.5 gigabits per second, so ST 2110 networks are built on 10, 25 and 100 gigabit switches with careful design.

SDVoE and similar pro AV systems send near-uncompressed video over 10 gigabit networks with very low delay, replacing HDMI extenders and matrix switchers in large installations. IPMX is an open standard for pro AV built on the ST 2110 family, adding things pro AV needs such as copy protection support.

Meeting room AV over IP products, often compressed and designed for 1 gigabit networks, are the most common of all: transmitters at sources, receivers at displays, and a switch as the matrix.

The arithmetic of any of them is the same: add up the bit rate of every stream that crosses a link, and make sure the link carries it with room to spare.

Bandwidth budgets

A network link is a pipe of fixed size, and every stream through it takes a share. A budget adds them up.

A 1 gigabit link carries about 1,000 megabits per second in theory, and should be planned to carry considerably less in practice, commonly no more than around 70 to 80 percent, so bursts and background traffic have room. Eight full-bandwidth NDI streams at 125 megabits each are 1,000 megabits — the whole link, which is therefore not enough. Six fit with some headroom.

Networked audio is light by comparison. A 64-channel flow of 48 kilohertz, 24-bit audio is roughly 75 megabits per second, so audio seldom fills a gigabit link, though it is the traffic most sensitive to delay.

Uplinks between switches matter most, because they carry everything that passes between them. A system where every camera is on one switch and every receiver on another sends all the video through a single uplink, and that link is the budget.

AV over IP families

Switch settings for networked audio

On the job

A conference with networked audio between a stage rack, front of house and a broadcast truck, all on switches supplied by the rental company. Sound check is clean. When the broadcast truck starts pulling its NDI camera feeds over the same network for the live stream, front of house starts hearing regular clicks, and the networked audio software shows clock errors on two devices.

The switches are managed but have their factory settings. There is no QoS, Energy Efficient Ethernet is on, and IGMP snooping is off. With the video running, the uplink between the stage switch and the front of house switch is carrying nearly 800 megabits per second of NDI, flooded to every port, and the clock messages are waiting in queues behind it.

You call the break and, with the production's network engineer, apply the audio manufacturer's published switch settings: strict QoS with the clock and audio marks, EEE off, and IGMP snooping with a querier. The video is moved to its own VLAN.

Back on air, the uplink still carries the video, the audio sits ahead of it in the queue, and the clicks are gone for the rest of the event.

How to do it

1. Find the manufacturer's published switch requirements for each AV system on the network.
2. Configure QoS with strict priority for the DSCP values the audio system uses.
3. Turn off Energy Efficient Ethernet on AV ports.
4. Enable IGMP snooping and make sure one querier exists.
5. Separate traffic types with VLANs as the network design requires.
6. Add up stream bit rates across every uplink, with headroom.
7. Test at full load — every stream running — before the show.

What goes wrong

Practice it

Answer before checking.

Control Systems

A room with a touch panel is two systems. One carries signals: microphones to loudspeakers, laptops to displays. The other carries commands: press "Presentation" and the display turns on, the screen lowers, the lights dim, the switcher selects the lectern and the microphone unmutes. The second system is the control system, and it now lives almost entirely on the network.

This chapter explains what a control system is made of, where its logic lives on the common platforms, and where a technician's work ends and a programmer's begins. The next chapter covers the protocols it uses to talk to devices.

Interface, processor and controlled devices

Every control system has three parts.

The user interface is what a person touches: a touch panel on a lectern or a wall, a keypad of buttons, an app on a tablet, a web page, or a scheduled event, an occupancy sensor or a fire alarm input that acts without anybody pressing anything. It sends a request — "the user pressed button 12" — and shows feedback, such as which source is selected and whether the display is on.

The control processor holds the program: the logic that turns one button press into everything the room needs to do, in the right order, with the right delays. It has control ports of several kinds — infrared outputs, serial ports, relays, input and output contacts, and a network connection — and it keeps track of what state every device is in.

The controlled devices are everything the processor commands: displays and projectors, switchers and matrices, DSPs, cameras, lighting and shading systems, screens, lifts, video conferencing codecs and more. Each has its own control protocol, and the processor speaks each one.

Traced as signal flow, a button press is a source, the processor is processing, and every controlled device is a destination, with feedback flowing back the other way. That makes a control fault findable in exactly the way any other signal fault is: did the press leave the panel, did the processor receive it and send the command, did the command reach the device, and did the device act and reply?

The platforms, and where the logic lives

Several control ecosystems dominate AV, and each puts the program in a slightly different place, which decides where a technician looks when something does not work.

Crestron systems use dedicated control processors and touch panels, with programs written by trained programmers in Crestron's own tools and loaded onto the processor. Extron control processors are often set up with configuration software, choosing devices and buttons from libraries rather than writing code, though they can also be programmed. AMX, now part of HARMAN, follows a similar processor-and-panel model. Q-SYS combines audio DSP, video and control on one core processor, with control logic built in a design file and scripting for custom behaviour. Many other manufacturers make smaller control systems, and videoconferencing rooms often run control from the room's own computer or conferencing system.

In every case there is a program or configuration file that defines the room's behaviour, device modules or drivers that know each controlled device's protocol, and an address or port for every controlled device. When a device is replaced with a different model, changes address or is moved to a different port, the program or configuration must know, or the button stops working even though the new device is perfectly fine.

A technician does not need to program any of them. A technician needs to know which platform a room uses, where its program lives, who maintains it, and how to see what the processor is doing — most platforms offer a web page, a debugging tool or a log that shows commands being sent and replies arriving.

Configuring against programming

The line in control work is between configuring a system and programming it, and knowing where it falls prevents a lot of damage.

A technician's work is the infrastructure: running and terminating control cables, connecting the right port to the right device, setting each controlled device's address and control settings as the documentation specifies, making sure devices have network control enabled, testing that each device responds to its commands, and reporting clearly what works and what does not.

A programmer's work is the logic: writing and changing the program, adding or updating device modules, designing the user interface, changing what buttons do, and loading new files onto the processor.

The two meet at commissioning, when the programmer and the technician work through every button and every device together. And they meet whenever something breaks: the technician proves whether the device and the path work, and the programmer fixes the logic. A technician who loads an old program file onto a processor to "reset it", or changes a device's address to one the program does not expect, turns a small fault into a large one.

The parts of a control system

Who does what

On the job

A university lecture theatre. Over the summer the old projector was replaced with a new laser projector from a different manufacturer. Since term started, the lectern touch panel's "System On" button lowers the screen and turns on the audio, and the projector stays off.

The facilities technician's first instinct is that the new projector is faulty. You check what the button actually does. The control processor's web page shows its log: when "System On" is pressed, it sends a power-on command out of its serial port 1 in the old projector's protocol. The new projector is connected to the network, not to serial port 1, and speaks a different protocol.

The projector is fine. The control system still believes the old one is installed. Nobody told the programmer the model changed.

You confirm the new projector responds to its own power command over the network, write down its model, address and protocol, and send them to the integrator's programmer. She loads the new projector's module and address into the program the next morning, and "System On" works. Your note goes in the room's documentation, so the next replacement gets a programmer's visit before the new projector is hung.

How to do it

1. Note exactly which button, and what should and did happen.
2. Check the controlled device is powered, connected and has control enabled.
3. Look at the processor's log or debugging tool to see whether the command was sent.
4. If it was sent, confirm the device's address, port and protocol match what the program expects.
5. Test the device directly with its own command, as the next chapter describes.
6. Report to the programmer what the processor sends and how the device responds.
7. Never load or change the program unless you are the one responsible for it.

What goes wrong

Practice it

Answer before checking.

Control Protocols and Show Control

A control processor speaks to each device in that device's own language, over whatever connection the device accepts. Some devices take infrared from a stick-on emitter, some take text commands over a serial cable, some need a relay to close, and most now take commands over the network. The command itself is an exact sequence of characters or bytes, and a single wrong character, a missing end-of-line or the wrong port makes the device ignore it.

This chapter covers every common kind of control connection, what a command string actually is, feedback and polling, the standard protocols for projectors, cameras, displays and monitoring, the show control protocols that trigger lighting, audio, video and playback together on live events, and how to test any command yourself.

Infrared control

Infrared control imitates a handheld remote. A small IR emitter is stuck over the device's infrared sensor and wired to an IR output on the control processor, which flashes the same codes a remote would.

It is the control of last resort for devices with no better option — some displays, media players and cable boxes — and it has three weaknesses. It is one-way: the processor never learns whether the command worked. It is easily blocked or knocked: an emitter that falls off, a sensor covered by a label, or bright sunlight reaching the sensor stops it. And many remotes use toggle codes, where the same power button turns a device on and off, so a system that sends "power" to a device that is already on turns it off.

Good IR control uses discrete codes where the device has them — separate codes for power on and power off, and for each input — and positions each emitter carefully with its own lead to one device, so it cannot also control the device next to it.

Serial control — RS-232, RS-422 and RS-485

Serial control sends commands as a stream of characters over a few wires, one bit at a time. Projectors, displays, switchers, cameras, DSPs and older equipment of every kind accept it, and it is reliable once set up correctly — which depends on details that must match exactly at both ends.

RS-232 is the most common. It connects one device to one device, over a short distance, around 15 metres. On the common 9-pin connector, one pin transmits, one receives and one is ground: on a computer-style port, pin 2 receives, pin 3 transmits and pin 5 is ground. Transmit on one end must reach receive on the other. Where both ends are wired the same way, a null modem cable or adaptor crosses pins 2 and 3; where they differ, a straight cable is right. Control processors often use small screw terminal connectors labelled TX, RX and G, and the same rule applies: TX to RX, RX to TX, ground to ground.

Both ends must also agree on the communication settings: the baud rate, the speed, such as 9600, 19200, 38400 or 115200; the number of data bits, almost always 8; the parity, usually none; and the stop bits, usually 1. That last combination is written 8N1. Flow control is usually off. The device's protocol document lists them, and one wrong setting produces nothing but silence or garbage characters.

RS-422 and RS-485 use balanced pairs of wires to run much further — hundreds of metres — and RS-485 allows several devices to share one pair, each with its own address. Many PTZ cameras and some lighting and building systems use them.

Relays, contact closures and GPIO

The simplest control of all is a switch. A relay output on a control processor is a switch it can open or close, electrically separate from the processor, often described as a dry contact because it provides no voltage of its own. It has a common terminal and a normally open or normally closed terminal, and it switches whatever is wired through it.

Relays drive motorised projection screens (one relay for up, one for down, pulsed briefly), lifts, curtain and blind motors, cue lights, "on air" signs and the trigger inputs on other equipment. Two relays that must never close together — screen up and screen down — are interlocked in the program. A relay switching anything at mains voltage is wired by an electrician, and the relay's rating must suit the load.

Inputs work the other way. A GPIO input, general-purpose input and output, senses a contact closing or a voltage appearing: an occupancy sensor, a door, a button on a wall, a fire alarm panel's output telling the AV system to mute and show an evacuation message. In broadcast and live video, the same idea is called GPI and GPO: a switcher closes a contact to start a recorder, fire a graphic or light a tally.

IP control

Most control now travels over the network. The processor opens a connection to the device's IP address on the port its control protocol uses, sends a command, and reads the reply.

The simplest form is a raw TCP connection, often on a port the manufacturer chooses, sending the same text commands the device accepts over serial. Many devices accept Telnet on port 23, which is the same idea with a terminal protocol around it, and some ask for a username and password first. Some accept commands over UDP, which needs no connection and gives no confirmation.

Newer devices increasingly offer APIs over HTTP or HTTPS: the processor sends a web request to a particular address on the device, often carrying data in JSON, and receives a structured reply. Some use WebSockets, which keep a connection open for continuous feedback.

Three practical points follow. The device must have a fixed address, by static setting or DHCP reservation, or the processor loses it. A TCP connection that drops — because the device rebooted or the network blinked — must be reopened, and good programs do this automatically. And the device must have network control enabled, which on many projectors and displays is off by default or disabled in their power saving modes.

Command strings — ASCII, hex and delimiters

A command is an exact sequence of characters or bytes, and the device's protocol document, sometimes called its control or API specification, lists them. Two kinds are common.

ASCII commands are readable text. A projector might expect "%1POWR 1" to turn on, or a switcher "1*3!" to route input 1 to output 3. Case matters, spaces matter, and so does every symbol.

Hex commands are raw byte values, written in hexadecimal because they are not printable characters. A camera using VISCA expects the bytes 81 01 04 00 02 FF to turn on. In control software they may be written as \x81\x01\x04\x00\x02\xFF, or $81$01$04$00$02$FF, depending on the platform.

Most text protocols also need a delimiter at the end, telling the device the command is complete. The usual ones are carriage return, written CR, \r or hex 0D, and line feed, written LF, \n or hex 0A, alone or together. A command that is perfect in every character but missing its delimiter is simply never executed, and this is the single most common reason a correct-looking command does nothing.

Some protocols add a checksum, a value calculated from the rest of the command, so the device can reject a corrupted message.

Feedback and polling

Two-way control lets the control system know what the room is actually doing, not just what it last told it to do.

Most network and serial protocols reply to a command, confirming it was received or reporting an error. Many also allow queries: "what is your power state?", "which input is selected?", "what is the lamp or laser hour count?". Some devices send unsolicited feedback when something changes, such as a user pressing a button on the device's own front panel.

A control system keeps its buttons honest by polling: sending status queries at intervals and updating the user interface from the replies. When somebody turns a projector off with its own remote, a polled system notices within seconds and shows it off. A system that never listens keeps showing it on.

Polling has a cost. A device asked for its status many times a second by several systems can become slow to respond to real commands, and some devices can only handle one control connection at a time, so a technician's laptop connected to the control port can lock the control processor out.

Standard device protocols — PJLink, VISCA, CEC and SNMP

Most devices have their own protocols, but a few shared standards save a great deal of work.

PJLink is a standard for controlling projectors and displays over the network, supported by many manufacturers. It uses TCP port 4352 and simple text commands: power on and off, input selection, audio and video mute, and queries for errors and lamp hours. A command such as "%1POWR 1" followed by a carriage return turns a projector on. PJLink may require a password, and its first class covers the basics while a later class adds more.

VISCA is a camera control protocol created by Sony and widely adopted by PTZ camera manufacturers. It carries pan, tilt, zoom, focus, presets and power, over RS-232 or RS-422 and over IP, commonly on UDP port 52381. Its commands are hex bytes.

CEC, consumer electronics control, travels inside HDMI and lets devices turn each other on and switch inputs. It is convenient in homes and unreliable in professional systems, because manufacturers implement it differently; many integrators disable it so devices do not wake or switch unexpectedly.

SNMP, the simple network management protocol, is used for monitoring rather than control: network switches, UPS units and many AV devices report their status and send alerts to monitoring software. IT departments use it widely, and AV monitoring systems use it to tell a support team that a projector's laser is failing before a user notices.

Show control — MIDI, MIDI Show Control, OSC, sACN, Art-Net and timecode

On live events, control means making lighting, audio, video, playback, effects and automation happen together, precisely, on cue. Show control uses its own protocols.

MIDI began as a way for musical instruments to control each other, on 5-pin DIN cables, now more often over USB or the network. Its note, program change and control change messages are used to trigger playback, recall console scenes and fire cues. MIDI Show Control, MSC, is an extension that carries theatrical commands — go, stop, resume, with cue numbers — to lighting, sound and video systems.

OSC, Open Sound Control, sends messages over the network, usually UDP, with readable addresses such as /cue/12/go and values attached. Playback software, audio consoles, media servers and custom show controllers commonly accept it, because it is flexible and easy to read.

sACN and Art-Net carry DMX lighting universes over the network, as other books in this library explain in depth. For show control they matter because media servers, LED processors and effects controllers often take their control from the lighting console this way, so the lighting desk becomes the show's master controller.

Timecode — as SMPTE linear timecode, MIDI timecode or over the network — labels every moment of a show, so devices can fire cues at exact times rather than on a button press. A show running to timecode needs every device to follow the same source.

Show control adds one rule that installed control does not always need: reliability under pressure. Critical cues have a manual backup, controllers and playback are often duplicated, and the operator can always stop everything with one action.

Testing a command with a terminal program

The single most useful control test a technician can do is to send a command to a device directly, from a laptop, without the control system. If the device responds, the device, its settings and the network path are proven, and any fault is in the program or the processor. If it does not respond, the fault is in the device or the path, and no amount of programming will fix it.

A terminal program opens a TCP, UDP or serial connection and lets you type or paste commands and see replies. Free tools exist for every computer, and many handle hex as well as text.

The test itself is simple. Put the laptop on the same network as the device, with an address in the same subnet, or connect it to the device's serial port with the right cable and settings. Open a connection to the device's IP address and control port, or open the serial port at the device's baud rate and 8N1. Type the command exactly as the protocol document shows, add the right delimiter, and send it. Watch for a reply and watch the device.

Common results tell you a lot. A connection that is refused means the port is wrong, control is disabled or the device is in a network standby mode. A connection that opens with no reply to the command usually means a missing delimiter or a typing error. Garbage characters on serial mean the baud rate is wrong. A reply of "error" means the device heard you and did not like the command.

Close the connection when you finish. Some devices accept only one control connection, and a forgotten terminal session locks the control processor out.

Network standby and device control settings

The most common reason a projector or display ignores IP control is not the network and not the program. It is a setting inside the device.

To meet energy regulations, many projectors and displays have a low-power standby mode that switches their network interface off when the device is off. The device answers perfectly while it is on, and the moment it is turned off, it disappears from the network, and the control system can never turn it back on. The setting may be called network standby, standby mode, eco mode, power saving or quick start, and it needs to be set so the network stays active in standby.

Other settings matter too: network control or remote control enabled, the control port, a control password, which serial port is used for control, and sometimes whether the device accepts commands only from particular addresses. A device reset to factory defaults, replaced under warranty or updated with new firmware may have all of them back to their defaults.

So the setup of every controlled device includes its control settings, written in the documentation, and checking them is the first step whenever a device that used to respond does not.

Control connections compared

Serial settings and delimiters

Standard and show control protocols

On the job

A corporate headquarters' auditorium. The control system turns the laser projector on every morning at 8 a.m. for the first meeting, and for a week it has failed. By mid-morning somebody always turns it on with the remote, and after that the touch panel controls it perfectly all day.

The processor's log shows the 8 a.m. power-on command being sent to the projector's address, and no connection. At 11 a.m., after the remote has turned the projector on, commands connect and work.

You bring a laptop, put it on the AV network with a spare address from the IP schedule, and open a terminal connection to the projector's address on PJLink port 4352 while the projector is off. The connection is refused. You turn the projector on with its remote, try again, and it connects; "%1POWR ?" with a carriage return replies that it is on.

In the projector's menu, its standby mode was set to eco. A firmware update the week before, installed by the manufacturer's service visit, had reset it from the network-active setting. You set standby to keep the network active, turn the projector off, and send "%1POWR 1" from the terminal. It powers on. The next morning at 8 a.m. the schedule works, and the standby setting is added to the room's documentation, along with a note to check it after every service visit.

How to do it

1. Find the device's protocol document, control port, settings and command list.
2. Check the device's control settings and standby mode in its menu.
3. Connect a laptop on the same subnet, or to the serial port with the right cable.
4. Open a TCP, UDP or serial connection with the correct address, port or serial settings.
5. Send a harmless query first, such as power status, with the correct delimiter.
6. Read the reply, then send the command you are testing and watch the device.
7. Close the connection so the control processor is not locked out.
8. Report what the device did and did not do, with the exact commands used.

What goes wrong

Practice it

Answer before checking.

Troubleshooting Networks

Network problems feel mysterious until you trace them the same way you trace any signal.

A troubleshooting approach

Network troubleshooting is signal-flow tracing applied to data. When a networked device will not communicate, you walk the path: is it powered and physically connected (link lights on the device and switch)? Is the cable good (the classic culprit — swap it)? Does the device have a correct, unique IP on the right subnet? Can it reach the gateway if it needs to? Stepping through this checklist methodically, from physical layer up to addressing, isolates most problems quickly, just as tracing an audio chain finds a dead channel.

The single most common AV network fault is an addressing mistake — a duplicate IP, or two devices on different subnets that cannot see each other — followed closely by a bad cable. Checking the physical connection and the IP settings first resolves a large majority of issues. Calm, methodical tracing beats random rebooting; the network is logical, and the fault is always at a specific, findable point on the path.

Working with IT and good habits

On many jobs the network is shared with, or owned by, an IT department, and a valuable skill is working with them well. That means communicating in their terms (you now have the vocabulary — IP, subnet, VLAN, switch), asking for what your AV gear needs (addresses, ports, possibly a VLAN), and respecting that they are responsible for the wider network. The AV professional who can bridge the AV world and the IT world is increasingly indispensable, because so much AV now lives on IT's turf.

Good habits prevent most problems: document your AV network (what device has what address), use static addresses for critical AV gear so it is predictable, label network cables, and keep the AV network as clean and isolated as the situation allows. The same discipline that makes you a good AV tech — prep, documentation, methodical troubleshooting — makes you a capable networker. Networking is not a separate, scary world; it is the AV mindset applied to data.

Practical sign-off

Networking is learned hands-on. The learner connects devices to a switch, sets unique IPs on the same subnet, gets two AV devices communicating, and troubleshoots a deliberate fault (a duplicate IP or bad cable). A mentor signs off when the learner can set up and troubleshoot a small AV network.

• Connected devices to a switch with good, tested cabling
• Set unique static IPs on the same subnet
• Got two AV-over-IP devices communicating
• Troubleshot a network fault (addressing or cable) methodically

The tools that turn a guess into a fact

A handful of free tools on any laptop answer most network questions in seconds.

ping sends a small message to an address and reports whether a reply comes back and how long it took. A reply proves the device is on the network and reachable at layer 3. No reply is less certain, because some devices and many firewalls deliberately ignore ping, so it proves only that this test failed.

ipconfig on Windows, and ifconfig or the network settings on a Mac, show your own laptop's address, mask and gateway. Checking your own settings first saves a surprising amount of time, because a laptop in the wrong subnet sees nothing.

arp -a lists the IP and MAC addresses your laptop has recently talked to. It shows what is on the network, and it reveals duplicate addresses when the MAC for an IP is not the device you expected.

traceroute, or tracert on Windows, shows each router a packet passes through on the way to a destination, which shows where traffic stops when crossing between networks.

Manufacturer discovery tools — networked audio controllers, device finders, NDI tools — list their devices with their addresses and status, and are often the fastest way to see what is really on the network. A managed switch's own web page shows which ports have links, at what speed, with how many errors, and which MAC addresses it has learned on each.

Packet capture software such as Wireshark records the actual traffic on a link. It is a specialist tool, and knowing it exists — and that a network engineer can use it to see exactly which commands were sent — is enough at this level.

Securing AV devices

Every networked AV device is a computer, and on a client's network it is a potential way in. Security is part of a technician's job, not only IT's.

Change default passwords. Many AV devices ship with a known default username and password, published in their manuals, and leaving them unchanged on a corporate network lets anyone on that network reconfigure them. Store the new credentials securely, in the place the client or the company specifies, not on a note taped to the rack.

Keep firmware current, from the manufacturer's official source, and follow the change process agreed with the client, because an update can also reset settings, as the control chapter showed.

Turn off services that are not needed. A device that accepts unencrypted Telnet control when the system does not use it is an open door.

Keep the AV network separate. AV devices belong on their own network or VLAN, connected to the client's network only where and how the client's IT team agrees. Never plug a show switch into a venue network to borrow internet access, and never connect a laptop with remote-access software to a show network without permission.

Provide remote access only through methods the network owner approves. Opening ports on a firewall so an integrator can reach a processor from the internet is how AV systems end up on lists of exposed devices.

Documenting an AV network

A network that is not documented is a network only one person understands, and that person is never on site when it fails.

The core document is the IP schedule: a table of every device with its name, model, location, IP address, subnet mask, gateway, VLAN, the switch and port it connects to, its MAC address, and a reference to where its credentials are stored. It is written before the system is built and corrected as it is built.

A port map shows, for each switch, what is plugged into every port and which VLAN each port belongs to. A VLAN table lists each VLAN's number, name, purpose and address range. A list of protocols and ports, as the traffic chapter described, goes to IT. For controlled devices, the documentation adds the control connection, protocol, port or serial settings, and the device settings that make control work, such as standby mode.

A naming convention ties it together. Names such as FOH-SW-01, STAGE-DANTE-RACK-A or AUD1-PROJ-MAIN say what and where a device is, and when the same name appears on the label, the IP schedule, the switch port description and the discovery software, anybody can match them.

Network tools

An IP schedule

On the job

A three-day festival. On the second morning, the production's networked audio stops between the main stage and the broadcast compound, while everything else on the network carries on.

You start at layer 1 with the switch pages rather than walking the site. The port map says the link to the compound is fiber on port 24 of MAIN-SW-01. Its web page shows port 24 linked at 1 gigabit, with a rapidly climbing error count. The far end, COMPOUND-SW-01 port 24, shows the same.

A link with errors is a physical layer problem. The fiber route runs past the catering area, and the overnight crew moved a generator. At the point where the cable crosses the service road, a vehicle has driven over the unprotected fiber, and it is crushed but not quite broken.

The spare fiber pair in the same cable tests clean, so you move both ends to it — the port map says exactly which connectors to use — and the error count stops rising. The damaged cable is replaced at the next changeover, a cable ramp goes over the road crossing, and the port map records which fiber pair is now in use.

How to do it

1. Record every device's name, model, location, IP, mask, gateway, VLAN, switch port and MAC address.
2. Label every device and cable with the same names used in the documents.
3. Write the port map for each switch and the VLAN table.
4. Record each controlled device's protocol, port or serial settings, and control-related device settings.
5. Record where credentials are stored, not the credentials themselves in open documents.
6. Record protocols and ports given to IT, and any changes they made.
7. Give copies to the client and keep one with the system files.

What goes wrong

Practice it

Answer before checking.

Glossary

What the gear actually looks like

Every device named in this book, in one place. Recognition is the whole point of Chapter 4 — use this page to attach a picture to each name before you meet it on a dock at six in the morning.

Audio

Dynamic microphone

Condenser microphone

Wireless handheld

Radio rack

Mixing console

Stage box / snake

Power amplifier

Main loudspeaker

Subwoofer

Stage monitor wedge

In-ear monitors

DI box

Video

Camera

Video switcher

Scaler / processor

Projector

LED wall panel

Confidence monitor

Lighting & control

Conventional fixture

Moving-head fixture

Lighting console

Dimmer

Show controller

Media server

Networking & infrastructure

Network switch

Patch bay

Equipment rack

Power distribution

Cable tester

A properly coiled cable

Connectors, close up

XLR

TRS / TS ¼-inch

SDI on BNC

HDMI

Cat5e / Cat6 (RJ45)

Fiber optic

DMX (5-pin XLR)

AC power — not signal