OT: troubleshooting "gotcha's"

[Edward R Cole]

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.

Case in point was a problem I was seeing with SWR read by the KX3 at
some frequencies in the HB TR switch that I was testing.  On HF I
figured there would be little distributed inductance and reactance in
the pc board.  I tested at 10w using the KX3 on the work bench and
got excellent SWR and transmission loss thru the pc board relays
until I got to 17m, 15m, and 12m.  Strangely, 10m tested good?

On those three bands the SWR went to heck.  Trying several things to
compensate got me nowhere.  I finally reconnected the input coax at
the same land as the output coax and still was seeing this effect -
huh?  I began to suspect the KX3 internal circuits had gone bad on
those bands.  So I connected a coax direct to the power meter and
50-ohm load (SWR still high).  Then is dawned on me.  I was running
with the ATU enabled and it had memory of previous loads that were
not 50-ohm.....duh!  I switched to BYP and retested and the SWR
problem went away for nearly all bands.  There was a little creep up
on the highest frequency (12m and 10m), but that is expected as
circuit dimensions become significant in wavelength.

 From the workbench,
73, Ed - KL7UW

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

[k6dgw]

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:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

[Matt Zilmer]

There is/was a flowchart for this type of troubleshooting.  It used
coarse language, but followed this same type of logic.

73,
matt W6NIA

On Tue, 07 May 2013 12:17:05 -0700, you wrote:

>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:[hidden email]
>
>This list hosted by: http://www.qsl.net
>Please help support this email list: http://www.qsl.net/donate.html

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

[Edward R Cole]

Fred,

Been there - done that!

When beginning my career in 2-way repair, an old experienced tech
told me some good advice on troubleshooting:  "its usually something
simple", in other words don't be looking at major things to
fail.  This is why the first step is to check all the inputs and
outputs.  Does it have power?  Does show output.  Is it plugged
in?  Did you push the wrong button.  Uhuh!

73, Ed - KL7UW

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

[Stan AE7UT]

Well let us hope I learned from the experience!

I just ordered a K2 to build.  I'm so grateful for
the patience and help from the group.

73
Stan AE7UT

[Don Wilhelm-4]

I have not previously posted on this thread, but there has been a lot of
good information posted by others.

Let me re-enforce what others have said on this subject. Some excerpts
follow:
- Look for the 'simple' things first.
- 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).
- Verify your test equipment.
- Do not make assumptions.
- 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'..
- If it was working before, there is only a single failure point.
- The problem is not usually the worst case scenario.
- RF voltage checks are important part of troubleshooting if you have a
transmit problem.
- Intermittent problems are a bear to find - when you touch something in
the area, it works and the problem disappears - look for faulty solder
connections.

Familiarity with the block diagram (or better yet the schematic) of the
transceiver is a great help as is some familiarity with the basics of
electrical laws and circuits. (i.e. if the emitter DC voltage of a
transistor is not correct, and the resistor value is correct, then the
transistor is not drawing the expected current - simple Ohms law).

73,
Don W3FPR

On 5/8/2013 6:33 PM, Stan AE7UT wrote:
> Well let us hope I learned from the experience!
>
> I just ordered a K2 to build.  I'm so grateful for
> the patience and help from the group.
>
>

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html

[k6dgw]

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

______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html