Last month, we began talking about the highest form of art when it comes to audiovisual systems: troubleshooting.

In that article, I began to make the point that the use of a logical troubleshooting methodology began in your head, rather than by swapping equipment or blind experimentation. I don’t think many people had an argument with that.

But in order to further the conversation, I decided to involve several experts in the field. One of the great things that 30 years in the business will give you is an excellent Rolodex (and yes, I know many of you are too young to understand what a Rolodex was, so rest assured that at this point I am talking about an electronic card file of email, web and SIP addresses).

So, method of addressing them aside, I gathered three highly experienced industry people to give me their comments on the art of troubleshooting. They are:

Scott Wills, CTS-D, CTS-I, Director of International Member Services, InfoComm International

Scott is the oldest card in that “Rolodex,” to the point where he actually once was listed on a paper card. He spent many years as a service and installation manager, and has since spent years organizing training and teaching for InfoComm, before his present role directing member services for the international portion of our trade association.  He’s one of the people I think of when I think of the art of troubleshooting.

Jim Smith, CTS, Partner Consulting Engineer, Polycom, Inc.

Many of you will recognize Jim’s name from your own Rolodex. He’s one of the people I have always gone to for insight into troubleshooting complex videoconferencing systems. I’ve taught alongside him for many years at InfoComm, and many of you will also recognize him as a regular panelist for both my columns and my podcasts.

Neil Willis, RCDD, CTS, President, Hypersign

Neil is the only one of the three who never had a paper card in my contacts file, but caught up fast. He’s the president of Hypersign, who formerly ran a large systems design and installation company. He’s one of those people where it only takes you 10 minutes talking to him to understand how deep his knowledge of this industry is.

So I think I gathered a good team for conference call about the art of troubleshooting,  and I began by asking them a number of questions:

First, I thought I would open a broad discussion by asking what the first requirement for accurate, effective troubleshooting would be. I got some great answers:

Scott Wills: “Well, I learned my troubleshooting skills  as a technician in the Navy. And I would say that the most fundamental thing about troubleshooting is that you must thoroughly know the system or piece of equipment that you are troubleshooting, and what its normal operation is. Absent that, you can’t have a benchmark for what you are trying to solve. For instance, in the Treasury Department they teach the people who detect forgeries by making them thoroughly familiar, first, with real currency. Then, when they see a forgery they know it. In the same way, if you are responsible for troubleshooting a boardroom system, you must first know its normal state of operation, and then you can recognize an anomaly.”

I then asked Neil Willis, who was driving at the time, to add to Scott’s thoughts.

Neil Willis: “I very much agree with Scott, as my troubleshooting skills were learned in the Air Force. We were taught to look at the output of any electronic system to see if it was normal. If it was not, we were taught to work backwards through the signal chain to locate the issue. With our industry and its systems becoming more logically complex every day, is necessary to have a thorough understanding of a given system and not just its components to troubleshoot it at all. If you don’t have an intimate knowledge of how the components are supposed to function together, you’re done. Years ago, we would look at the system physically, to determine if it was properly interconnected and if there were any termination errors. Today, many of those connections happen in logic, so beyond an understanding of the components we must have an understanding of the system and its programming and how these components have been taught to logically work together. So we have added a logical layer to the physical layer which you also must understand to effectively troubleshoot the system.”

At this point, I asked Jim Smith to jump in, with some understanding on a further issue that happens in system troubleshooting today,  namely that  systems now exist in disparate spaces, connected in the cloud.

Jim Smith: “From what I have seen, is now necessary to understand both ends of a system which is connected via network, in order to determine the intent of the programming and what correct results are. Simply understanding each gadget in the system as a separate unit is no longer enough, as they may have been program quite differently to interact in a specific way. In other words, understanding intent is as important as understanding the electronics. It is certainly possible for each item to function correctly and yet not to achieve its goal as a system which interacts with other systems. One of the traditional problems with AV troubleshooting is that traditionally the system stops at the wall jack. Today, with cloud-based and remote connections to other things, if you don’t know what’s on the other side of that wall jack you have no way to ascertain what the problem is.”

So, given our limitation for this month’s column, what do we draw from our comments so far?

My take is this: In the old days, I went to the field confident that I understood all of the components, and could figure out which one was not functioning correctly. Today, I need (before I go anywhere, or even log in remotely) to review the system as it was specified and installed, and have an understanding of the systems that interacts with before I can troubleshoot it correctly.

Next month, we will ask our panel (actually, I already have) to contribute some thoughts on how to properly prepare to troubleshoot complex or cloud-based systems.

Stay tuned.