We’ve all been through that magical moment when, after countless frustrating hours of experimenting and digging into your brain, the object of our attention begins to function. The 3D printer finally produces a good yield. The hacked laptop finally starts up. The car’s engine finally purrs. The question is, do we know why this started to work?
This is more important than you might think. Knowing the answer allows you to confirm that the main problem has been fixed, otherwise you may have just corrected a symptom. And lack of understanding means that solving one problem may just create another.
The solution is to adopt a methodical troubleshooting method. We’re talking about a structured problem-solving technique that, when used correctly, can help us solve a problem at its core without leaving behind any details. Such a methodology will also let you know why a solution worked or didn’t work in the end, and will give you repeatable results.
It is unreasonable to expect that we can effectively fix everything that we do not understand. For example, if a car is not performing quite well, it will be pointless to attempt a solution if you do not know the basics of ignition timing, fueling, engine operation at least at one point. base level.
If you are trying to create something from scratch or make a significant change to an existing product, a solid understanding of what the final product should look like will be needed. If you are unaware of these things, maybe it is time to take a deep dive, down the rabbit hole, as they say, on the subject in question.
Wikipedia, technical articles, forums, social media communities (groups.io, facebook groups, reddit, etc.) and of course Hackaday are all possible resources to learn. Once you understand how any system is supposed to work, you can move on to the next step in troubleshooting – the elimination process.
Now that you are as expert as you are going to be on whatever topic you choose, it’s time to dive in and see what’s wrong. Armed with our clear vision of what a successful process looks like and the process of elimination, we will investigate. Yes, we go all out Sherlock Holmes! If you grew up playing a certain copyrighted and registered board game, then you will know how it works.
The goal is simple: Identify all the steps that make up a successful process, then go through them one by one, starting with step one – even if (especially if!) You think you know where the problem already lies. One step after another. Not multiples, and certainly not all. No leap forward. Just one. And then after checking just one of the items at a time, you note: Did that solve the problem? Yes? No? Not sure? It is very good.
At each step, record your results, then move on to the next item on your list. Recording the results is vital to the process. And sometimes we don’t have all the facts until later in the investigation. Thus, being able to review the ratings will help us spot trends that we would never have noticed otherwise.
Even if you think you’ve fixed the problem, keep going through your list. Go through the entire system to make sure everything is working as it should. Troubleshooting is incomplete if you only watch part of the process.
In more complex systems, a multi-level approach will be very useful. Start with a high-level overview of the system at your fingertips. Follow the process until you find something broken. Once you have isolated the problem area, restart the troubleshooting process in that problem area, taking notes as you go. If you resolve an issue, return to the first level of troubleshooting and continue until the process is complete. This will help you answer the next question.
If you’ve identified and fixed what you think is the root problem, it’s time to verify that the fix is ââworking. The best way to do this is to test your article or process the same way it will be used. Sometimes it’s simple: The Thing works, and it’s fixed; there is very little in between to be had. Other times more in-depth testing is needed. Imagine fixing a car that won’t start, handing over the keys to its owner, and then finding out the hard way that it doesn’t have brakes either!
So you may need to take a âtest driveâ so to speak. The goal should be to verify that you haven’t fixed one problem but created two more and that the whole system is working as expected.
As with any method or process, it is quite possible to think that we are right when we are not. Troubleshooting is no different. If we get ahead at all in the process or if we don’t take notes along the way, it will be fairly easy to miss the point. Likewise, if we don’t fully understand the topic, we might not be able to identify when something doesn’t look quite right.
On the other hand, maybe we take a project from someone else and they’ve told us what’s wrong, but admit they don’t know how to fix it. This raises a thorny question: if they don’t know how to fix it, how can they be sure what is wrong to begin with? Take the incoming information with a grain of salt and see for yourself what the problem is before you start looking for a solution.
When I was young, I heard the woes of backyard mechanics complaining that they replaced hundreds of dollars in parts, but the problem they were having was not resolved. I distinctly remember them blaming the fancy new “electronic stuff” (fuel injection) for their problems. The reality is that they didn’t understand the system they were working with and therefore couldn’t effectively troubleshoot it, so they stopped analyzing the problem. and I just responded by throwing coins at it until something works, hopefully. And this is another way to fail the troubleshooting process.
In some cases, the exact troubleshooting process can be overkill. To build on the car analogy again, imagine you have an older fuel injected vehicle that is not performing well. It may be that due to the age of the system as a whole, nothing will really solve the problem. Years of dirt, poor connections, and worn parts all contribute to a vague problem that’s hard to duplicate. Also, we don’t know when the system was last fixed. In such cases, it may be necessary to adopt the shotgun approach. And no, I’m not talking about pulling it out and pulling it out!
The aforementioned troubleshooting method could best be described as a high precision rifle – we aim carefully and apply a fix. The shotgun method is exactly the opposite: we aim in the general direction of the problem and fire several projectiles, hoping that one of them hits its target and fixes the problem.
In our struggling EFI example, it might not be unreasonable to replace all the broken sensors and connectors. This would be followed by the reconstruction of the mechanical part such as the throttle body. Even replacing fuel pumps, filters, and cleaning the fuel system with fuel additive can help. And then once the system has been brought back to a known state, it can be tested and any remaining faults can be investigated using the proper troubleshooting technique.
Another use case for the shotgun approach is where we have an urgent problem that needs to be addressed. The root problem may have only a few known causes, so applying all the fixes at the same time may be faster in some cases. For example, we might not have time to properly troubleshoot a critical server with an unknown hardware issue. Swapping the storage system into a new computer will quickly bring it back online, and then the previous hardware can be tested without such time constraints.
Whatever the case, having a solid understanding of the system you are working on will help you take the right approach to solving the problem.
You may have noticed that the troubleshooting methods discussed are very similar to the scientific method that at least most of us have learned in school. And that’s why taking notes is so important.
Adam Savage jokingly said, “Remember kids, the only difference between screwing it up and science is writing it down!” ” (It was later attributed to Alex Jason.) And that’s really the point here: writing things down, taking notes on things whether they work or not, is a vitally important part of this whole process. Otherwise we are just blindly stabbing in the dark.
I hope you have found this foray into fixing delicate things useful. Do you have your own troubleshooting story, method or “Aha!” Â»Moment to share? Be sure to let us know in the comments below!