Thursday, December 5, 2019

A 500 Watt HF PA, Part 8: Complete Schematics

This is the last post in my series of posts describing my 500 watt HF PA project:

In this post I have gathered all of the schematics that were scattered across the previous posts.

But first, the block diagram, for reference:

And now, Schematics!

PA Assembly:

LPF Assembly:

Power Supply and Supervisory Circuitry (and Fan Control):

T/R Switching and Output Directional Coupler:

Front Panel and Controller Assembly:

Back Panel and Interconnects:

That's it!  The other posts in this series are here...

K6JCA HF PA Posts:

Standard Caveat:

I might have made a mistake in my designs, schematics, equations, models, etc.  If anything looks confusing or wrong to you, please feel free to leave a comment or send me an email.

Also, I will note:

This design and any associated information is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without an implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

A 500 Watt HF PA, Part 7: Back Panel, Interconnects, and Miscellaneous

This post is the seventh post in my series describing my 500 watt HF power amplifier project:

In this post I will describe the back panel, the various interconnecting cables, and any other miscellaneous topics that come to mind:

Here's a shot of the Back Panel:

And the its other side...

Back Panel Schematics:

There's really only one circuit on the back panel, and it is for the connectors to control the PA.  Here is its schematic:

My FPGA-SDR transceiver uses the RJ-45 connector (shielded!) to control the PA.  If I want to use the PA with a different receiver/transmitter combo (or transceiver), I've included a traditional RCA jack for the T/R conrol.

The diode to the RCA blocks any positive DC voltage that might be on the RCA jack's T/R signal so that it does not blow up my control circuitry.

Interconnect Cables Schematics:

The various assemblies within the PA require cables to interconnect them.  These cables are shown in the two schematics, below:


(Control cables with one end soldered to a board are not shown in the drawing, above.  Instead, they are shown on the appropriate schematic).




Some time ago I decided to standardize on using the carcasses of old HP gear for my project builds.  You can see an example of this here with my Automatic ATU, FPGA-SDR transceiver, and ancillary equipment (apart from the Tek scope and microphone):

For this project I chose another HP chassis, but while trying to fit the switching power supplies, the PA, LPF, Supervisory, T/R Switching, and other assemblies into it, I realized I had created a "blivet."

What is a "blivet"?  It's what you get when you try to squeeze 10 pounds of manure into a five pound bag.

The Blivet-to-be...

(Shown with an analog Vdd supply that I later discarded for switchers).

Back to the drawing board, or, in this case, a search of my attic, where I found another chassis.  At the time it seemed a little too large (but in hind sight the size is perfect!).  And, best of all, it was essentially a "virgin" HP chassis -- there were neither holes nor labels on the front panel.

In other words, apart from some holes in a back panel, it appeared unused.

Where did it come from?  I suspect a local HP engineer (this area is where HP started, after all) decided to use the chassis for a project but did not get too far with it.  Later it must have appeared at the local swapmeet where I picked up, long ago in the dim past.

Here is that HP chassis, now containing my new PA...

I had to purchase a 12"x12" 0.1" thick aluminum plate (from OnlineMetals) upon which I mounted  the various assemblies.

And I had to drill (and, for the bottom cover, punch) holes for ventilation:

But apart from that, the mechanical build was relatively painless.

And the case even included these very convenient carrying handles!

Overall weight of the entire Power Amplifier is about 27 lbs.

And that's it for miscellaneous topics and this blog post!    Continue on to the other posts in this series via the links, below...

K6JCA HF PA Posts:

Standard Caveat:

I might have made a mistake in my designs, schematics, equations, models, etc.  If anything looks confusing or wrong to you, please feel free to leave a comment or send me an email.

Also, I will note:

This design and any associated information is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without an implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Wednesday, December 4, 2019

A 500 Watt HF PA, Part 6: Front Panel and Controller Assembly

This is the sixth post in my series of posts describing my 500 watt HF Power Amplifier project:

This post will describe the Power Amplifier's Controller Assembly and its Front Panel Assembly.

Controller Assembly Schematics:

The Controller Assembly is the brain of this power amplifier.  It is tasked with the following:

  • When transitioning from Receive to Transmit, first flip the T/R relays.  Then, after the relays have stabilized in their new position, apply bias voltage to the PA.
  • Similarly, when transitioning from Transmit to Receive, first remove PA bias and then flip the T/R relays from their TX position to their RX position (i.e. bypass position).
  • Monitor the levels of Vdd, Idd, Output Forward Power, Output Reflected Power (as SWR), and the PA Temperature, and display this informationon the Front Panel's LCD.
  • Monitor the Front Panel controls.
  • Monitor faults that are detected via hardware (Idd fault, Output Forward Power fault, Output Reflected Power fault, and LPF Input SWR fault) and immediately interrupt Vdd and remove the PA bias voltage if one or more faults occur.
  • Monitor faults that are detected via software and perform the appropriate action if they occur.
  • Change bands automatically if I change bands on my FPGA-SDR transceiver.
  • Control fan speed.
  • Generate a PWM waveform for driving an analog meter with the Output Forward Power level.

There are five schematic pages for this assembly.  Let's start with the first one.

Controller Schematic:

The Controller Schematic contains the Arduino Nano processor:

Notes on the Controller Schematic:

1.  The Arduino Nano is only powered by an external +5V supply (+5V_FP).  Its own on-board voltage regulator is not used.

2.  The three front panel LEDs connect to this board via connector J3.  Note that all three LEDs are driven with 2N7002 FETs, rather than by the Arduino, itself (which could certainly sink the current).  I do this to minimize the amount of current the Arduino must sink (and therefore the amount of current flowing through its ground pins), because the Arduino is actually mounted on a header, and I'm concerned that a non-zero current-induced voltage drop on the ground header pins, even if its minor, could slightly skew the analog ADC readings (which use the Nano's 1.1V reference).

So -- I've attempted to minimize the current that the Nano needs to sink or source, and thus minimize any unintentional voltage differential on ground between the Nano "sub-board" and the Controller board's ground plane.

3.  R25 pulls up the RX/TX line (forcing it into RX) in case the LED connector is not installed at J3.

4.  Similarly, R30 keeps U6.11 low if the jumper at J5 is not installed.  By the way -- installing this jumper will shut off Vdd to the PA whenever the amplifier is in Receive mode.  Currently the jumper is not installed.

5.  R26 holds the TX/RX line in RX mode during power-up when the Nano I/O pins might be in an indeterminate state.

6.  R27 performs a similar function, holding nBias_ON high (and thus cutting off bias voltage to the PA) while the Nano I/O pin is in an indeterminate state at power-up.

7.  R21/C10 is a simple low-pass filter to attenuate any unwanted incoming RF that might have been induced onto the external cable the RF field within the amplifier.

8.  C11 and C12 on the I2C bus provide a small amount of filtering, too.

9.  R18 parallels the piezo-buzzer per a recommendation I'd seen some years ago in a datasheet (TDK).  They'd recommended 1K ohms in parallel with the buzzer.  I'm using 2.4K, to cut down the current-draw a bit.

10.  J6 let me, during my testing phase, disable the hardware faults from cutting off Vdd.  For normal operation a jumper is installed at J6.

11.  Note that J3 has signal-returns on pins next to its signal pins.  It's always a good idea (from an EMI susceptibility perspective) to route a signal-return next to its signal.  This technique will minimize the signal's overall "loop area" and thus minimize induced noise from B-field induction.

12.  If any of the four fault signals that are inputs to U6A go high, then the TX_FAULT signal will go high (assuming a jumper at J6 is installed, which it should be), driving the DIG_VDD_OFF signal high, which then (at the Supervisory assembly) cuts off VDD to the PA.

IO1 Schematic:

Notes on the IO1 Schematic:

1.  The PCF8575C cannot drive signals high.  Therefore it requires pullups on its outputs.  This is a bit of an inconvenience, but the device makes up for it by being simple to control via I2C.

2.  The PCF8575's Interrupt pin (U1.1) is not used.  (At one time it was connected to the Nano, but there was a problem, as I'll discuss later in this blog post, in the Interrupt section).

3.  If J1 is jumpered it will take the "AMP_PRESENT_OUT" signal low if there is a TX Fault.  This signal goes to my FPGA-SDR transceiver.  My purpose here was to use a high-to-low transition on  "AMP_PRESENT_OUT" to force my FPGA-SDR to stop transmitting.  But I have not yet added this feature to the FPGA-SDR transceiver's software, and so no jumper is installed.  Maybe someday...

IO2 Schematic:

Notes on the IO2 Schematic:

1.  Lots of 1-pole low-pass filters on the signal lines at their connectors to attenuate any RF that might be induced upon the interconnecting cables by the PA's RF fields.  These filters are usually 100 ohms with 100 nF, but I'll use 33 ohms if I want to minimize DC voltage drop on the resistance (e.g. if this signal is driving a relay), or 10 nF if I don't want to slow down the edges of digital signals too much.

2.  Note that the signals on J8 and J11 have their signal-returns on adjacent pins to minimize EMI susceptibility (in the case of J8 these signal-returns are actually +12VDC, not ground).

3.  However, the rotary encoder's connector does not interleave signal-returns with signals.  But it's a fairly short cable, and induced EMI doesn't (yet) seem to be an issue.

IO3 Schematic:

Notes on the IO3 Schematic:

1.  Again, lots of 1-pole filters (100 ohm/10 nF, etc.) on signal lines at their connector end to attenuate any EMI induced on the interconnect cables from entering the board.

2.  Note that J12 also has TVS diode arrays on its lines.  These signals come from the "outside world" (i.e. my FPGA-SDR transceiver), and I'm a believer that signals from the "outside world" should have protection on them to shunt static-electricity discharges away from the circuitry that might otherwise be harmed by ESD.

By the way, the 100 ohm resistors between J12 and the TVS diodes, in addition to acting as EMI filters (with their caps to ground) for the signals attached via J12, also provide some amount of current limiting for the TVS diodes.

3.  12VDC comes from a DC-DC converter module that is mounted on the Controller Assembly board (but shown instead on the Power Supply schematic), and thus it is a natural EMI source (see examples of 150 KHz ripple here).  If I need to run +12VDC off the board I try to first run it through a ferrite bead to suppress, hopefully, some of its EMI.  Thus FB1 and FB2  (hmm -- I should have added a ferrite bead for the +12V to the LPF boards relays!).

4.  Again, note that signals at connectors have their signal-returns on adjacent pins to minimize their overall loop area and thus EMI susceptibility.

5.  The circuitry at the PA I/F (J6) turns on or off the +12V_SW bias voltage to the PA.  Its operation is straightforward:  if  nBIAS_ON is low (i.e. true, being a low-true signal) and TX_FAULT is low (i.e. false, being a high-true signal), then the U1.4 output is low, and Q5, Q4, and Q3 are all turned ON and +12 VDC goes to the bias circuitry on the PA board.

But if a fault occurs (TX_FAULT goes high), or if the Nano should command that bias be turned off (nBIAS_ON goes high), then the output of U1 goes high, turning off Q5, Q4, and Q3, thus shutting off +12V to the PA.

Fault Detect Schematic:

This circuit is a hardware-detect of fault conditions and thus much faster at shutting down the PA if a fault occurs than depending upon the Arduino software to first detect a fault and then shut down the PA via a software routine.  When it comes to protecting the FETs, faster is better.

For this PA project I've adapted the hardware fault detect circuit described in the 2011 (and other years) ARRL Handbook design, "A New 250-W Broadband Linear Amplifier" (an design well worth checking out, and also it was designed by the same engineer, Dick Frey, who wrote the Microsemi App Note I'm using).

Notes on the Fault Detect Schematic:

1.  If Idd exceeds a threshold determined by potentiometer R8, its comparator's output (U3.13) goes low, immediately setting the "FAULT_IDD" output pin on U2 high.

2.  If Output Forward Power exceeds a threshold set by potentiometer R17, its comparator's output (U3.2) goes low, immediately setting the "FAULT_PFWD" output pin on U2 high.

3.  If Output Reflected Power exceeds a threshold set by potentiometer R29, its comparator's output (U3.14) goes low, immediately setting the "FAULT_PREF" output pin on U2 high.

4.  And if the output signal from the Directional Coupler at the LPF filter goes positive and exceeds the threshold set by R11, its comparator's output (U3.1) goes low, immediately setting the "FAULT_LPF" output pin on U2 high.

5.  If any of U2's four outputs go HIGH, Vdd (and bias voltage) to the PA will be immediately cut off.

6.  U2's latches (i.e. the four hardware fault bits) are RESET using the front panel ENABLE toggle switch.  If the toggle switch is in its DOWN position, the PA is disabled and the U2 latches are held reset.  If the toggle switch is UP, the PA is enabled and the latches are free to be set if a fault is detected.

7.  Under normal operation the voltage at J2 from the LPF Filter's Directional Coupler's output should be negative.  But the LM339 inputs have a spec'd maximum negative voltage rating of -0.3 volts, so I added D1 to, hopefully, clamp the negative voltage and prevent it from going too low and affecting the operation of the LM339.

8.  R15 and C23 are a simple 1-pole low-pass filter to attenuate any external RF that might be coming in on the cable attached to J2 (for EMI protection I also use RG-174 coax for the cable between this connector and the Directional Coupler output on the LPF assembly).

9.  R27 provides a DC path to ground for the incoming signal at J2.  I've made it large so that it does not load down the voltage too much (it's a relatively high-impedance source at the other end of the cable).

10.  There's a note on this schematic page about removing diode D1 from the Nano board.  I had done this in an attempt to discover why, when I attached my laptop's USB port to the Nano, the Nano's ADC's 1.1V reference voltage changed slightly

I never did find the reason why the ADC reference changed.  And I left D1 off so that the Nano, when connected to my laptop via USB, did not try to power the Controller board if the PA Power Supplies were off.  But it could probably be left on the board, too.

Peak Detectors Schematic:

In my Automatic Antenna Tuner project I sampled Pfwd and Pref as fast as I could so that I could catch their peaks. 

For this project I decided to take a different approach and not worry so much about sampling quickly.

What I've done this time is to "peak detect" in hardware the Pfwd, Pref, and Idd signals.  The "peak detectors" are sampled fairly slowly (i.e. about 7 times a second) and, after they've been sampled, they are immediately reset, so that they can each detect a new peak over the next 150 milliseconds.

This means that I am capturing only peaks that occurred over the peak-detect period (150 ms), never minimums.  But I don't care what the minimums are; I care what the maximums are.  That's when things can break.

Notes on the Peak Detectors Schematic:

1.  The basic peak-detector circuit consists of a non-inverting op-amp, an NPN transistor emitter-follower at its output (that is also within the feedback loop) to source enough current to charge the peak-detect capacitor to the same voltage as the voltage at the op-amp's non-inverting input, and the peak-detect capacitor (2.2 uF in this case).

2.  These peak detectors drive the Nano's ADC inputs -- the ADC reference is (about) 1.1 volts, so these outputs should never be much above 1.1V (the 10-bit ADC will simply saturate at 0x3FF).  The voltage divider networks at the non-inverting inputs of the op-amps scale the input voltages down so that they are compatible with the 1.1V max of the Nano ADC.

3.  And because a peak-detector's output voltage is so low, there's no reason to worry about reverse breakdown of the base-emitter junction.  If the op-amp output goes to zero when, say, the 2.2uF cap has 1.1 volts across it, Veb would then be only 1.1V, and the transistor's Vebo spec is 6 volts.

4.  The two FETs in each sample-and-hold circuit reset the sample.  They both turn on (and off) simultaneously.

The FET at the output of the circuit discharges the 2.2 uF cap (through a 10 ohm resistor, so that there is some amount of current limiting), while the FET at the input ensures that the op-amp's output is zero while the output FET is discharging the cap.

Without the FET shorting the op-amp's input, then, if the input had a positive voltage on it, the output NPN would also have a non-zero voltage at its emitter.  If the output FET was then turned on to discharge the 2.2 uF cap, the NPN, having a non-zero voltage at its emitter, would attempt to source current into the FET (amount determined by the series 10 ohms resistor) and possibly prevent the 2.2 uF cap from completely discharging.

Front Panel Schematic:

I hope this schematic is self explanatory!

(Note: the Front Panel's AC Power Switch is shown elsewhere, in the Power Supply schematic).

The Build:

The Controller Board sits above the switching power supplies.

Here are the power supplies...

... now with the Controller board (assembly just started) mounted above the power supplies

Another view (the board has been completed):

To build circuits with tiny SMD parts, I use proto-boards designed for that purpose.

Here's a small board onto which I'm building the sample-and-hold peak detectors:

And I'm using a piece of this board:

Note that this board's 0.05" square spacing is just a bit too tight for 0805 parts.  The part spans across an entire pad, but unless exactly placed, a part's conductive end might short to this "spanned-across" pad as well as the pad next to it.

I get around this potential problem by using the hot tip of my soldering iron to remove the unused pads under the 0805 parts:

I also like to use double-sided PCB stock as a platform to build upon -- it provides an excellent ground plane (whose importance cannot be over-stressed).

There are a number of ways to install parts on the PCB -- dead-bug style is a popular method.  But, when it comes to DIP IC's and connectors with 0.1" spacing, I like to use a Dremel tool with an engraving tip to cut out pads.

Here's an example, showing the connector for the PA interface and the pads I cut upon which are mounted the 1-pole filters (for external EMI suppression) constructed with SMD R's and C's as well as the circuitry for +12V_SW (including SOT23 transistors):

I use a Dremel tool (with a Dremel Flex Shaft) and an engraving bit to create the pads:

Regarding the mounting of the Arduino Nano:

The Nano boards usually come with header pins attached (or attachable by the user).  The Nano board used here did not have these header pins attached, and so I instead attached two female header strips.

These female headers allow me to easily remove and replace the Nano board if, for some reason, I blow it up.  (This has happened to me before, and unsoldering 30 pins and/or wires/components from the Nano board's pins so that I could replace the board was not fun.)

I put female headers on the Nano for the simple reason that I did not have any surface-mount female headers that I could solder to pads on the Controller board.  But I did have surface-mount male headers, and I had female thru-hole headers, so the thru-hole female parts went into the holes on the Nano board and the surface-mount headers went onto the Controller Board, as shown, below:

Using a header like this means that the Nano's ground connects to the main Controller ground plane via two rather long header pins (plus the contacts on the female header). These will have non-zero resistance, and thus, if there is appreciable ground-current flow between the Controller board and the Nano board, there will be a voltage drop across these ground pins and thus a voltage differential between Nano ground and Controller ground plane.

Such differentials might be small, but they can cause errors in low-level ADC readings.

For this reason I prefer to drive high current devices (e.g. LEDs) not directly with the Nano, but with transistors that are on the Controller board, minimizing currents between the Nano's ground and the Controller board's ground plane.

The finished Controller board:

And the back of the Front Panel:

Notes on the Arduino Firmware:

Some quick notes on the Arduino Firmware...


I use one interrupt, and this interrupt is for the T/R signal from the transceiver.  All other inputs (including front panel controls), are polled.

When the interrupt occurs for a receive-to-transmit transition, the TR relay is immediately set to TX (from RX (i.e. bypass)), and then the interrupt routine waits 15.5 milliseconds for the relay to settle (per the relay settling specification of 15 ms max) before setting the nBIAS_ON output bit low, switching ON the 12V bias supply to the PA.

My FPGA SDR Transceiver starts generating RF 22 milliseconds after it transitions its TR control signal (to the PA) from Rx to Tx.

So the timing is:

1.  Receive-to-transmit transition detected by the PA Nano's Interrupt Routine (call this time 0 milliseconds -- it is our timing reference point).

2.  The Interrupt Routine commands the TR Relay to flip to its Transmit position (assume the time is essentially +0 ms).

3.  Time for the Relay to flip and settle down, per the relay specification, is 15 ms, so time is now:  +15 ms.

4.  At 0.5 ms after the max time for relay settling, the Interrupt Routine sets the nBIAS_ON bit low, turning ON PA bias.  Time is now +15.5 ms.

5.  At 22 ms after the initial transition TR transition from the FPGA SDR, RF appears at the PA's input.

When the FPGA SDR Transceiver is finished transmitting (PTT or CW key released), its output RF (to the PA) will go to zero.

Then, after the amount of time equal to the FPGA SDR's "HOLD" time, the TR control transitions from Tx to Rx.  (I've set this HOLD time to 200 ms, so, after I release PTT or my CW key, the FPGA SDR will wait 200 ms before transitioning its TR control (to the amp) to Rx.  During this 200 ms no RF is being generated.

At the PA, the interrupt routine for this transmit-to-receive transition, when it is detected,  simultaneously turns off the PA's bias voltage and flips the TR relay to RX.  (The relay shouldn't react immediately, so doing both simultaneously should be OK).  Note again -- when these two actions occur, RF has not been applied to the amp for 200 ms.

NOTE:  for some reason the software crashes if I try to read the PCF8575 from within the interrupt routine, which squelched my plans for using the '8575 interrupt pin to force an immediate read of the device, and thus the reason why the external T/R signal is now the only interrupt.

Polled Inputs:

Apart from the interrupt just described, all other inputs are polled.

ADC inputs:

Five analog signals can be converted to digital by the Nano's ADC.  These signals are:

  • Idd
  • Vdd
  • Output Forward Power
  • Output Reflected Power
  • PA temperature.

The ADC uses the Nano's 1.1V reference.  But note that this 1.1 volts is not exact, and it can vary from Nano to Nano, so be sure to calibrate to the ADC reference of a particular Nano board.

NOTE:  When I attach my laptop's USB cable to my Nano (for code downloading and debugging), the ADC 1.1V reference's voltage changes a little bit in voltage -- not much, but it's enough to create a noticeable shift in the data being converted.

Analog Conversion:

To convert Idd, Pfwd, and Pref digital ADC values back into the values that they actually represent (current and power), I captured the ADC values while varying Idd, Pfwd, and Pref.  I then plotted these in Excel and used Excel to create linear equations representing the plots.

Using these equations, I can then map sampled ADC values into actual Idd, Pfwd, and Pref values.

Here are some examples of these plots and their Excel-derived equations:


And thus the Nano calculates Idd with the following equation:

  idd = (float(adc_idd) * IDD_SLOPE) + IDD_INTERCEPT;


(Note: I plotted "Pfwd vs ADC" and "Pref vs ADC" band-by-band, just in case there was a variation over frequency):


Note that the Pfwd and Pref analog input voltages represent power in dB (because the AD8307 is a log detector).  I calculate the dBm level for each of these signals using the slope and intercept values from the equations shown in the graphs, above:

    Pf_dBm = (float(adc_pfwd) * pfwd_slope) + pfwd_intercept;
    Pr_dBm = (float(adc_pref) * pref_slope) + pref_intercept;

And then I can convert to watts:

    pfwd = 0.001 * pow(10,(Pf_dBm/10.0));
    pref = 0.001 * pow(10,(Pr_dBm/10.0));

Return Loss and SWR are calculated as follows::

    rl = Pf_dBm - Pr_dBm;
    swr = ((pow(10,(rl/20))+1)/(pow(10,(rl/20))-1));

Lots of floating point math!  But I'm in no rush.


The Nano creates a PWM output signal for driving the analog power meter.

Peaks are held for 2 seconds, and then I decay the meter down at an exponential rate whose time constant is 300 ms.

  if(meter_state == DECAY){
    temp_delta_ms = now_time - decay_start_time;
    temp_float = float(temp_delta_ms);
    Pmeter = Pmeter_pk*pow(2.72,-temp_float/TIME_CONSTANT);

(Meter scale designed using a MATLAB routine written by Dick Benson, W1QG).

Auto Fan Speed Control:

There are four fan speeds.  These speeds can be controlled either manually, by the user, or automatically, by the Nano.

If the Fan Speed control is set to "Automatic," the Nano will use the PA's temperature to set the fans to one of four speeds.

This control has hysteresis, so, if temperature is rising, the fan speed will increase, for example, at temperature "A", but once the fans are at the new speed and if the temperature starts falling, the fans won't shift back down in speed at temperature "A".  Instead, they'll shift back down at a lower temperature.

There are four fan speeds:  SLOW, FAST, FASTER, and FASTEST.  The 'defines' below define the temperatures at which fan speeds shifts occur.

// Fan speed thresholds
#define SLOW_UP     37         // degrees C, equals 98.6 degrees F
#define FAST_UP     43         // 109.4 degrees F
#define FAST_DN     34         // 93.2 degrees F
#define FASTER_UP   48         // 118.4 degrees F
#define FASTER_DN   39         // 102.2 degrees F
#define FASTEST_DN  44         // 111.2 degrees F

For example, we won't transition from SLOW to FAST until the temperature reaches 37 degrees C.  If the temperature then starts falling, we won't transition back to SLOW until it has dropped from 37 to 34 degrees C.

If the temperature gets too high, software will declare a "temperature" fault, shutting down the PA and preventing further transmitting until it has cooled.  I've defined this maximum temperature to be 55 degrees, and I don't re-enable transmit until the temperature drops to 52 degrees C:

// Temperature Fault Limits:
#define MAX_C       55         // At this temp (131F) disable Transmit
#define OK_C        52         // At this temp (126F) re-enable XMIT

A final caveat regarding these temperatures -- I don't know if these are the best thresholds to use.  As I use the amp and I discover how PA temperature responds to various operating conditions, I may change some or all of them.  But they're a start.


Notes on the LCD Display and User Interface:

1.  The LCD is 4 lines by 20 characters.

2.  The Amplifier has two control modes, Automatic or Manual.  This mode is displayed on the LCD as either "Auto" or "Man." in the display's upper left-hand corner.

In Auto Mode, band selection and T/R is controlled by my FPGA-SDR transceiver when it is attached to the PA via an RJ45 cable.

If my transceiver is not attached, the Amplifier is, by definition, in Manual mode.  In this mode the T/R input is the RCA jack on the back panel, and the band is selected manually using the Rotary Encoder.

3.  The PCF8575 field on the LCD shows that state if its 16 bits, in hex.  I put it on the LCD for debugging, and I haven't had a good reason to remove it.

4.  If there are no faults, the "Fault Annunciators" field will display "------".

If every fault were to occur, this field would be:  "vtLRFI", where these letters represent:
  • v = Vdd Fault (i.e. Vdd below 58 Vdc).
  • t = PA Temperature Fault (i.e. Temperature > 55 degrees C)
  • L = Low-pass Filter Fault (e.g. wrong filter selected).
  • R = Reflected Power Fault (Reflected power at the output is greater than about 60 watts (i.e. 2:1 SWR when FWD power is 500 watts)).
  • F = Forward Power Fault (Forward power at the output is greater than about 600 watts).
  • I = Idd Fault (Idd is greater than about 22 Amps).
Note that the L, R, F, and I faults are all hardware triggered (and thus will immediately shut off Vdd), while the v and t faults are software polled.

Here's the display with all but the temperature fault triggered. This usually happens at power up when I've left the "ENABLE" toggle switch in the UP position and then turn on the AC power.  It's caused by the four fault latches not being reset at power up -- toggling the ENABLE switch resets them and everything is then copacetic.

5.  The LCD is updated at about a 7 Hz rate.  This is fast enough to let me see fields changing, but not so fast that they become a blur.

Also, both the Idd and the Pfwd fields are "peak hold" fields.  That is, so that I can more easily see what peak power and peak current are, I'll hold these values on the display for 2 seconds (unless, of course, a new peak occurs during that interval).

LCD Debugging Menus:

Clicking the Rotary Encoder will invoke my Debug Menus, which I can then scroll through using the rotary encoder.  The Debug Menus are:

Debug Menu 1:  TX & Bias:

I use this menu for adjusting the PA's bias pots.  Idd is displayed in the lower right-hand corner (and it is not peak-held in software for this menu).  And the ENABLE toggle switch, if toggled up, will force the PA into its Transmit state, turning on the bias voltage and allowing me to measure, and adjust, Idd bias current.

Clicking on the Rotary Encoder exits Menu mode and returns me to the normal LCD display.

Debug Menu 2:  Fan Speed

When I enter this menu the current fan-speed is shown in parentheses (in this example, the fan speed is selected Automatically, based upon temperature).

Clicking on the rotary encoder then allows me to use the rotary encoder to step through the five fan speed (Auto, Fastest, Faster, Fast, and Slow).  Clicking again on the rotary encoder will make the fan speed that is currently displayed the new fan-speed.

Debug Menu 3:  Pwr ADCs

This menu displays the Pfwd and Pref ADC readings.  I found that the ADC values will typically vary by a few counts, and so I also capture the peak-readings of this variation, which is displayed in the right-hand field.

I can then reset (i.e. zero) the peak ADC readings by clicking on the rotary encoder so that they can be determined anew.

Debug Menu 4:  Idd ADC

This menu displays the current Idd ADC value as well as its peak value.  The peak value can be zero'd (so that the peak-value determination can start anew) by clicking on the rotary encoder.

The peak ADC value is also used to calculate and display the peak Idd current, in Amps, in the lower right-hand corner.

Debug Menu 5:  Vdd ADC

This menu displays the current and the "peak" values of the Vdd ADC readings.  The "peak" value can be reset by clicking on the rotary encoder.

Debug Menu 6:  Efficiency

This menu displays the amplifier's efficiency.

Because there is naturally a small amount of variation in the Idd and Pfwd readings (e.g. +/- 1 count), I calculate efficiency (in percent) as:  (pkPfwd / minPdc) * 100, where minPdc is the minimum DC power (Idd & Vdd) over the measurement period, and PkPfwd is the maximum Forward Output Power over the same period.

These peak and min measurements can be cleared by clicking the rotary encoder.

Debug Menu 7:  DegC ADC

This menu displays the ADC reading from the temperature sensor on the PA's heatsink.

Debug Menu 8:  OvrPwr Beep

The internal buzzer can "beep" if I exceed a software-defined output power threshold (currently defined as 550 watts), which can sometimes happen on voice peaks.  This threshold warns me that I might be approaching the danger zone of PA shutdown if output power goes higher.

This menu let's me turn the beep on or off.

Debug Menu 9:  PWM

This menu let's me manually set the PWM value (between 0 and 255) that drives the meter.

The rotary encoder let's me change the value, but it changes in increments of 42.5 (i.e. 255/6 ), which is then rounded up when necessary to give an integer value.  These values should then step the meter's needle from 0 to 600 watts in 100 watt increments, allowing me to check its accuracy.

And that's the end of this blog post.  Continue on to the other posts in this series via the links, below...

K6JCA HF PA Posts:

Standard Caveat:

I might have made a mistake in my designs, schematics, equations, models, etc.  If anything looks confusing or wrong to you, please feel free to leave a comment or send me an email.

Also, I will note:

This design and any associated information is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without an implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.