Troubleshoot & Debug

USB Fail

Checking on the meaning of the word “troubleshoot” shows it to be defined as “trace and correct faults in a mechanical or electronic system” and the word “debug” describes “the process of identifying and removing errors from computer hardware or software”.

I use both of these words, a lot, and I hope I’ve used them enough in class to plant the idea into student’s heads that both of these words are really about problem solving, which is probably the most important thing you can learn in my class. If you’re dealing with physical things or electronic things, they are not always going to work, and figure out why they don’t work, and getting them to work is what it’s all about.

I recently had a student who had written some very simple code. It checked the distance of an object using an ultrasonic sensor, and when the right conditions were met, it turned a servo. This is dead simple, but for a student not well versed in writing code, can be a challenge. The student could not get it to work reliably. It worked for maybe 10 to 30 seconds, then froze up. I ended up wondering if there was a conflict between two code libraries, did some searches, determined there might be, found a way to write code without using a library, had the student test it, and the results were the same. I then duplicated the student’s circuit, ran the exact same code, and it worked fine for me. I then swapped servos with the student, then ultrasonic sensors, then Arduino, then… Then I just took the entire setup from the student, Arduino, USB cable, breadboard, wiring, sensor, servo, and tried it on my computer and it failed. Failed! Did not work. Eventually I discovered the student had a bad USB cable. Yes… a bad USB cable, that “sort of sometimes” worked. Sometimes. It worked reliably enough to upload code, but the student kept getting errors when trying to open the Serial Monitor (which should have been a clue) and had to attempt multiple times to open it.

Eventually, as you eliminate more variables, you narrow things down. Sometimes it’s just luck. Sometimes it’s knowing where to look, and not getting stuck thinking it’s one thing when it’s totally another. I took the bad USB cable, cut the end off, and tossed it in the junk bin, and gave the student a new cable. Everything worked fine then.

Whether it’s troubleshooting, debugging, or just “solving problems” it can take time, and you have to be willing to put in the time. It can be frustrating, but at the end you usually walk away with more knowledge about how to solve problems in the future. I can bet that if something like this happens again the student will remember that one bad USB cable that set back their progress for a few hours.

(I’ve also been working on rescuing a failed Windows computer this week, so I need all the strength I can muster to deal with the dumpster fire of an operating system that is Windows 7. I remain convinced that everyone who says they hate computers says so because they are forced to use Windows.)