AutoCap Tuner

For Small Magnetic Transmitting Loop Antennas

Matt Roberts - matt-at-kk5jy-dot-net

Published: 2014-04-09

Updated: 2016-09-17

Introduction

Small transmitting loop antennas are becoming increasingly popular. Their performance
is quite high considering their physical size, and such antennas have proven successful in
some of my recent experiments. These antennas are easy to tune
when using a remote motor drive, and for most operating, a simple up/down switch at the
control point is enough to quickly adjust the antenna for the current frequency.

For contesting operations, particularly when working "search and pounce", it can
be quite a challenge to stay on top of the antenna tuning, since the VFO frequency changes
minute-by-minute. An experienced contest operator can make several contacts per minute,
even when not "running". For a high-Q antenna such as a magnetic loop, an
automatic tuner would make the antenna adjustment much more compatible with contest
operations.

This article describes a loop tuning system that automatically keeps my contest-band loops
properly adjusted as I hop around each band making contacts. The main components are
readily available, and the design is deliberately left open and modular, to allow others to
extend or tailor it for their particular needs.

The Pieces

The current system consists of several components:

One or more loop antennas, each equipped with a
DC motor that
turns a capacitor shaft at low RPM. Most of my loops
are used for a single band, where each is most effective. Their
drive motors
have anywhere between 0.5 and 4.0 RPM unloaded shaft speed. I have also
started experimenting with
stepper motors, which
have proven to have some interesting advantages over normal brushed DC motors.

An SWR meter with a data output. This is used as a data source for
the automatic tuning algorithm, continuously monitoring the antenna SWR.
Two sensor options are currently implemented by the software:

The TelepostLP-100A, which has an
RS-232 port that can be queried for SWR and power readings.

A homebrew meter. A related project to this one is a simple
Serial/USB SWR Meter, that can be easily
adapted to use almost any SWR sensor.

Any device that emulates the protocol of either of these meters can be used by the
software to monitor the antenna.

A PC running a piece of open-source control software, AutoCap. This
software reads the SWR meter, continually evaluates the condition of the loop, and
generates motor commands that adjust the loop. This is the main component of the
automatic adjustment task.

A motor interface, which allows computer control over the motor attached
to the loop capacitor. I have tried several different strategies for this,
and each has its advantages.

Two relays connected to an RS-232 port's handshake lines, one of which controls
the motor polarity, and the other controls power (on/off) to the motor.

Two relays arranged into an H-bridge
configuration, connected to an RS-232 port's handshake lines.

A dedicated motor driver circuit, connected to a microcontroller with firmware that
accepts movement commands from the PC, and translates those into motor actions.
For this purpose, I chose an Arduino-based controller, with custom AutoCap firmware.

This last option turned out to be the best overall solution, able to drive all
types of hardware, including relays and solid-state H-bridges, enabling precise
control of both simple DC motors and stepper motors. The Arduino provides
a single standardized interface to the PC software, regardless of what kind of
motor or interface circtuits are used.

In this article, I will concentrate on the last two items, the PC software and the motor
controller. The other items are covered in the articles linked above. The AutoCap
system described here is mainly a software effort, both on the PC, and for the motor
controller.

The Control Software

The main component of the system is the PC-based software. The software is a single
GUI application, written in C#, that handles the control loop and motor management.
Since the software is written using a .Net language, it can run on any operating system
that provides a .Net runtime with Forms support. This includes Windows, Linux, and
any other system that can run a recent version of the free Mono framework.

This application is the "tuner." Everything else in the system is
a support component used by the GUI application to either measure something or move
something. The application's main window has a number of tabs that allow for
monitoring and control of the system.

Status Tab

The Status tab is where normal operating is done. This tab displays the system
state, and allows the user to manually control the motor if desired.

Figure 1a: Status Tab

When the Enable button is selected, the button becomes green, and software starts
to monitor antenna SWR and power. When the SWR rises above a certain threshold,
the application will adjust the antenna as needed, by commanding the attached motor
drive to turn the capacitor shaft. The software moves the capacitor in a series
of short movement actions, or pulses, and evaluates the SWR between each movement.

Figure 1b: Status Tab - Operational

When the application moves the motor, the motor commands are displayed, along with
SWR information. If the meter provides power readings, the forward power is
also displayed. If a radio connection is used, the frequency is displayed, as
well. The only required reading is the sensor SWR value. The others
are displayed if present, and they will be used to better manage the antenna.
While the system is running, the hardware version information for the meter/sensor,
motor controller, and radio connection are displayed at the bottom of the window.

If the Pause button is pressed, the button becomes yellow, and the system
temporarily stops making antenna adjustments. While paused, the software
continues to communicate with the meter and radio, but takes no action when a
threshold is exceeded. When the paused state is cancelled, by pressing the
button again, the system resumes making adjustments, as needed. This feature
can be used for any number of situations, but is provided primarily to allow the
operator to briefly pause automatic tuning while making manual adjustments using the
buttons at the bottom of the tab, as described below.

Figure 1c: Status Tab, Operational, but Paused

Five manual control buttons are provided on the Status tab. The outer
two allow for continuous motor movement, and move the motor in the direction
indicated as long as the buttons are pressed. A motor "down" command
is the left button, and an "up" command is the right button. If the
motor controller accepts variable effort commands, the Manual Effort box
allows for controlling the motor effort in the given direction. The next
inner two buttons also generate motor movement, but they generate a pulse, whose
duration is controlled by the Manual Pulse box.

If the motor controller supports stepper motors, the Manual Pulse can
also be configured to produce a specific number of steps, rather than a timed
movement. If you double-click the unit to the right of the number, it
will change from ms to st, to allow for precise manual stepping.

The center button is a "lock" button that turns the outer two buttons into
latching controls. That is, when the inner button is activated, it becomes green,
and the outer two buttons become push-on-push-off style latching buttons. This
function is provided to facilitate band changes, or other large manual tuning
actions. When the middle button is off, the outer two buttons act in a
momentary fashion, where they must be held down to move the motor.

Tip:

While the software is actively tuning the antenna, you can "hint" to the
algorithm that it should reverse direction by pressing any of the directional
controls. Doing so will cause the automatic tuning process to temporarily
favor the direction you indicate while it searches for a solution. This is
mostly useful if you know that the tuner is searching in the opposite direction
of the best tuning solution, such as might happen when the loop is too far from
the operating frequency for the meter to detect the current SWR slope. If
you are using a radio connection to provide frequency hints, this should not be
necessary, even if you make a large change in operating frequency. See
the Radio Tab section below, for details.

Timing Tab

The Timing tab controls how the automatic tuning algorithm responds to
changes in the antenna. The software continuously monitors SWR and power
levels, and each reading is compared against a set of thresholds, to determine
if any adjustment needs to be made to the antenna.

Figure 2: Timing Tab

There are four rows of SWR thresholds, and they are evaluated top-down for each SWR
reading. Whenever the SWR exceeds one of the thresholds, the system will move
the motor to try to adjust the antenna back into resonance. It will consider
a successful tune to be an SWR reading below the lowest SWR threshold.

A motor command is generated from the Pulse and Effort columns for the first
SWR threshold that was exceeded. This allows different pulse widths and efforts to
be configured for each threshold. When the SWR value is higher, more effort and/or
longer pulses can be used, to quickly move the motor towards a better state. When
the antenna is approaching resonance, slower and/or smaller actions can provide better
movement resolution, and avoid overshooting the best solution. This becomes more
important with faster motors, motor controllers with no braking function, or antennas
with narrower bandwidth.

Each entry in the Pulse column can specify either a pulse length, measured in
milliseconds, or a step count for stepper motors. The unit displayed after each
pulse value shows which type of action will be generated. If a time-based pulse
is to be generated for a given row, the pulse value will be followed by ms.
If a fixed step count is to be generated, the pulse value will be followed by st.
The step-count mode specifies an exact number of steps to advance the motor for a given
pulse action. This allows for more precise adjustment than using a timed pulse.

To change a given value from time to steps, just double-click on the ms unit label,
and it will change to st. That row will then generate a step-based pulse, and
the number specifies a step count. To change back to a time-based pulse, just
double-click the unit again. You can also change the mode by right-clicking on the
unit label, and selecting which type of action you want.

When using a stepper motor, either time-based or step-based pulses can be used, in
any combination, because the controller can generate either type of action for a
stepper motor.

Note that step mode requires an AutoCap controller configured for a stepper motor.

The Effort column will affect the speed of rotation for the motor. For a
typical DC motor, this will adjust the PWM duty cycle, to lower the average motor
current. This allows the motor to be moved with reduced torque, which builds up
less momentum during each tuning action, allowing for faster braking and less
turn-around between tuning actions. On a stepper motor, this field will slow
down the step rate to a percentage of the maximum step rate for the motor.

The Min. Power setting controls the minimum forward power level that must
be present before automatic tuning can begin. This setting exists to avoid
unnecessary tuning attempts when using a sensor that is inaccurate at low power
levels. It also helps the software work with low duty-cycle modes that generate
sparse pulses of power. A minimum value of one watt is recommended for this
setting.

Read Delay Configuration

The Read Delay controls how long the algorithm will wait after generating a
motor action, before reading the SWR again. There are some reasons why this is
important.

When an SWR excursion occurs, the algorithm estimates the next action as best
it can with the information it has, including past actions and optionally the
current frequency. But its initial action for an SWR excursion may be
wrong, for a number of reasons, and it may have to reverse its action to
correct it.

No motor is perfect, and after power is removed, non-stepper motors will
"coast" for some amount of time before stopping completely.
Gear reduction assemblies in the motor, and threaded drive assemblies in
vacuum variable capacitors both have a certain amount of slack in their
movement, especially when reversing direction. Even stepper motors
require a small amount of settling time when reaching their target position.

Likewise, any digital SWR meter is going to have some propagation delay,
both internally and in the communication circuits and operating system
drivers. Even once the motor comes to a stop, and the SWR settles,
an updated reading may still be some fraction of a second away from being
received by the software.

If the SWR is re-evaluated too quickly after a motor command completes, a
combination of these factors may cause the software to "chase itself" when
its first tuning attempt was in the wrong direction. The Read Delay
allows enough time for the motor to stop, and stable readings to be taken, to avoid
acting on premature data.

There are two values for Read Delay. One is used for all tuning actions,
and the other is used only for step counts.

The first value is a constant delay value that is added after each movement.
The system waits for this Read Delay value in addition to the movement time
itself. So if a 100ms pulse is generated, and Read Delay is set to 200ms,
the overall delay between SWR readings will be at least 300ms.

The second value is an additional delay to use per step. E.g., if the value is
1.0 msec per step, and a 50-step value is specified on a given row, the additional read
delay is 50 msec. If the Effort for that row is less than 100%, the
effective read delay is extended further, to account for the slower turn rate of the
stepper motor.

The step-mode Read Delay is adjusted based on the pulse length, because different
stepper motors and controllers will advance at different step rates, depending on how they
are configured, and few of them support any kind of feedback describing when an operation
is complete. Time-based pulse completion can be estimated by simply waiting for at
least the same duration as the pulse width. When performing a specific step count,
this strategy won't work. By adding an adaptive delay, the user can tune the
Read Delay to be compatible with the stepping speed of their specific motor.

Tip:

When using a normal brushed DC motor, braking the motor will allow for smaller Read
Delay values. Unbraked motors will need larger values. I found that when
using an unbraked controller made from relays, the read delay often needed to be nearly
one full second (1000 ms), especially for larger pulse widths. Using the
Arduino-based controller with braking enabled, PWM, and shorter pulses, the read delay
could be as small as 100 to 200 ms, depending on the motor.

Tip:

Using a Radio connection will provide the tuning algorithm with additional data
that it can use to learn how motor actions affect frequency. It may take a few
tuning cycles for it to figure out which direction raises the antenna's resonant
frequency vs. lowering it. Once it has learned which direction is which, the next
time the software needs to make an adjustment, it will have a much better idea which way
to initially turn the motor. This speeds the tuning process and reduces the overall
SWR excursion.

Sensor Tab

The Sensor tab selects an SWR meter/sensor type and the port to which it is connected.

Figure 3: Sensor Tab

Two sensor options are currently available: the LP-100A, and the Arduino-based kit
sensor. Any sensor that emulates the protocol of either of those units can be
used with the software.

If the SWR Only option is selected, the sensor will only be queried for its SWR,
and not for power or other measurements. This is really only useful for the AutoCap
sensor, since the LP-100A always reports all of its data fields. When the AutoCap
sensor kit is being used, this option changes the command used to query the sensor, to
one that only requests SWR, and not power readings.
Motor Tab

The Motor tab selects and configures the motor control circuit type and
communication parameters.

Figure 4: Motor Tab

The various motor connection schemes described above can be selected and
configured. If Polarity is RTS is selected, the RTS line of the
selected serial port will control the polarity relay, and the DTR line will
control the power relay. Otherwise, the relay functions are reversed.

If Enable Braking is selected, the controller will enable the brake of
the motor controller (if so equipped) between pulses, and whenever the motor is
stopped. This allows much more fine-grained control over the motor movement,
and allows shorter Read Delay values to be used. If the controller
has multiple output ports, the Output Port box chooses the port.

If Reverse Motor Polarity is selected, each motor command is always in the
reverse direction of the one commanded. This can also be done by simply
reversing the motor leads, but this setting is provided as an easy alternative.
This allows the up/down manual actions to be matched to the frequency up/down of
the antenna capacitor and motor, and is an operator aid for manual tuning.
The tuning algorithm will figure out which way to turn the motor, based on the
SWR readings, regardless of the value of this setting, or how the motor is
wired.

The AutoCap firmware, described below, can be configured or extended to just about
any motor control circuit. However, any custom controller can be built and
used with the AutoCap software by simply emulating the protocol used in the
firmware. A document is included with the firmware source, describing the
protocol details.

Radio Tab

The Radio tab selects an optional radio interface, that will provide
additional hints to the algorithm about how to adjust the antenna.

Figure 5: Radio Tab

This allows the program to learn which way to turn the motor to increase or decrease
antenna frequency, and helps it to make a correct initial tuning action for any given
SWR excursion. The radio interfaces currently available are the v5.0 of Ham Radio
Deluxe (the free version from Simon Brown, HB9DRV), and current versions of
FlDigi.

When Learning Enabled is selected, the frequency hint data will be updated
each time the loop is successfully tuned. Even when this is disabled, the
existing hint data is used to improve tuning actions. This option simply
enables or disables the learning process, and should be disabled once you are
satisfied with the loop's initial actions for each tuning cycle. This is
provided to prevent an otherwise well-trained profile from mis-learning new hint
data whenever something goes wrong, such as selecting the wrong antenna.

Profiles Tab

The Profiles tab allows the software to configure several antennas, and store
each configuration in a file for easy recall later. In this way, it can quickly
switch between antenna profiles by simply opening a new file.

Figure 6: Profiles Tab

Since each antenna will likely have different settings for controller, polarity,
timing, etc., profiles help keep track of these settings. In addition to the
current settings, the profile will store other supporting information, such as
the accumulated frequency hint data, when using a radio connection.

To create a new profile, we simply configure the settings in the other tabs for the
antenna. Once satisfied with the operation of that antenna with those settings,
select the Profiles tab, and click Save Profile. The software will
prompt for a filename for the profile. To use that profile later, click Load
Profile, select that profile from the list of available profiles, and those settings
will be restored to the other tabs.

When the application exits, the current settings for all of the tabs will be saved
into an unnamed profile. Those settings will be restored the next time the
application starts. So if only one antenna is used, those settings will be
automatically preserved each time the program is restarted.

The Microcontroller

This project started with only relays connected to a serial port. This
arrangement performed satisfactorily for me, but when driven from RS-232 handshake
lines, the timing was not precise. The .Net framework just isn't capable of
generating handshake pulses that are less than a few dozen milliseconds in length.
This led me to use the Arduino platform to provide improved motor control.

The Arduino team offers two very affordable open-source parts that together form
the entire hardware platform needed for a very precise motor controller.

The Arduino UNO R3
provides the CPU and I/O needed to communicate with the PC. There are
several variants of the UNO, including the
RedBoard. Many
of these should be compatible with the firmware, if properly configured.

The Arduino Motor
Shield R3 provides the motor interface circuits. Based on the
L298P
H-bridge chip, this shield is able to independently control two DC motors
at up to 2A each at 12V, or a single bipolar stepper motor. There
are clones of this board as well, but I chose this model because it provides
configurable braking functions for DC motors.

Update, Sept. 2016:
Unfortunately, Arduino.cc has marked the Motor Shield as a discontinued
product. They appear to still be available from
Digi-Key.
An alternative shield providing a nearly identical pinout can be
found here,
and a generic off-board H-bridge can be found
here.
I have successfully tested all three of these parts with AutoCap, and
there are many other motor interfaces that should work just as well.

Figure 7: Arduino UNO R3with Motor Shield

The AutoCap firmware provides a simple textual
interface to the PC. The PC connects to the Arduino using a virtual serial
port provided by the Arduino device driver. When the AutoCap application
on the PC wants to move the motor on the antenna, it sends a simple text-based
command to the Arduino unit, containing the details of the movement action
required. The Arduino is then responsible for controlling the motor with
the timing and effort needed. This frees the PC to concentrate on the
overall control loop, while the controller handles the details.

An UNO R3 and Motor Shield R3 together are the only hardware required to build a
complete solid-state motor controller. They have a combined street price of
around $50. The schematics for the UNO and the Motor Shield are openly
available, and equivalent circuits can be constructed for less, if one is
comfortable assembling the needed components by hand. There are also relay
shields available, and these can also be obtained inexpensively.

Tip:

If the Arduino is used to control relays, it will still produce more precise
timing control than can be accomplished with the PC-based relays. The type of
hardware attached to the controller depends entirely on the pin assignments made
in the configuration file for the firmware. If the motor shield is omitted,
and relays used, both the polarity/power and H-bridge relay circuits are possible
by properly assigning the output pin numbers, and both circuit types can provide
simple hardware braking if wired properly.

The firmware also supports optional user interface hardware, so that the Arduino
unit can be used to manually control the motor with the same precision as the PC,
even when no PC is used. Such operation is described in
a dedicated firmware article.

The Motor Shield has screw terminals for attaching motors and a 12V power source.
It is important to observe the voltage ratings on the product website, both for the
shield and for the controller board itself. I opted to remove the jumper
from the back of the board, which disconnects the controller's Vin
pin from the motor power rail on the shield. This allows the CPU to run from
USB power, and the motors to run from a 13.8V power supply attached to the screw
terminals. This keeps both devices well within their safe operating voltage
ranges. If 6V motors are used, it is possible to run the motors from the
Vin rail of the controller board.

For those who enjoy building their own circuits, the Motor Shield can be replaced by a
number of homebrew circuits, based on the L298P or similar IC. The
shield
schematic is open source, and can aid in building your own motor interface.
The firmware can be configured for designs that offer an ENABLE/DIRECTION/BRAKE interface,
as well as those that offer an ENABLE/IN1/IN2 interface. The difference between
them is the selection of pin assignments. If your motor interface only offers
an ENABLE/DIRECTION interface, you will still benefit from the controller's precise
generation of pulse timing, but you will have to perform motor braking on your own,
or just do without braking. Unbraked motors still work fine, but require more
delay between pulses for the SWR to settle.

When the AccelStepper
library is available, the motor shield can also be configured to support one bipolar
stepper motor, instead of two normal DC motors. There are plenty of other
stepper circuits that are compatible with the AccelStepper library, as well, and
these can also be used by configuring the firmware appropriately. There are
several examples in the firmware's README file, to aid in configuration.

One thing to keep in mind when using the Arduino platform is that the I/O lines
are not necessarily neutralized against stray RF. When running this system
with a 40m loop at higher power (300W or so), I found that the Arduino tended to
pick up stray RF from the 100' of DC power line running from the controller to the
motor. This would cause the Arduino to stop responding, USB device to
malfunction, and the AutoCap program to lock up. Choking the long lead out
to the motor solved the problem for me. I haven't noticed this at 20m or
shorter wavelengths — it seems to only be a problem at 40m. In any
event, proper RFI protection of the Arduino device is something to keep in mind
before applying any significant amount of power to your loop.

Finishing the Hardware

By adding a simple plastic
case, the controller can be made into a more finished product. The
case makes the device much more durable, and prevents the various pins and traces
from making contact with other metal surfaces. This particular case came
with several end pieces, one of which has openings for the power and USB for
the controller, and one of the others is configured to hold two PowerPole
connectors. As a result, the enclosed project is neatly wrapped into a
nice self-contained unit.

Figure 8: Finished Interface with Enclosure

The case is made from a clear translucent polymer, so the circuits can be
seen from the outside, preserving the satisfying "kit" feeling
of the project. The plastic was soft enough that I could trim unneeded
stand-off posts easily with a small pair of wire cutters. Some of these
posts were in the way of either mounting the Arduino, or closing the case.
The case needs a little improvement in a couple of other areas. At least
one of the built-in stand off posts doesn't align properly with the controller
board, and the included fasteners are made of an extremely soft metal.
Assembling and disassembling the case must therefore be done with extreme care
to avoid stripping out the Phillips-style fastener heads. Even with its
flaws, the case is a nice addition to the project, and for $7 US, it is still
worth the effort.

Tip:

The case really only has room to mount two PowerPole connectors. In the
current configuration, that only allows for power input and one motor output
port. It should also be possible to allow the Vin line
from the controller to power the motor, which would allow the power input to be
moved to the coaxial jack on the Arduino, as long as the voltage and current
limits of that connector are strictly observed. This would free the
second PowerPole connector to be used for the second motor port on the Motor
Shield. This would allow the unit to control two motors from a single
USB port. Cutting a custom panel to allow three PowerPole connectors is
also a good option for those with mechanical skills.

Tip:

The case dimensions are such that it will fit one Arduino UNO and one shield,
provided that the shield is mounted nearly flush against the controller.
This was a small challenge, because the Arduino Motor Controller R3 is shipped
with really long header leads. I'm not sure why they did this, but
perhaps they wanted good clearance from the controller board, or wanted you
to be able to easily see the Arduino LEDs even with the shield installed.
In any case, to make the two boards fit the enclosure, I had to trim the header
leads of the motor board slightly. I found that if I used a small spare
breadboard as a guide on the bottom of the motor board, I could trim the leads
to an almost perfect length, so that everything fit together.

The breadboard was simply placed up against each lead to be cut, and flat against
the board, and each lead cut to the height matching the thickness of the
breadboard. Since this trimming allowed the motor board to sit closer
to the controller board, I also had to trim the excess lead length for the screw
terminals, to prevent them from getting in the way of the controller's coaxial
power connector.

CAUTION: If you do any similar trimming to your
board, make sure to wear eye protection while you cut!

Figure 9: Using Spare Breadboard to Trim Motor Shield Leads

Stepper Motors

The current state of the software provides basic functionality for stepper
motors, as described above. These motors can produce both time-based
movement pulses, as well as specific step counts. There are some
things to keep in mind when using stepper motors with the system.

Stepper timing requirements can be very different from normally commutated
motors. The read delays can be smaller, which helps the overall speed
of a tuning action. However, the stepper motors have a much wider range
of speeds available. A 100% effort for a normal DC gearhead motor may
produce two or three RPM, but its slowest usable speed may still be 40% to
50% of its maximum RPM. With a stepper motor, the slowest speed is
nearly zero, and the minimum movement size can be tiny, especially when using
microstepping. However, the top speed of a stepper could be dozens
of RPM. As a result, when using time-based pulses with a stepper motor,
the effort and/or pulse duration may need to be much smaller than when using
a normal DC motor, especially when the antenna is close to resonance.

When using a stepper motor, you may find that the tuning algorithm overshoots
the 1:1 point, and then reverses trying to correct its mistake. If this
occurs with DC motors, it often means that the Read Delay is too short,
or the low-threshold pulses are too long. With stepper motors, it could
also be that the Effort values and/or step counts are too high for the
lower SWR thresholds. It may be easier to start with conservative step
values, and then increase them in small increments, to fine-tune them.

The AutoCap firmware for Arduino includes options for interfacing to stepper
motors by using the
AccelStepper
library, which supports several different stepper configurations.
Basic stepper integration can be as simple as using an H-bridge with an
appropriate power supply. However, there is a dizzying array of
stepper motor types, drivers, voltage and current ranges, etc., and even
the AccelStepper library can't support them all. When using a stepper
motor with the firmware, it is probably best to start with the simplest
interface and configuration that will make the motor work within its
ratings, and then add options from there.

Stepper motors do not produce continuous movement, even when microstepping
is used. Normally-commutated (brushed) DC motors do provide
continuous movement, although controlling these motors with precision is
more challenging than with a stepper. It is therefore important to
select a stepper motor that has sufficient step resolution to move the
capacitor with the frequency resolution desired.

In my experience, when appropriate timings are used, the tuning algorithm is
able to run much faster with a stepper motor than with a normal DC
motor, the final resting state of the antenna is much closer to 1:1, and the
repeatability is much higher. This is because the stepper can run at
higher RPM when the SWR is high, but when the SWR gets close to 1:1, the
stepper can produce very small, accurate movements in rapid succession
without overshooting the target.

Conclusions

Using this combined software/hardware system, I have been able to work contests
with my small loop antennas, moving the VFO up and down each band unpredictably,
and the loop automatically follows me while I operate. This frees me up to work
contest stations and not be continually concerned with the state of the loop.

The system does have some important limitations:

SWR Curve Assumptions - The system depends on antennas that have an SWR
curve that has a single "dip" at its resonant frequency.
It depends on being able to walk
monotonically downward along the SWR curve, from the current resonant
point to the intended resonant point, as the SWR curve shifts under
the control of the motor. This means that the current transmitter
frequency must be close enough to the resonant frequency of the antenna
that the SWR sensor can generate an accurate SWR measurement. Put
another way, if the transmitter frequency is so far from the antenna's
resonant point that the SWR sensor "clips" its reading, the
software may not be able to determine which way to move the motor to
bring the antenna to resonance at the transmitter's frequency.
Depending on the sensor and antenna being used, the frequency hints
provided by the radio may help to overcome this in some situations.
However, the SWR curve dependency is the main limitation of the system
that determines its ability to achieve any given tuning solution.

"Tuned" Antenna Assumptions - The system is not looking
for a local minimum when searching for a tuning solution. It is only
working towards satisfying the lowest SWR threshold configured. This means
that the bottom threshold on the Timing tab must be set to a value
that is higher than the resonant SWR of the antenna across its entire
intended operating frequency range. If the resonant point is found, but
the SWR is still higher than the lowest threshold, the system will hunt, back
and forth, across the resonant point, trying to find an SWR that is lower
than the bottom threshold, and it will never find it. A nice feature
addition might be an option to allow the system to detect this situation
and "give up" temporarily until the next higher threshold was
again exceeded. In lieu of such a feature, careful threshold
selection is very important.

Manual Band Changes - This system won't do automatic band changes.
Due to the dependence on the SWR curve described above, the system
probably won't be able to move the antenna beyond the current band to
which the antenna is tuned. This probably isn't a desirable feature,
either, because it would require the transmitter to send RF constantly
on the new band, while the algorithm searches for the 1:1 point. That
isn't good for the transmitter. Using an antenna analyzer along with
manual tuning is probably the best option for band changes for now. It
is the reason why the outer movement buttons exist on the Status
tab of the GUI application. I normally use monoband loops for each
band, so this isn't a major drawback for me.

Antenna Heating - If the antenna components are subject to RF
heating effects sufficient to change the resonant frequency of the
antenna, the software does not account for that when using a radio
connection for frequency hints. If you notice that the initial
motor commands are in the wrong direction, even when using a radio
connection, it could be that the antenna is heating enough to cause
the SWR to drift. The software will still compensate for the
drift, but it may take a bit longer per tuning cycle for it to reach
a successful tuning solution.

For my purposes, the current state of the system is satisfactory. It
overcomes the one limitation that has prevented me from using loop antennas
more often for contesting. The project took a little longer than expected,
but it was a good learning experience, and I am glad I spent time to put a more
professional finish on the components. I am hoping to further extend the
software so that it can all run on embedded hardware, allowing the entire system
to be used without a PC, and/or used remotely from the operating position.

The software used in the project is available below. As I improve the
system, or refine its features, I will update the downloads list. If you
take a look at the software, or use it for your own project, I would be happy to
hear from you and get your feedback. If you find any bugs, please also
let me know.

Why Another Loop Tuner Project? - The Motivations

There are some very nice hardware-only solutions available for loop motor management, and
they have different features and merits. The reason for using a mostly-software-based
solution here is both flexibility and simplicity. By placing the complexity of the
user interface and the configuration management into the PC software, the design should
allow an experimenter to build up and test a minimal working system quickly.

That's why I did it, anyway.

The Arduino-based hardware components are all available pre-built, which allows
a no-solder kit to be built from very inexpensive prefabricated boards, even when using
the most advanced features of the software. Since the Arduino firmware only
implements motor movement commands, adjustments to the tuner algorithm do not require
firmware changes. All the "brains" of the system are in the PC software,
so any experimentation or customization is done in the familiar environment of the PC,
rather than in embedded firmware.

A software-based solution is also easy to integrate with other software packages.
For example, there are optional features for connecting to HRD 5.0 and FlDigi, which
allows the software to read frequency information from practically any radio on the
market. In a future release, this could also allow SWR information to be read from
radios or amplifiers that support SWR readout, which would eliminate the need for an
external SWR meter altogether. By centering the design around a PC application,
the software has plenty of room for future integration options. When run on a very
small notebook, or a single-board computer such as the Raspberry Pi, the system could
be made part of a portable HF kit.

Some people have asked, why not just use a stepper motor with position feedback, so
that to reach a specific frequency, the motor simply has to turn to a specific
position? In other words, why do I require tuning based on SWR? Others
have tried the position-only approach, with varying success. Unfortunately, the
general-case solution isn't that simple, and here's why... a well-built loop has a
very narrow bandwidth, and the smaller the loop, the smaller the bandwidth.
This means that any change to the environment is going to cause the tuned
frequency to change, for any given capacitor position. If the loop's temperature
changes, or if it is rotated to point in a new direction realtive to other nearby
conductors, for example, the capacitor position for resonance for any given frequency
will change. For that matter, any change in siting, wither by rotation,
or a change in elevation, or moving the loop to a new location in the yard, any of
these things are likely to cause changes to resonant capacitor positions.

I was contacted one day by a ham down under who thought that the SWR-based approach
was too complicated, and he and some fellow hams came up with a solution that just
mapped stepper positions to frequencies. So when the radio dial was turned,
the loop changed frequency. That's great, and I'm glad it worked for them,
but unless their loop was very broad and inefficient, the first cold day they have
will cause them to have to recalibrate their software, because the loop will
drift.

Likewise, a loop on a rotor is a great asset, because you can point the nulls anywhere
you want, but turning a loop is almost guaranteed to change its tuning charactaristics
unless it is high and completely in the clear. On a well-constructed small loop
with narrow bandwidth, a drift of four or five steps on a 0.8° stepper motor might
be the difference between a 1:1 match and a 3:1 match. On a butterfly capacitor,
it could easily be the difference between a 1:1 match and a 10:1 match. Somehow
we have to compensate for loop drift, because it will happen.

The only way to solve this in the general case is to actually measure
the antenna to see where it resonates, and the only way to do that is to
transmit some power into it and see how much reflection you get. Then you
move the capacitor until the loop resonates on the frequency you want. No
matter how you implement it, what I have described is an SWR-measurement-based
solution.

This kit was started mainly for my own use, so I could experiment with the
combination of contesting + loop antennas. But I did try to make it have the
most utility to the most people, by keeping the hardware requirements reasonable
and making the fewest assumptions about the loop construction and motor hardware
that I could. All of the timings and thresholds are adjustable, and all the
software for a working system is open source, so you can customize it if you need
something that I haven't thought about. What that means is that if you don't
like it, you can make it better yourself, and then share your improvements with
the rest of us! ;-)

Software Downloads

Beta versions of the software used in this project are available for download.
Source code is available in ZIP files, and the GUI version of the host software is
also available as a binary MSI installer for Windows. The Linux version of the
host software must be built from source, for now. The firmware is available in
source form, and can be read and installed to an Arduino by the
Arduino Software. The Windows
version of that software contains the drivers needed to talk to a brand-name Arduino,
and any recent Linux distro should already have the Arduino drivers built in.

The software and source is being released under the GPL version 3. The
license is available on the download page.

2014-04-01 - The current GUI source code builds and runs on both Linux
and Windows. The AutoCap.exe executable file can be run on either
Windows or Linux, regardless of where it was built. Note that the Linux
build is still largely untested.

2014-04-03 - The serial code has been updated to be more reliable on
Windows, and may work on Linux. The serial code still hasn't been
tested on Linux. The goal is to eventually have the application
run on either Linux or Windows. There is also a skeleton for a console
mode application that I would like to eventually use with the
Raspberry Pi, so that
the entire tuner can be self-contained using embedded hardware, and not
require a PC. The Arduino firmware for the motor controller has also
been updated to make sure that the host cannot overflow the incoming data
buffer.

2014-04-04 - The WinForms (GUI) application and the new serial code have
now been lightly tested on my Ubuntu Linux box, which is version 12.04
LTS x64, with Mono 3.2.1 installed as described in the first/main answer
described
in this forum article. The code appears to be relatively stable,
but still needs much more testing. If the code proves stable in the
long term, this is the first version that can be used on both Linux and
Windows.

2014-04-05 - The core and CLI have been updated, and the CLI version
now runs on the Raspberry Pi. It has only been tested with the Arduino
sensor and motor interface. The WinForms application doesn't yet run
on the RasPi, because of a TextBox bug in the current Mono package for that
platform. That will likely be fixed by the RasPi team in the near
future. In the mean time, the CLI version appears to be working fine,
and uses an
SMI command set for
configuring and querying the running application. As time permits,
I will expand the interface and document it here. The current interface
is implemented in ProgramCLI.cs, for those who are curious about the
details.

2014-04-13 - The firmware and host software have both been updated to
improve reliability. The firmware has been tested on the
Arduino Mega 2560,
board, and improvements have been made to to the C# software's serial port
data management. I don't have as much time as I would like for long-term
testing, but this update has been lightly tested on both Windows and Ubuntu
Linux.

2014-04-14 - The main PC application has been updated to use a more
reliable way to query the state and version of the motor controller.
During runtime, the version string of the motor controller, the SWR sensor,
and the radio, if available, will be slowly scrolled on the status bar.
Some other minor UI updates, as well. Again, this version has been
lightly tested on Windows 7, and Ubuntu Linux.

2014-04-20 - This update has several small bugfixes to the UI and
core, and a few improvements. Most of my testing has been on Windows.
Please note that this project is still of beta quality, and I am still
tuning and working some final bugs out of it.

2014-06-05 - This is the first update that is capable of driving a
stepper motor. Both the firmware and application have been updated as
described in the text. The previous version is still available in the
download section.

2014-06-08 - This update contains code to work around an update issue
in the LP-100 meter. The issue has to do with how the LP-100 reports
its values when RF power is removed from the meter, and the work-around
prevents AutoCap from using errant samples from the meter.

2014-06-16 - This update fixes an issue where the AutoCap application
would use excessive CPU while running the main algorithm.

2016-03-02 - When using the HRD 5.0 interface for frequency
information, the radio index was previously required to be equal to one.
Now the index is detected at runtime.

2016-08-20 - This update incorporates a number of minor bugfixes and
improvements.