Antenna Auto-tuner Design, Part 9: Build, Phase 3: Incorporating a Microcontroller

Finally!  I've integrated a microcontroller into the design and the tuner can now tune automatically.  In other words, the Tuner is essentially finished!  (Software development, though, will probably continue without end).

This blog post describes design and implementation of this final block: the microcontroller and its interface circuitry.

The previous blog post, in which match-detection is incorporated into the design, can be found here:  http://k6jca.blogspot.com/2015/12/antenna-auto-tuner-design-part-8-build.html


Which Microcontroller to Use?

During this entire build I'd been planning to use a PIC processor as the system's microcontroller.  In the past I'd designed it into hardware for a few commercial products, but I had not programmed them, so I was approaching the anticipated (and unknown) software task with a bit of trepidation.

To get started with the effort, about a month and a half ago I ordered a "demo" board (PICkit 44-pin Demo Board with PIC18F45K20) to use as a development platform.  And it was right around this time that I serendipitously received an email from Graeme Jury, ZL2APV that changed my direction.  He had been working on an automatic tuner of his own and was in the process of writing the software, but he was using an Arduino processor.

Well, I'd heard of the Arduino.  In fact, much earlier in the year I'd purchased the ARRL's book, "Arduino for Ham Radio".  I had glanced through it after it arrived, but then it went onto the bookshelf and over the following months I forgot about it.

I learned from Graeme that one advantage of the Arduino platform was the variety of different pre-assembled boards (often quite inexpensive) that one could purchase.  This could simplify implementation.

Also, Arduino programming is in C, with quite a bit of open-source code available, and there is a large group of users who actively post (and answer) questions on the Arduino forum.

One specific concern I'd had going into this design was writing the code to measure frequency.  I knew that a PIC could measure frequency, but I was hoping that I wouldn't have to write the frequency-capture code in assembly (which would be a learning curve of its own), and I didn't know if there were any pre-existing frequency measurement code for the PIC that I might be able to use instead of "rolling my own."

When Graeme mentioned the Arduino, I did a quick internet search and discovered that there were several open-source frequency-measuring routines for the Arduino.

So I pulled the ARRL book from my bookshelf, blew off the dust, and read it more closely.  Looked pretty straightforward, and so I thought, why not give an Arduino a try?


The Arduino Nano

Arduino can be purchased in a number of hardware configurations.  Due to space-constraints, I chose the Nano platform and placed an order.  It arrived just after Christmas, about a month ago:

Merry Christmas!

I also ordered a 16x2 LCD with integrated I2C interface.  When it arrived I connected the two together and wrote my first bit of code:

(From little acorns...)

I had a few minor stumbles bringing up the Nano, but all resolved fairly quickly.  Specifically, they included selecting the proper COM port on the computer, discovering the I2C address of the LCD (this one's is 0x3F -- I had to download an I2C bus scanner "sketch" (Arduino's name for a program)), discovering that I needed to adjust the LCD's contrast pot before I could see anything, and finally, tracing down a problem in which only the first character of a string was shown on the LCD (I needed to update the IDE's LCD routines with the latest versions).  But, with the help of google and the Arduino forum, these start-up issues were quickly overcome.

Before I got too far into the programming, though, I wanted to verify that the Arduino could actually measure frequency (a prime requirement which would determine my processor choice), so I tested a couple of Frequency Counter routines.  The one that, to me, seemed to work the best was FreqCounter, available here and at GitHub here.

Note, the Arduino cannot directly measure frequency over my application's entire frequency range.  Clock resynchronization within the ATmega328 limits the counter's upper frequency to Fosc / 2.5 (per Atmel's datasheet).  Assuming the processor is running at 16 MHz (Fosc), then the upper frequency applied to the counter's input should be no more than about 6.4 MHz.

But not a problem.  If I divide the RF by 8, then the highest frequency the counter's clock should see is 3.75 MHz (i.e. 30 MHz / 8).

It looked like the Arduino could do the job.  Now it was time to design some hardware...


Schematics:

Again, schematics were drawn with the free version of Orcad.  Because of parts-count limitations imposed on designs when using this free version, the overall Microcontroller design is broken up into multiple projects, rather than integrated together into one design.  So, unfortunately, Orcad's design-rules checker cannot verify the entire design, and thus there could be errors in my drawings.  Also, portions of the design might be located on other pages from those where they should most logically have been placed, to comply with this parts-count-per-design limitation.

Schematic, Arduino Main:

(Click on image to enlarge)

Notes on the Arduino Main schematic:

1. I do not use Arduino's on-board 5V regulator -- I was concerned about its heat-sinking, given the loads I would be attaching to it.  So instead, 5V is generated elsewhere and fed into the Nano's 5V pin (it is OK to back-feed the NANO's on-board regulator this way).  The Arduino's 12V In pin is left floating (but it is RF bypassed to ground).
2. The FreqCounter routine uses pin D5 of the Arduino, so that's the pin into which I apply the frequency-sample signal.
3. The frequency sample (which is the RF frequency divided by 8) arrives on the Microcontroller board from an off-board RF Frequency Sampler circuit.  It is buffered on this board by U4, a Schmidtt-trigger inverter, that serves several purposes:  first, being a Schmitt-trigger, it (in theory) should be less sensitive to noise that might be coupled onto the RF_FREQ/N signal as it travels from the Tuner's RF compartment to the Microcontroller board.  It also provides a bit of protection between the outside world and Arduino, for although the RF_FREQ/N signal could directly drive the Arduino Nano input, if something went wrong with this signal I'd rather have it blow up this single inverter rather than take out the Nano board.
4. Strictly speaking, R7 and C73 aren't needed, but I'm so used to adding a small bit of high-frequency roll-off to clock signals (for emissions compliance in other products I've designed) that I feel weird not including it.  So not needed, but there they are!
5. I have a fear of high-power RF in such close quarters coupling into the wiring connected to the microcontroller circuitry and causing flakey processor operation, so there is much capacitor bypassing used in this design. One (inexpensive) technique I like to use to mitigate such "susceptibility" issues is to filter digital I/O signals with simple one-pole filters created with a small series resistor and a cap to ground.  So you will see 100 ohm resistors with either 100 nF or 10 nF caps to ground sprinkled throughout this design.  I try to place these filters where the I/O signals exit or entire a shielded area.
6. The Nano has an on-board Reset button, but with the Microcontroller board installed in the tuner chassis I would not be able to reach it, so I brought the Reset signal to a 2-pin header that would be easily accessible when the Tuner's cover was off.
7. But RF-bypassing Arduino's Reset line can create a problem.  As I unintentionally discovered, simply adding capacitance across Reset to ground can screw up Arduino.  Arduino uses a series 100 nF cap from an IO pin on their comm IC to drive the Arduino's Atmel processor into reset, and if capacitance-to-ground is added to the Arduino's Reset pin, the reset-voltage driving this pin will be reduced by the ratio of these two capacitors.  So, I've limited C36 to 10 nF, which is a factor of 10 times smaller than the 100 nF series cap on the Arduino board, and there shouldn't be a problem with its inclusion for RF bypassing.
8. Q13 provides a bit of isolation between the +5V on the microcontroller board and the +5V going to the RF divider in the RF compartment, just in case there's a "back-current" from the RF Frequency Sampler due to action of its protection diodes (see further discussion, below).
9. The SW_5VDC is used to disable the Microcontroller's drive to the relays when the Tuner is in Bypass or Manual mode.  This technique is discussed in more detail with the next schematic, below.
10. And strictly speaking, Q11 isn't needed -- Q8's base could be driven directly (through a series-R) with a low-true signal from the Arduino, but I'd added Q11 with the thought of driving Q8.base with a second signal, and although I decided that the second signal wasn't needed, I didn't remove this transistor.
11. A VTEST port was added so that I could calibrate the A/D conversion process by connecting an external DC voltage to this port and checking the A/D's measurement accuracy.
12. The buzzer is a TDK piezoelectric buzzer, p/n PS1240P02CT3 (available from Digikey).  Per the TDK datasheet, they recommend a resistor be placed across the buzzer (e.g. 1K).  I used a 2.4K value, deeming it close enough and wanting to reduce the current-draw a bit.  (By the way, the buzzer is very useful to alerting me to error conditions, etc.)

Schematic, IO Expander 1:

(Click on image to enlarge)

Notes on the IO Expander 1 schematic:

1. U1 is a PCF8575C I2C IO expander IC.  It has 16 bidirectional IO bits.
2. The PCF8575C outputs cannot drive high -- they must rely upon pullups to bring the output voltage up (although an internal current-source on each of the output pins will briefly source current to help charge capacitance on the output lines).
3. Thus, the 2.4K ohm pullups on the relay-driver lines.  These relay-driver signals are elsewhere diode-or'd with the signals from the rotary switches to turn ON, when high, the 2N3904 transistors which drive the relays.  The value of 2.4K assures that there will be enough base drive into these transistors to drive the transistors into saturation, even if the relay voltage is at 17VDC and the transistors are at their minimum Beta (assuming a minimum Beta of 60 and Relay Coil resistance of 360 ohms).
4. The 2.4K pullups are connected to a switched-5VDC line rather than the 5V bus.  Because of the diode-or'ing of relay control signals, when in Manual (rotary-switch control) mode, this voltage is switched OFF so that these signals all drop to 0 volts and thus won't drive the relays in parallel with the rotary switches.  Much less power is used when the drive to the relays is turned off in this fashion than if I'd instead, via software, written zeroes to all 16 bits and kept the pullups connected to +5V (which would mean an extra 33 mA from the +5V supply, sinked by the '8575C outputs, whenever I was in Manual mode).  
5. Note:  PCA9535 IO expanders can be used in lieu of the PCF8575 expanders -- their outputs don't require pullups.  But their software interface is a bit more complicated (there's an additional command word), and so for the sake of software simplicity I used the PCF8575 devices.
6. The nybbles of the inductor and capacitor relay-control bytes are arranged to make circuitry wiring convenient, rather than for the convenience of software.
7. There's an I2C EEPROM on board.  This was included in case I needed additional non-volatile memory above the 1024 bytes available on the Nano board (1024 bytes if the Nano uses the Atmega328 processor).  At this moment, I'm not using this external EEPROM.
8. Relay drive signal rise and fall times, measured at the relays themselves, are quite fast and well under 1 msec.

Schematic, IO Expander 2:

(Click on image to enlarge)

Notes on the IO Expander 2 schematic:

1. The I2C bus needs some sort of pullups, and they are included in this schematic.  Although the LCD module has pullups on it, if this module isn't connected to the microcontroller, the Arduino's I2C interface won't work.  So the microcontroller board has its own pullups.
2. Again, RF bypassing using series 100 ohms and caps to ground to attenuate RF that might be conducted to the board via external wiring.
3. Note that the PCF8575C on  this page has a different I2C address from the previous PCF8575C.
4. My original design had two output control signals, /TUNE_RLY and /DIS_AMP_RLY, meant for future, yet-to-be-defined uses.  After I built my FPGA SDR Transceiver I decided I wanted to use these two pins to communicate with the FPGA SDR, so that the SDR could send the transmit frequency to the ATU without first having to generate RF.

Schematic, Series-C Display:

(Click on image to enlarge)

Notes on the Series-C Display schematic:

1. These four LEDs visually show how much series-capacitance has been selected.  See additional notes on schematic.

Schematic, ATU-SDR Interface:

(Click on image to enlarge)

Notes on the ATU-SDR Interface schematic:

1. The interface consists of two signal: data-in and clock-out.
2. Rather than connect the 8575 pins directly to the cabling that will go to the SDR, they are buffered with 2N7000P inverters.  My thought here is that, if some destructive external ESD event were to couple onto the external ATU-SDR Interface signals, it would only "smoke" the 2N7000P device(s), which are much easier to replace than the 8575 IO Expander.
3. The clock and data at the 8575 are defined to be high-true, therefore the signals at J15 are low true (and thus the "n" as the first character in each signal name at J15 -- this is how I usually identify if a signal is low-true rather than high-true).
4. To help prevent blowing the 2N7000P transistors, 100 ohm resistors (in-line at J15), in conjunction with the TVS clamps, help to mitigate the effects of static discharges (the TVS devices clamp, while the 100 ohm resistors limit current).
5. The same 100 ohm resistors, in conjunction with 10 nF caps, filter external RF from coming into the circuitry -- i.e. they mitigate susceptibility to external EMI coupled into the circuit via cabling attached to J15.
6. For more information on this ATU-SDR interface, please go to this FPGA SDR page: http://k6jca.blogspot.com/2017/10/an-fpga-sdr-hf-transceiver-part-11.html

Schematic, RF Frequency Sampler:

(Click on image to enlarge)

Notes on the RF Frequency Sampler schematic:

1. The RF sampler directly samples the RF being applied to the Tuner's input to provide frequency information for the Arduino.  It is not part of the Microcontroller board, but is instead a separate sub-assembly.
2. An inexpensive inverter (74LVC1G14) does this sampling, converting the RF to a digital signal whose frequency is then divided by 8 by U1, a 4-bit counter.  This divided-down signal is then sent (via a short length of RG-174 50-ohm coax) to the Microcontroller board for frequency measurement.  For example, if the RF is at 30 MHz, Arduino should see a 3.75 MHz signal.
3. Strictly speaking, R6 and C6 aren't needed (but I have a habit of rolling off clock edges, see explanation earlier in this post).  However, I recommend some high-frequency roll-off of the divide-by-8's output signal (as provided here by R4 and C4) if driving it a "long" distance to an unterminated input, to minimize reflections that might cause ringing and possible false-clocking.
4. Because the peak RF voltage at the input of the Tuner could be very high (for design purposes I'm assuming 1000Vpeak), this voltage must be attenuated before it's applied to the input of inverter.
5. At RF, attenuation is accomplished via a capacitive voltage divider formed by C1 and the inherent capacitance of the various 1N4148 protection diodes (attenuation is very roughly 20 dB).  The 1 pF cap, C1, flattens the divider's response over frequency.  Without it, attenuation is much higher at higher frequencies.
6. R1, R2, and R5 are each 1/4 watt axial resistors which provide a direct DC path to ground.  R1 and R2 will also current-limit low-frequency signals (non-RF) strong enough to forward bias the protection diodes.
7. The diodes provide voltage clamping to ensure that whatever voltage applied to the input of the inverter does not exceed its input-voltage specifications.
8. The 74LVC1G14 Schmitt-Trigger Inverter's input only has a clamp diode from the input to ground (to clamp negative peaks).  There is no clamp diode from the input to the Vcc rail!  And per the datasheet, the input must not go above 6.5 Volts (irrespective of the actual value of Vcc).
9. I've added external diodes to limit input voltage peaks.  D2 limits the negative peak, and, although D1 can provide positive-peak limiting, I prefer to use the diode-string of D3-D8.  This is because, if D1 provides the positive-peak limiting, it is shunting RF current onto the +5VDC bus, which could raise the voltage on this bus (if its impedance is too large with respect to this current) and thus possibly create unwanted and unintended consequences (it is for this reason that I've also added extra 100 nF caps to this assembly's +5V power).  So consider D1 backup to the operation of D3-D8.
10. The 1N4148 diodes have a "Recurrent Peak Forward Current" absolute maximum rating of 400 mA (and an absolute maximum rating of 300 mA for DC Forward Current). 
11. Somewhere around 3 watts of applied power (into a 50 ohms load) is required to get an accurate frequency reading.  If the load is low impedance, more power will be required.

Here's an image showing the clamping provided by D3-D8.  The bottom trace is the input to the inverter, clamped by the diode clamps, and the top trace is the inverter's output.  Note that with the string of 6 diodes, the input is limited to 4V, peak:

Schematic, Other Controls:

(Click on image to enlarge)

Notes on the Other Controls schematic:

1. This is a revised schematic (revision now X2) of the schematic originally posted here.
2. I added an extra control line to the Arduino (AUTO), and removed some unnecessary components, having placed them instead on the Microcontroller board (e.g. the pull-down resistors).
3. I have also added the five new push-buttons.
4. And rather than have Arduiono control the /RLY_NORM/BYPASS signal, I simply diode-or the AUTO and the MANUAL signals to turn ON the 2N3904 transistor.

Schematic, Directional Coupler:

(Click on image to enlarge)

Notes on the Directional Coupler schematic:

1. The two 100 nF caps that had been connected across each AD8307 output to ground (for RF bypassing) have been removed.  Coupled with the internal 12.5K ohm output resistance of the AD8307 devices, they each had formed a pole whose cut-off frequency was roughly 130 Hz, which is much too low if one of my goals is to also measure peak power.  With them removed, the corner-frequency is now determined by the 1 nF feedthru caps, which shift the poles of the two outputs from about 130 Hz to about 13 KHz.

Schematic, Return Loss:

(Click on image to enlarge)

This schematic has changed due to a design error on my part.  At high input powers, U2A's "Input Common-Mode Voltage Range" specification can be violated.  As it turns out, for the specific LMC662 part that I've used on this board (I measured its "Input Common-Mode Voltage Range" and it is 3.6V), this would occur when input power is above 1 KW.

But, per the LMC662 datasheet, the typical value for this parameter is  (V₊ - 1.9V), or 3.1 V for 5V power, and over temperature this value decreases to about 2.5 VDC.

So with the original design and an applied RF-power of 100 watts, the voltage at U2 pin 3 would 3 volts (U1.1 is 4.0 volts) -- significantly above the worst-case spec of 2.5 V and uncomfortably close to the "typical" spec of 3.1 V.  Not a good design.

Better that the spec not be violated under any conditions, for when this spec is violated, an op-amp will no longer behave like an op-amp.

But the fix is simple -- if I change the voltage-gain of the differencing amp, U2A, from 3 to 1, then, if  one KW of RF power were applied to the tuner, the voltage at U2 pin 3 would be 2.25 VDC (given that the voltage at U1.1, by design, is 4.5VDC for 1KW of applied power).  And 2.25V is under the LMC662's worst-case spec for "Input Common Mode Voltage Range."

In other words, I can meet the specification if I just change R15 and R17 from 10K to 30K ohms.

And to get back the gain of 3 that I need for the Return Loss voltage, I've made use of the previously-unused op-amp in U2's package and given it the task of amplifying the differencing-amp's output by 3.

Again, a very simple change to make.  Just add two resistors and a cap to the unused op-amp and wire it into the circuit.  Done!


OK -- on to the build!


The Build:

The first question I had to answer -- how large should the Microcontroller board be?

I planned to mount it on the grounded chassis bulkhead, in the open area to the left of the power transformer. 

Because there so many wires passing between the RF compartment (where the relays are) and the front-panel compartment (where the Microcontroller mounts), I added header strips to allow me to easily attach and remove the front-panel.  Each pin of the header strip is bypassed to ground with a 100 nF cap an 0805 package (to bypass RF that might be conducted on the wiring from the RF compartment). The one exception to this bypass-cap rule is the divide-by-8 frequency pin from the RF Frequency Sampler.

NOTE: neither these header-strips, nor their bypass caps, are shown in the schematics.

Here are front and back images of the Microcontroller board.  Note that the PCF8575C devices in SOIC packages, and so I used 28-pin SOIC proto-boards (although the devices are 24-pin -- these were the boards I had on hand) so that I could mount them to my vector-board.

Almost all components are surface-mount.  One exception is the 2N2907 used to switch on and off the 5V_SW voltage..

For purposes of documentation (and my memory), here's a diagram showing the locations of the connectors:

Here's how the board mounts:

As I've mentioned earlier, one huge concern I've had is the effect of nearby high-power RF energy on the operation of the microcontroller electronics.  Usually I solve susceptibility issues with ground-floods on PCB top and bottom layers and simple (and inexpensive) stamped-metal shields over the sensitive electronics while simultaneously low-pass filtering signals that pass under the shields from the outside world.  But this tuner is a "one-off" project, not something designed to ship in quantity, so no PCB with its convenient ground floods and no stamped-shields (and their associated tooling charges).

Instead, I shielded the board with copper tape from my bin of, well, copper tape.

Kapton tape (and on the underside of the board, where the sharp connector-pin points are, an additional layer of cardboard), keep these shields from shorting-out the electronics.

Here's the process for the top-side of the board.  First, apply the Kapton tape:

Then add the copper tape, soldering it to the board's ground at as many points as possible (e.g. the four corners and points between).

You might be able to make out the slit I cut in the copper to reveal the Nano's LEDs. Also, the open area at the right is left empty because the back of the front-panel meter fits into this area.

Here are two shots of front and back shielding:

Here's the build of the RF Frequency sampler (shot while I was bench-testing it).  That "large" chip is the 4-bit counter used to divide the RF frequency by 8..

And here's an image showing the RF Frequency Sampler mounted in the chassis:

(Click on image to enlarge)

Finally, I needed to replace the two panel meters (that I'd intended to use to show tuning Resistance and Conductance) with the new LCD, requiring that I construct a new front panel and make a new panel overlay for it.

Again, the panel was cut from a piece of scrap PCB stock, and I made the overlay per the method described here:  http://k6jca.blogspot.com/2009/12/how-to-make-your-equipment-look-like.html

Here's the result (with no RF applied):

And here's how the display looks, with RF, after it's been tuned:

Decoding the display:

Top Line, starting from the left:

• "Am" means Automatic Tune mode, Manual Arm (must first be armed by pushing the Auto/Arm toggle switch down momentarily before it will trigger).  If the Auto/Arm switch is in its UP position, the display will instead show "Aa", meaning Automatic Tune mode, Automatic Arm (automatically arms itself and triggers if the SWR is above a pre-defined limit (currently set to 1.5:1)).
• "LC" means LsCp configuration (versus "CL" for CpLs).
• "L04":  Ls setting is 0x04.  This value is also displayed in the LEDs to the left.
• "C08":  Cp setting is 0x08.  This value is also displayed in the LEDs to the left.
• "B80":  80 meter band.  Sets Cs, the Series-capacitance.  This can be manually set, using the up/down push-buttons, or it can be set automatically, if there is enough applied power to provide Arduino with an accurate frequency reading.

Bottom Line, starting from the left:

• "3.865":  Frequency, in MHz.
• "p 49":  Power, measures 49 watts.
• "<1.1":  SWR, reading better than 1.1:1.

Note, the bottom line can also display power in terms of dBm and Return Loss (as dB) in lieu of SWR.  This option is selected via an LCD sub-menu (selected via push-buttons).  Sub-menus include:

• Select Peak power display versus Instantaneous power.
• Select a display of Power in dBm and Return Loss in dB, versus Power in watts and SWR.
• Store the current L-network setting in Arduino's EEPROM.
• Recall the L-network setting from Arduino's EEPROM and apply to the L-network (these are automatically recalled and applied at power-up).
• Scroll through and display the contents of Arduino's EEPROM (1024 addresses).
• Erase the contents of Arduino's EEPROM
• Display the actual "raw" RF frequency being measured by Arduino and the value it is "corrected" to.
• Display the raw ADC values for Vrl, Vf, Vr, and Vtest.
• Calculate a compensation value for the ADC. (Attach 4.800 VDC to the Vtest pin and measure.  In a perfect world (ADC reference equal to 5.000 VDC, etc.), the ADC should measure 0x3D6.  If not, use the measured value to calculate a compensation factor.)
• Turn on the relays, one at a time.  (Allows me to find faulty relays and/or connections by listening for their click when they turn on.  Note that this method doesn't work if you turn off a relay at the same time you are turning another one on.)

A Few Software Notes:

Burning the midnight oil...

The Top-loop and Peak Power Measurement:

There is no hardware "peak-hold" in this design.  So, if a display of peak-power is desired, Arduino must sample Vf very frequently if it hopes to capture a voice-peak.  This task defines the fastest loop in my code and it runs at a loop-speed of about 120  microseconds, thus sampling Vf at an 8 KHz rate.

This fast-sampling loop is shown in red on the left-hand side of the flowchart below, and it is part of the overall top-loop.

(Click on image to enlarge)

But I cannot spend all of my time in this sampling loop, looking for peak power.  Periodically I need to check the Return Loss, run the tuning algorithm and update the relays, read and debounce the front-panel switches, get the RF frequency, and update the LCD.  So after a fixed number of passes through the fast-sampling loop, I pop out and check if I should be taking care of other house-keeping tasks.  (Currently I pop out after 8 passes through the top-loop -- i.e. about once a millisecond).

These other tasks are shown at the right-hand side of the flowchart.

(Strictly speaking, I don't need to set a flag at one point in the code and then check for it later to see if I should call the necessary routines -- I could just call the necessary routines in lieu of setting a flag.  But setting a flag and checking for it allows me to interleave tasks and use the same flag at different points in the code, as is illustrated by the "22ms_flag" use in the flowchart above.)


Frequency Measurement:

As described above, the RF frequency is divided by 8 before it arrives at the Arduino, so the highest frequency that Arduino will see at its D5 pin is 3.75 MHz, assuming a 30 MHz RF signal.

I've programmed the frequency counter's gate-time to be 20 msec.  Because this gate time is 20 msec, I can convert the "divide-by-8" reading back to a count reflecting frequency with a simple shift-left by 2 operation (multiply by 4).  Measurement resolution is 400 Hz.

The FreqCounter routines contain a compensation function to correct frequency-counting errors, but when I first start using them, I discovered that if the displayed frequency is measuring too high, this compensation cannot lower it -- it can only raise a frequency that is too low.  So I instead just multiplied the measured reading by a "compensation value" that I had calculated would bring it in line with the actual frequency displayed on my HP 8640B.  (I later discovered that the counter on my HP 8640B was off, and that the FreqCounter's compensation routine probably would have worked, but I decided not to change my method, I just changed by compensation factor from a value slightly less than one to a value slightly greater than one).

By the way, here's my Frequency sub-menu, showing my three stages of frequency measurement:

The top left-hand number is the "raw" frequency reading, after the result from FreqCounter has been multiplied by 4 (shift-left by 2) but before compensation has been applied.  This value changes in increments of 400 Hz as frequency is increased or decreased (i.e. last digit bumps up or down in increments of 4).

The number just to its right, again on the top line, is the frequency after it has been compensated.  I only use one compensation value across the entire frequency range, but this value really wants to change slightly between low-frequencies (80 meters) and high-frequencies (10 meters).  However, the one-size-fits-all approach that I've taken gets me close enough to where I want to be (final display accuracy +/- 1 KHz).

And the third number, on the bottom line, is the final frequency!

An important note:  when making a measurement using FreqCounter the Arduino's "millis()" counter (and I also assume its micros() counter)  will be stopped.  So if you are using these routines for loop timing, you'll inadvertently lengthen the loops by the counter's gate time whenever millis() is invoked.  In other words, if you call millis() just before and just after the counter is invoked, the delta between the two readings will be 0 msec (or close to it), even though 20 msec of real time have actually passed (assuming a gate-time of 20 msec).

LCD Display Update:

The LCD display itself, because of the nature of the LCD material, is a bit slow to visually update.  So it doesn't make sense to frequently update the LCD -- you wont' see it.  For this reason, and also because updating the LCD can slow down my other loop times, I limit LCD updates to a screen update rate of once every 250 msec.


Tuning Speed:

Per the Relay datasheet, the worst case relay set/reset time is 15 msec, max.  My measurements of Vrl show a settling time (for a large transition) of about 7 msec.  So I've defined the basic "Stepping Speed" of this Tuner to be the sum of these two values:  22 msec.  In other words, after any change of the Ls or Cp relays, the voltages Vrl and Vf should not be sampled by the A/D for at least 22 msec.

With this constraint, actual tuning seems fairly fast.  It usually takes about 4.5 seconds to tune to a match starting from a "cold start" (Ls and Cp both at 0x00) and with a load of 500 ohms (10:1 SWR).  Other loads can be tuned more quickly, and tuning can also be faster still if not starting from the L and C = 0x00 point, but instead starting from the currently in-use value (assuming that the new frequency isn't too far away).

(An interesting side benefit of the 22 msec tuning speed -- I've always used 20 msec as being a good "switch debounce" time, so the tuning-loop speed of 22 msec allows me to also include switch/pushbutton debouncing within the same loop).


Searching for Best Return Loss (lowest SWR):

The search algorithm is the heart of the Tuner, and after some trial and error, I came up with a search pattern based on rectangles.  I cannot say that this method is the best, but it works, it is fast (relatively), and seems, so far, to always find the optimum match.

Here is a (very) brief description:

The algorithm starts its search from L = 0x0, C = 0x0 (this point I consider to be a "cold start") and with a step size set to 8 times the minimum step size specified for the frequency band being tuned (note that my minimum step size is 0x02 for 80, 60, and 40 meters, and 0x01 for 30 through 10 meters).

The algorithm starts in the LsCp configuration and then moves incrementally along the L "line", keeping C at 0x0 while L is incremented, until it finds a maximum value of Return Loss (i.e. lowest SWR) on that line.  If a maximum isn't found, the algorithm bumps C by one increments and repeats.  If none are found and both Ls and Cp are at their max, the algorithm will then switch to the CpLs configuration and begin again).

Note that I've defined the maximum values for Ls and Cp, per band, to be:

• 80 Meters: 0xFF
• 60 Meters: 0xFF
• 40 Meters: 0x7F
• 30 Meters: 0x5F
• 20 Meters: 0x4F
• 17 Meters: 0x3F
• 15 Meters: 0x2F
• 12 Meters: 0x1F
• 10 Meters: 0x1F

Once a return-loss maximum is found, the algorithm starts searching around this point in a "square" pattern in which the maximum is placed at the center of the square and the 8 nearest points around this maximum (at a distance defined by the current step-size) are searched for a new maximum.  If a new maximum is found in one of these 8 points, the search-square is moved to center on this new maximum and a new 8-point search commences.

If no new maximum is found, the step-size is reduced (by dividing it by 2) and 8 new points around the same maximum (and closer to it), are then searched.

After reaching the minimum step size and searching  but not finding a new maximum, the search (with a caveat, to be discussed just below) is considered to be finished.

Note that if the search-square is moved to an adjacent new maximum, we don't need to search all 8 points again.  We've already measured some of the points in our previous search, and so we can speed up the process by skipping these:

But, as I discovered during testing, sometimes the "square" search doesn't land on the optimal match.  I had this happen to me on 20 meters.  To demonstrate the problem, here's a spreadsheet showing Return Loss for a small area in the Tuner's match-space at 14.125 MHz.  Note that larger values of Return Loss are good, as they equal lower SWR (values shown are in Hex).

I discovered that the tuner would tune to the L and C setting for the "amber" square, but that this was not the optimal setting.  The optimal setting was actually for the "green" square, but there was no way for a "square" search pattern, once it was down to its minimum step size, to get to the green square from the amber square.

So as a "final check" I added a further search that takes place after I've reached the point of minimum step-size and no further square searches.  I do four 8-point rectangular searches (by rectangle I mean that one axis has a length different from the other axis).  Two searches use horizontal rectangles, and the other two searches use vertical rectangles.

(Click on image to enlarge)

Thus, the four rectangular searches, combined, result in this search pattern:

It was a quick fix, but so far it seems to do the trick.

A side note:  You might be looking at the above Return Loss grid for 14.125 MHz and wondering how this could be -- there are two maxima shown, yet a property of L-networks is that there should only be one maximum in the match space.

Well, there really is only one maximum.  The problem here is that the minimum component step-size used for the search is too large, so we miss the underlying Return Loss pattern as we step through the component values.

In other words, the actual Return Loss, if displayed as a grid similar to the one shown above but with much smaller component step sizes, probably looks like a "ridge" rising from the "North-Northeast" direction and descending to "South-Southwest," and with a single peak in the vicinity of the Ls = 0x03, Cp = 0x2B area.


Memories:

I utilize the Arduino's  internal 1024-byte EEPROM to store Tuner settings, thus allowing the tuner to quickly set itself to an optimal tuning setting for a frequency, as long as there is enough RF power for the Tuner to read frequency and as long as that optimal setting has already been stored into the EEPROM.

Tuner settings in the EEPROM are divided into 3 banks of 333 bytes, each.  So a total of 999 bytes out of the EEPROM's 1024 bytes are assigned to tuner-setting storage.

Each of the three banks is independent, and each can contain tuner settings for all nine ham bands (80 - 10 meters).

Each band within a bank is broken up into a number of frequency "bins," per the table below.

Each bin entry consists of 3 bytes:

• First Byte:  Configuration-bit (1 = LsCp, 0 = CpLs) and 4-bit Cs setting.  Bypass isn't stored, as it is not under software control in this design. 
• Second Byte:  Ls setting
• Third Byte:  Cp setting

(Note that the number of bytes could be reduced from 3 to 2 -- after all, if I know the frequency I know the band, and therefore I know the Cs setting without having to store it.  So Cs isn't needed.  Also, I could "pack" the configuration bit into either the Cp or Ls byte -- not all 8 bits are ever used.  For example, on 80, 60, and 40 meters my minimum step-size is 0x02, leaving the LSB of either component value unused, and so I could place the configuration bit in this bit location.  Similarly, on higher bands the MSB isn't used and the configuration bit could be stored there.  But the current design gives me maximum flexibility should I discover, as I use the Tuner, that I need to change minimum step sizes or maximum component values.  But who knows...perhaps a mod for the future?)

If the software, when tuning, does not first find a match in any of the EEPROM's 3 banks, it will invoke a "normal" tune cycle.  At the end of this cycle, if it has found a "great" match (at the moment defined to be SWR 1.2:1 or better), it will write this setting into the EEPROM in a FIFO fashion (First-In, First-Out).  That is:

• First, the Bank 2 setting for that frequency-bin is moved to Bank 3.
• Then, the setting for Bank 1 is moved to Bank 2.
• And finally, the new setting is written into Bank 1.

In other words, the three banks represent the settings in the order in which they were written into the EEPROM.  The first bank contains the latest setting for that frequency bin, and the last bank contains the "oldest" setting.

If another new setting is found, it will be written into the FIFO and the FIFO's contents shifted, and the last entry (the oldest, in Bank 3) will be dropped off.

In this way, settings that might no longer be useful (e.g. an antenna has changed, etc.) will eventually be automatically dropped, should new settings later be stored.

Three banks allows me to have settings for, say, three different antennas.  In other words, if I switch antennas and give the tuner some RF, the best setting appears (essentially) immediately.  But note that a bank isn't specifically assigned to an antenna.  Settings for an antenna can be in different banks, depending upon how many settings have already been stored for that specific frequency "bin.".

Or, in the case of my 80 meter loop (fed with twin-lead), multiple banks could allow me to store different settings to compensate for feedline/antenna detuning due to rain or snow.

Or, if an antenna has a really high Q (i.e. SWR changes appreciably within a bin), the three banks could store the optimum settings for three different frequencies within a bin (e.g. at the start of the bin, at the center of the bin, and at the end of the bin).

One final note on memory operation:  the EEPROM is not written-to if the contents to be overwritten are the same as the data to-be-written.  The EEPROM is only written-to if its contents will change.

And I should add:  I've also included an external I2C EEPROM in the hardware design just in case I needed it, but I haven't yet had a need to use it.


Other Software Notes:

To keep the relay contacts from degrading if switching high voltages or currents (i.e. if transmitting at maximum power and at high SWR), the tuner will only tune if Forward Power is below a "Maximum Tune Power" threshold.

I have (arbitrarily) chosen the Maximum Tune Power threshold to be 50 watts.

If, while tuning, Forward Power exceeds this threshold, the tuning process will stop, an Error message is displayed on the LCD (i.e. "Reduce Power!"), and the operator will hear beeps until either power is reduced and tuning continues, or the operator "clears" the tuning process by (briefly) transitioning to Manual or Bypass mode with the front-panel toggle switch.

(This excellent idea came from Jukka Siitari, SV9RMU, who is building an auto-tuner of his own design and mentioned this concept during an email conversation with me).


OK!  That ends my description of my software.


Return-Loss/SWR Meter:

Here's an idea of where the 1.5:1, 2:1, and 3:1 SWR readings are on the Return-Loss meter:

(1.5:1 was measured with a 75 ohm load, 2:1 with two 50 ohm terminations in parallel, and 3:1 with three 50 ohm terminations in parallel.)


Observations on EMI and Susceptibility to RF:

I have had two over-arching concerns regarding the integration of a Microcontroller into this design.  The first concern has been:  will the processor and/or its associated circuitry (e.g. LCD) generate noise that I can hear on my receiver?

And the second concern was:  would high-power RF cause the processor and/or its associated circuitry to act weirdly?

Because of these two concerns, I took care to create two compartments in the chassis -- one for the RF components such as the L-Network, and the other for the control circuitry.

I routed wiring in the RF compartment (e.g. the wires to the relays) as twisted-pairs, to minimize their loop area and thus B-field pickup, as well as bypassing them to ground with 100 nF caps at the shielded bulkhead wall between the two compartments.

Also, within the control compartment, the Microcontroller board was "locally" shielded with copper tape, and I filtered signals that pass between the outside world and the circuitry under this shield with R-C lowpass filters (except for the I2C lines to the LCD -- filtering these could adversely affect rise/fall times).  (Note, though, that the LCD assembly and its 4-wire interconnect cable are not shielded -- shields can be added, though, if an interference/susceptibility issue crops up).

So, to the first concern of Tuner-generated EMI: I've tested this tuner with it connected to a 50 ohm load (so there is no atmospheric noise that might mask any tuner-generated noise), and I haven't heard any difference in receiver noise between the tuner being powered ON and the tuner being turned OFF.

However, if the USB cable for Arduino downloading/monitoring is connected between the Tuner's Arduino Nano and my PC, there is a noticeable increase in receiver noise.  This noise occurs even if I simply touch the USB connector's shield to my tuner's ground, so it seems to be ground-loop noise, probably originating at the switching-supply used by my laptop.

It isn't a big deal, because this cable is rarely attached (it's connected only if I'm working on the Arduino code).

Regarding susceptibility to RF -- so far, there's been no problem, but I haven't extensively tested it.

I did notice, though, that if the chassis top cover (which is grounded) is pulled back to the point of revealing the Return Loss board and part of the Directional Coupler assembly, the Tuner's "Power" reading becomes inaccurate at 100 watts and more -- it reads too low.  I traced this problem to RF getting into the very short run of wire (for Vrl and Vf) between the Return Loss board and the chassis bulkhead.  Sliding the chassis cover over the Return Loss board fixed this problem.

I also ran my 813 AM rig through the Tuner to my 80-meter G5RV.  There was no flakey microcontroller or LCD operation while I was transmitting at a carrier power of about 230 watts (and therefore peak power of around 900 watts when I was saying "Ahhh").  So this is a positive sign.  But I need to do testing on other bands, too.

However, while I was transmitting with this AM transmitter and saying "ahhh", my shack lights turned off.  These are remote-control lights using an "X10" module.  This hasn't happened to me before -- normally I use a Johnson Matchbox (dedicated to this transmitter) for antenna tuning.  But it's been quite some time since I've used this rig and this antenna, and there have been some wind storms, so my current suspects are:

• The G5RV has become unbalanced (e.g. one of the radiating elements broke at the antenna's center-insulator in a windstorm -- it's happened before), and so there's RF in the shack from feedline radiation.
• RF is getting into the shack's AC wiring via the Tuner's AC power line.  Perhaps it needs better filtering?  Or power the tuner from an external 12 VDC supply?

Anyway -- at the moment the cause is unknown.  There are some experiments I can and will do, e.g. see if this problem occurs when using the Matchbox, or power the tuner from a separate 12VDC source (and not from its internal AC supply), etc.


Some Notes on this Tuner's Performance:

• Tuning range is from 3.5 MHz to 30 MHz.
• It should tune loads with 10:1 SWRs to an SWR of at least 1.2:1 (although some loads on 10 meters might be problematic) -- I've tested with 500-ohm and 5-ohm resistive loads, and, when tested on 75, 40, 20, 15, and 10 meters (I skipped the WARC bands out of laziness), this Tuner almost always tuned to an SWR better than 1.1:1.  Twice it tuned to 1.1:1 (5 ohm load on 10 and 20 meters), and once to an SWR of 1.2:1 (5 ohm load on 15 meters).
•  It will tune at low power (currently the tuning-power threshold is set to 10 milliwatts).
• To measure frequency, it requires (roughly) 5 to 10 watts of forward power (assuming a 50 ohm load, other loads can require higher power to achieve an adequate transmission-line voltage).
• Its tuning speed, into a 10:1 SWR, starting from L = 0 and C = 0, is about 4.5 seconds, max.

Notes to Myself:

• With 121 VAC applied to the Tuner's AC input, the +12VDC power supply measures 16.8 VDC (with 0.15 Vrms ripple) with all relays OFF, and 13.1 VDC (with 0.76 Vrms ripple) with all relays ON.

Still to Do (at a future date...):

• Hardware:  Add "Tuning" and "Amplifier Disable" relays.  The Arduino outputs to drive these relays have been implemented, I just need to fabricate a small board and attach it to the Tuner's back panel (with holes cut for RCA jacks).  And of course, it will require a bit of software.  But, at this moment, there isn't a need to do it.  Maybe down the road...

OK, that's it for this blog post.  The next, and final, blog post in this series will wrap it up with an update of all of the schematics (their revisions will be bumped from their current Rev. X levels to "Rev. A").

And here it is: http://k6jca.blogspot.com/2016/01/antenna-auto-tuner-design-part-10-final.html

And please note:  The "final" schematics could have changed from the versions included above, in this post.  The final "release" schematics can be found in Part 10 of this series:  http://k6jca.blogspot.com/2016/01/antenna-auto-tuner-design-part-10-final.html


A Thank You to...

A big thanks to Graeme Jury, ZL2APV for pointing me in the direction of the Arduino.  I'm amazed and very happy at how easy, with the Arduino platform, the code and hardware development turned out to be.

Also, a big thanks to Dick Benson, W1QG, for being a sounding board and source of good ideas, and for fabricating that special right-angle mounting bracket to get around mechanical interference issues with the LCD assembly.


Links to my blog posts in this Auto-tuner series:

Part 1:  Preliminary Specification

Part 2:  Network Capacitor Selection

Part 3:  Network Inductor Selection

Part 4:  Relays and L-Network Schematic (Preliminary)

Part 5:  Directional Coupler Design

Part 6:  Notes on Match Detection

Part 7:  The Build, Phase 1

Part 8:  The Build, Phase 2 (Integration of Match Detection)

Part 9:  The Build, Phase 3 (Incorporating a Microcontroller)

Part 10:  The Final Schematics


Links to my Directional Coupler blog posts:

Notes on the Bruene Coupler, Part 2

Notes on the Bruene Coupler, Part 1

Notes on HF Directional Couplers

Building an HF Directional Coupler

Notes on the Bird Wattmeter

Notes on the Monimatch

Notes on the Twin-lead "Twin-Lamp" SWR Indicator

Calculating Flux Density in Tandem-Match Transformers


Standard Caveat:

As always, I might have made a mistake in my equations, assumptions, drawings, or interpretations.  If you see anything you believe to be in error or if anything is confusing, please feel free to contact me or comment below.

And so I should add -- this design and any associated information is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Antenna Auto-Tuner Design, Part 8: Build, Phase 2: Match-Detection Integration

I've finally found some time to devote to my automatic antenna tuner build, and I've just finished incorporating the Match-Detection circuitry into it.  (The previous post in this series can be found here:  http://k6jca.blogspot.com/2015/09/antenna-auto-tuner-design-part-7-build.html).

Originally I had planned to incorporate four different Match Detection functions.  These functions were to be:

1. Return Loss (SWR) Detector
2. R Detector
3. G Detector
4. Phase Detector

(As discussed here and here).

But as I proceeded with this latest phase of the build I discovered I was space-constrained within the tuner's chassis (besides being timed constrained, too), and that it would be difficult to fit into the chassis all of the circuitry I had hoped to install.  So I decided to limit the detectors to a single one:  the Return Loss (SWR) Detector.  The design and installation of this detector is described below.

I've broken this design into two schematics.  The first schematic describes the Directional Coupler, including the two AD8307 Log-Amp Detectors which convert the Directional Coupler's output voltages into voltages that correspond to power in decibel form.

The second schematic describes the circuitry used to calculate Return Loss and which also provides outputs for driving an analog panel meter as well as a microprocessor with A/D inputs (I hope to describe the incorporation of this processor in the next blog post).

Let's take a look at these two schematics. First, the Directional Coupler...


Schematic, Directional Coupler:

(Click on image to enlarge)

Notes on the Directional Coupler Schematic:

I originally described my proposed Directional Coupler design in this post:  http://k6jca.blogspot.com/2015/07/antenna-auto-tuner-design-part-5.html

But since writing that post, I've made two changes to the proposed design:

1. The current-sense transformer and voltage-sense transformers now use differently sized cores.
2. The turns-ratio of each transformer is now 24, not 25

1.  Core Size:

I chose to use cores of different sizes because there is no reason why the current-sense transformer should be the same size as the voltage-sense transformer.  The Flux Density within the current-sense transformer is much less than the voltage-sense transformer's Flux Density, as I show in this spreadsheet:

The formulas used in the above spreadsheet can be found in the following two posts:

Calculating Tandem-match Transform Flux Densities

 

Antenna Auto-tuner Design, Part 5

The spreadsheet shows that the flux-density within the current-sense transformer's core is well within the specification of an FT50-43 core.  On the other hand, the voltage-sense transformer has a significantly higher voltage across its N-turn winding and thus a significant higher flux density, and so it uses a larger 2643625002 core (that I had in my junkbox).

Note:  Many designs using the Tandem Match Directional Coupler topology use identical cores for both Voltage and Current sensing transformers.  They needn't (as I've demonstrated above), and if a design is space-constrained (or cost constrained), a smaller core can be used for the current-sense transformer.

2.  Turns-ratio:

My original plan was to use 25 turns on each coil, but when I wound my first transformer I discovered that I had cut the wire slightly too short and I only had enough wire to wind 24 turns around the core.  Rather than rewind the core, I decided that 24 turns was good enough -- its Coupling Factor is 27.6, which is only 0.4 dB less than 28 dB (the Coupling Factor if the turns-ratio were 25, not 24).

3.  AD8307, Return Loss, and non-Simultaneity:

Why use AD8307 Log-amp detectors rather than just rectify the Directional Coupler's Forward and Reflected port voltages and amplify/buffer them with op-amps?

Two reasons.  The first is convenience.

I wanted to have some way to measure and display load-mismatch before I incorporated a microprocessor into the design.  I had used the AD8307 IC previously (here), and I knew that two AD8307 ICs would make this mismatch-measurement task easy -- they would convert the Directional Coupler's voltages into decibel form, from which Return Loss (which is related to SWR) could be calculated by simply subtracting the Reflected-path's AD8307 output from the output of the Forward-path's AD8307 output.

This Return Loss measurement would be accurate over a wide range of power (sub-watt to a kilowatt, in my design) without any need for additional pot tweaking if the input power changed.

And the second reason for this choice is my concern over A/D sampling methodology...

Over the years I've collected a number of commercial ham radio auto-tuners utilizing relay-switch components and controlled by microprocessors.  Most of them are gathering dust on a closet shelf because, when I used them, I noticed at times an inability to achieve a good match, even though one was available.

I've assumed this problem was due to microprocessor sampling, specifically that the micro was sampling and converting the Forward and Reverse voltages sequentially, rather than simultaneously.

Why might sequential sampling be a problem?

Suppose that the power level into the Tuner was fluctuating during these measurements (perhaps due to PA ALC action caused by load impedance variation (as the tuner tunes), or perhaps due to voice transients, or perhaps due to some other reason), then, if the power level changed between the measurement of the Forward voltage and the measurement of the Reflected voltage, the microprocessor's SWR calculation could be incorrect.

And if the SWR calculation was incorrect, it was possible, too, that the tuned-to setting was incorrect and perhaps sub-optimal. 

Of course, the severity of this potential error is a function the time delay between sequential samples as well as the input-power's rate-of-change.

Could either of these be large enough to be an issue?  I didn't, and don't, know.  But just in case they were, by calculating Return Loss (or SWR) externally and then feeding that result into a single A/D, rather than calculating Return Loss or SWR from two sequentially-sampled A/D values, the possibility of there being a problem (be that problem real or imaginary) was eliminated.

OK, let's continue...

4.AD8307 input range and PI attenuator:


From the its datasheet, here is a graph of the AD8307's output voltage versus input power:

(Click on image to enlarge)

As you can see, the transfer characteristic becomes noticeably non-linear above +15 dBm and below about -68 dBm.  So (in my opinion), a reasonable range of operation (with a bit of headroom) would be between -60 and +10 dBm.

I've specified the maximum power that this tuner should see as being 800 watts, but for the purposes of determining the input-range of the AD8307 ICs let's assume that it's 60 dBm (1 KW).

Therefore I will need 50 dB of attenuation to bring a 60 dBm signal down to my desired AD8307 maximum input level of +10 dBm.

Given that the 24-turn transformers have a Coupling Factor of 27.6 dB, I will need an additional 22.4 dB of attenuation (it doesn't need to be exactly 22.4 dB -- somewhere in the ballpark of that value will be fine -- I've designed in plenty of headroom).

So I've terminated each output of the Directional Coupler with a 50-ohm 22 dB PI-network attenuator.  Implemented with standard 1% resistor values (59 and 316 ohms) and taking into account the AD8307's input resistance of 1.5K ohms, the actual attenuation is 22.2 dB, and its input Return Loss is 50 dB.  (PI Network calculator here:  http://chemandy.com/calculators/matching-pi-attenuator-calculator.htm).

For power-dissipation calculations the maximum average power applied to the tuner is assumed to be 200 watts.  This power level is attenuated by the Directional Coupler's Coupling Factor (27.6dB) prior to being applied to the PI attenuators, which means that the maximum average power applied to a PI attenuator would be 0.35 watts.

Most of this 0.35 watts would be dissipated by the PI attenuator's first shunt resistor, so I've implemented this resistor with two 118 ohm 1/4-watt resistors connected in parallel.

5.  AD8307 Circuit:

The AD8307 circuitry is essentially the same circuit shown in the datasheet.  I have not incorporated the Intercept and Gain pots, preferring to do these functions in the Return Loss Calculator circuitry (described later in this post).

One AD8307 converts the Forward Power from the Directional Coupler to a decibel-related voltage.  The second AD8307 does the same for the Reflected Power.

The two AD8307 ICs are in their own shielded compartment with 0.1uF caps (and feed-thru caps) at the output and power pins of these two ICs to reduce the chances of external RF fields affecting performance in unwanted ways.

Note that the second shunt resistor of each PI attenuator is also installed in this compartment.

The AD8307 outputs have a transfer characteristic of about 25mV per dB of applied power, with a DC offset (when no RF is applied) of (very) roughly 0.28 VDC.


Schematic, Return Loss Calculator:

(Click on image to enlarge)

Notes on the Return Loss Calculator Schematic:

(Important note:  there was a design error in the original schematic that I posted here (Rev. X).  The schematic above is the corrected schematic, and its revision-level is now Rev. A1.  Please see Post 9 in this series for a description of the error and an explanation of the fix).

1.  Return Loss relation to SWR

The AD8307 output voltages represent, in dB form, the power applied to their inputs.  And thus Return Loss can be calculated via a simple subtraction, implemented with a single op-amp:

where Pi(dBm) is the output of the Forward path AD8307 and Pr(dBm) is the output of the Reflected path AD8307 (equation copied from Wikipedia).

SWR is related to Return Loss by this equation:

Not a simple relationship, but knowing this equation, if I'm using an analog panel meter to aid me in tuning, and if this meter's full-scale represents 30dB return loss (i.e. only 0.1% of the applied power is reflected back -- a very good match!), then I can easily mark the meter's scale per the following table:

(Click on image to enlarge)

A note on Return Loss meter orientation:  when tuning an antenna tuner using a Return Loss meter, the goal is to peak the Return Loss reading, which will then correspond to minimum SWR.  But I've been adjusting tuners for decades by dipping SWR meters for minimum SWR, so the Return Loss adjustment method of peaking the reading seems awkward to me.

A simple solution (it seems to me) is to install the Return Loss meter upside-down.  So, in my tuner, a Return Loss of 0 (infinite SWR) corresponds to the meter's needle at the top of the meter (undeflected).  And when the tuner has been tuned for a 1:1 match, the needle will deflect to its full-scale reading at the bottom of the meter's scale -- thus one dips the meter for best SWR!

(Click on image to enlarge)

2.  VF and VR circuits:

One of my goals is to incorporate a processor with A/D inputs (PIC or Arduino) to perform the automatic tuning, and I thought it would be nice to use the processor to calculate and display Forward Power using the AD8307 VF signal (and perhaps calculate and display Reflected Power using VR).

Assuming the processor A/D is referenced to its VDD pin (+5VDC), I'd like to have 4.5VDC represent the maximum applied power of +60 dBm (to give me a bit of headroom).

Also, I would like the range of Forward Power represented by VF to be, at a minimum, from 1 watt (30 dBm) to 1 KW (60 dBm).  Plus, if I'm measuring a 30 dB Return Loss when Forward Power is 1 watt, then the Reflected Power will be 1 milliwatt (0 dBm). And so VR must be just at least 0V when the Reflected Power is 0 dBm.

So, VF and VR, in spanning the range from 0 to 4.5 volts, must represent, at a minimum, a power range of 0 to 60 dBm.

If the AD8307's transfer function is 25 mV per dB, then multiplying this value by 3 would result in a transfer function of 75 mV per dB, which would give us a 60 dB span over the voltage range from 0 to 4.5 volts.

But why not have a bit more range?  If I multiply the AD8307's transfer function by 2 instead of 3, I will change the transfer function to 50 mV per dB (500 mV per 10 dB).  Assuming a 10-bit ADC referenced to 5 VDC, measurement resolution would be about 0.1 dB, which would be perfectly fine in this application.

And note that at 50 mV per dB, 0 to 4.5V will represent a 90 dB span, so I could accurately measure power and Return Loss at powers well below 1 watt.  (Theoretically, this would put the lower Forward Power limit for accurate Return Loss measurements at 0 dBm (1 milliwatt), but as I'll discuss below, the AD8307's specifications result, in this application, in a practical lower limit of +10 dBm Forward Power for accurate measurements).

Op-amps U1A and U1B, configured as non-inverting amplifiers with gains of 2, perform this amplification.  And by connecting the AD8307 outputs directly to their non-inverting inputs, I avoid any unnecessary loading of the AD8307 outputs that might affect their gain.

Potentiometers R11 and R12 create a DC shift so that, when calibrated, +4.5V represents +60dBm.  U11B and U11C isolate these two pots from being included in the gain-equations of the U1A and U1D feedback networks, so that adjusting R11 and R12 won't also change the path gain.

The voltages at U1.7 and U1.8 should be about 0.75 VDC when R11 and R12 are centered.  I then adjust R11 and R12 so that, for a +10 dBm signal applied to the Directional Coupler, VF (or VR) measures 2.00 VDC.

3.  Return Loss Circuit:

U2 performs two functions.  It subtracts VR from VF to create the Return Loss measurement, and it also multiplies this result by 3.

The scaling factor of 3 was chosen so that a measurement of 30 dB of Return Loss would be equal to 4.5V at VRL (VRL is the Return Loss signal that would drive a processor A/D input).  In other words, given the transfer characteristic of VF and VR of 50 mV per dB, I'd like the Return Loss transfer characteristic to be 150 mV per dB.

U2 also drives an analog panel meter so that I can use the tuner without having a processor installed.  The meter is 1 mA full-scale, and R19 adjusts the current through the meter so that 4.5V at VRL results in 1mA through the meter.  Thus, the meter would read 30 dB of Return Loss when deflected to its full scale.

R24 compensates for differences in path-gain between the Forward and Reflected paths.  Because it is in the attenuator network attached to U2's non-inverting input, it adjusts the gain of the Forward path (the gain of the Reflected path being fixed).

But there's a potential problem -- changing the gain at this point also changes, in effect, VF's DC offset as seen at U2's non-inverting input.  And because this change in DC offset at U2 is occurring simultaneously with a change in the Forward path gain at U2, these two changes become inextricably intertwined, and I don't know by how much I should adjust R11 to compensate for this change in offset.

The net effect is that VRL could be shifted slightly either higher or lower by a constant amount.  And thus Return Loss could be shifted, too, to be either higher or lower than it should be.


If the shift is small, this shouldn't be a big deal.  But it could become a problem for larger shifts, depending upon how accurate one wants the Return Loss measurement to be.

Fortunately, in my "one-off" build, the transfer characteristics of the two AD8307 ICs are essentially identical at 25 mV per dB and so adjusting U2's gain via R24 should be fine in this application -- I'm essentially just setting the gains of each of U2's "legs" to be equal.  But in hindsight I would have approached path-gain compensation differently.

For example, I probably would have made U2's gain fixed, without any pots (and using 1% resistors) and instead had separate gain adjustments earlier in the Forward path and the Reflected path.  Pots could have been placed at the outputs of the AD8307 ICs (per the datasheet), for example, or in the feedback networks of U1A and U1D.

But that's hindsight.

4.  Other notes:

0.1 uF caps are sprinkled liberally throughout the circuit and especially at any connector to which a cable might attach, thus bypassing these connectors to ground to (hopefully) prevent external RF fields that might couple into the wiring from affecting circuit operation.

I've inserted 100 ohm resistors between op-amp outputs and 0.1uF bypass caps (where these are used) to "isolate" the op-amp's output (and feedback network) from the capacitive load and thus isolate this load's effect on the overall amplifier phase-response and stability.  (More info on this here (Analog Devices), here (TI), and here (Microchip)). (Unfortunately, TI doesn't spec the output impedance of the LMC660 series, so it's difficult to judge what the effect actually is.  However, per my bench measurements, stability seems fine).

I also roll-off the U2's response with C9 and C10, placing a pole at about 5 KHz  -- there's no reason why this op amp needs a wide bandwidth.

OK, I believe I've covered the schematics.  On to the build...


Build, Directional Coupler:

The Directional Coupler started out as a prototype on a piece of PCB stock that would fit within the Tuner on the existing Capacitor-select board.  I tried some different orientations for the two transformers, such as orthogonal to each-other, but Directivity was only about 20 dB, so I went back to the implementation I'd used in this post: http://k6jca.blogspot.com/2015/01/building-hf-directional-coupler.html, which was:

I changed the current-sense transformer's core size (see discussion above) and bread-boarded the circuit:

Measuring Directivity:

With the implementation shown above Directivity measure 45 dB or better from 1 to 30 MHz.  But when I added additional compartment shielding and the 22 dB PI attenuators, worst-case Directivity dropped from 45 dB to 35 dB:

Note that the 30 MHz marker in the image above shows 85 dB of attenuation.  But we need to factor out 50 dB of attenuation (27.6 dB coupling factor plus the PI Attenuator's 22.2 dB of attenuation).  The result is 35 dB of attenuation, which represents the Directional Coupler's Directivity.

Here's that implementation:

(Note that you can just see the AD8307 circuitry at the far-left of the image above.  Although present in the photo above, this circuitry had not yet been installed when I made my Directivity measurements.)

Also, if you look closely, you can see some yellow Teflon insulation on the end of one of the voltage-sense transformer's secondary winding.  There is actually Teflon insulation on both ends of this winding.  Both ends are side-by side on the transformer and there is a high voltage potential between them (one end being grounded and the other end connected to the transmission line).

There is also a little rectangle of Kapton tape mounted under voltage-sense transformer on the bottom of the compartment.  It provides a bit more voltage isolation between the transformer windings and chassis ground.

(I also tested an implementation using a 2643625002 core for the current-sense transformer.  I saw no difference in performance between it and the FT50-43 I am currently using.)

Return-Loss Uncertainty due to Directivity:

Now that I knew the Directional Coupler's Directivity, I could determine Return-Loss Uncertainty.

Note that with a worst-case Directivity of 35 dB, there will be an increasing uncertainty in Return Loss readings as the Return Loss approaches its theoretical maximum of 35 dB (Return Loss cannot be larger than the Directivity).  This uncertainty is shown in the table below, per the calculator found here bytecollector.com/library/DirectivityErrorCalc-w-SWR.xls:

(Click on image to enlarge)

So, given my planned-for maximum Return Loss reading of 30 dB and a worst-case Directivity of 35 dB, the actual Return Loss for this reading (and excluding path errors such as AD8307 accuracy) would lie somewhere in the range between 26 and 37 dB, which represents an actual SWR that would be between 1.03 and 1.1 -- still quite acceptable.

AD8307 circuit implementation:

The AD8307 ICs are SOIC-8 packages.  I find that such a small size can be a headache to prototype with (unless, of course, one has a PCB with appropriate component footprints), so I purchased some small SOIC prototyping boards from eBay.  These greatly facilitate wiring to the IC pins.  (Alternatively, I could have purchased these ICs in DIP packages).

(I later added copper tape to shield the sides of the AD8307 chamber, and a copper top will be added over the entire assembly after I finished mounting it in the tuner chassis).


Build, Return Loss Calculator:

When I finished my Directional Coupler build I discovered, if I placed it in the Tuner chassis, there wasn't much additional room available on the Capacitor-selection board for me to add the Return Loss Calculator Circuitry.

And given the fact that my junk-box potentiometers were all designed to mount end-on, I decided instead to build the circuit on a small piece of plated-through perf board that I would mount vertically on the bulkhead shield that separates the Tuner's RF compartment from the Control compartment.

Although the two ICs are DIP ICs, the passive resistors and capacitors are all surface mount (0805 packages).

Here's the build, shown un-annotated and also annotated with I/O names and potentiometer reference designators added:

The board was notched in two places due to mechanical interference issues with two pre-existing mounting screws, given the tight space that I was trying to mount it into.


Incorporating the Directional Coupler and the Return Loss Assemblies into the Tuner Chassis:

Here's a picture showing the installed Directional Coupler Assembly and Return Loss Calculator Assembly.  (You can see the latter's pots next to the bulkhead divider).

(Note that I did not remove the SMA connectors on the Directional Coupler assembly.  They are left there in case I need them for future testing.)

Below I've installed a copper plate (cut from a sheet of 26 gauge copper) over the top of the RF compartments, with bent-down tabs tacked to the side walls in 5 places.

Calibration Procedure:

1.  With the Directional Coupler's output unloaded (open load) and disconnected from the Tuner's L-Network circuitry, and with a +10 dBm 3.5 MHz signal applied to the Directional Coupler's input, make the following adjustments:

• Adjust R11 so that VF is 2.00 VDC
• Adjust R12 so that VR is 2.00 VDC

2.  With the input to the Directional Coupler still +10 dBm at 3.5 MHz, connect a calibrated 75 ohm load to the Directional Coupler's output and make the following adjustments

• Adjust R24 so that VRL measures 2.10 VDC (equals 14 dB Return Loss times 0.15V/dB)
• Adjust R23 so that the Panel Meter deflects to 47% of Full Scale.

Design Verification Measurements:

1.  VF and VR versus Input Power.

This test is performed with the Directional Coupler's output unloaded (i.e. open, so that Forward and Reflected powers are identical) and after R11 and R12 have been calibrated to give equal readings of 2.00 volts at VF and VR for a +10 dBm input signal.  It measures the response, versus signal level, of VF and VR.

(Click on image to enlarge)

Note that the gain of VF and and the gain of VR are essentially identical.  (There's no guarantee that this will be true for all AD8307's, though).

2.  VRL versus Zload:

This test measures the Return Loss voltage versus different loads connected to the Directional Coupler's output.  Note that the Zload is resistive rather than a complex impedance.

(Click on image to enlarge)

For the three loads I used, the measured Return Loss is close (error under a dB) to the loads' actual Return Loss (per my HP 8753A).  This error is quite adequate for my tuner application, which is not meant to be a lab-grade measurement device.

3.  Step Response, VRL

This test checks VRL's step-response to a change in Return Loss, measuring the amount of time it would take the VRL reading to settle down after, for example, a change to the tuner's L-Network settings.

But rather than performing the test by changing the Directional Coupler's load in a "step" fashion (for which I'd have to design some sort of fast-switching circuit), I instead "mimic" a change in load impedance by taking advantage of the VF and VR circuits' characteristics at low signal levels.

This is an important point:  specifically, if the drive to the Directional Coupler is less than +10 dBm, and if the load itself is an accurate 50 ohm load (Return Loss > 30 dB), the measured Return Loss will be a function of the input power level, rather than a function of the load attached.

This effect is mainly due to the fact that, at low power levels, the VF and VR op-amp outputs will clamp to their negative rail -- they cannot go below 0 volts.

Thus, even with a 50 ohms load is connected to the Directional Coupler's output, Return Loss will appear to be very poor if the applied power level is very low, as I demonstrate in this table:

As one can see, because VR cannot go below U1's lower power rail of 0V, the delta between VF and VR is artificially reduced at low power levels.  And so Return Loss erroneously appears to worsen.

One important conclusion from this data:  If the input power applied to the Directional Coupler is less than +10 dBm, the Return Loss measurement could be wrong.  So tuning should only be done when VF measures at least 2.0 VDC (i.e. input power at least +10 dBm).

(But keeping the input power above +10 dBm shouldn't be an issue.  After all, +10 dBm represents 10 milliwatts.)

(Note, as power decreases, even if VR weren't clamped to 0V by U1, the same effect would occur at some lower power level because the Reflected path's AD8307 transfer-characteristic limits-out at at the lower limit of its input-power specification.)

We can use this behavior to mimic a step-change in the impedance seen by the Directional Coupler's output.

Here's an oscilloscope capture of VRL step-response to a step-change in the signal level applied to it (via my Fluke 6060B).  Although I'm stepping the level from -20 to -10 dBm, which, per the previous table, should give a VRL transient from 1.5 to 3 volts (a Return Loss step from 10 dB to 20 dB), the Fluke's attenuator relays, as they change, briefly create an attenuation larger than -20 dBm before they step to +10 dBm.  The result is that VF goes to 0 volts (rather than starting at 0.5V) before stepping to 1.0 volt.  VR is 0 volts in both cases, and thus VRL (being equal to VF-VR) steps from 0V to 3V.

In other words, this test mimics a step-change in Return Loss from 0 dB to 20 dB.

(Click on image to enlarge)

VRL settles down within about 7-8 msec of the initiation of the step transient.

4.  Impact of Directional Coupler circuitry and the Additional Grounded Shields on Tuner Match Performance:

This test checks if the addition of the Directional Coupler assembly (and its shields) has any effect on the Tuner's "match-space."  This test is performed at 30 MHz (the highest frequency I'm specifying for this tuner) to accentuate the negative effects of any stray parasitic components.

The test is identical to the one described in this post: http://k6jca.blogspot.com/2015/09/antenna-auto-tuner-design-part-7-build.html

And here are the results:

(Click on image to enlarge)

Below are the results from my prior testing (from Part 7 of this series of posts):

(Click on image to enlarge)

These two plots appear identical to my eyes. Therefore, the incorporation of the Directional Coupler assembly into the tuner has little, if any, effect on the tuner's match-space.


Other Notes:

I actually breadboarded the R, G, and Phase Detectors just to make sure that, conceptually, they worked.  And they did, but I only did a minimal amount of testing.

Here is an image of the schematics:

(Click on image to enlarge)

Note that the schematics are not entirely representative of the final breadboard circuit (they are included here only for sake of completeness).

For example, after I smoked one of the resistors in my first voltage sampler, I changed the two resistive transmission-line voltage samplers to instead be capacitive voltage dividers (each divider became a 1.7-11 pF variable cap (to the transmission line) in series with 120 pF fixed cap (to ground)).

I also needed to add a DC path to ground (yet high impedance at RF) at each capacitive dividers' voltage-divider node.  I did this with a 2.5 mH inductor connected in parallel across each 120 pF cap.
Also, I deleted the 2N7000 in the phase detector -- the goal was to have the LEDs turn ON only when RF was present.  But, given the 2N7000 turn-on voltage, this wasn't working as planned for the RF power levels I was testing at.  No problem, as I didn't really need to do this to verify detector functionality, so I simply grounded the 2N7000's Drain to ground.

And the Vv and Vi signals are defined per the definitions shown in my post (post 6 in this series) on Match Detection.


OK, that ends this post!


Part Nine of this blog series is posted here: http://k6jca.blogspot.com/2016/01/antenna-auto-tuner-design-part-9-build.html

And please note:  The "final" schematics could have changed from the versions included above, in this post.  The final "release" schematics can be found in Part 10 of this series:  http://k6jca.blogspot.com/2016/01/antenna-auto-tuner-design-part-10-final.html


Links to my blog posts in this Auto-tuner series:

Part 1:  Preliminary Specification

Part 2:  Network Capacitor Selection

Part 3:  Network Inductor Selection

Part 4:  Relays and L-Network Schematic (Preliminary)

Part 5:  Directional Coupler Design

Part 6:  Notes on Match Detection

Part 7:  The Build, Phase 1

Part 8:  The Build, Phase 2 (Integration of Match Detection)

Part 9:  The Build, Phase 3 (Incorporating a Microcontroller)

Part 10:  The Final Schematics


Links to my Directional Coupler blog posts:

Notes on the Bruene Coupler, Part 2

Notes on the Bruene Coupler, Part 1

Notes on HF Directional Couplers (Tandem Match)

Building an HF Directional Coupler

Notes on the Bird Wattmeter

Notes on the Monimatch

Notes on the Twin-lead "Twin-Lamp" SWR Indicator

Calculating Flux Density in Tandem-Match Transformers


Standard Caveat:

As always, I might have made a mistake in my equations, assumptions, drawings, or interpretations.  If you see anything you believe to be in error or if anything is confusing, please feel free to contact me or comment below.

And so I should add -- this design and any associated information is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.