3-element Trap Tri-bander on 50 MHz

Not long ago a friend asked me about using his short boom 3-element tri-band yagi on 6 meter. Apparently the idea is more popular than I expected. But it makes sense: it's already there, it's rotatable and it's high on a tower, so maybe it's worth a shot. He wanted to try it to see if he could do better than with his wire dipole.

When loading any antenna on a band for which it was not designed there are two critical metrics that must be addressed:

• Efficiency
• Effectiveness

Unless you're very lucky the SWR will be high. That has a strong impact on the efficiency of the antenna system. Elements far longer than that of a half-wave dipole can have peculiar patterns with multiple lobes and nulls. That can be a problem if the antenna is not rotatable.

I gave him my opinions solely based on my experience and thinking through the issues. Out of curiosity I followed up with a software analysis. It wasn't difficult to do since I have a EZNEC models of a tri-band dipole and small 3-element tri-band yagi in my files, and TLW easily analyzed efficiency and matching of the transmission line and tuner (matching network). The dipole is the driven element of the yagi without the beta match. The element model utilizes traps similar to that for common Hy-Gain antennas like the TH3.

It turns out that what I told my friend was partly right and partly wrong. While an educated guess is often good enough for ham work, a model and measurements will do far better for a modest amount of effort. Even experienced hams can be wrong so be very careful whose opinion you solicit. I don't mind being wrong since it's an opportunity to learn. Hence this article.

Above is my EZNEC model of a tri-band yagi fed on 50 MHz, showing the element currents. It is no surprise that the reflector and director currents are low since the spacing is almost double that on 10 meters (by wavelength) and the elements are not resonant on 6 meters. The low impact of the parasitic elements is apparent when they are removed from the model, since the pattern and impedance are little different (see below).

There are current "bumps" at the beta match and traps where there are impedance discontinuities. The traps have a net capacitive reactance at frequencies higher than their resonant frequencies. The beta match is essentially a dice roll since it is arbitrarily transforming a high SWR to a different but also high SWR

The azimuth pattern is pretty good. It's bidirectional with modest gain due to the narrowing of the lobes. The narrow lobes are due to the long length of the yagi driven element; as already noted, the parasitic elements have little effect so that the pattern of the tri-band dipole is almost the same. I wouldn't read too much into the higher free space gain of the dipole (red) since the difference is small and not easily predictable for the variety of commercial antennas of this type.

When I inspected the behaviour of the traps in EZNEC I was surprised to find that their loss was negligible even for realistic Q values of the constituent coil and capacitor. I expected the loss to be low but significant. I haven't yet looked into the details of what was to me an unexpected result. I have an idea how it comes about, but rather than present a guess let's move along.

Well, that was the good news. Now it's time for the bad news.

The SWR is very high, and that's bad. It is similarly high for the tri-band dipole, except that the R and X values are transformed to a high R and negative X by the beta match. I used a beta match in the model due to its use on Hy-Gain yagis and some other tri-band yagis. With other yagi matching networks the effect will be different but perhaps not so much in its behaviour on 50 MHz.

The SWR can be corrected in the shack using a tuner. The ATU in our transceivers cannot cope with an SWR of 30. In actuality, the mismatch loss on the coax is so high that the SWR in the shack will be far lower than 30. TLW is my tool of choice to model the effect of the transmission line.

Many hams use RG213 class coax in their HF antenna systems so that's what I started with. I further assumed 100' (30 m) of coax length, which is typical for a yagi on a small tower located a short distance from the house. The matched loss of RG213 is quite high at -1.6 db, and it balloons to -8.2 db due to the extreme mismatch. With LMR400 the loss is "only" around -6 db. Even with pricier LDF5 the loss is still -2.7 db. 

Notice that the SWR of 5 in the shack is almost within reach of a transceiver's ATU, and it might even manage it depending on the R and X values. That will depend on the length of the coax.

It should be obvious that to reduce the loss the transformation network should be placed at the feed point. It will have to switched by relays (one at each port) so that it is bypassed on HF. With fixed C and L an L-network can be very efficient. TLW has the following to say based on average quality components.

To connect all of this to the real world, I measured the impedance of my TH6 on 50 MHz. Of course there are differences between a real 6-element tri-band yagi and the 3-element tri-band model, but they're both trapped and the driven element of the TH6 has a close resemblance to the model. That was my intention when I originally developed the model years ago.

The impedance was measured in the shack with a RigExpert AA-54, which you've probably seen in many other articles on the blog. I could have used a VNA for improved accuracy, however that really isn't needed for this exercise. The transmission line has a few short sections of RG213 and LMR400, so I mentally estimated how that translates as an extension to the LDF5-50A Heliax transmission line I'm using. I only needed the approximate SWR, not the precise impedance at the antenna feed point.

The measured SWR is 5, which is about 8.5 at the feed point. Although that seems significantly less than 30 for the model it really isn't. Very high SWR is acutely sensitive to small details of the load and transmission line. For example, when I substituted RG213 in TLW the result was nonsensical because the load would have to have a negative impedance. The reason is that you could never read an SWR as high as 5 since that requires a transmission line with loss better that of RG213.

Suffice to say that the SWR is high and the mismatch loss can be very high. Few hams in the situation described in this article are likely to be using LDF5 Heliax!

For hams looking for a simple and effective 6 meter antenna, a switched network on top of the tower is probably not what they are looking for. A dipole mounted above the yagi and an inexpensive remote coax switch (or separate feed line) are probably a preferable alternative. 

A 2-element yagi is very small and has significantly better uni-directional gain. Hams of my acquaintance who get on 6 meters with their 20 to 6 meter hex beams seem to be satisfied with the performance. It isn't what I would choose for myself  but few hams have the towers and property that I do.

The northern hemisphere's summer sporadic E season is now finished. For those planning to get active on the band in 2023 this article may motivate you to put up a resonant antenna rather than try to get by loading an existing HF antenna. The improvement will have a remarkable impact on your success.

6 Meter Season: Diminishing Returns

I am reluctant to write this article. Although we are now 2 months past the peak of the summer sporadic E season the band is not quite dead. But I have to accept that we are about done and this is a good time to reflect on the season that was. E season wrap ups have become a regular feature of the blog; for example, here is last year's summary.

The 2022 season was a mixed bag. Propagation started slow on 6 meters, petered out right at the solstice peak, then July delivered a multitude of openings. The magic band likes to keep us guessing.

DXCC

On the DX front my DXCC count changed little. At the end of last year I had 111 worked and now the count is 120. Of the 9 new entities, a maximum of 7 can be attributed to sporadic E. The others were F-layer or TEP deep into South America to work CE and CX. The opening to the Pacific that netted E51WL and 3D2AG likely had a sporadic E component at this end of the path.

Considering that I logged 900 QSOs on 6 meters this season (over 700 of which are DX) that is one new country per 100 QSOs. The reach of sporadic E is limited and the further the path the lower the probability of an opening, especially at higher latitudes. Were there more activity from Africa the DX potential would be greater. Working DX on 6 meters is rarely easy, and if it was it would be less rewarding. I am not complaining, just relating the facts.

Operator duty cycle

One of the questions I am regularly asked about DXing on 6 meters is: when should I listen for which DX? Sporadic E is called sporadic for a reason, so I have to disappoint them. There are times of the day among a multitude of other indicators with an increased probability of DX over particular paths. Unfortunately for us, good and bad surprises are the norm.

There is no substitute for dedication and listening. At the very least, monitor DX spotting networks. During sporadic E season my rig is regularly monitoring 50.313 MHz even when the band is dead, just in case. I leave it on when I am out of the shack or away on other business so that I can review the sometimes long list of decoded FT8 messages.

The point is, you can't be sitting in front of the rig 24×7 for 4 months straight. Surprise openings are surprises (duh!) so you have to accept that you will miss some or many. When I miss openings I am able to learn likely propagation patterns by reviewing what I missed. That's the point of leaving the rig on when I can't be there.

There are times when I fully expect the band to open and I leave anyway. We all have responsibilities that brook no delay or rescheduling. During summer I also have non-ham interests that I attend to. Life is more than ham radio.

Here are many of the DXCC countries I missed working this year because I had to be away or I chose to be away: Z6, EY, ZL7, OA, V4, TR8, TT. There were also the inevitable almost new ones from partial contacts that could not be completed due to the rapid rise and fall of DX paths. One in particular that comes to mind is OD. 

Several others new ones were heard that did not hear me. That list is longer. Few hams have the quiet location that I have and it takes a lot of ERP and luck for be heard by them.

Rather than dwell of the disappointments, I prefer to focus on the future: the anticipation of next year's opportunities and the coming F-layer openings. I relish the challenges ahead.

Notable openings

There is an unfortunate habit for hams (just like regular folks) to brag. The presence of examples in this section is not intended that way, although I have to admit to being pleased with my successes. If this hobby doesn't give us pleasure, well, what's the point? With that in mind let's continue.

I already spoke of the fantastic Pacific opening that netted E51WL and 3D2AG early one evening so I'll simply link to that article. There you will also find a screenshot from a friend who copied ZL7DX. I was not present for that one and I don't know if I'd have copied the signal or made a QSO.

It is not always that way. My antenna system and low noise QTH often make the difference between my success and that of those nearby. I took the adjacent screenshot to prove to several friends that I was hearing Hawaii very well one evening in early June. Despite being within 100 km of me and with only slightly less effective antenna systems, they had no decodes of KH6HI or the other Hawaii stations I copied.

It's impossible to say whether the difference was propagation or our stations. Nevertheless, it is a fact that incremental improvements in transmission lines, power, antenna gain and antenna height are in your best interest. Small differences add up and will improve your success rate.

Last year I copied UN stations during a brief early morning opening. The amp was off and I failed to make a QSO. That isn't unusual for sporadic E.  I was therefore happily surprised when UN3G answered my CQ in early July. As you can see the signal reports are painfully low, but all that matters is that the QSO is good.

Much to my surprise there was more to come. On at least 3 further days in July we had openings to UN. In one case it lasted close to an hour. Now I have 6 contacts with Kazakhstan on 6 meters. Although the latter 5 are superfluous for DXCC, the joy of contacts over such a long path is never uninteresting. I almost don't mind that I missed EY8MM. There is always next year.

Despite the frequency of openings and large ham population, there are countries in Europe I have yet to work. Some have only occasional activity or their station conditions are poor. Two that I added were ER and ZA. The Italian station in Albania was periodically heard by me and my friends but never strong enough or in for long enough to allow for a QSO. 

During one excellent opening he was quite strong on 50.323 MHz and, as you can see, the new one was rapidly logged. It's always fun to convert a purple CQ to green. Signals improved and the friends I notified were also able to add ZA to their 6 meter DXCC total. The buddy system works.

I finally managed to work HL this year, and 4 of them for good measure. The bearing as you travel the short distance from JA6 to HL to BY shifts alarmingly north due to the long path length. That's what makes them so difficult from this part of the world.

The final South Korean station I worked occurred unexpectedly late in the evening (July 7, UTC). It took several tries with a kilowatt to finally be heard. Unexpected DX is always a pleasure. After our QSO he began calling CQ NA, probably similarly surprised by the opening to eastern NA.

Among my misses this year was China. As already mentioned, China is difficult due to the northern bearing of about 345° to 0° for the densely populated eastern half of the country. Compare that to 330° to 335° bearing range for Japan, which is a far easier path. Indeed, I worked dozens of new Japanese stations this year over several openings.

As you can see from the screenshot, I certainly tried to work China! BA4SI appears to be in the Shanghai region, which is about the least northerly path from here. Perhaps like many others they have a QRN problem. I heard them and other Chinese stations on at least 3 evenings in July. None responded to my calls. Other than BA4SI none of them were in for more than 3 consecutive FT8 intervals, which is barely sufficient for an QSO. I'll try again next year.

A notable opening that almost but didn't quite reach me was VK4. That's an extraordinary long path! It is a little north of west for us to those stations located in eastern VK4. That is about as far to the south the great circle path goes from here to anywhere in Australia, and that makes it about the easiest.

Many stations not far to the west and south of us were successful working the several VK4 stations that participated in the opening. I and my friends had not a single decode. Some things were never meant to be. This one may have to wait for an F-layer opening.

Pros and cons of increased activity

When the band is open it's busy, very busy. An increasing number of hams are discovering 6 meters and they are active. This is fantastic but it does add to the QRM and QRN. 

The increase is not only local so there are more DX stations to work and more countries to be worked. Cutting through the QRM to do so is unfortunately necessary. I prefer it this way compared to a quiet band with fewer stations to work. The intercontinental window at 50.323 MHz is less busy yet relatively few stations QSY.

Some of the QRM is due to improperly adjusted transmitters and amplifiers. Although we use the SSB mode on our equipment, digital is not phone. On SSB we "own" the full 2.7 kHz of spectrum we occupy, which is necessary to contain enough of the human voice to enable legibility. It is therefore not an inconvenience to others that we use non-linear techniques such as clipping and compression to increase average power. The distortion due to non-linear processing improves communications when judiciously applied.

Try this on digital modes and bedlam ensues. The 3 kHz window typically employed for FT8 requires that each occupant strictly limits their signals to the approximate 50 Hz audio bandwidth required. To do so requires audio linearity and RF linearity. 

Unfortunately our rigs often make this difficult since the non-linear features used for SSB must be manually disabled when switching to digital. Many hams forget or don't realize its importance. I know and yet I occasionally make mistakes. With a constant probability for each operator to make a "mistake", the probability of QRM due to these mistakes increases in proportion to activity. Then there are the anonymous "policemen" who add to the QRM with directed custom messages to harass the guilty parties. 

Expect problems to continue until we have a new generation of equipment that incorporates improved digital features and abandon use of the SSB mode. Hopefully that will also reduce distortion, audible computer sounds and background noise from live mics. For example, in the FTdx5000 that I use the mic is always live despite using the rear audio jacks to connect the PC. I have to remember to unplug the mic when switching to FT8. It's easy to forget.

Another notable behaviour is the increasing presence of robots. For those not familiar with digital robots, they are typically made from forks of the open source WSJT-X software. Robots are in violations of the open source license. It is not easy to get them taken down and there are numerous applications proliferating in the wild. I won't provide specific examples but the curious will not find them difficult to locate on the internet.

Robots will automatically CQ or call CQ'ers, work stations and log the QSOs. Some do not discriminate, calling everyone they hear, often progressing up and down the FT8 window in a easily identified pattern. Others are more particular about their behaviour and use filters to limit who they call. 

Most robot software users appear to have no evil intent. They may simply enjoy the novelty of the technology. Others like the idea of logging lots of stations while they at work or doing other things. A few do it to demonstrate (mostly to themselves) that digital modes are not "real" amateur radio. I will not work robots that I can recognize as robots. Persistent bad actors are particularly obvious and they have a well-earned poor reputation. 

Most on the band don't care or are even aware that they are working robots. It was inevitable that robot operators would migrate from HF to 6 meters along with everyone else.

Propagation lessons

It's impossible to be passionate about DXing on 6 meters without developing a keen appreciation of the underlying propagation science. Despite the vastly improved understanding of the mechanisms underlying sporadic E, TEP, scattering and other propagation modes, predictability remains elusive. 

We do far better with the weather since measurements that feed computer models are easier and more extensive. There are also strong economic incentives to improve predictions. Radio propagation lacks the economic incentive in the 21st century and there is no good way to install measurement instruments at multiple points in the outer reaches of the atmosphere. Remote observations are a poor substitute. 

Predictability will therefore remain a challenge. Those seeking certainty will continue to be disappointed with the poor predictability of openings on 6 meters.

Despite the challenges, the increased level of 6 meter activity, prevalence of digital modes and the broad use of internet tools are giving us a better understanding of sporadic E propagation. Although prediction is poor, we can do a lot better than in past decades. Here is a short list of what has become apparent to me (and others):

• Weak and brief sporadic E propagation over both short and long paths are more frequent than has been previously believed. Single decodes of distant stations on a "dead" band are fairly common. The proliferation of big stations continuously transmitting CQs makes this possible; beacons are too weak and require effort to individually monitor. I also will periodically rattle off CQs on a dead band, and in combination with PSK Reporter I see flags of my transmissions being decoded in unexpected places more than I would have once believed possible.
• Overnight DX openings during sporadic E season are more common than expected. I have taken to leaving WSJT-X running overnight many times this year, with the yagi pointed north into the perpetual Arctic daylight. The log of decoded messages that I review in the morning contains notable surprises. I have also been surprised by how often I will get a flag in western NA during our mornings, well before their sunrise, while I'm beaming to Europe or west Asia.
• Brief long distance openings to eastern Europe and Asia are common in the hour or two after sunrise. These are easy to miss since I am not an early riser and sunrise in the weeks surrounding the solstice is 5:15 AM.
• Conditions that result in an opening today don't immediately dissipate. There is an increased probability of a similar opening, perhaps weaker or stronger, the next day. I have noticed this on almost every path: east Asia, central Asia, east/west/south Europe, NA west coast, and South America. The same may be true of the Pacific, but with sparse activity it is difficult to know.
  

While scientifically interesting, some of the above phenomena do not translate into QSOs. The openings are too transitory and digital modes too slow to take good advantage. But they are there, and that's good to know. We may develop technological aids to turn those opportunities into results in the future. Being a ham involves progressing the art and not twiddling the VFO knob as we had to do in days of yore.

Looking ahead

We can expect a return of north-south propagation as we approach the fall equinox in late September. That can happen with modest solar activity if other factors are favourable. There are a few more South Americans that I would like an opportunity to work. Beyond that, we'll need a higher solar flux. 

When the solar flux rises above 150 the propagation, as seen from here, will spread east and west across the tropics and to the southern hemisphere. Going by my experience from the 1989/90 solar maximum, openings to South America will expand to include southern Africa and equatorial Africa. It is almost certainly present to the eastern part of the South Pacific, but there is almost no one there. The sparsity of land and hams is at fault.

Eventually, but probably not this year, we'll see east-west propagation within the northern hemisphere. The solar flux would have to hold above 180 for that to happen, and it would have to happen during the fall and spring for best results. Deeper into winter the northerly paths are less likely to open since solar insolation at high latitudes is weak. Winter sporadic E will occur but it is poor for DX at my location.

Despite the title of this article, I am hopeful that 2023 will be a good year for 6 meter DXing. We can count on a higher solar flux, increased activity and the return of sporadic E. More paths will open and more of us will be there to take advantage. With the diminishing returns of sporadic E propagation at my DXCC level, those additional propagation modes are needed to eke out more than a handful of new countries each year. 

Although the 1989/90 solar maximum was exceptionally good, I could not get past 70 countries because so few countries had access to 6 meters. It was frustrating to have great propagation to Europe and only be able to work a handful of countries. The majority had no access to the band. Those barriers are almost entirely down so if the present solar cycle is a good one there will be no shortage of DX to work, including with small stations. We have a lot to look forward to.

For the present my attention has shifted back to HF and preparing my station for the fall and winter contest season. I still have much to do.

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.