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.

10 Meter Stack Switch

This is the final stack switch for my 5/5 stacks on 20, 15 and 10 meters. The 10 meter yagis were built and raised last year, but without the stack switch only the upper yagi was connected. Once I make and install the phasing harness and control cable the system will be complete. Of the three stacks, this one was the lowest priority because of the solar flux. Now that cycle 25 is blossoming, I want the stack fully operational for the fall contests.

The design of the stack switch is almost identical to that for the 20 meter and 15 meter stacks. In this article I will focus on the differences. Please refer to the earlier articles, and this one about L-network stack switches. In addition to construction and testing details, you will find the theory of operation, component selection and a circuit diagram.

The major differences from the other stack switches include:

• More compact L-network to reduce stray inductance
• Compensation for the internal wiring when using the upper or lower yagi
• Components are mounted on the enclosure cover

The "dead bug" construction method used is not ideal for preserving a constant impedance throughout the circuit. A better method is to mount them on a circuit board and place the traces to approximate a transmission line between major components. It can never be perfect since wires travel to and from the board and there are uncompensated paths through the relays. 

Impedance deviations are small on the 20 meter stack switch, and imperfect but still acceptable on the 15 meter stack switch. I knew I would not be so lucky on 10 meters. The problem of stray reactance in inverse proportion to the wavelength; the reactance of an inductor is proportional to the frequency. Wire is an inductor, whether in a coil, as component leads or for circuit connections.

Before diving into those challenges, it makes sense to start with the final item: mounting components on the enclosure cover. My motivation to try this method of construction is due to Steve VE6WZ. He has several videos on his YouTube channel describing its advantages. It does indeed make working on a circuit easier. I'll definitely consider it for future projects.

Referring to the earlier articles you'll find that I'm using an identical set of components. They fit neatly on the aluminum cover. All I had to do was position the top connectors around the protrusions for the enclosure's screw holes. The aluminum enclosure is from the Hammond 1590 product line.

I'm using the same layout as for the 15 meter stack switch since it has less stray inductance than the layout used in the 20 meter unit. As we'll see, the wiring is be the same but mounting of the L-network will be quite differentl The terminal strip I used in the other stack switches is not needed. I hadn't yet made that decision when the picture was taken, which is why it's there. 

The 100 pf ceramic capacitor I purchased for a few dollars in the Hamvention flea market last month is suitable for a kilowatt in this application. It's worth mentioning that there are no extreme voltages and currents in a L-network with a low transformation ratio (2:1) and a modest SWR at the edges of the yagis' frequency range.

The picture at right shows the stack switch fully wired. Unlike the ones for the lower bands, the L-network is built over its relays for the shortest possible lead lengths. The lead lengths to and through the relays to the yagi ports at the top are about the same as the other units. The compact layout is made possible by the small capacitor and coil. 

TLW was used to design the network. While this network works well as a single band stack switch I must empathize that it is not a narrow band device. That is a common belief going by the feedback I've received from readers and others. A (transmission line) broadband transformer certainly has its uses, such as for tri-band yagi stacks, but it is larger, more difficult to build and in most situations it will be less efficient. The L-network single-band design works well and it is easy to design and build.

I did not adjust the default coil Q in the TLW design. The actual coil Q is calculated at over 300 using K6STI's Coil app. Power dissipation is lower than the calculated value in inverse proportion to the Q. For example, the loss would be 6 watts for a Q of 300. The coil is wound from 12 AWG copper. I tried 10 gauge wire but it was so stiff that I was concerned about damaging the circuit during mounting and network adjustment. I made a temporary coil wound with thin wire for the initial bench test since it was easy to work with.

Stranded wire connects the two ends of the coil to the relay pins to relieve mechanical stress on the relays during installation and adjustment. The standoff and aluminum angle bracket on the capacitor's cold side have sufficient mechanical strength to rigidly support both the coil and the capacitor.

The VNA plot of the completed stack switch in BIP mode (both in phase) shows a remarkably good match and low insertion loss. The insertion loss is not perfectly accurate because the impedances to the yagi ports are not exactly equal and the VNA was not recalibrated for this measurement. When I reverse the loads on the yagi ports the measurement is lower. We want the average insertion loss through the two yagis ports as close to -3.01 db as possible to minimize heat dissipation. With properly selected capacitors almost all the loss is from the coil.

There is one extra component in the stack switch that you may have noticed: a capacitor at the top of the unit. This brings us to a discussion about impedance compensation.

Due to the dead bug design there is an impedance"bump" between the input port and the yagi ports . The impedance through the switch with a calibrated 50 Ω load on the upper or lower yagi port is 52 + 6j ± 1j Ω. On a PCB with traces positioned to form a transmission, line the series inductance of the conductors is cancelled by the parallel capacitance between the conductors, leaving a reactance-free characteristic impedance. Even with a well-designed PCB there may still be a need for impedance compensation.

The impedance bump causes an SWR of about 1.15. That is no disaster but it is worthwhile correcting if not too difficult. As we'll see, the SWR can be corrected quite easily.

It is sensible to assume that the unwanted inductive reactance can be cancelled with a shunt capacitor on the input port of the stack switch. Designing a low-pass tuner with TLW confirms that this should indeed work. There series inductor calculated for the L-network can be ignored since it very small and dominated by the circuit's stray inductance. The value of the compensation capacitor is calculated to be in the range of 22 to 25 pf, depending on the yagi port.

The input port is a poor location for the capacitor because it would be in parallel with 100 pf capacitor of the L-network used for BIP mode. That wouldn't be so bad if I had a suitable L-network capacitor somewhat less than 100 pf, but I don't. The capacitor is instead mounted at the far side of the L-network output relay on the NO (normally open) contact that connects to the relays for each yagi port.

The picture also shows why there is a small difference in the inductive reactance to each yagi port. To minimize the total amount of interconnecting wire, the length of wire to the upper yagi port (penned with a "U") is longer. The small difference in reactance did not justify rewiring the relays, which is a delicate job. Of greater consequence was the capacitor's location and its value.

My first choice was a 27 pf ceramic transmitting capacitor. It turned out to have twice the required reactance to compensate for the inductive reactance because it is not at the input port. The location of the capacitor in effect creates a π-network, with two series inductors: one from the input port, through the L-network relay to the capacitor; and the other from the capacitor, through the yagi port relays, to the yagi ports.

Interpolating from the measurements, I needed a capacitor of about half the value. More digging in my junk box turned up a 15 pf ceramic transmitting capacitor. Above is the VNA plot of the through impedance and insertion loss for one yagi port. There is no need to show the nearly identical plot for the other yagi port. The compensation is very effective.

At this point I had a fully functional stack switch for 10 meters. The final step was the smoke test. Since I do not have a suitable dummy load I used the 2 × 8 antenna switch to select the upper 10 meter yagi and the TH6, and connect the coax for each operating position to the stack switch. RF power is supplied by an Acom A1500. To avoid annoying anyone, testing is done when 10 meters is mostly dead, and on a frequency well away from the main activity areas.

A power of about 1000 watts was applied for a 30-seconds during each test. The results exceeded my expectations. The L-network capacitor (BIP) and the compensation capacitor (upper, lower) remained cool to the touch. The L-network coil (BIP) was warm but not at all hot. The coil in the 15 meter stack switch got hotter during its smoke test.

To complete the project I need to design, make and install phasing harnesses for the 10 meter stack. The stack switch will be installed ~140 feet (40 m) up the tower and the control lines spliced into an already present run of Cat5 cable. More on that later this summer when I'm ready to proceed.

Lightning Strikes Twice

When lightning strikes twice do you blame bad luck or do you suspect a common cause? Both can be true, but they are not equally probable. The particular circumstances tell the tale. Lightning distribution on a largely homogeneous and reasonably flat expanse of geography, like mine, is highly unlikely to favour one particular location.

My station was struck by lightning a few days ago. Again. And again it struck the Beverage system. Unfortunately it is prime growing season and the fields are filled with tall hay and the bush is overgrown. I do not venture into those areas this time of year, so it may be a few months before the antennas can be physically inspected and repairs made. What I know is that the damage is almost certainly worse and the repair will be more extensive than the last time this happened.

It may seem strange that with 150' towers and a variety of high and pointy antennas that lightning would strike antennas that are low enough to be touched from the ground. Long wires can build up a substantial charge in the presence of lightning activity, and my Beverages are between 150 and 175 meters long. Lightning is an RF phenomenon and induction of charge onto a long wire is to be expected. This happens on electric utility distribution networks for the same reason.

This is a lesson I must take to heart. It would have been prudent to disconnect and isolate the Beverages during the summer storm season when they are not in use. Many do so. I haven't since this is not an area known for high lightning risk. Experience demonstrates that my station is at high risk and I will have to take steps to deal with it.

The lightning was unexpected. Although we had several storms over the past week, that morning the sky was clear and weather warnings were for later in the day. I was working on a non-ham task in the shack while monitoring the 6 meter FT8 watering hole at 50.313 MHz, waiting for a DX opening.

A small storm cell formed to the west of us and rapidly passed overhead. The unexpected thunder and lightning didn't worry me too much, and I did briefly consider whether to shut down the station. I didn't and a minute later there was the crackle of intense arcing coming from the A1500 amplifier and bright flashes visible around the edges of the band switch. The 6 meter antenna was the only antenna not grounded. A second later the thunder boomed.

Everything kept working, with FT8 signals being decoded, but WSJT-X lost CAT communication with the FTdx5000. I shut everything off and waited 10 minutes for the storm to move well to the east. The rig, amp and PC worked perfectly when powered up. When I moved on to test the HF antennas and switching systems I discovered that the Astron RS35A 13.8 VDC power supply turned on but there was no DC output. Without it I couldn't proceed to test the rest of the station.

Now I have 2 lightning damaged power supplies. The 3A Pyramid on the right used to power the antenna switches and station accessories until it was damaged by last year's lightning strike. I temporarily moved those power cables to the Astron. Temporarily turned into a year while my attention was focussed on other projects. On both power supplies the electronics have failed, likely due to semiconductor junction damage.

I guess I can't put off troubleshooting and repairing the supplies any longer! For the interim I purchased a 4A supply at a local flea market and a friend loaned me a 25A supply to test and power the second station (SO2R). Amazingly everything works, except for the Beverages. Even the receive antenna port on the FTdx5000 was undamaged despite being connected to the Beverage system.

The Beverages could not be tested because the knob on the antenna selector wouldn't move past the first position. It was physically blocked. So I opened up the antenna switching system enclosure and discovered the problem. The picture below was taken with my phone and a flashlight.

The tabs on the rotary switch deliver 12 VDC (upper left tab) over the Cat5 control cable that makes its way to the Beverage switch about 100 meters from the shack. It's buried for most of that distance. The RG6 coax for the antenna RF follows a different route. The Beverage antennas themselves are further away. A common mode transformer in the remote switch blocks DC between the Beverages and the RG6 run the shack. Of course lightning can bridge that small gap if the path looks favourable to it.

The far right (clockwise) position is off, where the switch was set at the time. The 3 middle tabs are for the current selection of 3 Beverages. The charred and melted tabs are evidence that the lightning current found ground via the power supply by arcing to the rotary conductor. The tab adjacent to the off position partially melted and physically blocked the wiper from passing underneath. There is a separate toggle switch (not visible) to power the reversing relay that delivers DC over the RG6 feed lines to each Beverage.

I hope to have the power supplies repaired in the not too distant future. As noted, the Beverage system will have to wait until well after the hay is harvested. There should be no problem getting everything back in shape by the fall contest season, despite the unwanted extra work.

I have taken modest steps to build lightning protection into my antenna farm. I admit that I need to do more. Let my mistake be a lesson to others. I'm not ashamed to admit my mistakes -- to err is human... -- when it can serve as a learning experience.

Beyond the repairs, there are steps I will take this year to reduce the risk from lightning strikes:

• Disconnect the Beverages and remote switch during the summer when I rarely operate 160 meters. Disconnect and ground cables when storms are in the area, at least as an interim measure.
  
• Investigate lightning mitigation measures for the Beverage system that may be implemented as soon as this winter.
• Install coax protection on all feed lines (4) coming into the house. There are 2 for the HF operating positions, one for VHF and one for the Beverages. I have a handful of VHF/UHF PolyPhaser protectors so the VHF feed line can be dealt with immediately.
• Complete the partial and then plan a full perimeter ground system around the house, complete with additional ground rods for the coax protectors. The best way to incorporate the station ground and electrical service ground will need to be investigated.
• Improved protection for the multitude of control cables for antenna switches and rotators. An ultimate solution is impractical so I will prioritize.
• Improve lightning protection for the 80 meter 3-element yagi. At the moment I rely on the extensive radial system, buried cables and a spark gap for the base insulated driven element (tower).

Is that enough? We can substantially lower the risk while understanding that perfection is impossible.

I am also tempted to invest in a multi-element vertical array for low band reception to avoid the lightning risk posed by the long Beverage wires. My long term plan is for a second receive array to use during multi-op contests. It may be prudent to bring the project forward and make it the primary receive array. The Beverages would only be connected for use during contests.

As I was finishing this article a message popped up when I checked the local weather. This is lightning safety awareness week in Canada. How timely.

CQ DX?

It's a warm June evening and I am seriously behind in my blogging. My intent was to write nothing until one of my many projects reached fruition, and then get back to publishing more technical articles. I have three partially written technical articles that are either taking longer than I'd like or the projects themselves are incomplete. I also have less time for writing because I have unrelated interests and responsibilities.

Since bloggers abhor a blogging vacuum, I come to today's article. What is DX and when is it appropriate or inappropriate to respond to a CQ DX?

I find it more of a nuisance on FT8 than CW and SSB. That is, when I call CQ DX on FT8 or a directed CQ such as CQ AS, I get many callers from W/VE stations. I do not consider them to be DX and they are certainly not in the targetted area. What they are thinking is less certain. When I make a directed CQ I rarely reply to them unless it's long distance propagation like W6/W7/VE7 on 6 meter sporadic E. 

Calls from non-DX stations has become so common that I often uncheck the "Call 1st" box on WSJT-X. I pick and choose every call. My reaction time in reading the caller list and choosing who I reply is more rapid and easier than when I was an FT8 novice. The early decode pass added in a previous WSJT-X version helpfully provides another second or two to the time you have to act. FT4 is far less forgiving of slow human reaction.

What are the reasons non-DX stations call me? I have an idea because some of them have told me:

• I really really really need FN24.
• I'm a W, you're a VE. Therefore, DX!
• Contest! The normal rules don't apply.
• I'm QRP (or a wet noodle antenna, etc.) and I have trouble working anybody. Please?
  
• Not human: robot software configured to respond to a CQ from a call not yet in the log.
  

Other than the last item none of these are truly unreasonable. It's a matter of perspective or opinion and reasonable people can disagree. Most who call me when my CQ is directed elsewhere stop after one or two attempts. A few don't give up. The truly annoying ones are those that call on my transmit frequency since that can QRM the targetted DX. After all, most digital operators choose a transmit frequency (audio offset) that is free of other signals and callers know that can be a good way to work you.

Sometimes I answer anyway. When I am testing propagation with a string of CQs and there is a low probability of getting what I'm calling for, working others accomplishes my main objective: being present and, hopefully, being heard if the propagation allows. I use PSK Reporter to see where I'm being heard. When the opening is alive and I'm working stations in the targetted area I do not respond to stations that are not DX. 

I am also more likely to reply to calls from hams I know personally. This is often a way to say 'hello' which is otherwise quite difficult on digital modes. There can also be a real life penalty for ignoring a call from a friend.

When I call CQ DX on CW and SSB I am more likely to respond to non-DX. They usually just want a signal report or to know they are getting out. Unlike FT8, it only takes a few moments of my time. I will not spend the required one to two minutes for an unwanted non-DX FT8 QSO while a tenuous 6 meter DX path is in play.

JTDX will filter the decoded messages to exclude unwanted areas and call sign patterns. That feature reduces screen clutter during busy DX openings. You also have the dubious excuse of not seeing the messages of callers you would rather not be bothered by. Of course you risk filtering some callers you might want to see, including those of friends or to monitor what others are working.

I use WSJT-X so I see all callers. Following the activity on the screen during hectic openings can be difficult, but at least I have the opportunity to see everything. Some days I wonder whether I am making the right choice. Many active 6 meters operators use JTDX and filter unwanted callers. It is possible that I will trial the software and its filters. Maybe I'll like it and maybe not.

At least for this season I'll continue with my ad hoc reactions when I call CQ DX.

6 Meter Sporadic E Season, So Far

As I type this the WSJT-X monitor is packed with signals. I glance at it occasionally but do not transmit. The reason is my primary motivation for being active on 6 meters: DX. There isn't much to be worked, or at least not yet.

This is not to say that I've worked no DX this season. I have. We also have F-layer propagation, better when the solar flux is high (it's low at the moment), or if it connects with northern hemisphere sporadic E. That has helped extend openings deep into South America and the Pacific.

I have yet to work a European station this year, and all I've heard is a few of the western Europe big guns. Last year I worked hundreds in May. Looking back at my records it is clear that 2021 was an exceptional year. This year appears to be more typical. The pattern up to the end of May is close to that of 2020. I am referring to the propagation here since it depends on your location. In Europe and the southern US the DX opportunities have been better. VE3 is not the best locale for sporadic E.

So what have I worked? No new countries since working CE and CX earlier this spring, but some have been heard or I've heard others working them. These include: V4, HR, OA, C5, ZL7, ZD7, OD. With 113 countries worked on 6 meter digital modes there are few opportunities to work more using sporadic E. I will keep trying! Prospects for working many more countries using the F-layer are rapidly improving. See the following chart from Macintosh:

Speaking of ZL7, here is a screen capture from a friend of mine. This occurred Thursday May 19, while I was travelling to the Hamvention. You can't be everywhere. I'll just have to be patient for another opportunity.

Paul didn't work him but a few others in the area did. Solar flux was 180 at the time, a record for the waxing solar cycle 25. We can expect a lot more DX opportunities over the next few years.

With few DX opportunities so far this season, my operating time on 6 meters has been minimal. However, I monitor activity daily. There is nothing else for the station to do since my interest in HF wanes in the warm weather and I am busy with ham and other projects. I am usually ready to pounce when I hear a station of interest. I miss a few when I am busy outside the shack.

That means you may not hear me when sporadic E is intense. If it's ordinary single hop with Canada and the US, I often stay off the air. I keep monitoring promising DX paths and perhaps occasionally transmit targetted CQs. When I do that I rarely reply to calls from nearby. For example, I typically ignore calls from Canada and US stations when I call CQ DX/EU/SA/AF/AS etc. I especially ignore those calling on my transmit frequency, since it is QRM for possible DX replies, or on the 50.323 MHz intercontinental DX window. It's a matter of courtesy.

One ongoing amusement is the number of hams replying to fake calls and false decodes. They have improbable call signs and grids, and in the latter case are almost always very weak. A couple of recent examples caught my attention. 

One was a station signing R0BOT from FN03. It was almost certainly someone accusing another certain someone of using robot software, which is unethical. Yet many stations who ought to know better called R0BOT! In a way it's touching that so many hams put an enormity of trust into the software they use.

I will only note that if this false decode was a real message we are likely witnessing the start of WW III.

Which brings us to a more interesting question: where are the blog's technical articles?

It's true that these have lagged. The warm weather has driven me outdoors and to non-ham pursuits, but I am partway through a number of projects. They'll eventually generate articles. These include:

• Rebuild of the prop pitch motor gearbox. I've made significant progress and also hit roadblocks. More on this when I am done. On related news, I may soon acquire a spare (third) small prop pitch motor. I really need a spare on hand so that I can rapidly make a substitution when a motor requires service.
• The UI (user interface) of the antenna selector is substantially complete, and it is communicating with the Arduino doing the actual switching chores. The project was delayed when I decided to make a fundamental change to the sharing of duties between the two software components. I have an article in the works to describe the various design choices I've made. It may be helpful to others with similar station automation aspirations.
• I have in hand the final component for the 10 meter stack switch. Construction is not a priority right now so I may not have the stack operational until the fall. I altered the physical design from that for the 15 meter and 20 meter stack switches to ease construction and repair.
• Repairs are needed to the 3-element 40 meter yagi. It still works well so I've procrastinated making the several climbs needed to deal with the problems.
  

Another bump in the road is COVID. I came back from Hamvention with the virus as did a number of my friends. It was truly a super spreader event! My symptoms were minor and no more than an inconvenience for several days. Nevertheless it cost me close to a week of productivity. I am almost fully recovered. 

This was going to be the end of the article, and then something wonderful happened.

Above is a PSK Reporter map of where I was being heard on 6 meter FT8 during the early evening of June 3. I was surprised to be flagged by E51WL on 50.313 MHz. You can see that I noticed the flag close to an hour too late. By then the common watering hole was extremely busy so I switched to 50.323 MHz to try my luck.

Within five minutes I logged 3D2AG. The amp was off for that QSO so I turned it on and kept looking to the Pacific. In the midst of a long string of CQs I was called by E51WL. We worked despite the weak signals. He was copied here as high as -2 db over the following hour. I heard many others working both E51WL and 3D2AG.

I kept CQing and monitoring but there was no more. It would have been nice to work ZL and others down under. The breadth and length of the opening and the slow QSB are strong indicators that it was F2 propagation. 6 meters will become increasingly interesting over the next few years.