- Is the problem in the source path or receive path?
- Does the problem
- Change with respect to frequency?
- Change with respect to power?
- Be sure you’re looking for the right problem
- Usually run all diagnostics
The list shows the basic thoughts to always keep in mind when troubleshooting the Cassini Test System.
The test system uses the sources to test the receiver, and visa-versa. When a test fails, you can immediately cut the problem in half by checking if the problem is in the source path or the receive path.
Also, does the problem change with respect to frequency (frequency response problem) or power (linearity problem)?
Always remember, more often than not, “Murphy’s Corollary” applies. “There is always more than one problem”.
The inverse of that can also apply: sometimes one problem can cause multiple failure symptoms. This is why you want to run all the diagnostics, to find patterns in the failure symptoms that point to a specific problem.
‘Normal’ Troubleshooting Tree
- Run Diagnostics (all of them)
- Review failed data
- Look for patterns (only 1 port, direct receive path, etc.)
- Pull up test plan
- Re-name to ‘Junk’
- Set breakpoint
- Run to breakpoint
- Open Controller
- Manipulate settings through controller
- Begin ‘halving’ signal path
- Isolate bad component
Unfortunately, for RF, it’s not practical to insert test points wherever we feel like. So, to diagnose RF problems, you normally have to run all of the tests, then look for the patterns in the failures. For example, if a problem occurs at RF3, but not RF2, 6, or 7, then the problem must be in some area that’s unique to RF3. If the problem occurs at RF2, 3, 6, and 7, then the problem must be with something that’s common to all those ports.
Using this process of elimination, you can usually diagnose the problem to a couple of possibilities before you connect any test equipment.
Once you’ve done the heavy thinking to eliminate what it can’t be, then you can check for the remainder by manipulating a test plan to stop at specific points, and checking where the signal goes bad.
Remember, you are a super-user. As such, you have the power to render the test system totally inoperable. An easy way to ‘accidentally’ do this is to modify a test plan then save it.