AV Troubleshooting Methodology

Introduction

Every AV technician is eventually the person standing next to something that has stopped working, with other people looking at them. The presenter's microphone is dead. The LED wall shows a blue screen. The stream has pictures and no sound. The touch panel does nothing. Doors are in twelve minutes.

What separates the technicians who are asked back from the ones who are not is rarely knowledge of that particular piece of equipment. It is a method: staying calm, finding out exactly what is wrong, following the signal to where it stops, checking the obvious before the exotic, changing one thing at a time, getting the show back first and finding the real cause afterwards, and writing it down so it does not happen again. That method works on audio, video, lighting, networks, control, power and people, on equipment you have never seen before.

What this book covers

The troubleshooting mindset and a formal method; the thinking traps that catch experienced people; defining a fault precisely, with what changed, is-and-is-not analysis, reproduction and evidence; tracing a signal and choosing test points; checking the simple things and the usual faults in each discipline; isolating faults by half-splitting, substitution, bypassing and swapping, including intermittent and multiple faults; the test tools and using them safely; restoring a live show with workarounds, backups, time-boxing, escalation and communication; and confirming, finding the root cause, preventing a repeat, documenting and returning equipment.

It was measured against the troubleshooting methodology taught in technician certifications, formal problem analysis, IT incident and problem management, root cause analysis methods and AVIXA's troubleshooting and verification training, so that nothing a technician is taught elsewhere about finding and fixing faults is missing here.

What this book does not do

It does not teach component-level repair of equipment, and it does not authorise opening mains-powered equipment, electrical work or rigging to chase a fault. It teaches how to find the faulty part, the faulty setting or the faulty connection, and what to do next.

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 fault 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 fault notebook. For every fault you meet, write the symptom as you first heard it, the precise definition, what you checked, what it turned out to be, how long it took and what would have found it faster. Within a year you will have a library of patterns that no manual contains.

Write it by hand, and write it soon after the fault, while the details are fresh. Writing down how you found a fault is how the method becomes a habit.

Then use it twice. Read a few pages on the way to a job, and carry it on the job, because the fault in front of you has very probably happened before.

A note on the words

Troubleshooting borrows words from IT, engineering and the trade, and they overlap. Half-splitting is divide and conquer. Known-good substitution is swapping. An intermittent fault is a flaky one. A workaround is a patch or a bypass. Restoring service and fixing the problem are different things, and both are sometimes called fixing it. A return for repair is an RMA.

None of that is worth arguing about. What matters is saying precisely what is happening and what you have done, because a clear description of a fault is half of finding it.

A note on safety

Faults tempt people to take shortcuts — to open a device with its power on, to lift a mains earth to stop a hum, to climb to a truss to check a cable, to reset a breaker that keeps tripping. None of those is troubleshooting. Troubleshooting stays within your training, and when the path to a fault leads to mains power, rigging or work at height, it has reached somebody else's job.

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 been the person standing next to something that stopped working, and want a method instead of luck, start here.

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

What pairs with this

• Signal Flow & System Architecture — the chains this method follows

Where it leads

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

• AV Networking Intermediate — because more and more faults live on the network
• Commissioning & Quality Assurance — finding faults before the client does, as a discipline

Before You Begin

The Troubleshooting Mindset

Panic guesses; professionals reason. The right mindset is most of the skill.

Calm and systematic

When something fails on a show, the untrained reaction is to panic and start randomly changing things — unplugging cables, pushing buttons, swapping gear — hoping something works. This usually makes things worse, because you can no longer tell what fixed or broke what. The professional does the opposite: stays calm and works systematically, treating the fault as a logical problem with a findable cause. Calm is not just composure; it is what makes clear thinking possible, and clear thinking is what finds the fault.

The core belief of troubleshooting is that every fault has a specific, logical cause at a specific point — the signal stops somewhere, a setting is wrong, a part has failed. Nothing is random or magic. Holding that belief turns a frightening failure into a puzzle you can solve step by step. The method in this book is simply how you find that cause efficiently instead of by luck.

Define before you fix

The first step is always to define the problem precisely, because a vague problem cannot be solved efficiently. It's broken is useless; the left speaker has no sound while the right is fine is solvable. Pin down exactly what is and is not working, when it started, and what changed around that time. Often the precise definition points straight at the cause — knowing only the left side is dead immediately tells you to look at what is unique to the left signal path, not the parts shared by both.

What changed is a powerful question. Faults rarely appear from nothing; usually something was just plugged in, moved, switched, or adjusted. Identifying the recent change often locates the fault immediately. Defining the problem and asking what changed are quick steps that frequently solve the problem before any deeper work, and always make the deeper work faster.

A method, step by step

The troubleshooting methods taught in technician certifications, in IT and in engineering all follow the same sequence, and naming the steps makes them easier to follow when nerves are high.

First, identify the problem: gather information, ask what changed, and reproduce the fault if you can. Second, form a theory of probable cause, starting with the obvious. Third, test the theory: check, measure or substitute to confirm or eliminate it; if it is eliminated, form a new theory. Fourth, plan the fix, thinking about its effects on the rest of the system and the show. Fifth, carry out the fix, or escalate if it is beyond your authority or ability. Sixth, verify that the whole system works, not only that the symptom has gone, and take steps to stop it happening again. Seventh, document what happened, what you found and what you did.

In AV, the middle of that sequence is signal-flow thinking: tracing, half-splitting and substitution are how theories are tested. And on a live show, a step is added at the front: restore the show first, with a workaround or backup, and work through the method properly when there is time. The chapters of this book follow the same order.

Thinking traps

The faults experienced technicians take longest to find are usually lost in their own heads rather than in the equipment. A few traps catch everybody.

Anchoring is fixing on the first explanation that comes to mind — "it's the wireless again" — and interpreting everything afterwards to fit it.

Confirmation bias is looking only for evidence that supports your theory and not noticing evidence against it. The antidote is to ask what you would expect to see if your theory were wrong, and to check that.

Tunnel vision is staring so closely at one device that you miss the obvious elsewhere: the fader that is down, the mute group that is active, the laptop that is asleep.

Assuming it is still true is trusting something you checked earlier, or something somebody told you, without checking it again. "I tested that cable this morning" is not the same as "that cable works now".

And pressure makes all of them worse. The best defence is the method itself, spoken out loud: say what you know, what you think, and what test would prove it. A colleague listening will often spot the trap before you do.

The troubleshooting method

Thinking traps

• Anchoring — stuck on the first explanation.
• Confirmation bias — seeing only evidence that fits.
• Tunnel vision — missing the obvious nearby.
• Stale truth — trusting a check that is no longer current.

On the job

A corporate conference. The second presenter's handheld wireless microphone drops out every few seconds. The A2 has seen wireless dropouts all week in this hotel and says it is RF interference. He changes the frequency. It still drops out. He changes it again, then swaps the receiver antenna cables.

The A1 steps over and asks him to say out loud what he knows. The drops are only on this microphone; the other four wireless channels are perfect. They happen when the presenter moves her hand. The frequency has been changed twice with no effect.

If it were interference, other channels near that frequency would suffer, and a new frequency would help. Neither is true. The evidence points to the microphone itself. A fresh battery changes nothing; the known-good spare transmitter works perfectly. Inside the dropping transmitter, the battery contact is bent and loses connection when the case flexes.

The spare goes to the presenter, the faulty transmitter is tagged, and the A2 writes in his notebook: "Anchored on RF. Should have asked what else would be true."

How to do it

1. Say the symptom precisely.
2. Say what you know for certain, and how you know it.
3. Say your theory of the cause.
4. Say what you would expect to see if the theory were wrong, and check that.
5. Choose one test that would confirm or eliminate the theory.
6. Do the test, and say the result.
7. Repeat with a new theory if needed.

What goes wrong

Practice it

Answer before checking.

Defining the Problem

Most of the work of troubleshooting happens before anybody touches a cable. The difference between "the sound's not working" and "the lectern microphone is silent in the room loudspeakers and working on the stream, since the break" is the difference between an hour and two minutes, because the precise definition has already located the fault.

This chapter is how to get to a precise definition: asking the right questions, comparing where the fault is with where it could be and is not, reproducing it, and gathering the evidence that already exists in logs, indicators and people's memories.

Is and is not

A powerful way to define a fault, from formal problem analysis, is to describe it twice: what it is, and what it could be but is not.

What is affected, and what similar thing is not? The left loudspeaker, not the right. Where is it seen, and where could it be seen but is not? On the LED wall, not on the confidence monitor fed from the same switcher. When did it start, and when did it not happen? Since the break, not during the morning session. How much or how often, and how much could it be but is not? Every few seconds, not constantly.

Each pair points at a difference, and the cause lives in the difference. If the left loudspeaker is dead and the right is fine, the cause is in something that is different about the left path — its amplifier channel, its cable, its output — not in anything shared, such as the console's main mix. If the problem started at the break and not before, something changed at the break.

Then test every possible cause against both columns. A cause must explain everything in the "is" column and not contradict anything in the "is not" column. A theory that the console has failed does not explain why the right loudspeaker still works, so it is eliminated before anybody touches the console.

What changed, when did it last work

Systems that were working do not usually stop working on their own. Something changed: a cable was unplugged and replugged, a laptop was swapped, a preset was recalled, a device was restarted, firmware updated overnight, a department moved something in the break, the room filled with people and phones.

Two questions find that change quickly. When did it last work? And what has changed since then? Ask everybody who might know, including other departments and the client — the presenter who "just plugged in to charge", the caterer who moved a table onto a cable, the lighting programmer who reloaded the show file.

Be specific about time. "It worked at sound check" and "it worked five minutes ago" narrow the search very differently. Some systems keep logs that show exactly when a device dropped off the network or a setting changed, which answers the question with a timestamp.

Reproducing the fault

A fault you can make happen on demand is a fault you can find, because every test gives a clear answer. So, where it is safe and the show allows, try to reproduce it: have the presenter repeat the movement, play the same video file, press the same button, recall the same preset.

If it reproduces reliably, the rest of the method works quickly. If it does not, note carefully the conditions when it did happen — time, which source was on, what was moving, how hot the room was — because an intermittent fault needs a different approach, covered in the isolation chapter.

Reproduction also confirms the definition. A fault the client describes as "the screen goes black" might turn out, when reproduced, to be "the screen goes black only when the laptop's lid is closed", which is a completely different fault.

Gathering the evidence that already exists

Before testing anything, look at what the system is already telling you.

Indicators: link lights on network ports, signal and clip lights on audio equipment, input status on switchers and processors, a hoist controller's phase light, a GFCI's trip indicator, the colour of a wireless receiver's RF and audio meters.

Screens and menus: an error message on a display — "no signal", "HDCP error", "unsupported format" — is a precise clue. A console's input meter, a processor's status page, a routing matrix's current routes and a networked audio controller's device list each show the state of part of the system.

Logs: many control processors, network switches, streaming encoders and media servers keep logs with timestamps.

People: the operator who was in the chair, the presenter, the stage manager who called the cue. Ask what they saw and did, precisely, and listen without accepting their theory of the cause as a fact.

Write the evidence down as you gather it. A few lines in a notebook — symptom, is and is not, last worked, what changed, indicators — is the definition.

The is and is-not worksheet

Describe the fault twice. The cause lives in the differences.

Questions for a definition

• What exactly is wrong, and where?
• What similar thing is not affected?
• When did it last work, and what changed since?
• Can it be reproduced?
• What do the indicators, screens and logs show?
• Who saw it happen, and what did they see and do?

On the job

A product launch. Fifteen minutes before doors, the producer tells the video engineer the stream "has no sound".

The video engineer does not start swapping cables. She asks three questions and looks at two screens. Is there sound in the room? Yes. Is there sound on the record feed? Yes. On the stream platform's preview? No. When did it last work? The stream test at 5 p.m. was fine. What changed? The graphics operator replaced a laptop at 5:30 because the first one was slow.

Is and is not: the audio exists in the room and on the record feed, not on the stream; it worked at 5, not since 5:30. The stream's audio comes embedded in the program video from the switcher, and the new graphics laptop is on a switcher input.

The switcher's audio settings show that input 4, where the new laptop is, is set to follow video with embedded audio — and the program output's audio is set to follow the program source. When the graphics laptop is keyed over the program, the switcher takes the laptop's silent embedded audio. On the old laptop the setting had been changed to take the console's audio instead. She sets the program audio back to the console input, the stream has sound, and it is still twelve minutes before doors.

How to do it

1. Write the symptom as reported.
2. Ask what exactly is wrong, and what similar thing is not affected.
3. Ask where, when, and how much — and the "is not" for each.
4. Ask when it last worked and what changed since, from everybody involved.
5. Look at indicators, error messages, status screens and logs.
6. Try to reproduce it, if safe and the show allows.
7. Rewrite the symptom as a precise definition before testing anything.

What goes wrong

Practice it

Answer before checking.

Trace the Signal

The single most powerful technique: follow the signal until it stops.

Following the chain

Troubleshooting is, above all, signal-flow tracing — the skill from AV Fundamentals applied to finding faults. A fault is the point where the signal stops travelling from source to destination, so you find it by walking the chain and checking whether the signal is present at each stage. Start where you know the signal is good and move towards where it is missing (or vice versa) until you find the exact stage where it disappears. The fault lies between the last point with signal and the first point without.

This works on any system because every system is a chain: audio (mic to speaker), video (camera to display), lighting (console to fixture over DMX), data (device to device). Knowing the chain for the system in front of you — which is why discipline knowledge helps — lets you trace it confidently. The tools you use to check for signal at each stage (meters, monitors, indicator lights, test gear) vary, but the logic is identical: where does the signal stop?

Both ends and the middle

You can trace from the source forward or from the destination backward — both are valid, and the best choice depends on where it is easiest to start checking. Often the fastest approach is to check the middle first: if the signal is present halfway along, the fault is in the second half; if not, it is in the first half. This idea — testing a point to eliminate half the chain at once — is so useful it gets its own treatment in "Isolate the Fault".

Tracing also tells you what to ignore. If sound reaches the console but not the speaker, the microphone and its cable are fine — no need to touch them. Each test either contains the fault to a smaller part of the chain or clears a part entirely. This is why tracing is so much faster than random swapping: every step shrinks the search instead of just trying things.

Choosing test points

A trace is only as fast as its test points: the places in the chain where you can find out whether the signal is present and correct. Good test points are easy to reach, need no disconnection, prove a lot of the chain at once, and give an unambiguous answer.

In audio, the console's input meter proves everything from the microphone to the preamp; an aux or solo in headphones proves the channel; the output meters prove the mix; a processor's input and output meters and an amplifier's signal lights prove the rest. In video, a switcher's multiview proves each input arrives; a monitor on a spare output or a distribution amplifier proves a path; a processor's input status proves the format arrived. In lighting, a console's output view proves the data leaves the desk; a DMX tester or a node's status shows it arriving. On networks, a switch's port lights and management page and the networked audio or video controller's device list are test points. In control, the processor's log is the test point that shows whether a command left.

Where there is no convenient test point, you make one: a known-good monitor plugged in at a distribution point, headphones on a spare output, a laptop on a switch port.

The rule for choosing is the same as half-splitting: pick the point that removes the most possibilities for the least effort.

Test points by discipline

On the job

A theatre show's projection goes to "no signal" during the interval. The projection chain runs from a media server backstage, through a fiber transmitter and receiver, to a scaler and then the projector in the booth, forty metres away.

Instead of walking to the booth, the video technician uses test points. The media server's output preview shows the content: the source is good. The fiber transmitter's input light is on. At the booth end, the receiver's output light is on too. A monitor plugged into the receiver's spare output shows the picture. So everything up to the receiver is proven, from one trip and one plug.

The scaler's input status says "no signal". The HDMI cable between receiver and scaler has been pulled half out by someone moving a chair in the booth. It is reseated, and the scaler locks.

Four test points, one walk, and nothing was unplugged that did not need to be.

How to do it

1. Write the chain from source to destination.
2. Mark every place you can see or hear the signal without disconnecting anything.
3. Choose the test point that proves the most of the chain for the least effort.
4. Check it, and mark the chain good or bad up to that point.
5. Move to the next test point between the last good and first bad.
6. Where there is no test point, make one with a known-good monitor, headphones or laptop.

What goes wrong

Practice it

Answer before checking.

Check the Simple Things First

Most faults are embarrassingly simple. Checking the obvious first saves hours.

The common causes

Before suspecting a failed amplifier or a broken console, check the simple things, because the large majority of faults are simple: something not powered on or plugged in, a cable not fully seated or in the wrong port, a wrong input selected, a muted channel, a fader down, a setting changed. These cost seconds to check and are the cause far more often than a dead piece of gear. The experienced troubleshooter checks the obvious first precisely because it is so often the answer.

There is a discipline here against jumping to complex conclusions. The instinct under pressure is to assume the worst (the expensive box has died) and start replacing major gear, when the real cause is a muted channel or an unplugged cable. Checking power, connections, and settings first — the cheap, fast, common causes — resolves most faults in moments and stops you from chasing expensive ghosts.

Is it just this, or everything?

A fast diagnostic question is how widespread the fault is. Is one channel dead or all of them? One screen or every screen? If only one of many similar things is affected, the fault is in what is unique to that one (its cable, its channel, its source). If everything is affected, the fault is in something shared by all of them (common power, a master setting, a shared device upstream). This single question often halves the problem instantly by pointing you at either the individual path or the common element.

This is the same logic as tracing and half-splitting: use what you can observe to eliminate large areas quickly. Combined with checking the simple things, asking is it one or all turns most everyday faults into quick fixes. Only when the simple and common causes are ruled out do you move to deeper investigation — and by then you have already narrowed where to look.

Question the obvious

Technician certifications put the same advice into their troubleshooting methods in three words: question the obvious. It means not assuming that the simple things are fine because they should be.

Is it actually switched on, or does the light only mean standby? Is it plugged into the socket the drawing says, or the one next to it? Is the cable fully seated and latched, or just resting in the connector? Is the mute on, the fader down, the input selected, the laptop asleep, the display on the right input, the camera's lens cap off, the volume on the device itself up?

Question the obvious out loud, and check it with your hands and eyes rather than your memory. The fault that takes an hour to find is often the one somebody said was "definitely fine" in the first minute.

The usual suspects, by discipline

Every discipline has its own list of faults that happen again and again. Knowing them means checking them early.

Audio: mutes, mute groups and DCAs; faders and input gain; phantom power off for a condenser microphone, or on for a device that dislikes it; the wrong input or patch; a microphone switched off; flat batteries in wireless packs; the wrong wireless frequency or channel; a polarity or pad switch pressed; a ground loop hum from mixed power; a recalled scene that changed routing.

Video: the display on the wrong input; the wrong resolution or frame rate for the chain; EDID giving a source the wrong format; HDCP blocking protected content; audio not embedded; a laptop's display set to mirror instead of extend, or asleep; an extender with no power at one end; a loose HDMI connector with no lock.

Lighting: a fixture on the wrong DMX address or mode; a terminator missing; a DMX cable daisy chain broken by an unpowered fixture; a node on the wrong universe; the console in blind mode or with a grandmaster down; a park or highlight left on.

Networks and control: the wrong IP address or subnet; a duplicate IP address; a cable in the wrong switch port or VLAN; a device renamed so subscriptions broke; a projector in network standby; a missing delimiter on a control command.

Power: a tripped breaker or GFCI; a power strip switched off; a device on a sequencer outlet that has not come on yet.

None of these needs deep knowledge to check, and together they account for a very large share of show faults.

The usual suspects

On the job

A conference general session. The presenter's slides appear on the confidence monitor and not on the main LED wall, a minute before she walks on.

The video engineer starts to open the LED processor's settings. The show caller, who has watched a lot of shows, asks on headset: "Is the wall on the right input?"

It is not. The LED processor has two inputs, main and backup, and during the break someone testing the backup path had switched the processor to its backup input, which is fed from a laptop that has gone to sleep. One button returns the processor to its main input, and the slides are on the wall as the presenter reaches the lectern.

Afterwards, the engineer adds "processor input selection" to his pre-session check, and writes in his notebook that he went straight past the most obvious check in the chain.

How to do it

1. Check power — actually on, not standby.
2. Check each connection by hand — seated, latched, the right port.
3. Check mutes, faders, gain, input selection and scene recalls.
4. Check the device's own controls — volume, input, sleep.
5. Check the usual suspects for the discipline.
6. Only then go deeper.

What goes wrong

Practice it

Answer before checking.

Isolate the Fault

When the simple checks don't solve it, isolation narrows the cause to a single point.

Half-splitting

Half-splitting (or divide and conquer) is the most efficient way to isolate a fault in a chain. Instead of checking every stage in order, you test a point in the middle: that one test tells you which half contains the fault, eliminating the other half entirely. Then you test the middle of the remaining half, and so on, halving the search each time. A long chain that would take many sequential checks is narrowed to the faulty point in just a few tests. This is why understanding the signal chain pays off so directly.

Half-splitting works on any chain — a long cable run, a complex signal path, a series of devices. The art is choosing test points where it is easy to check for signal and that meaningfully divide the chain. Each test should roughly halve what is left. This disciplined narrowing is dramatically faster than checking everything in sequence and is the core technique of efficient troubleshooting.

Known-good substitution and one change at a time

Substitution isolates a fault by swapping a suspect part for one you know works (a known-good cable, mic, or device). If swapping the cable fixes it, the cable was bad; if not, the cable is cleared and you look elsewhere. Substitution is powerful because it definitively tests one component, but it must be done deliberately — swap a known-good part for one suspect part, observe the result, and you have a real answer. Random swapping of multiple things at once tells you nothing.

This is the cardinal rule of isolation: change only one thing at a time, and observe the effect before changing anything else. If you change three things and the fault clears, you do not know which one fixed it — and you may have introduced a new problem. Disciplined one-change-at-a-time testing, combined with tracing and half-splitting, lets you isolate any fault to its exact cause with certainty rather than guesswork.

Bypassing, and swapping sides

Two more isolation techniques are fast and very widely used.

Bypassing removes a stage from the chain to see whether the fault goes with it. Plug the laptop straight into the display, skipping the extender and switcher. Take the external processor out of the insert. Run the audio from the console directly to the amplifier, past the loudspeaker processor. If the fault disappears, it was in what you bypassed; if not, that part is cleared.

Swapping sides moves a suspect part to a working path and sees whether the fault follows it. If the left loudspeaker is silent, swap the left and right cables at the amplifier. If the silence moves to the right loudspeaker, the fault is upstream of the swap point — the console output or the left cable run — because the left signal is still silent on its new path. If the silence stays on the left, the fault is downstream: the left amplifier channel, the left loudspeaker cable or the loudspeaker. The same trick works with microphone channels, camera inputs, DMX lines and network ports.

Both techniques follow the one-change rule: swap or bypass one thing, observe, and put it back or decide before the next change. And both assume you have a working path to compare with, which is often the case in AV, where systems are full of identical left and right, main and backup, channel one and channel two.

Intermittent faults

An intermittent fault comes and goes, which makes it the hardest kind to find: it may be working perfectly while you test it.

Stop waiting for it to happen and look for its pattern. Log every occurrence: the time, what was happening, what the operator was doing, the temperature, what was moving. Patterns appear quickly — every time the presenter walks to the left, every time the lighting changes to a particular look, every twenty minutes when the air conditioning starts, every time a particular source is selected.

Then try to provoke it. Gently flex cables and connectors while watching or listening, which finds intermittent connections — often called a wiggle test. Move the microphone or transmitter to where the pattern suggests. Recreate the conditions: the lighting look, the heat, the network load, the radio traffic.

Common causes of intermittent faults in AV are worn or loose connectors and cables, overheating equipment that fails when hot and recovers when cool, wireless interference and range, marginal cable lengths and signal formats, clock problems on digital audio, network congestion or loops, power supplies near their limit, and power saving modes switching devices off.

And where you cannot find it in time, substitute the whole suspect path with known-good parts and take the suspect parts away to test at leisure.

More than one fault

Occasionally a system has two faults at once, and it can defeat the method in a particular way: you fix the first fault, nothing changes because the second is still there, and you conclude, wrongly, that the first thing was not the fault and put it back.

Watch for it when a substitution that should have fixed the problem makes a small difference, or changes the symptom without curing it; when a trace shows the signal stopping in two places; or when a system has just been moved, rebuilt or repaired, which creates several changes at once.

The protection is discipline about what each test proved. If a known-good cable replaced a suspect one and the symptom changed, the old cable goes aside and is tested separately, not back into the system. Keep a written list of what has been found and fixed, and keep working the method until the whole definition is resolved.

Swapping sides

Common causes of intermittent faults

• Worn or loose connectors and cables.
• Equipment overheating.
• Wireless interference and range.
• Marginal cable lengths and formats.
• Clock problems on digital audio.
• Network congestion or loops.
• Power supplies near their limit, and power-saving modes.

On the job

A wedding band's bass guitar drops out for a second or two, several times a set. It never happens during sound check.

The A1 logs each dropout with the time and what the bassist was doing. By the third, a pattern: every dropout happens when the bassist moves to the left side of the stage to sing backing vocals.

The bass is on a wireless instrument system. The dropouts line up with moments when the bassist's body is between the pack on his belt and the receiver antennas at the stage right side, near a steel pillar. It is range and body shielding, not the bass or the cable.

At the set break, the A2 moves the receiver's antennas to a higher position with a clear line to the whole stage, and gives the bassist a spare pack clipped on the other hip. The dropouts do not return. The log goes into the A1's notebook with a drawing of the stage, the pillar and the antenna position.

How to do it

1. Log each occurrence — time, activity, source, location, temperature.
2. Look for the pattern in the log.
3. Try to provoke it — wiggle connections, move, recreate conditions.
4. Test the likely causes for that pattern.
5. If it cannot be found in time, replace the whole suspect path with known-good parts.
6. Test the removed parts later, and label them until cleared.

What goes wrong

Practice it

Answer before checking.

Test Tools

A technician's senses are the first test tools, and they are unreliable under pressure: a quiet signal sounds like no signal, a slightly wrong format looks like a dead cable. Test tools give answers that do not depend on how tired you are or what you expect to find.

This chapter covers the everyday test tools of AV — meters, cable testers, signal and pattern generators, known-good sources and devices, network tools and the tools built into equipment — what each proves, and how to use them within your training.

Signal sources you trust

The most useful test tool is a signal you know is good. Testing a path with an unknown source — a presenter's laptop with mystery settings, a microphone that may be faulty — gives an answer you cannot trust.

For audio: a tone generator producing a steady sine wave at a known level is ideal for checking continuity and level through each stage. Pink noise exercises the whole frequency range and is used to check loudspeakers and polarity. A known-good microphone and cable, and a phone or player with a familiar music track, are everyday references. Most consoles and processors can generate tone and pink noise internally.

For video: a test pattern generator produces colour bars, grids and resolution charts in a set format, and shows immediately whether the right format arrives, whether the picture is cropped or scaled, and whether colours and levels are right. Many switchers, processors and LED controllers generate patterns internally. A known-good laptop set to a standard resolution is the everyday reference.

For lighting: a DMX tester can both send DMX to a fixture and read DMX from a line, proving the console, the cable and the fixture separately.

Keep known-good test sources labelled and reserved for testing, so they stay known-good.

Cable testers and meters

Cable testers check that every conductor in a cable is connected, to the right pin, and not shorted. Audio cable testers handle XLR, jack and multicore; network cable testers check the eight wires of an Ethernet cable and their pairing, and more capable ones check length and whether a cable meets its category. Coaxial and fiber have their own testers; fiber testers measure light loss, and a fiber inspection scope shows a dirty or damaged connector end.

A multimeter measures voltage, resistance and continuity. A technician uses it to check continuity and resistance on an unplugged cable, the voltage of a battery, or low-voltage DC on a power supply output. Measuring mains voltage, or anything inside mains-powered equipment, is for trained and qualified people using meters rated for it.

A sound level meter measures acoustic level; a phantom power tester confirms 48 volts on a microphone line; a wireless scanner or spectrum analyser shows radio frequency activity; a light meter measures illuminance for cameras; a waveform monitor and vectorscope show video levels and colour.

Network tools and built-in diagnostics

Networked systems come with diagnostic tools built in, and they are often the fastest test tools of all.

On a laptop: ping, to check whether an address answers; ipconfig or the network settings, to check your own address; arp, to see which hardware answered for which address; and a terminal program, to send a control command straight to a device.

On network switches: the management page shows each port's link, speed, errors and which devices are connected, and which VLAN each port is on.

In AV software: networked audio controllers list every device, its clock status, its subscriptions and its errors. Streaming encoders show bit rate, dropped frames and connection status. Media servers, LED processors and switchers show input status and formats. Control processors keep logs of commands sent and replies received.

Use them before touching hardware. A device list that shows one device with a clock error, or a switch port with a climbing error count, locates a fault in seconds.

Using test tools safely

Test tools create their own hazards if used carelessly.

A tone or pink noise sent into a live system at the wrong level can damage loudspeakers and hearing, and during a show it can end up in the room. Start low, know which outputs are live, and warn everybody before sending test signals.

A test pattern or a DMX tester sent into a live system changes what the audience sees, and can move moving lights, effects and automation. Never send test signals into anything connected to effects, motors or a live show without the operator's agreement.

A multimeter is used only within its rating and the user's training. Mains measurements, and anything inside equipment with its covers off, belong to qualified people.

And a network tool used on a client's network can trigger security alarms. Ask before scanning or connecting to networks you do not control.

Test tools and what they prove

On the job

A touring show's second night. During the load-in, the monitor engineer reports that the in-ear mix for the drummer has a crackle on the left side only. The in-ear transmitter, the pack and the earphones were fine last night.

The A2 does not start swapping the drummer's gear. He sends a quiet sine tone from the monitor console into the drummer's mix. On headphones at the console's output, the tone is clean. On headphones plugged into the transmitter's input loop-through, the tone crackles on the left. So the fault is between the console output and the transmitter input: a single cable.

He tests it with the audio cable tester: pin 3 on the left leg is intermittent when the connector is flexed. The cable goes aside with a tag, a spare goes in, and the tone is clean at the transmitter and in the pack.

A tone and a cable tester found in four minutes what could have taken half an hour of swapping earphones, packs and transmitters.

How to do it

1. Agree with the operator which outputs are safe to test, and warn everybody.
2. Choose a known-good test source — tone, pink noise, test pattern or DMX tester.
3. Start at a low level or on a monitor output.
4. Check the signal at the first test point, then move along the chain.
5. Where the signal changes or disappears, test the connection or device there.
6. Test suspect cables with a cable tester.
7. Turn test signals off and return all settings when finished.

What goes wrong

Practice it

Answer before checking.

When the Show Is Live

Everything in this book so far assumes you have time. During a live show you do not. The audience is waiting, the client is watching, and the question is not "what is the cause?" but "how do we get the show back?" The cause can wait for the interval, the end of the night or tomorrow.

This chapter is troubleshooting under that pressure: restoring the show first with workarounds and backups, deciding how long to look before switching, escalating, communicating calmly and clearly, and learning from it afterwards.

Restore first, repair later

IT service management draws a clear line between two jobs that AV often blurs. Restoring service means getting the user working again as fast as possible, by any safe means. Solving the problem means finding and removing the underlying cause. During a show, restoring service comes first, every time.

Restoring usually means a workaround or a backup. A dead lectern microphone is replaced with the spare handheld. A failed playback machine is switched to its backup. A laptop with a display problem is replaced with the show's spare. A stream with no audio has the console's mix patched straight into the encoder's analogue input. A fixture that has stopped responding is left parked while the rest of the cue runs. The show continues with a slightly different system, and the audience notices nothing or very little.

This only works if backups exist and have been tested, which is why professional shows build redundancy and practise changeovers, and why a technician should know the backup for every critical element before the show starts.

Once the show is restored, the faulty part is set aside, labelled and left alone until there is time to troubleshoot it properly. Trying to repair the original during the show, and breaking the workaround in the process, is a common way to have two faults instead of one.

Time-boxing and escalating

Under pressure it is easy to keep looking for a fault long after switching to a workaround would have been faster. Time-boxing prevents it: decide in advance how long you will look before you switch.

For something the audience is waiting for, that may be seconds: the presenter is at the lectern and the microphone is dead, so the spare goes in immediately. For something that will be needed in ten minutes, it may be two or three minutes of method before switching to the backup. Say the time box out loud to your lead: "Give me two minutes on the playback machine, then we switch to backup."

Escalate when the fault is beyond your knowledge, your authority or your time box: to your lead, the department head, the manufacturer's support line, or the person who designed or programmed the system. Escalating is not failing. A technician who escalates at minute three with a clear description is far more valuable than one who struggles alone until minute twenty.

And escalate immediately, without troubleshooting at all, for anything involving safety: a burning smell, a tripped main breaker, a rigging concern, anything electrical beyond plugging in.

Communicating during a fault

How a fault is communicated decides whether the people around it stay calm or panic, and whether the right decisions get made.

Tell the right person first: your lead or the show caller, on the right channel, briefly. Say what is wrong, what it affects, and what you are doing: "Video, caller — LED wall input lost, confidence monitors fine, switching to backup processor input now, thirty seconds."

Give updates at the times you promised, even if the update is "still working on it, backup ready if needed". Silence during a fault makes everyone assume the worst.

Keep panic off the channel and out of your body language. The client and the audience read the crew. A calm technician walking briskly with a spare microphone is reassuring; a technician running and shouting is not.

Let the show caller or the lead decide on show changes — holding a cue, moving a segment, making an announcement. Your job is to give them clear information to decide with.

After the show — the review

When a fault happened during a show, it is worth ten minutes afterwards, while memories are fresh, to go through it with the people involved: what happened, how it was noticed, what was done, how long each step took, what worked, and what would have made it faster or prevented it.

Many productions call this an after-action review or a debrief. It is not a hunt for blame. The questions are about the system and the process: was there a backup, was it tested, did the right people know, was the fault visible early, did the checklist cover it.

The output is a short list of changes — a check added to the pre-show routine, a spare moved closer, a setting documented, a cable replaced across the whole inventory — and a note in the fault log.

Restore, then repair

A fault call

• Who you are calling, and who you are.
• What is wrong.
• What it affects, and what is fine.
• What you are doing, and how long it will take.
• When you will update.

On the job

The final evening of a three-day conference, during the awards. Five minutes into the ceremony, the main playback machine freezes on the winner's video.

The playback operator does not start rebooting the main machine. The show caller hears "Playback, caller — main machine frozen on award three video, switching to backup, ten seconds." The backup machine, running in sync all night, is cut to the switcher, and the video continues from the right point. The audience sees a one-second freeze.

The main machine stays frozen and untouched until the break. At the break, the operator notes the time, the file and what was on screen, restarts it, and finds a system notification from an operating system update that had popped up over the playback software, which the playback software had not handled. Updates are disabled on both machines for the rest of the event.

At the debrief, the production manager adds "disable operating system updates and notifications on show machines" to the company's playback setup checklist. The change is in place for every show the next week.

How to do it

1. Tell the show caller or your lead briefly — what, what it affects, what you are doing.
2. Restore the show with the workaround or backup you planned.
3. If there is no backup, time-box a quick trace, and say the time box out loud.
4. Escalate at the end of the time box, or immediately for anything safety-related.
5. Leave the failed part alone and labelled until there is time.
6. Update at the times you promised.
7. Troubleshoot the original properly afterwards, then hold a short review.

What goes wrong

Practice it

Answer before checking.

Confirm, Document & Stay Calm

Finding the fault isn't the end — confirm the fix, learn from it, and keep your head under pressure.

Confirm and document

Once you believe you have found and fixed the fault, confirm it — verify the system actually works fully, not just that the symptom went away, and make sure you have not introduced a new problem. A fix that is not confirmed can fail again at the worst moment. Then, where it matters, document it: note what the fault was and how it was fixed. On a complex system or a recurring issue, this record saves the next person (often you) from solving the same puzzle twice and reveals patterns.

Pattern recognition is how troubleshooters get faster over time. The more faults you solve and remember, the more often a new symptom matches one you have seen, letting you jump closer to the cause. Experienced techs seem to fix things instantly not because they skip the method but because they have internalised so many patterns that the method runs in seconds. Documenting and reflecting on faults accelerates building that library.

Troubleshooting under pressure

Real AV faults often happen live, with an audience waiting and a client watching, which adds pressure to an already tricky task. The method is your anchor here: when everything in you wants to panic and start yanking cables, falling back on define, trace, check the simple things, isolate, one change at a time keeps you effective when instinct would make you worse. Calm, methodical troubleshooting under pressure is one of the most respected skills in the industry precisely because it is hard.

Communication is part of it. Keeping calm visibly, telling the right people what is happening (working on it, I've isolated it to the video path), and not broadcasting panic keeps the whole situation manageable. And knowing when to escalate or switch to a backup, rather than chasing a fault forever while the show waits, is mature judgement. Master the method, stay calm, communicate, and you become the person a crew is endlessly grateful to have when things go wrong.

Practical sign-off

Troubleshooting is learned by solving faults. The learner defines a problem precisely, traces a signal to where it stops, checks simple causes, isolates a fault by half-splitting and substitution changing one thing at a time, and confirms the fix. A mentor signs off when the learner troubleshoots methodically and calmly.

• Defined a fault precisely and asked what changed
• Traced a signal to the stage where it stopped
• Isolated a fault using half-splitting and known-good substitution
• Confirmed the fix and stayed calm under pressure

Finding the root cause

Fixing a symptom and fixing a cause are different. A cable reseated fixes the symptom; asking why it came loose may find a cable with a broken latch, a cable run under tension, or a rack with no strain relief. If only the symptom is fixed, the fault comes back.

The simplest root cause method is to ask why, repeatedly, usually about five times. The stream had no audio. Why? The switcher sent silent embedded audio. Why? The program audio followed the graphics laptop. Why? The replacement laptop was on an input with default settings. Why? The switcher's audio setup was not documented, so the change made for the old laptop was not repeated. Why? There is no written switcher configuration for this show. The root cause is the missing documentation, and the fix that stops it happening again is to write it.

Larger problems often have several contributing causes, and a cause-and-effect diagram, sometimes called a fishbone or Ishikawa diagram, groups them under headings such as equipment, people, methods, environment and materials. It is overkill for a loose cable and very useful for a fault that has now stopped three shows.

Root cause analysis looks at processes and systems, not at who to blame. A person who made a mistake usually did so because the process made the mistake easy.

Preventing a repeat

The last step of a good fix, in every formal method, is to stop the fault happening again. Once the root cause is known, ask what change would prevent it, and make it or recommend it.

Prevention in AV usually looks like one of a few things. A check added to a pre-show or pre-session checklist. A setting documented, or saved in a preset, so it survives a device change. A spare, a backup path or a redundant connection added. Equipment repaired, replaced or retired across the whole inventory, not just the one unit. A label, a lock, a cable tie or strain relief that makes the mistake physically harder. And training, when the fault came from not knowing something.

Small preventive changes compound. A company that adds one check after every fault has, a year later, a pre-show routine that catches most faults before the audience arrives.

The fault log

A fault log is a written record of faults: on a show, for a venue, for a set of equipment. It is how patterns are found, how recurring problems are recognised, and how the next technician avoids solving the same puzzle again.

Each entry is short: the date and time, the system and location, the precise definition of the fault, what was done to restore service, the cause that was found, the fix and the preventive action, who dealt with it, and how long it took. Equipment faults include the serial number of the unit.

IT service management calls a fault whose cause is known, but not yet fixed, a known error, and records its workaround so that anybody meeting it can restore service quickly. AV companies and venues benefit from exactly the same thing: a list of the known quirks of their systems and what to do about each.

Manufacturer support, repairs and returns

Some faults end with the equipment going back for repair. The report that goes with it decides how fast it is fixed and whether it is fixed at all.

Before contacting support, gather the model, serial number, firmware version, a precise description of the fault and how to reproduce it, what you have already tested, and any error messages or logs. Many problems are solved on the phone with that information: a known firmware issue, a setting, a replacement part.

If the unit must be returned, the manufacturer or the rental company usually issues a return authorisation number. Label the unit clearly as faulty with the fault description attached, so that it is not accidentally put back into stock, and note in the fault log where it went and when.

A unit sent back with "doesn't work" on a piece of tape often comes back unchanged, labelled "no fault found". A unit sent back with "right channel output distorts above +10 dBu after 20 minutes of operation; reproduced three times with tone" gets fixed.

A fault log entry

Before calling manufacturer support

• Model, serial number and firmware version.
• Precise fault definition and how to reproduce it.
• What has already been tested.
• Error messages and logs.

On the job

A rental company notices that three shows in a month have had a wireless microphone receiver drop out mid-event, each time on a different receiver of the same model.

The warehouse manager holds a root cause review with the technicians involved. Why did the receivers drop out? Each lost power briefly. Why? Each was on a power strip at the back of a rack. Why did they lose power? The receivers' external power supplies have plugs that sit loosely in that model of power strip, and vibration in the truck or a knock during the show partly unseats them. Why was it not caught? The pre-show check confirms receivers are on, not that their plugs are secure. Why? Nobody knew the combination was a problem.

The fix is not three repairs. The company replaces the power strips in those racks with locking outlets, adds "power supplies seated and secured" to the rack check, records the combination as a known error in its fault log with the workaround — tape or retain the plug — and briefs every technician.

No receiver drops out for the rest of the season.

How to do it

1. Verify full function of the whole system, not only the symptom.
2. Ask why at least five times to find the root cause.
3. Decide the preventive change and make it or recommend it.
4. Write the fault log entry.
5. Tag and report faulty equipment with a precise fault description.
6. Contact manufacturer support with model, serial, firmware and evidence where needed.
7. Share anything others need to know, such as a known error and its workaround.

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