After building and installing my two reversible Beverage receive antennas and the remote switch to select the 4 directions (and expandable to 8) I wired up a simple switch arrangement at the operating desk to control the system. Temporary solutions do have a tendency to linger and I have been living with it and its limitations ever since.
I have now made definitive steps towards a permanent control system for the operating desk. I modelled the home brew system based on the ergonomics of the control systems I've admired in the shacks of other low band aficionados. The prototype software is complete and the design of the enclosure and controls is almost done. Soon I'll be punching holes and putting it all together.
Completion is still weeks away because there are several equally important projects filling my time. Rather than wait I thought it would be interesting to describe the design and the prototype so that you can see the project midstream. Too often when showing the final product many important steps and decision points are omitted, yet they are quite interesting to other prospective builders.
Design objectives
The design is focussed on ergonomics. It needs to fit comfortably on the operating desk among all the other paraphernalia needed for two keyboard SO2R. Room on the desktop is at a premium. I expanded the original plan to make use of the additional space on the sloped project box a friend (VE3WMB) gave me to include the 80 meter vertical yagi and control of high and low antenna combinations on all bands.
It is not and will not become an antenna switch. This direction and high-low antenna selector works in concert with my existing controller for the 2 × 8 antenna switch. Automation will be added in due time.
The design objectives, as I originally conceived the selector:
- Fit comfortably on the operating desk, within easy reach and not crowded out other equipment
- Visual indication of where each antenna is pointed, and whether high or low antenna selected
- Sloped panel for maximum visibility when seated at the desk
- Big, fat buttons that are easy to see and hit when contest fatigue sets in
- Visual indication of all selection modes so that mistakes are minimized
- Intuitive operation that does not require a manual
- Easy to switch between off/on and omni-directional/directional
- Compatible with future touch screen control
Enclosure design
The enclosure I was given constrains the design of the controls and construction. That isn't a bad thing! Ask any poet and they'll tell you that meter and rhyme help rather than hinder their creativity. I stared at the enclosure periodically over a few months until I could envision the complete design. Though not perfect (what is?) it is adequate to my objectives.
As you can see it's small but not tiny. If it is to be central the display will need to be 2" higher so that it fits beneath. Putting it on a transceiver, like the current manual antenna select, would reduce visibility of the sloping panel. I may move the rotary antenna switches on the vertical front face to keep all the controls in one place and eliminate one box. Until I have full automation that seems to be a reasonable compromise.
I used OpenOffice drawing software to experiment with the layout -- there are many other choices. It is critical that software dimension controls match what is printed. The rulers and dimension parameters for each object are very helpful to ensure proper alignment. All the sizes you see are exact for the parts to be used. I use squares to accurately and easily place button around their circles. The big buttons have LEDs built in; I purchased a selection of colours.
Each big circle is for a world map projection centred on my QTH with true bearings. Many sites around the internet will produce these for free, a donation or a small charge. I like the ones produced at the NS6T site. They are free (donation requested), visually appealing and the size is customizable.
There are several ways to plasticize the printed map and I am exploring those. I'll use paper until I settle on a durable format.
To control the high band stacks I will initially use 3-way switches (on-off-on) to select lower, upper or both. The LED colours are blue for upper (sky) and green for lower (ground), which I find intuitive and understandable with a quick glance.
Both upper and lower LEDs ought to be lit for both but for manual 12 VDC switching it is easier not to do so even though the logic is easy enough: !U for the lower LED and !L for the upper LED. Later I can wire these into the software to avoid extra logic and for remote control. I follow the same logic for 80 and 40 meter antennas even though they are not stacked.
Another option is to substitute push buttons for the various switches. Pressing the button cycles through the available choices. For example, the stacks have 3 combinations. Hole size is approximately the same for buttons and switches so they can be changed later. Buttons all around can make operation simpler even when a button must be pressed twice. Software makes this flexibility easy to implement.
By printing the layout and taping it to the box various designs can be tested. Moving the drawing from the screen to the fingers is a useful means to verify that it works for you. Finally, the drawings are taped to the box as a drilling template.
Processor and software
I chose Arduino for this project. It's simple to use and program with the free IDE. Even the small Arduino Nano has more than adequate capacity for the Beverage controller. The greater though still modest complexity of Raspberry Pi isn't needed. The constraint isn't speed or memory: it's GPIO pins.
The Beverage selector fits nicely on a Nano but to add the others requires the large GPIO count of an Arduino Mega. Alternatively, more than one Nano can be used: one for the 80 meter array and another for upper deck controllers. Multiple processors simplify the software and wiring at the cost of managing multiple Arduino sketches and downloading them. I have a Mega board so I will try it out.
For normal use no USB connection is needed. It is powered from a 12 (13.8) VDC for the remote antenna relays and, via a 5 VDC voltage regulator, the Arduino(s).
The main difficulty building the breadboard prototype for the Beverage selector is the quantity of LEDs and controls. There are 8 direction LEDs (top left), 5 relays (bottom right LEDs) and 8 push buttons. There are so many wires and LEDs I needed two breadboards. The sum (21) is more than the GPIO complement of the Arduino Nano.
To conserve GPIO pins the direction selector buttons connect to a single analogue GPIO pin. A resistors in a ring among the buttons comprise a voltage divider. When a button is pressed it puts a voltage in the range of 0 to 5 VDC on the analogue pin and converted to a digital value by the ADC.
The resistors are equal (220 Ω in the prototype) to ensure the voltage steps are near equal. The blue wire from A0 and resting at top centre is the "button". It is touched to a junction of the resistor ring to simulate a button push.
The picture shows the north direction has been selected. The LED at the top is for the button lamp. It's dim because I ran out of 220 Ω resistors and the GPIO high level is less than 5 VDC and is pulled down by LED current. The relay for the north-south Beverage is on (blue) and because south is the normal direction the reversing relay (red) is on.
A high value resistor (bottom left) from the pin to 5 VDC acts as a pull-up resistor that puts 5 VDC on the pin when no button is pressed. Although there are software selected pull-up resistors for the GPIO pins these are of uncertain value and we need one whose value is much greater than the sum of the resistor network. It is 33 kΩ only because that was the first suitable one I pulled from my resistor bin.
The Arduino code to interpret the analogue input is simple and reliable. ADC_MAX is 1023, the maximum value for a 10-bit ADC referenced to 5 VDC.
int buttonValue (int adcValue, int buttons) {
if (adcValue < 0 || adcValue > ADC_MAX || buttons < 1) return -1;
int difference = 1000;
int button = -1;
for (int i = 0; i <= buttons; i++) {
int newDiff = abs(adcValue - i * (ADC_MAX / buttons));
if (newDiff < difference) {
difference = newDiff;
button = i;
}
}
if (button >= buttons) button = -1;
return button;
}
Button presses are detected by periodic polling. Event driven (interrupts) are preferred but this is not practical on the Arduino, and not available on the Nano. There is a trade off among fast polling, processing cycles and human perception. As polling frequency increases the behaviour is closer to that of interrupts, which is good. Since the Arduino is doing nothing else this is not a problem, and the power dissipation penalty of the additional processing cycles is negligible. The prototype uses slow 100 ms polling (BUTTON_FSM_STEP) to aid debugging. That is slow enough for the polling rate to be noticed.
void loop() {
int bevButtonSense = analogRead(BUTTONS_BEV_ADC);
int bevButton = buttonValue (bevButtonSense, BUTTONS_BEV);
bevButtonFsm (bevButton);
delay(BUTTON_FSM_STEP);
}
A finite state machine (FSM) is used to interpret and act events. This is a common algorithmic technique that may be unfamiliar to many hobbyists. I'll omit the details in this discussion. The FSM debounces the buttons, differentiates short and long presses and controls the states of indicator LEDs and antenna relays. One FSM is needed for every selector: Beverages, 80 meter direction, 80 meter mode, stacks, etc. There's just the one for the Beverages in the prototype.
A short press is one that passes the debounce check and the button press is longer than 200 ms. A short press selects the direction and updates the state of the indicator LEDs and relays. A long press of 2000 ms on the currently selected direction turns off all the relays and LEDs. It is equivalent to an off switch. I like to have the relays off when I'm away from the shack. I will decrease the timers after the controller is complete. Others may prefer more relaxed time limits.
The prototype does not account for the processing between polling steps since it is brief. For more precise timing the software can use the Arduino clock to adjust the step time to compensate for processing time. A fast poll rate avoids this perception problem for short press and button hold times to improve system response for hasty operators such as myself.
const int BUTTONS_BEV_ADC = A0;
const int RELAY_BEV_NE = A1;
const int RELAY_BEV_S = A2;
const int RELAY_BEV_E = A3;
const int RELAY_BEV_SE = A4;
const int RELAY_BEV_REVERSE = A5;
int RELAY_BEV_PINS [RELAYS_BEV] = {RELAY_BEV_NE, RELAY_BEV_S,
RELAY_BEV_E, RELAY_BEV_SE, RELAY_BEV_REVERSE};
int BUTTON_BEV_LEDS [BUTTONS_BEV] = {3, 4, 5, 6, 7, 8, 9, 10};
int BEV_RELAYS [BUTTONS_BEV] = {RELAY_BEV_S, RELAY_BEV_NE, RELAY_BEV_E,
RELAY_BEV_SE, RELAY_BEV_S, RELAY_BEV_NE, RELAY_BEV_E, RELAY_BEV_SE};
int BEV_REVERSE [BUTTONS_BEV] = {true, false, false, false,
false, true, true, true};
The GPIO pins and options are put into arrays and constants. This makes it easy to reassign pins without finding and editting each instance throughout the code. Clearing a set of LEDs and relays can be done with a single subroutine that is passed the array.
Since not all 8 directions are currently installed I can substitute Beverages in the arrays for ones that are closest. For example, to choose northwest the north Beverage can be selected until the southeast-northwest Beverage is actually built. The northwest or north indicator LED can be lit per your preference. I haven't decided which.
I am using several of the analogue pins as digital outputs, which the Arduino allows and is needed because there are insufficient digital pins on the Nano. The 'An' values are numeric constants above those of the digital GPIO pins. The values are different on different Arduino processors so the constant names should always be used in preference to their integer values.
Solid state switching
I don't like the sound of clacking relays in the shack. For the Beverage controller there will be a lot of that as I cycle through the directions on every CQ to pull weak signals out of the noise. The GPIO pins cannot directly drive the 12 VDC relays in the remote switches so local switching peripherals are needed.
Opto-isolated relays are commonly used since they're inexpensive and widely available. They're also noisy, bulky and overkill for switching currents of well below 1 A. I've operated at stations where a band change is startling because of the all the clacking relays that switch antennas, amplifiers and filters. I want a quiet, compact solid state solution.
One giant hole in my education is solid state theory and circuit design. I have always relied on circuits designed by others or made do with the simplest of circuits for my needs. Often I can troubleshoot solid state equipment since you don't need a lot of the theory. The lack is a problem because the commercial products for solid state switching are unsuitable and designing switches from discrete components is a challenging exercise for me.
My home brew switches are high side, where the relays are grounded and they are powered by placing 12 VDC on the control lines. Solid state high side switches are more difficult to design than low side switches, which should be low loss and must prevent the high relay voltage appearing on the GPIO pins and thereby destroy the microprocessor.
I educated myself from what I could find on the internet. Finding simple yet sensible design advice was not easy. Most is vague or far too technical.
Once I settled on an approach I purchased parts to experiment with. Candidate circuits were built and adjusted on a breadboard until I got the performance I wanted. The circuit at right is successfully emulating a relay switch for the reversing relay GPIO pin. It is shown operating at 5 VDC and it has been successfully tested at 12 VDC. I have yet to test it with the full range of load currents it will have to deal with in my station.
High side solid state switching for GPIO pins is an interesting topic that deserves an article of its own. Look for it within the next month.
Construction
Other than a long list of projects to do the prototype is done and construction of the final product can proceed. It's difficult to predict when it'll be done, other than I am determined to have it in use before the end of the winter 160 meter season.
When it's complete and in use for a while another article will follow to describe the controller in its entirety. I may make the final Arduino sketch available if there's interest.
No comments:
Post a Comment
All comments are moderated, and should appear within one day of submission.