Dumb question out of ignorance. In electronics when you have absolutely no idea where something is failing is it possible to apply kind of a binary search in the circuit to either spot or discard a failing section? Is this an effective way to search for problems in electronics or are better ways to do it? Perhaps is a very stupid question but I had it in my mind for some time.
Just like with software, oftentimes you can bisect, sometimes you can't. There are some common approaches to roughing out problematic areas (checking power rails, confirming known oscillations, clocks and regular signals…). When you have the schematics, just as with source code you often can make educated guesses. With an unknown design though it is a laborious process akin to debugging a third party binary executable.
It's like every other debugging issue. First you need to figure out what it's doing and what it's supposed to be doing.
Then you work forward and backward until you find a spot where you can see a transition where the inputs are as expected and the outputs are not.
The more you know about the ciruit the easier it is. Arcade circuits tend to have a lot of documentation from the maker as they were expected to be serviced. But machines with small production runs are harder; the manuals may be lost or less detailed. Makers also tend to leave out details of protection mechanisms, some of these have been reverse engineered and documented by the community, but more work happens on higher production systems. In this case, they had three player boards that should work the same, but only one worked, and they were able to narrow it to communication (by using an undocumented test switch). They got lucky finding a missing ground, and then looked at communication with a sillyscope and replaced a standard communication chip.
Comments
Dumb question out of ignorance. In electronics when you have absolutely no idea where something is failing is it possible to apply kind of a binary search in the circuit to either spot or discard a failing section? Is this an effective way to search for problems in electronics or are better ways to do it? Perhaps is a very stupid question but I had it in my mind for some time.
Just like with software, oftentimes you can bisect, sometimes you can't. There are some common approaches to roughing out problematic areas (checking power rails, confirming known oscillations, clocks and regular signals…). When you have the schematics, just as with source code you often can make educated guesses. With an unknown design though it is a laborious process akin to debugging a third party binary executable.
It's like every other debugging issue. First you need to figure out what it's doing and what it's supposed to be doing.
Then you work forward and backward until you find a spot where you can see a transition where the inputs are as expected and the outputs are not.
The more you know about the ciruit the easier it is. Arcade circuits tend to have a lot of documentation from the maker as they were expected to be serviced. But machines with small production runs are harder; the manuals may be lost or less detailed. Makers also tend to leave out details of protection mechanisms, some of these have been reverse engineered and documented by the community, but more work happens on higher production systems. In this case, they had three player boards that should work the same, but only one worked, and they were able to narrow it to communication (by using an undocumented test switch). They got lucky finding a missing ground, and then looked at communication with a sillyscope and replaced a standard communication chip.