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.
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.
