Amps
[Top] [All Lists]

[AMPS] Amps and Microprocessors

To: <amps@contesting.com>
Subject: [AMPS] Amps and Microprocessors
From: Ian White, G3SEK" <g3sek@ifwtech.com (Ian White, G3SEK)
Date: Thu, 25 Oct 2001 09:20:44 +0100
Jim Bryant wrote:
>
>What experiences have people on this list had with both shielding 
>microprocessor 
>control circuitry and display electronics internal 
>to a power amplifier from the intense RF fields as well as preventing the 
>microprocessor and display circuitry from inducing a hash 
>onto the output signal?
>
>My thoughts involve a brass box, vented, with forced air cooling, that would 
>be 
>chassis grounded, and with common-mode chokes on all 
>leads coming from this box.  Would this be enough?
>
>Also, any suggestions on which ADC/Multimeter chips that have a fast enough 
>response time as well as reasonable RF immunity?
>
>This is for a wet-dream amp project using a 4CX1600B that I've been acquiring 
>parts for for about a year or so, and am about halfway 
>to getting to the starting point.
>
I can't reply directly to the questions on microprocessors, but some
experience with several hundred Triode Boards and Tetrode Boards may be
worth sharing.

First of all,  if the amplifier is well designed and built, the control
circuitry should never be subject to intense RF fields. In a homebrew
amplifier you can ensure this by keeping the RF compartment well
shielded and bypassed, with the power and control in a separate
compartment.

Tetrode amplifiers are almost entirely homebrew, by people who seem to
take reasonable care with the layout and bypassing. Using single-sided
boards with reasonable precautions about bypassing, I haven't had any
reports of RFI problems.

Triode amplifiers are somehow different, because there are so many bad
examples of "open plan" layout. People follow those bad examples in
their HB amplifiers and the RF crawls everywhere - as I learned from
beta-testing the Triode Boards. The worst was the 50MHz "amp from hell"
which had so much stray RF it was lighting the front-panel LEDs!
Survival in that sort of environment requires high-level control logic
with extensive bypassing and choking. After the beta-testing I also
changed to a double-sided board, mostly to simplify the layout but it
also gave the opportunity to make most of the top-side into a
groundplane. That even worked in the "amp from hell".

Most of these precautions will be OTT for most amplifiers, but I never
know where my boards are going to be used, so it's better to be sure.

Turning that experience around to predicting RFI *from* an on-board
microprocessor is rather uncertain.  My feeling is that a shielded box
with bypassed/choked inputs and outputs will be fine - especially  if
the main layout does a good job of keeping RF only where it belongs.

>My goal is to get as near hands-free as possible, with realtime monitoring of 
>every aspect of circuit operation on a LCD panel [no 
>multimeter switches], automatic tune-up, ALC, hands-free realtime screen grid 
>protection that would require no operator intervention 
>and not result in the amplifier being shutdown or bypassed [IMHO, idiot lights 
>are a dumb idea, and can go unnoticed long enough for 
>damage to occur; coming from an enterprise computing background, downtime is 
>unacceptable, 

Everybody agrees with that, in principle... but good luck with making
that philosophy work in an amateur radio station! 

I agree that idiot lights should be restricted to announcing what went
wrong, and that the amplifier should already have taken its own
action... but your ambitions for zero downtime may be unrealistic.

If the amplifier was working OK, but now detects a fault condition, then
something has gone wrong - and that fault may not be related to either
the amplifier or the transceiver. Considering the whole station, from
the mains to the antenna, there is a very limited range of fault
conditions that the amplifier is capable of fixing on its own. It is
often better to make the amplifier safe (hot standby) and alert the
operator to the fact that something has gone wrong.

This may be where microprocessor control in the amp can reduce downtime
by analysing the fault and displaying useful information.

>so, plate-voltage cutoff when an 
>excessive screen-current condition exists is IMHO just as bad as an idiot 
>light.  
>Amplifier shutdown should only happen when signs 
>of catastrophic failure are detected, rather than a condition that can be 
>corrected in realtime].

The whole trick is to know the difference. After more than 25 years of
running tetrode amplifiers, often under extreme conditions, I'm still
not sure! Even with a system where excessive screen current cuts the HV,
I've still not experienced much downtime. Pushing the RESET button
brings the amplifier back to hot standby in literally one second. The
major downtime is always in finding out what made it trip.

A very useful concept is a hierarchy of faults. Alpha amps distinguish
between "soft" faults which put the amp into standby, and "hard" faults
which shut it down. I do something very similar on the Triode Board.
It seems that you're trying to venture into a third and much trickier
level, namely "correctable faults" which the amp should be able to
handle without interrupting service.

One area where microprocessors can score is to distinguish between
faults that appear gradually and faults with a very fast rise-time. For
example, if screen current is gradually creeping up, a re-tune followed
by possible ALC action may be indicated... and there will probably be
time to do that. OTOH, if screen current is shooting up very quickly,
that probably means the HV has failed, and you want to shut down the amp
instantly - if not sooner. A microprocessor can check rise-times by
comparing current and previous measurements (with some difficulties
about getting comparable measurements with varying SSB modulation) but
this takes additional cycle time and gives a slower reaction to
catastrophic faults.

To get the very best out of a microprocessor-controlled amplifier, it
needs lots of attention to the fine details of programming. And I'd
still be inclined to implement the catastrophic-failure protection
independently in hardware. While the control software is still under
development, it could frequently push the amp into the catastrophe zone
so it needs some hardware backup. 

>Keep in mind that I'm not knocking traditional-design manually-operated 
>amplifiers, in the hands of a good attentive operator, they 
>do just fine.  

I understand that, and am offering these comments in exactly the same
spirit.

>I just want to do my amplifier right.  Gawd knows, I'm spending 
>enough money on the traditional parts, I've got no 
>problem with going the extra mile to get the rest of it right.
>
Sounds good to me! I hope these thoughts and experiences are helpful.

>I may do an article on this once it's built, after all, share and enjoy.

Yes please!

73 from Ian G3SEK          Editor, 'The VHF/UHF DX Book'
                          'In Practice' columnist for RadCom (RSGB)
                           http://www.ifwtech.com/g3sek

--
FAQ on WWW:               http://www.contesting.com/FAQ/amps
Submissions:              amps@contesting.com
Administrative requests:  amps-REQUEST@contesting.com
Problems:                 owner-amps@contesting.com


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