Good troubleshooters are becoming rare these days. To some, the idea of working through a problem, finding and then fixing an issue seems like a time-consuming, wasteful evolution. More often than not, it is easier to replace the entire assembly with a new one, throwing the old one away. This is especially true with computer components. The other option is to send a module or assembly back to the factory for repair. Truth be told, often that is a good course of action when a fully equipped repair bench is not available. Surface mount technology can be difficult to repair in the field, as can many RF components.
Being able to troubleshoot components and assemblies is still a valuable skill. Finding and identifying trouble is a good skill no matter what it is used for. I find analytical troubleshooting skills to be good life skills to have. I think my in-laws are occasionally amazed when I walk into a situation and point to something and say: There it is, fix that.
Many times, however, there is no smoking gun. Those situations require a bit of investigative work. The first step in troubleshooting is developing a history:
- Has this failed before
- Is there a history of failures
- Has it been worked on recently
- Is it new
- Has it been installed properly
- It is old
- Has it been affected by some outside force like lightning or a power surge
This is where good maintenance records or maintenance logs come in handy. Recently, I have found many places that lack any type of maintenance documents, which means the repair history is unknown. This makes it difficult to find a good starting point and can greatly increase the amount of time required to troubleshoot a problem.
Once the pertinent history is gathered, it can be organized and analyzed for clues. For example, if something has been worked on recently, that is a good place to start. If something has a past history of failures, that is a good place to start. Newly installed equipment is subject to early failures under warranty due to component failures. Old equipment may just be plumb-worn out. Improperly installed equipment can exhibit all kinds of bizarre failure modes. That information coupled with known symptoms would indicate a good starting point for troubleshooting the problem.
If no good starting point can be discerned, then the next step is to recreate the failure. This usually means turning the thing back on to see what it does. Chances are good that whatever the problem is, it will still be there. Once a good set of symptoms have been identified, then it is time to start working at one end of the problem unit once the failed component is isolated.
Oftentimes, equipment manuals will have troubleshooting guides. These can greatly speed up the process for large, complicated things like transmitters, generators, and so on. There is also the tried and true troubleshooting chart:
This is an example of a troubleshooting chart for a transmitter power supply. Many equipment manuals will have this type of information in the maintenance sections.
It is also important to note that when working on high-voltage systems, it is necessary to have two persons on-site at all times.
Good troubleshooting skills have many applications.
2 thoughts on “Troubleshooting”
Well, just remembering some training that I have had about troubleshooting, it was 1982/83, ATS, Analytic Trouble Shooting. Sailing over the Internet showed up that the Company that used to teach this is still in business. It’s Kepner & Tregoe with is “Analytic Trouble Shooting® (ATS SM)”. Then was my first time in DEC.
If I remember the start example on how to work on ATS was a broken muffins maker machine. Think on the problem, think on several muffins with and without the problem, be pressed by mass production issues of malformed muffin and so on. Nobody want to eat a squared muffin, I learned. I think I have no eat muffins since then, I know why!
That was the time of departmental computer and super-mini multi boxes machines. Thing started to become a little bit more complex than simple 10 boards and some disks machines. S there was the need to discover how to develop and apply analytic brain power prior to swap tens of boards of not LSI and even not SMD boards at a time. A simple oscilloscope would not suffice tracking down a multiplex 64 wires bus, not anymore. So we had to change ours minding. BTW having several boards/components changed together the same time may introduce new problems and requires new analysis. Taking on what was the first group of reasons to made the change and the newest problem, fault, that the technician is facing. Not easy to do if made your first swap choices on guessing and betting. Make a change at a time is another golden rule, with several other things to be taken into account …
Nowadays who anymore is motivated to carry on with experience, just who knows the value of that. Who is able to speak on the why and when out of what is made a problem not blurring all around?
Or, better, is capable to ask customers about symptoms and behaviors. Just to have the right sense of the things well before to be on site.
Effective communications are often a not to be forgotten of any troubleshooting event, but who care of it? Customers, management, name others just quite to shot no for each one. Effectiveness of communications today is almost lost in between assertiveness and some, more worst, habits.
IMHO, still today, you reap what you sow. But anyway, dinosaurs has no left ours world in one day, take it easy and let changes flown. ;->
I still remember those heavy troubleshooting pathfinders with pages and pages like the one in yours picture … after having had frequent visits to each one of those they went covered of glyphs and notes like the inside of those ancient pyramids.
Hope to be understandable with my poor English, if you get here it could be, isn’t it?
Best regards and thanks for yours interesting blog.
Salvo, thanks for commenting, I think I understand the gist of what you are saying. Troubleshooting is a process. Working on a 64 bit buss sounds like fun! It’s nice to know management issues transcend culture and language.