[Top] [All Lists]

Re: [TowerTalk] Balun Recommendation

Subject: Re: [TowerTalk] Balun Recommendation
From: Ian White GM3SEK <>
Reply-to: Ian White GM3SEK <>
Date: Tue, 24 Apr 2012 11:03:07 +0100
List-post: <">>
Jim Brown wrote:

>  If this sounds complex, it's because IT IS!  And it's why Ian and 
>Ward have emphasized that adding a choke changes the system, so we must 
>re-analyze it.
>But it's also why we recommend "brute force" solutions that tend to 
>more problem-free and have a better chance of success than others, like 
>a high value of resistive impedance choking.

I agree with Jim, but calling this a "brute force" approach is being 
unkind to ourselves. Real-life RFI problems provide a deeper technical 

RFI problems often affect other people, and they often put the 
reputation of ham radio itself on the line. In those situations we don't 
have the luxury of analysing the situation in complete depth. We also 
don't have the luxury to "try, try again". When other people are 
involved, there is an imperative to GET IT RIGHT FIRST TIME!

If we do nail the problem first time, then it's an outright win. If that 
involved using higher-impedance chokes than might have been strictly 
necessary with the luxury of 20-20 hindsight... then so be it. The only 
important thing is that our solution WORKED.

Jim also mentioned another important concept in RFI: "a better chance of 
success" - and the key word there is "chance".

Choke design and the suppression of unwanted RF currents is a very big 
subject, but it is still only one-half of any RFI problem. The other 
half depends on the characteristics of the affected ("victim") 
equipment... and we often have no control of over that. This often 
reduces RFI - quite literally - to a game of chance.

As Jim says, our only viable strategy is to use high-performance chokes 
that shift the odds in our favor. I agree with Jim that the key to this 
is a high resistive impedance, maintained over a broad bandwidth.

Steve has provided some new insights showing that reactances will often 
combine in our favor as well. When reactances add significantly to the 
installed impedance of the choke, then of course that is a very welcome 
bonus; but in a new RFI situation with no time for an in-depth analysis, 
I wouldn't want to bet on retaining that bonus across every amateur 
band. The only part of the impedance that we can depend upon in every 
possible situation is the broadband resistive component.

So how much resistive impedance do we need, to give ourselves a 
DEPENDABLY high chance of getting it right first time? That answer can 
only come from the combined experience of many users in many different 
situations, and of course it can only ever be a fuzzy answer involving a 
large element of technical judgement.

But we do know that "500 ohms" is a *wrong* answer. There are too many 
examples of failure of these low-impedance chokes (eg short strings of 
beads), either failure to solve RFI problems or failure to handle high 
power is severely unbalanced antennas. These failures aren't at all 
surprising because "500 ohms" has a very dubious technical background.

There is a broad consensus that chokes with a broadband resistive 
impedance of... let's say, "a few thousand ohms"... will offer a much 
better chance of success in many or most practical RFI situations. I 
have tended to focus in this area of performance, and on the 
cost-effective use of ferrite (which in Europe is almost double the best 
prices in the USA because of shipping and taxes).

For severe RFI problems, or for chokes that are required to act as 
"ferrite insulators" within an antenna, then by all means go with Jim's 
heavy-duty choke designs that provide a broadband resistive impedance of 
5000 ohms and more.

In summary, there is a very good technical rationale for the use of 
high-performance chokes, which goes a long way beyond "brute force" and 
"overkill". As Jim says, it's all about giving ourselves a very good 
chance of getting it right first time.


73 from Ian GM3SEK

TowerTalk mailing list

<Prev in Thread] Current Thread [Next in Thread>