Analyzing an Absurd Attenuator

I made a last minute decision to enter the CW NAQP (North American QSO Party) this past weekend. My contesting ambitions are muted during the warm summer months and my station is a shambles, as those of you following the blog will know. The weather on the weekend was so hot and humid that staying indoors with air conditioning was too tempting.

With several antennas not available, a competitive effort was off the table. I am also several months out of SO2R practice. On a whim I decided to enter in the QRP class. By thus lowering my expectations I could relax and enjoy 10 hours of summer contesting.

Choosing QRP caused one small problem. The primary radio, a FTdx5000, can only be lowered to 10 watts. I ran into this once before and I built a 3 db attenuator capable of dissipating 5 watts of CW or SSB; it wasn't robust enough for key down, and that isn't necessary. Not expecting to do QRP again with that rig I repurposed the aluminum enclosure for another project. 

I did keep the core of the attenuator -- a π resistor network -- storing it in a small plastic bag. I should get rid of lots of junk I've accumulated over the years, but the attenuator hardly takes up any room. The greater danger was misplacing or losing it because it's so small. But there it was in a drawer of the operating desk and I pondered what to do. 

I was in no mood to spend the time punching holes in another enclosure for a one-time use. So I improvised. With a couple of SO239 jacks, wire and a few minutes solder, I produced the monstrosity below.

No, you should never do this! RF circuits need be wrapped in a conductive enclosure to keep RF in and to keep RF out. But it worked after a fashion. With a calibrated load on one end the SWR gradually rose with frequency, reaching about 1.15 at 30 MHz. That's pretty good, and better than I had any right to expect. The power meter read about 5 watts, so the primary objective was met.

The 3 db of attenuation on receive was no inconvenience: any signal so weak that 3 db would make it inaudible is someone I'd never be able to work with QRP anyway. On bands below 10 meters even that is irrelevant since atmospheric noise dominates the SNR.

Knowledgable readers will see that there is are potentially serious drawbacks of the open air design, related to those already mentioned. Any nearby noise source would leak into the receive path, and on transmit the leakage could affect the receiver of the second radio (for SO2R).

Tuning across the 10 meter band where the problem should be most severe, I heard a number of electronic noises that are likely coming from computers in the shack and other electronics in the house. The spurious signals were strong enough that I decided it would be worthwhile to deal with it. After about 30 seconds of not-so-serious thought I invented version 2. It took another 5 minutes of my time.

This proves that monstrosities can be made into truly absurd monstrosities. A strip of aluminum foil stolen from the kitchen was spirally wrapped around the attenuator and firmly taped to the SO239 jacks for a conductive seal. The exposed leads and resistors connecting the centre pins were taped to avoid shorts when the foil was wrapped.

Yes, this is a monstrosity but it is a better performing monstrosity. The spurious signals dropped at least 20 db. The SWR also improved, though only slightly. The contest start was rapidly approaching so I declared the project a success and spent several minutes readying the rest of the station. The attenuator worked flawlessly during the contest.

A couple of days later I contemplated what to do with it. I can spare the connectors so it could go back into storage. I didn't expect the foil to survive storage so I prepared to remove it. I stopped and wondered how it truly performs. I pulled out my VNA and put it to the test before ripping off the foil.

I measured S11 (SWR) and S21 (insertion loss). I did the S11 measurements with a calibrated load. The result changed a small amount when I added a coax jumper to facilitate the S21 measurements. The test setup is shown above. I did the measurements with the foil covering first to best reflect its performance during the contest, but I'll show the VNA plots in the order I built the attenuator. The foil is too fragile to survive a second wrapping.

The coax jumper is not the best, which explains the higher SWR than what I measured when it was first built. The calibrated coax tails from the VNA are too stiff and short to connect to both ends of the attenuator without using the jumper. An SWR of 1.2 on 10 meters is pretty good. No tuner is necessary to prevent the transmitter from folding back power, and in any case the antennas are responsible for most of the higher SWR where it does occur.

Insertion loss is slightly less than the required -3 db to drop 10 watts down to 5 watts. The power meter read very close to 5 watts on both 20 and 10 meters, so either the meter is misreading or the transmitter is not quite accurate on the power setting. Setting and measuring RF power is something of a black art and accuracy requires careful test methodology and calibrated instruments.

My measurement of the RF power is good enough for amateur work, and for a one-off application at that. In the worst case the BPF add an insertion loss of from -0.2 to -0.5 db, depending on band, so I was easily at or below 5 watts even if I started with 5.5 watts.

This plot is with the aluminum foil wrapping. The foil has a negligible effect on the insertion loss, which is no surprise. The improvement of the port impedance is more significant. The reduction of common mode and radiation into and out of the attenuator are likely responsible. The measurement data support what was already evident from the sharp reduction of spurious signal reception when the foil was added.

Many readers will have no doubt thought up ways to improve the attenuator. Well, so have I, but that was not the point of the exercise. I wanted it to be quick and functional for a single operating event. For example, with 15 minutes of work I could have run wires between all 4 corners of the jacks to improve it mechanically and electrically. I deliberately avoided doing that.

Finding the optimum balance between excess effort and poor performance is never easy. Others in the same predicament might lean either toward higher quality or shoddier construction. I simply find it interesting how much can be accomplished with a minimum of effort when you understand the underlying physics and mechanics of what you're doing. 

The less you understand the more you tend to overbuild or underbuild. The same is true of almost everything in our stations: antennas, towers, small accessories and more. A little knowledge goes a long way. Amateur radio offers an ideal playground to learn, and to practice what you learn. 

I hope you enjoyed this (slightly) silly midsummer distraction.

Frankenstein's Prop Pitch Motor

When we last visited my malfunctioning prop pitch motor, a variety of problems were evident. After that article was published I proceeded with a complete disassembly of the gearbox. That uncovered more problems; poor low-temperature performance was the least of them. 

Several bearings were in poor shape. Among those are the 6 bearings supporting the 3 low-speed planetary gears. According to K7NV, perhaps the foremost expert on prop pitch motors, they have no modern equivalent. I was able to confirm that with extensive catalogue searches. Note that I'll be citing the K7NV web site numerous times in this article. If you have an interest in prop pitch motors you'll enjoy browsing his web pages.

I can try to repair the bearings or I can fabricate shims to accommodate the closest alternative. With the oil and grease removed in a solvent bath there are two of the group that exhibit damage to the races and/or balls serious enough to warrant repair or replacement.

Another difficulty is the sleeve on the motor end of the gearbox axle. It has splines that match the motor shaft splines and the sleeve cannot be removed with any jig I could cobble together in the workshop. I'll have to take it to a professional.

None of these are insurmountable problems, but it will take time. Summer is running away from me and I need the 15 and 20 meter stacks to be fully operational before the fall contest season. There are many other jobs to be done and I can't spend all my time on one motor. 

In the midst of these woes the elderly father of a friend of a friend was downsizing and had a small prop pitch motor for sale. After speaking on the phone and reviewing pictures of it I went ahead and bought it, sight unseen. The price was attractive, especially since it came with a DC power supply and rudimentary direction indicator. A friend picked it up and saved me a long drive.

When it arrived I connected it to my existing controller and got a big surprise. The motor turned at 4 or 5 rpm. That's much faster than the more typical rotation speed of 0.6 to 0.75 rpm. I called the seller and he, too, was surprised.

He had never opened the gearbox and had no idea that it was performing in any way that was unusual. The motor has a long pedigree of many owners, lost in the mists of time. Like those earlier owners, he controlled the speed with a Variac or similar voltage rheostat; that is; with a voltage below the nominal 24 VDC. Not everyone is a prop pitch motor expert -- it works to their expectations and that's that!

I refused his offer to refund my money. The spare parts and electronics are worth the price. However there was still a mystery to be solved. I had a vague recollection that some early owners of prop pitch motors modified them to run at a higher speed, or lower voltage. I had never come across one before and I was curious how it was done.

It turns out that the way it is done is horrifying. A friend dug through his extensive prop pitch motor library and found an article from a 1949 issue of CQ magazine that described the mod. It's a non-reversible mod that destroys a critical component of the gearbox. 

With trepidation I opened the gearbox. I could have been more careful about it because a quantity of machine oil poured out and splashed over the workshop bench and floor. Almost everyone who converts these motors for rotator service drains the oil and does not replace it. The oil is removed to prevent fouling the motor when it is mounted upside down. The oil seals are not perfect and the original bearings are open and need to splash through the oil reservoir. 

The usual procedure is to replace the original bearings with modern sealed bearings and to grease the gears. That wasn't done for this motor. However, the oil seals seemed to be working well.

After cleaning the mess I discovered that the motor was indeed modified per that 1949 article. In the picture I am pointing at the cut edge of the large bell gear. The bell gear of the motor being repaired is shown for comparison. 

The smaller diameter gear of the low-speed planetary gears have nothing to mesh with. Steel plugs (one is shown) directly couple the oil channels of the bell gear and the carrier for the low-speed planetary gears. One stage of speed reduction is thereby eliminated.

It is an atrocity to do this to a perfectly good prop pitch motor. Or is it? A digression to review the historical context is enlightening. 

After WW II, these motors were often easily and cheaply acquired on the US military surplus market. Indeed, many ham shacks of the late 1940s and 1950s were filled with war surplus transmitters, receivers, cables and other odds and ends. Few hams had towers and yagis, and large rotatable HF yagis were very rare indeed. It was still the early days of broadcast television and the mass market for rotatable TV antennas and rotators. Many hams made their own rotators.

A 24 VDC power supply was easily built, and everyone knew someone who could do a little machining and welding to adapt the motor to a tower plate and mast. But the motor turns slowly and it makes quite a lot of noise for a suburban neighbourhood. Bypassing one stage of reduction in the gearbox speeds up rotation too much, so the motor voltage is reduced to compensate. The motor is much quieter when run at only 1000 to 2000 rpm. Problem solved. That is, until a ham like me comes along decades later.

So, the modification is not an atrocity, just a disappointment. I considered options. The motor mounts and housings are of a different design and it was no simple matter to substitute components from one motor housing to the other. Over the ~25 years these motors were produced there were a variety of engineering changes, not all of which were backward compatible. The mast drive system on the new motor is well done (see pic at the bottom of the article) but it, too, is not easily retrofit to my mast and I am not going to take down the 15 and 20 meter yagis and mast to do it.

I pulled the planetary drive assembly from the gearbox to compare it with the malfunctioning unit. They are identical, right down to the part numbers stamped or printed on the components. All the bearing and gears were working properly.

I decided to mix parts from the two dead or half-dead prop pitch motors. Hence the reference to Frankenstein in the article title. 

The critical step was to drop the newly acquired planetary drive assembly into the old housing. That sounds straight-forward, except that I ran into a few complications.

The first thing I did was a cold temperature test of the assembly. As I did to diagnose the problems with the one I pulled down from the tower, I placed it in the freezer overnight. Not all oils and greases have a temperature range to match our climate.

The next morning I checked all the bearings and they spun freely. The oil didn't noticably thicken. Condensation moisture gradually evaporated and did not appear to foul the oil residue. This is important since despite the best waterproofing moisture will condense inside the housing at night when the relative humidity is high. Condensation and freezing fouled a couple of the open and improperly greased bearings in the old planetary drive assembly, which contributed to its poor low-temperature performance

Without the oil bath to keep the bearings and gears lubricated, grease would have to be applied. I was not prepared to fully disassemble the planetary drives to replace the bearings with sealed units. It would take too long and there was a risk of damaging something.

I may pull the motor down again next year to inspect the durability of the lubricants and bearings. At this point I simply need it to survive the coming winter and contest season.

I bought suitable wide-temperature range oil and grease, oiled the bearings and packed grease where I could. Gear cogs were heavily coated with a water-resistant grease as recommended by K7NV.

In the picture the oiled and greased planetary gear assembly is pressed into the motor side of the old housing, along with the ring gear that is sandwiched between the halves of the housing. The only thing left is to press the large bell gear onto the assembly and the gears of the low-speed planetary drive. That did not go well.

There is a trick to mounting the bell gear that is due to the asymmetry between the gear cogs that engage the ring gear and those that engage the bell gear. I assumed they were aligned since the assembly showed no obvious sign of having been taking apart in the past. No matter what I did the bell gear would not fit.

Checking the alignment was a messy job since the gears were heavily greased. There are alignment marks on the 3 low-speed planetary gears that must all be oriented outward. I posed one of these gears of the disassembled planetary system to illustrate the procedure.

I removed the ring gear and rotated the planetary drive while wiping grease off the upper surface, searching for the alignment marks. Two of the gears were aligned but not the third. It had been disassembled in the past and not correctly reassembled. You can do that with the modified gearbox because the ring gear will engage the planetary gears no matter how they're oriented.

With a long sigh I removed the nut from the axle and pried off the top bearing and low-speed planetary drive. With the cogs disengaged from the gear on the bell gear for the high-speed planetary drive, the gears were aligned and then carefully pressed back onto the axle and spur gear. Despite being covered in grease up to my wrists I grinned when the bell gear easily dropped onto the planetary drive gears. 

I repacked the grease and proceeded to finish the job. Mostly this consisted of cleaning the remaining half of the housing and renewing the seals. Waterproofing the coupling to the mast is a separate task that I've already begun. I temporarily used a small number of bolts to hold the housing together and secure the motor to the housing. There were two tests to be done before the rebuild could be considered complete.

It was more convenient to take the motor to the controller than the opposite. Well, sporadic E season isn't quite over and it's easy to monitor or operate digital modes on 6 meters while testing the prop pitch motor. I gave it a lengthy spin in both directions and it behaved as it should. Rotation speed is the same as before, which is about 100 seconds to turn 360°. The motor on the other tower does the same in 80 seconds. I have an idea why it's slower but that will have to wait for another time, perhaps in 2023.

I removed the motor and freezer tested the reassembled gearbox for low-temperature performance. That went well so I remounted the motor and installed all the bolts holding the components together.

Assuming no new obstacles intervene, the motor should be back in service by mid-August. I am making a few changes to the mast coupling system to better centre the mast coupling and to keep water out of the motor. Although the drive system appears to be well sealed there's clear evidence that some water is leaking into the crown gear and from there into the gearbox. That's another good reason to use sealed bearings throughout.

I cleaned the waterborne rust that coated the inside of the hub. It was washed down from the unpainted coupling pipe. The high quality steel comprising the prop pitch motor housing and parts is almost immune from rusting.

I'll resume work on the disassembled gearbox when I have time this winter. I plan to rebuild it with sealed bearings and, hopefully, repair the damaged bearings on the low-speed planetary drive. That will give me more prop pitch motor service options for next year and beyond.

One final point worth mentioning is that the recently acquired motor has an adapter plate. This is ideal for keeping water out when mounted upside down for rotator service. Unfortunately I had to set it aside since the mast coupling system I built isn't compatible with it. It seems a shame to waste so I may try a retrofit in future.

I've learned a lot about prop pitch motors while doing this repair job. I am no longer shy about cracking them open and getting my hands dirty, literally! They are truly impressive devices.

Station Automation: Design Choices

After abandoning the physical interface for the antenna controller I am building I ran into several challenges. The fully software solution certainly required additional software components to be designed and built. That wasn't the problem. The problem I faced was an entire vista of possibilities to choice from. A physical UI (user interface) with buttons, LEDs and switches imposes constraints that limit the possibilities. Those constraints were suddenly gone.

The second problem was one very common to software development: feature creep. I was no longer limited to transferring a physical UI to a software UI. There was more opportunity to plunge into a bottomless barrel of station automation features that I've planned for some time. I found it beneficial to accommodate the future features into the design and UI use cases. As I did so, all those future features became current features. The incremental effort to include more sooner rather than later is not that great.

The antenna switch has morphed to incorporate the following station automation functions:

• Two radios, for SO2R and multi-op
• Selection of BPF
• Automatic antenna selection on band changes
• Prevent hot switching
• Integration with CAT and logging software
• Selection of non-contest band antennas
• Primary and secondary antennas per band
• Sharing and selection of multi-band antennas

Amplifier band switching would be included if I had amplifiers capable of it. Among other features, this will be deferred to a future version.

Objective of this article

This is not a how to guide. I won't show code, tell you how to code, how to solder or how to design the circuits, layout and cabling. What I will discuss is to approach a project of this magnitude. It requires developing a set of design objectives and framework to reach those objectives. My way is not the only way, but it is one that works.

By showing my thinking process for the design it may give you ideas and insight. Even if you would never undertake a similar project -- and that includes almost everyone reading this -- I believe you can still benefit. One benefit is that by thinking through what you want and need for a station controller that suits your operating style and station design. 

Ergonomics are critical for contests. For less intense environments we can usually work around deficiencies. Some find a measure of enjoyment from complaining.

The second benefit is to help you evaluate the large and increasing variety of commercial products, open source software and kits for station automation. Once you have a good understanding of what should work best for you, you can make informed decisions. Without a guide of some kind or previous experience, it can be very difficult to see past the enticing promises in colourful ads to make a careful analysis.

It may be helpful to read about some of the more popular choices that currently exist. Even if you never choose them you will learn how others propose to solve the problems of station automation. A few examples include:

• K1XM MOAS (mother of all switches)
• GHE (Green Heron Everywhere)
• 4O3A
• Hamation
  

There are more, many more! I am not trying to be all inclusive so don't be upset, or tell me, if I omitted your favourite. Many of the popular contest and non-contest logging applications provide interfaces for controlling commercial products or allow you to develop your own, as I am doing.

I apologize if the text is tough going in places. By going into detail there is a lot to read, understand and ponder. There are a few pics and diagrams, which may not be enough for every reader. Composing diagrams those takes time that I don't have. Perhaps the most difficult section to read is the UI. Since that is the key to the rest, it's where I'll start.

User interface (UI)

The UI is what you see and what you touch. It should be so intuitive that you can use it without reading a manual. Indeed, if done well you will hardly need to interact with it at all. After all, this is supposed to be station automation. 

The system should figure out what you need and do it without fuss. As a boss, you should prefer an employee who anticipates your needs, then does it and let's you know that it's done. Or would you rather one you must walk through every step of every task, or one that requires constant oversight?

Below is an annotated screenshot of the UI as presently built. The ugly and missing bits of the UI will be dealt with in due course. But it already does quite a lot. Let's walk through the major sections without worrying about how pretty it isn't.

The top row has 4 buttons and a status bar in the centre. Green is good. At the time of the screenshot, N1MM was connected to the left radio, and it is on 20 meters. When the antenna selector is complete, the antenna names will appear on their respective buttons. 

If the radio button goes yellow or red, the UDP broadcasts have gone missing. R2 is white because there is no right (second) radio. When N1MM becomes aware of a second radio (multi-op or SO2R configuration) the automation software will adapt to the new configuration.

The COM port, speed and status for the Arduino switch provides the basic and critical information. The colour changes as communications is started, interrupted or resumed. When not green, all button presses have no effect. If the Arduino is alive, all switch states should persist. This is not true if the Arduino resets for any reason.

Buttons are used for the radio and antennas to allow manual override. When N1MM communication is lost, or N1MM loses the CAT interface, press the radio buttons to advance through the bands. Antennas and BPF will be selected as usual. In normal operation, the antenna button is used to choose an alternative antenna for the band.  The TH6 tri-bander is not primary on any band. It can only be selected by pressing the antenna button to set through the available selections on the high bands.

An antenna in use by the other radio will be skipped during the selection process. All the antennas are presented for selected when no band information is available. This cannot be done for the BPF so the operator must revert to manual control of the BPF. The last selected antenna for each band is recalled when returning to that band, unless that antenna is not available.

The 6 stack buttons are used to switch the mode of the stacks for 20, 15 and 10 meters. BIP  is the default, and the high and low yagis can be individually selected. The high yagi button turn blue when it is selected, and the low yagi turns green when it is selected. Blue sky, green grass: get it? Both button are lit for BIP. It is never the case that neither button is lit, except briefly during initialization.

To go from BIP to upper (or high), press the "Hi" button. To switch to the lower, press the "Lo" button. To return to BIP press whichever button is lit. I find this intuitive though others might disagree. I find it less intuitive (see the 20 meter selection in the screenshot above) to press the "Lo" button to select BIP.

The 3 sets of buttons for the low contest bands (160, 80, 40) are similar except there is no BIP since they are not stacks. You can choose either the high or low antenna, and not both. Pressing a button changes the antenna for the band, but the selection is not made unless the band is in use. In other cases the chosen antenna will be selected when moving to that band.

When currently on the band for the pressed antenna button there is an alternative. Press the radio's antenna button to step through the antennas for that band. For this use case, either method will work. They are not equivalent since there can be more than two antennas for a band.

The operators in a multi-op need to be careful not to alter the antenna or mode for the other station; the UI doesn't know whose hand is clicking the buttons! With a dedicated UI for each operating position, a feature will be added to restrict the operator to only being able to change antennas and modes on bands not occupied by another station.

High and low choices for the low band antennas require additional explanation due to the unique configuration of my station. 

The 80 meter 3-element yagi is the high antenna, despite being ground mounted, because it has the lowest elevation angle of radiation. Likewise, the big 160 meter antenna is the high one because it has the superior performance compared to the 160 meter mode of the 80 meter yagi. Of course when the 80 meter yagi is in use, the other radio can't select it for either 80 or 160 meters. 

Pressing the 80 meter yagi button when it is already selected and it is not in 160 meter mode, switches between SSB and CW. When in SSB or 160 meter mode the direction buttons are disabled since the antenna is omni-directional; if the antenna changes in future, the UI behaviour will also change. For 80 meter CW mode, the direction buttons select the direction. Pressing the button of the active selection selects the CW omni-directional mode; that is, yagi mode is disabled.

When the 80 meter yagi is in use on 160 meters, the 80 meter direction and mode buttons are ignored. You can switch between 80 and 160, and if there is no other 160 meter antenna available the mode of the yagi will be automatically selected. However, if the other station is using the antenna on, say, 80 meters, it will be unavailable for 160. It sounds complicated but I expect that it will be easy to understand in practice.

The Beverage buttons work similarly to the 80 meter CW direction buttons. Since there is no omni-directional mode, when no Beverage direction is active the system is off. That is also the default. It is complicated to have the software instruct the radio via N1MM and CAT to switch the receive antenna port in and out. It is also radio specific and requires injection of proprietary commands. It is a consideration for the future, but with a low priority.

Antennas that are not available cannot be selected. They may be disconnected for maintenance or, like my big 160 meter antenna, when the radials are rolled away during haying season. The selection algorithm skips over these antennas, similar to the skipping of antennas in use by another radio.

UI appearance will be improved after it is operational. Right now, it is far more important that it works. Despite its ugliness I like that it is compact: screen real estate is precious. More computer displays can be added but all those displays, while pretty, can be a distraction and a nuisance during a contest.

Conflict is inevitable

There are two kinds of conflict we must deal with: two stations vying for the same antenna, and two stations vying for the same band. The UI, Arduino and antenna switch resolve contention for the same resources. However, the operators (or a confused and tired SO2R operator) will have to negotiate or back off without forcing the issue.

You cannot "steal" an antenna. Another antenna will be automatically selected or one station will be blocked. In the first case, this can occur with multi-band antennas, of which I have two at the moment for contest bands: a tri-band yagi (TH6) and the 160 meter mode on the 80 meter vertical yagi. For WARC bands, there is additional conflict since I use a tuner on non-resonant antennas. It is rarely a problem in daily operating since only rarely are both stations active.

To select an in-use multi-band antenna requires that the other station choose a different antenna. Only then can the antenna be selected by pressing the antenna button on the UI. I have no triplexer or similar antenna sharing technology.

In the case of a band conflict, no antenna will be selected. The BPF can be selected anyway because with the antenna line grounded there is no significant risk to the receiver from the kilowatt next door already on that band -- I will revisit the issue if there is a problem in practice. The antenna names are displayed on the antenna buttons. I haven't yet decided which of several alternatives to use to provide feedback when there is a band conflict.

The purpose of conflict resolution is to make the system idiot proof by doing something sensible while the operator(s) decide how to proceed. We all become idiots late into a 48 contest due to brain fog and fatigue. Mistakes will happen even when we are fully alert. We're human.

What the software can't do is resolve conflict between operators. They'll have to work it out together.

Configuration vs code

Users should be able to configure a product for their unique needs. This is mandatory for commercial products that are installed in diverse stations. I have another option because my software is solely for my own use: station configuration changes can be done in the code.

Configuration is nice to have but not necessary for custom software. My antennas and peripheral equipment will change infrequently and developing software to allow configuration from the UI can be quite complex. I know, I've done enough of it. 

For a first version it is acceptable to hard code everything. However, that does not imply that software behaviour is inflexible. The internal structure allows for rapid changes using suitable levels of abstraction. As time allows in the future I will add configuration options to the UI.

Example of the configuration that are currently being hard coded:

• COM port and speed for connection to the Arduino
• GPIO pins for the multitude of relays and switches
• Antenna names and band assignments
• Communication protocol elements on both the Arduino and PC
• Antenna availability: for example, the big 160 meter vertical is unavailable during the farming season when the radials are rolled away

An alternative that falls between the extremes is a configuration file: an ".ini". Each line contains a parameter name and a parameter value. For example, "ArduinoPort:COM5". I will look at this option after the first version is complete.

Data dependencies

Software and hardware does not exist in isolation. Station automation requires requires data transfer to and from other station components. Data dependencies includes:

• Band and frequency
• Transmit/receive status
• Operating systems and software platforms hosting the station automation components
  

My original intent was to connect the system to the band data ports of the radios and convert the signals to the band number. There would be no frequency data unless the software also connected to the rig CAT interface. However, the CAT interface is used by the logging software. 

There are ways to listen to the CAT traffic directly even with another application using it, but that adds complexity and is unique to each vendor. Radios come and go and each with its own proprietary protocol is a serious challenge. I have no good reason to do all that work. The good news is that there is no need.

Since I am now use N1MM Logger+ for contests and for daily operating I decided to use its UDP broadcasts for pertinent data for the one or two radios it can control, and let it deal with CAT. The UDP message content is the same regardless of the radio models. That saves a lot of work, but it comes at a price.

I am now dependent on N1MM. Without it my station automation does not function. I would be in the same position with a commercial solution, like one of those listed above. Indeed, there is a name for it since it is a common dilemma in the technology industry: vendor lock in. Vendor lock in isn't necessarily bad and, as we see with N1MM, it can be quite beneficial. Weighing the pros and cons must be done with care.

By choosing Arduino for the switching functions and a UI on a PC, I am committed to those platforms going forward. They can be changed with work, and it can be a substantial rewrite. For the UI, I limited my dependency of the computer technology and OS (operating system) by using Python and the tkInter UI package. With these choices the software can be moved between Windows and Linux systems with only a little work. 

Moving to a tablet/phone system like Android is more difficult but it supports touch screens. I've developed numerous Android apps so that I am comfortable with the environment. Unfortunately, it is wholly different that what you'll find on most platforms. My hope is to eventually have the UI run on a separate PC with a touch screen, and possibly one for each operating position. Something like a Raspberry Pi could fit the bill, and the Python software and UI is easily converted. 

Communication to the Arduino switch is OS dependent since the USB or other wired interface require more modification. It will be better to make it remote by way of Wi-Fi, which not only removes the wired interface dependency, it also allows the control cables to be kept out of the shack and there is less potential for RFI.

To prevent hot switching, the radio transmit status from N1MM is not sufficient. Use of the mic or paddle can put the rig into transmit without N1MM knowing. I have included a provision in the Arduino software to take that one bit of information directly from the rigs. For the first version, I am not using this data to avoid the dependency and complexity. For the first version I will accept the small risk that I or another operator might make a mistake.

Clients and servers: partitioning functionality

The Arduino switch holds the bulk of the criticaldata for system operation: radio bands, transmit state, antenna selection, antenna modes, antenna directions, antenna switch states and more. For this reason I started the design by making the Arduino the authoritative source for system state and decisions. The UI would communicate button presses and update the UI per the Arduino responses.

This approach turned out to be impractical. The primary reason is that it is much easier to develop software on a PC with a language like Python than on the Arduino with its limited ability to connect to the world and the restricted version of C it supports. Further, much of the needed data came from N1MM, and UDP broadcasts are far more easily dealt with on the PC. For example, imagine installing the needed packages for UDP broadcasts and parsing XML on the Arduino. It can certainly be done, but there is no good reason to do it when the alternative is easier.

The current version of the software implements a client-server relationship between the UI and Arduino. The UI (client) is the definitive authority and the Arduino (server) acts on commands. The UI client waists to update system state until the Arduino positively confirms the action for those resources that the Arduino controls: antennas, antenna mode and direction, and BPF.

For example, if you press a button and there is no response, the UI assumes the action has failed. The user notices that the UI hasn't updated and can try again or figure out why the command failed to be fulfilled. It may be that the selected antenna is in use or that a hot switch was detected. There really is no need to flash messages and warnings; our natural inclination is to hit the button again anyway. Our objective is to be functional, not flashy. All the needed information is displayed by the UI.

This method of function partitioning is working well. The Arduino code is far simpler and it is easy to deal with system complexities using Python on the PC.

Should I eventually give each operating position its own UI (currently there just one that's shared) the two instances will communicate to update their respective UI and to resolve conflicts. In most of the conflicts between multiple UI, it may be sufficient for the Arduino to not act on commands that can't be fulfilled. For example, the near-simultaneous selection of an antenna (race condition). 

When the UI doesn't update after a button press, the operator will know that the requested action was not fulfilled. The follow up is to try again, select another antenna or to tap the other operator on the shoulder.

Protocol

I came up with a simple protocol for communication between the UI and Arduino. Messages are asynchronous and there is no reply (transaction) implied in any message. That is, there is no expectation of a reply. In this respect it is similar to UDP.

With the UI as the master, the Arduino only responds to commands or sends heart beat messages to keep the communications link alive. Multiple commands or replies can be packed in one message, separated by ";". The message ends with a CRLF ('\r\n'). 

Each field in each item is one ASCII character. The software has a dictionary for encoding and decoding messages.

• H: Heart beat message; only sent by the Arduino
• R: Reset notification or command
• Acmd: Antenna command or reply; 'X' in a position signifies "off" or not applicable
  
• c: Antenna code (unique identifier of each antenna)
  
• m: Antenna mode (e.g. BIP)
• d: Antenna direction (e.g. northeast or omni-directional)
  
• Rnab: Radio command or reply; 'X' plays the same role as for Acmd messages
  
• n: Radio number: at present it can only be '1' or '2'
• a: Antenna code of the antenna connected to the radio
• b: Band, contest or other non-contest band, or 'X' for non-ham band reception

That's it. Simple and expandable. There is no need for a supplementary package (many are available) to manage the communications. When I migrate from USB to Wi-Fi, it will be necessary to change the communication code on both ends, which ought to be straight forward. The protocol will not change.

Band Pass Filters

With band data from N1MM Logger+ there is no need for a separate hardware connection to each rig, or to deal with the diversity of hardware and software interfaces. Most commercial BPF allow up to 4 data sources for switching: 

• Yaesu/Elecraft 4-line BCD
• Icom voltage level line
• 6 lines to power the relays for each band
  
• Manual switch: push button or rotary

My 6-band low-power switched BPF product are positioned between the rig and amp. When one of the bands is not selected the BPF are bypassed. That allows them to be permanently inline.

The BPF are VA6AM prototypes and I believe that I still have the only two in existence. Pavel intends to make this a kit product, eventually. The timing is uncertain due to his busy schedule. They are excellent filters, superior to most alternatives, and they are very economical in kit form.

The main lack at present is a control board to automatically switch bands based on band data input. I could design and build my own. It isn't very difficult to do but it isn't necessary. The automation software can do the bulk of the work using data from N1MM. 

I installed a rotary switch to manually select the band. There 8 positions: 6 for the contest bands, off and automatic. Automatic is yet to be implemented so the mark is not labelled. There is a DE9 on the rear panel for band data that is currently unused.

My chosen design for automatic BPF selection requires routing of the +13.8 VDC line. The power jack at the rear of the BPF enclosure is wired to the rotary switch. Turning the switches routes the power to the relays for the selected band for manual operation. For automatic operation, the power routes out the DE9 connector to the Arduino. When a band is selected via a GPIO pin, the GPIO-controlled switch (see further below) routes DC back to the DE9 pin for the selected band. There is a control line for each of the 6 contest bands. These control lines are connected in parallel with the manual positions on the rotary switch. 

When a band is manually selected the Arduino switches for the band selection do nothing. The software can remain ignorant of whether the BPF is in manual or automatic mode. The operator chooses the selection mode with the rotary switch. I plan to add a row of LEDs so the operator has a visual indication of which BPF, if any, is active, and whether operation is manual or automatic. 

I considered having the BPF inline or bypassed automatically based on whether one or two radios are in use. That adds complexity that is really not necessary, and can cause confusion when N1MM communication with one of the radios is interrupted.

A further benefit of using N1MM band data for the BPF is GPIO conservation. The Yaesu/Elecraft band data is BCD with 4 binary TTL (+5 VDC) lines. Without a control board for the BPF the data must go to the Arduino and consume 4 GPIO pins in addition to the 6 powering the BPF selection. For two operating positions that's an additional 8 GPIO pins. Even with an Arduino Mega I am near to using all of its GPIO pins. By exploiting N1MM's CAT control and UDP broadcasts, no direct band data is needed and all models of transceiver are supported.

Switching technology

There are really just two choices for switching antenna relays: relays and transistors. My first choice was to use solid state switching throughout. They are small, silent and inexpensive. Following my initial experiments and in consideration of my actual experience with station operation, my strategy has changed to hybrid switching, using a mix of relays and solid state switches.

One of the major reasons for the change is lightning. With two strikes via the control lines, semiconductor switches are too vulnerable. Although lightning current can arc over the short air gap between relay contacts, the relays often survive. The greater risk is to the power supply and other interconnected equipment. I plan to deal with that with a simpler power supply circuit and Wi-Fi. It isn't foolproof but the risk will be greatly reduced.

Solid state switching will only be used for indoors peripherals. For now that is just the BPF. These require Darlington transistors since the BPF relays require high side switching of +12 VDC. More specifically, the switching transistor must be PNP and the driver is NPN. Indeed, all the GPIO drivers must be NPN for positive logic: GPIO pin high activates the circuit. PNP-PNP Darlington high-side switches require reverse logic in the Arduino software: GPIO pin low to activate the circuit.

I purchased 2N2222A transistors in bulk for this purpose, along with the required 1000 Ω base transistors. The driver alone serves for low side switching of relays, provided that their coils are no more than 5 VDC. Darlington transistors (2 stages) are mandatory when the switched voltage is above that of the process or logic. All my BPF and antenna switching relays have 12 VDC coils.

The schematic (picked up from the internet, somewhere or other) shows a generic GPIO pin with an NPN driver and PNP switch operating together as a complementary Darlington transistor. The load (e.g. a relay coil) is high side switched with a positive supply voltage higher than the computer logic.

Drivers are needed since the Arduino has insufficient GPIO current capacity to directly drive most relays. Some GPIO pins in my experience won't even properly light an LED. Each Arduino GPIO is typically rated at 20 ma, but often can't deliver that much without a severe voltage drop. The total GPIO current budget depends on the Arduino model. 

The relays I've chosen are +5 VDC reed relays with internal flyback diodes. These are the same that I used for the Beverage switch but with a coil voltage equal to the logic level so that the driver can be just an NPN transistor. Despite the trouble I've had with the internal flyback diodes, if lightning reaches the Arduino I will have far greater worries than blown diodes! I like reed relays since they won't add to the noise in the shack. The small current being switched is well within their capacity.

Since I am using drivers I could use PNP transistors as high side switches. However, I have 2N6034G PNP-PNP Darlington transistors in my junk box with no better use. I can be rid of them and avoid one of the resistors that would be needed with a discrete PNP transistor as the high side switch.

The picture shows my 2021 testing and design rig for Arduino GPIO switching running prototype software for Beverage direction selection. Notice that the Arduino Nano has difficulty directly driving the row of LEDs (upper left) representing the 8 direction indicators. This is the case even with no other GPIO pins drawing current. 

In contrast, the analogue GPIO pins have no difficulty driving the row of  LEDs (lower right) representing the 5 relays (4 Beverages and 1 to reverse direction). The reversing GPIO pin is tapped to test switching with Darlington transistors. There is a 2N2222A driver and 12 VDC switched by the 2N6034G to light the LED (top centre). 

The voltage drop across the PNP switch is 0.6 to 0.7 volts, which is typical. For large currents than I will be switching, the power dissipated in the Darlington transistor may require a heat sink.

Pots are used in each stage of the switch to adjust for reliable operation with the minimum current draw from the GPIO pin. I discovered that only ~1 mA is needed, however I went with a little more than that to guarantee reliability. When I was satisfied with the design I ordered resistors in bulk.

This far simpler setup is how I test the software in advance of the switching system fabrication; the mounting studs are for the PCBs that will contain the switching relays and transistors. A voltmeter is used to read GPIO states. The small PCB contains two 5 VDC regulated supplies, not connected at present. One is for the Arduino (in the case where Wi-Fi is used rather than USB) and one is for the 5 VDC reed relays. 

The 12/13.8 VDC input powers the 5 VDC supplies and is used directly for the antenna switches. A simple, lightly regulated power supply is sufficient and less prone to lightning damage since relays coils don't need a tightly regulated source of DC.

Fail safe: dealing with software and hardware outages

"Anything that can go wrong will go wrong." Hams are not immune from Murphy's Law. As our stations become more complex the risk of failure increases. I'm only surprised that it doesn't happen more often. Have a close look at the complexity of the hardware and software inside any transceiver, PC or software application we rely on, and be astonished that it performs as reliably as it does.

Station automation increases the probability of failures occurring at a critical time. One-off home brew hardware and software is particularly at risk. I strive for reliability in what I build while knowing that there will be failures. Those failures often occur during contests when we push ourselves and our stations to extremes. That's also when their impact is greatest.

I wanted options available when problems occur. For example, if the software or hardware fails catastrophically should there be a fully manual option, similar to what I currently have in my station? It can certainly be done, although I haven't, or at least not yet.

The software can be restarted and the Arduino and PC reset when they fail. Software components automatically synchronize when they start and the UI provides visual status information (see above). The same is true for N1MM communication. When in doubt, reset or restart, and operation will resume in seconds.

Spare computers, power supplies and major components can be kept on hand. When one fails a replacement can be installed in as little as several minutes. Having spares on hand is expensive and substitution takes time and is not without risk. 

Strict RFI mitigation for control lines and computer cables will reduce unexpected outages. The initial reliance on USB for communication among components will later be replaced by Wi-Fi to further reduce RFI risk. Hopefully transceivers and other connected commercial products will make more use of wireless.

Aside from those major items, the design has fault tolerance features. In case of N1MM communication failure due to PC, software or network trouble, the band and antenna selections can be performed manually. This was described above in the UI section. Manual operation is also useful when N1MM isn't used. 

Moving the UI to a separate computer isolates the station automation from other equipment and a cascade of software failures. When that is done in a future version, the UI can be run from any of the logging computers or on computers dedicated to the UI. Failure of any one PC will degrade but not halt contest operation.

I considered making the peripheral interface connectors transferable between my manual antenna controller and the Arduino system. Unfortunately, the manual controller was poorly designed in this respect and I made improvements that are not backward compatible. I need to give this more thought.

Every conceivable failure cannot be dealt with. My objective is to handle many of the major risks that are not too onerous to implement. Beyond that, I'll just have to hope for the best. With experience I'm sure to come up with additional measures.

Non-contest operation

Non-contest bands are included in the lists of antennas. From experience I know which antennas work best on bands where there is no resonant antenna, and the rig ATU is preset for them. Those antennas are the first choice. Other antennas that are potentially useful for a band are included in the list. The selections are stepped through using the antenna button on the UI, just as it is for the contest bands. BPF are bypassed when a non-contest band is selected.

Listening on non-ham bands is permitted with a provision to allow manual antenna selection on those frequencies. The operator can decide which antenna is best. It isn't very convenient to step through all the antennas (repeatedly clicking or pressing the antenna selector), but then I rarely listen outside the ham bands. I can tolerate the inconvenience.

N1MM is my primary logging application for contests and for daily operating. Most hams use different software outside of contests. Due to the dependence on N1MM, when it isn't being used the operator must manually select bands and antennas. Were I to switch to a different logging system for daily operating I would certainly investigate a software interface that would have the functionality I have with N1MM. Many logging applications can now support a similar interface, though with different API.

Onward...

Summer is a poor season for writing software and wielding a solder iron. There are far too many enjoyable distractions. Colder weather and contest season is racing closer and I don't know how ready I'll be. It is likely that I'll start the season with the existing manual system and migrate to the new system in stages. There will be ample opportunity to experiment with alternative UI layouts and functionality.

One task I dread is the multitude of transistors, resistors and relays that have to be mounted on PCB, wired up and interconnected with the Arduino and external connectors. There's no escaping it. I purchased several prototyping boards to find the best one for packing these components into a small package that is also not difficult to work with. I've made my selection.

Expect to see more about this project as it proceeds to fruition. There are no more major barriers blocking progress. It's simply a matter of making the time and getting down to work.

Hopefully this detailed description of my station automation plan will inspire others. I suspect that most reader bailed before reaching the end of the article! 

A custom solution is more difficult than choosing a commercial product. That path excludes the opportunity to learn and to create a system that works best for you and that is ripe for experimentation. I know that it is not for everyone, and that's okay. At the least you are now be in a better position to evaluate which commercial solution is best for your station.

Flyback Diodes and the 1N4148

I keep a large inventory of 1N4148 diodes. These are small signal diodes that every ham builder is undoubtedly familiar with. I use many of them in my station, almost exclusively for antenna switching matrices. They have seen greatest use in my 80 meter 3-element vertical yagi. The 1N4148 diode is cheap in small quantities and it is easy to find in electronics stores and online.

They are not always used appropriately. To some, one diode is pretty much like another diode, other than specialty devices like Zener diodes and PIN diodes. Commercial products are full of them, whether appropriate to the application or not. The 1N4148 will do the job in most cases and most people never experience the events that demonstrate otherwise.

Other than switching, perhaps the most common application of the 1N4148 is a flyback diode (pic reference) on a relay coil. (Flyback diode seems the generally used term but there are others: surge suppression, reverse EMF protection, etc.) When a coil is turned off, the magnetic field will discharge in the reverse direction of the applied current. The flyback diode dissipates or shunts the energy to ground to protect sensitive electronics driving the relay coil. Other inductive loads, like motors, require similar measures.

Calculating the required ratings for the diode is not difficult, although I've never felt the need. For the small relays used in my many antenna switches a 1N4148 is seemingly adequate. Unfortunately the calculation can be very misleading when used for antenna switches in our stations. There are other considerations than its main function. 

I previously ranted against the 1N4148 while I was repairing a Hamplus 2×8 antenna switch a few years ago. I ranted again when a lightning strike wiped out the reed relays in the Beverage switch. The reed relays have which integrated flyback diodes, which is convenient. The datasheet for those reed relays says nothing about the diode ratings. Based on how the requirements are typically calculated, the integrated flyback diode is likely no better than a 1N4148.

The reason I am returning to the subject is due to the continuing fallout from my recent lightning strike. As time went by more problems appeared in the station. Semiconductor junctions don't always fail immediately, continuing to function while weakened until failing later. This occurred with the antenna switch when one morning I could not select the 20 meter stack. 

Cleaning contacts and checking the control wires was no help. I narrowed down the fault when I checked the control line voltages and currents while the stack was selected on the station's left radio.

The antenna switch was brought indoors. The coax and control cables were wrapped in plastic to protect them from the weather. An earwig colony that infested the weather cover over the switch was disrupted in the process. They will surely find another home!

Testing in the shack confirmed my guess that the flyback 1N4148 for the misbehaving switch position was shorted. Two other diodes had measurable reverse current that promised imminent failure. I heated up the soldering iron and removed all 15 of the 1N4148 flyback diodes. The 1N4007 that replaced the original failed 1N4148 tested good so I left it alone.

As you can see from the picture I was not gentle with their removal! I should have done this the first time, but it's a lot of fussy PCB work that I was eager to avoid. Although they are easy to remove, installing new diodes in PCB holes plugged with solder is difficult to do while being careful to avoid damaging the diodes and PCB traces.

The job is done and the switch has passed initial testing. Once I complete testing it will be re-installed and I can get back on HF. For the time being I am only able to operate 6 meters, and that's okay since the "magic band" has been pretty good lately.

So what have I actually accomplished? Presumably the diode replacement is questionable since the 1N4001 and 1N4148 are, per the flyback diode calculation, equally adequate with respect to their current and voltage ratings. Yet I here I am, again insisting that the 1N4148 is a poor choice.

From the Vishay datasheet we see that the PIV rating is about the same as for the 1N4001. It is of course 1000 volts for the 1N4007. While repairing the antenna switch I ran out of 1N4007 diodes and when ahead and used several 1N4001 in the antenna switch without a qualm. 

My concern is the survival of the diode and not only its ratings as a flyback diode. Of course, no diode will survive or protect against a severe lightning strike, but most strikes are secondary or inductive and many semiconductors will survive if they can withstand the surge current and heating. Not only can a more robust flyback diode survive the abuse, they can protect downstream devices if the surge can flow through the diode to ground. 

That is where the 1N4000 series of diodes is superior to the 1N4148. The surge current for all of them is 30 A, or 15 times that of the 1N4148. The power they can shunt and dissipate is much greater and that can make all the difference. The 1000 PIV rating of the 1N4007 makes it more likely to survive than a 100 PIV device, however that is often not the major factor. Hence my willingness to use the 1N4001 rather than wait and order more of the former.

A device such as a MOV is better for protecting control lines, but every little bit helps. A diode that survives has a chance to also protect. MOVs have other issues with respect to lightning protection which I won't delve into, especially since my knowledge of them is limited. In many applications they should prove adequate if the power supply and switching electronics can withstand having control lines shorted by a MOV reacting to the high voltage of a lightning strike. Failed flyback diodes usually burn open or short, usually the latter in my personal experience.

Power supplies need protection as well for the same reason: inductive loads. In the schematic extract we see a protection diode across the output of the small Pyramid linear power supply that was damaged in a previous lightning strike. It's a low voltage and high current 1N5402. It survived the strike.

Going through the schematic of the Astron RS35 power supply damaged in the recent strike there is no equivalent diode across the output terminals. There is an SCR used in the crowbar circuit but I doubt it provides any protection from reverse EMF. It also appears to have survived the strike.

I have heard that the Pyramid power supplies are better engineered than those by Astron and this is evidence supporting that view. After all, a 35 A power supply can be employed with a variety of inductive loads, and those loads may not have diodes.

The digression about power supplies is relevant. It brings us back to a question about how to best deploy flyback diodes in the antenna switching systems in use at my station. Do they add value? Is just one enough and can the one in the power supply do the job on its own? Why is there one on every relay? 

I have flyback diodes on all my home brew antenna switch relays. This includes stack switches, Beverage switch, 80 meter yagi mode and direction switches, and there will be more. All use high side switches. The Hamplus antenna switch has a flyback diode on each control line (low side switching) but not on every relay: there are 16 lines and 24 relays.

The schematic depicts a circuit where every relay coil has its own flyback diode. An alternative is shown on the right that we'll discuss shortly. There is only one switch (box with an 'X') per relay coil, either high side -- switches the +12 VDC, with the other side grounded -- or low side -- switches the grounding, with other side connected to +12 VDC. The Hamplus uses low side switches, with each control line running back to an operator controlled switch.

When the (high or low side) switch opens, the relay coil and diode are isolated from the circuit upstream of the switch. The magnetic field collapses and the energy, with nowhere to go, is dissipated in the flyback diode and coil. Without the diode the field would collapse more slowly, but in both cases it happens fast.

Why have a flyback diode on every coil? Could just one suitably selected diode do the job? It could even be the one in the power supply. I toyed with this approach when I got frustrated with the time and effort to de-solder and re-solder the 16 flyback diodes in the Hamplus switch.

First, with a remote diode, such as in the Pyramid power supply, there is a propagation delay measured in microseconds. That isn't a lot but entails a slightly elevated risk to local electronics due to the distance between the switch and flyback diode. The second and more important point is to understand what kind of circuit we're protecting. The power supply is (or should be) already protected, so it's the low/high side switch we should be concerned about.

If the switch is a relay or mechanical switch there is little to protect. The contact will "spark" a minuscule amount, however for many relays that can increase the lifetime of the relay by, what is sometimes called, wetting the contacts.

If the switch is solid state there is risk. With just one flyback diode (option at the right of the schematic) in the equipment or power supply the semiconductors, typically transistors, in each switching circuit will not be well protected. It is better to use a flyback diode on every control line which energizes one or more relays. That is the case for the Hamplus switch with its 16 diodes and 24 relays.

I have flyback diodes on every relay coil or commonly switched groups of relays. All the diodes are 1N4001 or 1N4007 so that they are better able to withstand lightning surges than the 1N4148. I probably should have replaced all 16 in the Hamplus when I first repaired it. 

I have altered the design for my station automation system to use Arduino GPIO controlled relays, not Darlington transistors, for antenna switches that are exposed to lightning surges. Flyback diodes on the relays coils is inexpensive and protects solid state switches for the control lines. For relay switching of the control lines, having the diodes present is no inconvenience.

Another Tower Appears

The ham that keeps an ear on the ground will find that many used towers are available. People downsize their possessions when they get old and, as we know, the average age of hams is quite high. Those hams that delay downsizing end up passing the torch to their friends and family via estate sales. It's sad but understandable. Just don't let that sentiment get in the way of a good deal.

Certainly there are some who ask an unreasonably high price. But for every one of those there must at least 3 that are free for the taking (down). Some may already be on the ground. If you don't climb you may know a fellow ham who does. Do him a favour and perhaps he'll do you a favour.

The challenges are twofold:

• Taking the tower down
• Taking the tower home

Earlier this year a friend asked for help to take one of his towers down. I was happy to oblige even though I didn't expect to take the tower for myself. My first thought was to find another ham who needed a tower. There are surprisingly few of them since many of the newer hams make do with small antennas to avoid the hassle with the municipal authorities, neighbours and family. They just want to avoid the effort and worry in their busy lives.

This particular ham is not downsizing. Indeed, he has a large contest station. This small tower was at the family home, and his big station is at their rural property. One day this spring I and another contester friend headed over to do the job. Since he had helpfully already removed the antennas and rotator the job only took a couple of hours. That left us plenty of time to chat and eat.

That's me posing on the tower after all but the last section was down. Dave VE3KG is on the left and in the centre is Vlad VE3JM. The tower is Vlad's. The photo was taken by Vlad's wife Marija. After Dave left, Vlad and I spent another hour digging the bottom section out of the paving stone patio to unbolt it from the base stubs. Although a below grade concrete foundation is generally a poor choice, there was good drainage and no rust damage to the section after more than 20 years.

I don't have a large enough vehicle or a trailer so I had to wait until a friend could assist. Vlad was in no rush so I delayed while I worked on other things. Earlier this month, Brian VE3CRG and I took the seats out of his large van and moved the tower to my place. A fair amount of driving (and gas) was involved since the 3 of us live some distance apart (3 adjacent grid squares).

The DMX line of towers are self-supporting up to 8 × 8' sections, with sections from #8 (the largest) to #1 (the smallest). The DMX product is well known to Canadian hams. While not commonly seen outside the country there are similar light duty self-supporting towers made by others, including Rohn in the US.

The driven element of my 3-element 80 meter vertical yagi consists of sections #6 to #1, with a guying bracket. I first purchased that tower to support a yagi at my previous QTH.

The picture at right shows the #7 and #8 sections of Vlad's tower after they were unloaded. These are the key sections for what I have planned. The other sections will be stored until I find a use for them.

The first application I have in mind is as part of the rebuild of the 80 meter yagi. The tower that currently forms the bulk of the driven element, and wire elements support, stands about 14.5 meters. The additional length for make a full ¼λ vertical on 80 meter is a stinger. That stinger is a weakness, and there have been problems. That said, the current stinger has done very well.

With the #7 and #8 sections the tower portion of the driven element becomes about 19.2 meters tall. The tower base must be changed to accommodate the larger base section (currently a #6). The stinger (if we can still call it that) will be less than 1 meter. A second guy station will be added for stability. I can reuse the improvised design from its original installation.

The electrical design of the yagi remains the same. It is only necessary to adjust the pipe at the top to resonate as before, and provide a 2' non-conductive pipe above it to support the 4 wire elements as before. However, I plan to take the opportunity to make long-planned improvements to the array. These include altered wire element design to improve gain and directivity. 

With a switched, side-mounted stinger at the top of the tower and and top loading I can have a far more efficient year-round vertical for 160 meters than the current base loaded mode of the 80 meter yagi's driven element. The 80 and 160 meters improvements do not have to be done at the same time. Both can be done during the colder months when work on the other towers and antennas is paused.

As for the other 4 sections of my newly acquired tower? That is yet to be determined. I have tentative plans for another tower, possibly for VHF or WARC band antennas. It is easier to locate #1 and #2 DMX sections than #7 and #8 sections, so when those cross my path I will have enough for a suitably high tower. For the present the extra sections go into storage.

Blog note: It's summer. My time to write for the blog is severely budgeted, as is usual for this time of year. Backlogged articles will appear, eventually. I may also be slow to respond to email, and I have several in the inbox awaiting my attention.