That observation extends to a variety of "things that should work but
don't," not just electronics. Over the years, I've noted several
troubleshooting rules in my engineering notebooks. Some examples:
1. Unless there was a fire, and sometimes even then, it usually is
*not* the worst possible problem although that seems to be a common
assumption at first. "Nuts! I must have blown the PA's," when the fuse
to the PA power supply just quit [they actually do that].
2. If it worked fine for a long time, and no one changed any of the
code, it is very unlikely to be a programming bug so don't start
tweaking and recompiling.
3. If it worked fine for a long time and "no one changed anything," the
odds are very very high it's pilot error. If your K3 receiver seems
dead on one band, check the ANT 1/2 switch setting on that band first.
The radio remembers it by band, you may not.
4. If someone gave me a buck for every time I spent days or weeks and
exhausted every source trying to debug a function, only to ultimately
discover that the code actually doesn't call that function anymore, I'd
have retired much earlier.
5. Is it plugged in?
73,
Fred K6DGW
- Northern California Contest Club
- CU in the 2013 Cal QSO Party 5-6 Oct 2013
- www.cqp.org
On 5/7/2013 3:32 AM, Edward R Cole wrote:
AS I read "Re: [Elecraft] KAT100 project - removing the control board",
Stan related his troubleshooting adventure and found that his
assumptions led him astray. That is one of the cardinal issues with
troubleshooting - do not assume. As soon as you assume soemthing is OK
that will be what you eventually will find wrong.
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:Elecraft@mailman.qth.net
This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
