True story. My wife teaches spin classes at a local gym, and the other day I went to her class. Before class she was struggling with the computer that runs the audio and scheduling in the room. She couldn’t get it to work, so I thought I would help. The computer is a NUC-type, about six inches long by about four inches wide and inch deep, and it was mounted to the back of the equipment rack. All of the cables, both power and data, were routed through the locked rack, concealing their path. The monitor had an error message saying that it was not receiving a video signal. So I disconnected and reconnected the video cable at the monitor and at the computer, but the same error message appeared. Then I disconnected reconnected the power cable at the computer, thinking that resetting it might help. Again, the same error message appeared on the monitor. It must be a bad video cable, I thought. It was frustrating not being able to get into the rack to get a better look, and I was at a loss about what else I could do. I almost gave up. About that time, the manager of the gym came along and pushed a button on the computer and it came to life. It turned out that the On/Off switch was in the Off position.
The first rule of troubleshooting is to check the obvious things first. Bill Byrd used to be a technician at High End Systems. He started there shortly after serving as a tech in the Air Force. That’s where, he said, he picked up the first rule of troubleshooting. “Is the O-N/O-F-F switch in the O-N position?” That was his favorite line.
Another good practice while troubleshooting is to take pictures as you go so that you can reference them when it’s time to put things back together. We used to have to write everything down but now with smart phone cameras, it’s much quicker and easier to take pictures.
One last tip is to write down your steps as you go so that you never have to repeat your work. Last month I was troubleshooting a complicated lighting network at a major television studio. (Look for the article about it in the Winter 2018 issue of Protocol magazine.) We had run a temporary Ethernet cable to a network switch in a computer closet, so we had two cables – the main and the temporary. The system worked fine on the temporary cable but there were problems with the main cable. I wanted to rule out the cable itself, so we tested the system in four different conditions; one with the main cable connected to the main port in the switch, one with the temporary cable connected to another port in the same switch, one with the main cable connected to a different port in the switch, and the last with the temporary cable connected to the main port in the switch. So I quickly drew a table with four rows and labeled them 1 through 4. As we conducted the test, I would write down the results.
I’ve learned over the years that even a simple test like this can be interrupted or you can lose track of which combinations have already been tried. So writing it down saves time and effort. This is a technique that I learned from reading about Leonardo da Vinci, who was said to document everything his did in excruciating detail. It takes longer but in the end, it saves time.
There is a lot more to troubleshooting, and as you gain experience you will develop your own techniques. But in the meanwhile, focus on the simple solutions first, take lots of pictures, and document your work.