For a long time the ugliest presence on my operating desk has been the controller for the two prop pitch rotators. When I say ugly, I mean really ugly. Have and look and see what you think. It's sitting on top of an Icom 7610, which makes for quite a contrast.
The controller is home brew and very old. The repurposed CDR direction meter failed over a year ago. As an interim(!) measure I installed a pair of op amp circuits on a prototype board feeding an outboard milliammeter pulled from my junk box. A rotary switch was installed to select the motor and direction, and also select which rotator direction to display.
Despite its deplorable appearance it works quite well. Just don't breathe hard when you get close to it! I never did get around to putting the circuits on a PCB. My intent was to gut the innards of a couple of orphan Hy-Gain rotator controllers to serve as the prop pitch controllers. Then I had second thoughts. I put off doing anything with it until I was certain of what I wanted for a permanent solution.
Earlier this year I decided to set aside the orphan controllers that I picked up at local flea markets and took an entirely different approach. So I built a new prototype. It's been languishing on the operating desk due to family issues, thus adding to the ugliness for months. I recently made an effort to move the project forward.
I have all the parts and a plan to complete the controller. The first version will only display the direction of the rotators. Turning the motors will, for the time being, continue with the ugly controller. One reason is that, in the midst of this project, the power supply developed serious problems and needs repair or replacement. Troubleshooting has been difficult with the fragile prototype board perched on top of the transformer and filter capacitor.
Although not assembled, even in its first version, enough has been done to be worth an article. Another will follow when it is done, and perhaps another when the rotation activation features are added. After that it will require refinement, which will be easier since the work should be almost entirely in the software.
Design objectives & features
I had a variety of objectives in mind for the controller, some critical and others for convenience or personal interest. They are listed below, but not in any particular order. I developed the list organically as I considered options to replace the existing controller and as I formed opinions on functionality as I proceeded.
- Compact size: I want it to fit well and look good on the operating desk
- Remote power supply: The 24 VDC power supply for the motor is fairly large and does not need to take up space on the operating desk
- Future PC integration: Integrate rotator control with my station automation system to provide easy access from each operating position (multi-op contests) and, possibly, for remote operation
- Software: Ease of modification and extension
- Support a variety of direction pot methods, and possibly other direction indicators
- Over 360° rotation: Handy in a pinch, but with strict limits to avoid coax damage
- Digital display and control: No mechanical meters or user-activated switches for motor power
- Front panel calibration: No need to open it up or to climb the tower
There are commercial products that can do most of what I want. However, regular readers will have learned by now that I prefer to design and build what I can. This project is well within my abilities. Indeed, it should be within the abilities of many hams. It's an opportunity to learn and to have the satisfaction of building station equipment that will be used every day.
Architecture
This version of the controller requires that the direction potentiometer on the tower be 10:1 and 10 kΩ. The manufacturer is Bourn and they are available from most large component suppliers. There are knock offs available on other sites that are not the same quality but are cheap and work pretty well. They need to be well protected from moisture. You can see one in the picture below being used to emulate the tower pot.
An op-amp differential amplifier compares the tower pot to a 10 kΩ zeroing pot in the controller and feeds that to an Arduino analogue (ADC) GPIO pin via a linear protection circuit. The op-amp circuit is very similar to that in the prototype sitting on the old controller. The differences are described in the next section.
Software measures the voltage and converts that to a bearing. In the present implementation, north is at the centre of rotation and over-360° rotation is supported. This is the most useful arrangement for HF propagation in this part of the world. Any centre can be set in the software, as can rotation limits.
The display is a 2×16 LCD (1602A). These are very common and cheap. A friend made a few bezels for the display on his 3D printer from designs available online. We haven't yet settled on which one to use.
The controller is powered from a 12 VDC (13.8 VDC) external supply. Onboard converters and regulators provide ±15 volts for the op-amp circuits and external pots and 5 VDC for the Arduino and LCD. The prototype is driven by a pair of 9 VDC batteries which, as we'll see, is insufficient.
There will be connectors on the rear of the enclosure for the direction pots on the towers and to drive relays in the 24 VDC motor power supplies. I have two power supplies so that both motors can be run concurrently. The software will sequence the relays and, in a future version, detect motion faults to prevent damage to the motors and power supplies.
Op-amp circuit
The op-amp circuit is almost identical to that of the earlier prototype, the one that is currently in use. I reverted to this circuit after exploring alternative differential amplifier designs that never quite did what I wanted. I developed a simple spreadsheet to predict performance. The circuit has to be linear within the range the tower pot covers with predictable and adjustable gain and zeroing.
In the end, simplicity won out over perfection. I can live with a few quirks.
There is one important difference between this circuit and that of the earlier prototype. A physical meter responds to current while the analogue GPIO pin ADC responds to voltage. I set a fixed circuit gain (negative feedback) and used a pot as a voltage divider to lower the net gain of the circuit. The protection circuit protects the Arduino microprocessor from adjustment errors and voltage surges.
For ±15 VDC op-amp power, one turn of the 10:1 tower direction pot has a 3 volt range over 360° (10% of 30 volts). That corresponds to the motion of the direction pot on the 1:1 rotation of the chain-driven prop pitch motor. On the other tower, the belt drive for the pot has an approximate ratio of 2.5:1 for 360° rotation. The circuit supports both with the fixed resistor for negative feedback. All that's required is to set the level pot.
The protection circuit design is linear between 1.5 and 4.5 volts, which is a range of 3 volts. With the 10 kΩ feedback resistor the gain of the op-amp is above unity, so the direct drive motor will cause a range higher than 3 volts at the op-amp output. The gain isn't so high that the op-amp is pushed beyond its linear curve; that is, output voltage approaching either power rail. It is however recommended that the tower pot be roughly centred within its 10 turn rotation so that there is no risk of the inputs approaching the power rail voltages. The 741 data sheet specifies what is allowed.
The same spec sheet shows that the minimum supply voltage for the 741 is ±10 volts. The 9 volt batteries are not quite enough and I did see a few anomalies when I let the input voltages get too high. Consider that for a 3-turn rotation of the tower pot the input voltage range is 5.4 volts (30% of 18 volts), or 9 volts for ±15 volt supplies.
Because the voltage for counterclockwise south (180° bearing) is 1.5 volts and not 0 volts, adjustment of the gain (level pot) also changes the 1.5 volt value. This does not occur on the earlier prototype because there is a true zero volt point for the meter movement. This is an unfortunate quirk but one I can live with. Both the zero and gain pots will be exposed to the operator for calibration. For a true zero point circuit the gain control can be a trim pot within the enclosure, calibrated to the the turns ratio driving the tower pot.
The circuit requires protection from RFI and surges (e.g. lightning) since the tower pots are permanently connected. Op-amps are sensitive devices and microprocessors are fragile. Modular connectors rather than barrier strips will allow rapid disconnection for added safety. RFC and capacitors will bypass RF to ground. GDT (gas discharge tubes) will shunt high voltages pulses to ground. These will depend on the RFC and capacitors to "slow" the rise time since the pots must be DC coupled. Component selection has not yet been decided.
Arduino hardware & software
Perhaps one of the most critical requirements of a processor for control applications is the number and type of GPIO (general purpose input output) pins. Despite its simplicity, quite a few are needed:
- LCD: 6
- Direction indicator: 1 analogue input per direction pot
- Rotation selection: 2 digital inputs per prop pitch motor
- Rotator activation: 2 digital outputs per prop pitch motor, and 1 more for power sequencing
- Rotation sensing: 1 or 2 analogue inputs per rotator
- Wi-Fi connectivity: if not integrated, at least 1 RX/TX pair is needed
For control of my two prop pitch motors, the initial version requires 18 GPIO pins, of which 2 are analogue. There are ways to reduce the GPIO requirement that I won't delve into in this article. I am keeping the design simple for the initial version of the project.
I dug into my junk box and pulled out the clone Arduino Uno that you can see above. It is barely sufficient in this application since almost every GPIO pin will need to be used. Something like an Arduino Mega would be needed to support more than two prop pitch rotators. Processor speed and memory are unimportant in this application.
The display is a bottleneck so it's helpful that not a lot is needed in this application. An LCD with two lines of 16 characters, with each character a 5×8 matrix (like dot-matrix printer of the past) is good enough. Above you can see that the top line is for labels and the second is for the direction information. There is a limited character set native to these cheap and ubiquitous displays (a few dollars each) but it is easy to create custom characters. I created characters for the degree symbol (shown), arrows for rotation direction and alert symbols for faults and warnings.
The trim pot on the left side of the protoboard sets the display contrast. It is very sensitive to the voltage, with the required value in the vicinity of 1 volt. There are pins for powering the backlight, and that's mandatory for almost all environments. Visibility of the display is better than it appears in the picture.
Although the dimensions are almost an industry standard, not every LCD of this type is identical. When you 3D print a bezel be sure it's the correct size and that there is a way to tighten it to the enclosure front panel. Our first few attempts were deficient. I am eagerly awaiting the latest print since it appears to be what I need.
The replacement of physical with digital direction indication requires smoothing. The signal from the tower pot is constantly changing, whether the motor is running or not. The mast rocks back and forth and the pot has imperfections and glitches, especially as it ages. Physical meter movements naturally smooth brief glitches (perhaps up to 100 ms) but we want to see all real motion of the mast. With a readout precision of 1° and Arduino cycle times that are quite short, the displayed direction is constantly changing. Active smoothing is desirable.
Smoothing can be done in hardware or software, or both. A time constant circuit (T = RC) easily takes care of brief glitches. For example, a 20 μF capacitor across the 10 kΩ level pot has a time constant of about 200 ms. Glitches will be smoothed but not normal rotation, which includes rocking in the wind. The same can be accomplished in software with a moving average. A simple example is to display the average of the last 5 measurements, where the loop interval is 50 ms. Software can do even better by identifying glitches -- unexpected and impossible changes between successive measurements -- and discard or modify them.
With these methods it is possible to keep the bearing display sane. However, if the pot has degraded to the point that glitches are common or the voltage is unreliable it will have to be replaced. Software can't solve every problem.
Glitches are common with buttons and will have to be dealt with in a similar fashion when, in the next version, they are used to turn the rotators. Again, both hardware and software measures can be used. In this case, the term for the process is debouncing.
Notice in the picture above that the right hand bearing is "---°". This is done in software when the signal at the analogue GPIO pin (ADC) is out of range. In this case the pin has been grounded (not used for now). If it is not grounded the display might show a value, and that value would be related to that present on the operational pin for the bearing on the left. This is necessary since the Arduino multiplexes the analogue GPIO pins into a single ADC circuit and continuously scans each input.
Due to the high input impedance and stray capacitance, an open but used analogue GPIO pin will measure the residual voltage stored in the stray capacitance. When the pin is in service the phantom reading vanishes. Unused inputs for disconnected tower pots may have to be grounded or pulled high to avoid this phenomenon. It can be done by modifying the software but that can be inconvenient.
Next steps
Circumstances to which I previously alluded are serious enough to keep me away from contests and most station work, and the blog. I've climbed towers only thrice in the intervening two months and two of those weren't mine. The list of station work to be done is growing. This will be a busy year.
At least the prop pitch controller can be worked on indoors and during evenings which gives me more opportunity to get it done. I have the enclosure, the power supplies and other components to box up the controller. Aspects of those details are interesting and well worth another article. Time permitting, that will come later in May.