Read a schematic or just trace a schematic?

[guitjr]

Some of the replies to my post "What the books don't tell you?" suggested that in order to effectively debug a (n audio) circuit one need be able to "read" a schematic.

I took "read a schematic" NOT to mean that one could just TRACE a schematic  a) discern electrical components from each other and read their values plus b) follow printed circuit trails and directions.
I take "read a schematic" it to mean being able to pick out component configurations that might indicate this is an input circuit; this is an oscillator; this is an amplifier; etc. and use that knowledge to help one along in the debugging process.

That's not to say even following the lines effectively isn't a skill. Based on a hint in thread "FX90 Analog Delay Troubleshooting and Repair help please" (one that I'm still struggling on—partially just for this reason)
But I've been invigorated by a suggestion that I use my Photoshop skills (need not be Photoshop) to make the job easier: I'm busy at work photographing both sides of a circuit board; placing them in an art program's layers; resizing them so that they are the same size; flipping one photo and adjusting it so that I can simultaneously (and with opacity adjusted) see the bottom of the board superimposed on the component side. Neat trick!

But thinking more about it, I'm wondering why even this knowledge (although undeniably useful and probably essential to debugging complicated circuitry and absolutely essential to modifying or designing electronics) is necessary. For one thing, most of the components on a schematic aren't accessible—they're housed in those black boxes known as ICs.

SOOOOOOOOOO...After one's gone through the cleaning the board; looking-for-broken-connections; burnt parts; and dirt that could mess up connections,

Why aren't the following two methods adequate (though admittedly laborious) to debugging electronic equipment:
1)   Trace a signal from the input to where the signal stops. Right around where it stops should be the culprit. (What to do then might be tricky: check component (resistor, capacitor) values; replace the transistor or IC; and go on with the trace)
2)   Compare voltage values match with what someone else who has a working model gets from a) IC pinouts, etc.

I used #1 to trace the signal on a large guitar amp to the output transistors; replaced the transistors and voila! It worked. 
(Of course even using this very basic approach you learn things like: Any piece of equipment that involves a lot of plugging/unplugging will likely sport a break where the jack connects to the board...)

I thought doing the same to a little (few component) FX90 stompbox ought to be a breeze...and that this was a great place to start...but I haven't solved the problem yet.

[R.G.]

Why aren't the following two methods adequate (though admittedly laborious) to debugging electronic equipment:
1)   Trace a signal from the input to where the signal stops. Right around where it stops should be the culprit. (What to do then might be tricky: check component (resistor, capacitor) values; replace the transistor or IC; and go on with the trace)
2)   Compare voltage values match with what someone else who has a working model gets from a) IC pinouts, etc.

They are good, and you will probably recognize (1) as the advice for using an audio probe, often given here, and (2) as a reduced version of the advice in the debugging thread. Both of these were known and used all the way back to the early 1900s for debugging tube equipment, and they're still used.

The reason they are not adequate is that there are flaws that they won't in themselves catch. Among these are power supply issues, grounding and oscillation issues, and cumulative errors, such as a DC bias error that throws off a stage further down the amplification chain, as well as thermal issues and intermittents.

Power supply issues can make everything wrong; grounding/oscillation problems can make al the stages not act properly; offset errors have to be chased all the way back to the stage that causes it, which may still be passing signal and may not be too far off nominal voltages. There is a special place in hell for thermal and intermittent issues. These are the ones that come and go; they hide from you.

So yes, they're good, and the right place to start. The real art in debugging is to look at the schematic, think about how the circuit ought to work, then imagine flaws and conditions that MIGHT cause what you see, and then going and checking whether that was in fact the case. Ever watch "House, M.D."?

[karbomusic]

I take "read a schematic" it to mean being able to pick out component configurations that might indicate this is an input circuit; this is an oscillator; this is an amplifier; etc. and use that knowledge to help one along in the debugging process.

I just got into this around Jan 21st 2014. I did have some experience from decades ago but the first month or two, I'd look at schematics and have no idea I was looking at a voltage divider, or what it even did; or a buffer or emitter follower or feedback loop and so on. I was completely lost because I had no idea what these little "modules" were or that they even existed, it was all magic to me regardless of being able to "read" the schematic.

So I started studying them one by one. Building them isolated one by one which was the most important thing, build a simple voltage divider, play with it, measure it, stick my finger up it's proverbial butt. Moved on to bread boarding the simplest of transistor circuits and buffers, then the simplest of opamps, then the simplest of filters and clipping diode sections. As I added more and more to my list, I realized these were very much just that, modules and building blocks.

Then I went back to stompbox schematics, and voila "There's the buffer!", "There's the Vref", "There's the feedback path!", "There is the clipping section". Though I'm still quite the noob, I can pull many schematics up and figure out what they are doing very quickly. They make sense to me now and values of the components now tell me about how that particular module is configured. I can even design some simple things using datasheets alone.

I still remember "not getting" a simple MPF102 fet buffer and the LM386 simple amplifier circuit I was trying to marry it with. I got so frustrated, I pulled the datasheets for the transistor and the opamp and sat there and literally stayed up until dawn after deciding, I was going to get it one way or the other. Somewhere about the crack of dawn and a few thousand ripped out and replaced jumpers later, I got it... and the next evening, I had my own 1/2 watt guitar amp running off batteries.

So, my silly advice is to start with those building blocks and learn the most used ones, one at a time by actually building them and learning what they do. Doing so will raise questions, search out those answer to learn why they are designed the way the are, then return to schematics.

[PRR]

> most of the components on a schematic aren't accessible—they're housed in those black boxes known as ICs.

Schematics usually show ICs as white boxes. (Or triangles.)

There are a few major types of "black box guts". You should know the Op-Amp in its many forms. You should be aware of BBD Delays, CMOS switches, small Power amps, and a few others.

> Trace a signal from the input to where the signal stops. Right around where it stops should be the culprit.

And then there is the Inverter, or the virtual-ground mixer. At the Input pin there is "NO" audio voltage, nothing for the signal-tracer to trace. There IS a signal current through this node, but to prove that we'd have to break the curcuit and insert an audio current detector. This is possible but rediculously awakward and we never do that. Instead we recognize the virtual-earth character, and check the voltages at the live end of the in/out resistors.

[petemoore]

 They tell me it's been like this for a long long time, that's why I call inventors> discoverers.
There's nothing you can do that can't be done.
Electricity occured well before the word electricity was thought of.
How does mother nature keeps track of it all?

[Jdansti]

There's nothing you can do that can't be done.

Nothing you can sing that can't be sung.
Nothing you can say but you can learn how to play the game.
It's easy.

[bluebunny]

Ha ha!      "All together now!"