Sunday, July 31, 2022

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:

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.


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.


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.

Thursday, July 21, 2022

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.

Tuesday, July 12, 2022

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.