Tech Tip: Guide to Troubleshooting

Tech Tip: Guide to Troubleshooting

September 03, 2013

By Rick Escobar - Product Support Assistant Manager 

We have all been there. Something we are working on just will not work and we find our shelves stumped. I'm going to do my best to offer a process for working through any problem. 

Where's the problem? 
It's often the simple stuff that gets you. I find it best to first establish where it is working and reverse engineer from there. Let's take a simple system that consists of an iPod audio source, amplifier/mixer, and speakers. In this case everything seems fine but no sound is coming out of the speakers. 

Is there signal from the iPod? 
Using a pair of head phones will quickly establish if there is a signal. 

Test the Cable
Is the volume up on the amplifier? Try different Inputs. Is there an auxiliary output you can listen to?If the amplifier is verified as working then try a short cable to a known working speaker and connect to your amplifier output. This will rule out any wiring issues. 

Now let's look at some tools useful for troubleshooting. 

Product Knowledge: Having some information on the product capabilities and requirements can be invaluable. This is especially true for more complicated systems. This includes reading the manual, no one likes to do it but the solution may be just an index away. Of with a PDF ctrl F and a key word search is your friend.

System Knowledge: For example a microphones require pre amplification so hooking up to a line level input may produce nothing or a very low signal. The Devil will be in the details.

The Internet: It's amazing the amount of information that is out there. Sometimes a quick search will turn up a quick solution. I may be someone has already had the same issue. This also would include user groups. There are tons of these for all kinds of subjects and in general these groups are very helpful.

Tech Support: When all else fails, break glass in case of emergency.

How to explain a problem so that even an engineer will understand it. 

The best problem descriptions look more like a cooking recipe than anything else. You will get what is a being made, a summary of what it may taste like and steps to reproduce and an expected result. Here's a example of a Cake Gone Bad: Mom's Chocolate Cake Summary: The Cake did not rise Recipe: Mix batter per instructions Cook at 325 for 2 hours Result: Cake did not rise Expected: Cake should have risen 

Now the chief could look at this, review the mixing instructions and other steps. Maybe it was the incorrect temperature, maybe the yeast was bad. But from this point it is easy to keep moving forward to find a solution. 

I tried to keep this short and to the point, of course a complicated problem can be very time intensive but the process of moving forward to a solution pretty much stays the same.

When all else fails, don't hesitate to contact my team by 
clicking here.

Scroll to top