Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Jay Barracato]

As I mentioned before, I am gearing up to teach digital electronics next year. I would like to keep things practical and incorporate good techniques.

Apparently, one of the most time consuming parts of the course is designing and modeling circuits in multisim, and then breadboarding them to confirm results.

Troubleshooting seems to be an ongoing problem, that the previous teacher never really mastered, and while I am very comfortable with system level troubleshooting, I really don't have any practical experience with component level trouble shooting. I can usually manage remove and replace for something that is obviously bad, but beyond that...

Are there any practical hints you can share with me that I can share with my students?

My instinct is to identify voltage/current values at important nodes for a working circuit and then use those values to test during troubleshooting.

Is this even a common technique?

Sent from my Moto Z (2) using Tapatalk

[John Roberts {JR}]

1-First step for component level troubleshooting is visual inspection. Faulty components can release their smoke leaving physical evidence. Some caps expand and/or release electrolyte making an obvious mess.

2- next common fault vector is bad connections. Over time mechanical solder connections can flow (solder is a liquid). Overheating solder connections can cause them to "dry" (become open). The fix for dry connections is to "re-wet" them with flux or fresh solder (to get fresh flux).

3- Schematic voltage/waveform advice. For digital troubleshooting this can get difficult because unlike analog it is not real time, but a trapeze act of events in sequence where timing matters. Troubleshooting new designs can be an order of magnitude more difficult than troubleshooting known working designs, but modern digital circuitry has a lot of the trapeze act inside so more robust and easier to debug. (note: "debugging" refers to moths getting stuck in relays opening the connection causing faults in primitive computing circuits.)

======

Troubleshooting is a logical exercise involving inductive/deductive reasoning... Eliminate what it isn't leaves what it is.

JR

[Jonathan Johnson]

The hardest part of troubleshooting to teach is the ability to work backwards and answer the question: "What possible factors could lead to the result I am observing?"

It's probably difficult because it generally requires both experience and an intimate understanding of the component behavior of the circuit being examined, and how those components interact with each other, to identify or dismiss possible factors. Students new to a discipline rarely have the experience or the familiarity of the product to have an intimate understanding.

This type of troubleshooting doesn't start by looking for the problem; it starts by looking at possible causes. When you understand the possible causes, that helps you determine what to look for and where to find it. Otherwise you're just changing parts hoping one of them fixes the problem.

It's applicable not just in circuit design, but in pretty much any field: audio (our common field here), computers, plumbing, advertising -- anything.

[Scott Helmke]

It can be surprisingly hard to make the jump from a design to a working circuit, or even from modding existing circuits to building new. Certainly took me some time to do that.

JR suggested the most obvious thing - just look at it and see if anything is burned.

One of the most useful troubleshooting things you can do happens in the design phase - make it easy to troubleshoot. Divide functionality into modules, and have definite tests for each module on its own. Build the power supply first, and have a plan for testing it standalone. Then move onto the next module. That way you never have to troubleshoot the whole thing at once.

[John Roberts {JR}]

It can be surprisingly hard to make the jump from a design to a working circuit, or even from modding existing circuits to building new. Certainly took me some time to do that.

JR suggested the most obvious thing - just look at it and see if anything is burned.

One of the most useful troubleshooting things you can do happens in the design phase - make it easy to troubleshoot. Divide functionality into modules, and have definite tests for each module on its own. Build the power supply first, and have a plan for testing it standalone. Then move onto the next module. That way you never have to troubleshoot the whole thing at once.

This is a bit of a veer but circuit design for testability is a real thing... the most obvious is including test points for probing voltage/waveforms, but subtle stuff like not using hidden vias that can't be probed helps. Modern multi-layer PCB make it easier to lose circuitry when troubleshooting but that comes with the territory.

JR

[Ivan Beaver]

I was a component level bench tech for most of my life.  Working DC up to 11GHZ gear.

The "standard approach" is different for different cases.

It is one thing to have a piece of gear that turns on, but does not operate properly.

It is quite another to have a piece of gear that blows fuses or circuit breakers when turned on.

And then you have the intermittants.

They each have their own set of headaches and approaches.

It would be a small book trying to generally describe each one.

Depending on what you are working on, for audio, the following pieces of test gear will go a long way towrds finding problems.  VOM, oscope, signal generator, AC series 100watt bulb (for amps), dummy load.

JR described a number of issues.  But to add, for gear that pulls to much current is to use an ohm meter (in the diode test position) to test all the diodes and normal transistors.  I can't begin to count the number of hours looking for shorted parts that way.

[Jay Barracato]

I was a component level bench tech for most of my life.  Working DC up to 11GHZ gear.

The "standard approach" is different for different cases.

It is one thing to have a piece of gear that turns on, but does not operate properly.

It is quite another to have a piece of gear that blows fuses or circuit breakers when turned on.

And then you have the intermittants.

They each have their own set of headaches and approaches.

It would be a small book trying to generally describe each one.

Depending on what you are working on, for audio, the following pieces of test gear will go a long way towrds finding problems.  VOM, oscope, signal generator, AC series 100watt bulb (for amps), dummy load.

JR described a number of issues.  But to add, for gear that pulls to much current is to use an ohm meter (in the diode test position) to test all the diodes and normal transistors.  I can't begin to count the number of hours looking for shorted parts that way.

Since the students will be breadboarding, I like the idea of designing with troubleshooting in mind. Another thing that comes to mind is testing the components as they come out of the band.

Also, I know they have had trouble with the link to the multisim used for the final measurement. Once I know more about it, a proof of the test equipment would also be handy.

I have gotten some solid examples from the contributions so far. By all means keep them coming.

Sent from my Moto Z (2) using Tapatalk

[Frank Koenig]

I would like to keep things practical and incorporate good techniques.

Spend some time on the analog side of digital design -- what generally is called signal integrity. I don't know where your students are in their studies and, admittedly, if they're just writing code for a field-programmable gate array (FPGA) they don't really have to know much about what goes on inside. But in the case of board- or system-level design this skill is often lacking. A few subjects come to mind:

Edge rates (rise and fall times), as opposed to clock rates, and their effect on design rules.

Current and fanout limits.

Voltage and noise margins.

Transmission lines, when needed (length > lambda/20?),  and their proper termination.

Clock skew.

Electrostatic discharge (ESD) protection and radio frequency interference (RFI) -- both in (susceptibility) and out.

Common board layout methods to avoid problems.

Story: When Cirrus Design first built the SR-22 (a single-engine light airplane) keying the mic (turning on the transmitter) on the number 2 radio while the flaps were in motion would cause them to turn around and go back to the previous setting. This will get your attention during an approach. The flap control board was not shielded and right next to the #2 com antenna. This stuff does matter. (A few strategically placed ferrite beads fixed the problem.)

--Frank

[Scott Holtzman]

Frank are you a pilot? 

Sent from my VS996 using Tapatalk

[John Roberts {JR}]

Spend some time on the analog side of digital design -- what generally is called signal integrity. I don't know where your students are in their studies and, admittedly, if they're just writing code for a field-programmable gate array (FPGA) they don't really have to know much about what goes on inside. But in the case of board- or system-level design this skill is often lacking. A few subjects come to mind:

Edge rates (rise and fall times), as opposed to clock rates, and their effect on design rules.

Current and fanout limits.

Voltage and noise margins.

Transmission lines, when needed (length > lambda/20?),  and their proper termination.

Clock skew.

Electrostatic discharge (ESD) protection and radio frequency interference (RFI) -- both in (susceptibility) and out.

Common board layout methods to avoid problems.

Story: When Cirrus Design first built the SR-22 (a single-engine light airplane) keying the mic (turning on the transmitter) on the number 2 radio while the flaps were in motion would cause them to turn around and go back to the previous setting. This will get your attention during an approach. The flap control board was not shielded and right next to the #2 com antenna. This stuff does matter. (A few strategically placed ferrite beads fixed the problem.)

--Frank

The world is analog, while finely quantized. 

JR

[Hayden J. Nebus]

JR described a number of issues.  But to add, for gear that pulls to much current is to use an ohm meter (in the diode test position) to test all the diodes and normal transistors.  I can't begin to count the number of hours looking for shorted parts that way.

Diode scale is like the Swiss-army setting on a DMM! Continuity, shorts, capacitor polarity, capacitor leakage, transitor leg orientation, the list goes on... Oh yeah, diodes too!

[Steve M Smith]

And then you have the intermittants.

Meaning it works perfectly every time you have it in to look at it but goes wrong every time you give it back to the customer!


Steve.

[Ivan Beaver]

Meaning it works perfectly every time you have it in to look at it but goes wrong every time you give it back to the customer!


Steve.

I worked for a guy once who told the customer to take a picuter of him and put it under the lid of their VCR.

That way the electrons inside the VCR would "behave" because a tech was looking at them.

TRUE STORY.  He could not find the intermittant (he was a very good tech) and just gave up.

[John Roberts {JR}]

Diode scale is like the Swiss-army setting on a DMM! Continuity, shorts, capacitor polarity, capacitor leakage, transitor leg orientation, the list goes on... Oh yeah, diodes too!

Some of us old timers will recall before we had DMM and fancy diode scales. The old school Simpson 260 could check diode/transistor junctions using the ohms scale...

I suspect modern DMMs could too but dedicated diode scale is better.

JR

[Chris Hindle]

Some of us old timers will recall before we had DMM and fancy diode scales. The old school Simpson 260 could check diode/transistor junctions using the ohms scale...

I suspect modern DMMs could too but dedicated diode scale is better.

JR

Jeez, that brings back memories.
I still have my 260 - somewhere..
Pulled the batteries, but didn't have the heart to bin it.
Chris.

[Frank Koenig]

I suspect modern DMMs could too but dedicated diode scale is better.

Modern DMMs are specifically designed NOT to turn on P-N junctions in Ohms mode unless using the diode setting. This is to allow in-circuit testing of connections and passives. A great innovation, I think.

As to intermittent problems, there has been a standing joke among my friends (for decades) that I possess the "laying on of hands". Whenever someone brings me some broken thing and I lay my hands on it it starts working. Of course when I send something to a shop to get fixed it starts working, too, more often than not. This leads me to think that another aspect of trouble shooting is thinking in terms of setting traps for intermittent problems. Digital scopes, data logger, buzzers with alligator clips, etc.

--Frank

[Frank Koenig]

I still have my 260 - somewhere..

I've got one sitting on my bench right now with leads attached ready for action. But I confess I don't use it much.  -F

[Frank Koenig]

Frank are you a pilot?

Hi Scott, FAA still thinks I'm a pilot. I have my doubts sometimes. I'm going to fly more next year -- really, I am, really. -F

[Stephen Swaffer]

As to intermittent problems, there has been a standing joke among my friends (for decades) that I possess the "laying on of hands". Whenever someone brings me some broken thing and I lay my hands on it it starts working. Of course when I send something to a shop to get fixed it starts working, too, more often than not. This leads me to think that another aspect of trouble shooting is thinking in terms of setting traps for intermittent problems. Digital scopes, data logger, buzzers with alligator clips, etc.

I've fought my share of "intermittents" in industrial electronics-but I have to ask, are there any really, truly intermittents?  The laws of physics are never intermittent-so there is always a cause-the trick is finding the root cause-be it vibration, thermal, radiation or whatever.

[John Roberts {JR}]

I've fought my share of "intermittents" in industrial electronics-but I have to ask, are there any really, truly intermittents?  The laws of physics are never intermittent-so there is always a cause-the trick is finding the root cause-be it vibration, thermal, radiation or whatever.

For analog circuitry I agree and age old techniques to parse out intermittence include cold spray (to force thermal stress), and percussive (tapping) troubleshooting for mechanical stress. OTOH modern digital circuitry can get into what appear to be intermittent states from combinations of flawed software, and or obscure button press combinations. While technically this is deterministic, this can be very difficult to replicate.

I have one digital controlled appliance that can lock up under random powering up sequences. Almost impossible for me to troubleshoot (without access to code, boot-up circuitry, etc). I just leave it always powered up. (Life is short and I already fix enough of other product designer's mistakes.) 

A little like a couple of my GFCI outlets that randomly trip for no known reason. One likes to trip when power is interrupted. I don't know how to fix that, other than replacement, while I doubt the fault is from old age or stress.

JR

PS: A classic joke about percussive repair is that the repairman charges the big bucks because he knows where to smack it. 

[Jay Barracato]

For analog circuitry I agree and age old techniques to parse out intermittence include cold spray (to force thermal stress), and percussive (tapping) troubleshooting for mechanical stress. OTOH modern digital circuitry can get into what appear to be intermittent states from combinations of flawed software, and or obscure button press combinations. While technically this is deterministic, this can be very difficult to replicate.

I have one digital controlled appliance that can lock up under random powering up sequences. Almost impossible for me to troubleshoot (without access to code, boot-up circuitry, etc). I just leave it always powered up. (Life is short and I already fix enough of other product designer's mistakes.) 

A little like a couple of my GFCI outlets that randomly trip for no known reason. One likes to trip when power is interrupted. I don't know how to fix that, other than replacement, while I doubt the fault is from old age or stress.

JR

PS: A classic joke about percussive repair is that the repairman charges the big bucks because he knows where to smack it. 

Yeah, I sometimes get odd responses if I forget to boot the coffee pot before I bring the toaster into the kitchen network. I usually end up having to reflash the toasters firmware from a jump drive. On the other hand the can opener seems to communicate with either flawlessly

Sent from my Moto Z (2) using Tapatalk

[Jonathan Johnson]

Meaning it works perfectly every time you have it in to look at it but goes wrong every time you give it back to the customer!

What's more frustrating than something that doesn't work when it should?

Something that works when it shouldn't.

[Tom Bourke]

I think troubleshooting is all about understanding signal and power flow.

Intermittents have a cause, It just takes time to figure out if it's mechanical, thermal, or software.

[ProSoundWeb Community]