Jim White, WD0E

Linear actuators used to turn home TV C/Ku band dishes provide an inexpensive way to position or point Amateur antenna arrays or dishes. A simple DPDT switch can be used to move the arm in or out and elevate the array. But there is no simple method for displaying the elevation in the station. A potentiometer with a weight on the shaft could be built and attached to the antenna, but this is vulnerable to wind and other problems. More expensive solutions include single package gravity actuated tilt meters. However linear actuators include a contact closure that provides pulses as the arm moves that can be read by a simple microprocessor or embedded controller and interpreted to provide the elevation readout. Today's embedded controllers combined with some very capable C language compilers make the job of building a combination control and readout quite easy.

This controller was built to run the linear actuator used to elevate the EME array at The Olde Antenna Lab, W6OAL, Parker, Colorado (Figures 1, 2 and 3). As of this writing it is in the experimental stages. This article is intended to describe the hardware and software so others may build on these ideas. This unit is one of a kind, however these methods could be used to build similar units for other antenna installations.

Operation is quite simple. The front of the control box (Figure 4) provides a switch and button to move the array up or down and an LCD that shows the direction of movement, the pulse counts from the arm, and the elevation in degrees. The back panel (Figure 5) has connectors for the external 24 VDC supply, the 5 VDC supply, and the wires to the actuator. The back also has a combination contrast and on/off control and a serial connector for calibration and test.

The schematic for the controller is shown in Figure 6. The Microprocessor (MPU) is an Atmel 90LS8535. This chip provides considerably more functionality than this application requires but was used because we had several on hand. The controller uses only the serial interface, LCD interface and three I/O pins of the MPU. The MPU is operated at 4 MHz using its internal oscillator and an external crystal. The /reset line is held high by a pull up resistor. Other sensitive pins are also pulled high or low and some are bypassed with small capacitors to ground. Zener diodes are used to prevent motor back EMF pulses from spiking a high voltage into the MPU input pins.

24 VDC is supplied from an external source to run the linear actuator motor. 5 VDC is supplied from an external source to run the MPU and LCD. The 5V supply is also used to provide a high to the sense pin that counts contact closure state changes from the pulse relay in the actuator.

A DE-9F connector provides a serial interface to a PC at RS-232 levels and 9600 bps. The MPU has an internal UART that provides a TTL level serial interface, a MAX202 interface chip provides the TTL to RS-232 level conversions. This interface is used only when calibrating the control unit to a particular installation and for diagnostics and testing.

An AND48GST LCD provides the display of motor direction, actuator pulse counts and elevation in degrees. It is connected to PORT C of the MPU and is a two line by 16 character display. Four data lines and three control lines are interfaced to the MPU and three wires provide LCD power and contrast. The contrast is controlled by a 10k potentiometer that also functions as an on/off switch for the 5 V supply.

Applying 24 VDC to its motor moves the actuator arm. Reversing the polarity reverses the motor and the direction of the arm. A DPDT switch is used to set voltage polarity, then a SPST momentary contact button is used to turn on the motor. The voltage on the two motor leads is connected through diodes and voltage dividers to provide about 5V to two pins of the MPU. The software detects a logic high (+ voltage) on these pins to sense when the motor is on and which direction it is moving.

As the arm moves in or out a contact opens and closes in the actuator at the rate of about 20 closures (40 transitions) per inch. The 5 V supply is connected through a current limiting resistor to that set of contacts and back to an I/O pin on the MPU. A pull down resistor on that pin assures clean voltage transitions on the pin. The software detects and counts the transitions and uses them to determine the position of the arm.

The software performs the following functions:

• Determine when the actuator motor is turned on and which direction it is moving
• Detect and count pulse transitions and maintain a count reflecting the position of the arm
• Use a formula to translate the transition count into elevation in degrees
• Display the motor direction, counts, and degrees of elevation on the LCD
• Facilitate calibration by talking to a PC via the serial port
• Provide some diagnostic data on the serial port when the motor is activated

The main loop first looks to see if the motor is on. If it is off "OFF" is displayed on the LCD along with the current pulse count and elevation in degrees. In this 'off' loop the serial buffer is checked to see if any characters have come in from the external PC. If so a case statement construct and messages to the serial port step the user through the calibration process. If the motor is on the 'UP' pin is tested to determine if the movement is up or down. "UP" or "DOWN" is displayed accordingly, the 'up' flag is set, and the procedure 'do_math()' is called. In 'do_math()' a formula is used to calculate the elevation in degrees from the position of the arm as reflected by the transition count and the counts and degrees are displayed on the LCD. They are also sent to the serial port for diagnostic purposes along with other data used when testing.

Values that must be retained when the unit is powered off are stored in the MPU’s internal EEPROM. These include the zero elevation count, the 90 degrees count, the formula coefficients and the current position in counts and degrees.

The software in the included source listing is written in CodeVision AVR-C for Atmel micro-controllers (see Tools, below, for sources and availability of tools used in this project). This is a very capable integrated development environment. We used the Standard version that includes a code generation 'wizard'. The program was built by first using the wizard to create a shell of source code with the functions we needed. We simply started up a new project and selected the functions we wanted. For this project we told the wizard to build the following code:

• The interrupt driven UART interface at 9600,N,8,1. Interrupt on receive only.
• The LCD interface and what port it is on (the 90LS8535 has four 8 bit ports called A, B, C and D.)
• How to initialize the port pins we are using to sense motor motion and count pulses (PORT A)
• Turn off all other features we are not using.

The wizard then built about a two page C source code listing with all the initialization code for the MPU and the functions we needed. It included a main process loop with a comment line inside that said

"// put your code here".

We entered only the code shown in Figure 7, including the EEPROM flag on those variables we wanted to store in the internal EEPROM so they persist when power is turned off. The wizard, combined with the built in functions in the IDE such as the LCD interface, made the task of writing the code to do what we needed in our application relatively easy. We didn't have to figure out how to talk to the LCD, how to get characters in and out of the serial port, or even how to store data permanently in the EEPROM.

Unpleasant weather has prevented the integration of the controller to the array. The following section discusses the calibration method currently programmed into the MPU, a method of calibrating an array like this that might be used and the method we intend to use when Mother Nature allows.

The only time a PC needs to be connected to the controller is to do calibration. The current MPU program includes a calibration process that uses the 0 and 90-degree elevation transition counts and assumes a linear relationship between counts and the elevation of the antenna.

The calibration process starts when the user hits any key on a terminal connected to the controller's serial port. The software sends a prompt message telling the user to move the antenna to the zero elevation position and hit '0'. When the user hits '0' 100 is stored in the EEPROM as the zero elevation count. That value was chosen to avoid negative numbers (although it wouldn't really matter if we set this to zero counts and had a negative count if the array went below zero elevation). Note that the zero elevation position will always be 100 counts regardless of the position of the arm when at zero elevation. The user is then prompted to move the array to 90 degrees and hit '9'. When they hit '9' the count value for the 90 degree position of the arm is stored, the difference between the two (-100) is calculated and that value is divided by 90. This results in a multiplier factor that is stored in EEPROM (counts per degree of elevation). The user is then sent a message indicating calibration is complete. From this point the counts are divided by the multiplier factor to determine and display the elevation in degrees.

As noted above this method assumes the length of the actuator arm relative to the elevation of the antennas can be expressed by a linear function (elevation = transition count / calibration factor). In practice this relationship will depend on the mechanical linkage between the arm and the antenna array. For most installations it is likely a more complex formula will be needed to accurately calculate degrees from pulse transitions. Unfortunately no single formula is going to work in every installation.

In the W6OAL EME array the actuator is attached to the vertical mast and cross tower section to form a triangle. If we look at this as a trigonometry problem, the mast and cross tower are two unequal fixed length sides of the triangle while the arm of the actuator forms the third side. As the arm moves in and out the length of the actuator side changes and the angle between the mast and cross tower changes reflecting the elevation of the antennas. The elevation angle is that included by the mast and cross-tower and is opposite the actuator arm side. Consulting a trigonometry reference, we find the formula for relating the length of the actuator side of the triangle to the angle opposite is:

where A is the elevation angle, b and c are the adjacent fixed length sides and c is the opposite side (the actuator arm). To calibrate the controller we might carefully measure the distances between the hinge pivot point and the attachment points of the arm to get b and c, carefully measure the length of the actuator arm relative to pulse transitions to get a over the range of zero to ninety degrees of elevation, then plug those numbers into this formula to get the elevation angles A. However the accuracy of the result would depend on our ability to precisely measure all those lengths, which is not an easy task given the construction of the brackets and the fact that this assembly is on top of a tower.

The method we will use is much faster, easier and more accurate. It is essentially an end to end measurement of the system. We will temporarily attach a protractor with a weighted string at its center to the two vertical legs of the cross-tower to provide an elevation angle measurement. First we will move the array to zero elevation and tell the software we are there. We will then move the array up to 90 stopping every 5 degrees to manually record the elevation in degrees and the counts as provided by the software. This will give us a table that relates angle to transition counts. By relating angle to counts directly we will eliminate all potential sources of error except our ability to read the protractor. The next step is to find a formula which expresses that relationship. For this we will use a very nice shareware program called CurveExpert that I have used to derive the telemetry calibration coefficients for several satellites. We will simply enter the table of recorded values (elevation vs. transition counts) into the CurveExpert input screen and with a few mouse clicks tell it to fit the curve and give us the formula and its coefficients. We will first try the simplest case, the quadratic equation.

where angle is the elevation angle in degrees, x is the transition counts and a, b and c are provided by CurveExpert.

But if that will not fit the OAL antenna case there are a couple of hundred built in formulas CurveExpert will test against the data looking for the one that best fits. We may also enter the ACOS formula above and let CurveExpert determine the coefficients. Either way measuring the input data (degrees) and the resulting counts, then deriving a formula to fit that table is more accurate than trying to measure multiple mechanical variables in the system and build a formula from them.

When we see what formula will fit the data for the OAL array we will replace the calculation code in do_math() with the formula that works and remove the sections of the calibration routine that aren’t applicable.

Nothing about the construction of this controller is particularly critical. Wire length, parts placement, enclosure and connectors can all be done with just about whatever you have available (Figure 8). The most sensitive area is probably the placement of the crystal and its associated capacitors, which need to be as close to the MPU as possible. The next most sensitive issue may be the length of wire from the controller to the actuator, which needs to be short enough or large enough to assure a reasonable voltage drop. It's also a good idea to keep the motor wires away from the MPU, especially the Vcc and Reset pins. We used a plastic enclosure but a metal one may be a good idea to shield the electronics from RF especially if used in a high power HF station.

The software for the MPU was developed using the CodeVisionAVR C language integrated development environment (IDE) from HP InfoTech S.R.L We run it on a Pentium 150 PC with a 17" monitor. The parallel port is connected to an STK200 development board from Atmel. That board allows us to plug in any of the AT90 series MPUs and program or test them. It provides pins to access all the ports, the UART, etc, as well as providing power for the chip. We built up the electronics for the controller on a plug in proto-board with an old actuator connected for testing. Then we inserted a 90LS8353 into the STK200 and wired the sense pins between the STK200 and proto-board. The process of making a code change and testing it takes just a few seconds and is delightfully easy. You simply use the provided editor to make the change and click on a tool bar button. The IDE does the rest: Compile the C code into assembler, create an AVR object module, program the flash memory in the MPU and start it running. It is so fast and easy it lends itself to lots of experimentation.

CodeVisionAVR is available at http://infotech.ir.ro. We used the Standard version which is the full featured commercial product and costs about US$150. Less capable and less expensive versions are also available. There are a couple of other similar C language IDEs also available with varying sets of features and a range of costs. For Linux there is a set of GNU tools available for the Atmel processors.

The STK200 evaluation board is available from several sources on the web. A search for Atmel products will turn up a number of vendors. Stock varies among them so you may have to search a bit and perhaps make some phone calls to find one. They should cost less than US$100.

Atmel processors are also available from numerous vendors. Stocks were low during the latter part of 2000 but there seem to be plenty available now. The AT90LS8535 is about US$8 in small quantities. A controller like this could also be built around the Microchip PIC series parts. Similar tools are available for them.

We bought the parts we didn't have in the junk box from Allied and DigiKey via the WEB but many other vendors had them as well.

CurveExpert is available through http://www.ebicom.net/~dhyams/cvxpt.htm.

This is an experiment. The author is not responsible for results those using this software, circuits or ideas may or may not achieve. The author has no relationship with any of the suppliers except that of a satisfied customer.

The purpose of this article was primarily to show how modern multi-function microprocessors can be used to provide the position read-out from linear actuators in antenna installations. In the process we hope we also provided some ideas about how one might build an actuator into an antenna system. We also hoped to showed how easy it is to create software for projects like this using modern software development tools. Applications for similar microprocessor controlled devices in Amateur stations are limited only by the imagination.