[AMPS] Microprocessor control of high power amps

John Lyles jtml@lanl.gov
Mon, 8 Dec 1997 12:23:14 -0700


hi,

>Has anyone any experience in controlling a high power amp with a
>microprocessor ?

I have some experience with this topic, but it is dated...
I'm sure folks like Dick at ETO have a lot of background with this. Most of
the broadcast transmitters over $25,000 have an embedded controller
in them. When you spend half a million on a TV tranmitter, you can bet it
has some extra features built with a micro these days.

> I would also be interested to hear
>from any owners of commercial amps that use microprocessor control. Do
>you know the sort of micro used ? I did look at making a board myself,
>using the Motorola HC11 microcontroller, but in the end too the easy
>option.

In the early 1980's the company i worked for was the first to put an
embedded controller in
a broadcast FM transmitter. Our first attempt was, however, not an
especially robust design.
The micro designer was also the high power RF design engineer (not an
especially good approach).
It was based on the now extinct Motorola CMOS MC14500B inductrial 1 bit
controller. I remember that the RF leakage (from amplifier cavity out to
controls) and transients during tube or cavity arcs would wipe out some of
the CMOS logic. A favorite failure mode was for the IC package of one chip
to actually erupt with a small plastic crater in the center, and smoke. We
called it 'cratering' the chips! RF filtering was minimal, mostly disc
ceramic capacitors on the digital boards, and the package was in a box with
easy opening panels with 1/4 turn fasteners.

This product was only on the market for less than a year, while the company
redesigned it. Our improved version, went to hard logic (still CMOS, for
the higher noise immunity), RF filtering/transient suppression networks on
all analog inputs, optical isolators on all digital or relay signals, and
high performance RF gasketed enclosures for all subsystems, to keep RF in
the RF parts, and RF out of the controller parts. We then built a second
microprocessor-based monitoring system, that used a Z80, and S100-like bus.
The designers did a fantastic job, and built automatic watch dog circuitry
that could make the transmitter run on the hard logic or the
microprocessor. It was a redundant system. The switch over could take place
during operation without a glitch with the use of analog switches at the
inputs and output.
The CPU did a lot of nice tricks like measure the air exhaust temp,
computed the dissipation based on Pin and Pout, keep a log of what the
latest trips were caused by (after the fact even), and handle RS232
communications from the TX to the user at a radio studio. We never needed
auto tuning when driving a broadcast array with a fixed frequency and
power. All of our original rigs got a free replacement with the new
hardware i think. It was a pretty major retrofit, but I commend the
management for taking the step, eating the costs, and doing it to uphold
their reputation in the industry. They were a newcomer to that market, and
this step did a lot to convince customers that they would not ignore
problems. A lot of the stuff that we put in the microprocessor version was
on the forefront for commercial products (not ham stuff, I didn't know much
about what it had those days).

About 6 years ago, I worked for a few months on a project with an RF
dielectric heater. It was BIG,
and had an Allen Bradley PLC for control, having not only the RF tube
protection and timing, but the product transport control, the temperature
of the process, etc. Again, someone designed first by skimping on RF
protection, ground loops, transient protection, and we lost components, I/O
modules, A/d converters, until we went in with a heavy approach to add
shielded wiring in place of twisted pairs, series L and ferrite beads in
addition to short leaded disc capacitors, and so on. We finally succeeded
in cleaning it up, and it was quite functional.

I realize that an amateur amplifier would probably be smaller, more
compact, and have lower RF leakage than these examples, but the lessions
learned are the same, only scaled. Take great care to buffer, isolate,
filter, average the data, whatever it takes to make the CPU work and
calculate with nice steady signals, not RF waveforms. And remember the
facts that analog electronics (op amps) can become overloaded and make
great detectors for RF. For critical designs such as the tube protection,
you might consider doing it in hard logic or relays, and let the CPU know
about it. If timing is critical, and the CPU is in a loop making a
calculation, you may stand to loose a tube. And add a watchdog timer to the
CPU to ensure that it will not sit there brain dead if the program seizes
up. You transmitter will continue to meltdown otherwise.

I believe that it is probably more prudent to overdesign the RF filtering,
transient protection, and overall quality of the software than to start
bottoms-up, build a piece of junk, and try and then figure out what's
wrong, while breaking tubes along the way!

The Parallax and Micron microcontrollers, the 'HC11, and a number of other
board level systems should do a great job. As long as you do a great job
with the I/O.

john
K5PRO






















--
FAQ on WWW:               http://www.contesting.com/ampfaq.html
Submissions:              amps@contesting.com
Administrative requests:  amps-REQUEST@contesting.com
Problems:                 owner-amps@contesting.com
Search:                   http://www.contesting.com/km9p/search.htm