[Elecraft] OT: troubleshooting "gotcha's"

Fred Jensen k6dgw at foothill.net
Wed May 8 22:57:22 EDT 2013


Elecraft sells kits.  Troubleshooting is part of kit building, always 
has been.  Heath did some really great things with kits, but didn't 
provide the support Elecraft builders get, both from the company and 
this list ... but of course, the Internet hadn't been invented then 
either. :-)

On 5/8/2013 4:02 PM, Don Wilhelm wrote:

> Let me re-enforce what others have said on this subject. Some excerpts
> follow:
> - Look for the 'simple' things first.

The #1 thing!  I've assumed all engineers and hams kept a notebook, and 
practically everyone did BI [Before Internet].  Many of mine as a teen 
were on the back of my log pages.  If you don't keep one, start one. 
Encountering what you think is a problem, start with the date, a 
description of the problem you're seeing, and what you can see without 
changing anything.  A large fraction of all the things I initially 
thought were "problems" turned out to not be.  Every entry gets a date 
... sometimes mine get a time.  Working out the sequence of what I did 
and what I find now is important.  It's like writing a story to 
yourself, you'll need it later.

> - Break things down into basics - work into a good dummy load, work with
> minimum connections to the transceiver. (It might be external equipment
> causing the problem).

Absolutely!  Isolation is the key.  "Radio won't make RF suddenly and 
behaves strangely," record in your notebook, and then get rid of stuff 
in the equation, ONE BY ONE!.

Make ONE change at a time ... and observe and record all the effects.

> - Verify your test equipment.
> - Do not make assumptions.

This is probably the biggest hindrance to finding the problem.  "Oh, 
well it's gotta be in the <mumble> I'll start there."  The odds of 
winning the lottery are about the same that the problem you observe, if 
it really is a problem, are in the <mumble>, given how many <mumbles> 
there are in our radios today, and how many ways the <mumbles> can 
confound us.

> - What is working is just as important as what is not, but do verify
> what is working first.

> - Work in an orderly manner - take notes if your memory of what has been
> done is lacking in the 'heat of battle'..

Yes, take notes, and then go back and read them before you decide to 
make a test.  Explain your proposed test to yourself, and explain to 
yourself, why this test might shed any light on on what you're 
observing?  "What do I expect the outcome of the test to be?"  "What 
does it mean if the outcome is what I expect?"  "What if the outcome is 
a surprise?"

My then current engineering notebook was on the kitchen counter, my wife 
asked if she could look at it, I said, "Sure, good luck," and she 
finally said, "It reads like you're having a debate with yourself.  I 
don't understand any of the 'stuff' you're working with, but I thought 
you all just knew how to do this." :-))

> - If it was working before, there is only a single failure point.

Not always ... but I can count the number of times when that hasn't been 
true on the fingers of one hand, and I retired from technology 13 years 
ago after nearly 50 years.  If it worked, and *truly* doesn't now, the 
odds that it's more than one thing are about the same as the odds I'm 
pregnant with twins. :-)  Multiple things almost always fail together 
only in a disaster cascade ... think aircraft crash, or Challenger, 
Challenger started with a single point failure, all the rest just 
happened too quickly to do anything about it.

> - The problem is not usually the worst case scenario.

I'd say, "If there hasn't been a fire in a corner of the chassis, a 
direct lightning strike, or the item has been physically destroyed," 
that isn't, "usually true" ... it's *always* true. :-)  Count the number 
of times Don has listed 1 or 2 or or sometimes maybe 3 things or 
components to check first and was right, usually on the first.  We 
always think the worst, it rarely is.

Things are a lot different from the Heathkit days, I could not have 
imagined my K2 then, and 50 years later, I built it.  We had Elmers 
then, maybe not so much now, however there are way more hams now, and 
this list is probably the Ultimate Elmer, and Elecraft is probably the 
Ultimate Heath. :-)

73,

Fred K6DGW
- Northern California Contest Club
- CU in the 2013 Cal QSO Party 5-6 Oct 2013
- www.cqp.org



More information about the Elecraft mailing list