What’s Inside of the Dual Axis Rotor System?
When we first came out with the original Portable 12Volt Antenna Rotor System now called the 12PR1A Ultra-Portable Rotor System, I wrote a document that detailed a lot of the details of the design and tried to explain why making a system like that was possible for Hams that like to build things but that it was not practical and would be difficult to do at a lower cost for the same feature set. This document details some of the technology used in the development and production of the 12PRSAT Dual Axis Rotor System, and details some of the complexity found in this product.
When we decided to develop a 12Volt Portable Dual Axis Rotor System we came up with a long list of features and design characteristics along with manufacturing requirements needed to make the product and bring it to market.
Some of the initial requirements included:
- Same low voltage operation as our other single axis products – 12Volt
- 4 wire interface between the Rotor Unit and a Hand Controller, same as the 12PR1A
- Fully digital; no potentiometers sending analog voltages for position.
- 1 Degree turning accuracy
- Fast and easy deployment; Include functionality to aid in rapid deployment for portable operations
- Common parts to our other products.
- User rich feature set
To support the first requirement of a 4 conductor interface meant that a dual processor design would be required; one processor in the hand controller acting as the master, providing the user and remote computer interface and a second controller in the motor unit managing the motors and sensors. There is no other way to control 2 motors and track their rotation along with monitor various sensors with only 4 conductors without a processor in the motor unit. The 2 processors must communicate with each other so the development of a command and response protocol to be used between the 2 processors needed to be developed. If a dual processor scheme was not used the system would require a rotor cable of 10 or more conductors making the cable large and bulky defeating the portable and rapid deployment aspect of the project.
The original design prototype used the same mechanical hardware as the Ultra-Portable Single Axis design. That worked fine for initial hardware and code development but we soon found that the light weight design was not ridged enough. The light weight internal metal frame would flex under a light load, especially during the breaking action used to stop a turn. A new frame using the same gear motor and output worm gear was designed using much thicker steal that is laser cut, precision bent and welded at each corner. Strong roller bearings were added to the design to further strengthen the internal structure. The final structural improvement was the use of brass for the worm wheel as the nylon and Delran worm wheels that are used in the Ultra-Portable design were not ridged enough for the demanding job or starting, turning and stopping at 1 degree increments. Both the Azimuth and Elevation units use the same basic frame/motor hardware, with different mounting positions. To get the resolution needed to track at 1 degree resolution, the use of an optical encoder is used requiring a custom made optical encoder disks.
To strengthen the design even more, we went to an aluminum enclosure and though not water proof, it is rain resistant as we use rubber seals on all openings and a custom made set of aluminum fittings to make the rotational interface between the Azimuth and Elevation motor units.
Experiments were done using stepper motors but we found for the available power of 12-14 volts at a few 100 ma along with the required start-stop loads that stepper motors were not the best choice. They are also more expensive, so we kept to the original DC gear head motor design. The use of DC motors had its own challenges and it took many months to develop the motor control state machine which is part of the core of the firmware used in the motor controller. A stepper motor would be much easier to control but some form of feedback loop is needed to track rotation as a stepper motor can miss steps or stall when loads are too high for the electrical/mechanical system so no savings in parts or complexity.
Pictures of the Clear Plastic Cover Demo Unit showing the internal parts of the rotor unit
This project uses a number of custom made parts. Some parts like the PCBA bracket are 3D Printed, and many of the aluminum parts are machined on large commercial CNC machines by local shops. Simpler Aluminum parts are made in our metal shop. Two custom PCBs were developed to support the electronics and industrial grade microcontrollers are used; sorry, no Arduinos in this product.
Some of the Custom Parts that we make in the shop or have made for us along with both PCBAs
Much of the design effort was in the software that controls the system. To use a 4 conductor Rotor Control cable and control 2 axis of rotation requires some form of programmatic control at the rotor units. Of the 4 conductors in the cable, 2 conductors are used for power, and 2 conductors are used for simplex RS485 serial communications. High slew rate drivers are used with the interface speed of 19.2Kbaud to minimize radiated noise. Early in the design phase a serial control protocol was developed to allow for the Hand Controller, which is the master controller in the system, to issue commands to and to receive responses from the remote Motor Controller. There are currently 17 commands used for inter-processor communications. Commands range from the most commonly used command called ‘getStatus” where the Hand controller is asking for status of the Motor Control System to the ‘Move’ command that starts the ‘moveAzEl’ to a new Az and or El position.
The motor Controller contains the more complex operating code and therefore has a larger firmware image. Not only does it respond and carry out operations directed by the Hand Controller but it manages the Magnetometer / Accelerator and GPS operations. It is the control that actually tracks antenna position and performs many operational functions autonomously. At system startup, the hand controller which has the flash memory, uploads stored configuration and position data to the motor unit. Status data along with Az and El position and operating temperature are requested and returned every second when operating with a non-poling host PC application or when operating standalone. With a poling host application the position pole from the host initiates the get status and other data process. Applications like PSTRotator poll continuously while applications like SATPC32 only pole for position data when a turn is in progress. The hand Controller automatically switches back and forth between the host computer initiated status poling and self-initiated status poling as conditions change.
Dual Axis System Block Diagram
All programming for the project is done in ‘C’ with assembly used for the boot-loader code. As with many complex control applications, the majority of the effort was in the software. There are well over 10K lines of code between the 2 processors where the binary image in the Hand Controller is a little less than 32K in size and the binary image in the Motor controller is a little over 32K. The code base grew as we added error detection and correction features. As the design matured we implement fail-safes features to prevent run away motors and recovery processes if something failed in a move operation such that user intervention is not needed.
I have read about various home brew dual axis satellite tracking systems that fellow hams have built in their home shops for use in portable operations but none have the rich feature set and can reliable handle an antenna load as large as the dual antenna LEO-PACK antenna system. For details on this 12PRSAT Rotor system and the many rapid deployment features built into the system, please download and read the full User Manual which can be found in the Resources section of the web page.
Copyright (C) Portable Rotation, Inc. 2017