AutoCap Tuner

For Small Magnetic Transmitting Loop Antennas

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

Published: 2014-04-09

Updated: 2018-12-21

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 Telepost LP-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

Figure 7: Arduino UNO R3
with Motor Shield

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.

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 V_in 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 V_in 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 V_in 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.

Figure 10 shows example timings for a 5-foot loop with a 400 step/rev stepper motor, connected to a 3-60pF Comet vacuum variable capacitor:

Figure 10: Example Stepper Timings

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! ;-)

Why No Soft Stops?

Some people have asked me why the firmware doesn't have support for soft stops — that is, inputs that would signal the firmware to stop turning in a given direction because the hardware had reached one end of the capacitor range. Adding soft stops wouldn't be difficult, but they aren't part of the firmware (yet) for a few reasons:

Many capacitor designs simply don't need stops — at all. Most air-variables use continuous motion, which allows the shaft to be turned any number of times in either direction. As a result, these capacitors don't tend to need stops. This isn't a reason per se to omit support for soft stops, but for those capacitors that do need stops, there are more reasons below.
For capacitors that need stops, hard stops are just better. For example, some capacitors use a screw-drive linear-motion shaft drive that can bottom out or unscrew the shaft from the mechanism if the shaft is turned too far in one direction or the other. The vacuum variables are commonly constructed like this. If the hardware you choose needs to have stops to protect the hardware from damage or malfunction, put the protection out at the hardware to be protected, and use it to directly interrupt the power to motor. Hard stops (that are independent of the controller) are the choice of most rotor manufacturers, and many vacuum capacitor prices easily exceed the cost of a nice rotor, so hard stops make even more sense for a magloop that uses such a capacitor.
Stop form is hardware-dependent. That is, depending on what switches or transducers you use for stop detection, the cabling and signaling from those devices to the interruptors can be quite varied. Simple switches may be the interruptors themselves, or they may be part of a more complex latched relay interruptor, depending on the motor used and the desired operation. Some stepper controllers have their own stop inputs, independent of the driving controller.
Similarly, some hard stop devices aren't even electronic. These solutions involve devices like hardware stops (for steppers) and clutches. These are also better than soft stops, because they work whether the controller cooperates or not.
Soft stops require more cabling, and more RFI protection. Wetted GPIO input wires run all the way to the (very) near field of the loop is just asking for RFI, which could interfere with the operation of the stops, and easily damage the GPIO inputs of the controller if not protected very carefully. This is actually another reason to put protection circuits out at the loop, if needed.

Someone may yet make a compelling reason for me to support soft stop inputs in the firmware, but as of now, I can't think of a good one.

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.

AutoCap 1.0 Downloads (Click Here)

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.

2018-12-21 - This update incorporates a number of bugfixes for operating on systems with locales that use comma as a decimal separator. Reading the AutoCap SWR sensor is done in a locale-independent manner.

Links

Small Transmitting Loops - Details of the loops I have built for the contest bands.
Serial/USB SWR Meter - A low-cost SWR meter project that works with AutoCap.
Arduino - Open-source hardware and embedded development tools.
SparkFun - Good source for Arduino and robotics hardware.
AdaFruit - Another good source for Arduino hardware.