[...]
Testing doesn't mean just poking something with an instrument to see what's coming out.
Well, most of the time that statement is accurate... but it seems very cut and dried unless you are in a controlled environment. Say you are repairing an unfamiliar and undocumented piece of equipment, you have absolutely no idea what is causing some obscure fault - so you are looking for clues. You might be following the "golden rule" of checking the supply voltages first, for example. So you might look for excessive noise on the lines. But at what frequency? Depends on the circuitry sipping the juice as much as the PSU, right? Could be 60Hz, 120Hz, or several megahertz. Taking a look around using different timebases suddenly seems more like a prudent strategy of elimination rather than random probing?
It really doesn't matter if you're dealing with a familiar device or something new, really. Because there is always some basic information you will have. You may not be familiar with the UUT but you still must have some idea what it does, because if not then you wouldn't be able to determine what is faulty behavior and what not in the first place.
You always start from what you know, not from what you don't know. And the more you don't know about the UUT the more critical becomes proper preparation before you start probing.
In your noise example you wouldn't jump in with a scope. You'd first visually examine the device, check for visible damage, determine what kind of PSU it uses, how it seems to work and what voltages you expect to see where (which also are your first test points). You then might want to draw this out on a piece of paper and mark the points to test (and what voltage you'd expect at each point).
Right now you have already increased your knowledge about the UUT without even doing any measurements! But it's probably also as far as you can get visually with the amount of information you have, so to learn even more you need to start to gather additional data.
The first set of measurements should establish what the actual voltages are at the points you identified and if they are stable. Because knowing the voltages will help you to establish if your basic assumptions above about the PSU are correct. And the best tool to measure voltages isn't a scope, it's a DMM. Depending on the capabilities of your DMM you might also want to measure the AC component (low frequency noise, usually somewhere up to 1kHz) of DC voltages.
So you power up the device, measure the voltages and (for DC voltages also the AC components) at the test points and note them down in your drawing.
Then you go back to your paper which now has the new data, look at the test points and the expected and the measured voltages (and the measured AC component). If there are differences then you start examining the ciruitry which feeds the rail which shows the difference, deduct some schematics and calculate what the correct voltage and tolerable AC component would be. Maybe you determine you need additional data (i.e. the voltages over specific components), so add the additional test points to your drawing and perform another set of measurements which gives you even more data. Then you go back to your drawing to evaluate the data and find out if the results are as expected or not.
If so far everything has worked out then the point comes where you look at noise, and for that the scope is probably the best tool. But agin, you shouldn't just jump in, twiddling knobs until something appears on the screen. You spend some time thinking about what information you want (here: amplitude and frequency of noise if there's any) and what can you get, based on the limitations of your test equipment.
Let's for the moment assume all you have is a DS1054z, i.e. a basic scope with no power analysis or other advanced stuff, plus some passive x10 probes (say 250MHz). In single channel mode you get 1GSa/s and an analog BW of (hacked) around 130MHz. Therefore any noise you can find with your scope will be within a range of ]0Hz;130MHz]. Also, the noise amplitude needs to exceed the scope's + probe's internal noise, as otherwise it would get hidden in your test equipment's noise floor. So let's say (let's assume for the moment the DS1054z noise floor is at 800uV, or 8mV with an x10 probe). So clearly, you're not capturing very low noise levels (which still might shift the power rail outside spec) or noise components of more of approx 130MHz.
The DMM measurments already covered AC ripple up to 1kHz (if not then you'd want measurements specific for that). Which means the noise frequency you want to look at would be [1kHz;130MHz]. 1kHz means a period is 1ms long, and ideally you want to capture at least three of them. A DS1054z with 24Mpts will be able to capture 10 periods (10ms) at full 1GSa/s sample rate (using 10Mpts memory), so the scope should be set to a timebase of 1ms/div. Set trigger mode to AUTO, trigger level to say 10mV, enable Vpp and Vrms measurements, then start to probe. Connect to the test point and turn up the vertical div setting to increase the signal to cover as much screen space as possible without extruding from it. Enable zoom and zoom in to check various sizes of a signal segment for any visible AC content. In your example, lets assume that most PSU rails are OK but there is one with lots of noise. So you make sure the signal height is maximized as for screen height use without over-shooting, then enable FFT so look at the frequency components. Set FFT to cover the band from 1kHz (or zero) to 130MHz and then read out the individual peaks.
At this point you not only know which rail has the noise problem, you also know that the other rails are fine and for the failing rail you even know the noise frequency (which can help you find out where it comes from, if you, again, use a methodological approach).
No matter where you start, you always need to make sure first that you understand what you are testing before you can even think about making a determination if certain behavior is normal or a fault.
Learn to test, test to learn! 
Testing properly means working methodologically, you have to spend some time thinking about what you have, what you want to achieve, what you ideally expect, what problems/issues you may encounter and how to address them, and then develop a test strategy which will give you the desired data in a reasonable amount of time and with reasonable effort. And then you go and execute your strategy. And if your strategy was sensible you get the data you need. If not, you re-strategize and execute again. Simples.
Sure, but that could describe playing chess or any other difficult activity... in other words, the description is not enough information to actually play the game well!
It is. Again, think about what you know, not what you don't know. A methodological approach gives you a way to get the missing, relevant data in shortest time and with the least amount of effort.
And yes, that same principle may well hold true for other unrelated activities. Chess, after all, is a game of strategy 
I think that sounds a perfectly valid strategy and I do appreciate the logic. The strategies and "hunches" used to fault find could fill entire bookshelves.
But - is it downright wrong to just use the scope for the whole thing in this example? - after all, most digital scopes will give you the DC voltage, peak to peak & RMS noise, as well as a visual indication of any noise, and more, just by touching the probe to a rail once and doing a single shot (which you then zoom in/out, naturally, to get the full overview). In many repair situations, the boss will want FAST results... and a digital scope is surely one of the fastest and best tools ever for inspecting the overall behaviour or electronic circuits, even at the initial stages?
One of the huge advantages of multi-channel scopes is revealing connected behaviours between different parts of the circuit that would be difficult to see with a DMM or even a single channel scope. So for example, by scoping 2 rails and an output simultaneously you might see events that are connected between them, possibly giving you vital clues that you wouldn't otherwise have got?
Home
Help
Search
Login
Register
