USB/Serial SWR Meter

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

Updated: 2017-10-31

The Goal

While working recently with the AutoCap software, I realized that the "weak link" in the system was the LP-100 meter. This device is critical to making the tuning software function, because it provides the constant stream of SWR data used to quickly tune the loop capacitor. The device works well, but I don't want to depend on it for the loop tuner kit, for a handful of reasons:

Price - the LP-100A is an expensive device, and has only once source. Keeping a "spare" around is just not possible for most of us. Just obtaining one is out of the question for many small stations.
Closed - the LP-100A has available schematics, but the firmware is closed source. That's not a problem for an appliance, but I want the AutoCap system to be available as a kit, and all components to be Open Source hardware and software.
Physical - the LP-100A is designed to be used at the operating desk, and it isn't very portable. I would never take the meter to a Field Day site, or anywhere that it might be exposed to the elements. Since many loop users expect their antennas to be portable, it would be nice to have something compact that would travel. The LP-100A also requires an external 12V power source and its current draw is not trivial when operating from batteries. It would be desirable to have an SWR sensor that was power-efficient, and could take its power directly from the attached PC.
Bugs - I don't mean to speak badly about the LP-100A, because it is a great meter that I enjoy using with my station. However, the data output port on my particular unit has some minor update bugs that sometimes prevent it from reporting correct SWR values during an AutoCap tuning cycle. I have worked around all of the issues I know about, but I still wanted something a little more predictable (and maintainable) for this particular use.

The LP-100A is certainly a capable device, and it is is offered as one of the sensor options in AutoCap. However, it isn't the universal solution, and this project is intended to provide a more flexible option.

Getting Real About Requirements

What I really want is a cheap SWR meter for the loop tuning system, that can be easily interfaced to the computer. Those are actually the only two hard requirements in the feature set:

Easily interfaced to a PC
Reliably, quickly, and continuously read antenna SWR

Perhaps more interesting is the list of features that I do not need:

Power readings (forward or reflected). This meter needs only to read SWR, which is calculated from the ratio between forward and reflected power. The first sensor device I will use below is a power meter, but the only data critical to the tuning cycle is the relative magnitude of the two readings, used to compute the SWR. The values of the actual readings themselves aren't required to run the AutoCap algorithm.
Certified accuracy. Accuracy is great, but not always necessary in the quantities to which we are accustomed. For this project, if the SWR reading is close enough to make good tuning decisions, this is sufficient. More specifically, the meter only needs to be 100% accurate at 1:1 SWR. If it reads properly at 1:1, but accumulates some error as the SWR rises, that is fine for this application, because the goal of AutoCap is to continually push the SWR towards 1:1. Of course, if I can make an accurate instrument, so much the better.
Analog meters, a digital readout, LED bargraphs, etc. This is a PC-based meter, to be used only to feed the AutoCap software. That software has its own readout for the important things.

I may add some of these "unneeded features" as time goes on, but for now, the project should start as simple as possible.

The Hardware

This project is mainly about software. For computing hardware, I will start with the Arduino UNO R3, and much of the work will be done in its firmware. The UNO is an easy platform to work with, even for a first project. The only hard requirement for the board is that it have at least two free A/D inputs, and is able to communicate with the PC via serial port or virtual port. Most of the Arduino products fit this description, and the software should run fine on any of them, as long as appropriate pin definitions are used.

I want this project to be flexible enough that any number of sensors can be mated to the controller, and still work satisfactorily with no more effort than a little tuning. However, any SWR meter still needs a sensor, so the first one will be the very inexpensive Universal SWR Bridge from Kits and Parts. This kit is easy to construct, and each complete kit is a whopping $9 US. At that price, I bought two to start with, just in case I ran into build problems with either of them. This kit is rated for 10W, and has two simple voltage outputs, one for forward power, and one for reflected power. This is sufficient to start the project.

The sensor assembly was straightforward, and even with my limited soldering skills, two working boards were built, and one was configured with SO-239 sockets and header pins for easy connection to the UNO R3:

Each of these sensors produces two DC output voltages. One corresponds to the forward power, and the other to the reflected power. Most RF sensors work in this fashion. While testing the boards with a volt meter, I noticed that both of these voltages are considerably less than 5V when the devices are driven within their stated power limits. That allowed me to connect the FWD and REF lines directly to A/D inputs on the UNO R3. In order to prevent stray RF from getting into the A/D circuits, I placed a 0.05uF ceramic disc capacitor between each line and the GND pin. Since the A/D inputs are very high-impedance, and the SWR sensor outputs were meant to drive current devices (e.g., analog meters), I also placed a 75k resistor across each of the 0.05uF caps, to drain the accumulated charge when no RF was applied.

One oddity I noticed with these sensors is that the silkscreen labels on the header pads appear to be reversed. The FWD voltage comes from the REV pin, and vice versa. Working around this is as simple as swapping those two wires, but that was a humorous little bug I found while testing the sensor. I compared the schematic to that given in a presentation on how to build homebrew SWR meters, and the kitsandparts schematic appears to be correct except for the mislabeled outputs. You can look at that presentation by following the link to the NA0TC website, and check whether I am correct. In any event, swapping the wires made my sensor work properly.

A summary of the hardware used includes:

1x Arduino UNO R3
1x KitsAndParts Universal SWR Bridge
2x 0.05uF ceramic disc capacitors
2x 75kOhm 1/6W resistors

The resistors can be any appropriate value, as can the caps. I selected these values from hardware I had available.

The Software

It should be possible to accomplish everything else within the Arduino itself. There is only one essential function of the meter, which is to read and compute the SWR, and report it to the PC through a virtual serial port. The PC interface uses the standard modem interface from the CW project, and contains a small set of basic commands:

SWR - reads and returns the current SWR as a floating point number.
RAW - reads the forward and reflected power readings as raw integer values, in a comma-delimited pair.
PWR - reads the forward and reflected power readings as scaled power (watt) values, in a comma-delimited pair. This isn't needed for AutoCap, but it is a nice touch if the meter is anywhere near calibrated to the actual power levels.
ALL - returns a comma-delimited triple, containing SWR, forward power, and reflected power. This is the command currently used to poll the meter in AutoCap. The power readings are not used unless the minimum tune power in AutoCap is set to something other than zero.
AUTO - enables SWR auto-polling at a user-specified interval; this is an alternative to active polling from the PC. When AUTO is sent with no argument, the current auto-polling interval (in msec) is returned. If an argument is supplied, auto-polling is configured to use the interval provided. An interval of zero disables the feature.
ECHO - enables echo of characters received by the device, to allow the easy use of the device from a terminal; this is mainly for debugging and calibration.

All commands are sent using the standard command wrappers of hash (#) and semicolon (;). E.g., to read the current SWR, the PC will send:

#SWR;

To which the software might reply:

#SWR=1.35;

This one command by itself is enough to implement the SWR sensor function for use with AutoCap, so my next task is to integrate the sensor with that software. However, there will be some more features added later, mostly just for fun. In the end, I chose to integrate the ALL command instead, so that if the power meter provies power readings, they can be used with the optional Min. Power setting in AutoCap. If you integrate a sensor that only provides SWR, you can leave that setting set to zero, and return zeros in the ALL commands two power reading slots. Again, the only required reading from the controller is the SWR.

The command interface described above is in no way special to this particular sensor and firmware. Using this interface, any kind of USB or serial sensor could be integrated into the AutoCap PC software, without having to change any of the PC-side software itself. This is similar to how many rotors emulate the old Yaesu protocol, even though they have nothing in common with the Yaesu rotors. By providing the documentation and a reference implementation, sensor designers can add any SWR sensor they want to the system, and it will work just as well as the one described here.

The modem interface isn't strictly needed here, because there is no data interleaving between commands and data. Everything here is commands and responses, but it seemed like a solid protocol that worked well for the CW board, so I used it here.

LED Fun

I said that visual output wasn't needed for this project, but let's face it, half the fun of working with embedded computers is the chance to attach LEDs, right? And certainly no Arduino project is complete without an LED party, so I thought I would go ahead and add the red/yellow/green SWR bargraph.

Each LED is individually addressable, providing an 11-step visual SWR meter. The images above only show a few states. The code for generating the SWR bar is general, allowing for bar graphs of any size, as long as the controller has enough free digital output lines. So bars of three, five, or eight are just as possible as the one shown here. Larger bars can be done on the Mega. Each LED has its own SWR threshold for illumination.

The variable trimmer resistors you see on the breadboard in the above pictures were used to provide a variable voltage source to simulate the FWD and REV voltages for testing. This turned out to be a big help in debugging, since I don't have to wear out my transmitter in order to test and debug the software. At the same time, using this debugging tool allows me to exactly simulate the conditions the A/D inputs will see during normal operation, for a number of different SWR scenarios.

In addition to bar graphs, adding numeric displays is even easier. I picked up a small number of SparkFun 7-Segment serial displays for demonstration purposes. These displays are standard 7-segement LED blocks, mounted on a "backpack" board. The backpack board contains a microcontroller of its own, that drives the LEDs, and is driven by serial commands from the Arduino. The backpack has several options for interfacing to the Arduino, including SPI, I²C, and TTL-level asynchronous (basically RS-232 at TTL voltage levels of zero to +5V).

The ino firmware file (see Downloads below) has a function called UpdateDisplays() where custom display code can be placed. I added a few lines to write the SWR to the display via the serial port, and keep it updated.

Display Fun

The most recent version of the firmware also supports an LCD or OLED display, which can be used to display forward and reflected power, and the computed SWR. Any display that implements the basic Arduino LiquidCrystal interface can be used. An example OLED display output is shown below.

The OLED looks really nice and would make a great permanent meter display. However, I discovered that powering the OLED from the 5V output pin of the Arduino added considerable noise to the A/D readings. A production circuit should probably use a dedicated 5V regulator to power the OLED, so that the Arduino's voltage supply is left steady enough to take good A/D readings, especially when using the readings for automated purposes, such as with AutoCap.

The customization possibilities are endless, but the idea is that you can use the SWR firmware as-is, or add small amounts of custom code to drive your own displays, in addition to the existing USB interface to the PC. The main goal of the project was to have the USB interface to the PC, so that AutoCap could read the SWR from a homebrew meter. That said, lots of blinking lights add a lot of fun to any homebrew project. They also provide a certain amount of instantanous visual feedback, that can be helpful for diagnostic purposes.

A/D Processing

The current code uses an exponetial smoother on the forward and reflected readings taken from the A/Ds. As a result, the SWR value computed from those readings is also smoothed. The value of alpha can be set independently for both forward and reverse readings, and the updated values can be saved to EEPROM, so that they will be reloaded when the device is restarted.

The alpha values can be read with:

    #ALPHAFWD;

...for foward alpha, and...

    #ALPHAREF;

...to read reflected alpha. To set the alpha values, use:

    #ALPHAFWD=value;

...for foward alpha, and...

    #ALPHAREF=value;

...to write reflected alpha. The alpha values must be in the range between 0.01 and 1.0. A high value of alpha performs very little smoothing, and produces the most responsive readings. Lower values of alpha will smooth out the readings more, but the response will be somewhat slower.

If EEPROM persistence is enabled in the main .ino file, the alpha values will be persisted whenever they are changed using the above commands. After first installing the firmware, the EEPROM should then be prepared by sending a single write command:

    #EWRITE;

This will format the EEPROM for use with the SWR meter firmware. If this step is omitted, the meter will still run, but it will not update the EEPROM when settings are changed. Once this command has been run one time, further updates will be automatic, whenever either alpha value changes.

Coupler Alternatives

The firmware can be modified or extended to just about any kind of directional coupler that generates two DC output voltages, one for forward power, and the other for reflected power; or to a sensor that has a single DC output voltage corresponding to actual SWR. If you want to build a meter with more power range than the one shown here, you will need a higher-power coupler.

A starting point might be a device like the Elecraft CP-1. This device claims a range of up to 250W, and has two outputs. You will need some kind of rectifier and buffer circuit to attach this to an Arduino, to generate the zero to five volts (but no more) DC needed by the controller's A/D. So some design work is required to interface a unit like this. Even so, the list of homebrew and kit options is probably endless.

All of the Arduino products based on the 8-bit ATmel processors will have an A/D input resolution of ten bits. That gives you 1024 possible voltage measurement steps from zero to full scale, or about 0.1% of full scale per step. A meter that reads 5V at 1000W power will have a resolution of about 1W. A meter that reads 5V at 100W power will have a resolution of about 100mW. Keep this in mind as you set the full scale voltage of your transducer.

AutoCap Integration

Integrating the meter into AutoCap was straightforward, and the software now offers to use any working sensor based on this kit:

One note to using this project with AutoCap: the AutoCap firmware for Arduino and the SWR meter for Arduino are two separate sketches. That means that each one requires its own controller. Some people have written to me asking about merging the sketches onto a single board, but since both sketeches are running real-time tasks, they really don't belong on the same microcontroller. This is especially true when using the AutoCap firmware to drive a stepper motor. When tuning, each sketch needs to be as responsive as possible, and having independent microcontrollers is the most straightforward way to ensure this.

It should be possible to merge the tasks onto a fast microcontroller, like one of the newer Teensy boards, but I have no need of that, and I haven't heard from enough people to do the work for others. :-)

Someone mentioned (complained) to me that two Arduino boards is almost $50, even without the coupler or motor controller components. This is true if you use branded UNO boards from Arduino.cc. But there are all kinds of very high-quality boards that can be used for this project, including some that are designed to be embedded in larger projects. Here are a few of my favorites for people who want to try this project in a cost-conscious way:

SainSmart UNO - currently $10 in singles. This board is essentially a clone of the Arduino UNO, with the same processor and USB connector.
Sparkfun Arduino Pro - currently $15 in singles. This board is designed for embedding in other projects, and the host port is a TTL serial port. To connect this to the computer, you will want either an RS-232 level shifter or an FTDI converter.
Sparkfun Arduino Pro Mini - currently $10 in singles. This is an even smaller version of the Arduino Pro, but functionally identical, with the same host port connection options. This board even provides two extra A/D pins than any of the other UNO replacement options.
Sparkfun RedBoard - currently $20 in singles. This board is an upgraded clone of the Arduino UNO, with a USB mini connector and an SMT processor and prettier LEDs. The host connection uses an FTDI chip, which is nearly universally supported on all popular operating systems.
SparkFun Arduino Pro Micro - currently $20 in singles. This board is similar to the Pro Mini, but it includes a USB micro connection for the host connection.

There are plenty of other inexpenive options, as the Arduino UNO is one of the most-cloned hobby boards. Just search the internet for "Arduino clone" and you will find all kinds of boards that should work fine. Even the Teensy boards should be able to work for either the AutoCap or SWR Meter firmware.

With a little shopping, it should be easy enough to get two controller boards to match your needs for around $20.

Conclusions

A simple, inexpensive, USB-enabled SWR meter is definitely possible and practical using open-source hardware and designs. This project is ongoing, so there will be more updates to come. The main goal has been accomplished, which is that the whole AutoCap project is now Open Source Software, and Open Source Hardware.

Software Downloads

2016-09-20 - The alpha values are now split into forward and reflected values, and can be set via host commands. Settings persistence has also been added.

2016-09-18 - The software has been updated substantially, to add LED/LCD display support, and to make configuration more consistent. Also, some bugs were found in the SWR reading and calculation logic which have been fixed.

2014-03-30 - The current software is available for download. The firmware is only available in source form, and can be read by the Arduino Software.

SWR Meter 1.0 Downloads (Click Here)

The source is being released under the GPL version 3, which is also available on the download page.

Links

AutoCap Version 1 The main AutoCap project page.
Kits and Parts - Open-source hardware for ham projects.
NA0TC - Homebrew SWR Notes
Arduino - Open-source hardware and embedded development tools.
SparkFun - Supplier for Arduino boards and hardware.
AdaFruit - Another good source for Arduino hardware.